对于字体解析的建议

[iHamsterball]

由于涉及到晋江的油猴脚本项目需要处理晋江VIP章节的字体问题，所以曾经借助和参考了此项目的字体处理机制。 之前观测到晋江开始换字体后，手动修改必然是不可能的，所以曾经做了一个粗糙的对照表生成工具，目标格式与此项目的一致。 因为使用情形不同，所以到此为止，后来使用Javascript的fontkit在油猴脚本内单独实现了一遍，脱离了手动操作。 对于此项目而言，仅需少量修改即可使用，我认为是比使用外部服务更快速更可靠的实现。

[7325156]

我的新版本反爬虫是直接取晋江上https://jjwxc.yooooo.us/jjwxcfont_00gxm.json 里的内容。 我看了看你的项目，你的反爬虫信息似乎是放在pickle文件里，生成pickle文件的程序里有一个读取json格式文件，问题来了，这个json文件的来源是什么？（我在你的项目里没找着）还是说晋江还有什么不为人知的反爬虫信息？

[iHamsterball]

那个json是我自己项目里用到的，就是从你txt的对应表生成的，本质上就是一个对应关系。 如果能找到晋江那边用来修改的原始的字体，看起来大概是某个版本的微软雅黑，那么直接对这个字体进行处理生成一个完整CodePoint对Glyph的关系是最好的，能直接拿到正确的所有汉字的CodePoint对应Glyph的关系。 不过显然我没做到，所以用了替代的办法多加了一层。 一个典型的jjwxcfont字体：修改的CodePoint -> 一个Glyph 已知的对照表：修改的CodePoint -> 正确的汉字 目标是：（正确的汉字 -> 这个字的CodePoint）-> 修改的CodePoint -> 这个字的Glyph 这样就在没有原始的字体文件的前提下拿到对应关系，用于所有基于这个原始字体生成而来的反爬虫字体的反反爬虫解析。

[7325156]

https://github.com/yingziwu/jjwxcFontTables 我觉得可以参考这位大佬的方案。

---原始邮件--- 发件人: @.> 发送时间: 2021年9月4日(周六) 晚上7:26 收件人: @.>; 抄送: @.**@.>; 主题: Re: [7325156/jjwxcNovelCrawler] 对于字体解析的建议 (#11)

那个json是我自己项目里用到的，就是从你txt的对应表生成的，本质上就是一个对应关系。 如果能找到晋江那边用来修改的原始的字体，看起来大概是某个版本的微软雅黑，那么直接对这个字体进行处理生成一个完整CodePoint对Glyph的关系是最好的，能直接拿到正确的所有汉字的CodePoint对应Glyph的关系。 不过显然我没做到，所以用了替代的办法多加了一层。 一个典型的jjwxcfont字体：修改的CodePoint -> 一个Glyph 已知的对照表：修改的CodePoint -> 正确的汉字 目标是：（正确的汉字 -> 这个字的CodePoint）-> 修改的CodePoint -> 这个字的Glyph 这样就在没有原始的字体文件的前提下拿到对应关系，用于所有基于这个原始字体生成而来的反爬虫字体的反反爬虫解析。

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[iHamsterball]

你可以参考任何你认为有用的方案。 我的方案的侧重点在于你可以完全信任Glyph的点阵的匹配结果，它是绝对可靠的，而晋江用于生成反爬虫字体的原始的字体是不必要的。 我看了 https://yooooo.us/2021/solve-custom-font-auti-crawler 和 https://github.com/yingziwu/jjwxcFontTables 的处理过程，他们都采用了OCR，原因就是他们没有找到原始的字体。而OCR带来的诸多错误在你来回修改对应表时应该已经体会过了。

[7325156]

也对，毕竟天知道晋江用的什么字体。

---原始邮件--- 发件人: @.> 发送时间: 2021年9月4日(周六) 晚上7:38 收件人: @.>; 抄送: @.**@.>; 主题: Re: [7325156/jjwxcNovelCrawler] 对于字体解析的建议 (#11)

你可以参考任何你认为有用的方案。 我的方案的侧重点在于你可以完全信任Glyph的点阵的匹配结果，它是绝对可靠的，而晋江用于生成反爬虫字体的原始的字体是不必要的。 我看了 https://yooooo.us/2021/solve-custom-font-auti-crawler 和 https://github.com/yingziwu/jjwxcFontTables 的处理过程，他们都采用了OCR，原因就是他们没有找到原始的字体。而OCR带来的诸多错误在你来回修改对应表时应该已经体会过了。

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[iHamsterball]

勘误：https://github.com/fffonion/JJGet 是用坐标对照的，博客末尾有说。

[iHamsterball]

那么是我多此一举了，他的思路是跟我一样的。 不过我仍然建议将处理过程放到你的项目内而不是依赖一个第三方的接口来执行。

[7325156]

非也非也，每一份贡献都是宝贵的，至少你比我牛批，我一看点阵就完全不想玩。 （其实我根本不想做反爬虫，直接把字体一下载，epub一加载，既省精力，效果又好，爽的一批，奈何大家都喜欢TXT……）

---原始邮件--- 发件人: @.> 发送时间: 2021年9月4日(周六) 晚上7:46 收件人: @.>; 抄送: @.**@.>; 主题: Re: [7325156/jjwxcNovelCrawler] 对于字体解析的建议 (#11)

那么是我多此一举了，他的思路是跟我一样的。 不过我仍然建议将处理过程放到你的项目内而不是依赖一个第三方的接口来执行。

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[iHamsterball]

嗯……epub这么搞能看，但是默认字体不是微软雅黑/方正兰亭黑时还是能看出来字体不一样的，我那边油猴脚本是网页换了个字体所以更明显。至于txt的话，我也是标题加markdown的标题tag，然后所有误用的半角符号和能看到的屏蔽词改改扔给Calibre转azw3扔给安卓的Kindle应用。

[7325156]

所以可以得出以下结论：其他手段得出的对照表总有小bug，最终还是要靠人肉校对……行叭，兜兜转转又绕回来了，但起码可以减轻工作量……

[iHamsterball]

讲道理爬虫跟反爬虫简直没完没了，这回搞完反反爬虫他们明天再来个反反反爬虫。 而且由于反爬虫的核心在于只要增加爬虫这边的解析成本就算赢，所以永远要容易些。 就说这个，只要他晋江明天对每个字体的点阵做一个随机微调，这边点阵匹配就得开始算偏移量。