问哪个多字节字符集以0x7F开头，长度为4个字节？

EN

我正在尝试使用的

One字符编码以0x7F开头，长度为4个字节

其他字节是什么？这个编码中有没有拉丁文本？

如果是“0x7f 0x...0x00 0x00“您正在查看UTF-32LE。它也可以是两个UTF-16 ( LE或BE)字符。

大多数东亚编码使用0x80-0xFF作为非ASCII字符的前导字节；据我所知，除了ASCII删除之外，没有任何其他编码会使用前导0x7F作为前导字节。

预计到达时间：

是否应该有字节顺序标记？

如果有一种带外的方式来通知编码是‘UTF-32LE’(可能在它到达之前就丢失了)，那么就不需要有BOM。

我还不得不使用一些日语编码，每个字符都以0xE3开头，长度为3个字节。

这肯定是UTF-8。序列0xE3 0x...0x...将导致U+3000和U+4000之间的字符，这是平假名/片假名居住的地方。

如果我在视窗中选择日语区域设置，它会在我的电脑上正常显示，但是，它不能在我们的应用程序中正确显示。

那么很有可能你的应用程序是一群令人遗憾的不符合Unicode的应用程序之一，它仍然在‘W’后缀的应用程序中使用‘A’(*)版本的Win32接口。你是否能根据字符串的真实编码来读入它还是个未知数:一个不兼容Unicode的应用程序永远不能在西方语言环境中显示东亚表意文字。

(*：以“ANSI”命名，这是Windows对“无论当前系统代码页设置为什么”的误导性术语。这就是更改语言环境会影响它的原因。)

ETA(2)：

好了，破解了。这不是我以前遇到过的任何标准化编码，但如果假设Unicode代码点是编码的，那么破解它就相对容易了。

0x00-0x7E: plain ASCII
0x7F A B C: Unicode character

Unicode转义中编码的字符可以通过获取A、B和C键字符串中的索引并将其相加来计算：

A*0x1000 + B*0x40 + C

也就是说，它是一个64位字符集，但不是通常的Base64标准。一个简单的实验给出了一个关键字符串：

.0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz

“.”和‘_’字符是猜测，因为你张贴的字符都没有使用它们。我们需要更多的数据来找出确切的字符串。

所以，举个例子：

0x7F 3 u g
A=4 B=58 C=44
4*0x1000 + 58*0x40 + 44 = 0x4EAC
U+4EAC = 京

ETA(3)：

是的，通过手动提取每个代码点并将其连接为一个字符来创建原生Unicode字符串应该很容易。不太确定您正在使用的平台上有什么可用，但任何支持Unicode的平台都应该能够简单地从代码点生成字符串(希望不必手动重新编码为UTF-16LE字节)。

我注意到这三个示例字符的第一个转义字符位于相同的通用范围内，并且与其Unicode代码点具有相同的数字顺序，因此我认为它一定是Unicode代码点。另外两个字符似乎是随机变化的，所以它很可能是代码点的高位优先编码，而base-64编码可能是可读的ASCII之外的最多位。

标准Base64本身以字母开头，这会使以数字开头的内容在基本的多语言平面中太高。所以我开始猜测“0123456789ABCDEFG...”这将是密钥串的另一个明显的选择。这样得到的结果数字接近给定字符的代码点，但有点太低。在键字符串的开头插入一个额外的字符(因此数字‘0’不会映射到数字0)会使其中一个字符正确，而另外两个字符非常接近；右边的那个没有小写字母，所以为了只更改小写字母，我在大小写之间插入了另一个字符。这得出了正确的数字。

不能保证这确实是正确的，但(除了随意选择插入的字符之外)很可能是正确的。

你可能想看看维基百科上的chinese character encoding页面。我能看到的唯一一个总是4字节的编码就是UTF-32。

GB 18030是当前的标准中文字符集，但长度可以是1到4个字节。

试试chardet。它在猜测字节串的字符编码方面做得很好。

Unicode和

-8是一样的吗？

不是的。UTF-8只是将Unicode字符表示为字节序列的一种方式。Unicode是完整的标准，它为每个字符分配数字和人类可读的标识符，以及大量关于字符的元数据。