此行编译正确
Thread t = \u006E\u0065\u0077\u0020\u0054\u0068\u0072\u0065\u0061\u0064\u0028\u0029\u003B
这是文本new Thread();
我的问题是接受" "或' '之外的unicode字符需要什么。我们可以在字符串文字和字符文字中使用unicodes。但是在实际的代码中它需要被接受的是什么？
答案 0 :(得分：5)
这样做的原因是Unicode转义序列不是由语法或字符串解析代码处理，而是由tokenizer处理。因此，Java语法永远不会“看到”那些转义序列，它会获得一个Unicode字符串。
这有不幸的副作用，如此代码无法编译：
// C:\user\...
对于我们大多数人来说，这是一个评论。对于tokenizer，它是非法的unicode序列ser\。
这样做的原因是你现在可以在Java源代码中的任何地方使用任何Unicode字符 - Java标识符不仅限于ASCII！
但编辑Java的工具可能不太好。 1994年，很难找到一个支持Unicode的文本编辑器。此外，如果您使用ASCII，代码生成器通常可以更好地工作。
答案 1 :(得分：4)
JLS指定了
Java编程语言（“Java编译器”）的编译器首先在其输入中识别Unicode转义符，将ASCII字符\ u后跟四个十六进制数字转换为指定十六进制的UTF-16代码单元（第3.1节）值
这个转换后的版本同样可以被Java编译器接受并代表完全相同的程序。以后可以通过转换存在多个u的每个转义序列来从此ASCII格式恢复确切的Unicode源。一个Unicode字符序列，少一个u，同时将每个转义序列用单个u转换为相应的单个Unicode字符。
答案 2 :(得分：2)
这是有效的，因为Java语言规范要求这样做。见3.3. Unicode Escapes：
Java编程语言（“Java编译器”）的编译器首先在其输入中识别Unicode转义，将ASCII字符
\u后跟四个十六进制数字转换为UTF-16代码单元（第3.1节）。指示的十六进制值，并传递所有其他字符不变。表示补充字符需要两个连续的Unicode转义。此转换步骤将生成一系列Unicode输入字符。
原因很简单：Java允许完全支持unicode（即使是标识符！），但有时为源文件使用实际的unicode是不切实际的，在这种情况下你可以使用转义。
这也意味着unicode转义不是Java中字符串的工件，而是编译器的实际内容：如果你有一个带有unicode转义的String（或char），它将在编译时转换为实际的角色，而不是在运行时！
3.2. Lexical Translations部分也很重要：
使用以下三个词汇翻译步骤将原始Unicode字符流转换为一系列标记，这些步骤依次应用：
将Unicode字符的原始流中的Unicode转义（第3.3节）转换为相应的Unicode字符。形式为
\uxxxx的Unicode转义，其中xxxx是十六进制值，表示编码为xxxx的UTF-16代码单元。此转换步骤允许任何程序仅使用ASCII字符表示。- 产生的Unicode流的翻译
步骤1 [...]
答案 3 :(得分：1)
如果源代码不是UTF-8，则此功能可以在源代码中使用Unicode字符，否则无法使用