有一类 bug 特别折磨人，因为它看不见：两段”一模一样”的字符串比较却不相等；CSV 导进数据库平白多出一列；在 Windows 写好的脚本传到服务器一跑就 bad interpreter；Git 的 diff 整片飘红，肉眼却找不出改了哪。这些几乎都是肉眼不可见的控制字符在搞鬼。这篇带你认识这些隐形字符，并用 ASCII 码表把它们一个个揪出来。
这些看不见的字符从哪来
文本不只有字母数字标点，还藏着大量不显示字形的字符：行尾的换行、缩进的 Tab、字符串结尾的 NUL、文件开头的 BOM……它们大多是早期电传打字机时代留下的控制码，用来指挥设备动作而非显示内容。平时它们安分守己，但一旦跨平台、跨编码传递，就成了灵异 bug 的源头。识别它们的统一方法只有一个：看字符的实际码值。
坑一：CRLF 与 LF，换行符不统一
换行这件小事，不同系统用了不同字节：
| 名称 | 字节 | 转义 | 系统 |
|---|---|---|---|
| LF | 10 (0x0A) | \n | Unix / macOS / Linux |
| CR | 13 (0x0D) | \r | 老 Mac（已淘汰） |
| CRLF | 13 + 10 | \r\n | Windows |
后果都很经典：
- Windows 写的 shell 脚本带 CRLF，传到 Linux 执行，多出来的
\r被当成命令一部分 →bad interpreter: /bin/bash^M - 两端换行不一致 → Git 刷出大量无意义 diff 和
LF will be replaced by CRLF警告 - 字符串按
\n切分时，残留的\r留在了每行末尾，导致比较不相等
修复：编辑器统一设 LF，Git 用 .gitattributes 配 * text eol=lf，从源头消除混用。
坑二：Tab 与空格，缩进的隐形战争
Tab（ASCII 9）和空格（ASCII 32）是两个完全不同的字符，但在编辑器里都是”一段空白”，肉眼难辨：
- Python 对缩进敏感，Tab 和空格混用直接
TabError - Makefile 要求命令行必须用 Tab 缩进，用空格会报错
- 代码 review 时一片”看不出区别”的缩进改动，其实是 Tab↔空格的转换
发现办法：开编辑器”显示空白字符”，或把缩进字符逐个对照 ASCII 码——是 9 就是 Tab、是 32 就是空格。团队统一风格 + .editorconfig 是根治方案。
坑三：BOM 与其它幽灵字符
还有一批更隐蔽的：
- BOM：某些编辑器在 UTF-8 文件开头加的
EF BB BF三字节，会让 PHP 在header()前输出内容、JSON 解析失败、CSV 第一个字段名前带乱码、脚本 shebang 失效。保存时选”UTF-8 无 BOM”。 - 尾随空格 / 行尾 \r：让字符串比较失败、Markdown 渲染出意外的换行
- NUL（0）：C 字符串结束符，混进文本会截断内容
- 零宽字符 / 全角空格：冒充普通空格，是”看着一样却不等”的常客
虽然 BOM 和零宽字符属于 Unicode 而非纯 ASCII，但排查思路一致：看头几个字节、看每个空白的真实码值。
怎么把它们揪出来
定位不可见字符的通用流程：
- 先怀疑——遇到”灵异不相等""莫名多字段""换台机器就报错”，第一反应查隐藏字符
- 看字节——用 hex 模式、
cat -A（行尾显示$、Tab 显示^I）、或能显示编码的工具，看出实际字节 - 对照 ASCII 码表反查——把看到的码值（13、9、0…）丢进查码框确认身份，或正向查某个字符的 DEC/HEX 确认”这空白是不是标准空格”
- 统一并固化——换行统一 LF、编码选无 BOM、缩进二选一，再用
.editorconfig/.gitattributes让规则自动生效
小结
文本处理里最难缠的 bug 往往不在你能看见的字符，而在看不见的控制字符：CRLF 让跨平台脚本崩、Tab 与空格让缩进战争开打、BOM 在文件开头埋雷。掌握”一切回归码值”的思路，用 ASCII 码表把可疑字节正查反查确认身份，再从编辑器和项目配置层面统一换行与编码，这类灵异问题就再也藏不住了。