サイトが文字化けするときの直し方 — 宣言は3か所にあり、勝つのは1つ

公開 2026-10-25 ／ 更新 2026-10-25 ／ 文：スブリ

先に結論

サイトが文字化けしているとき、やってはいけないのは「ブラウザの設定を確認してください」と案内することです。 Chromeにはエンコードを切り替える機能がもうありません。 閲覧者側では直せないので、直すのは配信する側だけです。

そして、文字コードの宣言は3か所にあります。食い違ったとき、勝つのは1つだけです。 Chrome 152 で11パターン動かして確かめました。

症状から当たりをつけてください。

宣言は3か所にある。勝つのは1つ

11パターンを実測した

HTTPヘッダ・meta・BOM の組み合わせを変えたページをローカルで配信し、 Chrome 152 が最終的にどの文字コードで読んだか（document.characterSet）を取りました。

4行目が、この記事で一番伝えたいところです。 <meta charset="utf-8"> と正しく書いてあるのに、 HTTPヘッダが shift_jis だと化けます。 HTMLをいくら直しても直りません。

優先順位

実測から、順位がはっきりします。

Chrome の開発者向けドキュメントにも、同じ順番の記述があります。 document.characterSet は まずHTTPヘッダの値になり、無ければ <meta> の charset 属性の値になる、と説明されています。

「metaを直したのに直らない」の正体

HTTPヘッダは、HTMLの中には書いてありません。 だからソースを見ても気づけません。開発者ツールで確認します。

# コマンドラインで見るのが一番早い
curl -sI https://example.com/ | grep -i content-type

# こう返ってくれば、HTMLの meta は無視されている
Content-Type: text/html; charset=Shift_JIS

開発者ツールなら、Networkタブで該当のドキュメントを選び、 Response Headers の Content-Type を見ます。

charset= が付いていたら、それが答えです。 HTMLの meta は読まれません。サーバー側の設定を直す必要があります。

宣言が無いとどうなるか

実測

HTTPヘッダにも meta にも何も書かず、BOMも無い場合です。表3の3行目と8行目がそれにあたります。

宣言が無いと、UTF-8として読まれます。 中身がUTF-8なら偶然うまくいき、Shift_JISなら化けます。

「指定しないとShift_JISで読まれる」は、もう逆

2010年代前半に書かれた解説には、 「charsetを指定しないと、既定のShift_JISで読まれてしまう」という説明がよく出てきます。 当時の日本語環境ではそのとおりでした。

いまは逆です。実測のとおり、宣言が無ければUTF-8として扱われます。

古い静的ページだけが化けるという症状は、たいていこれです。 昔はShift_JISで保存しておけば勝手に読まれていたものが、いまは読まれません。 ファイルをUTF-8に変換して、<meta charset="utf-8"> を書くのが正解です。

閲覧者側では直せない

エンコードの切り替えは無くなった

「表示メニューからテキストエンコーディングを切り替えてください」という案内を見かけますが、 いまのChromeにその項目はありません。 Chrome 55（2016年）でエンコードメニューが削除された、と複数の技術者が記録しています。

ISO-2022-JPの自動判定も削除された

さらに新しい動きがあります。Chrome公式のリリースノートに、こう書かれています。

「ISO-2022-JP を指定すれば直る」という解説は、方向が逆です。 ブラウザは日本語の文字コードを推測する機能を減らしています。 推測に頼る設計から離れて、正しく宣言するしかありません。

宣言より前に、何も出力しない

「1ページだけ化ける」ときに一番多い原因です。 <meta charset> は <head> の先頭近くに書いてあるはずなのに、 その前に別のものが出力されているパターンです。

BOMは厄介です。目に見えないのに本文として扱われ、 しかも文字コードの宣言としては最優先で効きます（表4）。 「BOMがあるからUTF-8で読まれて正常」なのか「BOMが本文に出てレイアウトが崩れている」のかは別の話なので、 BOM付きで保存しないのが無難です。

先頭バイトを見れば確認できます。

# 先頭にBOM（ef bb bf）が付いていないか
head -c 3 index.html | xxd

# 付いていればこう出る
00000000: efbb bf                                  ...

どこを直すか

優先順位のとおり、上から順に潰します。下だけ直しても上が勝ちます。

<meta charset> には置き場所の決まりがあります。MDNによれば 「文書の最初の1024バイトの中に完全に収まっている必要があります」。 <head> を開いたらすぐ書く、と覚えておけば外しません。

化け方を見れば、元の文字コードが分かる

化けた文字列そのものが手がかりになります。 「文字化けテスト」という同じ文字列を、組み合わせを変えて変換したものを並べます。

見た目の特徴がはっきり分かれるので、逆引きできます。

いちばん上が圧倒的に多いです。 「譁」「蟄」「縺」のような日常で使わない漢字が並んでいたら、UTF-8をShift_JISとして読んでいると思って、 まず HTTPヘッダ を疑ってください。

切り分けの手順

上から順にやれば、3分で原因が決まります。

1と2がずれていたら、どこかに別の宣言があります。 2が意図した値なのに化けているなら、文字コードの問題ではなくデータそのものが壊れています。

AIに任せるときの注意

判定の目安です。答えに「ブラウザの設定」「ISO-2022-JP」「Shift_JISを指定」が出てきたら、情報が古いと思ってください。

よくある質問

meta charset を直したのに変わりません

HTTPヘッダが別の値を送っています（詳しく）。 curl -sI で Content-Type を確認してください。 charset= が付いていれば、HTMLの meta は無視されます。

ブラウザのエンコード設定はどこですか

Chromeにはありません。Chrome 55で削除されています（詳しく）。 閲覧者側では直せないので、配信側を直してください。

Shift_JIS や ISO-2022-JP を指定すれば直りますか

直りません。MDNは <meta charset> の値は 「"utf-8" と一致する必要がある」としています。 Chromeは ISO-2022-JP の自動判定をセキュリティ上の問題を理由に Chrome 139 で削除しました（詳しく）。

1ページだけ化けます

そのページだけ宣言より前に出力があります（表7）。 デバッグ出力、警告、BOM、ファイル先頭の空白を疑ってください。

古いページだけ化けます

ファイルがShift_JISのままで、宣言が無いためです。 宣言が無いときの既定はUTF-8に変わりました（表6）。 昔は勝手に読まれていたものが、いまは読まれません。

一部の文字だけ化けます

全体が読めているなら、文字コードの宣言は合っています。 データそのものが、保存の時点で壊れています。 データベースに入れるときに化けている場合は MySQLの「Incorrect string value」の直し方 を見てください。

先頭に見慣れない文字が出ます

BOMが本文として表示されています。 head -c 3 で ef bb bf が出るか確認し、 「UTF-8（BOMなし）」で保存し直してください（表8）。

BOMを付けておけば安全ですか

文字コードの判定としては最優先で効きますが（表4）、 本文として表示されたり、他の処理を壊したりします。 付けないほうが無難です。

まとめ

• 宣言は3か所にある。強い順に BOM → HTTPヘッダ → <meta charset>（Chrome 152で実測）。
• meta を直しても直らないのは、HTTPヘッダが勝っているから。curl -sI で確認する。
• 宣言が無いとUTF-8として読まれる。「指定しないとShift_JISになる」は、いまは逆。
• 閲覧者側では直せない。Chromeはエンコードの切り替えを削除している。
• Chromeは ISO-2022-JP の自動判定をセキュリティ上の理由で削除した（Chrome 139・公式）。推測に頼らない。
• MDNは <meta charset> の値を "utf-8" と一致する必要があるとしている。答えは1つしかない。
• <meta charset> は最初の1024バイト以内に置く。
• 1ページだけ化けるなら、宣言より前の出力（デバッグ・警告・BOM・空白）を疑う。
• 切り分けはヘッダ → document.characterSet → BOM → ファイルの実体の順。