ベストアンサー1
確かに、HTML5とHTML4の違いの1つは、W3C 相違点ページ、 は：
アンパサンド (&) は、HTML4 と比較して、エスケープせずに残されるケースが多くなります。
実際、HTML5 仕様では、文字を消費 (および解釈) することの意味を決定する実際のアルゴリズムが詳細に説明されています。
特に、文字参照のトークン化に関するセクションHTML5 仕様の第 8 章では、属性内でアンパサンド文字の後に次の文字が続くことがわかります。
- タブ、LF、FF、スペース、、、
<EOF&、または追加の許可された文字 (属性値が引用符で囲まれている場合は または 、そう"でない場合は ) ===> アンパサンドは単なるアンパサンドなので、心配はいりません。'> - 番号記号 ===> HTML5トークナイザーは、数値文字実体参照があるかどうかを判断するために多くのステップを実行しますが、この場合、解析エラー(仕様を読んでください)
- その他の文字 ===> パーサーは、たとえば のような名前付き文字参照を見つけようとします
∉。
最後のケースは、あなたの例に次のような内容が含まれているため、あなたにとって興味深いケースです。
<a href="somepage.html?x=1&y=2">...</a>
文字列が
- アンパサンド
- ラテン小文字 Y
- 等号
yここで、HTML5 仕様のうち、名前付きエンティティ参照ではないため、あなたのケースに関係する部分は次のようになります。
一致しない場合は、文字は消費されず、何も返されません。この場合、U+0026 アンパサンド文字 (&) の後の文字が、1 つ以上の英数字 ASCII 文字のシーケンスとそれに続く U+003B セミコロン文字 (;) で構成されている場合は、解析エラーになります。
そこにはセミコロンがないので、解析エラーは発生しません。
では、代わりに、
<a href="somepage.html?x=1é=2">...</a>
これは違う。é はHTML 内の名前付きエンティティ参照。この場合、次のルールが適用されます。
文字参照が属性の一部として消費され、一致した最後の文字が「;」（U+003B）文字ではなく、次の文字が「=」（U+003D）文字または英数字の ASCII 文字である場合、歴史的な理由により、U+0026 アンパサンド文字（&）の後に一致したすべての文字は消費されず、何も返されません。ただし、この次の文字が実際には「=」（U+003D）文字である場合、一部のレガシー ユーザー エージェントはそのような場合にマークアップを誤って解釈するため、これは解析エラーになります。
そのため=、従来のブラウザが混乱する可能性があるため、エラーが発生します。
HTML5 仕様では、「このアンパサンドは文字エンティティ参照の先頭ではないので、ここでは参照はありません」と長々と説明しているようですが、解析エラーになる名前付き参照 (例: 、、、) を含む URL に遭遇する可能性があるという事実を考えると、私見isinでは、それらを使用する方がよいでしょう。ただし、もちろん、属性の制限が緩和されたかどうかのみを尋ねたのであって、何をすべきかを尋ねたのではありません。実際、緩和されたようです。partsumsub
バリデーターが何ができるかを見るのは興味深いでしょう。