.net - COM/.NET 接口(interface)名称中的非字母数字字符

Question

我正在考虑使用字符#@!在我们的系统生成的一些 COM 接口(interface)中。 COM 类型库也导出到 .NET。这些角色以后会给我带来麻烦吗？

我今天大部分时间都对其进行了测试，一切似乎都很好。我们的系统会像往常一样继续工作。

我谨慎的原因是这些字符在 MIDL 中是非法的，它使用 C 语法作为类型名称。但是我们不使用 MIDL - 我们使用 ICreateTypeInfo 和 ICreateTypeLib 构建我们的类型库。看起来这只是 MIDL 限制，COM 和 .NET 对非字母数字字符感到满意。但也许有一些我不知道的...

Answer 1

这就是我发现的。

我认为毫无疑问，这些名称在 COM 中的二进制级别是合法的，因为 COM 接口(interface)的名称是它的 IID，而文本名称只是文档。

在 .NET 方面，相关规范是公共(public)语言基础设施规范(ECMA-335，http://www.ecma-international.org/publications/standards/Ecma-335.htm。)我想知道 .NET 或 Mono 是否在顶部添加了自己的限制——这样做会降低互操作性，但这是真实世界。

第 8.5.1 节介绍了通用类型系统中的有效类型名称，并简单地说名称是使用代码点进行比较的。奇怪的是，它没有说明名称的组成，只说明名称的比较方式。此部分由 MSDN 在 http://msdn.microsoft.com/en-us/library/exy17tbw%28v=VS.85%29.aspx 上解释。 ，它表示唯一的两个限制是(1)类型名称“编码为 Unicode(16 位)字符的字符串”，以及(2)它们不能包含嵌入的 0x0000。

我引用了关于 16 位 Unicode 的内容，而不是对其进行解释，因为它使用了不精确的语言。据推测，该页面的作者指的是 UTF-16。在任何情况下，ECMA-335 都指定了逐字节比较，并且没有提及 Unicode(关于类型名称)，也没有禁止嵌入零。也许.NET 已经偏离了这里的 CTS，尽管我对此表示怀疑。更有可能的是，这个 MSDN 页面的作者在编写它时正在考虑编程语言。

公共(public)语言规范(也在 ECMA-335 中定义)定义了源代码中标识符的规则。标识符与我的问题没有直接关系，因为我的内部类型名称从未出现在源代码中，但我还是调查了它。 CLS 是 CTS 的一个子集，因此它的限制不一定是更广泛的 CTS 的一部分。 CLS 规则 4 规定标识符必须遵循 Unicode 标准 3.0 技术报告 15 附件 7 的规则 - 参见 http://www.unicode.org/reports/tr15/tr15-18.html .该文件也有点模糊，因为它提到了“其他字母”和“连接标点符号”，但没有定义它们。这有助于:http://notes.jschutz.net/topics/unicode/ .

ECMA 规范的第 8.5.1 节包含一个非规范性注释，即 CLS 使用者(我想，例如 C# 或 Visual Studio 类型浏览器)“不需要使用违反 CLS 规则 4 的类型”。我提议的接口(interface)名称确实违反了规则 4。该注释似乎暗示有效类型的名称可能违反规则 4，并且 CLS 使用者应该接受流氓名称或安全地忽略它。 (Visual Studio 类型的浏览器毫无怨言地显示它。)

所以我提议的类型名称在源代码中通常是非法的。但请注意，第 10.1 节(关于 CLS 中的标识符)说“由于其规则仅适用于导出到其他语言的项目，因此未从程序集导出的私有(private)成员或类型可以使用他们选择的任何名称。”

我的结论是使用字符#@ 是安全的!在我的类型名称中，只要它们保留在二进制域中并且永远不需要出现在源代码中或程序集之外。事实上，它们从未在 COM 服务器之外使用过。

关于面向 future 的一句话…… CTS 对类型名称的组成几乎没有什么要说的，尽管有一个称为“有效名称”的部分(第 8.5.1 节)。他们将来可能会改变这一点，但是这个广泛而自由的规范已经邀请我们所有人做我们喜欢做的事情。如果 CTS 的设计者想要为改变留出空间，那么他们肯定会为此做出一些规定，或者至少不那么慷慨。