为什么Java允许在源代码中转义unicode字符？

2018-05-30 04:14:38

我最近了解到的Unicode是Java源代码内允许不仅为Unicode字符（例如。 double π = Math.PI;而且还为转义序列（例如。 double u03C0 = Math.PI;

第一个变体对我来说很有意义 - 它允许程序员用他们选择的国际语言命名变量和方法。但是，我没有看到第二种方法的实际应用。

以下是一些代码示例，用Java SE 6和NetBeans 6.9.1进行了测试：

此代码将打印出3.141592653589793

public static void main(String[] args) {
    double π = Math.PI;
    System.out.println(u03C0);
}

说明：π和 u03C0是相同的Unicode字符

此代码不会打印出任何内容

public static void main(String[] args) {
    double π = Math.PI; /u002A
    System.out.println(π);

    /* a comment */
}

说明：上面的代码实际上编码为：

public static void main(String[] args) {
    double π = Math.PI; /*
    System.out.println(π);

    /* a comment */
}

哪些评论印刷品。

从我的例子来看，我注意到这种语言功能存在一些潜在的问题。

首先，一个糟糕的程序员可能会用它来暗中评论一些代码，或者创建多种识别同一个变量的方法。也许还有其他可怕的事情可以做，我没有想到。

其次，IDE之间似乎缺乏支持。 NetBeans和Eclipse都没有为示例提供正确的代码突出显示。事实上，NetBeans甚至标记了语法错误（尽管编译不是问题）。

最后，这个功能没有文档记录，也没有被普遍接受。为什么程序员会在他的代码中使用其他程序员无法识别和理解的东西？事实上，我甚至无法在隐藏的Java功能问题上找到关于此的信息。

我的问题是这样的：

为什么Java允许在语法中使用转义的Unicode序列？尽管有许多“缺点”，这个功能的某些“优点”是什么让它能够保持Java的一部分？

Unicode转义序列允许您以纯ASCII格式存储和传输源代码，并仍然使用整个Unicode字符范围。这有两个好处：

没有非ASCII字符被无法处理它们的工具破坏的风险。这在九十年代早期Java设计时是一个真正的问题。发送包含非ASCII字符的电子邮件并使其到达不受限制是一种例外情况，而不是常态。

无需告诉编译器和编辑器/ IDE使用哪种编码来解释源代码。这仍然是一个非常有效的关注点。当然，更好的解决方案应该是将编码作为元数据放在文件头中（如XML），但这还没有成为当时的最佳实践。

第一个变体对我来说很有意义 - 它允许程序员用他们选择的国际语言命名变量和方法。但是，我没有看到第二种方法的实际应用。

两者都会产生完全相同的字节码，并具有与语言功能相同的功能。唯一的区别在于源代码。

首先，一个糟糕的程序员可能会用它来暗中评论一些代码，或者创建多种识别同一个变量的方法。

如果你担心程序员故意破坏你的代码的可读性，那么这种语言特性是你的问题中最少的。

其次，IDE之间似乎缺乏支持。

这不是该功能或其设计者的缺点。但是，我不认为它曾经打算被“手动”使用。理想情况下，IDE可以选择让您正常输入字符并使其正常显示，但会自动将它们保存为Unicode转义序列。甚至可能已经有插件或配置选项，使IDE的行为。

但总的来说，这个功能似乎很少使用，因此可能得不到支持。但是，1993年前后设计Java的人怎么会知道这一点呢？

关于u03C0编码的u03C0在于它不太可能被错误编码设置的文本编辑器淹没。例如，在我的软件中的错误是从UTF-8所引起的意外转变é成的MacRoman é被错误配置的文本编辑器。通过指定Unicode代码点，您的意思完全毫不含糊。

uXXXX语法允许Unicode字符在不能直接表达它们的编码的文件中明确表示，或者即使在最小公分母（即7位ASCII编码）中也保证可用表示。

你可以使用 uXXXX来表示你所有的角色，甚至是空格和字母，但是很少需要。

链接地址: http://www.djcxy.com/p/3471.html