や&が消えない・戻る原因｜二重エスケープの見分け方と直し方
ブログやWordPressの本文を編集していると、「 」や「&」が文字として画面にそのまま表示されたり、消したはずなのに保存すると復活したりすることがあります。これは文字化けではなく、HTMLエンティティが正しく変換されず、テキストとして残ってしまっている状態です。原因はほぼ「コピペ元に含まれるノーブレークスペース」と「二重エスケープ」の2パターンに絞られます。この記事では見分け方と、それぞれの直し方を解説します。
や&がそのまま表示されるのはなぜ？
HTMLエンティティとは、&（アンパサンド）や <（小なり）のようにHTMLで特別な意味を持つ文字や、キーボードから直接入力しにくい文字を、& や のような記法で表現する仕組みです。ブラウザは通常これを自動的に解釈して、元の文字（半角スペースや&）として表示します。
ところが次のような状態になると、エンティティが「解釈されるべき記号」ではなく「ただの文字列」として画面に出てしまいます。
- 本文の入力欄（ビジュアルエディタ）に、記号としての
という文字列がそのまま入力されている - すでにエンティティ化された文字列を、もう一度HTML変換ソフトやプラグインに通してしまい、
&の部分だけがさらに変換された（二重エスケープ）
見た目は同じ「 が表示される」という症状でも、原因によって直し方が変わります。
症状から原因を見分ける
| 症状 | 考えられる原因 |
|---|---|
単語間や改行の後ろに という文字列が大量に出る | WordPressの自動整形機能、またはWord/Excelからのコピペで混入したノーブレークスペース |
&nbsp; のように amp; が挟まって表示される | 二重エスケープ（すでにエンティティ化された文字列を再度変換した） |
& だけが & になって表示される | フォーム入力や保存処理で自動エスケープが二重にかかっている |
| コピペした瞬間は正常なのに、保存後に文字が化ける | エディタとデータベース側、両方でエスケープ処理が働いている |
まずソースコード表示（WordPressなら「テキストエディタ」「コードエディター」表示）に切り替え、&nbsp; のように & が二重になっていないかを確認するのが最初の一手です。ここで amp; が挟まっていれば二重エスケープ、挟まっていなければコピペ由来の混入と判断できます。
WordPressで が消えない・大量発生する場合の対処法
WordPressでは、ビジュアルエディタが持つ自動整形機能（wptexturize という機能）が、改行やスペースを保持する目的で を自動的に挿入することがあります。加えて、Word・Excel・Googleドキュメントで作成した文章をそのままコピペすると、見た目には普通のスペースに見えても、実体は「ノーブレークスペース」（U+00A0）という特殊な空白文字が含まれていることがあり、これがエディタによって に変換されて表示されます。
対処法は次の順に試すのが現実的です。
- コピペ元を経由させる — Word・Excel・Googleドキュメントの文章は、一度メモ帳などの「書式のないテキストエディタ」に貼り付けてコピーし直してから、ブログの編集画面に貼り付けます。これだけでノーブレークスペースの混入自体を防げます。
- コードエディター表示で直接削除する — WordPressの「テキストモード」「コードエディター」に切り替え、
を検索して手動で削除、または半角スペースに置き換えます。 - 既存記事をまとめて直す — 本文をいったんコピーし、後述のHTMLエンティティ変換ツールで「デコード」して元の文字に戻し、余分な空白を整理してから貼り戻す方法もあります。
なお、wptexturize を無効化するテーマ設定やプラグインを紹介しているサイトもありますが、サイト全体の表示に影響する変更のため、適用前に必ずバックアップを取り、可能であればステージング環境で確認してから本番に反映することをおすすめします。
&が&amp;になる「二重エスケープ」の直し方
こちらはWordPress特有の問題ではなく、フォームやCMS、プログラムで文字列をHTMLとして出力する際に起きる、より一般的な現象です。
& という文字は、HTMLとして出力するときに & へ変換（エスケープ）する必要があります。ところが、次のような場合にすでにエスケープ済みの文字列に対して、もう一度同じ処理をかけてしまうことがあります。
- データベースに保存する前と、画面に表示する前の両方でエスケープ処理をしている
- テンプレートエンジンの自動エスケープ機能と、手動のエスケープ処理が二重に働いている
- 他のツールで一度変換した文字列を、気づかずにもう一度変換ツールへ通した
この場合、直し方はシンプルで、該当箇所を一度「デコード」して元の状態（& や半角スペース）に戻してから、必要な場所だけ改めて「エンコード」し直すのが確実です。手作業で amp; を探して削除するより、変換ツールに通したほうが早く、かつ数え間違いも防げます。
HTMLエンティティ変換ツールでは、テキストを貼り付けて「デコード」を選ぶだけで & などのエンティティを元の文字に戻せます。逆に、特殊文字を含む文章を安全にHTMLへ埋め込みたいときは「エンコード」で変換できます。ブラウザ内で処理が完結するため、サーバーに送信されない点も、社内文書や下書き段階の文章を扱う際に安心材料になります。
見落としがちな落とし穴：ツールで直そうとして三重エスケープになるケース
他のサイトではあまり触れられていませんが、実務でよく起きる失敗が「二重エスケープを直そうとして、逆に三重エスケープにしてしまう」というものです。
すでに &nbsp;（二重エスケープの状態）になっている文章に対して、原因を確認せずにいきなり変換ツールで「エンコード」をかけると、& の部分がさらに変換されて &amp;nbsp; という三重エスケープになってしまいます。逆に、単純な の混入（一重）だと思って「デコード」を2回かけると、今度は数値文字参照が壊れて意図しない文字が出てくることもあります。
これを避けるコツは、変換をかける前に、必ずソースコード表示で amp; が何個挟まっているかを目視で確認してから、デコードの回数を決めることです。1回で直らない場合は、1段階ずつデコードして途中経過を確認しながら進めると、意図しない変換を防げます。
メールの文字化けとは別の問題であることに注意
「文字が正しく表示されない」という症状は、メールが文字化けする原因やURLエンコードの文字化けとよく似ていますが、原因は別物です。メールやURLの文字化けは主に文字コード（Shift_JIS・UTF-8など）の解釈違いが原因であるのに対し、今回の & の問題は、文字コードではなくHTMLエンティティの変換段階で起きています。対処法も異なるため、まずどちらの症状かをソースコード表示で切り分けることが重要です。
同様に、Markdownの表が崩れる原因やMarkdownのチェックボックスが表示されない原因も、見た目は似ていても原因はマークアップの記法の問題であり、エンティティの二重エスケープとは切り分けて考える必要があります。
まとめ
や&がそのまま表示されるのは文字化けではなく、HTMLエンティティが正しく解釈されていない状態 の大量発生は、WordPressの自動整形機能かWord・Excelからのコピペに含まれるノーブレークスペースが主な原因&nbsp;のようにamp;が挟まっていれば二重エスケープが原因。デコードしてから必要な箇所だけ再エンコードする- すでにエスケープされた文字列に気づかず再変換すると、三重エスケープになる落とし穴がある。 変換前に
amp;の個数をソースコードで確認する - コピペ元は一度書式なしのテキストエディタを経由させると、混入自体を予防できる