空白字符可视化：把空格、Tab、换行都看出来

代码里最难查的 bug，往往是你根本看不见的那个字符。一行 Python 看着和上一行一模一样，运行起来却抛 IndentationError。一个配置键肉眼对得上，查找却怎么都失败。一段从聊天窗口复制来的代码，粘进编辑器后某个数字就是解析不出来。这些情况的共同点，是问题藏在空白字符里：空格、Tab、换行，还有那些长得像空格却不是空格的隐形字符。

把这些字符显示成可见符号，问题就一下子摊开了。我用空白字符可视化把文本粘进去，它会把每一类空白画成不同的淡色标记，谁是谁一眼就分得清。

每一类空白用什么符号标出来

工具的做法是给每种空白字符一个专属符号，互不混淆：

空格显示成中点「·」，四个行首空格就是「····」。
Tab 显示成箭头「→」，一个 Tab 缩进就是行首一个「→」。
换行在真正断行之前显示段落符「¶」，你能看清每行到底在哪结束。
不间断空格(U+00A0)有自己的标记「⍽」，它看着和普通空格一样，却是另一个字符。

这样设计的意义在于：宽度相同的缩进，符号不同。Tab 和四个空格在大多数编辑器里看起来一样宽，但在这里一个是箭头、一个是四个中点，真相藏不住。

Tab 和空格混用：报错的经典来源

Python 对缩进极其挑剔。同一个缩进层级里，有的行用 Tab、有的行用空格，解释器就会抛 TabError 或 IndentationError，而你盯着屏幕看半天也找不出哪行不对，因为它们看着一样宽。

举个真实例子。下面这段函数，第二行用了一个 Tab 缩进，第三行用了四个空格缩进：

def total(items):
	count = 0
    for x in items:
        count += x
    return count

粘进可视化工具后，缩进列长这样：

def·total(items):¶
→count·=·0¶
····for·x·in·items:¶
········count·+=·x¶
····return·count¶

第二行以「→」开头，下面几行以「····」开头，混进 Tab 的那行立刻跳出来。计数面板还会在一行用 Tab、另一行用空格缩进时直接给出混用警告，所以你还没逐行看，就已经知道问题出在哪一类缩进上了。Makefile 也是同一个坑：配方行前面必须是真正的 Tab，如果显示成中点而不是箭头，那个 missing separator 报错就有了解释。

行尾空白：看不见却污染 diff

行末尾的空格和 Tab 同样隐形，却会带来实打实的麻烦。它们会污染 git diff，明明只是动了一个看不见的空格，整行却显示成被改过；它们会破坏把行尾空白当作有意义的 YAML 和 Markdown；shell 的 here-doc 也会因此出错。工具会把每一行末尾带空白的行高亮出来，再提供一键复制去掉全部行尾空白的版本，这是提交前的标准清理动作。需要对整份文件做更彻底的清理时，可以接着用文本清理工具一并处理多余空行和首尾空白。

复制粘贴塞进来的隐形字符

不间断空格是这里最阴险的一个。它是 U+00A0，看上去和普通空格一模一样，可 Word、网页、聊天软件复制时常常悄悄把它塞进文本。结果字符串比较失败，像 1 000 这样的数字解析不出来，按普通空格切分时又偏偏漏掉它。按普通空格做修剪也清不掉它，因为它压根不是那个字符。工具用专门的「⍽」把每个不间断空格标出来并计数，一个看着没问题却行为出错的值，差异立刻显形。

我自己印象最深的一次，是一个怎么都对不上的配置键。两个字符串并排放，肉眼完全一致，查找却始终返回空。把它们都粘进可视化工具，其中一个键的中间多了一个「⍽」，是从一份在线文档里复制时带进来的。换成普通空格，问题当场消失。那一刻我才真正明白，看不见不等于不存在。

几个使用提醒

带标记的预览是视觉辅助，满屏中点和箭头，不是可用的文本，别直接复制回代码里。要拿到干净输出，用「已去掉行尾空白」的复制按钮。所有处理都在浏览器本地完成，文本不离开页面，也不上传。把文本粘进去，扫一眼第一个符号，缩进、行尾、隐形字符的真相就都在眼前了。

Made by Toolora · Updated 2026-06-13