我已经报告了一个错误并在 KDiff3 站点 （https://sourceforge.net/p/kdiff3/bugs/198/） 上输入了支持请求，但我想知道是否有人对我所看到的行为有任何提示信息，这可能会让我理解为什么可能存在这样的错误——如果这些 unicode 字符有任何不寻常之处。
当我使用 KDiff3 版本 0.9.98 合并两个包含字符稍的相同文件时，它将字符读取为稊，并在合并的所有窗格中显示该字符。然后，输出包含该字符而不是稍。
我在 KDiff3 的 0.9.98 版中观察到了 UCS-2 Little Endian 编码的这种行为，但没有使用 UTF-8 编码，也没有在 TortoiseHg 附带的 Kdiff3 版本 0.9.96a 中观察到这种行为。虽然我可以在 0.9.96 和 0.9.97 中重现该问题，但 TortoiseHg 的 KDiff3 报告它是版本 0.9.96a，并且没有出现该问题。
编辑：我隐约怀疑问题的根源在Qt库中的某个地方。因此，任何关于Qt在处理国际文本方面所做的事情的信息都可能是有用的。
处理文本文件的实用程序需要将文本分解为字符才能有效运行。最简单的过程是将每个 8 位字节视为单个字符。不幸的是，这不适用于 UTF-16 或 UCS-2 输入，因为每个字节只是字符的一半。
您遇到问题的字符是稍（U+7a0d），它正在转换为稊（U+7a0a）。当您将它们分解为小端字节时，您会得到0x0d, 0x7a和0x0a, 0x7a。8 位字符0x0d是返回的 ASCII 代码，0x0a是换行的代码。似乎 KDiff3 将这些字节解释为行尾，并在遇到返回时替换换行。这已通过您指示文件中行尾不一致的错误消息报告进行验证。
Unicode 时，通常最好使用 UTF-8 编码。U+007f 以上的字符仍将占用多个字节，但每个字节的值为 0x80 或更大，并且不会意外误认为是其中一个 ASCII 字符。例如稍变成0xe7, 0xa8, 0x8d。