ITエンジニアにお勧めの本 ↗
技術スキル以上に大切な「考え方」をアップデートできる。世界基準の効率的な仕事術が学べます。
文系社会人のためのIT資格の歩き方: 文系のあなたに最適な道をご提案します (YKcreate kiki)
ロードマップが非常に明確。キャリアプランを見据えた、無駄のない学習順序を提案してくれます。
エンジニアを説明上手にする本 相手に応じた技術情報や知識の伝え方
「伝える技術」もエンジニアの重要なスキル。相手の視点に立った、具体的な説明のコツが満載です。
技術広報入門 ー テックブログから始めるエンジニアカルチャーのつくり方
テックブログを入口にエンジニア組織の文化をどう設計し、育てていくかという実践論が学べます。
「バッチファイルを作って実行したはいいものの、画面に表示される日本語がすべて文字化けして読めない……」 「最近のモダンなエディタでファイルを保存したら、急にバッチファイルがエラーを起こすようになった……」
Windows環境で自動化スクリプトを作成する際、このような文字化けのトラブルに直面して困った経験はないでしょうか。近年、Windows以外の環境を含む開発ではUTF-8が一般的になり、Windowsの従来型のバッチファイル環境との間で文字コードの違いが問題になることがあります。
この記事では、バッチファイルで日本語が文字化けしてしまう根本的な原因を解き明かし、chcpコマンドの活用やエディタの設定変更といった具体的な解決策を分かりやすく解説します。最後までお読みいただければ、環境に合わせた「batファイル文字化け対策」が身につき、日本語を含むログ出力やメッセージ表示を意図通りにコントロールしやすくなります。
バッチファイル（.bat）で文字化けが発生する原因
バッチファイルを実行したときに文字化けが起きるのは、 「バッチファイルのエンコーディング」 と 「cmd.exeがその文字列を解釈する際のコンソールコードページ」 が一致していないことが主な原因です。
Windowsのコンソールコードページとバッチファイルの相性
日本語Windowsの従来の環境では、コマンドプロンプトのコンソールコードページとしてCP932（いわゆるShift-JIS系）が使われるケースが多くあります。
そのため、昔ながらのメモ帳などで作成したバッチファイル（CP932保存）であれば文字化けせずに動作していました。しかし、VS Codeなど近年のテキストエディタではUTF-8が一般的です（ファイルごとにエンコーディングは変更可能）。UTF-8で保存された文字列を、CP932など別のコードページとして解釈すると、元の文字とは異なる文字列として解釈され、文字化けが発生します。
なお、現在のWindows環境では設定によってUTF-8（CP65001）が使用されている場合もあります。実際のコードページは、コマンドプロンプトで以下のコマンドを実行することで確認できます。
chcpActive code page: 932（※932ならCP932、65001ならUTF-8として動作しています）
Shift-JISからUTF-8への移行に伴うトラブル
近年、GitGit [ギット]ソースコードの変更履歴を管理する分散型バージョン管理システムでのソースコード管理やクロスプラットフォームでの開発が当たり前になり、文字コードはUTF-8への統一が進んでいます。
これに伴い、バッチファイルもUTF-8で保存されることが増えましたが、ここに大きな罠があります。
- UTF-8（BOMなし） で保存されたバッチファイルをCP932環境のコマンドプロンプトで実行すると、日本語のメッセージやコメントが文字化けする場合があります。
- UTF-8（BOM付き） のバッチファイルは、Windowsのバージョンや実行環境によって挙動が異なります。古い環境や設定によっては先頭のBOM（Byte Order Mark）が不正な文字として誤認識され、実行エラー（「’@echo’ は、内部コマンドまたは外部コマンド… として認識されていません」など）を引き起こすことがあるため、既存環境との互換性に注意が必要です。
文字化けが発生する具体的なバッチファイル例
実際にどのようなバッチファイルで文字化けが起きるのか、具体的な例を見てみましょう。
VS Codeなどのエディタで、デフォルト設定の**UTF-8（BOMなし）**で以下のバッチファイル（sample.bat）を作成・保存したとします。
@echo offrem 文字コード：UTF-8（BOMなし）で保存
echo ========================================echo バッチファイルの文字化けテストecho ========================================
echo バックアップ処理を開始します...echo 処理を続行します...echo 処理が完了しました。
pauseこのバッチファイルを、CP932環境のコマンドプロンプトでそのまま実行すると、環境によっては日本語部分が文字化けする場合があります。（※実際の文字化け結果は、Windowsのバージョンや現在のコードページなどによって異なります）
なぜ文字化けしてしまうのか？
UTF-8では日本語1文字を通常3バイトで表現しますが、CP932では日本語の多くの文字が2バイトで表現されます。その結果、バイト列の区切り位置がズレてしまい、意図しない漢字や記号として画面に現れてしまうのです。
さらに、画面へのメッセージ出力だけでなく、以下のような実務上の処理でも予期せぬ不具合を引き起こす可能性があります。
- 日本語を含むフォルダ・ファイル操作:
cd "C:\作業フォルダ"やcopyコマンドで指定パスが正しく認識されず、「指定されたパスが見つかりません」などのエラーになる - コメント行（
remや::）: コメント内の日本語が文字化けしてもそれだけで必ず構文エラーになるわけではありませんが、文字化けがコマンド構文の解釈に影響すると意図しない結果になることがあります - 条件分岐（
if文）: 文字コードの不一致によって、日本語文字列が意図した文字列として解釈されず、比較結果が期待と異なる場合があります
この問題を解決するには、これから紹介するいくつかの対策を適切に組み合わせる必要があります。
対策1：chcpコマンドでコンソールのコードページを切り替える
最も手軽な方法の一つが、バッチファイルの内部でコマンドプロンプトのコンソールコードページをUTF-8に変更することです。これには chcp（Change Code Page）コマンドを使用します。
UTF-8を指定する「chcp 65001」の書き方
UTF-8を表すコードページ番号は 65001 です。バッチファイルの先頭付近で chcp 65001 を実行することで、実行中のコンソールのコードページをUTF-8に変更できます。
なお、chcp 65001 はバッチファイルそのものの文字コードをUTF-8に変換するコマンドではありません。実行中のコンソールで使用するコードページをUTF-8（CP65001）に変更します。
以下は、UTF-8（BOMなし）で保存したバッチファイルをUTF-8環境で実行する際の基本的な記述例です。
@echo offrem 文字コードをUTF-8（コードページ65001）に変更するchcp 65001 >nul
echo ========================================echo バッチファイルの文字化け対策テストecho ========================================
echo 処理を続行します...pauseバッチファイル冒頭に記述する際の注意点
chcp 65001 を利用する際は、以下のポイントに注意してください。
- バッチファイル自体の保存形式:
chcp 65001を記述していても、バッチファイル本体がCP932で保存されている状態で日本語のコードを書くと、ファイル読み込みの段階ですでに文字化けします。UTF-8で管理する場合に、chcp 65001を冒頭付近で実行してコンソールをUTF-8に合わせる方法があります。 - 標準出力のフォント: コンソールで使用するフォントによっては、コードページが正しくても一部の文字を表示できない場合があります。日本語を表示する場合は、コマンドプロンプトのプロパティから「ＭＳ ゴシック」など日本語グリフを含むフォントを使用してください。
>nulの活用:chcp 65001を実行すると、画面に「アクティブなコードページ: 65001」というメッセージが表示されます。バッチファイルの見た目をすっきりさせたい場合は、上記サンプルコードのように>nulをつけて標準出力を非表示にすると便利です。- コマンドによっては不具合が起きる可能性:
chcp 65001は手軽で有用な方法ですが、万能の解決策ではありません。環境やWindowsのバージョン、あるいはfor /fやfindstrなどの特定のコマンドを使用した場合、chcp 65001を指定していても予期せぬ不具合や文字化けが起きることがあります。
対策2：エディタ側で「CP932（ANSI）」として保存する（バッチを変更しない場合）
「社内システムや既存ルールの都合でバッチファイル内に chcp コマンドを追加したくない」「スクリプト側は一切いじらずに実行したい」という場合は、エディタ側でファイルの保存文字コードを 「CP932（ANSI）」 に変更して保存するのが確実な解決策です。
Windowsのコマンドプロンプトは日本語環境においてデフォルトでCP932を採用しているケースが多いため、バッチファイル本体が最初からCP932で書かれていれば、文字コードの切り替えを行わなくてもそのまま綺麗に日本語が表示されます。
エディタでのCP932保存手順
Windows標準メモ帳の場合
- メニューの「ファイル」から「名前を付けて保存」を選択します。
- 保存ダイアログ下部にある「エンコード」のプルダウンから、 「ANSI」 を選択します。（日本語Windowsでは、「ANSI」と表示された場合にシステム標準のCP932として扱われることがあります）
- ファイル名を指定して保存します。
【注意点】「BOM付きUTF-8」の挙動差について
文字コードを意識したことがある方の中には、「UTF-8にBOM（Byte Order Mark）を付ければ、Windowsが自動判別して文字化けが直るのでは？」と考える方がいらっしゃいます。
しかし、UTF-8のBOMに対する cmd.exe の挙動は、Windowsのバージョンや実行環境によって異なります。そのため、BOMの有無だけで互換性を判断するのではなく、実際の実行環境で確認することが重要です。
近年のWindows 10やWindows 11の標準的な環境であれば、BOM付きUTF-8のバッチファイルであっても cmd.exe がBOMをスキップして正しく処理できるケースが多くなっています。
しかし、古いWindows環境や特定の実行方法（タスクスケジューラ経由での実行など）との組み合わせでは、依然として以下のような問題が起こる可能性があります。
- BOMがUTF-8として期待どおりに扱われないケース: 実行環境によっては、ファイル先頭のBOMをUTF-8の識別情報として期待どおりに扱えず、文字化けや実行時の問題につながる場合があります。
- BOMが正しく処理されず、1行目のコマンドの解釈に影響するケース:
cmd.exeがBOMのバイト列（EF BB BF）をファイル先頭の文字としてそのまま読み取ってしまい、1行目の@echo offなどの先頭に不要な文字が付いたような状態になり、コマンドが正しく認識されず実行エラーが発生することがあります。
そのため、環境や実行方法を限定せず高い互換性と安全性を確保したい場合は、 「CP932」または「UTF-8（BOMなし）＋ chcp 65001」 を選ぶのが確実です。
まとめ：環境に合わせた文字コード対策を選ぼう
今回は、Windowsのバッチファイルで発生する文字化けの原因と、正しく日本語を表示させるための具体的な対策を解説しました。
実務においては、バッチファイルのエンコーディングと実行環境のコードページに合わせて、以下のパターンのいずれかを選択するとよいでしょう。
| バッチファイル | 実行環境のコードページ | 対応 |
|---|---|---|
| CP932 | CP932 | そのまま実行 |
| UTF-8（BOMなし） | CP932 | chcp 65001 などでUTF-8環境に合わせる |
| UTF-8 | CP65001（UTF-8） | UTF-8環境として利用 |
| UTF-8（BOM付き） | Windowsのバージョン・環境により異なる | 実際の実行環境で互換性を確認する |
- 対策1: UTF-8で管理したい場合は、UTF-8（BOMなし） で保存し、スクリプト冒頭に
chcp 65001 >nulを記述することで実行環境のコードページをUTF-8に合わせる方法があります。 - 対策2: 既存のWindows業務環境などでCP932のバッチをそのまま維持する方が適切な場合は、エディタで CP932（ANSI） として保存します。
ご自身のプロジェクトや運用の都合に合わせて、適切な対策を選択してください。文字化けストレスのない快適なWindows自動化環境を手に入れましょう。
以上で本記事の解説を終わります。
よいITライフを！
ITエンジニアにお勧めの本 ↗
エンジニアが知っておきたい思考の整理術 複雑な情報を【理解する】【伝える】テクニック
思考の整理というテーマを、実務ですぐに使える具体的な「技術」として落とし込んだ一冊です。
おすすめ
1 / 5人気記事
- 1
- 2
- 3
- 4
- 5
思考の整理というテーマを、実務ですぐに使える具体的な「技術」として落とし込んだ一冊です。