KDiff3에 영향을 미칠 중국어 유니 코드 문자 稍 및 Any에 대한 이상한 점은 무엇입니까?

Question

버그를보고하고 KDiff3 사이트 (https://sourceforge.net/p/kdiff3/bugs/198/)에서 지원 요청을 입력했는데, 내가 본 행동에 대해 다른 사람이 나에게 그러한 버그가 존재하는 이유를 이해하게 할 수도있는 프롬프트 정보가 있는지 궁금합니다. -이 유니 코드 문자에 이상한 것이 있으면.

KDiff3 버전 0.9.98을 사용하여 문자가 포함 된 두 개의 동일한 파일을 병합하면 문자가 as로 읽히고 병합의 모든 창에 해당 문자가 표시됩니다. 그 결과 출력에는  대신 해당 문자가 포함됩니다.

내가 KDiff3 버전 0.9.98에서 UCS-2 리틀 엔디안 인코딩이 동작을 관찰하지만 UTF-8 인코딩 및 하지 버전 0.9.96a Kdiff3의 버전 함께 제공 한 TortoiseHg. 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, 0x7a 및 0x0a, 0x7a이됩니다. 0x0d의 8 비트 문자는 Return의 ASCII 코드이며 0x0a은 Linefeed의 코드입니다. KDiff3은 이러한 바이트를 라인 끝으로 해석하고 Return을 만나면 Linefeed를 대체하는 것으로 보입니다. 이는 파일에서 일관되지 않은 줄 끝을 나타내는 오류 메시지가 보고서에 의해 확인됩니다.

유니 코드로 작업 할 때 종종 UTF-8 인코딩을 사용하는 것이 좋습니다. U + 007f 위의 문자는 여전히 1 바이트 이상을 차지하지만 각각의 바이트는 0x80 이상의 값을 가지며 우연히 ASCII 문자 중 하나와 오인 될 수 없습니다. 예를 들어 稍는 0xe7, 0xa8, 0x8d이됩니다.