WinMergeで文字化け!? 半角中点と文字コード誤判定の罠
はじめに
Shift_JIS（CP932）で保存されたはずのテキストファイルをWinMergeで比較しようとしたとき、
「エンコーディングエラーにより情報が失われています」
というエラーが表示され、文字化けが発生したことはありませんか？
今回のケースでは、その原因が "半角中点"（0xA5） によるものでした。この記事では、この現象の原因を追いながら、文字コードとツールの仕様の落とし穴について紹介します。
事象の概要
- CP932で保存されたテキストファイルに、半角中点（0xA5）を含む
- WinMergeでファイルを比較しようとしたところ、エンコーディングエラーが発生
- 該当ファイルを編集し、半角中点を削除して再度読み込ませたところ、文字化けが解消
原因の正体
一見、CP932でも0xA5はちゃんと「半角中点」として定義されています。
| バイト列 | 文字 | 備考 |
|---|---|---|
0xA5 |
･ |
半角カタカナの中点 |
では、なぜエラーになるのか？
その答えは、WinMergeの文字コード自動判定ロジックにあります。
キーポイント：0xA5の後続バイト
WinMergeは、ファイルのエンコーディングを自動判別する際に、バイト列のパターンを元にUTF-16などと誤認識することがあります。
例：A5 83
この2バイトが並ぶと、UTF-16BEで見たときは 0xA583 というコードポイントになります。
0xA583 は Unicode の私用領域（PUA）に属しており、環境によっては表示できなかったり、不正扱いされたりします。
その結果、WinMergeは
- UTF-16BEとして解釈 → 不正なコードポイントと判断
- 「エンコーディングエラー」として処理を中断、または文字化け
という挙動をしていたわけです。
検証と再現性
実際に以下のような処理で再現できました：
- 半角中点を含むCP932ファイルを作成（例：
A5 83） - WinMerge（特定バージョン）で比較
- エラー発生
- 半角中点（0xA5）だけ削除 → 正常に比較可能に
つまり、問題は半角中点そのものではなく、その後続バイトとの組み合わせによるUTF-16BE誤判定が原因だったのです。
回避策
- ファイルの先頭にASCIIコメント等を追加し、誤判定を避ける
- 半角中点（
･）を全角中点（・）に置き換える - UTF-8（BOM付き）へ一時変換してから比較する
- 他の比較ツール（例：Beyond Compare、Meld）を使用する
おわりに
文字コードの問題は、一見ただの文字化けに見えても、
- ツールの仕様
- 自動エンコーディング判定のアルゴリズム
- バイト列の偶然の並び
など、複雑な要因が絡んでいることが多いです。
今回のように、**一見普通の文字（中点）**が原因でツールが誤動作するケースもあるので、
「エンコーディングエラーが出たら、ファイルの中身（バイト列）を疑う」
という視点を持っておくと、トラブル対応が格段に楽になります。
この記事が、同じような問題で悩んでいる方の助けになれば幸いです！