【3分で解決】WinMergeの文字コード指定方法｜UTF-8・Shift_JIS・BOM設定を解説

WinMergeでファイルを比較したときに、日本語が文字化けしたり、変更していないはずなのに大量の差分が表示されたりして困ったことはありませんか。

その原因の多くは、UTF-8やShift_JISなどの文字コードの違いにあります。

特にWindows環境では、古いCSVや業務システムのファイルがShift_JIS、新しい開発環境のファイルがUTF-8で保存されていることが多く、WinMergeの自動判定だけでは正しく比較できない場合があります。

この記事では、WinMergeで文字コードを指定する方法を最短手順で解説するとともに、UTF-8・Shift_JIS・EUC-JPの違い、BOMあり・なしの考え方、文字化けが直らないときの対処法まで詳しく紹介します。

WinMergeで毎回文字化けする方や、差分比較の精度を高めたい方はぜひ参考にしてください。

WinMergeで文字コードを指定する方法【3分で完了】
WinMergeで文字化けする原因とは？
UTF-8・Shift_JIS・EUC-JPの違いと選び方
用途別のおすすめ文字コード設定
文字コード指定しても直らないときの対処法
WinMergeの文字コード指定でよくある質問

WinMergeで文字コードを指定する方法【3分で完了】

WinMergeで文字化けが発生した場合、まず確認したいのが文字コード設定です。

比較対象のファイルがUTF-8やShift_JISなど異なる文字コードで保存されていると、日本語が正しく表示されなかったり、本来存在しない差分が大量に表示されたりします。

この章では、WinMergeで文字コードを指定する手順と、比較結果を正しく表示するためのポイントを分かりやすく解説します。

やりたいこと	操作内容
文字化けを直したい	エンコーディングを手動変更する
UTF-8を指定したい	表示メニューからUTF-8を選択する
Shift_JISを指定したい	表示メニューからShift_JISを選択する
文字コードを変換保存したい	名前を付けて保存を利用する

比較画面から文字コードを変更する手順

WinMergeでは、比較結果を表示した後でも文字コードを変更できます。

そのため、ファイルを開いた瞬間に文字化けしても慌てる必要はありません。

比較画面から再読み込みすることで、正しい文字コードへ切り替えられます。

操作手順は非常にシンプルです。

WinMergeで比較ファイルを開く
メニューの「表示」をクリックする
「エンコーディング」を選択する
目的の文字コードを指定する

文字コードを変更すると、WinMergeがファイルを再読み込みします。

その結果、日本語の文字化けが解消される場合があります。

例えばUTF-8として読み込まれていたShift_JISファイルは、Shift_JISへ変更するだけで正常表示されることがあります。

文字化けした場合は、まずエンコーディングを切り替えて再表示するのが最も簡単な解決方法です。

UTF-8・Shift_JIS・EUC-JPを指定する方法

WinMergeでよく利用される文字コードはUTF-8、Shift_JIS、EUC-JPの3種類です。

現在の開発環境ではUTF-8が主流ですが、古いWindows環境ではShift_JISが使われているケースも少なくありません。

文字コード	主な用途
UTF-8	Web開発・プログラミング・Git管理
Shift_JIS	古いWindowsアプリ・CSVファイル
EUC-JP	古いLinux・UNIX環境

設定方法はすべて共通です。

表示
エンコーディング
対象の文字コードを選択

まずはUTF-8を試し、それでも改善しない場合にShift_JISを選択する方法がおすすめです。

特にCSVファイルや古い業務システムの出力データではShift_JISが使われていることが多くあります。

UTF-8が正解とは限らないため、ファイルの作成元も確認しておきましょう。

英数字だけのファイルは自動判定が失敗しやすいため、手動指定が必要になることがあります。

文字コード変更後に保存する方法

表示だけでなく、文字コードを変換して保存したい場合もあります。

例えばShift_JISファイルをUTF-8へ統一したい場面です。

そのような場合は「名前を付けて保存」を利用します。

文字コードを変更する
ファイルをクリックする
名前を付けて保存を選択する
保存時のエンコーディングを指定する

これによりShift_JISからUTF-8への変換保存が可能になります。

Git管理やWeb開発では、文字コードをUTF-8へ統一することで文字化けトラブルを減らしやすくなります。

一方で、古い業務システムではShift_JIS前提になっていることがあります。

変換前に利用システムがUTF-8へ対応しているか必ず確認してください。

また、大量のファイルを変換する場合はバックアップを作成しておくと安心です。

変換後にWinMergeで比較すれば、内容が破損していないか簡単に確認できます。

文字コード変換後は、再度WinMergeで比較して内容に差異がないことを確認するのがおすすめです。

WinMergeで文字化けする原因とは？

WinMergeで文字コードを指定しても、なぜ文字化けが起きるのか疑問に感じる方は多いです。

実は文字化けの多くは、WinMergeの不具合ではなくファイル側の文字コードや保存形式の違いによって発生しています。

ここでは、文字化けの代表的な原因と、比較結果がおかしく見える理由を理解していきましょう。

症状	主な原因
日本語が記号になる	文字コードの誤認識
全行が差分になる	文字コードや改行コードの違い
一部だけ文字化けする	BOMや不正文字の影響
突然文字化けした	保存時の変換ミス

文字コードの違いで文字化けが起こる仕組み

文字化けの最大の原因は、ファイルの文字コードと読み込み時の文字コードが一致していないことです。

コンピューターは文字を数字として保存しています。

その数字をどのルールで文字へ変換するかを決めているのが文字コードです。

例えばShift_JISで保存されたファイルをUTF-8として読み込むと、日本語部分だけ意味不明な文字列になることがあります。

これは、日本語の辞書を英語の辞書で無理やり読もうとしているような状態です。

文字そのものは保存されていても、解釈方法が間違っているため正常表示できません。

保存形式	読み込み形式	結果
UTF-8	UTF-8	正常表示
Shift_JIS	Shift_JIS	正常表示
UTF-8	Shift_JIS	文字化け発生
Shift_JIS	UTF-8	文字化け発生

文字化けの多くは「保存時」と「読み込み時」の文字コード不一致によって発生します。

自動判定で誤認識されるケース

WinMergeには文字コードの自動判定機能があります。

通常はファイルを開くだけで適切な文字コードを推測してくれる便利な機能です。

しかし、自動判定は100％正確ではありません。

特に以下のようなファイルは誤認識されやすい傾向があります。

BOMなしUTF-8
英数字中心のソースコード
日本語が少ないファイル
古いCSVファイル
ログファイル
一部だけ破損したファイル

例えば英数字だけで構成されたソースコードは、UTF-8とShift_JISの判別が難しくなります。

その結果、自動判定が誤る場合があります。

また、古いCSVファイルはShift_JIS前提で作られていることが多く、自動判定では正しく認識できないケースがあります。

文字化けした場合は、自動判定を疑い、手動でUTF-8やShift_JISを切り替えてみましょう。

特に日本語を含むCSVファイルはShift_JISの可能性が高いです。

BOMあり・BOMなしが影響する理由

UTF-8にはBOMありとBOMなしの2種類があります。

BOMとは、ファイルの先頭に付加される識別情報のことです。

正式にはByte Order Markと呼ばれています。

この情報があることで、一部のアプリケーションはUTF-8だと認識しやすくなります。

種類	特徴
UTF-8 BOMあり	Windows系アプリとの互換性が高い
UTF-8 BOMなし	Web開発やプログラミングで主流

同じUTF-8でも、BOMの有無によってWinMergeや他のソフトの判定結果が変わることがあります。

そのため、UTF-8なのに文字化けするという現象が発生することがあります。

特に古いWindowsアプリで作成されたファイルでは、この影響を受けやすい傾向があります。

もしUTF-8を指定しても改善しない場合は、UTF-8 BOMありとUTF-8 BOMなしの両方を試してみてください。

UTF-8で文字化けする場合は、BOMの有無を確認するだけで解決するケースがあります。

UTF-8・Shift_JIS・EUC-JPの違いと選び方

WinMergeで文字コードを指定するとき、多くの方が「結局どれを選べばいいのか分からない」と悩みます。

文字化けを解決するためには、各文字コードの特徴と使われる環境を理解することが重要です。

この章では、WinMergeでよく遭遇するUTF-8・Shift_JIS・EUC-JPの違いと選び方を分かりやすく解説します。

文字コード	主な利用環境	現在の利用頻度
UTF-8	Web開発・Git・クラウド環境	非常に多い
Shift_JIS	Windows業務システム・CSV	多い
EUC-JP	古いLinux・UNIXサーバー	少ない

UTF-8を使うべきケース

現在の標準文字コードはUTF-8です。

新規開発プロジェクトの多くはUTF-8で統一されています。

特にWeb開発やクラウドサービスでは、UTF-8が事実上の標準と考えて問題ありません。

UTF-8の最大のメリットは、多言語対応と高い互換性です。

日本語だけでなく、英語、中国語、韓国語、記号、絵文字なども同じ仕組みで扱えます。

Webサイト制作
HTML・CSS・JavaScript
PHP・Python・Java開発
Git管理
VSCode利用
Mac・Linux環境
API連携
クラウド開発

特にGitを利用している場合は、UTF-8へ統一することで不要な差分や文字化けを減らしやすくなります。

また、Windows・Mac・Linuxが混在する環境でも安定して利用できます。

新規作成ファイルや開発用途では、基本的にUTF-8を選べば問題ありません。

特別な理由がない限り、現在の標準はUTF-8です。

Shift_JISを使うべきケース

Shift_JISは長年Windows環境で利用されてきた日本語向け文字コードです。

現在でも多くの企業システムで利用されています。

そのため、業務で扱うファイルではShift_JISに遭遇する機会が少なくありません。

代表例	Shift_JIS利用の可能性
古いCSVファイル	高い
会計システム出力	高い
基幹システムデータ	高い
Excel保存CSV	高い

特にWindows版ExcelでCSV保存したファイルはShift_JISになっているケースが多くあります。

そのため、CSV比較時に文字化けする場合はShift_JISを疑うと原因を特定しやすくなります。

また、古い業務システムではUTF-8に対応していないこともあります。

そのような環境では、UTF-8へ変換すると逆に文字化けや取込エラーが発生する場合があります。

古いシステムへ取り込むファイルは、勝手にUTF-8へ変換しないよう注意してください。

CSV・帳票・業務システム関連ファイルはShift_JISの可能性が高いと考えると判断しやすくなります。

EUC-JPが使われる環境と注意点

EUC-JPは、かつてLinuxやUNIX環境で広く利用されていた日本語文字コードです。

現在ではUTF-8への移行が進み、新規利用はほとんど見られません。

しかし、古いサーバーや長期間運用されているシステムでは残っていることがあります。

古いLinuxサーバー
UNIX系システム
レガシーWebシステム
長期運用中の業務サーバー

例えば10年以上前から運用されているシステムでは、ログファイルや設定ファイルがEUC-JPのまま残っているケースがあります。

そのため、UTF-8でもShift_JISでも文字化けする場合は、EUC-JPを試してみる価値があります。

ただし、現在の一般的なWindows利用者がEUC-JPを扱う機会はかなり少なくなっています。

そのため、まずはUTF-8、その次にShift_JISを試し、それでも改善しない場合にEUC-JPを確認する流れがおすすめです。

試す順番	推奨度
UTF-8	最優先
Shift_JIS	次に確認
EUC-JP	最後に確認

文字コード選びで迷った場合は「UTF-8 → Shift_JIS → EUC-JP」の順番で確認すると効率的です。

用途別のおすすめ文字コード設定

文字コードは「どれが優れているか」ではなく、「どの環境で使うか」で選ぶことが重要です。

実際には、同じWinMergeでも比較するファイルによって最適な文字コードは変わります。

ここでは、よくある利用シーンごとにおすすめの文字コード設定を紹介します。

自分の用途に近いケースを確認すると、文字化けや不要な差分を素早く解決しやすくなります。

用途	推奨文字コード
CSV比較	Shift_JIS または UTF-8
Web開発	UTF-8
Git管理	UTF-8
サーバーログ	UTF-8 または EUC-JP

CSVファイルを比較する場合

CSV比較はWinMergeで最も利用されるケースのひとつです。

特に業務システムから出力されたCSVでは、Shift_JISが利用されていることが非常に多くあります。

そのため、CSV比較で文字化けした場合は最初にShift_JISを試すのがおすすめです。

一方で、近年はクラウドサービスやWebシステムから出力されたCSVでUTF-8が使われるケースも増えています。

例えばGoogleスプレッドシートから出力したCSVはUTF-8になることがあります。

そのため、CSVだから必ずShift_JISとは限りません。

CSVの出力元	よく使われる文字コード
Excel	Shift_JIS
業務システム	Shift_JIS
クラウドサービス	UTF-8
Googleスプレッドシート	UTF-8

CSV比較で文字化けした場合は、まずShift_JIS、その次にUTF-8を確認するのが効率的です。

Web開発・プログラミングで利用する場合

Web開発ではUTF-8を選ぶのが基本です。

現在のHTML、CSS、JavaScript、PHP、Pythonなどの開発環境は、ほぼUTF-8を前提として設計されています。

特にGitHubやクラウドサービスとの連携を考えると、UTF-8へ統一しておく方が管理しやすくなります。

また、多言語対応や絵文字対応が必要な場合もUTF-8が有利です。

HTML
CSS
JavaScript
PHP
Python
Node.js
Laravel
WordPress

これらの環境では、UTF-8 BOMなしが主流です。

特にPHPでは、BOM付きファイルが原因でヘッダー送信エラーが発生することがあります。

Web開発用途では、UTF-8 BOMなしを基本設定として考えるのがおすすめです。

新規開発プロジェクトでは、文字コードをUTF-8へ統一すると管理が楽になります。

Git管理ファイルを比較する場合

Git管理では文字コード統一が非常に重要です。

文字コードが混在すると、本来変更していない行まで差分として表示されることがあります。

その結果、コードレビューが難しくなったり、不要なコミットが増えたりします。

特にチーム開発では、Windows・Mac・Linuxが混在するケースも多くあります。

そのため、UTF-8で統一する企業や開発チームが増えています。

管理方法	おすすめ
個人開発	UTF-8
チーム開発	UTF-8
OSS開発	UTF-8
クラウド開発	UTF-8

WinMergeでGit管理ファイルを比較する場合も、UTF-8を基準にすると不要差分を減らしやすくなります。

また、改行コード設定も合わせて確認しておくと効果的です。

Git環境ではUTF-8へ統一し、改行コードも管理することで差分品質を向上できます。

サーバーログや設定ファイルを比較する場合

ログファイルや設定ファイルは、運用環境によって文字コードが異なります。

最近のLinuxサーバーではUTF-8が一般的ですが、古いシステムではEUC-JPが残っている場合もあります。

そのため、サーバー保守やログ解析では少し注意が必要です。

例えば、10年以上前から運用されているサーバーではEUC-JPのログが残っていることがあります。

また、一部の業務アプリケーションではShift_JISログを出力するケースもあります。

環境	主な文字コード
最新Linux	UTF-8
クラウドサーバー	UTF-8
古いLinux	EUC-JP
Windowsサーバー	Shift_JIS

UTF-8で正常表示されない場合は、EUC-JPやShift_JISも試してみましょう。

また、ログファイルでは改行コードの違いによる差分も発生しやすいため、文字コードと合わせて確認することが重要です。

ログ解析では文字コードだけでなく改行コードも確認すると原因を特定しやすくなります。

サーバー関連ファイルは、UTF-8を基準にしながらEUC-JPやShift_JISも候補として確認するのがおすすめです。

文字コード指定しても直らないときの対処法

UTF-8やShift_JISを指定しても文字化けが改善しない場合があります。

そのようなケースでは、文字コード以外の原因が隠れていることも少なくありません。

実際の現場では、改行コード・コードページ・ファイル形式・エディター設定などが原因になっているケースも多くあります。

ここでは、文字コード変更だけでは解決しない代表的な原因と対処法を紹介します。

症状	確認すべきポイント
全行が差分になる	改行コード
文字化けが直らない	実際の文字コード
意味不明な記号が並ぶ	バイナリファイルの可能性
WordやExcelが比較できない	ファイル形式の違い

改行コード（CRLF・LF）の違いを確認する

WinMergeで大量の差分が表示される原因として、改行コードの違いがあります。

文字コードが同じでも、改行コードが異なるだけで全行変更扱いになることがあります。

代表的な改行コードは以下のとおりです。

改行コード	主な利用環境
CRLF	Windows
LF	Linux・macOS
CR	古いMac OS

例えばWindowsで編集したファイルとLinuxサーバー上のファイルを比較すると、内容は同じでも全行差分になる場合があります。

この場合は文字コードではなく改行コードが原因です。

WinMergeのステータスバーや外部エディターを使うと確認しやすくなります。

文字化けではなく大量差分が発生している場合は、まず改行コードを確認しましょう。

コードページ差異を無視する設定を使う

WinMergeにはコードページ差異を無視する設定があります。

内容自体は同じなのに、エンコーディングの違いだけで差分扱いになるケースで役立ちます。

設定手順は以下のとおりです。

編集をクリックする
オプションを開く
比較を選択する
一般設定を確認する

環境によっては「コードページ差異を無視」や「エンコーディング差異を無視」と表示されることがあります。

この設定を有効にすると、不要な差分表示を減らせる場合があります。

特にUTF-8 BOMありとBOMなしの比較で効果を発揮することがあります。

また、文字コード統一作業前の確認にも便利です。

ただし、本当に文字コードが異なる場合は根本解決にはならないため注意してください。

まず正しい文字コードを指定し、その後に差分削減目的で利用するのがおすすめです。

VSCodeやサクラエディタで文字コードを確認する

WinMergeだけで原因が分からない場合は、外部エディターを活用すると効率的です。

特にVSCodeやサクラエディタは文字コード確認機能が充実しています。

エディター	確認できる内容
VSCode	文字コード・BOM・改行コード
サクラエディタ	文字コード・改行コード
Notepad++	文字コード・制御文字

VSCodeでは画面右下を見るだけで現在の文字コードを確認できます。

また、ワンクリックでUTF-8やShift_JISへ切り替えて再読み込みすることも可能です。

サクラエディタは日本語環境との相性が良く、Shift_JIS系ファイルの確認に向いています。

文字コードだけでなく、BOMや改行コードも同時に確認できるため原因特定がしやすくなります。

WinMergeだけで解決できない場合は、VSCodeなどで文字コードを確認すると原因を特定しやすくなります。

Word・Excelファイルで文字化けする場合の対処法

WordやExcelファイルは通常のテキストファイルではありません。

そのため、WinMergeで直接比較すると正常に表示されないことがあります。

特に.docxや.xlsxは内部的に複数のXMLファイルと圧縮データで構成されています。

その結果、意味不明な記号や大量の差分が表示される場合があります。

ファイル形式	比較方法
.docx	TXTまたはPDFへ変換
.xlsx	CSVへ変換
.csv	WinMergeで比較可能
.txt	WinMergeで比較可能

特にExcelデータを比較する場合はCSVへ変換するのがおすすめです。

CSVに変換すると文字コード確認も行いやすくなります。

また、契約書や仕様書などのWordファイルはTXT保存して比較すると文章差分だけ確認しやすくなります。

WordやExcelを直接比較している場合は、まずテキスト形式へ変換してから比較してください。

文字コードを変更しても直らない場合は、ファイル形式そのものが原因になっている可能性があります。

WinMergeの文字コード指定でよくある質問

WinMergeの文字コード指定については、設定方法以外にも多くの疑問があります。

特に文字化けや不要な差分が発生したときは、原因が複数考えられるため判断に迷いやすくなります。

ここでは、実際によくある質問とその対処法をまとめて解説します。

よくある質問	結論
UTF-8なのに文字化けする	BOMや判定ミスを確認する
Shift_JISとUTF-8はどちらを選ぶべき？	基本はUTF-8
自動判定は信用できる？	通常は問題ないが万能ではない
デフォルト設定は変更できる？	変更可能
不要な差分を減らしたい	比較設定を調整する

UTF-8なのに文字化けするのはなぜ？

UTF-8を指定しても文字化けする場合があります。

その原因として多いのが、BOMあり・BOMなしの違いです。

同じUTF-8でも、ファイル先頭にBOMが付いているかどうかで判定結果が変わることがあります。

また、実際にはUTF-8ではなくShift_JISで保存されているケースも珍しくありません。

特に複数のソフトを経由して編集したファイルでは、途中で文字コードが変換されている場合があります。

UTF-8で文字化けする場合は、UTF-8 BOMあり・なしの両方とShift_JISを確認するのがおすすめです。

Shift_JISとUTF-8はどちらを選べばよい？

迷った場合はUTF-8を選ぶのが基本です。

現在のWeb開発環境やGit管理環境では、UTF-8が標準的に利用されています。

Windows・Mac・Linuxのどの環境でも扱いやすい点も大きなメリットです。

ただし、古い業務システムやCSVデータではShift_JISが使われているケースがあります。

利用環境	推奨文字コード
Web開発	UTF-8
Git管理	UTF-8
CSV比較	Shift_JISまたはUTF-8
古い業務システム	Shift_JIS

現在の標準はUTF-8ですが、CSVや古いWindows環境ではShift_JISも候補になります。

自動判定は信用しても大丈夫？

通常の利用であれば、自動判定のままでも問題ないケースが多くあります。

特にUTF-8 BOMありのファイルは比較的正確に判定されます。

しかし、BOMなしUTF-8や英数字中心のファイルでは誤判定が発生することがあります。

また、日本語がほとんど含まれていないソースコードやログファイルも判定が難しくなります。

文字化けした場合は、自動判定を信用しすぎず手動指定を試してください。

普段は自動判定、問題発生時は手動指定という使い分けがおすすめです。

デフォルトの文字コードを固定できる？

WinMergeでは既定の文字コードを変更できます。

毎回UTF-8やShift_JISを指定するのが面倒な場合に便利です。

設定はオプション画面から行えます。

編集をクリックする
オプションを開く
コードページ設定を選択する
既定の文字コードを指定する

Web開発やGit利用が中心であれば、UTF-8を既定に設定する方法がおすすめです。

反対に、業務システムのCSV比較が多い場合はShift_JISを既定にする選択肢もあります。

利用頻度の高い文字コードを既定にすると、比較作業を効率化できます。

WinMergeで不要な差分を減らす方法は？

不要な差分は文字コード以外の設定でも減らせます。

特に空白や改行コードの違いは、大量差分の原因になりやすいポイントです。

設定	効果
空白無視	インデント差分を減らす
行末空白無視	不要変更を減らす
大文字小文字無視	英字比較を簡略化する
改行コード無視	CRLFとLFの差分を減らす