为什么二进制转文字总是转出错误的字符

一串0和1看起来毫无歧义——这就是二进制，没什么好解读的。但实际上，二进制转文字出错的方式跟十六进制转文字几乎一模一样，根本原因也相同：一串比特要经过好几层假设才能变成文字，只要其中任何一个假设错了，输出就会以某种特定的、可以诊断出来的方式出错。

原因一：比特分组方式错了（7位 vs 8位）

标准ASCII每个字符只需要7位，但大多数二进制转文字工具默认按8位一个字节处理，因为文字在真实系统里就是这么存的。如果一串二进制数据本来是按7位分组生成的（一些教科书例子和老系统至今还这么干），你却按8位字节去解码，每一个字符都会整体错位——分组边界从第一个比特起就是错的，所以乱码是均匀分布在整段输出里的，而不是先正常、后面才开始乱。

判断标志：如果输出里每一个字符都是错的，不是只有一部分，先检查比特分组方式，别的先放一边。

原因二：多了或少了一个比特，导致后面全部错位

这是二进制版的“奇数个十六进制字符”问题——多了或少了一个孤立的0或1（复制粘贴时多出来的字符、掉了一位、被误当成数据解析的空白符），会让出错点之后每一组的字节边界都往后错位。跟原因一不同，这种情况产生的文字是前面正常、后面开始乱——这是个很强的信号，说明问题出在字符串某处的比特数量不对，而不是整套编码方案从头到尾都错了。

先数一下总比特数：字符串长度应该是8（或者7，如果你已经确认用的是这种分组）的整数倍。如果不是，那多出来或少掉的那个比特才是bug，不是解码器的问题。

原因三：字符编码问题，跟十六进制的情况一样

比特正确分组成字节之后，你还得决定这些字节值作为字符具体代表什么——UTF-8、ASCII、Latin-1。这跟十六进制转文字的情况完全一样：多字节的UTF-8字符（带音调的字母、符号、非拉丁文字）如果被一个字节一个字节地当成独立字符解码，会变成两三个乱码符号，而不是一个正确的字符。如果比特分组已经确认没问题（排除了原因一和二），但输出偏偏在非ASCII字符附近出错，几乎可以肯定就是这个原因。

原因四：字节序问题，针对代表数值而非文字的二进制数据

如果这串二进制代表的是一个数值而不是字符数据——比如长度前缀、校验和、跟文字一起嵌入的ID——比特/字节的顺序就很关键，而且没有一个放之四海皆准的默认值。单独的00000001这一个字节没有歧义，但多字节的数值可以按“最高有效字节在前”或者“最低有效字节在前”存储，取决于产生它的是什么系统，用错了假设去读，不会报出明显的错误，而是悄悄给出一个看起来合理但实际错误的数字。

按顺序排查

先检查总比特数是不是你所假设的分组方式（通常是8）的整数倍——数量不对就是原因二，先修输入。
如果每一个字符从一开始就均匀地出错，先怀疑分组大小本身（原因一），别急着动编码方式。
如果输出一开始正常、中途才开始变乱，说明问题精确定位在那个位置的多余/缺失比特（原因二），不是编码问题。
如果分组和比特数都确认没问题，只有非ASCII字符看起来不对，那就是字符编码问题（原因三）。
如果这串数据代表的是数值而不是文字，数值看起来合理但就是不对，先查字节序（原因四），别急着怀疑转换逻辑本身坏了。

跟十六进制一样，转换这一步本身很简单——真正的bug几乎总是藏在这四个假设里的某一个，而不是在做转换的代码里。