5

在最新一期的 JavaSpecialists 时事通讯中，作者提到了一段在 Java 中不可编译的代码

public class A1 {
  Character aChar = '\u000d';
}

尝试编译它，你会得到一个错误，例如：

A1.java:2：字符文字中的非法行结束
              字符 aChar = '\u000d';
                                ^

为什么等效的一段 c# 代码没有显示出这样的问题？

public class CharacterFixture
{
  char aChar = '\u000d';
}

我错过了什么吗？

编辑：我最初的问题是 c# 编译器如何正确解析 unicode 文件（如果是的话），为什么 java 仍然应该坚持不正确的（如果是的话）解析？编辑：我还想恢复我原来的问题标题？为什么要进行如此繁重的编辑，我强烈怀疑它严重改变了我的意图。

4

1 回答 1

12

Java 的编译器将\uxxxx转义序列翻译为最开始的步骤之一，甚至在标记器破解代码之前。当它真正开始标记时，已经没有\uxxxx序列了；它们已经变成了它们所代表的字符，因此对于编译器来说，您的 Java 示例看起来就像您实际上在其中以某种方式输入了回车一样。它这样做是为了提供一种在源中使用 Unicode 的方法，而不管源文件的编码如何。如有必要，即使 ASCII 文本仍然可以完全表示 Unicode 字符（以可读性为代价），而且由于它做得这么早，您几乎可以在代码中的任何地方使用它们。（您可以说\u0063\u006c\u0061\u0073\u0073\u0020\u0053\u0074\u0075\u0066\u0066\u0020\u007b\u007d，编译器会将其读取为class Stuff {}，如果你想惹恼或折磨自己。）

C# 不这样做。 \uxxxx稍后与程序的其余部分一起翻译，并且仅在某些类型的标记中有效（即，标识符和字符串/字符文字）。这意味着它不能在某些可以在 Java 中使用的地方使用。 cl\u0061ss例如，不是关键字。

于 2012-10-29T06:12:01.743 回答