「＆」を「＆amp;」として本当にエンコードする必要がありますか？

207

&私のサイトのHTML5およびUTF-8で「」記号を使用しています<title>。Googleは、タイトルのすべてのブラウザと同様に、SERPにアンパサンドを表示します。

http://validator.w3.orgは私にこれを与えています：

＆は文字参照を開始しませんでした。（＆おそらくエスケープされるべきだった&amp;。）

私は本当にする必要があり&amp;ますか？

検証のために自分のページを検証することに戸惑うことはありませんが、これについての人々の意見を聞き、それが重要かどうか、そしてその理由を知りたいです。

validation  html  utf-8  character-encoding 
— ハロルド
ソース
63
スペックにはそうは書かれていません。ポスターは、すべてのシナリオでアンパサンドをエスケープする必要がないHTML5を指します。
— Matthew Wilson
2
あなたが意見を探しているので、これはコミュニティWikiである必要があり、妥当性検証に煩わされないことは、回答する客観的な根拠がないことを意味します。
— Richard JP Le Guen 2010
6
@リチャード：本当に？「検証は問題ではない」という意見には同意しませんが、これは非常に客観的な質問だと思います。「これは仕様以外のものを壊しますか？」
— Joachim Sauer
2
@YiJiang 現在のWebブラウザーは、ユーザーを理解するために多くの時間を費やしています。また、Googleも同様です。これは仕様の一部です。将来のWebブラウザは、許容度が低くなる可能性があります。したがって、Wikipediaがどのように実行するかを確認し、コピーすることは常に良い考えです。
— unixman83
2
HTML仕様はがらくた入力を受け入れるように言っています。それはあなたのサイトが今がらくたになることを「許可」されているということですか？閉じる必要があるタグを閉じて、物事をエスケープしてください！人に来なさい。
— doug65536

回答:

143

はい。エラーが言ったように、HTMLでは、属性は#PCDATAであり、解析されることを意味します。つまり、属性で文字エンティティを使用できます。&それ自体を使用することは間違っており、寛大なブラウザではなく、これがXHTMLではなくHTMLであるという事実は、解析を壊します。ちょうどそれをエスケープして&amp;、すべてがうまくいくでしょう。

HTML5では、エスケープせずに残すことができますが、後続のデータが有効な文字参照のように見えない場合のみです。ただし、このシンボルのすべてのインスタンスをエスケープする方が、必要なものと不要なものを心配するよりも優れています。

この点に留意してください。＆にエスケープしていない場合、作成したデータ（コードが無効になる可能性が非常に高い場合があります）に対して十分に悪い場合は、タグ区切り文字をエスケープしていない可能性もあります。これは、ユーザーが送信したデータにとって大きな問題です。これは、HTMLやスクリプトのインジェクション、Cookieの盗難、その他の悪用につながる可能性が非常に高いです。

コードをエスケープしてください。それはあなたに将来の多くのトラブルを救います。

— デラン・アザバニ
ソース
9
どのブラウザもそれ自体を「誤解」することは決してありません。既存のすべてのブラウザでは、「＆」として表示されます。彼がそれを行うための実際的な理由を明示的に要求したこと、および彼は検証については気にしないと述べたことを考慮して..
— トーマス・ボニーニ
47
はい。しかし道徳的には、ブラウザの寛大さと「素敵な」エラー処理に頼るべきでしょうか？それとも正しいコードを書けばいいのでしょうか？
— Delan Azabani、2010
8
@Delan：私が書いたすべてのページを検証しようとしている間、私は彼の質問を読んで彼が「道徳的に」気にしていないことを理解しています。彼はそれがうまくいくかどうか気にしています。これらは2つの異なる哲学であり、どちらにも長所と短所があり、「正しい」ものはありません。たとえば、このWebサイトは検証されませんが、それでも優れたWebサイトです。
— Thomas Bonini
3
@Andreasですが、無意味なマークアップを送信したときに正しい結果が得られるかどうかに応じて、ブラウザは正しいコードを解釈する方法に十分なバグがあります。今日はその例で機能し、次の例で失敗する可能性があります（次の例のセミコロンが＆の後ろにある場合など）
— Jon Hanna
11
誰もがHTML5について話しているようですが、元の質問ではHTML5が使用されていると述べています。HTML5は、この状況で、エスケープされていない＆を明示的に許可します。
— Matthew Wilson
55

検証はさておき、Webページとして適切かつ安全にレンダリングできるように、特定の文字をエンコードすることがHTMLドキュメントにとって重要であるという事実は変わりません。

エンコーディング&として&amp;、すべての状況下で、私にとっては、エラーや障害の可能性を減らすことによって、生きるために簡単なルールです。

次を比較してください：どちらが簡単ですか？どちらが盗聴しやすいですか？

方法論1

  1. アンパサンド文字を含むコンテンツを記述します。
  2. それらをすべてエンコードします。

方法論2

（一粒の塩を入れてください;））

  1. アンパサンド文字を含むコンテンツを記述します。
  2. ケースバイケースで、各アンパサンドを見てください。次のことを確認します。
    • 分離されているため、アンパサンドです。例えば。volt & amp
       >その場合は、わざわざエンコードしないでください。
    • 分離されていませんが、結果のエンティティは存在せず、エンティティリストが進化することがないため存在しなくなるため、それはあいまいではないと感じます。例amp&volt
       >その場合は、エンコードする必要はありません。
    • 孤立しておらず、あいまいです。例えば。volt&amp
       >エンコードします。

??

— リチャードJPルグエン
ソース
3
の2番目のケースamp&volt はあいまい&voltです。エンティティ参照であるかどうか。
— ガンボ
6
@Gumboのアンパサンドamp&voltは、あいまいなアンパサンドではありません（HTML仕様の定義による）。mathiasbynens.be/notes/ambiguous-ampersandsおよびmothereff.in/ampersands#amp%26voltを参照してください。
— Mathias Bynens 2012年
@MathiasBynens（2019年）までに、あいまいなアンパサンドの定義は、 2011年にmathiasbynens.be/notes/ambiguous-ampersandsで引用した定義から少し変更されているようです。
— ジェイコブC.がモニカを復活させる
21

HTML5ルールはHTML4とは異なります。HTML5では必須ではありません-アンパサンドがパラメーター名の始まりのように見えない限り。「＆copy = 2」はまだ問題です。たとえば、＆copy; 著作権記号です。

ただし、次のテキストによっては、エンコードするかしないかを決めるのが難しいように思えます。したがって、最も簡単な方法は、おそらく常にエンコードすることです。

— マシューウィルソン
ソース
2
これは、属性値を引用するようなものです。必ずしもそうする必要はありませんが、常にそうすることで間違いはありません。
— ポールD.ウェイト2010
3
&copy=2あなたが考えるほど大きな問題ではありません。属性値（href属性など）では、はの&copy文字参照とは見なされません©。属性値の外では、そうなります。
— Mathias Bynens 2013
アンパサンドは通常、英語のテキストの前後にスペースがあるため、私が従う規則を覚えたり考えたりすることは難しくありません。アンパサンドが別の表示文字に触れていない場合は、ほとんどの場合、必要ありません。エンコーディング。それ以外の場合は、単純化のために単にエンコードします。
— カールスミス
HTML5ルールへの参照を追加できますか？
— Ferrybig 2018年
17

これは、「ブラウザが気にしないのに、なぜ仕様に従うのか」という疑問に変わったと思います。これが私の一般的な答えです：

標準は「現在」のものではありません。それらは「未来」のものです。私たちが開発者としてWeb標準に従うと、ブラウザーベンダーはそれらの標準を正しく実装する可能性が高くなり、CSSハッキング、機能検出、およびブラウザー検出が不要な完全に相互運用可能なWebに近づきます。特定のブラウザーでレイアウトが壊れる理由や、それを回避する方法を理解する必要がない場合。

具体的には、HTML5で＆amp;を使用する必要がない場合。特定の状況で、HTML5 doctypeを使用している（そしてユーザーがHTML5準拠のブラウザーを使用していることも期待している）場合は、そのようにする理由はありません。

— ライアン・キナル
ソース
1
そうは言っても、一般的に言えば、「標準」の方法のほとんどはまだドラフトモードであり、将来変更される可能性があることを覚えておく必要があります。
— refaelio 2014年
6

まあ、それがユーザー入力からのものである場合、明らかな理由から、完全にそうです。このWebサイトがそれを実行しなかったとしたら、この質問のタイトルが表示され、「＆」を「＆」として本当にエンコードする必要がありますか？

それがちょうどそのようなものであるならばecho '<title>Dolce & Gabbana</title>';、厳密に言えばあなたはする必要はありません。それは良いでしょうが、あなたがそうしなければ、ユーザーは違いに気付かないでしょう。

— トーマス・ボニーニ
ソース
5

あなたの本当の姿を教えてくださいtitle。提出するとき

<!DOCTYPE html>
<html>
<title>Dolce & Gabbana</title>
<body>
<p>am i allowed loose & mpersands?</p>
</body>
</html>

http://validator.w3.org/ - 明示的に実験的なHTML 5モードを使用することを求めて -それはについての苦情がない&のを...

— AakashM
ソース
1
はい、HTML5には以前のHTMLおよびXHTMLパーサーとは異なるパーサーがあり、特定の状況ではエスケープされていないアンパサンドを使用できます。
— ケビンジ2011
これらの例に関する限り、これはHTML5の新機能ではありません。<title>Dolce & Gabbana</title>と<p>Dolce & Gabbana</p>はどちらも有効なHTML 2.0です。
— Mathias Bynens、2012年
4

HTMLでは、a &は、文字参照またはエンティティ参照のいずれかの参照の開始を示します。その時点から、パーサーは#、文字参照を示すか、エンティティ参照を示すエンティティ名のいずれかを期待します;。これが通常の動作です。

しかし、参照名場合は、単に基準開度は、&ホワイトスペースなど他の区切り文字が続いている"、'、<、>、&、エンディング;とプレーンを表現するためにも、参照は&省略することができます。

<p title="&amp;">foo &amp; bar</p>
<p title="&amp">foo &amp bar</p>
<p title="&">foo & bar</p>

これらの場合にのみ、末尾;または参照自体を省略できます（少なくともHTML 4では）。HTML 5には末尾が必要だと思います;。

ただし、仕様では、混乱を避けるために&#38;、常に文字参照やエンティティ参照などの参照&amp;を使用することを推奨しています。

著者は、文字参照（エンティティー参照のオープン区切り文字）の始まりとの混同を避けるため&amp;に、 " &" ではなく" "（ASCII 10進数38）を使用する必要があります。&amp;CDATA属性値内では文字参照が許可されているため、作成者は属性値にも「」を使用する必要があります。

— ガンボ
ソース
1
これは、リンク先のHTML 4仕様です。（ドラフト）HTML 5仕様を読んだところ、あいまいなアンパサンドのみが許可されていません。たとえば、アンパサンドの後にスペースが続く場合はあいまいではないため、（ここでも読みますが）許可する必要があります。HTML5バリデーターが受け入れるマークアップについては、私の回答を参照してください。
— AakashM 2010
1
@AakashM：よくわかりません。
— ガンボ
3

ユーザーがそれを渡した場合、またはURLに巻き込まれる場合は、エスケープする必要があります。

ページの静的テキストに表示される場合はどうなりますか？すべてのブラウザがこれを正しい方法で取得します。問題なく動作するため、心配する必要はありません。

— ディーン・J
ソース
3

更新（2020年3月）： W3Cバリデーターは、URLのエスケープについて文句を言いません。

画像のURLをエスケープする必要がある理由を確認していたため、https：//validator.w3.orgで試しました。説明はかなりいいです。URLでさえエスケープする必要があることを強調しています。[PS：URLが必要なため、消費されたときにエスケープ解除されると思います&。誰かが明確にできますか？]

<img alt="" src="foo?bar=qut&qux=fop" />

エンティティ参照がドキュメントで見つかりましたが、その名前で定義された参照は定義されていません。多くの場合、これは参照名のスペルミス、エンコードされていないアンパサンド、または末尾のセミコロン（;）を省略したことが原因です。このエラーの最も一般的な原因は、「URLのアンパサンド」のWDGで説明されているように、URLのエンコードされていないアンパサンドです。エンティティ参照は、アンパサンド（＆）で始まり、セミコロン（;）で終わります。ドキュメントでリテラルアンパサンドを使用したい場合は、それを "＆"としてエンコードする必要があります（URL内であっても！）。エンティティ参照をセミコロンで終了しないように注意してください。セミコロンを使用しないと、エンティティ参照が次のテキストに関連して解釈される可能性があります。名前付きエンティティの参照では大文字と小文字が区別されることにも注意してください。＆Aelig; とæは異なる文字です。

— ニシャント
ソース
1
トップ投票の答えを読んでください。属性は#PCDATAであるため、解析されます。エンティティはそこで処理されます。あなたの例では、&はエンティティ参照を開始します。を読んだ後&qux、パーサーは最後のセミコロン（;）を見つける=ことができませんが、等号（）に遭遇します。これはエンティティー名の一部にすることはできません。パーサーが（HTML 4によると）本当に厳密にしようとした場合、これは解析エラーになるはずです。HTML 5では、エンティティの解析は全体的に緩和されています。
— Palec
1
そのため、一般的には;（リンクを制御するときに）クエリ文字列の区切り記号として使用するのが最適だと思います。
— デミ
2

はい、可能であれば、有効なコードを提供するようにしてください。

ほとんどのブラウザはこのエラーを警告なしに修正しますが、ブラウザでのエラー処理に依存することには問題があります。不正なコードの処理方法に関する標準はありません。そのため、エラーごとに何をすべきかを理解するのは各ブラウザーのベンダー次第であり、結果は異なる場合があります。

ブラウザーが異なる反応をする可能性が高いいくつかの例は、要素をテーブルの内側であるがテーブルのセルの外側に置く場合や、リンクを相互にネストする場合です。

特定の例では問題が発生する可能性は低いですが、ブラウザのエラー修正により、たとえば、ブラウザが標準準拠モードから互換モードに変更され、レイアウトが完全に壊れる可能性があります。

したがって、コード内のこのようなエラーを修正する必要があります。そうでない場合は、バリデータのエラーリストを短くして、より深刻な問題を特定できるようにする必要があります。

— グッファ
ソース
2

数年前、Webアプリの1つがFirefoxで正しく表示されていないという報告を受けました。ページに次のようなタグが含まれていることがわかりました

<div style="..." ... style="...">

繰り返されるスタイル属性に直面すると、IEは両方のスタイルを結合しますが、Firefoxは一方のみを使用するため、動作が異なります。タグを

<div style="...; ..." ...>

そして確かに、それは問題を修正しました！この話の教訓は、ブラウザは有効なHTMLを無効なHTMLよりも一貫して処理することです。だから、いまいましいマークアップを修正してください！（または、HTML Tidyを使用して修正します。）

— dan04
ソース
1

HTML&で使用されている場合それをエスケープする必要があります

&JavaScript文字列で使用されている場合、例えばalert('This & that');またはのdocument.hrefなどの必要はありません。

document.writeを使用している場合は、それを使用する必要があります。 document.write(<p>this &amp; that</p>)

— アレックス
ソース
— Oriol
についての良い点document.write()。しかし、アレックスはスクリプトスタンドからのドキュメントへの書き込みについて、全体的に言っています。+1
— Patrick M
1

セミコロンがの近くで終わり&、まったく異なるものを表示する可能性に依存します。

たとえば、ユーザーからの入力を処理する場合（たとえば、ユーザーが提供したフォーラム投稿の件名をタイトルタグに含める場合）、ユーザーがランダムなセミコロンを配置する場所がわからず、奇妙なエンティティがランダムに表示されることがあります。したがって、常にそのような状況では脱出してください。

独自の静的htmlの場合、確かにそれをスキップすることもできますが、適切なエスケープを含めることは非常に簡単なので、それを回避する十分な理由はありません。

— ダグラス
ソース
0

あなたが本当に静的テキストについて話しているなら

<title>Foo & Bar</title>

ハードディスク上のファイルに保存され、サーバーから直接提供されます。そうすれば、おそらくエスケープする必要はありません。

あるのでしかし、非常に完全に静的だその頃は少しHTMLコンテンツを、私は、HTMLコンテンツが他のソース（データベースコンテンツ、ユーザー入力、Webサービスの呼び出しの結果、従来のAPIの結果から生成されていることを前提とし、以下の免責事項を追加します。 ..）：

単純なをエスケープしない場合は&、a、&amp;or、&nbsp;or <b>、<script src="http://attacker.com/evil.js">またはその他の無効なテキストもエスケープしない可能性があります。つまり、せいぜいコンテンツを誤って表示しており、XSS攻撃の疑いがある可能性が高いということです。

言い換えると、他のより問題の多いケースをすでにチェックしてエスケープしている場合、not-totally-broken-but-still-somewhat-fishy standalone-＆をエスケープしないままにする理由はほとんどありません。

— ヨアヒムザウアー
ソース
2
私は反対票を投じませんでしたが、推測する必要がある場合は、答えは（インテリジェントながら）質問と少し一致していないため、反対票を投じたと思います。彼はユーザー入力のエスケープについて質問していません。彼はキャラクターをコントロールしていて、基本的には「私がやりたいことをするなら、文字の言語仕様に従うことが本当に重要ですか？」と尋ねています。つまり、彼はそれを置くために＆があることを知っています。
— マット・
@マット：なるほど、それは理にかなっています。私は、だれも完全に静的なHTMLページをもう書いておらず、ほとんどすべてのコンテンツが少なくともいくらか動的である（通常、いくつかのデータベースコンテンツに基づいている）と想定していました。多分その仮定は明確にされるべきだったのでしょう。
— Joachim Sauer、2010
-1

これが誰にとっても便利かどうかわからない...私はしばらくこれと戦っていた...ここにあなたのすべてのリンク、javascript、コンテンツを修正するために使用できる素晴らしい正規表現があります。私は、誰も修正したくなかった大量のレガシーコンテンツに対処する必要がありました。

これをマスターページまたはコントロールのレンダリングオーバーライドに追加します。

これを間違った場所に置いたことで私を非難しないでください：

// remove the & from href="blaw?a=b&b=c" and replace with &amp; 
//in urls - this corrects any unencoded & not just those in URL's
// this match will also ignore any matches it finds within <script> blocks AND
// it will also ignore the matches where the link includes a javascript command like
// <a href="javascript:alert{'& & &'}">blaw</a>
html = Regex.Replace(html, "&(?!(?<=(?<outerquote>[\"'])javascript:(?>(?!\\k<outerquote>|[>]).)*)\\k<outerquote>?)(?!(?:[a-zA-Z][a-zA-Z0-9]*|#\\d+);)(?!(?>(?:(?!<script|\\/script>).)*)\\/script>)", "&amp;", RegexOptions.Singleline | RegexOptions.IgnoreCase);
— リチャード・デュフォー
ソース
-1

リンクには、いつ、どのようにしてエスケープ&する必要があるかについてのかなり良い例があります。&amp;

https://jsfiddle.net/vh2h7usk/1/

興味深いことに、ここでの私の回答で適切に表現するために、キャラクターをエスケープする必要がありました。組み込みのコードサンプルオプション（解答パネルから）を使用する場合、入力するだけで正常に表示されます&amp;。しかし、手動で<code></code>要素を使用する場合は、正しく表現するためにエスケープする必要があります:)

— マティン
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.