c - 在UTF-16、UTF-16BE、UTF-16LE中，UTF-16的字节序是计算机的字节顺序吗？

Question

UTF-16 是一种双字节字符编码。交换两个字节的地址将产生 UTF-16BE 和 UTF-16LE。

但我发现在 Ubuntu gedit 文本编辑器中存在名称 UTF-16 编码，以及 UTF-16BE 和 UTF-16LE。用C测试程序发现我的电脑是little endian，UTF-16被确认为与UTF-16LE相同的编码。

另外:在小端/大端计算机中，一个值(例如整数)有两种字节顺序。小端计算机将在硬件中产生小端值(Java 产生的值除外，它始终形成大端)。

虽然文本在我的小端计算机中可以保存为 UTF-16LE 以及 UTF-16BE，但字符是一个字节一个字节生成的(例如 ASCII 字符串，引用 [3] 和 UTF- 的字节顺序) 16 只是由人类定义的 -- 不是大端机器写入大端 UTF-16 而小端机器写入小端 UTF-16 的现象的结果吗？

1. http://www.ibm.com/developerworks/aix/library/au-endianc/
2. http://teaching.idallen.com/cst8281/10w/notes/110_byte_order_endian.html
3. ASCII strings and endianness
4. Is it true that endianness only affects the memory layout of numbers,but not string?这是一篇关于字符串字节顺序和机器之间关系的文章。

Answer 1

“UTF-16 的字节序是计算机的字节顺序吗？”

可以从文件的写入者或读取者的角度来看计算机字节顺序的影响。

如果您正在读取标准格式的文件，那么读取它的机器类型无关紧要。格式应该足够明确，无论阅读机的字节顺序如何，数据仍然可以正确读取。

这并不意味着格式不灵活。使用“UTF-16”(当格式名称中未使用“BE”或“LE”消歧时)定义允许将文件标记为大端或小端。这是通过文件前两个字节中称为“字节顺序标记”(BOM) 的东西完成的:

https://en.wikipedia.org/wiki/Byte_order_mark

BOM 的存在为文件的编写者提供了选择。他们可能会选择为内存中的缓冲区写出最自然的字节顺序，并包含匹配的 BOM。对于其他一些读者来说，这不一定是最有效的格式。但是任何声称支持 UTF-16 的程序都应该能够以任何一种方式处理它。

所以是的——计算机的字节顺序可能会影响 BOM 标记的 UTF-16 文件的字节顺序选择。仍然......一个小端程序完全能够保存文件，将其标记为“UTF-16”并使其成为大端。只要BOM与数据一致，用什么样的机器写入或读取都无所谓。

...如果没有 BOM 怎么办？

这是事情变得有点模糊的地方。

一方面，Unicode RFC 2781和 Unicode FAQ 很清楚。他们说一个既不以0xFF 0xFE 也不以0xFE 0xFF 开头的“UTF-16”格式的文件是interpreted as big endian。 :

the unmarked form uses big-endian byte serialization by default, but may include a byte order mark at the beginning to indicate the actual byte serialization used.

但要知道您是否有 UTF-16-LE、UTF-16-BE 或没有 BOM 的 UTF-16 文件……您需要文件外部的元数据来告诉您它是三者中的哪一个。因为并不总是有地方放置这些数据，所以一些程序最终使用启发式方法。

考虑像 this from Raymond Chen (2007) 这样的东西:

You might decide that programs that generate UTF-16 files without a BOM are broken, but that doesn't mean that they don't exist. For example,

cmd /u /c dir >results.txt

This generates a UTF-16LE file without a BOM.

这是一个有效的 UTF-16LE 文件，但是“UTF-16LE”元标签存储在哪里？有人仅通过称其为 UTF-16 文件而忽略它的可能性有多大？

根据经验，有关于该术语的警告。维基百科 page for UTF-16说:

If the BOM is missing, RFC 2781 says that big-endian encoding should be assumed. (In practice, due to Windows using little-endian order by default, many applications similarly assume little-endian encoding by default.)

和unicode.readthedocs.org说:

"UTF-16" and "UTF-32" encoding names are imprecise: depending of the context, format or protocol, it means UTF-16 and UTF-32 with BOM markers, or UTF-16 and UTF-32 in the host endian without BOM. On Windows, "UTF-16" usually means UTF-16-LE.

此外，Byte-Order-Mark Wikipedia article说:

Clause D98 of conformance (section 3.10) of the Unicode standard states, "The UTF-16 encoding scheme may or may not begin with a BOM. However, when there is no BOM, and in the absence of a higher-level protocol, the byte order of the UTF-16 encoding scheme is big-endian."

Whether or not a higher-level protocol is in force is open to interpretation. Files local to a computer for which the native byte ordering is little-endian, for example, might be argued to be encoded as UTF-16LE implicitly. Therefore, the presumption of big-endian is widely ignored.

When those same files are accessible on the Internet, on the other hand, no such presumption can be made. Searching for 16-bit characters in the ASCII range or just the space character (U+0020) is a method of determining the UTF-16 byte order.

因此，尽管标准没有歧义，但上下文在实践中可能很重要。

正如@rici 指出的那样，该标准已经存在一段时间了。尽管如此，对声称为“UTF-16”的文件进行复查还是值得的。或者甚至考虑是否要避免很多这些问题并采用 UTF-8...

"Should UTF-16 be considered harmful?"