Java中的UTF-8和UTF-16

Question

我真的希望下面的字节数据显示不同，但事实上，它们是相同的，根据维基http://en.wikipedia.org/wiki/UTF-8#Examples ，字节中的编码看起来不同，但为什么Java打印出来的一样吗？

    String a = "€";
    byte[] utf16 = a.getBytes(); //Java default UTF-16
    byte[] utf8 = null;

    try {
        utf8 = a.getBytes("UTF-8");
    } catch (UnsupportedEncodingException e) {
        throw new RuntimeException(e);
    }

    for (int i = 0 ; i < utf16.length ; i ++){
        System.out.println("utf16 = " + utf16[i]);
    }

    for (int i = 0 ; i < utf8.length ; i ++){
        System.out.println("utf8 = " + utf8[i]);
    }

Answer 1

虽然Java在内部将字符保存为UTF-16，但是当您使用String.getBytes()转换为字节时，每个字符都使用默认的平台编码进行转换，这可能类似于windows-1252 。 我得到的结果是：

utf16 = -30
utf16 = -126
utf16 = -84
utf8 = -30
utf8 = -126
utf8 = -84

这表示我的系统上的默认编码是“UTF-8”。

另请注意，String.getBytes（）的文档具有以下注释： The behavior of this method when this string cannot be encoded in the default charset is unspecified.

但是，一般情况下，如果你总是像使用a.getBytes("UTF-8")那样指定一个编码，你就会避免混淆

另外，另一件可能导致混淆的事情是在源文件中直接包含Unicode字符： String a = "€"; 。 该欧元符号必须编码为存储为文件中的一个或多个字节。 当Java编译您的程序时，它会看到这些字节并将它们解码回欧元符号。 你希望。 你必须确保将欧元符号保存到文件中的软件（记事本，eclipse等）以与Java期望的方式相同的方式对其进行编码.UTF-8正变得越来越流行，但它并不普及并且许多编辑器不会以UTF-8编写文件。

Answer 2

一个好奇心，我想知道JVM如何知道原来的默认字符集......

JVM用于确定初始默认字符集的机制是特定于平台的。 在UNIX /类UNIX系统上，它由LANG和LC_ *环境变量决定; 看到man locale 。

---

Ermmm ..此命令用于检查特定操作系统中的默认字符集是什么？

那是对的。 但我告诉过你，因为手动条目描述了默认编码是如何由环境变量决定的。

回想起来，这可能不是您原始评论的意思，但这是指定平台默认编码的方式。 （并且单个文件的“默认字符集”的概念毫无意义;请参阅下文。）

假设我有10个Java源文件，其中一半保存为UTF-8，其余保存为UTF-16，编译后，我将它们（类文件）移动到另一个OS平台，现在JVM知道它们的默认编码？ 是否将默认的字符集信息包含在Java类文件中？

这是一组相当混乱的问题：

1. 文本文件没有默认字符集。 它有一个字符集/编码。

2. 非文本文件根本没有字符编码。 这个概念毫无意义。

3. 没有100％可靠的方法来确定文本文件的字符编码是什么。

4. 如果你不告诉java编译器文件的编码是什么，它将假定它是平台的默认编码。 编译器不会试图再次猜测你。 如果编码不正确，编译器可能会或可能不会注意到您的错误。

5. 字节码（“。class”）文件是二进制文件（见2）。

6. 当字符和字符串文字被编译成“.class”文件时，它们现在以不受平台默认编码影响的方式或您可以影响的任何其他方式表示。

7. 如果在编译时使用源文件编码时出错，则无法在“.class”文件级别修复它。 您唯一的选择是返回并重新编译类，告诉Java编译器正确的源文件编码。

8. “如果我说我有10个Java源文件，其中一半保存为UTF-8，其余保存为UTF-16” 。
   就是不要这样做！

   • 不要将源文件保存在混合编码中。 你会疯狂的。
   • 我完全没有理由把文件存储在UTF-16中......

---

所以，我很困惑，虽然人们说“平台依赖”，它是否与源文件有关？

依赖于平台意味着它可能依赖于操作系统，JVM供应商和版本，硬件等。

它不一定与源文件有关。 （任何给定源文件的编码可能与默认字符编码不同。）

如果不是，我该如何解释上述现象？ 无论如何，上面的混淆将我的问题扩展到“所以，在我将源文件编译成类文件后会发生什么，因为类文件可能不包含编码信息，所以现在结果实际上依赖于'platform'而不是源文件了？”

平台特定机制（例如环境变量）确定java编译器将其视为默认字符集。 除非你覆盖它（例如通过在命令行上为java编译器提供选项），否则Java编译器将使用它作为源文件字符集。 但是，这可能不是源文件的正确字符编码; 例如，如果您在具有不同默认字符集的其他计算机上创建它们。 如果java编译器使用错误的字符集来解码源文件，则可能会将错误的字符代码放入“.class”文件中。

“.class”文件不依赖于平台。 但是如果它们被错误地创建，因为您没有告诉Java编译器源文件的正确编码，那么“.class”文件将包含错误的字符。

---

你的意思是：“单个文件的”默认字符集“的概念是没有意义的”？

我说是因为它是真的！

默认字符集表示未指定字符集时使用的字符集。

但我们可以控制我们希望如何存储文本文件吗？ 即使使用记事本，也可以选择编码。

那是对的。 那就是你告诉记事本用于文件的字符集。 如果你没有告诉它，记事本将使用默认字符集来写入文件。

^{在GUESS的记事本中有一点黑魔法，它在读取文本文件时是什么字符编码。 基本上，它会查看文件的前几个字节，以查看它是否以UTF-16字节顺序标记开头。 如果它看到一个，它可以启发式地区分UTF-16，UTF-8（由Microscoft产品生成）和“其他”。 但它无法区分不同的“其他”字符编码，并且它不会将UTF-8识别为不以BOM标记开头的文件。 （UTF-8文件上的BOM是特定于Microsoft的约定...如果Java应用程序读取文件并且不知道跳过BOM字符，则会导致问题。）}

无论如何，问题不在于写入源文件。 它们发生在Java编译器使用不正确的字符编码读取源文件时。

Answer 3

你正在处理一个糟糕的假设。 getBytes()方法不使用UTF-16编码。 它使用平台默认编码。

您可以使用java.nio.charset.Charset.defaultCharset()方法进行查询。 在我的情况下，它是UTF-8，对你也应该是一样的。

Answer 4

如果未找到特定于平台的编码，则默认为UTF-8或ISO-8859-1 。 不是UTF-16 。 所以最终你只在UTF-8中进行字节转换。 这就是你的byte[]匹配你可以找到默认编码的原因

 System.out.println(Charset.defaultCharset().name());