Question

字节顺序掩码（BOM）使用Unicode字符U + FEFF根据以下规则确定文本文件的编码：

+-------------+-----------------------+
|    Bytes    |     Encoding Form     |
+-------------+-----------------------+
| 00 00 FE FF | UTF-32, big-endian    |
| FF FE 00 00 | UTF-32, little-endian |
| FE FF       | UTF-16, big-endian    |
| FF FE       | UTF-16, little-endian |
| EF BB BF    | UTF-8                 |
+-------------+-----------------------+

我的问题是：是否有任何字节组合可以使一个UTF编码与另一个UTF编码混淆？

例如，如果我有一个没有BOM的UTF-16大端编码文件，并且字符为U + EFBB和U + BF40（EF BB BF 40），则可能会与带有BOM的UTF-8编码文件混淆和ASCII字符@？

Answer 1

当然，在不知道编码的情况下，一系列U + 0000字符的长度未知。

00 00 00 00  UTF-8   U+0000 U+0000 U+0000 U+0000     
00 00 00 00  UTF-16  U+0000 U+0000 
00 00 00 00  UTF-32  U+0000

看起来像字节顺序标记的BTW字节不能用于确定文本文件的编码。一般来说，这是一个无法解决的问题 - 数据丢失。

Answer 2

BOM旨在查找大小已知的字节顺序。所以没有U+FFFE代码。 charset没有进一步的限制，因此可能存在一些重叠的代码。（@TomBlodget有一个＆＃34;退化＆＃34;案例的例子）

不需要UTF-8中的BOM，但应该保留它，以便从其他unicode编码进行完美的循环转换。只是Windows开始使用它来区分UTF-8与其他编码（特别是在unicode编码之外），并且它不是100％可靠。

C0和C1是UTF-8上不允许的字节，沿着各种序列（字节1上的第一位定义了序列的长度，因此＆＃应该有这么多字节） 34;继续前缀＆＃34;（0b10）。所以通常很容易找到一个字符串是UTF-8（如果不是太短或＆＃34;退化＆＃34;）。

UTF-32只有0到U+10FFFF的有效值，所以这可以用来区分它与UTF16（再次，＆＃34;退化＆＃34;短字符串不可辨别，OTOH，我们应该经常在UTF32中00 00，在UTF16 正常文本上通常没有00 00，但最后是ev。）。

控制字符和私人字符集不应用于＆＃34; public＆＃34; Unicode文本（但如果您同意协议，但不应该是问题的情况）。

字节顺序掩码：混淆UTF编码

2 个答案: