下面的代码产生输出“Hello World!”(不,真的,试试看)。

public static void main(String... args) {

   // The comment below is not a typo.
   // \u000d System.out.println("Hello World!");
}

这样做的原因是Java编译器将Unicode字符\u000d解析为一个新行,并转换为:

public static void main(String... args) {

   // The comment below is not a typo.
   //
   System.out.println("Hello World!");
}

从而导致注释被“执行”。

既然这可以用来“隐藏”恶意代码或任何邪恶的程序员能想到的东西,为什么它被允许在注释中呢?

为什么Java规范允许这样做?


当前回答

我同意@zwol的观点,这是一个设计错误;但我对它更加挑剔。

\u转义在字符串和char字面值中很有用;这是它唯一应该存在的地方。它应该像其他转义一样处理,比如\n;“\u000A”的意思应该是“\n”。

在评论中有\uxxxx是绝对没有意义的——没有人能读懂。

类似地,在程序的其他部分使用\uxxxx也没有意义。唯一的例外可能是在强制包含一些非ascii字符的公共api中——我们上次看到这种情况是什么时候?

设计者在1995年有他们的理由,但20年后,这似乎是一个错误的选择。

(问读者——为什么这个问题不断得到新的投票?这个问题是来自某个流行的地方吗?)

其他回答

由于这还没有解决,这里有一个解释,为什么Unicode转义的翻译发生在任何其他源代码处理之前:

它背后的想法是,它允许在不同字符编码之间无损地转换Java源代码。今天,Unicode得到了广泛的支持,这看起来不像是一个问题,但在当时,对于一个西方国家的开发人员来说,从他的亚洲同事那里收到一些包含亚洲字符的源代码,进行一些更改(包括编译和测试),并将结果发送回去,而不破坏任何东西是不容易的。

因此,Java源代码可以用任何编码编写,并允许在标识符、字符和字符串字面量和注释中使用广泛的字符。然后,为了无损地传输它,目标编码不支持的所有字符都被它们的Unicode转义替换。

这是一个可逆的过程,有趣的是,翻译可以通过一个不需要了解任何Java源代码语法的工具来完成,因为翻译规则不依赖于它。这是因为在编译器中转换到实际Unicode字符的过程也独立于Java源代码语法。这意味着您可以在两个方向上执行任意数量的翻译步骤,而不会改变源代码的含义。

这就是为什么会出现另一个没有提到的奇怪特性:\uuuuuuxxxx语法:

当翻译工具转义字符时,遇到一个已经是转义序列的序列,它应该在序列中插入一个额外的u,将\ucafe转换为\uucafe。含义不会改变,但是当转换到另一个方向时,该工具应该只删除一个u,并仅用Unicode字符替换包含单个u的序列。这样,在来回转换时,即使是Unicode转义也会保留其原始形式。我想,没有人使用过这个功能……

“这样做的原因是Java编译器将Unicode字符\u000d解析为新行”。

如果为真,那么这正是错误发生的地方。

Java编译器也许应该拒绝编译这个源代码,因为(作为Java源代码)它是格式不正确的,因此要么一开始就不好,要么在途中被篡改,要么被不理解转换规则的工具链中的某些东西改变了。他们不应该盲目地改造它。

如果所讨论的编辑器是一个只使用ascii的工具,那么所述编辑器正在做正确的事情——将Unicode转义序列视为(格式错误的)注释中无意义的字符串。

如果所讨论的编辑器是一个支持Unicode的工具,那么它也在做正确的事情——保持Unicode转义序列“原样”,并将其视为(格式错误的)注释中无意义的字符串。

无损可逆转换需要将1-1映射到——因此两个集合的交集必须为空。在这里,即使正确实现的escape-ify-ing转换没有修改字符,这两个问题集也可以重叠,因为范围(000-07F)中的escaping - unicode可能已经出现在输入流中。

如果目标是在Unicode和ASCII之间进行无损、可逆的转换,则转换到/从ASCII的要求是转义/重新编码任何大于hex 007F的Unicode字符,并保留其余的字符。

做到这一点后,Unicode感知的语言将把转义后的Unicode字符视为注释或字符串内部以外的任何地方的错误——它们不能在注释中转换,但必须在字符串中转换——因此在词法分析将源转换为标记(即词素)之前不能进行转换,从而允许以类型安全的方式进行转换。

这是一个有意的设计选择,可以一直追溯到Java的原始设计。

对于那些问“谁想在注释中使用Unicode转义?”的人,我假设他们的母语是拉丁字符集。换句话说,在Java的原始设计中,人们可以在Java程序中任何合法的地方使用任意的Unicode字符,最典型的是在注释和字符串中。

这可以说是用于查看源文本的程序(如ide)的一个缺点,即这些程序不能解释Unicode转义并显示相应的字形。

Unicode解码发生在任何其他词汇翻译之前。这样做的主要好处是,它使得在ASCII和任何其他编码之间来回切换变得很简单。你甚至不需要弄清楚注释在哪里开始和结束!

正如JLS 3.3节所述,这允许任何基于ASCII的工具来处理源文件:

[…Java编程语言指定了一种将用Unicode编写的程序转换为ASCII的标准方法,这种方法可以将程序转换为基于ASCII的工具可以处理的形式。[…]

这为平台独立性(支持字符集的独立性)提供了基本保证,这一直是Java平台的关键目标。

能够在文件的任何位置编写任何Unicode字符是一个很好的特性,在用非拉丁语言编写代码时,这在注释中尤其重要。事实上,它能以如此微妙的方式干扰语义只是一个(不幸的)副作用。

关于这个主题有许多陷阱,Joshua Bloch和Neal Gafter的《Java Puzzlers》包含以下变体:

这是一个合法的Java程序吗?如果是,它打印什么? \ u0070 \ u0075 \ u0062 \ u006c \ u0069 \ u0063 \ u0020 \ u0020 \ u0020 \ u0020 \ u0063 \ u006c \ u0061 \ u0073 \ u0073 \ u0020 \ u0055 \ u0067 \ u006c \ u0079 \ u007b \ u0070 \ u0075 \ u0062 \ u006c \ u0069 \ u0063 \ u0020 \ u0020 \ u0020 \ u0020 \ u0020 \ u0020 \ u0020 \ u0073 \ u0074 \ u0061 \ u0074 \ u0069 \ u0063 \ u0076 \ u006f \ u0069 \ u0064 \ u0020 \ u006d \ u0061 \ u0069 \ u006e \ u0028 \ u0053 \ u0074 \ u0072 \ u0069 \ u006e \ u0067 \ u005b \ u005d \ u0020 \ u0020 \ u0020 \ u0020 \ u0020 \ u0020 \ u0061 \ u0072 \ u0067 \ u0073 \ u0029 \ u007b \ u0053 \ u0079 \ u0073 \ u0074 \ u0065 \ u006d \ u002e \ u006f \ u0075 \ u0074 \ u002e \ u0070 \ u0072 \ u0069 \ u006e \ u0074 \ u006c \ u006e \ u0028 \ u0020 \ u0022 \ u0048 \ u0065 \ u006c \ u006c \ u006f \ u0020 \ u0077 \ u0022 \ u002b \ u0022 \ u006f \ u0072 \ u006c \ u0064 \ u0022 \ u0029 \ u003b \ u007d \ u007d

(这个程序原来是一个普通的“Hello World”程序。)

在谜题的解决方案中,他们指出了以下几点:

更严重的是,这个难题有助于加强前三个问题的教训:当您需要将无法以任何其他方式表示的字符插入到程序中时,Unicode转义是必不可少的。在所有其他情况下都要避免使用。


Java:在注释中执行代码?!

我同意@zwol的观点,这是一个设计错误;但我对它更加挑剔。

\u转义在字符串和char字面值中很有用;这是它唯一应该存在的地方。它应该像其他转义一样处理,比如\n;“\u000A”的意思应该是“\n”。

在评论中有\uxxxx是绝对没有意义的——没有人能读懂。

类似地,在程序的其他部分使用\uxxxx也没有意义。唯一的例外可能是在强制包含一些非ascii字符的公共api中——我们上次看到这种情况是什么时候?

设计者在1995年有他们的理由,但20年后,这似乎是一个错误的选择。

(问读者——为什么这个问题不断得到新的投票?这个问题是来自某个流行的地方吗?)