Question

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

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

尝试编译它，您将收到错误，例如：

A1.java:2: illegal line end in character literal
              Character aChar = '\u000d';
                                ^

为什么等效的c＃代码没有出现这样的问题？

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

我错过了什么吗？

编辑：我最初的问题是c＃编译器如何解析unicode文件正确（如果是这样）以及为什么java仍然应该使用不正确的（如果是）解析？编辑：我还想恢复原始问题标题？为什么这么重的编辑，我强烈怀疑它严重改变了我的意图。

Answer 1

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不是关键字。

为什么某些字符文字导致Java中的语法错误？

1 个答案: