NordVPN
広告厳格なノーログポリシーと6000台以上のサーバーで、安全かつ高速なネット接続を提供するVPN。
詳細を見る →テキストを貼り付けて特殊文字をHTMLエンティティにエンコードするか、エンティティを含むHTMLを貼り付けてデコードします。名前付きエンティティ(&、<、©)、10進数(©)、16進数(©)から選択できます。非ASCII文字をすべてエンコードして最大互換性を確保するオプションも用意しています。
HTMLエンティティとは、HTMLで特別な意味を持つ文字や直接入力できない文字を表すための特殊なテキストコードです。最も重要なのはHTML構文で予約されている5つの文字で、それぞれ & (アンパサンド) → &、< (小なり) → <、> (大なり) → >、" (ダブルクォート) → "、' (シングルクォート) → ' に対応します。これらの文字をエンコードせずにテキストコンテンツ内に記述すると、ブラウザがHTMLマークアップと解釈し、レンダリングエラーやセキュリティ上の脆弱性を引き起こす可能性があります。
HTMLエンティティには3つの形式があります。名前付きエンティティは説明的な名前を使用します(© には ©、€ には €)。10進数の数値文字参照はコードポイント番号を使用します(© には ©)。16進数の数値文字参照は16進コードを使用します(© には ©)。3つの形式はすべて等価であり、どの形式を使ってもブラウザは同じ文字をレンダリングします。名前付きエンティティは最も読みやすく、数値エンティティは任意のUnicode文字に対応するため最も汎用的です。
テキストコンテンツや属性値に予約済みの5文字(&、<、>、"、')が含まれる場合は、最低でもそれらをエンコードする必要があります。エンコードを怠るとクロスサイトスクリプティング(XSS)の脆弱性の原因となります。ユーザー入力をエンコードせずにHTMLに挿入すると、攻撃者がスクリプトタグやイベントハンドラを注入できてしまいます。React、Vue、AngularなどのモダンなフレームワークはデフォルトでHTMLを自動エンコードしますが、innerHTML は手動エンコードが依然として重要な主な例外です。
必須の5文字に加えて、UTF-8を確実に処理できない環境では非ASCII文字もエンコードすることを検討してください。HTMLメール、レガシーCMSシステム、最大互換性が求められるドキュメントなどが該当します。「非ASCII文字をすべてエンコード」オプションを使うと、コードポイント127以上のすべての文字が数値エンティティに変換され、出力が純粋なASCIIになりながらもレンダリング時の見た目を保ちます。最新のUTF-8 HTMLファイルでは非ASCIIのエンコードは任意であり、charsetを正しく宣言するだけで十分です。
HTMLエンティティ、URLエンコード(パーセントエンコーディング)、Base64はそれぞれ異なるコンテキストで使われる3種類のエンコード方式です。HTMLエンティティ(& など)はHTML文書内で文字を安全に表現するために使われます。URLエンコード(& を %26 にするなど)はURLやクエリ文字列内で特別な意味を持つ文字をエンコードするために使われます。Base64は任意のバイナリデータをASCIIテキストとしてエンコードするもので、データURIやメール添付ファイルに使われます。
よくある間違いは、これらを混同することです。HTMLコンテンツにURLエンコードを使ったり、URLにHTMLエンコードを使ったりするケースが代表的です。例えば、URLクエリ文字列内のアンパサンドにはパーセントエンコーディング(%26)が必要で、HTMLエンティティエンコーディング(&)ではありません。HTMLの属性内に埋め込まれるURLを構築する場合は両方が必要で、URLエンコード済みの形式を属性値に入れ、その属性値自体をHTMLエンコードします。どのコンテキストにどのエンコードが適用されるかを理解することで、二重エンコードのバグやセキュリティ上の問題を防げます。
アンパサンドのHTMLエンティティは & です。文字通り &、a、m、p、セミコロンで構成されます。HTMLソースに & と書くと、ブラウザは単一の & 文字を表示します。このエンコードはテキストコンテンツや属性値にアンパサンドが含まれる場合に必須です。エンコードされていない & はパーサーがエンティティシーケンスの始まりとして解釈しようとするためです。
著作権 © には3つの等価なHTMLエンティティがあります。名前付き ©、10進数 ©、16進数 © です。いずれも同じ © 文字をレンダリングします。名前付きエンティティは使用可能な場合に最も読みやすい選択肢です。現代のUTF-8 HTMLでは、charset=utf-8 を宣言していれば © 文字を直接入力することもできます。
ダブルクォート(")はダブルクォートで区切られたHTML属性内では " としてエンコードする必要があります(例:<input value=""">)。シングルクォート(')はシングルクォートで区切られた属性内では ' または ' としてエンコードする必要があります。要素のテキストコンテンツ(タグの間)ではどちらのクォート文字もエンコードせずに使えますが、エンコードしても問題ありません。すべてのコンテキストで両方を一貫してエンコードするのが最も安全なアプローチです。
名前付きエンティティは説明的な単語を使用します(©、€、♥)。これらはHTML仕様で定義されており、すべてのUnicode文字に名前付きエンティティがあるわけではありません。数値エンティティはUnicodeコードポイントを使用し、10進数(€ には €)または16進数(€ には €)で表します。数値エンティティは任意のUnicode文字に使用できますが、名前付きエンティティはそのサブセットのみカバーします。どちらもブラウザでは同じようにレンダリングされます。
通常は不要です。HTMLドキュメントでUTF-8エンコーディング(meta charset=utf-8)を宣言し、UTF-8で保存されていれば、非ASCII文字を直接記述できます(é、ñ、中、🎉 など)。エンティティとしてエンコードすることは任意であり、ソースが読みにくくなります。例外は、エンコードが保持されない可能性があるコンテキストでHTMLを送信する場合です。メールメッセージ、レガシーAPI、非ASCIIバイトを破損するシステムなどが該当します。そのような場合は、すべての非ASCIIを数値エンティティとしてエンコードすることで、出力が純粋な安全なASCIIになります。
クロスサイトスクリプティング(XSS)はセキュリティ上の脆弱性で、攻撃者がエンコードせずにHTMLにサーバーが反映するテキストを挿入することで、悪意のあるJavaScriptをウェブページに注入します。例えば、ユーザー入力 <script>alert('xss')</script> がページに直接挿入されると、ブラウザがスクリプトを実行します。入力を適切にエンコードして < を <、> を > に変換すれば、ブラウザはそれをタグとして解析せずにテキストとして表示します。HTMLエンティティエンコーディングは反射型・蓄積型XSSに対する主要な防御手段です。
このツールは名前付きエンティティを持つ文字をエンコードします。ノーブレークスペース(Unicode U+00A0)は、実際のノーブレークスペース文字を入力すると としてエンコードされます(一部のシステムではAlt+Spaceで挿入できるか、文字マップからコピーできます)。通常のスペース(U+0020、スペースバー)は安全なASCII文字のためエンコードされません。出力に が必要な場合は、ノーブレークスペース文字を入力に直接入力または貼り付けてください。
はい、ユーザーが提供したテキストをHTMLに挿入する前にエンコードすることは、HTMLインジェクションとXSSに対する主要な防御手段の1つです。最低でも5つの予約文字(&、<、>、"、')をエンコードしてください。このツールは5つすべてをエンコードします。ただし、エンコードだけでは完全なセキュリティ対策にはなりません。適切なContent Security Policyヘッダー、属性内のjavascript: URLの慎重な処理、フレームワークレベルの保護も必要です。本番アプリケーションでは、手動エンコードではなくセキュリティのために設計されたサーバーサイドライブラリ(OWASP Java Encoder、クライアントサイドにはDOMPurifyなど)を使用してください。
最終更新: