bard99

@mw2c #15 @tabris17
我刚才做了几个实验，猜测找到了原因：

我使用 WPS 先生成 word ，再将 word 转成 PDF 。使用的是思源宋体：


然后使用 Python 脚本读取 PDF 内容和 Unicode 编码值：

发现 WPS 生成 PDF 的文字是正常的「 4e59 」编码！

对比之下，我之前使用 itext 生成的 PDF 。使用的是思源宋体：

使用 Python 脚本读取 PDF 内容和 Unicode 编码值：

这个 PDF 的文字是异常的「 2f04 」编码！

所以猜测可能就是 itext 的 bug：
1. 对于共用字型的字体，如：2f04 和 4e59 ，字型为「⼄」和「乙」。
2. itext 程序的 bug ，导致了在使用 html 生成 PDF 的过程中
3. 首先 html 文本传入的是 4e59 ，然后 itext 根据 4e59 找到了字体「乙-2f04/4e59 」
4. 然后写入生成 PDF 的过程中，使用了「乙」的字型，但错误的使用了 2f04 的 Unicode 编码！
a. 对于 WPS 来说没有这个问题，会使用 4e59 的 Unicode 编码。
5. 所以原因，还是 itext 的问题！ [至于具体的原因，还得 debug 去看了；看了半天没看出来逻辑在哪里...] ！
a. 初步推测，itext 根据 4e59 找到了字体「乙-2f04/4e59 」，然后写入 PDF 时写入了「乙-2f04 」，很可能就是获取了第一个 Unicode 编码值！而 WPS 可能是写入了「乙」，然后 Unicode 编码值则从原始文本获取，这样就关联正确了！

@tabris17 #14 刚用 fontstore 试了狮尾四季春、SiHei 字体，发现他们都没有给 2F04 编码添加字型！所以这 2 个字体生成的 PDF ，文字都是正常的，都是 4E59 编码的「乙」！

@mw2c 这 2 篇文字涨知识了，感谢。然后我本地试了一下 4 种正规化的结果，打印如下： 。

这个结果看上去，好像可以得出：
- 只有「部首」字符（如：2f04 ）在正规化后，可以变成正常的「单音」字符（如：4e59 ）。
- 而「单音」字符的正规化，得到的仍然是它本身。

如果这 2 个结论对的话，在我的场景里，却是「单音」字符，转换后得到了「部首」字符，那就不符合这个结论了。

@NessajCN #9 感谢指正，试了下确实如你所说。 实际上我中间省略了一些过程，我是 debug 过程中，使用 itext 的 PdfReaderContentParser 读取生成后 PDF 文件，然后取出文本内容，在这里拿到了异常的 ⼄⽅ u2f04 。

@tabris17 #6
看到了，果然共用了字型！

@tabris17 难道上面截图里，表示的是 2f04 引用了 4e59 的字型？感觉可以说得通啊！

@NessajCN 直接复制 PDF 的文本出来，然后就可以查询了：
我帖子里用的是 birdfont： https://birdfont.org/

@tabris17 大佬，怎么看是共用了一个字型呢？

回帖：自动纠正关了后，出现频率确实有下降。现在是几周出现 1 次😂，解决办法还是进程里面 kill 掉简体中文输入法。
问题肯定是这个输入法有问题。
同事换搜狗输入法后没出现这个问题，我不想换🤣