贡士
- UID
- 155378
- 积分
- 2986
- 回帖
- 1016
- 主题
- 67
- 铜币
- 44843
- 威望
- 2439
- 银币
- 0
- 贡献
- 0
- 发书数
- 57
- 注册时间
- 2023-6-14
- 最后登录
- 2024-5-6
- 在线时间
- 1540 小时
|
楼主 |
发表于 2024-3-18 06:22
|
显示全部楼层
本帖最后由 edennow 于 2024-3-18 19:07 编辑
花了点时间把提供的这批词条整理了一下,感觉可用性挺不错,只有少数十几二十条我没有直接加进去,非常感谢,可以下载一下新的附件看看。
另外提供一些建议:
首先是少量词条的长度和辨识度个人感觉不是很够,特别是 2 个字的。
例如:好勒->好嘞
如果是通过人工搜索这两个字来替换,相信可以很容易一条条判断哪些要改哪些不要改。
但是加到脚本的词库里的时候,由于校正过程是自动的,没有人工介入,只能通过 bc 比较校正后的结果。
如果单纯只提供这两个字,就会造成文本中所有的“好勒”都变成“好嘞”,
要是文本中有“刚好勒住”“恰好勒住”这种词,就都会被误改,而且是每碰到一次有这样的词语的书,就被误改一次。
根据这个词的常见用法和特征,可以判断基本都是位于一个句子成分的结尾,那就可以拆分成:
['before' => "好勒,", 'after' => "好嘞,"],
['before' => "好勒。", 'after' => "好嘞。"],
['before' => "好勒!", 'after' => "好嘞!"],
这样几组词,这样的话“刚好勒住”“恰好勒住”这种就不会被误伤到。
意思就是把词条加入这个脚本词库的时候,还是需要尽量提升一些辨识度(不光是可以加标点,也可以加前缀后缀,从一条变成多条,当然改成正则表达式也可以,但执行效率会变低,反而不如直接堆放到 normalMap 里)。
上面的例子虽然从一条词条变成了三条,但因为是自动改正,不需要耗费精力去重复人工检索替换,所以也不会影响操作效率。
暂时是推荐尽量堆词条而不是正则,只要不是需要把一个词条拆成几十上百条这种无法接受的数量,都是一次性劳动,设置好一次之后就可以生效了。
即使可能会比直接用 好勒->好嘞 这样改得少了点,但是提升了正确率,也就不用在 bc 里面一条条把误改项还原回去。
同理还有 陈恳->诚恳 这种,我也拆分成了几条词条,如果文本中碰到有人的名字是陈恳,也能尽量减少一些误伤。
当然如果不把这样的 2 字词条拆成多条,直接就用它来校正也可以,这样会改得更多一点(虽然可能会额外有误伤)。
是否需要拆分还是要根据这个词的特性(比如 陈恳 这种,100 本书里面可能也不会碰到一本有名字叫陈恳的角色),
以及个人的偏好来进行一些取舍,暂时没有什么权威标准。
我之前整合 txtFormat 的词库就发现了,它的词库里面 4 个字的词条辨识度远比 2 个字和 3 个字的高,直接加入到脚本里面也不会增加多少误伤。
而 2 个字和 3 个字的词条反正我是不敢直接弄过来,不然 bc 比较的时候改误伤项会很麻烦(可以回忆一下平时用 txtFormat 是不是经常要跳过误改词条,疯狂点“下一个”……)。
总之就是这个脚本是全自动修正的,是旨在把一些确定性高的词条在进一步校对前,提前做好修正,然后通过 bc 进行对修正结果的确认。
即使比人工用 txtFormat 修正改得要少(也有可能会改得更多),但是操作体验应该是比单纯在 tf 里点点点会有提升。
主要是得实际校正比对几本书,多体验一下,可能就能理解一些词条怎样设置效果才会比较好了(以及需要尽量阅读理解一下帖子里提到的几条词条设置的规则,最好能理解类似“暴发户->暴发户”这种 before 和 after 值相同的词条能起什么作用)。
——————————
第二个是新增词条的存放位置,我看还是被单独放到了 preprocessMap 里面了,应该是还没有看到这个帖子里“预处理流程”的逻辑吧。
简单说明一下,同一个词条可以“同时放到 preprocessMap 和 normalMap 里”,也可以“单独只放到 normalMap 里”,
但是不能“单独只放到 preprocessMap 里”,需要保证 preprocessMap 里的词条一直都是 normalMap 词条的子集,否则会造成混淆。
“单独只放到 normalMap 里”的那些词条在预处理的时候不会被用到 booksBak 的文件里,在 beyond compare 比较的时候是能看到这些词条的校正结果的。
“同时放到 preprocessMap 和 normalMap 里”的词条则会在 booksBak 的文件中也进行修正,这时在 beyond compare 比较的时候,就根本看不出来文件实际上已经被改过了。
“单独只放到 normalMap 里”的词条,等于是“我改了这个词,我也会在 bc 里面告诉你我改了它”。
“同时放到 preprocessMap 和 normalMap 里”的词条,则等于“我改了这个词,但我在 bc 里不会直接告诉你”。
所以除非你非常确定这个词条不会在任何情况下被误改(或者只有在极少数情况下才会误改),否则尽量不要放到 preprocessMap 里,而是单独堆到 normalMap 里面就好,这样可以比较好在 bc 里确认有没有被误改。
还有就是在这两个 map 中新增词条的时候,最好是都跟着放到这两个 map 的末尾,可以参照下面的两张图(注意'挨'在这个文件里有两个相同的词条,分别是在 preprocessMap 和 normalMap 里的,不要找错了):
这样可以把你自己加的词条和我这边加的词条区分开来(我一般会在原词条的位置直接加,位置比较随机),如果后续有词库更新的话,可以通过 bc 对比,较容易地看出我做的词条增改和你自己做的有什么差异,同步一些词条的增删改操作。
也可以在我这边更新词库的时候,直接把这两个地方后面的自己加的词条统统移到新的词库文件里面,而不用详细看我改了什么,这样起码能保证自己新加的词条一直是有效的。
对在这两个位置上方的词条,最好只做删除或注释的操作,让不需要的词条失效;
下方则只放置自己新增的词条(或者是把上面的词条删掉,自己在下面新增一个对应的映射,等于是更改了 before 的值,属于更新词条)。
新增词条之前建议先搜索下这个文件里有没有你需要的词,例如“无瑕”“无暇”这种我已经收集了不少可以用来校正的词条,可以先参考下,避免重复劳动。
——————————
还有个问题是词条里面不要出现 CJK 扩展区的字符,比如【尸从】这种(即使要加相关词条,也应该用本来的那个未简化字),否则在 bc 里面会报编码错误,无法编辑(文件编码会被脚本默认转成 UTF-8)。
因为这个脚本会把文件都统一处理成“UTF-8 无 BOM 的编码,以 LF(也就是 \n) 为换行符”的形式。
如果是执行 【双击运行】1.书籍校正.bat,会自动转码,无需关心(可以在校正和确认完后,自己把文件编码恢复成所需的中文编码)。
但如果执行【双击运行】2.书籍校正(不进行原文件预处理).bat 且本来的文件编码不是 UTF-8,最好在 bc 比较前把编码都统一改成 UTF-8 无 BOM,否则也有可能出现一些奇奇怪怪的问题。
只要是那种看上去有点奇怪的简体字,和电脑里的默认字体长得都不一样的,基本都是扩展区的字符,如果无法准确判断,可以查询汉典:
https://www.zdic.net/
出现了这种带有“扩展”两个字的,就是 CJK 扩展区中的字符,最好就不要采用了,这样的字符貌似很多都不在规范的汉字表里(http://www.jiaodui.com/bbs/read.php?tid=22867 这里也有说),目前有些阅读器的字体也是不支持完整的扩展区字符,而出现缺字的空白,兼容性比较差。
——————————
额外提一下,如果你会在手机平板等移动设备记读校笔记/批注/高亮,然后再统一在某个时间点改文本的话,不妨参考一下这个帖子:
随时随地进行校对
如果可以按照里面说的格式来记笔记(辨识度要尽可能高),也可以利用这个脚本,做到一键修正成百上千条笔记,应该能提升一些读校的效率(如果你是直接在电脑上边读边改文本的,就不用参考了……)。
当然,欢迎随时提出意见和分享新的词条,我尽量都会根据实际情况整合到词库里。
|
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有账号?立即注册
x
|