当 UTF-16 无法解决问题时，Java 会采取保护措施

Question

我的理解是Java默认使用UTF-16(对于String和char以及可能的其他类型)并且UTF-16是地球上大多数字符编码的主要超集(尽管我可能是错的)。但我需要一种方法来保护我的应用程序，以防止它读取使用 UTF-16 不支持的编码(我不确定是否有很多或根本没有)生成的文件。

所以我问:

1. 在读取文件之前假设文件是​​ UTF-16 是否安全，或者，为了最大限度地提高不出现 NPE 或其他格式错误的输入异常的机会，我是否应该使用 JUniversalCharDet 或 JCharDet 或 ICU4J 等字符编码检测器来首先检测编码？
2. 然后，在写入文件时，我需要确保字符/字节没有进入产生以下结果的内存对象(字符串、OutputStream 等)写入字符串或文件时产生垃圾文本/字符。理想情况下，我希望有某种方法来确保这个产生垃圾的字符在进入我正在编写的文件之前以某种方式被捕获。我该如何防范这种情况？

提前致谢。

Answer 1

Java normally uses UTF-16 for its internal representation of characters 。 Java char 数组是 UTF-16 编码的 Unicode 代码点的序列。默认情况下，char 值被视为 Big Endian(与任何 Java 基本类型一样)。但是，您不应使用 char 值将字符串写入文件或内存。您应该使用 Java API 中的字符编码/解码功能(见下文)。

UTF-16 不是编码的主要超集。实际上，UTF-8 和 UTF-16 都可以对任何 Unicode 代码点进行编码。从这个意义上说，Unicode确实定义了您可能想在现代通信中使用的几乎所有字符。

如果您从磁盘读取文件并假定 UTF-16，那么您很快就会遇到麻烦。大多数文本文件使用 ASCII 或 ASCII 的扩展来使用一个字节的所有 8 位。这些扩展的示例包括 UTF-8(可用于读取任何 ASCII 文本)或 ISO 8859-1(拉丁文)。然后有很多编码，例如由作为这些扩展的扩展的 Windows 使用。 UTF-16 不与 ASCII 兼容，因此不应将其用作大多数应用程序的默认值。

所以，是的，如果您想读取大量编码未知的纯文本文件，请使用某种检测器。这应该可以回答问题 #1。

对于问题#2，想象一个完全是 ASCII 的文件。现在您想要添加一个不在 ASCII 中的字符。您选择 UTF-8(这是一个非常安全的选择)。无法知道打开文件的程序是否正确猜测它应该使用 UTF-8。它可能会尝试使用拉丁语，甚至更糟糕，假设使用 7 位 ASCII。在这种情况下，你会得到垃圾。不幸的是，没有任何聪明的技巧可以确保这种情况永远不会发生。

查看CharsetEncoder和 CharsetDecoder类来了解 Java 如何处理编码/解码。