分享个人使用的网文常见字词替换校对表（含 php 脚本）

edennow

【最近更新信息】
4 月 21 日更新词库，“自定义词库.php”文件中新增两个变量“strictMap”和“strictRegexMap”，分别用来存放一些区分标准较为严格的词条和正则。

发现有部分（疑似）象声词（例如“滋滋”等）、口语化表达（例如“涉及到”“来自于”“仅仅只”“出乎意料之外”等），以及一些区分比较细致的字词（例如“做作”“坐座”“撇瞥”等），在一般的文本中出现频率非常高。

和一些明确纠错的词条混合在一起校正容易分散注意力，故把这部分单独放到那两个变量里，可以随时自行调整，把一些个人认为可改可不改的词都先堆到这两个地方，然后在命令行选择“严格模式”进行单独校正（这部分词条的准确率相对较高，单独看校正结果也比较轻松）。

请确认一下这两个变量中现有的词条，并仔细留意一下命令行中新增的选项信息，如果不用“严格模式”单独校正一轮的话，这部分词条就不会在文本中进行替换了。

4 月 5 日更新词库，词条新增“replaceHolder”（随意造的词）设置，可用于进一步折叠词条，便于扩展不同的前缀后缀等（尤其是一些“的地得”的词条）。
如果感兴趣可以拉到 $normalMap 的最后，搜索一下“付诸实践”，在那个词条的位置附近有写一些注释说明，可供理解参考。



目前论坛里的这个置顶帖：
http://www.1000qm.vip/forum.php?mod=viewthread&tid=42400

已经有了比较全的用于文本校对的工具，不过根据我自己的使用体验，以及论坛中经过软件校对发出来的文本内容来看，貌似有一些网文里常用的字词还是没有替换到。

因此额外分享一份个人用的字词替换表，包含了基本的教育部发布的《第一、二批异形词整理表》，以及个人加上的一些网文常见错别字。
用这份字词表替换之后，再用太阳系的 emeditor 宏以及 txtFormat 之类的软件进行校对，应该能提升一些效率和准确率。

毕竟再也不想看到：

“半响”“臻首”“嘎然而止”“诺大的”“按耐”“一颗树”“一柱香”
“附骨之蛆”（应为“疽”，百思不得其解的一个错词，到底为什么能写成“蛆”-_-||）
“一滩水/血/泥”（应为“一摊水/血/泥”，不用怀疑，“滩”并没有量词的用法）

这些令人哭笑不得（按“网文通假字”的写法可能是“苦笑不得”）的错别字出现在文本里了。


如果要使用本脚本，请务必详细阅读下面的：
原文件预处理流程说明（建议必读一）
修改校正表说明（建议必读二）



php 脚本（可一键运行）


emeditor 貌似只能手动调用宏进行文本替换（应该是我没找到自动批处理的宏或者方法），
所以另外用 php 写了一套自动修正的脚本，支持 epub 和 txt 两种格式的文件，支持自动嵌套递归批量修改书籍文件。

php 环境
现在把 php 8.1 版本的可执行文件也同时打包进来了，不需要额外自己安装环境，一键运行即可。
因为本身代码写得很简单，为了减小压缩包体积，去掉了一些 php 扩展文件，如果执行有问题可以提出。

【额外说明】
这个脚本在运行过程中，会将所有文本文件的编码统一转换成“UTF-8（无 BOM）”，
换行符统一转换成“LF（即 \n）”。
如果对文件编码和换行符有要求，需要在校正完成和确认修改结果后，自行将文件编码恢复成自己需要的。

如果后续有在 txtFormat 中继续校对的需要，脚本转换出来的这个文本格式可能会导致 txtFormat 频繁弹出报错弹窗。
可以按照如下设置，转换文本的换行符和编码，txtFormat 就不会报错了（只转换行符，不转编码也可以）：


使用方法
把所有书籍放入 books 文件夹，执行 【双击运行】1.书籍校正.bat 或【双击运行】2.书籍校正（不进行原文件预处理）.bat，这两个命令都会对 books 文件夹中的书籍进行备份（自动复制一份到 booksBak 中）和递归校正。

区别在于第二个命令不会执行该帖上面提到的“原文件预处理”流程，自动备份在 booksBak 文件夹中的书籍原文件是原封不动的，

但是要注意，此时可能会在 beyond compare 中产生大量的差异项提示，请详细看看这个帖子中的“原文件预处理”，并确认你不需要进行原文件预处理，否则最好执行第一个命令脚本，会自动对原文件进行预处理。

执行了 FixText 中的校正 bat 脚本，完成文本校正后，建议直接用 beyond compare（在上面的置顶帖中可以找到下载） 的 “文件夹对比” 功能对比【books 文件夹】中被修改的书籍 和 【booksBak 文件夹】中被预处理过的书籍备份原文件，手动进行对修改结果的确认和对误伤项的修复。

其他详细校对流程，参考：epub 校对教程
推荐把本帖和上面这篇结合看一下，能更好理解个人进行 txt 和 epub 文件校对的思路（虽然很长很啰嗦）。

php 脚本运行效果如下：




原文件预处理流程说明（建议必读一）
可大幅提升用 beyond compare 比较时的校对效率。

目前替换表里融合了《第一、二批异形词整理表》、【太阳系联盟增强 emeditor 宏】的大部分词库，
以及个人根据校对经验选出的部分网文常见错别字。

其中包含了一些常见词组和成语的纠错，比如“好象”->“好像”“提心掉胆”->“提心吊胆” 等，
这种词组的特征是：

• 改正正确率极高，如果文本中出现的是前面那个错误用法，基本可以宣判 “死刑”，直接替换，不会出现误伤。
• 如果在文本中进行替换，替换的频率非常高，可能在一个文本里会替换成百上千处这样的词组。
  

这就造成了后续在 beyond compare 进行【修改后的文件】和【原文件】比对 的时候，会出现大量“你明知道它改的是正确的，还是会出现提示的差异项”，会分散校对的注意力。

所以这里提出 原文件预处理 的流程思路：
也就是在使用 beyond compare 比较原文件前，先把这部分“特征明显，误伤率低，出现频率高” 的词组在 原文件的文本 里进行替换（因为基本不会误伤，不影响正确率），让原文件和修改后的文件里的这部分词组保持一致，这样就不会出现差异提示，可以把注意力专注到其他被替换的词组身上，确认修改，拯救误伤，提升校对的效率。

如果不加这一步替换原文件词组的话，我的感受是重复出现的差异项是很耗费心智的，原本只要花几分钟就能确认完的文本，可能会额外花费你几倍的时间。

如果你能理解我说的这个思路，可以自己修改 src/maps文件夹 里 1.自定义词库.php 的 $preprocessMap 变量的词条（里面都是预处理流程中用到的词条），把不需要的删掉，加上你认为百分百不会误伤的词条（需要把这里的改动也同步到 同文件的 $normapMap 变量，因为前者是后者的子集，$preprocessMap 变量里有的词条用 ctrl + f 就能在 $normapMap 变量 找到一份一模一样的 ），最好也是把新加的词条放到最后，可以确保新加的内容生效。



修改校正表说明（建议必读二）
如果想修改校正表，增加或者删除规则，直接改 src/maps 文件夹的 “1.自定义词库.php” 文件（在 src 文件夹中的 maps 文件夹里）即可。

按照目前这种机械堆砌词条的做法：

• 没有符合所有人口味的词库
• 没有适用于所有文本的词库
• 没有一劳永逸既不漏改又不误伤的词库
  

最好还是靠平时的不断校正对比除错，多校正几本书，根据和原文件比对的实际情况，自行增改完善适合自己的词库。



目前在  src/maps 文件夹的 “1.自定义词库.php” 文件中划分了几种类型的 map，
下面详细说一下这几种 map 的区别和用途：

①$normalMap，用来放自定义的替换词条


把里面的词条整行复制新增即可，也可删除或修改，格式比较好懂，应该挺容易操作（图中的 $normalFixMap 被合并到一起了，可以无视，只改 $normalMap 就行了）。

目前脚本使用 php 的内置函数 strtr 进行批量关键字替换，速度相当有保障，比一般从头到尾遍历多个关键字，进行多次全局替换的 emeditor 宏要快几个数量级，几百万字的网文大概在 10 秒以内就能处理完毕。
下面着重插入介绍几个该脚本中的词条设置和修改规则，后续修改各种词库中的词条时，请务必参照这里提到的设置规则，以免出现词条的词义混淆或者不生效的情况：

1.可以通过设置 before 与 after 值相同的词条，提高某些词条的优先级，防止被误改。
比如可以想象一下整个词库里只有“暴发->爆发”这一个词条，那文本中所有的“暴发”都会变成“爆发”，“暴发户”也无法避免地会被误改成“爆发户”。
如果额外加上“暴发户->暴发户”这种词条（before 和 after 的值都是“暴发户”，看上去好像什么都没改），就是告诉脚本：

“帮我把所有的‘暴发’都改成‘爆发’，但是如果碰到‘暴发户’这个词就保留原样”。

这样也就起到了防止某些词条被误伤的效果了。

同理也可以再加上“暴发之家->暴发之家”的词条，就是告诉脚本，碰到“暴发户”和“暴发之家”就保持原样，其他所有的“暴发”都统统帮我改成“爆发”。

要解决这同一个“暴发户”被误改为“爆发户”的问题，还有另外一种简单的思路，
那就是加上“爆发户->暴发户”的词条，这种方式和普通用户的直觉应该非常贴合，无非就是：
第一次替换，把所有的“暴发”都改成“爆发”，有一些改错的词条也没关系。
第二次替换，把第一次被误改出来的“爆发户”还原成“暴发户”。

这种设置“爆发户->暴发户”词条的方式本质上是做了两次修改。
而设置“暴发户->暴发户”词条的方式则是通过较长词条“暴发户->暴发户”的高优先级覆盖了较短的“暴发->爆发”，实际上是只做了一次修改（或者说 0 次）。

这两种方式在大部分的替换结果中并没有差异，但实际上是有一些语义区别的，需要通过实际操作自行体会一下，个人是推荐优先考虑通过“暴发户->暴发户”这种看上去什么都没改的词条来覆盖一些误伤项，产生额外问题的概率会相对较小。

2.较长的词条优先级更高。
例如，原文是：他是一个爆发户。
替换词条是：爆发户->暴发户 和 爆发->乱发，

无论你在词库文件里把哪个词条放在前面，
比如：
爆发->乱发
爆发户->暴发户
或者：
爆发户->暴发户
爆发->乱发
脚本都会优先匹配“爆发户->暴发户”（正向最大匹配），结果都是：他是一个暴发户，不会被误伤成：他是一个乱发户。

另外注意一下，这里的长度优先级是在词条有“相同前缀”的前提下生效的（实际上前缀比长度更重要），
例如这里的爆发和爆发户两个词条，前面的部分都是一样的，故长度优先的原则生效，爆发户会被优先匹配。
前缀不同时，以词条在原文字符串的出现顺序为准，出现得越早，匹配优先级越高（判断前缀+正向最大匹配）。

也就是说，如果你设置的词条是：
爆发户->暴发户
个爆->乱改

即使第一个词条的长度比第二个的长，但是“个爆”这两个字在字符串中比“爆发户”这三个字出现得更早，
所以结果会是：他是一乱改发户。

3.同样长度的词条，放在后面的优先级更高。
例如，原文是：黑夜消散了。
替换词条是：夜消->夜宵 和 夜消->夜失。
第一个词条放后面，执行两个词条替换后，结果是“黑夜宵散了”;
第二个词条放后面，执行两个词条替换后，结果是“黑夜失散了”。

另外需要注意的一些要点：
①尽量保证改前和改后值（before 和 after 值）的长度相等，一般情况下不建议做加字或减字的操作，除非特征非常明显。
②尽量避免出现同一个 before 值对应多种 after 值的情况（比如 夜消->夜宵 和 夜消->夜失 这样两个词条，实际只会改成放在后面的这个词条，放在前面的那些相同 before 值的词条半点用都没有，可以删掉）。

目前为了处理一些有隐晦关联的词条，尽量保证每次执行的结果都是一致的，实际上是每个词条都会重复执行两遍替换（abb 式的叠词应该会没问题了，不过更多重复的可能还是会有部分出错），
同时需要注意，部分长度较短的词条可能会被长度较长的词条完全包含，也有可能产生一些混淆（每个词条都执行了两次替换，可以自己实验下）。
当然，上面说的几个原则同样还是生效的，如果出现了莫名其妙的混淆问题，不妨再尝试理解一下这些原则，自行修改词库。



②$preprocessMap，用来存放原文件预处理的词条


文件最开头的 $preprocessMap 变量，存放的是上面提到的用于原文件预处理的“特征明显，误伤率低，出现频率高” 的词条，如有需要可以自己修改（需要把对 $preprocessMap 变量 的改动也同步到  $normalMap 变量，因为前者是后者的子集，$preprocessMap 变量 里有的词条用 ctrl + f 就能在 $normalMap 变量 找到一份一模一样的。）

③$punctuationsMap，定义了一些标点的转换


在这个 map 里定义的标点转换，会导致全角的英文数字等被转换成半角字符。
直角引号「」也会变成弯引号“”，如果不需要这些转换的可以直接把这一堆符号的转换删掉再执行。

④$regexMap，存放正则表达式替换规则


这个 map 里存放的正则规则会被逐一执行，进行替换。
支持分组、断言之类的功能，注意替换处的分组引用形式为“$1$2……$n”，而不是 calibre 和 sigil 等编辑器中的“\1\2……\n”。
不过其实不太推荐往这里堆太多的正则，除非有些词汇的特征比较明显，而且不好拆分成不同词条，否则最好还是把词条堆到上面的 $normalMap 变量中，有助于保持执行效率。

⑤$postFixMap，校正后置词库


目前的脚本运行步骤是“各种词库的批量关键字替换”->“一系列正则表达式规则替换”。
导致有部分被误改的词条即使放到各种 map 变量中，也有可能被正则表达式再次误改。

因此新增了这个 $postFixMap 变量，也就是等上面的“关键字替换”和“正则表达式替换”都做完后，
会再调用一遍这个变量里的词条，进行对误改处的修复。

可以理解为这里面设置的词条是优先级最高的，且一定会执行替换，可以用来修复各种看着不爽的误改（主要是 regexMap 中的正则导致的），
当然设置规则和上面解释的是一样的，请务必仔细理解词条的修改和设置逻辑，以免混淆。

建议必读的“原文件预处理”和“修改校正表”的相关说明到此就结束了，帖子里的其他内容（关于 txtFormat 词库的说明也推荐看一下）可以有时间再慢慢看。



此外在 src/maps 文件夹 中（看这一节最上面的图），还引入了：

• 2.繁转简词库.php
• 3.txtFormat词库.php
• 4.的地得词库.php
• 5.临时校正表.php
• 书籍专有替换词库.php
  

2.繁转简词库.php
注意，繁转简默认是不开启的。
需要在开始校正的时候手动输入【繁转简词库】的索引值使用该词库。

另外说一下这个 $t2sMap 中的词条来源，是个人从 opencc 代码的字典库中提取并结合实际经验整合好的，去掉了 cjk 扩展区字符和蛋疼的“乾”字转换，理论上和 opencc 繁转简效果一致且更不易出错。

何为 cjk 扩展区字符？
可以简单理解为对简体汉字（还有日韩和东南亚的一些奇葩文字）的一个扩充。

例如“赵孟【兆頁】”的“【兆頁】”字，在 cjk 扩展区中被简化为“【兆页】”字，可能很多人也见过类似的字符，如语文教材中出现过的“【山献】”“【酉农】”等字。

但很可惜这部分字符是位于扩展区的“非规范的简化字”，在 bc 和部分编辑器中会显示为“编码错误”，不允许编辑（用 UTF-8 编码打开报错，可手动改成 ANSI 编码，即可编辑）。
此外，如果浏览的时候使用的字体字库不全，这部分字符可能会出现显示为空白的现象。

为了保证更佳的兼容性，把这部分字符在 opencc 词库中做了手动过滤，剔除掉了，尽量不影响后续的比对和编辑体验。

为何暂时没做简体转繁体？
繁体字和简体字之间有不少“一简对多繁”（干->乾和幹 发->發和髪）的情况，将“多个繁体字”映射为“一个简体字”，个人认为准确率是比较高的，可以比较放心地做繁体转简体的操作；

但是，如果反过来将“一个简体字”映射为“多个繁体字”，可想而知难度比较大，准确率也相对较低，即使使用 opencc 做转换，也会出现不少错误转换，因此个人不太建议直接做“简体转繁体”的操作。

如果实在需要，建议尝试使用【繁化姬】：https://zhconvert.org/
桌面版应用下载：https://github.com/Fanhuaji/Fanhuaji-GUI-by-James1201/releases

3.txtFormat 词库.php
注意，txfFormat 词库默认是不开启的。
需要在开始校正的时候手动输入【txtFormat 词库】的索引值来使用该词库。

说明：
3.txtFormat 词库.php 文件中的词条来自 txtFormat 2.0.8 版本的错别字词库文件（2.1.0 版本的好像被封装了，没找到，但目测 2.0.8 版本跟 2.1.0 版本的词库并没有差别），包含约十万条词条（有一些我认为明确没啥用的词条被我删掉了，数量不多，可以在用脚本的【txtFormat 词库】自动校正之后，把这份校正完的文档导入到 txtFormat，再测试一下它的“常见错别字”修正，其实已经做不出什么有效的修改了）。

经过粗略测试多本网文的校正效果，目前脚本的自动修正基本能达到 txtFormat 【有效】手动修改错别字操作（排除掉 TF 那些乱七八糟的误改） 80%-90% 的效果（还会额外做出很多 txtFormat 默认词库没有的修正）。

在目前优化的操作流程中，可以在选用【自定义词库】完成第一轮校正后，再输入 1 进行第二轮校正，
并在此轮校正中选用【txtFormat 词库】来校正，结果相当于将 txtFormat 中的每个错别字修改都应用了“全部替换”（等于是在 txtFormat 中做了 100% 的修正操作）。

因为第一轮用【自定义词库】基本已经把能自动修正的错别字都改好了，所以用【txtFormat 词库】再校正其实并不会有特别多的有效修正（除了一些 OCR 出的怪异错误），而且 txtFormat 词库中的较短词条容易产生混淆，在 BCompare 对比时会发现有不少误改。

通过 BC 对比第二轮校正结果时，可以直接无视掉那些误改，抽取一些 txtFormat 做出了有效修改的词条，补充到【自定义词库】中，这样会持续提升【自定义词库】对 txtFormat 词库中有效词条的覆盖率。

如果原来在 BC 比较时的“修复误伤”的操作方向是 booksBak->books，那在第二轮可以考虑把操作方向换成 books-> booksBak，将 books 中被【txtFormat 词库】做出的有效的修改项先同步到 booksBak 的文件（booksBak 中的文件实际上是上一轮通过【自定义词库】改好的结果文件）中，最后再将 booksBak 的文件全体覆盖到 books 中（这样可以直接把 books 中的那些【txtFormat 词库】造成的误改项全部覆盖掉），会提高【txtFormat 词库】的校对操作效率。

最好先将【自定义词库】校正完后的 books 中的文件移到别的地方进行备份，再进行第二轮使用【txtFormat 词库】的校正。
因为【txtFormat 词库】会产生很多无谓的误改，只是用于抽取部分有效词条进行参考，并不推荐直接使用 txtFormat 词库校正后的文本作为最终的结果，而是应该采用【自定义词库】改好的那份文本。

另外， txtFormat 的词库本身也不一定全部都是规范用词，例如更推荐使用的“血脉偾张”在词库中是“血脉贲张”；“下功夫”在词库中则是“下工夫”，都和推荐用法有出入，即使用 txtFormat 校对，也需要自己有相关的判断意识。

目前脚本中有大约 60% 的词条是直接从 txtFormat 里搬的，脚本词库和 txtFormat 词库的大致关系如下：




如果能够在第二轮校正采用【txtFormat 词库】再扫一遍文本，就可以持续识别出黄色的这部分 tf 中的有效词条（如上面所说，在这一轮只关注正确的修改项就好，误改项可以一律无视），并加入到脚本的词库中，后续就基本可以脱离 txtFormat “常见错别字”（其他叠字叠词之类的检查功能，可以继续用 tf 或者自行写正则搞定）那种机械单调无聊的点点点的交互了。

总而言之就是，第一轮用自定义词库来校正，正确率比较高，应该专注于查出误改项（等于是金里挑史），进行手动恢复。
第二轮用 txtFormat 词库校正，准确率相当低，应该专注于查出正确项（等于是史里淘金），补充到词库中，同时用 booksBak 中的备份，覆盖掉被 txtFormat 修正过的文件。

做完这两轮校正并比对后，只会比单纯用 txtFormat 做出更多的有效校正，而不可能比它做得更少。

4.“的地得”词库.php
注意，“的地得”词库默认是不开启的。
需要在开始校正的时候手动输入【的地得词库】的索引值使用该词库。

说明：
这个“的地得”词库也是从 txtFormat 2.0.8 版本 中提取出来的，本来以为 txtFormat 的“的地得”转换是写了一堆很复杂的正则才实现的，结果看了一眼，发现和上面的错别字词库一样，也是朴实无华地用成千上万的关键字拼成了一个超长的匹配规则。

那就干脆提取出来进行自动替换了（提取过程有点无语，掏出了尘封已久的按键精灵……）。

这个词库包含了 txtFormat 中“的地得”错误处理的完整词库（约一万条），建议一般也是不用开启，只有在单独处理“的地得”的时候，可以试用一下。

相当于在 txtFormat 中把所有的“的地得”转换应用了“全部替换”，误伤率应该是蛮高的，需要仔细通过 beyond compare 进行比对甄别。

不过个人感觉比起在 txtFormat 里面重复按键成百上千次，还是这样对比效率要高一点，而且也能随时自行更改“的地得”词条，降低误伤率。

5.临时校对表.php
支持“将阅读软件的批注自动转成校对替换表”，详情见：操作流程

书籍专有替换词库.php
此文件可存放各种书籍的专有替换词条，因为某些词条是只有某本书里才会出现的（某些误改也是只有某本书里才会发生的），
所以没有必要全部都堆在“自定义词库”的文件里。

可以选择在这个文件中参照我设置的 $《天之下》 变量，按格式创建对应的 $《书名》变量，
这样只有在校正这本书籍时，才会加载对应变量的词条，进一步提升准确率。
书名和变量名必须要对上，校对的实际文件名不用加书名号，比如实际文件名是 天之下.txt 或者 天之下.epub（任一文件后缀均可，但要注意 epub 格式的文件名不要包含下划线，否则无法生效），
而词库里的变量名则要加书名号，是：$《天之下》


这个词库在多次调用 FixText 脚本的场景下，应该相当有用。
比如在一段时间内给自定义词库加了很多的词条，这时想用扩充过的词库来校正一下之前校过的书，
把之前被误改的词条记录在这里，可以防止同一本书每被校正一次就被误改一次。
而且相当于是对应书籍的校对笔记，后续校正其他书时也可参考。

该文件的词条是在 各种 map 的关键字替换 和 postFix 后置操作 中都会调用的，也可以理解为优先级最高，且一定会执行替换，同时也支持“暴发户->暴发户”这种防误伤词条的设置。



完成校正后，强烈建议用 beyond compare 比较原文件
执行了 FixText 中的校正 bat 脚本，完成文本校正后，建议直接用 beyond compare（在上面的置顶帖中可以找到下载） 的 “文件夹对比” 功能对比【books 文件夹】中被修改的书籍 和 【booksBak 文件夹】中被预处理过的书籍备份原文件，手动进行对修改结果的确认和对误伤项的修复。

虽然绝大部分字词都是替换准确的，但是肯定有少部分词条因为上下文环境等原因出现偏差，多检查一下总是好的。

尤其是目前词条扩充之后，发现误伤率有所提升，所以最好最好再用 beyond compare 检查一遍。
至于如何减少 beyond compare 比较时可能出现的大量干扰项，请看上面的 原文件预处理流程说明。

按照目前的脚本词条设置来看，只要文本中不是有一些比较频繁出现的误改词条，基本正确率能达到 90% 左右（如果有那种重复次数很多的误改词条，也较容易识别，顺手就能在 beyond compare 里面全局替换改掉）。

感觉只要正确率差不多能维持在 80% 到 90% ，运行这个脚本是能称得上划算的。

按目前这种做法想要完全消除误改，也不太现实，暂时也没有引入什么 ai 手段来校正的想法，只能依靠平时的校正结果来手动调整词条，降低误伤率。

所以可以看成这个脚本帮你做了一份 80-90 分的考卷（95 分以上也是有可能的），你需要做的工作就是在 beyond compare 里进行批改（以及根据被误改的词条来对词库文件进行增删改等调整），这样的“改试卷”和在 txtFormat 里手动“做试卷”比较起来，个人觉得在效率上还算是有一定提升的。

另外这个程序是直接就地修改覆盖了原文件，在使用之前一定要先备份，要先备份，要先备份。

beyond compare 论坛内下载地址：
http://www.1000qm.vip/forum.php?mod=viewthread&tid=42400
这个帖子里的倒数第二个附件。

其他详细校对流程，参考：epub 校对教程
推荐把本帖和上面这篇结合看一下，能更好理解个人进行 txt 和 epub 文件校对的思路（虽然很长很啰嗦）。



ps：整理这份替换表的时候真是见识了部分作者的 typo 能力，永远不知道他们能写出什么错别字。

也学习到了不少现代汉语的规范用法，感兴趣的可以用这个脚本去处理一些论坛内或者其他书源站的文本，可能会出现不少你没想到的纠错（当然也会有误改和无需更改的地方，务必使用 beyond compare 进行确认）。

！！校对表内容会有不定时更新，可以留意本帖最后编辑时间及最新附件上传时间！！

edennow

更新记录【2023】
传送门

更新记录【2024】
1 月 2 日版本更新，继续完善替换表，新增了 “postFixMap”校正后置词库，
以及“书籍专有替换词库”，详情请见上面的“修改校正表说明”一节。
（请在本页面搜索 ⑤$postFixMap 和 书籍专有替换词库.php 查看说明）

1 月 13 日版本更新，将 txtFormat 词库中的四字词条做了基本的筛选（我觉得没用的都没加进来），整合进了自定义词库中。
目前自定义词库的词条数量已超 5.5 万，基本覆盖了 txtFormat 中的四字词条（我认为），不过其中可能也有不少词条需要根据书籍实际校正情况，自行进行删减。
另外，txtFormat 中的三字和二字词条（约 4.5 万条）较容易产生混淆，以后看情况随缘整合吧。

3 月 19 日版本更新，执行 【双击运行】1.书籍校正.bat 前，提供【是否需要进行额外的标点符号修正】的选项。
请详细看一下命令行的提示信息，可自行尝试不同选项，以确认各选项的修正效果，之前是强制执行这部分标点符号修正的。

3 月 24 日版本更新，新增 csv 格式的词库转换功能，具体内容见 85 楼。

4 月 3 日更新词库，优化操作流程，以便于调用多种词库进行多轮校对。

经过粗略测试多本网文的校正效果，目前脚本的自动修正基本能达到 txtFormat 【有效】手动操作（排除掉 TF 那些乱七八糟的误改） 80%-90% 的效果（还会额外做出很多 txtFormat 默认词库没有的修正）。

在目前优化的操作流程中，可以在选用【自定义词库】完成第一轮校正后，再输入 1 进行第二轮校正，
并在此轮校正中选用【txtFormat 词库】来校正，结果相当于将 txtFormat 中的每个错别字修改都应用了“全部替换”（等于是在 txtFormat 中做了 100% 的修正操作）。

此外，还可以通过【的地得词库】【繁转简词库】等继续进行多轮校正，每轮校正都只会在 BC 中看到当前选择词库的修改效果。

4 月 5 日更新词库，词条新增“replaceHolder”（随意造的词）设置，可用于进一步折叠词条，便于扩展不同的前缀后缀等（尤其是一些“的地得”的词条）。
不过该设置的操作比较复杂，等同于将 (开心|高兴|振奋)的(说着|笑着) 这样的正则通过脚本自动展开成“开心的说着”“开心的笑着”“高兴的说着”“高兴的笑着”……这样一批词条。
以后有空再详细说吧，如果在词库中见到有“@”，以及 replaceHolder 字段的词条，先无视就可以了。
如果感兴趣也可以拉到 $normalMap 的最后，搜索一下“付诸实践”，在那个词条的位置附近有写一些注释说明，可供理解参考。

4 月 15 日更新词库，部分替换频率比较高的词（不少是可改可不改的）加了一些基于个人理解和查证的注释说明（例如“不承想”“按捺”“喑哑”“捱”“化装”“眼力见”“门闩”“脚指头”“定制”“的一声”“的一下”“藉以”等），增删词条前可以先在自定义词库中进行搜索参考，避免重复劳动。
另外如果有些词搜不到，应该是被 regexMap 里的那十几条正则给改了，也可以稍微熟悉一下那些正则，根据个人需要进行调整，目前数量并不算多。

edennow

cumt313 发表于 2023-11-17 21:14
楼主，再帮我看一下呢，这究竟是怎么回事？我在公司能用，回到家用自己的电脑就不行。

已知问题 1：
windows 下如出现 PHP Warning...vcruntime140.dll... 相关报错信息，应该是 windows 库文件过时所致。


在这个页面：https://visualstudio.microsoft.com/zh-hans/downloads/
找到这个，下载装一下试试（64 位系统要装 x64，不行就装 x86 试试，反之亦然）。


已知问题 2：
windows 下如出现类似乱码界面：


应该是 cmd 的默认编码不支持中文内容导致的，可参考这个链接：
https://blog.csdn.net/B11050729/article/details/131463516
进行一些设置。
推荐先在乱码的界面右键一下标题栏，进入 cmd 设置，然后更改一下字体，换成如图所示的宋体或者 simsun（实际也是宋体）之类的自带系统中文字体试一试：

阳方十月

这个脚本运行后我界面都是这样的老哥

無愛

edennow 发表于 2024-4-24 22:03
没关系，我写了脚本来自动查重和整合的，晚点再处理下就好了，不过其中有些区分比较细的词条可能会先放到 ...

OK，不会增加你的工作量就好。

edennow

無愛 发表于 2024-4-24 21:47
整理了300条左右的新词条，不知道有没有重复的
看了下，词库还是4月4号的

没关系，我写了脚本来自动查重和整合的，晚点再处理下就好了，不过其中有些区分比较细的词条可能会先放到新增的 strictMap 里面，也可以先了解下最新的说明哈。

無愛

edennow 发表于 2024-3-30 07:52
我也找了几本书来试了一下，其实它分词的结果基本算是比较准确的，不过可能是我不怎么了解细节，感觉确实 ...

整理了300条左右的新词条，不知道有没有重复的
看了下，词库还是4月4号的

edennow

破晓陨星沉 发表于 2024-4-18 21:26
对于脚本的运作，我有一个疑问：
我在词库里看到有一些条目前后完全一样的内容，比如
    ['before' => " ...

是这样的，其实你在当前页面搜一下帖子内容就能看到了：“可以通过设置 before 与 after 值相同的词条”。
那里有比较详细的说明，还有另外几条规则也可以详细理解一下。

就是可以通过先规定所有 "干个世纪"要改成“下个世纪”，然后再通过“若干个世纪->若干个世纪”这样的设置规定碰到这部分例外词条就保持原样。

这就类似于防火墙，先挡住所有的流量，然后通过白名单，放一些例外的流量进来。

目前在自定义词库那个文件里面，用正则搜一下：'before' => "(.*?)", 'after' => "\1" 这样的内容，就能看到很多这种防止误改的词条了。
当然这样也会导致有些词条漏改一些内容，不过主要是为了提升相关词条的正确率，也还算划算。

破晓陨星沉

对于脚本的运作，我有一个疑问：
我在词库里看到有一些条目前后完全一样的内容，比如
    ['before' => "干个世纪", 'after' => "下个世纪"],
    ['before' => "若干个世纪", 'after' => "若干个世纪"],
是不是所有的替换都是同时进行的？
这样就能达成“若干个世纪”就不变，别的“干个世纪”就变成“下个世纪”这个效果？

破晓陨星沉

破晓陨星沉 发表于 2024-4-18 11:58
我今天试了一下15号的脚本，发现了一些问题，整理了一下，请参考

感谢  楼主威武

edennow

破晓陨星沉 发表于 2024-4-18 11:58
我今天试了一下15号的脚本，发现了一些问题，整理了一下，请参考

非常感谢反馈。

其中《》、《》和《》，《》中间标点的问题，可以参考一下目前的标点符号规范，如果是并列的名词或者书名，这中间最好是不放逗号或者顿号。

如果书名号（或引号）之间是顿号，我认为 99.99% 都是在罗列一些并列的名词，比如《三国演义》、《红楼梦》、《西游记》，“一级联盟”、“二级联盟”、“三级联盟”这样的，因此顿号我是直接删掉了，在 bc 里也没有显示出这个修改。

但如果书名号（或引号）之间是逗号，确实会碰上：“他写了一本《水浒传》，《水浒传》从此家喻户晓，流传至今”这种实际上不应该删除中间逗号的情况。目前也没有办法做到很好的检测，只能是把对逗号的修改在 bc 里显示出来，供用户自行判断。

如果是不需要参考这样的规范的，可以直接把：

    ['before' => "”，“", 'after' => "”“"],
    ['before' => "’，‘", 'after' => "’‘"],
    ['before' => "》，《", 'after' => "》《"],

这几条从 normalMap 的顶部删掉就可以了，特别是一些标点符号使用较为规范的书，发现去除引号中间的逗号会有比较多的误改，那就最好把这个修改从词库里去掉再执行。

其他一些关于的地得误改的反馈也很有效，其中有些词条是我加的时候偷懒了（比如“地音调”改成“的音调”），有些例外的情况还没来得及考虑，后续会进行一些补充。

不过按目前这种机械的做法，如果想提高一些词条的辨识度，就只能加上一些前缀后缀，把一个词条拆成几个带其他限制字符的词条了，而一旦这么加，有些词条的替换能力就会被限制，导致同一种错误会有部分漏改。
而且有一些词条，即使再补充很多的例外情况，通过类似“暴发户->暴发户”这种防误伤词条进行覆盖，或者加前缀后缀，也还是会产生一些误改的，因为“能改得多的必然改错的也多”“能错得少的基本能改的也很少”。

所以目前感觉有些词条（以及正则，特别是“带”“戴”修复的那两条）还是需要做一些权衡，可能在某些情况下还是允许一些词条有误改的存在，会在加词条的时候省事一点（否则就只能把这些词条彻底删掉不改了），用户在 bc 对比结果的过程中进行一些手动修复目前看是必不可少的。

如果想避免用这个脚本跑同一本书，每跑一次就误改一次，可以考虑按照帖子里的“书籍专有替换”那部分的写法，把特定书籍的一些错误记录下来，就不会反复被误改了（当然太水的书就没必要这么大张旗鼓了哈哈）。
我感觉这种做法还是挺有效的，我也自己加了挺多本书的特定误改词条，节省了不少重复修复误伤的劳动。而且通过写这样的记录，可以总结出一些词条的误改情况，对词库做一些补充。