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

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 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  

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

Answer 2

BOM的设计是为了在已知大小时找到字节顺序。所以没有U+FFFE代码。字符集没有进一步的限制，因此可能存在一些重叠代码。(@TomBlodget有一个“退化”案例)

UTF-8中的BOM并不是真正需要的，但是应该保留它，以便完成与其他unicode编码的完美循环转换。仅仅Windows就开始使用它来区分UTF-8和其他编码(特别是unicode编码之外的编码)，而且它不是100%可靠的。

C0和C1是UTF-8上不允许的字节，包括不同的序列(字节1上的第一个位定义了序列的长度，所以应该有那么多带有“延续前缀”(0b10)的字节。因此，通常很容易找到一个字符串，它是UTF-8 (如果不是太短或“退化”)。

UTF-32只有从0到U+10FFFF的有效值，所以这可以用来区分它与UTF16 (同样，“退化”和短字符串是不可区分的，OTOH我们应该经常在UTF32中期望00 00，通常在UTF16普通文本上没有00 00，但是ev。最后。)。

控制字符和私有字符集不应用于“公共”Unicode文本(但如果您同意协议，但这不应该是问题的情况)。