您的位置:首页 > 编程语言 > Java开发

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

2014-04-23 11:57 344 查看

知识点:

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


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

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

问题:

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

/**
* 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");
}
}

// 期望结果:hello world
// 实际结果:不能通过编译


结果是不是出乎大家的意料呢?的确如此。

产生这个结果的原因:

这个谜题看起来相当简单。该程序包含了两条语句,第一条打印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 转义字符上下文之外,即使

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

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签:  java java解惑
相关文章推荐