qt - 中文 unicode 字符有点和稊有什么奇怪会影响 KDiff3 的吗？

Question

我报告了一个错误并在 KDiff3 站点 ( https://sourceforge.net/p/kdiff3/bugs/198/ ) 上输入了一个支持请求，但我想知道是否有人对我的行为有任何提示信息看到这一点可能会让我理解为什么会存在这样的错误——如果这些 un​​icode 字符有什么不寻常的话。

当我使用 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 在处理国际文本方面所做的事情的信息都可能有用。

Answer 1

处理文本文件的实用程序需要将文本分解为字符才能有效运行。最简单的可能过程是将每个 8 位字节视为单个字符。不幸的是，这不适用于 UTF-16 或 UCS-2 输入，因为每个字节只是字符的一半。

您遇到问题的字符是稍 (U+7a0d)，它正在转换为稊 (U+7a0a)。当你把它们分解成小端字节时，你得到0x0d, 0x7aand 0x0a, 0x7a。8 位字符0x0d是返回的 ASCII 码，0x0a也是换行的代码。KDiff3 似乎将这些字节解释为行尾，并在遇到返回时替换换行符。这可以通过您报告的错误消息来验证，该错误消息指示文件中的行结尾不一致。

使用 Unicode 时，通常最好使用 UTF-8 编码。U+007f 以上的字符仍将占用一个以上的字节，但这些字节中的每一个都将具有 0x80 或更大的值，并且不会意外地被误认为是其中一个 ASCII 字符。比如有点变成了0xe7, 0xa8, 0x8d。