中文排版规范化工具漏改的那个冒号，问题出在它只看紧挨着的那一个字

摘要：想知道一款排版工具的脾气，最快的办法不是读它的说明，是点开它自带的那个示例按钮。我点完发现，示例文案第一行的逗号被换成了全角，最后一行同样位置的冒号却原样留着——差别不在标点本身，在紧挨着它的下一个字是中文还是英文。

这篇把这条边界、以及它衍生出的一串连锁反应逐条量了出来：哪些符号在什么条件下会动、哪些永远不会动、为什么统计面板说改了300处而明细只列200条。顺带说明，写这篇的过程中我修掉了它的四处实现缺陷，文中标注了改前改后的对照。

中文稿子里那些半角逗号、直角引号、三个点的省略号，单看每一处都是小毛病，攒够一整篇就变成另一回事了。尤其是多人协作的稿件，有人用输入法默认的全角，有人从英文文档里粘过来一段带半角标点的，还有人习惯敲两个连字符当破折号。等到要统一发布的时候，人工一个个找纯属折磨。

保哥自己写稿也天天碰这事，所以做了这款中文排版规范化工具。但工具做出来是一回事，它到底在什么条件下动手、什么条件下装作没看见，是另一回事。这篇就是把这条线量清楚。

为什么第一件事是点那个示例按钮？

写工具评测有个偷懒但极其有效的办法：别急着自己造用例，先点作者自己放上去的那个示例。

道理很简单。示例是作者亲手挑的，代表他认为最能展示这款工具的场景，也代表他认为这些场景是能正常跑通的。如果连自带示例都露出破绽，那这个破绽一定是真的，而且没法用"你这用例太刁钻"来解释。

示例文案里塞了些什么

这款工具的示例按钮会往输入框里填一段六行的文本，密度相当高，几乎每行都在测一类规则：

• 第一行：半角逗号、半角句号，中英文混排（工具集,现在一共有106款工具.）
• 第二行：三个点的省略号、直角引号「」与『』、两个连字符的破折号
• 第三行：一个网址、一个邮箱地址
• 第四行：反引号包起来的行内代码
• 第五行：半角冒号、半角括号包着中文

能看出作者的意图：前两行演示"该改的都改了"，后三行演示"该保护的都保护住了"。这段示例的信息密度其实相当高，六行文本覆盖了八条规则里的六条，作为演示素材是合格的。

顺便说一句，把示例按钮当对照组这个办法，我拆别的工具时也一直在用，命中率高得出奇。原因不玄乎：外人构造的用例总带着"我想找茬"的痕迹，容易被一句"你这输入太极端"挡回去；而作者自己放的演示素材，是他默认不会出错的地方，一旦在那里翻车，性质完全不同。

跑完之后，账不是这么算的

我点了示例再点规范化，输出里有几处和预期对不上。最扎眼的是这两行的对比：

同样是半角标点，同样紧跟在中文后面，一个转了一个没转。这不是随机的，也不是漏了——是规则本身就长这样。

同一个冒号，凭什么有的转有的不转？

把标点转全角这条规则拆开看，它要求的不是"前面是中文"这一个条件，而是三个条件同时成立。

规则的真实形状

它匹配的是这样一个模式：前面紧挨着一个中日韩汉字，中间是那个半角标点，标点后面还必须是空白、行尾、或者另一个中日韩汉字。三者缺一不可。半角逗号、句号、感叹号、问号、冒号、分号这六个符号，走的都是同一条规则。

所以"参数说明:width"这处，冒号前面确实是中文的"明"字，但后面跟的是英文字母w，第三个条件不成立，规则直接放行。而"工具集,现在"这处，逗号后面是"现"字，三个条件齐了，转。

四组对照实测

我构造了四组只差一个字的输入，跑出来的结果把这条边界描得很清楚：

规律非常干净：标点后面跟英文，就一律不动。

受这条规则管的一共六个符号：逗号、句号、感叹号、问号、冒号、分号。六个走的是同一套判据，所以你在冒号上看到的行为，在其它五个上完全一样。稿子里如果有"这批货有三种规格,S、M、L"这样的写法，那个逗号后面跟的是大写字母S，同样不会转。

三个条件里最容易忽略的是第一个

后面跟英文这条比较好记，前面必须紧挨汉字这条反而更容易翻车，因为它连一个空格都不容许。

规则允许汉字和标点之间夹空白，但不允许夹别的字符。如果你的稿子里写的是"结束）,下一段"，逗号前面是个全角右括号而不是汉字，这处就不会转。同理，引号、书名号后面紧跟的半角标点，也都在射程之外。

这类位置在实际稿件里不算少，尤其是引用结束后接逗号的写法。规范化跑完之后，重点扫一遍标点扎堆的地方，那里最容易留下漏网的半角符号。

这个设计到底对不对

我一开始觉得这是漏洞，想了想又觉得作者的顾虑有道理。

中文稿子里紧跟英文的半角标点，很多时候真的不该转。像文件名里的config.inc.php、版本号里的v1.2.3、参数写法里的width=1200,height=630，这些点和逗号一旦变成全角，内容就废了。作者选择"后面是英文就别碰"，是拿漏改换误改，在一个没有语法分析能力的正则工具里，这个取舍我认可。

但代价要说清楚：你的稿子里凡是"中文＋半角标点＋英文"的组合，工具一个都不会帮你处理，得自己扫一遍。像"参数说明:width"这种冒号，本来就该是全角，它不会替你改。

更麻烦的是这条边界完全不可见。工具不会告诉你"这里我看到了但故意没动"，它只是安静地跳过去。所以规范化跑完不等于全稿都规范了，只等于"符合那三个条件的地方都处理了"。

括号那条规则，文档和代码原来说的不是一回事

示例文案末尾那个(推荐尺寸)没转成全角，一开始我以为跟冒号是同一个原因，查下去发现是另一码事，而且这处是真的写错了。

文档里承诺的是什么

工具左侧选项列表里，这条规则的说明写的是"两侧都是中文时才转，避免误伤缩写"。页面下方的常见问题里也重复了一遍，说括号的转换比较保守，只在两侧明确是中文环境时才转，因为英文缩写后跟括号的情况很常见，一刀切会误伤。

这个意图是对的。中文里写SEO(Search Engine Optimization)是很常见的写法，那对括号确实不该变成全角。

实测下来是什么

三组输入，结果全都偏离文档：

实现只检查了左侧的那一个字符是不是汉字，右侧看都没看。于是左边是汉字就转，哪怕括号里装的是纯英文缩写；左边不是汉字就不转，哪怕括号里全是中文。文档承诺的"两侧"，代码里只兑现了一侧，而且是没用的那一侧。

我把它改成了什么

发现这个之后我没有绕过去，直接改了。改法不是补上右侧判断——右侧那个字符可能是句号、可能是行尾，硬要求是汉字反而会挡掉一堆正常情况。

真正决定该不该转的，是括号里装的是什么：里面出现中文就转全角，里面是纯英文纯数字就保持半角。这才是文档那句"避免误伤缩写"想表达的东西。改完之后同样四组输入：

四条全对。示例文案里那处括号，现在也跟着对了。选项说明和常见问题里的措辞我一并改成了"括号里含中文时才转"，免得文档继续跟代码打架。

三块面板报的数，为什么对不上？

规范化跑完，结果区有三样东西：处理后的正文、一排改动计数、一份逐条改动明细。理论上它们说的应该是同一件事。实测下来，这三块曾经各说各话。

单引号：改了，但明细里一条都没有

输入一句带两个半角单引号的话，计数面板显示"引号统一2"，改动明细里却只有一条标点全角的记录，单引号的改动一条都不显示。

原因在代码里一眼能看到：双引号、直角引号「」、书名号式的『』转换时都调用了记录改动的函数，唯独单引号那一段漏了，只加了计数没有记录。这属于纯粹的实现遗漏，已修复，现在两处单引号会各出现一条明细。

省略号：输出没变，统计说改了一处

这条更隐蔽。输入一句已经很规范的"他说……然后结束了。"，输出与输入一字不差，改动总数却显示1。

因为省略号规则匹配的是"两个以上的省略号字符"，标准的中文省略号正好是两个字符，自己匹配自己，替换成一模一样的东西。改动记录函数会比较前后是否相同、相同就不记录，所以明细里是空的；但计数器在函数外面，照加不误。已修复，现在遇到本来就规范的省略号会直接跳过。

两百条：统计说三百，明细只肯给两百

我拿一段有300处待改标点的文本试了下：计数面板显示改动总数300，改动明细列出200条整，然后就没了，页面上没有任何提示告诉你后面还有100处。

代码里有个写死的上限，记录改动的数组满200条就不再往里塞。这个上限本身是合理的，几千条明细渲染出来页面会卡死。问题是它截断得太安静了——你以为自己核对完了全部改动，实际只看了三分之二。

这类静默截断在工具里是最难发现的一种缺陷，因为界面上没有任何异常，一切看起来都很正常。已修复，现在超过200条会在明细末尾补一行提示，写清楚总共改了多少处、只列出了多少条。

还有一处对不上：空格空行那栏永远只有数字

顺着这条线往下查，我发现清理空格与空行那类改动也从来不进明细。输入两行带行尾空格的文本，计数面板显示"空格空行2"，明细里一条记录都没有。

这类改动的性质和前面几处不太一样：行首尾空格被删掉了，这件事在明细里怎么展示都很别扭——你总不能画一行"两个空格变成零个空格"给人看。所以这处我没有动，它属于展示上的取舍，不是实现缺陷。

但你得知道有这回事：改动总数这个数字，一直大于明细能给你看到的条数。差额来自空格空行这一类不可视的改动。核对的时候按明细走，不用去凑那个总数。

为什么这三处值得单独修

可能有人觉得，一个统计数字差一点点无所谓，反正输出是对的。我不这么看。

这类工具的价值，一半在处理结果，另一半在让你敢相信处理结果。改动明细存在的唯一意义就是让你核对，而核对的前提是明细跟实际改动一一对应。如果单引号改了却不告诉你、没改的地方却算进了总数、超过两百条就悄悄不说了，那这份明细就从"核对工具"退化成了"装饰品"。等你哪天真被误伤一处，也不会想起来去看它。

剩下那几条规则各自在做什么？

标点和括号占了大部分篇幅，但选项列表里一共有八条规则。剩下几条实测下来都很本分，值得各说两句，因为它们的边界同样有用。

省略号：三种写法收敛成一种

中文标准的省略号是六个点，在Unicode里是两个连续的省略号字符。实际稿件里的写法五花八门：英文习惯敲三个句点，有人敲三个中文句号，还有人敲一个省略号字符了事。

这条规则把三个以上的半角句点、三个以上的中文句号、两个以上的省略号字符，统统换成标准的两个省略号字符。我实测输入"等等...还有。。。以及……结束"，三种写法出来是一模一样的标准形式。这条做得很干净。

破折号：连字符和短横线一起收

中文破折号占两个字符宽，写法上是两个连续的破折号字符。稿子里常见的错写有三种：两个半角连字符、一个英文的短横线、以及只写一个破折号字符。

三种都会被收成标准形式。我实测"这是--破折号–和—单个"，输出三处全部统一。前面提到的命令行参数被误伤，根源就是这条规则——它没法区分你写的是破折号还是--force里的双连字符，也不可能区分，因为字符本身完全一样。

全角英数转半角：这条很少有人想到要开

全角的英文字母和数字，长得比半角宽一倍，在中文里夹一串全角数字非常难看。这类字符多半来自输入法没切回来，或者从某些老系统里导出的数据。

实测输入一串全角的字母数字，输出全部变回半角，一个不漏。注意它只转字母和数字，全角的标点不会被转回半角——这是对的，中文正文里的标点本来就该是全角。

合并重复标点：默认关着，开之前想清楚

八条规则里只有这一条默认不勾选，它把连续重复的句号、感叹号、问号、逗号、顿号、分号、冒号合并成一个。

默认关掉是对的。中文写作里连着敲三个感叹号往往是刻意的语气表达，社交媒体文案和口语化内容里尤其常见，一刀切合并会把情绪抹平。这条更适合处理正式文档、产品说明这类不该有情绪标点的稿子。

结果区那三个按钮

处理完之后有复制、下载、放回输入框三个动作。复制走的是浏览器剪贴板接口，下载会生成一个纯文本文件，放回输入框则是把结果塞回原位置，方便你改完选项再跑一次。

要注意最后这个：把结果放回去之后，原文就没了。工具没有撤销功能，原文全靠输入框里那份。如果你打算连跑两轮不同的选项组合，先把原文另存一份。

哪些内容它保证不碰？

一款会批量替换标点的工具，最要命的风险是把代码改坏。这方面它做得比我预期好。

五类会被保护的片段

处理正文之前，工具会先把五类内容整段挖出来存好，等所有替换做完再原样放回去：

1. 三个反引号包起来的代码块
2. 单个反引号包起来的行内代码
3. 尖括号包起来的HTML标签
4. 以http或https开头的网址
5. 邮箱地址

示例文案里那行const a = 1, b = 2;用反引号包着，跑完之后里面的半角逗号和分号一个没变，这个保护是真的生效了。

占位符用的是私用区字符

这里有个细节值得说，因为我一开始判断错了。

挖走片段之后总得留个记号，等会儿好把内容填回去。我第一眼读源码，看到留下的记号像是纯数字的序号，当场倒吸一口凉气：如果记号是裸数字，那还原的时候正文里所有的数字都会被当成记号，示例文案里那句"一共有106款工具"就该变成一堆乱码了。

结果实测完全正常，106还是106。回头去查字节才发现，序号两侧各裹了一个Unicode私用区字符，位置在U+E000和U+E001。这两个码位在正常中文稿件里几乎不可能出现，拿来当分隔符是对的。之所以我读源码时没看见，是因为这类不可见字符在多数编辑器和文本读取工具里根本不显示。

这件事的教训比结论本身有用：读源码得出的判断，必须拿真实运行结果验一遍再写。我这条"数字会被抹掉"的猜测，从推理链条上看无懈可击，跑一遍就碎了。不可见字符尤其容易骗人。

那这个保护有没有破法

有，但很窄。既然记号是"私用区字符＋数字＋私用区字符"，那如果你的原文里恰好包含这样一段序列，还原的时候就会被误认成记号。我构造了一个这样的输入，输出里如愿出现了undefined。

要触发它，你的稿子里得凑齐这个三段结构。私用区字符本身不算罕见——图标字体的字形就大量落在U+E000往后的区间，从图标库网页上复制文字时有可能连带复制到。但恰好夹一个数字再夹一个U+E001，概率低到可以忽略。这条属于理论上的边界，不是日常会踩的坑，我在这里写出来是为了说明保护机制的作用范围，而不是提醒你去防。

没有标记的裸代码，它救不了你

保护的前提是有标记。反引号、尖括号、http开头，这些是标记。如果你直接在正文里裸写一行代码，工具看到的就只是普通文本。

常见项目工作流参数写法就是重灾区：--force这种双连字符开头的参数，跑完会变成中文破折号。我实测输入"运行时加--force参数就好"，出来的是"运行时加——force参数就好"。写技术类稿件的话，凡是命令行参数，一律用反引号包起来，这一条能省掉大部分麻烦。

中英文之间那个空格，加还是不加？

这是中文排版里最能吵起来的一个议题，工具没有替你选边，给了三个档位。

三个档位分别做什么

• 去掉空格：把汉字与英文数字之间的空格删掉，这是默认档，也是本站的规范
• 保持原样：一个字不动，只跑其它规则
• 补上空格：在汉字与英文数字相邻的位置插入一个半角空格

我实测了幂等性——把补空格的结果再跑一遍补空格，输出没有变化，不会越跑空格越多。这是个容易写错的地方，作者处理对了。

两派各有各的道理

主张加空格的一派，理由是中西文字形的重心和留白不一样，紧挨着排视觉上会挤。W3C的《中文排版需求》文档在中西文混排那一节里，确实建议在汉字与西文之间留出四分之一个字宽的间隙。

但要注意，规范说的是排版层面的间隙，不是让你在文本里手敲一个空格。真正规范的做法是交给渲染引擎去处理字距，而不是把空格写进内容。出版界的中文书刊里也基本不在正文里插空格。

本站选了不加，理由很实际：空格一旦写进内容，它就会跟着内容跑遍所有地方——数据库、接口返回、搜索索引、AI抓取时的纯文本。一处加了另一处忘了加，全站就不统一了。而统一比选哪一派重要得多。

顺带清掉的还有中文之间的空格

清理空格与空行那条规则里，还包含一项：把两个汉字之间的空格删掉。这条对付的是从PDF或图片识别里粘出来的稿子，那类文本经常带着莫名其妙的字间空格。

如果你是刻意用空格做人名对齐之类的排版，记得把这条规则的勾去掉，不然会被一并清掉。

为什么统一比正确更值钱

这话听着别扭，但在排版这件事上确实成立。加空格和不加空格，读者几乎不会因为你选错了而离开；可同一个站里一半加一半不加，那种毛糙感是能被看出来的。

更现实的影响在机器那一端。搜索引擎和AI抓取拿到的都是纯文本，"SEO优化"和"SEO优化"在字符串层面是两个不同的东西。同一个概念在站内出现两种写法，聚合、去重、匹配的时候都要多绕一道。稿子多了之后，这种小分歧的成本是复利式增长的。

所以真正该做的决定只有一个：挑一派，写进规范，全站执行。至于挑哪一派，坦白讲没那么重要，重要的是别让它变成每个作者自由发挥的地方。

什么样的稿子不该直接过这个工具？

说完能力再说边界。有三类内容我建议先想清楚再跑。

带英文撇号的稿子

英文里的don't、it's用的是半角单引号，跟中文单引号是同一个码位。工具的引号规则会把它当成中文引号的一半，按一开一合交替替换。

实测输入"这是don't和it's的写法"，输出变成了"这是don‘t和it’s的写法"——第一个撇号变成了左单引号，第二个变成了右单引号。如果你的稿子里英文缩写比较多，把引号规则关掉再跑。

技术文档和代码密集的稿子

前面说过的裸代码问题，在技术文档里出现频率最高。文件路径、正则表达式、配置片段、命令行，这些东西只要没包在反引号里，就是普通文本。

建议的做法是：先把稿子里的代码片段都标记好，再跑规范化，跑完逐条看改动明细。明细面板现在会老老实实告诉你改了多少条、列出了多少条，比以前可信。

已经很规范的稿子

这条不是风险是浪费。如果你的稿子本来就是全角标点、中文引号、标准省略号，跑一遍的收益接近零。工具适合处理的是来源混杂的稿子——多人协作的、从别处粘贴的、跨系统导入的。

混排了日文假名的稿子

这条比较偏，但踩到了很难查。工具判断"这是不是中文"用的字符范围，除了常用汉字和扩展区之外，还包含了日文假名的区间。

也就是说，平假名和片假名在这套规则眼里等同于汉字。做日语站或者稿子里夹了日文商品名的话，假名后面的半角标点也会被转成全角。多数时候这个结果是对的——日文正文本来也用全角标点——但如果你是在中文稿里引用一段日文原文，可能就不希望它被动。

已经发布出去的内容

最后这条是流程问题不是工具问题。文章发布之后，正文会被摘要、结构化数据、各层缓存、站内搜索索引分别取用过。这时候再回头改标点，改的只是数据库里那一份，其余各处得挨个刷新。

为一堆半角逗号折腾这一圈不值当。要么在发布前处理干净，要么就让它带着那些半角标点活下去——排版规范这种事，收益是长期的、缓慢的，没必要为存量内容付一次性的高成本。

六万字要跑多久？

常见问题里写着"十万字级别在现代浏览器上一两秒内能完成"。我拿一段6.2万字符的文本实测，从点击到结果渲染完成，用了39毫秒。

比承诺快了将近两个数量级。原因也不难理解：所有规则都是一遍正则替换，没有分词，没有语法分析，没有网络请求，整个过程就是十来次字符串扫描。这类纯正则的文本处理，浏览器跑起来是很快的。

顺带说一句，工具的常见问题里说"页面加载后断网也能用"，这句是真的——所有逻辑都在页面里，没有任何后端接口。稿子不会离开你的浏览器，未发布的内容拿来跑也不用担心。这一点和Emoji表情生成器、中文简繁转换器这些同类工具是一样的设计。

怎么把它放进自己的发稿流程？

工具本身是个单点，真正省事的是把它嵌进流程里。我自己的顺序是这样的。

放在哪一步

放在定稿之后、录入之前。不要在写作过程中反复跑，写的时候心思应该在内容上；也不要在文章发布之后才想起来，那时候改动会连带影响已经生成的摘要、结构化数据和各处缓存。

如果稿子是从别的地方翻译或整理过来的，还可以往前加一步——先过简繁转换统一字形，再跑排版规范化，顺序反过来会多绕一圈。需要生成URL里的英文别名，可以接拼音转换工具。

先跑一段试水

面对一份陌生来源的长稿，别一上来就整篇跑。先揪出最有代表性的两三段——最好包含代码、英文、数字的那几段——单独跑一遍，看改动明细里有没有你不想要的改动。确认脾气之后再整篇过。

这个习惯不只适用于这一款工具。凡是会批量修改内容的东西，先小样本验证再全量执行，都是省事的做法。写长文档的时候也是一样的道理，Word长文档的样式与目录那套东西同样吃这个习惯。

改动明细要真的看

结果区那份明细不是装饰。尤其在改动数量不大的时候，从头到尾扫一遍花不了三十秒，能挡掉绝大部分误伤。我自己的经验是，越是觉得"这次肯定没问题"的稿子，越容易在里面藏一处不该改的地方。

如果稿子是AI参与生成的，这一步更值得做——机器写出来的文本里，标点风格常常在段落之间来回横跳，规范化的改动量会明显偏大。关于这类稿子怎么处理得更省心，可以看用AI写作又不想让稿子一眼假那篇里的做法。

常见问题解答

为什么我的冒号没有被转成全角？

大概率是冒号后面跟着英文或数字。标点转全角这条规则要求前面是汉字、后面是空白行尾或另一个汉字，三个条件同时成立才动手。像"参数说明:width"这种后面跟英文的情况，工具会直接放行。这是作者为了避免改坏文件名和参数写法而做的取舍，代价是这类位置需要你自己处理。

括号什么时候会转成全角？

看括号里装的是什么：里面出现中文就转成全角，里面是纯英文或纯数字就保持半角。所以"说明(推荐尺寸)"会转，而"SEO(Search Engine Optimization)"不会转。这个判据是我在写这篇时改的，此前的实现只看左侧字符，会把中文后面跟英文缩写的括号误转成全角。

改动明细为什么只有200条？

明细列表有200条的渲染上限，超出部分不再逐条显示，但计数面板给的是完整数字。现在超过上限时明细末尾会补一行提示，写明总共改了多少处。如果你需要逐条核对全部改动，把长稿分段跑。

代码会不会被改坏？

用三个反引号包的代码块、单个反引号包的行内代码、尖括号包的HTML标签、http开头的网址和邮箱地址，这五类会被整段保护，替换完原样放回。但没有任何标记的裸代码识别不出来，双连字符开头的命令行参数会被当成破折号处理。技术类稿件建议先给代码加好反引号。

英文的撇号会被改吗？

会。don't和it's里的半角单引号与中文单引号是同一个码位，引号规则会把它们按一开一合替换成中文弯单引号。英文缩写较多的稿子，建议把引号统一那条规则的勾去掉再跑。

中英文之间到底该不该加空格？

两派都有依据，工具给了去掉、保持、补上三档让你自己选。W3C的中文排版需求建议在中西文之间留出四分之一字宽的间隙，但那说的是排版层面的字距，不是让你把空格写进正文。本站的规范是不加，工具默认也是去掉。关键不在选哪派，在全站统一。

内容会上传到服务器吗？

不会。所有处理都在浏览器里完成，页面加载完之后断网也能用，没有任何后端接口。未发布的稿件可以放心跑。

处理长稿会不会很慢？

不会。实测6.2万字符的文本，从点击到渲染完成用了39毫秒。全部规则都是正则替换，没有分词和语法分析，速度瓶颈基本不存在。真正需要分段的理由是方便逐条核对改动，不是性能。

权威参考资料