WinMergeで文字化け!? 半角中点と文字コード誤判定の罠

はじめに

Shift_JIS（CP932）で保存されたはずのテキストファイルをWinMergeで比較しようとしたとき、

「エンコーディングエラーにより情報が失われています」

というエラーが表示され、文字化けが発生したことはありませんか？

今回のケースでは、その原因が "半角中点"（0xA5） によるものでした。この記事では、この現象の原因を追いながら、文字コードとツールの仕様の落とし穴について紹介します。

一見、CP932でも0xA5はちゃんと「半角中点」として定義されています。

バイト列	文字	備考
`0xA5`	`･`	半角カタカナの中点

では、なぜエラーになるのか？

その答えは、WinMergeの文字コード自動判定ロジックにあります。

WinMergeは、ファイルのエンコーディングを自動判別する際に、バイト列のパターンを元にUTF-16などと誤認識することがあります。

例：A5 83

この2バイトが並ぶと、UTF-16BEで見たときは 0xA583 というコードポイントになります。

0xA583 は Unicode の私用領域（PUA）に属しており、環境によっては表示できなかったり、不正扱いされたりします。

その結果、WinMergeは

という挙動をしていたわけです。

実際に以下のような処理で再現できました：

つまり、問題は半角中点そのものではなく、その後続バイトとの組み合わせによるUTF-16BE誤判定が原因だったのです。

文字コードの問題は、一見ただの文字化けに見えても、

など、複雑な要因が絡んでいることが多いです。

今回のように、**一見普通の文字（中点）**が原因でツールが誤動作するケースもあるので、

「エンコーディングエラーが出たら、ファイルの中身（バイト列）を疑う」

という視点を持っておくと、トラブル対応が格段に楽になります。

この記事が、同じような問題で悩んでいる方の助けになれば幸いです！