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

【问题标题】：Why do some character literals cause Syntax Errors in Java?为什么某些字符文字会导致 Java 中的语法错误？
【发布时间】：2012-10-18 11:21:53
【问题描述】：

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

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

尝试编译一下，会报错，如：

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

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

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

我错过了什么吗？

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

【问题讨论】：

哈哈。你除了Java要改吗？我需要那种笑声:)
您可以恢复原始标题（单击“X 时间前编辑”链接查看修订）。然而，原标题对于比较 Java 的“方式”和 C# 的“方式”具有主观性和争论性。它们是具有不同规范的不同语言。
@pst - 但是有了这个标题，我不应该问这个问题，因为同一份时事通讯给出了足够的解释。我尊重所做的编辑，并不强制恢复它。我的意图是为什么两个相似的编译器在这种情况下存在差异。
我不是故意输的（我认为它仍然存在，即使不在最前沿）。在这一点上，我唯一能给出的解释是“因为规范是这样写的”。虽然并非总是如此，我发现 C# 通常“清理”了 Java 使用的语法，同时逐渐添加了 Java 中没有的新功能。我怀疑其中一些基本的解析“缺陷”是由从事 C# 1.0 工作的个人解决（该版本比 Java 晚了至少几年，并且深受 Java 的影响）。

标签： c# java unicode syntax-error

【解决方案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 不是关键字。

【讨论】：

能否详细说明“稍后”、“某些类型的令牌”、“某些地方”？
@Vic：“稍后”几乎是我能做到的，“某些地方”甚至带有一个例子。我已经为“某些类型的令牌”添加了说明。