二进制解码指南：分组错了，结果一定错

二进制解码几乎不会「部分正确」：只要少一位、错一位或混进一个别的字符，后面的分组就整体偏移，结果会面目全非。

典型用途：把示例读回人话

教材、协议文档、面试题里经常直接给一串 01001000 01101001，让你说出它是什么。手工换算又慢又容易错，粘进来就能看到原文。位域说明、老系统的转储、课堂演示也常这样用。

还有一种情况是自己写位运算时的草稿：把中间结果展开成二进制，再解回字符，确认移位方向没搞反。它不能替代调试器，但能在一分钟内验证一个猜测，省下反复改代码的时间。

第一，必须八位一组。工具按空白切分，每组读成一个字节；写成七位、九位或中间断开，都会得到错误的值。第二，前导零要保留，01000001 和 1000001 对解析器来说不是同一个输入。

第三，只能出现 0 和 1。混入字母、逗号或全角字符时，这一组会被读成无效值，最终体现为 0 字节或乱码。遇到结果完全不对，先检查是不是从网页复制时带进了不间断空格或零宽字符。

工具只做 UTF-8 解码。如果原始字节是 GBK、UTF-16 或者压缩数据，结果会是 � 和怪字符，这不是解码错误，而是「这些字节本来就不表示 UTF-8 文本」。先确认来源，再选工具。

二进制也不是加密，任何人按八位一组读回即可还原，所以别用它藏密码。它还很占空间，是十六进制的四倍；真正需要记录字节时，用十六进制或 Base64 更实际，把它当编码方式看待就不会误用。

少一位会怎么样？

从缺少的那一位开始，后面所有分组都会错位，读出来的字节和原文完全无关。工具不会提示「位数不对」，所以粘进来之前先确认总位数能被 8 整除。

为什么解出来是乱码？

多数情况是原始数据不是 UTF-8 文本，或者分组时混入了非 0/1 字符。先检查字符集是否只有 0 和 1、每组是否 8 位，再确认来源编码，不要反复解码。

能解二进制文件吗？

不能。这里处理的是文本的字节展开，图片、压缩包、可执行文件需要专门的十六进制查看器或解析工具，而且必须先按文件格式解释字节，而不是当作文本。