什么多字节字符集以0x7F开头并且长度为4个字节？

我正在尝试使用一些遗留代码来正确显示中文字符.我尝试使用的一个字符编码以0x7F开头,长度为4个字节(包括0x7F字节).有谁知道这是什么样的编码以及我可以在哪里找到它的信息？谢谢..

更新:我还必须使用一些日语编码,它以0xE3开始每个字符并且长度为3个字节.如果我在Windows中选择日语语言环境,它会在我的计算机上正确显示,但是它在我们的应用程序中无法正确显示.但是,如果选择了除日语之外的任何其他语言环境,我甚至无法正确查看文件名.所以我猜这个编码不是Unicode.有人知道这是什么吗？是ANSI吗？它是Shift JIS吗？

对于中文版,我用Unicode和UTF-8字符进行了测试,我得到了相同的模式; 0x7F后跟三个字节.Unicode和UTF-8是一样的吗？

我正在尝试使用的一个字符编码以0x7F开头,长度为4个字节

其他字节是什么？你有这个编码的拉丁文吗？

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

大多数东亚编码使用0x80-0xFF作为非ASCII字符的前导字节; 没有我知道的将使用前导0x7F作为ASCII删除以外的任何东西.

ETA:

应该有Byte Order Marks吗？

如果有一种带外方式的信号表明编码是'UTF-32LE'(可能是在它到达之前丢失的那个),则不需要BOM.

我还必须使用一些日语编码,它以0xE3开始每个字符并且长度为3个字节.

这肯定是UTF-8.序列0xE3 0x ... 0x ...将导致U + 3000和U + 4000之间的字符,这是平假名/片假名所在的位置.

如果我在Windows中选择日语语言环境,它会在我的计算机上正确显示,但是它在我们的应用程序中无法正确显示.

那么很可能你的应用程序是令人遗憾的非Unicode兼容应用程序之一,仍然使用'W'后缀内的'A'(*)版本的Win32接口.您是否可以根据其实际编码读取字符串是没有意义的:不符合Unicode的应用程序永远无法在西方语言环境中显示东亚表意文字.

(*:以"ANSI"命名,这是Windows对"目前无论系统代码页设置如何"的误导性术语.这就是为什么更改您的语言环境会影响它.)

ETA(2):

好的,破解了.它不是我之前遇到过的任何标准化编码,但如果你假设Unicode代码点被编码的前提,则解密起来相对容易.

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

可以通过将索引放在A,B和C的键字符串中并将它们相加来计算Unicode转义中编码的字符:

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代码点具有相同的数字顺序.其他两个字符似乎随机变化,因此它很可能是代码点的大端编码,并且可能是6位的base-64编码与您可以从可读ASCII中获得的位数一样多.

标准Base64本身以字母开头,这些字母会以一个数字开头,这个数字太多,不能在Basic Multilingual Plane中.所以我开始猜测'0123456789ABCDEFG ...'这将是键字符串的另一个显而易见的选择.这得到的数字接近给定字符的代码点,但有点太低了.在键字符串的开头插入一个额外的字符(因此数字'0'不映射到数字0)得到一个字符正确,另外两个字符非常接近; 正确的那个没有小写字母,所以只改变小写字母我在大写和小写之间插入了另一个字符.这提出了正确的数字.

它不能保证这实际上是正确的,但(除了任意选择插入的字符)它很可能是它.