WinMergeの文字コード（エンコーディング）を変更する方法｜設定手順と注意点まとめ

この記事でわかること

WinMergeで文字化けを直すために、「開く時」「比較する時」「保存する時」「既定設定」をどこで切り替えるかを、作業の順番どおりにまとめます。

特に、UTF-8（BOMあり/なし）とShift_JIS（CP932）が混在する現場で起きやすい

• WinMergeだけ表示が崩れる（メモ帳やVS Codeでは正常なのにWinMergeでは化ける）
• 差分が大量に出て読めない（文字コードの誤認に加えて改行・空白差が混ざる）
• 保存したら別アプリで開けなくなった（Excelで文字化け、区切りが崩れる）

といった状況を想定し、原因の切り分けから再発防止までを一気通貫で扱います。

同じ「文字化け」に見えても、原因は大きく3つに分かれます。

• 1) 読み込み時の誤判定（開き方の問題）
• 2) 保存時のエンコーディング不一致（次回再発する問題）
• 3) 表示フォントや不可視文字（文字コード以外の問題）

この記事では、闇雲に設定をいじるのではなく「今はどれが原因か」を短いチェックで当てて、最短手数で直す流れにします。

結論：まずは「個別に開く時の指定」→次に「保存時」→最後に「既定」

まずは該当ファイルだけを指定の文字コードで開き直すのが安全で、影響範囲を最小にできます。

既定設定は便利ですが、他の比較にも影響するため、最後の手段として使うと事故が減ります。

また、比較で直ったように見えても「次回開いたらまた文字化けする」ケースは、保存時のエンコーディングが揃っていないことが原因になりがちです。

そのため、表示が直った後に「保存後の再オープン」「別エディタでの認識」「相手環境（Excel等）での表示」を確認して、やっと完了と考えるのが確実です。

さらに実務では「自分のPCでは直ったが、別PCで開いたら再発した」も起きます。

既定コードページやフォント、Excelの取り込み方法など環境差が関係するため、最後のチェックまで入れると手戻りが減ります。

対象範囲：開く／比較／保存／既定

本記事はテキスト比較（txt、csv、ソースコード等）を前提に、WinMergeの文字コード指定と文字化け対策に絞って解説します。

WinMergeの基本的な使い方（差分移動やマージ操作）は最小限にとどめ、

• どこで文字コードを確認するか
• どのタイミングで指定して開き直すか
• いつ保存変換すべきか
• 既定設定を変えるべきか

の判断に必要なポイントだけを整理します。

「まず表示を直す」「次に比較を読みやすくする」「最後に運用を安定させる」の順で進めるので、急ぎなら手順セクションだけ拾っても作業できます。

環境

文字化けの原因は「WinMergeの自動判定」と「元ファイル側の実際の文字コード」が食い違うことが多いです。

同じファイルでも、開くアプリ（WinMerge/VS Code/メモ帳/Excel）によって自動判定や既定文字コードが違うため、「どのアプリでは正常で、どのアプリで崩れるか」をメモしておくと切り分けが一気に早くなります。

また、ネットワーク共有やリモート環境（RDP/VDI）で作業している場合、フォントや地域設定が違って見え方が変わることがあります。

まずは「ファイルが同じでも環境が違えば結果が変わる」前提で整理しておくのがコツです。

WinMergeのバージョン・OS

WinMergeはバージョンにより表示や操作位置が少し変わるため、まず利用中のバージョンを確認します。

Windowsのメジャー更新やエディタの設定変更で既定の扱いが変わることもあるため、同じ手順でも結果が違う場合があります。

チームで手順を共有する場合は、

• Windowsのバージョン（例：Windows 10 / 11）
• WinMergeのバージョン
• 文字化けが出るファイルの拡張子

の3点を最低限そろえると、再現・検証がしやすくなります。

補足として、WinMergeの設定はユーザー単位で保持されることが多いです。

同じPCでも別ユーザーでログインすると挙動が違う場合があるため、検証するなら「どのユーザーで起きたか」も控えると原因が設定なのかファイルなのか切り分けやすくなります。

対象ファイル（txt/csv/ソース）と改行コード（CRLF/LF）

CSVやソースコードは文字コードだけでなく改行コードやタブ幅の差で「比較が崩れたように見える」ことがあります。

改行コードが混在していると差分が増えるので、文字化け解決後に改行の統一も確認します。

加えて、

• CSVは「区切り（カンマ/タブ/セミコロン）」「引用符」「アプリ依存の解釈」
• ソースコードは「インデント（タブ/スペース）」「不可視文字」「末尾空白」

が絡むため、まずはテキストとして正常に読める状態（文字化けがない状態）に戻してから、差分ノイズを減らす順番が安全です。

なお、拡張子だけで「テキスト」とは限りません。

たとえば .csv でも実体はTSVだったり、ログがバイナリに近い形式だったりします。

文字コードを疑う前に「純粋なテキストか」を軽く確認すると遠回りになりません。

前提確認：UTF-8（BOM有無）／Shift_JIS／混在の有無

UTF-8はBOMありとBOMなしが混在すると、ツールによって判定が揺れて文字化けのように見えることがあります。

日本語Windowsの現場ではShift_JIS（CP932）も多く、UTF-8との混在が典型的なトラブル源です。

「どの文字コードが正しいかわからない」場合は、次のヒントが使えます。

• そのファイルを作ったツール（Excelで出したCSV、古いバッチ出力、Git管理のソースなど）
• 同じフォルダ内の他ファイルの傾向（同プロジェクトなら同じ方針になりやすい）
• ファイル先頭のBOM有無（UTF-8 BOMの可能性）

現場のあるあるとして「移行途中で一部だけ古い文字コードが残っている」「外部委託の納品物だけ別の文字コード」などがよくあります。

混在の可能性は常に疑っておくと判断が早くなります。

最短で直す：文字コード変更の全体像

最短の考え方は「正しい文字コードで開く」→「必要なら保存時に変換する」→「頻発するなら既定を見直す」です。

ここで重要なのは、いきなり既定設定を変えないことです。

既定を変えると、別案件のファイルや過去資産の読み込みが崩れることがあるため、まずは「この比較だけ直す」手段（個別指定）から当てます。

また、比較用途では「正しく見えること」が第一です。

保存変換は再発防止のフェーズに回し、まずは読める状態に戻すのが最短です。

文字化けの主因は「自動判定ミス」と「BOM/混在」

WinMergeはファイル内容から文字コードを推定しますが、短いファイルや特定のバイト並びでは誤判定が起きます。

誤判定を疑うサインは、同じファイルが別のエディタでは正常表示なのにWinMergeだけ崩れるケースです。

もう1つのサインは、「一部だけ化ける」「ファイルによって直ったり直らなかったりする」ケースで、これはBOMの有無や混在が疑わしいです。

機械判定は万能ではないため、「明示指定で読む」ことを前提にすると作業が安定します。

特にASCII中心のファイルはUTF-8/Shift_JISの区別が付きづらく、判定が揺れやすいので注意します。

UTF-8とBOM（あり/なし）の違い

BOMは「このファイルはUTF-8（またはUTF-16等）です」と示す目印として使われることがあります。

UTF-8は本来BOMが不要ですが、運用やツールの都合でBOMありを採用しているプロジェクトもあります。

BOMあり/なしのどちらが正しいかは「プロジェクト方針」と「相手ツール（Excel等）の都合」で決まることが多いので、

• リポジトリやチームの規約
• 既存ファイルの傾向
• 納品先の期待

を基準に揃えるのが現実的です。

一般に、BOMなしはツール間で扱いやすい一方、古いツールだとUTF-8として認識されにくい場合があります。

逆にBOMありはUTF-8だと分かりやすい反面、先頭のBOMが邪魔になるツールもあります。

迷ったら「最終的に開くアプリ」を基準に決めるのが実務的です。

自動判定が外れやすいケース

短いファイル、ASCII中心のファイル、一部の日本語記号が含まれるファイルは自動判定が外れやすいです。

拡張子や中身の先頭が似ているだけで別の文字コードとして扱われることもあります。

特に、

• ほぼ英数字で、たまに日本語が出るログ
• 先頭数行がコメントのみのソース
• 1行だけの設定ファイル

は「判定材料が少ない」ため、個別指定での読み込みが安定します。

制御文字や不可視文字が混じると表示が崩れたり差分が増えたりすることもあるので、文字コードだけに固執せず「内容がテキストとして妥当か」も並行して疑うのがコツです。

文字コードの設定手順

手順は「現状把握」→「個別に指定して開く」→「左右で違う場合の整理」→「保存で変換」→「既定を調整」の順で進めます。

途中で迷ったら、まずは「個別指定で開き直して表示が直るか」を試し、直ったら保存変換や運用に進むのが最短です。

ここでは操作そのものよりも「どの状態になったら次へ進むか」を重視し、各手順に確認ポイントを付けています。

手順0：いまの文字コードを見分ける（表示/ステータス等）

最初にWinMergeが今そのファイルを何の文字コードとして読んでいるかを把握します。

WinMergeのステータスバーにエンコーディング表示が出る構成では、そこが最短の確認ポイントになります。

表示が見当たらない場合は、同じファイルを別のエディタ（VS Codeやメモ帳等）で開き、文字コード表示と突き合わせると判断が早いです。

さらに確実にするなら、

• 同じファイルを「別PC」でも開いてみる
• そのファイルを作った人/ツールに確認する
• 可能ならGitの履歴（過去コミットの傾向）を見る

といった方法で、正解の文字コードを特定しやすくなります。

補足として、CSVの場合は「開き方」で結果が変わります。

Excelのダブルクリックは既定判定に引っ張られやすいので、インポート機能で文字コードを選べるかも含めて確認すると、原因の切り分けが進みやすいです。

• 確認ポイント：WinMerge上の表示が明らかに文字化けしているか。
• 確認ポイント：別エディタでは正常表示か。
• 確認ポイント：UTF-8（BOMあり/なし）やShift_JISなど、想定している文字コードが何か。

手順1：ファイルを指定の文字コードで開く（個別指定）

「この比較だけ直したい」なら、既定設定に触らず個別に文字コードを指定して開き直すのが安全です。

WinMergeには左右どちらのファイルをどのコードページで読み込むかを指定できる導線があります。

操作例としては、メニューの「ファイル」配下にある「ファイルエンコーディング（File encoding）」系の項目から、左または右の読み込みコードページを選ぶ流れが一般的です。

UTF-8にしたい場合はコードページ「65001（UTF-8）」を選ぶ運用がよく使われます。

Shift_JIS相当で読み込みたい場合は、環境によって「ANSI」や「Japanese（Shift_JIS/CP932）」のような表記になることがあります。

指定後に表示が直らない場合は、いったん閉じてから同じ指定で開き直すと反映されることがあります。

また、表示が直っても差分が不自然に多い場合は、次の可能性があります。

• 実は左右で文字コードが違う（手順2へ）
• 改行コードや空白差がノイズになっている（後半のチェックへ）

実務的には「表示が正しくなったか」を最優先で見て、差分ノイズは後で潰す方が迷いません。

まずは文字が読める状態に戻してから、差分の意味を判断します。

• 確認ポイント：開いた直後に日本語が自然に表示されるか。
• 確認ポイント：左右で表示が一致し、意図しない差分が減るか。
• 確認ポイント：再度開き直しても同じ表示が維持されるか。

手順2：左右で文字コードが違うファイルを比較する（考え方＋対処）

左右で文字コードが違う場合は、まず「どちらが正で、どちらを合わせたいか」を決めるのがコツです。

比較の目的が「差分の確認」だけなら、表示を揃えるために双方を同じ文字コードとして読み込む設定にするだけで十分なことがあります。

一方で「最終的にファイルを統一する」目的なら、どちらかを保存時に変換して文字コードそのものを揃えるのが確実です。

左右で違うときのよくあるパターンは「片方がShift_JIS（CP932）、片方がUTF-8（BOMなし）」です。

この場合は、まず両方をUTF-8として開いて表示が正しいかを確認し、正しい方に合わせて保存変換する流れが安全です。

もう1つ多いのが「片方がUTF-8 BOMあり、片方がUTF-8 BOMなし」です。

見た目は似ていてもツール側の扱いが変わることがあるので、チーム方針に合わせてどちらかに統一します。

補足として、「左右で読めるが、日本語の一部が片側だけ化ける」場合は、片側に機種依存文字や外字が混じっている可能性もあります。

文字コードだけで説明できないと感じたら、後半のチェック（フォント・外字）も一緒に疑います。

• 確認ポイント：左右それぞれの想定文字コードをメモできているか。
• 確認ポイント：同一文字コードで読み込んだときに表示が揃うか。
• 確認ポイント：差分が「文字化け由来のノイズ」ではなく内容差になっているか。

手順3：保存時に文字コードを指定する（変換のやり方）

比較で表示が直っても、元ファイルの文字コード自体が揃っていないと次回また混乱します。

この場合は「保存」または「名前を付けて保存」で、保存時のエンコーディングを指定して変換します。

保存ダイアログに「Encoding」や「文字コード」のドロップダウンがある場合は、そこでUTF-8やANSI（環境によりShift_JIS相当）などを選べます。

BOMありUTF-8に揃える運用なら、保存時にBOMありで出力される設定になっているかも確認します。

変換は不可逆に近い作業なので、必ずバックアップかGit等の履歴がある状態で実施します。

実務上は、次のように進めると安全です。

• まず別名で保存（変換版を作る）
• WinMergeで元と変換版を比較して内容差がないか確認
• 相手が開くアプリ（Excel等）でも表示確認
• 問題なければ置き換え（またはコミット）

特にCSVは「Excelで崩れる」問題が起きやすいので、変換後はExcelの想定手順でテストするのが確実です。

ファイル自体は正しくても、相手の開き方がダブルクリック固定だと再発することがあるため、納品要件として「取り込み手順」まで決めることもあります。

• 確認ポイント：保存後に再オープンしても文字化けしないか。
• 確認ポイント：別エディタでも同じ文字コードとして認識されるか。
• 確認ポイント：差分比較で不要なノイズが増えていないか。

手順4：既定（デフォルト）を変える時の注意（影響範囲・戻し方）

同じトラブルが何度も起きるなら、WinMergeの既定コードページを見直すのが有効です。

一般的には「編集」→「設定（Options）」→「コードページ（Codepage）」で、デフォルトコードページをカスタム指定し、UTF-8なら「65001」を選びます。

既定を変えると過去のShift_JIS資産を開いたときに逆に崩れることがあるため、混在環境では安易に固定しない方が安全です。

元に戻す方法も先に確認し、必要なら設定変更前のスクリーンショットを残します。

「いつでも戻せる」状態にしておくと、案件ごとに最適な設定を試しやすくなります。

また、既定を変える前に「個別指定で困っていないか」を確認します。

個別指定で十分に回るなら、既定変更はしない方がトラブルが少ないです。

• 確認ポイント：よく扱うファイル群で文字化けが減るか。
• 確認ポイント：別の案件や古いファイルで新しい文字化けを生まないか。
• 確認ポイント：設定を戻せば元の挙動に復帰できるか。

設定しても直らない時のチェック（原因→確認→対処）

文字コードを直したのに比較が崩れる場合は、文字コード以外の差分要因が混ざっていることが多いです。

ここでは「原因→確認→対処」の順で、最短で潰せる順に並べます。

ポイントは、

• 「表示」の問題なのか（見え方だけ）
• 「比較」の問題なのか（差分がノイズで膨れているだけ）
• 「保存」の問題なのか（次回また崩れる）

を分けて考えることです。

比較が崩れて見えるときは、まず「表示を揃える（正しい文字で読める状態にする）」→「差分ノイズを減らす（改行・空白・不可視）」→「必要なら変換して統一」の順に進めると迷いません。

改行コード（CRLF/LF）で比較がズレる

改行コードが左右で違うと、行単位の差分が大量に出て「内容が全部違う」ように見えることがあります。

WinMerge側の表示オプションやフィルタで改行差を扱える場合があるので、まずは改行コードの実態を確認します。

対処としては、対象ファイルを同じ改行コードに変換してから比較するのが確実です。

「どちらが正か」迷う場合は、プロジェクトの既存ファイルに合わせるか、Gitの改行設定（.gitattributes等）に合わせます。

改行で迷いやすいケースとしては、

• Windows由来のファイル（CRLF）と、Linux由来のファイル（LF）が混ざっている
• 自動生成ファイルだけ改行が違う
• エディタの保存設定で改行が勝手に変わっている

などがあります。

まずはWinMerge側で「改行コードの可視化」や「EOL表示」相当の機能が使えるなら有効化し、差分が改行だけかどうかを見抜けるようにします。

タブ／スペース／全角半角の差がノイズになる

インデントがタブかスペースかで、見た目と差分が大きく変わります。

比較目的が「ロジック差」なら、空白差分を無視する設定や、整形してから比較する運用が有効です。

全角半角の混在はレビューで見落としやすいので、検索や置換で可視化してから直すのが安全です。

また、不可視文字（ノーブレークスペース等）が混じっていると原因が見えにくいので、疑わしい場合は一度プレーンテキスト化して確認します。

実務で多いのは「インデント規約があるのに、1ファイルだけ混ざって差分が爆増する」ケースです。

このときは、

• 差分を追う前に空白差分の扱い（無視/強調/可視化）を決める
• 可能なら整形ツール（formatter）で統一してから比較する

の順にすると、比較の目的（本当の差）を見失いにくくなります。

機種依存文字・外字・フォント差で崩れる

同じ文字コードでも、表示フォントが対応していないと四角や豆腐になって文字化けに見えます。

機種依存文字や外字が含まれるファイルでは、表示環境を揃えるか、代替表現に置き換える検討が必要です。

文字が欠ける場合は、まず別フォントや別エディタでも同じ症状かを切り分けます。

もし「WinMergeだけ豆腐」なら、WinMerge側のフォント設定（表示フォント）を見直す余地があります。

さらに、

• Windows側のフォントが欠けている（社内配布フォントが未導入）
• 言語パック/地域設定の差
• 置換不能な外字が混じっている

といった要因もあり得るため、同じファイルを別PCで開いて結果が変わるかも確認すると原因に近づきます。

症状別の早見表

次の表は「原因候補→確認→対処」を最短で回すための早見です。

表の「確認」から順に潰していくと、原因を取り違えにくくなります。

補足：安全な変換とチーム運用

文字コードは個人設定だけで解決しきれないことが多いため、運用ルールまで決めると再発が減ります。

「誰が」「どのタイミングで」「どの形式で」保存するかを揃えるだけでも、比較時の事故が激減します。

さらに、混在環境では「既定設定をいじる人」と「個別指定で運用する人」が混ざると、同じファイルなのに結果が変わって混乱しがちです。

チームでは「まず個別指定で対処」「変換は手順化してから」「既定設定はチーム合意があるときだけ」のように、優先順位を決めておくとトラブルが減ります。

安全に文字コード変換するコツ（バックアップ／差分確認）

文字コード変換は元に戻しづらいので、変換前に必ずバックアップを取り、差分比較できる状態で進めます。

変換後はWinMergeで再比較し、文字化けが消えたことと、内容が変わっていないことの両方を確認します。

CSVはアプリ側（Excel等）の期待文字コードも絡むため、利用者が開くアプリでの表示確認まで行うと安全です。

さらに、運用のコツとしては次が有効です。

• 変換は一括置換ではなく、まず代表ファイルで試す
• 変換後に改行・空白差分が増えていないか確認する
• 大量ファイルなら、変換スクリプト/ツールのログを残す
• 変換前後でファイルサイズが極端に変わっていないか見る（異常の早期発見）
• 変換対象が複数人で触られるなら、変換のコミット/差分をまとめてレビューする

チームで統一するなら：推奨→例外→ルール（UTF-8推奨・BOM方針）

新規案件や複数OSが混在する環境では、UTF-8に統一するとツール間の相性問題が減りやすいです。

一方で相手先がShift_JIS前提の場合は、納品物だけShift_JISにするなど例外を明確にします。

BOMありにするかなしにするかは混乱ポイントなので、どちらを正とするかをルール化して共有します。

おすすめのまとめ方は、次の3点をセットで決めることです。

• リポジトリ内の標準（例：UTF-8 BOMなし）
• 相手都合の例外（例：Excel提出はShift_JIS）
• 変換の担当と手順（例：提出前に別名保存で変換、差分確認）

加えて、実務では「いつ統一するか」も重要です。

• 新規追加ファイルから統一する（既存資産は触らない）
• 一定のタイミングでまとめて統一する（例：大きなリリース前）
• 触ったファイルだけ順次統一する（ボーイスカウト方式）

のどれにするかを決めておくと、混在期間の混乱を抑えやすくなります。

よくある質問（Q ＆ A）

最後に、実際にハマりやすいパターンをQ&A形式で回収します。

本文手順で解決しないときは、該当する質問から切り分けのヒントを拾ってください。

Q：UTF-8にしたのに文字化けが残る（BOM／混在／判定）

A：UTF-8でもBOMの有無や混在で判定が揺れるため、保存時にUTF-8を明示し、必要ならBOM方針も統一します。

A：短いファイルや特殊記号を含む場合は自動判定が外れることがあるので、手順1で個別に指定して開き直します。

A：それでも直らない場合は、左右で別の文字コードになっていないか（手順2）と、フォント表示の問題が混ざっていないか（チェック表の「豆腐」）を確認します。

A：CSVの場合は、WinMerge上の表示が直ってもExcelで崩れることがあるため、「どこで崩れるか（WinMerge/Excel/メモ帳）」を切り分けてから対処すると遠回りになりません。

Q：Shift_JISで保存したい／相手環境に合わせたい

A：名前を付けて保存でエンコーディングをShift_JIS相当に指定し、相手の環境で開いて確認するのが確実です。

A：同名上書きは事故が起きやすいので、変換版は別名で作り、差分比較してから置き換えます。

A：チーム内では「普段はUTF-8、提出物だけShift_JIS」のように役割分担すると、日常の比較は安定しやすくなります。

A：提出物がCSVなら、相手のExcel取り込み手順（インポートで文字コード選択できるか）も確認し、可能なら「保存形式を変える」前に「取り込み方法で解決」できないかを試すと安全です。

Q：CSVの日本語だけ崩れる（区切り／引用符／アプリ依存）

A：CSVは文字コードだけでなく、区切り文字や引用符の扱いがアプリごとに違うため、最終的に開くアプリ側の仕様を確認します。

A：WinMerge上で直ってもExcelで崩れる場合は、Excelが期待する文字コード（例：Shift_JIS系）に合わせた保存が必要なことがあります。

A：Excelでの「データの取得（インポート）」を使うと、文字コードを選べることがあるため、保存形式を変える前に試す価値があります。

A：また、区切り文字が「カンマ」なのか「タブ」なのかで見え方が変わるため、テキストとして開いたときに区切りがどれかを確認してから、アプリ側の取り込み設定に合わせます。

Q：設定を変えたら他の比較にも影響する？（既定と一時指定）

A：既定（デフォルト）を変えると新規に開くファイル全体に影響するため、まずは一時指定（手順1）で解決するのが安全です。

A：頻発するなら既定を変える価値がありますが、混在環境では戻し方も含めて運用を決めてから適用します。

A：既定を変えた後は、代表的なUTF-8/Shift_JISファイルを数本開いて「新しい文字化け」を生んでいないかをチェックしておくと安心です。

A：チームで既定を揃える場合は、個々のPCで勝手に変わらないように「設定手順（スクショ）」と「推奨値」を共有し、変更時は共有する運用にするとトラブルを抑えられます。

完了チェックリスト

最後に、直ったかどうかを自分で判定できるチェック項目を置きます。

次の項目がすべて満たせていれば、文字化け対策はひとまず完了です。

• 文字化けなしで表示できる。
• 比較結果が妥当で、文字化け由来のノイズ差分が減った。
• 保存後も再オープンで崩れない。
• 別エディタ（VS Codeやメモ帳等）でも同じように表示できる。
• Excelなど相手が使うアプリで開いても崩れない（必要な場合）。
• チームや相手環境の規約に合っている（BOM方針を含む）。