HTMLが文字化けしたときの直し方 化ける場所を先に決める切り分けの順番

自社サイトのページを開いたら、日本語が「譌･譛ｬ隱」のような記号の列に変わっていた。

メールで届いたHTMLのファイルをiPhoneで開いたら、読める文字が1つもなかった。そういう経験のある経営者やWeb担当者に向けて、この記事を書いています。

結論から言います。文字化けは、直す前に「どこで化けているか」を決めると、原因が3つほどに絞れます。

ページの中のmeta宣言をいじる前に、サーバーが出している指定、ファイルを保存した形式、読んでいる側の画面の順に、強い指定から確かめます。

HTMLの仕様（WHATWG）が決めている優先の順番は、先頭の目印（BOM）、サーバーが送る指定、ページの中のmeta、読む側の推測の順です。サーバーの指定は、ページの中のmetaに勝ちます。

この点は、ブラウザ2種で実際に動かして測りました。結果は、後ろの節に表で載せています。

この記事の軸は、「文字化けの原因の切り分け順」です。化けた場所から逆にたどって、直す場所を1つに決める手順を書きます。

metaタグ全般の説明は、既存の記事「metaタグとは Googleが使うものと消してよいものの分け方と確かめ方」に任せます。そこにある文字コードの位置（先頭から1024バイト以内）の話は繰り返さず、今回は「それでも化けるとき」を扱います。

先に答え：文字化けについて、確かめられたこと

先に、この記事の結論を表にまとめます。右端の列は、答えの根拠にした資料です。

疑問	答え	根拠にした資料
文字コードは何で決まるか	先頭の目印（BOM）、サーバーの指定、ページ内のmeta、読む側の推測の順	HTMLの仕様（WHATWG）の「文字コードの決め方」の節
サーバーの指定とmetaが食い違ったら	サーバーの指定が勝つ	仕様と、ブラウザ2種での測定
新しく作るページの文字コードは	UTF-8。仕様が必須としている	HTMLの仕様（WHATWG）と、文字コードの仕様（Encoding Standard）
指定がまったく無いと	読む側が推測する。推測の結果は、ブラウザや読み方で変わった	ブラウザ2種での測定
メールが化けるのは	メールの部品ごとのヘッダーに書かれた指定が基準になる	電子メールの規格（RFC 2045・RFC 2047）
化けたページはAI検索に使われるか	公式に記載なし。確かめられた範囲は、後ろの節に書いた	Google・OpenAI・Anthropicの公式文書

表の2行目が、この記事でいちばん大事な点です。ページの中に正しいmetaを書いたのに化ける場合、サーバー側の指定が別の値を出している可能性があります。

この記事の読み方

最初の2つの節で、化ける場所の決め方と、化け方の見た目から原因を絞る方法を書きます。

次の節で、ブラウザが文字コードを決める順番を、測定した結果つきで示します。

そのあとに、iPhoneで開く場合、HTMLメールの場合、WordPressの場合を、場所ごとに書きます。最後に、検索エンジンやAIとの関係と、今日できる点検の表を置きました。

この記事の根拠にした資料

ここに書く内容は、2026年11月10日に開いた次の資料と、その日に自分で測った結果だけです。

資料	確かめたこと
HTMLの仕様（WHATWG）、2026年11月9日更新の版	文字コードの宣言の書き方と、文字コードの決め方の順番
文字コードの仕様（Encoding Standard）、2026年10月19日更新の版	UTF-8を使う決まりと、名前の一覧
電子メールの規格 RFC 2045・RFC 2047	メールの文字コードの指定と、件名の書き方
Googleの検索セントラル「Googleがサポートしているmetaタグ」、2025年12月10日更新	文字コードについての推奨
Googleのクローラーの概要、2026年6月12日更新	クローラーが扱う圧縮の種類
WordPressの開発者向け資料	ページの文字コードの出し方
弊社が自動操作のブラウザで測った結果	Chromium 145とWebKit 26.0での表示

測ったのは、パソコンの上のブラウザ2種です。iPhone本体は測っていません。そこは、該当する節に書きました。

Q&Aサイトで見かけた「Shift_JISで保存したら全部の環境で化けないか」という質問

先日、Q&Aサイトでこのような切実な悩みを拝見しました。

質問した方は、Windowsのメモ帳でHTMLを書き、ページの中でmetaにShift_JISと宣言して、保存形式はANSIにしていました。保存のときに警告は出ませんでした。

そのファイルをFTPで置けば、Windows、Mac、iPhone、Androidのどれで開いても化けないと考えてよいのか、という質問です。

質問の最後には、AIに聞くたびに答えが変わって困っている、とありました。

回答に書かれていたこと

回答は5件ありました。

ある回答は、断言はできないと書いたうえで、ファイルの保存形式、ページの中の宣言、サーバーが送る指定の3つがそろっている必要がある、と説明していました。

別の回答は、いまからならUTF-8で書いて、UTF-8で保存することを勧めていました。ページの中の宣言と、ファイルの保存形式は別のものなので、両方をそろえる、という説明も付いていました。

もう1件は、Shift_JISで作る理由を尋ねていました。丸で囲んだ数字のような環境依存の文字を使うときに注意が必要で、そのためにUTF-8へ移ってきた、という趣旨でした。

回答のどこまでが確かめられるか

「3つがそろっている必要がある」という説明は、仕様と測定で確かめられました。後ろの節で、表にしています。

「UTF-8が無難」という勧めも、仕様が新しいページにUTF-8を求めているので、裏が取れます。

一方で、メモ帳の「ANSI」保存が実際にどの文字コードのファイルになるかは、今日開いた一次資料では確かめられませんでした。この点は、保存したファイルの中身を実際に調べる方法を、後ろの節に書きます。

質問から読み取れる3つの疑問

この質問の背景には、3つの疑問があります。

1つ目は、ページの中の宣言と、ファイルの保存形式が別のものだという点が、見えにくいことです。

2つ目は、サーバーが送る指定の存在を知らないと、「宣言したのに化ける」理由が分からないことです。

3つ目は、OSやブラウザが違うと、同じファイルが違って見えるのではないかという不安です。

先に短く答える

結論は、保存形式、ページの中の宣言、サーバーの指定の3つが同じなら、測った範囲では、ブラウザの違いで化けることはありませんでした。

3つのうち1つでもずれていると、ブラウザは決まった順番で1つを選び、残りは無視します。その選ばれ方が、次の節以降の主題です。

切り分けの順番：どこで化けているかを先に決める

直し方の記事を読んで、ページの中のmetaを書き換えても化けが直らない。そういうときは、見ている場所が違います。

文字コードを決めているものは、化けた場所ごとに別です。先に場所を決めると、確かめる項目が減ります。

場所は4つに分けられる

次の表は、化けた場所ごとに、文字コードを決めているものと、最初に見る所をまとめたものです。

化けた場所	文字コードを決めているもの	最初に見る所
ブラウザで開いたホームページ	サーバーの指定、ページの中のmeta	ブラウザの開発者向け画面の通信欄にあるContent-Type
手元に保存したHTMLのファイル	ファイルの中のmetaと保存形式。サーバーは関わらない	ファイルを保存したときの文字コード
HTMLメール	メールの部品ごとのヘッダー	メールのソース（ヘッダー全文）
WordPressの画面や記事	WordPressの設定とテーマの出力	公開ページのソースの先頭と、サーバーの指定

場所が決まれば、次に見る項目も決まります。

4つの場所は、化けるときの仕組みがそれぞれ違うので、直す人も違うことがあります。

ブラウザで開いたホームページの場合

ホームページは、サーバーがページを送るときに、文字コードの指定を添えることがあります。これが、HTTPヘッダーのContent-Typeです。

仕様は、この指定がある場合は、ページの中のmetaより先に採用すると決めています。

サイトを作った制作会社と、サーバーを管理している会社が別のとき、この食い違いが起きやすくなります。

手元のファイルの場合

メールで添付されたHTMLファイルや、保存したHTMLのファイルを開くときは、サーバーが関わりません。

ファイルを開いたソフトは、ファイルの中のmetaと、ファイルの中身の並びから、文字コードを決めます。宣言が無いと、ソフトの推測に頼ることになります。

メールの場合

HTMLメールは、ホームページとは別の決まりで動いています。

メールの本文を入れた部品ごとに、ヘッダーで文字コードを指定する決まりです。メールの節で詳しく扱います。

場所が分からないときの確かめ方

ここまでの4つのうち、どこか分からないときは、別のブラウザで同じURLを開きます。

別のブラウザでも同じ化け方なら、ページかサーバーの側に原因があります。別のブラウザでは読めるなら、最初に開いたブラウザの設定や、そのブラウザが過去に覚えた指定を疑います。

次に、ほかの端末で同じページを開きます。端末によって変わるなら、読む側の問題です。

化け方の見た目から、原因を絞る

文字化けの見た目には、型があります。型を見分けると、どの組み合わせで読み違えたかが分かります。

次の表は、日本語の「日本語のテスト」という文字列を、わざと読み違えさせて出した結果です。ブラウザ2種で測り、結果が同じものを載せています。

見た目の型は3つある

見た目	何が起きているか	見たときに疑うこと
「譌･譛ｬ隱」のように、漢字と記号が混ざる	UTF-8で書かれた文字を、Shift_JISとして読んだ	metaやサーバーの指定がShift_JISになっている
読めない部分が、疑問符入りの置き換え記号に変わって並ぶ	Shift_JISで書かれた文字を、UTF-8として読んだ	metaやサーバーの指定がUTF-8になっている
「æ—¥」のように、アクセント付きの欧文字が並ぶ	UTF-8で書かれた文字を、西欧の文字コードとして読んだ	指定が無いか、サーバーが西欧の文字コードを送っている

どの型でも、元のファイルの中身が壊れているとは限りません。読み方が違うだけです。

置き換え記号が出たら、書き戻しても直らない

2つ目の型に出てくる置き換え記号（四角や菱形の中に疑問符が入った記号）は、読み取れなかった部分を置き換えたものです。文字コードの仕様が、読み取れないバイトをこの記号に置き換えると決めています。

置き換えられた時点で、元の文字の情報は表示の上から消えています。

化けた画面を見て、その文字をコピーして貼り直しても、元には戻りません。直すのは、読み方の指定です。元のファイルが残っている場所で、指定を直します。

化けた状態で上書き保存しない

置き換え記号が出ているページを、編集ソフトで開いたまま上書き保存すると、化けた文字がファイルに書き込まれます。

文字化けに気づいたら、まず、元のファイルのコピーを取ります。そのうえで、読み方を変えて確かめます。

一部だけ化けているときは

ページの全体は読めるのに、一部の文字だけが化けることがあります。

考えられる原因の1つは、使っている文字コードで表せない文字が混ざっていることです。後ろの節で、丸で囲んだ数字などを使って測った結果を載せます。

3つの型の使い分け

次の表は、見た目の型から、最初に確かめる指定をまとめたものです。

見た目の型	最初に確かめる所	次に確かめる所
漢字と記号が混ざる	サーバーの指定	ページの中のmeta
置き換え記号が並ぶ	ファイルの保存形式	ページの中のmeta
欧文字が並ぶ	指定が無いか	サーバーの指定

最初に見る所を決めて、そこで原因が見つからなければ、次の列に進みます。

ブラウザが文字コードを決める順番

ここからは、ブラウザがどの指定を採用するかを、順に見ていきます。

HTMLの仕様（WHATWG）の「文字コードの決め方」の節は、ブラウザが従う手順を書いています。2026年11月10日に開いた版で確かめました。

仕様に書かれた順番

仕様は、この手順の中で、文字コードに「確定」と「仮」の2段階の確からしさを付けています。

次の表は、仕様の手順を、強い順に並べたものです。

順番	見るもの	確からしさ
1	ファイルの先頭の目印（BOM）	確定
2	利用者がブラウザで手動で指定した文字コード	確定（任意）
3	サーバーが送る指定（Content-Type）	確定
4	ページの中のmeta（先頭付近を先読みして探す）	仮
5	同じ出どころの親ページの文字コード（埋め込みの場合）	仮
6	読む側の推測	仮
7	読む側の既定値。日本語の環境ではShift_JISが提案されている	仮

ページの中のmetaは、4番目です。サーバーの指定より弱く、先頭の目印よりも弱い位置にあります。

仕様は、仮の指定が見つかったあとで、それと食い違う宣言を見つけたときは、読み直してよいとも書いています。

先頭の目印（BOM）とは

BOMは、ファイルの先頭に付く、目に見えない数バイトの目印です。UTF-8のファイルでは、3バイトの並びが使われます。

BOMがあると、ブラウザは、サーバーの指定もmetaも見ずに、その文字コードで読みます。

埋め込んだ中身の文字コード

iframeなどで別のページを埋め込んだ場合、埋め込まれた側のページが宣言を持たなければ、同じ出どころの親ページの文字コードが使われます。仕様の5番目です。

埋め込みそのものの考え方は、既存の記事「iframeとは 埋め込みの判断と書き方」にあります。

ブラウザ2種で測った結果

仕様の順番が、実際のブラウザでも守られているかを、自動で操作したブラウザで測りました。

測ったのは、Chromium 145とWebKit 26.0です。WebKitは、iPhoneのSafariと同じ系統のエンジンです。ただし、iPhone本体では測っていません。

同じ日本語の文章を、文字コードと宣言を組み合わせて配り、読めるかどうかを見ました。自分のパソコンの上に置いた小さなサーバーから、ヘッダーつきで配っています。

指定をそろえたときと、ずらしたとき

組み合わせ	結果
UTF-8で保存、metaはUTF-8	読める
Shift_JISで保存、metaはShift_JIS	読める
Shift_JISで保存、metaはUTF-8	化ける（置き換え記号が並ぶ）
UTF-8で保存、metaはShift_JIS	化ける（漢字と記号が混ざる）

保存形式とmetaがそろっていれば、読めました。ずれると、必ず化けました。

サーバーの指定が加わったとき

組み合わせ	結果
UTF-8で保存、metaはUTF-8、サーバーはShift_JISを送る	化ける
UTF-8で保存、metaはShift_JIS、サーバーはUTF-8を送る	読める
Shift_JISで保存、metaはShift_JIS、サーバーはUTF-8を送る	化ける
UTF-8で保存、metaはUTF-8、サーバーは西欧の文字コードを送る	化ける

サーバーの指定が、metaに勝ちました。2つのブラウザで、同じ結果です。

質問者の疑問「宣言したのに化ける」の答えが、これです。ページの中の宣言が正しくても、サーバーが別の値を送っていれば、サーバーの値が採用されます。

指定が無いとき

組み合わせ	Chromium 145	WebKit 26.0
UTF-8で保存、指定が一切無い	化ける（欧文字の型）	化ける（漢字と記号の型）
UTF-8で保存、metaの文字コード名を存在しない名前にした	化ける（欧文字の型）	化ける（漢字と記号の型）

指定が無いときの化け方は、ブラウザで変わりました。仕様が、読む側の推測や既定値を許しているためです。

metaを書いたつもりでも、文字コードの名前が違えば、指定が無いのと同じになります。UTF-8の綴りは「utf-8」と書きます。

BOMがあるとき

UTF-8のファイルにBOMを付け、metaにはShift_JISと書いて測りました。2つのブラウザとも、UTF-8として読み、正しく表示しました。

仕様の順番どおり、先頭の目印がmetaに勝っています。

metaの位置を後ろにしたとき

仕様は、文字コードのmetaを先頭1024バイト以内に置くよう求めています。この点は、既存の記事「metaタグとは」で扱いました。

今回は、metaをファイルの3000バイト目より後ろに置いて測りました。2つのブラウザとも、読めました。

読めたのは、見つけた宣言に合わせて、ブラウザが読み直したためと考えられます。ただし、仕様の決まりは1024バイト以内です。測って読めたから後ろでよい、という話ではありません。

数値文字参照を使った場合

文字を、「日」のような数値の書き方に直したファイルも測りました。指定が一切無い状態です。

2つのブラウザとも、正しく日本語を表示しました。この書き方は、ファイルの文字コードに左右されないためです。

ただし、日本語の文章を全部この形にするのは、保守が難しくなります。緊急の回避として知っておく程度で十分です。

文字コードと圧縮は別の話

Googleのクローラーの概要には、「gzip、deflate、Brotli」という圧縮の種類が出てきます。名前が似ているContent-Encodingですが、これは通信の圧縮の話です。

文字コードとは別のものです。ここで文字化けの原因を探すと、遠回りになります。

Shift_JISとUTF-8のどちらを使うか

質問者は、Shift_JISで作ろうとしていました。いまから新しいページを作るなら、どちらがよいかを、仕様で確かめます。

仕様が求めていること

HTMLの仕様は、文字コードの宣言について、UTF-8を使うことを求めています。宣言があってもなくても、実際の文字コードはUTF-8でなければならない、と書いています。

文字コードの仕様（Encoding Standard）にも、書き手はUTF-8を使うこと、という決まりがあります。

仕様は、さらに、書くためのソフトが新しい文書を作るときに、UTF-8を既定にすることも求めています。

Shift_JISで書くとどうなるか

Shift_JISで保存してShift_JISと宣言したページは、測った範囲では読めました。2つのブラウザが、いまもShift_JISを読めるからです。

ただし、仕様の適合から外れた書き方です。仕様は、ほかの文字コードでは、フォームの送信やURLの組み立てで、予想外の結果になることがあると書いています。

名前の対応：Windows-31Jという別名

文字コードの仕様の一覧では、Shift_JISという名前の文字コードに、「windows-31j」や「ms932」といった別名が付いています。

HTMLにShift_JISと書いても、Windows-31Jと書いても、ブラウザは同じものとして扱います。回答にあった「ANSI保存の実体はWindows-31J」という説明は、この別名の関係と合っています。

丸で囲んだ数字は読めるか

丸で囲んだ数字や、株式会社を1文字にした略号を、Shift_JISで保存して測りました。metaもShift_JISです。2つのブラウザで、そのまま表示されました。

UTF-8で保存した場合も、同じ文字が正しく表示されました。

判断：新しく作るならUTF-8

次の表は、新しいページで文字コードを選ぶときの判断をまとめたものです。

場面	選ぶもの	理由
これから新しく作るページ	UTF-8	仕様が必須としている
すでにShift_JISで動いているページ	直す必要があるか確かめる	読めていれば、まず保存形式と宣言とサーバーの指定をそろえる
古いページをUTF-8へ移す	ファイルの保存形式、meta、サーバーの指定を同時に変える	1つだけ変えると、ずれて化ける

古いページを変えるときは、3つを同時に変えます。1つだけ直すと、測定の表のとおり、別のずれが生まれて化けます。

iPhoneでHTMLファイルが化けるとき

Q&Aサイトでも、検索の候補でも、「iPhone」と組み合わせた質問が多く出てきます。

メッセージやメールで受け取ったHTMLのファイルが、iPhoneで化ける、という相談です。ここでは、手元のファイルの場合を考えます。

公式資料に書かれていたこと

Appleのサポートサイトにある、iPhoneユーザガイドの「ファイル」のページを2つ開きました。ファイルやフォルダを変更するページと、検索して表示するページです。

2026年11月10日に確かめた範囲では、どちらにも、HTMLファイルの文字コードの扱いについての記載は見つかりませんでした。

そのため、iPhoneだけで起きる特別な文字化けの原因があるのか、公式の資料からは言えません。以降は、測定で確かめられた範囲の一般的な切り分けとして書きます。

手元のファイルは、サーバーの指定が無い

手元のファイルを開くときは、サーバーが送る指定が存在しません。ファイルを開いたソフトは、ファイルの中のmetaと、先頭の目印と、推測で決めます。

ブラウザ2種で、HTTPを通さず、手元のファイルとして開いて測りました。

手元のファイルで測った結果

ファイルの中身	Chromium 145	WebKit 26.0
UTF-8で保存、metaあり	読める	読める
UTF-8で保存、指定が一切無い	読める	化ける
Shift_JISで保存、metaあり	読める	読める
Shift_JISで保存、指定が一切無い	読める	読める
UTF-8にBOMを付けて保存、指定が一切無い	読める	読める

指定が無いUTF-8のファイルだけ、エンジンによって結果が分かれました。

仕様は、手元のファイルについて、UTF-8の並び方を調べて推測する方法が有効だと書いています。Chromiumは、この推測で読めたと考えられます。WebKitは、同じ条件で化けました。

つまり、指定の無いUTF-8のファイルは、パソコンのブラウザでは読めても、別のエンジンで化けることがあります。

送る側が直せること

送る側が直せるのは、次の3つです。

1つ目は、ファイルの中に、UTF-8のmetaを書くことです。測定の表で、metaがあるファイルは、どちらのエンジンでも読めました。

2つ目は、UTF-8のBOMを付けて保存することです。BOMがあれば、指定が無くても読めました。ただし、BOMは仕様が許容している範囲で、書き込みに使うソフトによっては、付けられないことがあります。

3つ目は、ファイルで渡さず、公開したページのURLで渡すことです。サーバー経由なら、サーバーが送る指定が加わるので、読む側の推測に頼りません。

受け取る側が試せること

受け取った側は、ファイルを書き換えずに、読み方だけを変えて確かめます。

ファイルを、パソコンのブラウザで開いてみます。パソコンで読めて、iPhoneで読めないなら、読み方の違いが原因です。

どちらでも化けるなら、ファイルの中の宣言か、保存形式がずれています。送り主に、UTF-8のmetaがあるかを尋ねるのが、近道です。

iPhoneの画面での具体的な操作は、Appleの公式資料で確かめられなかったので、書きません。

HTMLメールが化けるとき

HTMLメールは、ホームページのHTMLとは、文字コードの決め方が違います。

メールの規格（RFC）が、メールを部品に分けて、部品ごとに文字コードを指定する決まりを定めているからです。

メールの本文は、ヘッダーで決まる

電子メールの規格 RFC 2045は、本文の種類を示すContent-Typeの中で、charsetという項目を使って文字コードを指定すると書いています。

charsetは、文章の種類（text）のどの形式にも使える項目です。HTMLの本文も、プレーンテキストの本文も、それぞれの部品に付けます。

この指定が無いときは、US-ASCIIの文章として読む、と規格が決めています。日本語を書いたのにcharsetが無ければ、化ける前提になります。

実際のヘッダーの例

次の例は、Pythonの標準のメール機能で、日本語の件名とHTMLの本文を持つメールを作り、ヘッダーを出したものの抜粋です。2026年11月10日に作りました。

“`
Subject: =?utf-8?b?44GU5qGI5YaF77ya5paH5a2X5YyW44GR44Gu54K55qSc?=
Content-Type: multipart/alternative; boundary=”===”

Content-Type: text/plain; charset=”utf-8″
Content-Transfer-Encoding: base64

Content-Type: text/html; charset=”utf-8″
Content-Transfer-Encoding: base64
“`

テキスト版とHTML版の部品が、それぞれcharsetを持っています。メールの文字コードは、この行を見れば分かります。

件名は別の仕組み

件名は、本文とは別の決まりで書かれます。RFC 2047は、日本語などの文字を、「=?」で始まり「?=」で終わる形に包むと決めています。

例の「=?utf-8?b?…?=」は、UTF-8の文字をBase64という方式で書いた、という意味の包みです。

本文は読めるのに件名だけが化ける場合は、この包みの中の文字コード名か、中身がずれています。

本文の中のmetaについて

HTMLメールの本文の中にも、metaを書くことができます。

ただし、今日開いたRFC 2045とRFC 2047には、本文の中のmetaをメールを読むソフトがどう扱うか、という記載は見つかりませんでした。読む側のソフトの動作は、確かめられた範囲を超えるので、書きません。

確かな基準は、部品ごとのヘッダーのcharsetです。

送る側の点検

次の表は、HTMLメールを送る側が見る項目です。

点検すること	確かめ方	見つかったときの直し方
HTML版の部品にcharsetがあるか	届いたメールのソース（ヘッダー全文）を開く	配信の設定で文字コードを指定する
本文と件名で文字コードがそろっているか	ソースの件名の包みと、本文のcharsetを見比べる	配信の設定をUTF-8にそろえる
テキスト版も付いているか	ソースに、プレーンテキストの部品があるか	テキスト版も一緒に送る設定にする
本文の保存形式が、宣言と合っているか	配信に使う原稿の保存形式を調べる	原稿をUTF-8で保存し直す

配信用の画面で見た表示と、実際に届いたメールのソースを見比べると、ずれている場所が見つかります。

受け取る側の確かめ方

受け取った側で、メールが化けて見えるときは、ソースを開いて、HTML版の部品のcharsetを見ます。

charsetが書かれていてUTF-8なのに化けるなら、読むソフトの側の問題です。charsetが無い、または違う値なら、送る側の設定の問題です。

どちらか決まれば、直す人も決まります。

WordPressで化けたとき

WordPressで作ったサイトが化けたときも、同じ切り分けで進みます。

最初に、化けている場所を決めます。公開ページか、管理画面か、特定の記事だけかを確かめます。

WordPressが文字コードを出す仕組み

WordPressの開発者向け資料では、ページの文字コードを返す関数の説明があります。サイトの設定にある「ページとフィードのエンコーディング」の値を返し、値が空のときはUTF-8を返す、という動きです。

この値が、ページの先頭付近のmetaとして出力されるかどうかは、テーマ次第です。今日開いた資料では確かめられなかったので、出力の細かい形は書かず、次の弊社の実測で示します。

弊社のサイトで実測した結果

弊社のサイトは、WordPressで作っています。公開記事を新しい順に30本取得し、1秒以上の間隔を空けて、サーバーの指定とmetaを調べました。

2026年11月10日の結果は、30本すべてで、サーバーの指定が「text/html; charset=UTF-8」でした。ページの中のmetaも、30本すべてがutf-8で、先頭から145バイト目にありました。BOMが付いたページはありませんでした。

サーバーの指定とmetaが、同じUTF-8でそろっている状態です。測定の表で、読める組み合わせです。

化けたときの確かめ順

次の表は、WordPressのサイトが化けたときに、確かめる順番をまとめたものです。

順番	確かめること	方法
1	別のブラウザや別の端末でも化けるか	同じURLを開く
2	サーバーが送る指定	下のコマンドか、ブラウザの通信欄で見る
3	ページの中のmeta	ソースの先頭付近を見る
4	直前に変えたもの	テーマ、プラグイン、サーバーの設定の変更日を確かめる

2番目のコマンドは、サーバーが送る指定だけを表示します。

curl -sI https://自社のURL/ | grep -i content-type

「charset=UTF-8」と出れば、サーバーの指定はUTF-8です。ここがShift_JISや西欧の文字コードになっていれば、直す場所はサーバーの設定です。

直す人を決める

サーバーの指定がずれていたら、サーバーを管理している会社の仕事です。metaがずれていたら、テーマを管理している人の仕事です。

制作会社とサーバー会社が別のときは、症状の見た目の型と、確かめた2つの値を、そのまま伝えます。伝わる情報が多いほど、直るのが早くなります。

化けたページを、検索エンジンやAIはどう読むか

文字化けしたページが、検索結果やAIの回答にどう影響するかを、公式の資料で確かめました。

確かめられたことと、確かめられなかったことを分けて書きます。

Googleの文書に書かれていたこと

Googleの検索セントラルによると、「Googleがサポートしているmetaタグ」のページは、文字コードを示す2種類のタグ（metaのcharsetと、http-equivを使う形）について、ページの内容の種類と文字セットを定義するものと説明しています。

そのうえで、「可能な場合は、Unicode/UTF-8 を使用することをおすすめします。」（英語の原文を和訳）と書いています。2025年12月10日更新のページです。

Googleが推奨しているのは、仕様と同じUTF-8です。

AIの機能についての文書

Googleの「AI機能とウェブサイト」のページ（2025年12月10日更新）には、文字コードや、読めないページの扱いについての記載は見つかりませんでした。

OpenAIのクローラーの概要の文書と、Anthropicのクロールについてのヘルプにも、同じく記載は見つかりませんでした。

確かめた範囲を表にする

資料	文字コードについて確かめられたこと
Googleの「Googleがサポートしているmetaタグ」	UTF-8を推奨している
Googleの「AI機能とウェブサイト」	公式に記載なし
OpenAIのクローラーの文書	公式に記載なし
Anthropicのクロールについてのヘルプ	公式に記載なし

公式に書かれているのは、UTF-8を推奨するという1点です。

弊社の整理

ここからは、公式に記載がなく、弊社の整理として書きます。

化けた文字は、ページを読む側にとって、記号の並びです。記号の並びから、ページの内容を取り出すのは難しいと考えられます。

検索エンジンやAIが、化けたページをどう扱うかは、確かめられていません。ただ、人間が読めないページを、読み取って答えに使う場面は、想像しにくいところです。

ページを読み取れるかという点では、JavaScriptで描かれるページの問題と似ています。こちらは、既存の記事「JavaScriptで表示する内容はAIに読まれるか」で、確かめた範囲を書きました。

ページの先頭付近を、まとめて点検する

ページの先頭付近には、文字コードのほかにも、読む側が最初に見る指定が並びます。

ページの先頭1行にあたるdoctypeは、既存の記事「doctype htmlとは 読み方と書き方 無いと互換モードになる理由」に書きました。

doctypeと文字コードの宣言は、同じ「ページの先頭の約束」に入ります。両方を確かめておくと、読む側が迷う余地が減ります。

化けたときの切り分けを、4手にまとめる

ここまでの内容を、手順としてまとめ直します。

1手目：化けている場所を決める

ブラウザで開くホームページか、手元のファイルか、メールか、WordPressの画面か。場所が決まると、次に見るものが決まります。

別のブラウザや別の端末で、同じ化け方かどうかを、最初に見ます。

2手目：見た目の型を見分ける

漢字と記号が混ざるのか、置き換え記号が並ぶのか、欧文字が並ぶのか。型で、どの組み合わせで読み違えたかが分かります。

置き換え記号が出ているファイルは、上書き保存しません。

3手目：強い指定から順に確かめる

先頭の目印、サーバーの指定、ページの中のmetaの順です。

サーバーの指定は、通信欄か、curlのコマンドで見ます。ページの中のmetaは、ソースの先頭付近です。

4手目：直したら、3つ同時にそろえる

保存形式、ページの中のmeta、サーバーの指定。この3つを、同時にUTF-8へそろえます。

直したあとは、別のブラウザで、もう一度同じURLを開いて確かめます。

切り分けの対応表

見た目の型	場所	最初に直す所
漢字と記号が混ざる	ホームページ	サーバーの指定
置き換え記号が並ぶ	手元のファイル	元ファイルの保存形式
欧文字が並ぶ	ホームページ	指定が無いか、サーバーの指定
件名だけが化ける	メール	件名の包みの文字コード名
一部の文字だけが化ける	どこでも	表せない文字が混ざっていないか

よくある質問

Q1. HTMLが文字化けするのは、なぜですか

読む側が使った文字コードと、ファイルを保存した文字コードが違うからです。

違いが生まれる場所は、サーバーの指定、ページの中のmeta、ファイルの保存形式の3つです。

Q2. HTMLの文字化けは、どう直せばよいですか

先に、化けている場所を決めます。次に、見た目の型から、疑う指定を絞ります。

最後に、保存形式、meta、サーバーの指定を、同時にUTF-8へそろえます。

Q3. iPhoneでHTMLのファイルを開くと化けるのは、なぜですか

Appleの公式資料には、この点の記載が見つかりませんでした。

測定では、指定の無いUTF-8のファイルが、WebKitで化けました。送る側が、UTF-8のmetaを書くと、読める可能性が高まります。

Q4. HTMLメールが化けるのは、なぜですか

メールの部品ごとに付いたヘッダーのcharsetが、指定の基準です。

charsetが無いか、本文の保存形式とずれていると、化けます。件名は別の包みで書かれるので、件名だけが化けることもあります。

Q5. 化けたページは、SEOやAI検索に影響しますか

公式の資料には、文字化けとAI検索の関係についての記載は見つかりませんでした。

Googleは、UTF-8の使用を推奨しています。弊社の整理では、人が読めないページは、読み取る側にも使いにくいと考えています。

まとめ：化けた場所から、強い指定の順にたどる

文字化けは、直す前に、どこで化けているかを決めます。

場所が決まれば、強い指定から順に、先頭の目印、サーバーの指定、ページの中のmetaの順に確かめます。測定では、サーバーの指定がmetaに勝ちました。

新しく作るページはUTF-8です。保存形式、meta、サーバーの指定を、同時にそろえます。

iPhoneやメールは、公式資料に書かれた範囲だけが確かめられました。書かれていない部分は、一般的な切り分けとして扱っています。

今日できる点検

自社のサイトで、次の表の順に確かめてください。ブラウザの通信欄と、ページのソースの表示だけでできます。

点検すること	確かめ方	見つかったときの直し方
サーバーが送る指定がUTF-8か	通信欄で、Content-Typeを見る	サーバーの管理者に、UTF-8へ直してもらう
ページの中のmetaがUTF-8か	ソースの先頭付近を見る	テーマの出力を、UTF-8にそろえる
metaが、先頭から1024バイト以内にあるか	ソースの先頭からの位置を見る	metaを、headの先頭近くへ移す
保存形式がUTF-8か	編集ソフトの文字コード表示を見る	UTF-8で保存し直す
手元で渡すファイルに、metaが入っているか	ファイルの先頭付近を見る	UTF-8のmetaを足す
HTMLメールの部品に、charsetがあるか	届いたメールのソースを見る	配信の設定で、文字コードを指定する

ページを増やしても問い合わせが来ないなら、原因はページの外にあります。その場合は、下の入口からご相談ください。