《Java解惑》系列——02字符谜题——谜题15：令人晕头转向的hello

知识点：

在JavaDoc中，不要使用Unicode转义字符，应该使用HTML实体转义字符取代Unicode转义字符。

总之，要确保字符\u 不出现在一个合法的Unicode 转义字符上下文之外，即使是在注释中也是如此。

在机器生成的代码中要特别注意此问题。

问题：

下面的程序会打印什么？？

结果是不是出乎大家的意料呢？的确如此。
产生这个结果的原因：

这个谜题看起来相当简单。该程序包含了两条语句，第一条打印Hell，而第二
条在同一行打印o world，从而将两个字符串有效地连接在了一起。因此，你可
能期望该程序打印出Hello world。但是很可惜，你犯了错，实际上，它根本就
通不过编译。  
问题在于注释的第三行，它包含了字符\units。这些字符以反斜杠（\）以及紧
跟着的字母u开头的，而它（\u）表示的是一个Unicode 转义字符的开始。遗憾
的是，这些字符后面没有紧跟四个十六进制的数字，因此，这个Unicode 转义字
符是病构的，而编译器则被要求拒绝该程序。Unicode 转义字符必须是良构的，
即使是出现在注释中也是如此。  
在注释中插入一个良构的Unicode 转义字符是合法的，但是我们几乎没有什么理
由去这么做。程序员有时会在 JavaDoc注释中使用Unicode 转义字符来在文档中
生成特殊的字符。 
可能你会感到很诧异，在这个谜题中，问题出在注释这一信息来源自一个实际的
bug报告。该程序是机器生成的，这使得我们很难追踪到问题的源头
——IDL-to-Java编译器。为了避免让其他程序员也陷入此境地，在没有将
Windows文件名进行预先处理，以消除的其中的反斜杠的情况下，工具应该确保
不将Windows文件名置于所生成的 Java源文件的注释中。 

 

解决方法：

1、注意开头提到的知识点，在JavaDoc中不要使用Unicode转义字符，请使用HTML转义字符代替。

总结：

总之，要确保字符\u 不出现在一个合法的Unicode 转义字符上下文之外，即使
是在注释中也是如此。在机器生成的代码中要特别注意此问题。