一些编译器在 JavaDoc 和源代码注释中的非 ASCII 字符上失败。
这很可能是因为编译器假定输入是 UTF-8,并且源文件中存在无效的 UTF-8 序列。这些似乎在源代码编辑器的注释中是无关紧要的,因为词法分析器(将注释与其他标记区分开来)永远不会运行。当工具在词法分析器运行之前尝试将字节转换为字符时发生故障。
和说的man
页面javac
javadoc
-encoding name
Specifies the source file encoding name, such as
EUCJIS/SJIS. If this option is not specified, the plat-
form default converter is used.
所以javadoc
使用编码标志运行
javadoc -encoding <encoding-name> ...
替换<encoding-name>
为您用于源文件的编码后,应使其使用正确的编码。
如果您在需要一起编译的一组源文件中使用了多个编码,则需要首先修复该问题并为所有源文件确定一个统一的编码。你真的应该只使用 UTF-8 或坚持使用 ASCII。
Java 源文件中关于 Unicode 的当前(Java 7)和未来(Java 8 及更高版本)实践是什么?
Java中处理源文件的算法是
- 收集字节
- 使用某种编码将字节转换为字符(UTF-16 代码单元)。
'\\'
'u'
用对应于这些十六进制数字的代码单元替换所有后跟四个十六进制数字的序列。如果"\u"
后面没有四个十六进制数字,则会出错。
- 将字符转换为标记。
- 将标记解析为类。
当前和以前的做法是第 2 步,将字节转换为 UTF-16 代码单元,取决于加载编译单元(源文件)的工具,但命令行界面的实际标准是使用-encoding
标志。
转换发生后,语言要求\uABCD
在词法分析和解析之前将样式序列转换为 UTF-16 代码单元(步骤 3)。
例如:
int a;
\u0061 = 42;
是一对有效的 Java 语句。任何 java 源代码工具都必须在将字节转换为字符之后但在解析之前查找 \uABCD 序列并对其进行转换,以便将此代码转换为
int a;
a = 42;
在解析之前。无论 \uABCD 序列出现在何处,都会发生这种情况。
这个过程看起来像
- 获取字节:
[105, 110, 116, 32, 97, 59, 10, 92, 117, 48, 48, 54, 49, 32, 61, 32, 52, 50, 59]
- 将字节转换为字符:
['i', 'n', 't', ' ', 'a', ';', '\n', '\\', 'u', '0', '0', '6', '1', ' ', '=', ' ', '4', '2', ';']
- 替换 unicode 转义:
['i', 'n', 't', ' ', 'a', ';', '\n', a, ' ', '=', ' ', '4', '2', ';']
- 莱克斯:
["int", "a", ";", "a", "=", "42", ";"]
- 解析:
(Block (Variable (Type int) (Identifier "a")) (Assign (Reference "a") (Int 42)))
JavaDoc 中的所有非 ASCII 字符是否应该使用 HTML &escape; 类代码进行转义?
'<'
除了您希望在文档中逐字显示的 HTML 特殊字符外,不需要。您可以\uABCD
在 javadoc 注释中使用序列。在解析源文件之前进行Java 处理\u....
,因此它们可以真正出现在字符串、注释、任何地方。这就是为什么
System.out.println("Hello, world!\u0022);
是有效的 Java 语句。
/** @return \u03b8 in radians */
相当于
/** @return θ in radians */
就 javadoc 而言。
但是 Java//
注释的等价物是什么?
您可以//
在 java 中使用注释,但 Javadoc 只在/**...*/
注释中查找文档。 //
评论不携带元数据。
\uABCD
Java 处理序列的一个分支是,虽然
// Comment text.\u000A System.out.println("Not really comment text");
看起来像单行注释,许多 IDE 会这样突出显示它,但事实并非如此。