文本转二进制

关于 文本转二进制

学习字符编码、调试串口数据、做编程教学演示时，常需要把文字拆成一串 0 和 1。本工具在浏览器本地把文本与二进制位串双向转换，严格基于 UTF-8 编码处理每个字符的字节：一个常见汉字占 3 字节（24 位），emoji 通常占 4 字节（32 位），绝不是一个字固定一个字节。转换结果默认按每 8 位（一个字节）用空格分组，便于人眼比对；还原时自动忽略空格，带不带分组都能正确解析。最容易踩的坑是位数不对齐：还原时需要位串总长度是 8 的倍数，如果从某处复制来的位串被截断一位，就会因为无法对齐字节而报错。全部计算在本机完成，输入内容不会发送到任何服务器，可放心粘贴隐私文本。按字节分组查看能直观看到汉字占三字节、表情符号占四字节，无论是课堂演示计算机如何存储文字、查看某个字符的真实 UTF-8 字节，还是把抓到的位串还原成设备报文，都能即时完成。

误用集中在编码约定上：同一个汉字在 UTF-8 下是三字节、在 GBK 下是两字节，二进制串的长度与内容因此完全不同，编码时与解码时必须使用同一字符集。另一个误用是忽视分隔约定——连续的位串没有分隔符就无从切分，因此要么按固定宽度分组，要么以空格分隔，双方约定不一致时会得到完全错误的还原结果。

用途上要区分「展示」与「传输」：把文本写成二进制便于教学演示与逐位核对，但作为传输编码它非常低效——每个字节要用八位字符表示，体积是原文本的八倍，而十六进制是两倍、Base64 约为一点三三倍。因此实际传输应选择后两者，二进制位串只在需要逐位观察、或与硬件与协议文档逐位对照时才有优势。

若目的只是让人看懂位模式，建议同时给出十六进制形式：位串适合逐位对照，十六进制四位一组更紧凑，两者并排时既便于观察也不至于让版面过长。反过来，若目的是给程序解析，应直接使用字节数组或十六进制字符串，位串需要额外的解析步骤且容易在分组长度的约定上出错。

最后一个前提是可读性成本：二进制位串很长，人工核对时极易把 0 与 1 看错，尤其是连续重复的位。因此核对这类内容应改用分组显示并辅以十六进制对照，或者干脆用校验和确认整段是否一致，而不是逐位比对。把「人工逐位核对」换成「用摘要比对整段」，是这类数据上更可靠的验证方式。

两个方向必须配对使用，这一点比想象中更严格。编码时的分组方式与解码时的不一致，结果就会完全不同：同一串位，按八位一组与按四位一组解读，得到的是两套毫无关系的字符。因此自建流程时应当把编码约定写进文档，并在接收端用一组已知输入做冒烟测试，确认解码器与编码器的约定一致。

作为一种「表示法」，它和十六进制、转义序列解决的是同一类问题——把字节写成可读字符，区别只在紧凑程度与直观程度。选择依据不是哪个更高级，而是哪个更适合当前用途：需要逐位观察用位串，需要紧凑传输用十六进制或编码格式，需要在文本里内嵌二进制用转义或编码。把三者的适用面分清，就不会在传输场景里误用最冗长的那种。

在教学与文档场景里，位串有个不易替代的优势：它能让读者直接看到某个标志位或掩码的作用。协议文档里写「第三位表示某某」，配上位串比配上十六进制更容易对应。因此即使传输上不推荐，作为说明工具它仍然有存在价值，关键是明确它服务于「看懂」而不是「传递」。

处理长文本时要意识到体积会迅速膨胀：每个字节变成八个字符，一段一万个字符的文本会变成八万字符的输出，粘贴与比对都会变得笨重。若只是为了核对，建议只取首尾若干字节；若确实需要完整转换，应导出为文件而不是留在页面上，否则复制过程本身就容易出错。

最后一点与验证方式有关：人工逐位核对位串几乎必然出错，连续重复的零与一尤其难分辨。更可靠的验证是把整段数据的摘要算出来做比对，或先用十六进制确认内容一致再转成位串。把「人眼比对」换成「摘要比对」，是这类数据上最值得养成的一个习惯。