HTMLでエスケープする必要がある文字はどれですか？

それらはXMLと同じですか、おそらくスペース1（ ）に加えますか？

HTMLエスケープ文字の巨大なリストをいくつか見つけましたが、エスケープする必要があるとは思いません。何を脱出する必要があるのか知りたい。

ドキュメントのテキストコンテンツが期待される場所にテキストコンテンツを挿入する場合¹、通常は、XMLの場合と同じ文字をエスケープするだけで済みます。要素の内部には、エンティティエスケープアンパサンド&と要素の区切り記号の小なり記号と大なり記号のみが含まれます< >。

& becomes &
< becomes &lt;
> becomes &gt;

属性値の内部では、使用している引用符もエスケープする必要があります。

" becomes "
' becomes '

場合によっては、これらの文字の一部のエスケープをスキップしても安全ですが、間違いを犯す可能性を減らすために、すべての場合に5つすべてをエスケープすることをお勧めします。

ASCIIエンコードされたドキュメントで絵文字を使用しようとしている場合など、ドキュメントエンコーディングが使用しているすべての文字をサポートしていない場合は、それらもエスケープする必要があります。最近のほとんどのドキュメントは、完全にUnicodeをサポートするUTF-8エンコーディングを使用してエンコードされていますが、これは不要です。

一般に、スペースをエスケープしないでください 。 通常のスペースではなく、改行しないスペースです。通常のスペースの代わりにこれらを使用して、2つの単語の間に改行が挿入されないようにしたり、自動的に折りたたまれずに余分なスペースを挿入したりできますが、これは通常まれなケースです。これを必要とするデザイン制約がない限り、これを行わないでください。

¹「テキストコンテンツが期待される場所」とは、通常の解析ルールが適用される要素または引用符で囲まれた属性値の内部を意味します。例：<p>HERE</p>または<p title="HERE">...</p>。上記で記述した内容は、スクリプトやスタイルタグの内部、要素や属性名など、特別な解析ルールや意味を持つコンテンツには適用されません。たとえば、次のように<NOT-HERE>...</NOT-HERE>、<script>NOT-HERE</script>、<style>NOT-HERE</script>、または<p NOT-HERE="...">...</p>。

これらのコンテキストでは、ルールがより複雑になり、セキュリティの脆弱性を導入することがはるかに簡単になります。これらの場所に動的コンテンツを挿入することはお勧めしません。有能なセキュリティ対応開発者のチームがこれらの値を正しくエンコードしていると想定して脆弱性を導入するのを見てきましたが、エッジケースがありません。通常は、動的な値を属性に入れてJavaScriptで処理するなど、より安全な方法があります。

必要な場合は、Open Web Application Security ProjectのXSS防止ルールを読んで、覚えておく必要のある懸念のいくつかを理解してください。

それはコンテキストに依存します。HTMLで可能ないくつかのコンテキスト：

• ドキュメント本文
• 共通属性の内部
• スクリプトタグ内
• スタイルタグの内側
• さらにいくつか！

OWASPのクロスサイトスクリプティング防止に関するチートシート、特に「信頼できないデータをHTMLエンティティだけでエンコードできないのはなぜですか？」と「XSS防止ルール」のセクションを参照してください。ただし、ドキュメント全体を読むことをお勧めします。

基本的に、HTMLファイルとXMLファイルでは常にエスケープする必要のある3つの主要な文字があるため、残りのマークアップと相互作用しないため、おそらく予想通り、そのうちの2つは構文ラッパーになります。 >、それらは以下のようにリストされます：

 1)  &lt; (<)
    
 2)  &gt; (>)
    
 3)  &amp; (&)

また、二重引用符（ "）を"として、単一引用符（ '）を＆aposとして使用することもできます。

<script>およびに動的コンテンツを<style>配置しないでください。これらのルールはそれらに適用されるものではありません。たとえば、JSONをに含める必要がある場合は、<を\ x3cに、U + 2028文字を\ u2028に、U + 2029を\ u2029にJSONシリアライゼーション後に置き換えます。

HTMLエスケープ文字：完全なリスト：http : //www.theukwebdesigncompany.com/articles/entity-escape-characters.php

したがって、文字参照を開始する可能性のある何かが続く場合は、<または＆をエスケープする必要があります。また、アンパサンドのルールは、引用符で囲まれた属性の唯一のそのようなルールです。一致する引用符がそれを終了させる唯一のものだからです。ただし、そこで属性値を終了したくない場合は、引用符をエスケープします。

UTF-8に変更すると、ファイルが再保存さ

れます。ページに文字エンコードUTF-8を使用すると、ほとんどのエスケープの必要を回避して、文字を操作するだけで済みます。ただし、ドキュメントのエンコーディングを変更するには、ページの上部またはサーバーでエンコーディング宣言を変更するだけでは不十分です。ドキュメントをそのエンコードで再保存する必要があります。アプリケーションでこれを行う方法を理解するには、Webオーサリングアプリケーションでのエンコーディングの設定を参照してください。

非表示またはあいまいな文字：

エスケープの特に有用な役割は、表示で不可視またはあいまいな文字を表すことです。

1つの例は、Unicode文字U + 200F RIGHT-TO-LEFT MARKです。この文字は、双方向テキストの方向性を明確にするために使用できます（アラビア語またはヘブライ語のスクリプトを使用する場合など）。ただし、グラフィック形式ではないため、これらの文字がテキストのどこにあるかを確認することは困難であり、失われたり忘れたりすると、後で編集するときに予期しない結果が生じる可能性があります。代わりに（またはそれに相当する数字参照）を使用すると、これらの文字を簡単に見つけることができます。

あいまいな文字の例は、U + 00A0 NO-BREAK SPACEです。このタイプのスペースは改行を防ぎますが、文字として使用すると他のスペースと同じように見えます。を使用すると、そのようなスペースがテキストのどこに現れるかが明確になります。

正確な答えはコンテキストによって異なります。一般に、これらの文字は存在してはなりません（HTML 5.2§3.2.4.2.5）：

テキストノードと属性値は、Unicode文字で構成されている必要があり、U + 0000文字が含まれていてはならず、永続的に未定義のUnicode文字（非文字）が含まれていてはならず、スペース文字以外の制御文字が含まれていてはなりません。この仕様には、正確なコンテキストに応じて、テキストノードと属性値の正確な値に対する追加の制約が含まれます。

HTMLの要素の場合、テキストコンテンツモデルの制約も要素の種類によって異なります。たとえば、textareaはエスケープ可能な未加工のテキスト要素であるため、textarea要素内の「<」をHTMLでエスケープする必要はありません。

これらの制限は仕様全体に散在しています。たとえば、属性値（§8.1.2.3）には、あいまいなアンパサンドを含めてはならず、（i）空である、（ii）一重引用符で囲む（したがって、U + 0027アポストロフィ文字を含めない'）、（iii）二重引用符で囲んではならない（ U + 0022 QUOTATION MARK文字"）または（iv）引用符を含めないでください—次の制限があります：

...リテラルスペース文字、U + 0022 QUOTATION MARK文字（ "）、U + 0027アポストロフィ文字（ '）、U + 003D EQUALS SIGN文字（=）、U + 003C LESS-THAN SIGN文字（ <）、U + 003E GREATER-THAN SIGN文字（>）、またはU + 0060 GRAVE ACCENT文字（ `）。空の文字列であってはなりません。