以非ASCII语言编码

Question

好吧,我发现这对我来说非常奇怪,但在C#中,你实际上可以用不同的语言编写源代码.我用韩语写了一个示例源代码来说明我的观点:

namespace ???? {
    public class ?? {
        public string ?? { get; private set; }
        public string ??? { get; private set; }

        public ??(string ??, string ???) {
            this.?? = ??;
            this.??? = ???;
        }
    }
    public class ??? {
        private List<??> ????? = new List<??>();

        public void ??(?? ???) {
            ?????.Add(???);
        }

        public void ?????() {
            foreach (?? ????? in ?????) {
                Console.WriteLine("??: {0}", ?????.??);
                Console.WriteLine("???: {0}", ?????.???);
            }
        }
    }
    public class ???? {
        static void Main(string[] args) {
            ??? ????? = new ???();
            ?????.??(new ??("???", "??? ?? 29??? ??? ? ???? ??? ??? ????? ?????"));
            ?????.??(new ??("????", "??? ?? ? ????? ???!!!"));
            ?????.??(new ??("?????", "?? ???? ?? ?????~~~"));

            ?????.?????();
        }
    }
}

上面的代码编译并为您提供有效的输出.

除了关键字,您实际上可以使用英语以外的语言编写源代码.当然,这是非常不切实际的,没有人会这样做.

我的问题如下:

• 这是C#功能还是Visual Studio功能？(我无法在Visual Studio 2010下获得类似的程序在C++中工作)
• 性能影响是什么？(我很乐意假设几乎没有,但不确定他们是否进行了任何类型的疯狂转换,允许非ASCII字符进行编码)
• 实现此功能的原因是什么？

Answer 1

1:它是C#语言规范,所以:C#

2:没有; 解析器并不关心某些东西是否是Fredvs ????; 对编译器来说都不重要

3:因为并非所有开发人员都说英语(或拉丁语言)作为他们的主要语言.它很可能是????表达类的意图很容易和有意义的对项目工作的开发者

Answer 2

1) C# 规范和 CLI 规范都允许这样做。

C# 标准说

源文件是 Unicode 字符的有序序列。

和

符合标准的程序中的标识符必须采用 Unicode 规范化形式 C 定义的规范格式，如 Unicode 标准附件 15 所定义。遇到非规范化形式 C 中的标识符时的行为是实现定义的；然而，不需要诊断。

ECMA CLI 标准是这样说的：

I.8.5 命名

名称被赋予类型系统的实体，以便它们可以被类型系统的其他部分或类型的实现引用。类型、字段、方法、属性和事件都有名称。对于类型系统，值、局部变量和参数没有名称。类型系统的实体被赋予单一名称（例如，一种类型只有一个名称）。

I.8.5.1 有效名称

所有名称比较都是在逐字节（即区分大小写、与区域设置无关，也称为代码点比较）的基础上完成的。当名称用于访问内置 VES 提供的功能（例如，类初始化方法）时，定义上始终有一个附带指示，以免内置任何保留名称集。

重要段落如下：

CLS 规则 4：程序集应遵循 Unicode 标准 3.0 技术报告 15 的附件 7，该附录 7 管理允许开始并包含在标识符中的字符集，可在线获取：http://www.unicode.org/unicode/reports/tr15 /tr15-18.html 标识符应采用 Unicode 规范化形式 C 定义的规范格式。出于 CLS 目的，如果两个标识符的小写映射（由 Unicode 区域设置不敏感的一对一小写映射指定）相同，则两个标识符是相同的） 是相同的。也就是说，对于在 CLS 下被视为不同的两个标识符，它们的不同不仅仅在于其大小写的不同。然而，为了覆盖继承的定义，CLI 需要使用原始声明的精确编码。

[注意：CLS（消费者）：不需要使用违反 CLS 规则 4 的类型，但应有一种机制允许访问使用其自己的关键字之一作为名称的命名项。CLS（扩展程序）：不需要创建违反 CLS 规则 4 的类型。应提供一种机制来定义遵守这些规则的新名称，但与语言中的关键字相同。CLS（框架）：不得导出违反 CLS 规则 4 的类型。应避免使用编程语言中常用作关键字的名称。

2) 不应有任何性能影响。CLI 规则规定，名称匹配必须使用 Unicode 区域设置不敏感映射来完成，这意味着当需要比较两个名称时，必须转换为 Unicode 代码点序列。如果编译器或运行时选择将此信息保留在可变长度编码（例如 UTF-8）中并动态转换为代码点，那么理论上会存在一些性能差异；实际上，我不期望任何实现能够做到这一点，或者如果它们这样做的话，性能差异是可测量的。

请注意，CLS 规则 4 表示“为了覆盖继承的定义，CLI 需要使用原始声明的精确编码”，这在覆盖名称时确实施加了特定的限制。但由于这不是普遍要求，因此无论如何都必须实现“在比较之前将所有内容转换为代码点”。

3) 同样，这是在 CLI 规范中，因此语言必须这样做。