谜题15:令人晕头转向的Hello
打印出什么呢?
/** * Generated by the IBM IDL-to-Java compiler, version 1.0 * from F:\TestRoot\apps\a1\units\include\PolicyHome.idl * Wednesday, June 17, 1998 6:44:40 o’clock AM GMT+00:00 */ public class Test{ public static void main(String[] args){ System.out.print("Hell"); System.out.println("o world"); } }
这个谜题看起来相当简单。该程序包含了两条语句,第一条打印Hell,而第二条在同一行打印o world,从而将两个字符串有效地连接在了一起。因此,你可能期望该程序打印出Hello world。但是很可惜,你犯了错,实际上,它根本就通不过编译。
问题在于注释的第三行,它包含了字符\units。这些字符以反斜杠(\)以及紧跟着的字母u 开头的,而它(\u)表示的是一个Unicode 转义字符的开始。遗憾的是,这些字符后面没有紧跟四个十六进制的数字,因此,这个Unicode 转义字符是病构的,而编译器则被要求拒绝该程序。Unicode 转义字符必须是良构的,即使是出现在注释中也是如此。
// Unicode 转义字符在JavaDoc 注释中有问题的用法 /** * This method calls itself recursively, causing a * StackOverflowError to be thrown. * The algorithm is due to Peter von der Ah\u00E9. */
应该使用HTML 实体转义字符来代替Unicode 转义字符:
/** * This method calls itself recursively, causing a * StackOverflowError to be thrown. * The algorithm is due to Peter von der Ahé. */
前面的两个注释都应该是的在文档中出现的名字为“Peter der Ahé”,但是后一个注释在源文件中还是可理解的。
可能你会感到很诧异,在这个谜题中,问题出在注释这一信息来源自一个实际的bug 报告。该程序是机器生成的,这使得我们很难追踪到问题的源头——IDL-to-Java 编译器。为了避免让其他程序员也陷入此境地,在没有将Windows 文件名进行预先处理,以消除的其中的反斜杠的情况下,工具应该确保不将Windows 文件名置于所生成的Java 源文件的注释中。
总之,要确保字符\u 不出现在一个合法的Unicode 转义字符上下文之外,即使是在注释中也是如此。在机器生成的代码中要特别注意此问题。