W3C が ";" の使用を推奨しているという話をよく耳にします。クエリ文字列の区切りとして "&" の代わりに。
HTTP サーバーの実装者、特に CGI の実装者は、";" の使用をサポートすることをお勧めします。"&" の代わりに、このように "&" 文字をエスケープする手間を省きます。
誰かが理由を説明できますか ";" 「＆」の代わりに推奨されますか？
";"また、代わりに使ってみまし"&"た。(例: .com?str1=val1;str2=val2) . Request.QueryString["str1"]私が得るように読むとき" val1;str2=val2"。が推奨される場合";"、クエリ文字列をどのように読み取るのでしょうか?
リンクされたドキュメントにあるように、;推奨される&理由は次のとおりです。
フォーム フィールドを区切るための「&」文字の使用は、文字実体参照を区切るために SGML 属性値での使用と相互作用します。
たとえば、URL を...?q1=v1&q2=v2
& そこには何の問題もありません。しかし、そのクエリを HTML 属性に入れたい場合は、 HTML 属性内で文字エンティティの開始を表しているため、<a href="...?q1=v1&q2=v2">それが壊れます。asを&エスケープする必要があります。&&<a href="...?q1=v1&q2=v2">
;このように過負荷になることはまったくありません。HTML 属性に入れることができ、気にする必要はありません。したがって、サーバー;がクエリ パラメーターの区切り文字として認識されると、はるかに簡単になります。
ただし、（実験に基づいて）物事を見ると、ASP.Netはそれをそのように認識しません。入手方法は？できるかどうかわかりません。
要するに、HTML は (その寛容さゆえに) 大混乱であり、セミコロンを使用することでこれを大幅に簡素化することができます。
セパレータとしてセミコロンを使用するために、.NET でこのカスタマイズが許可されているかどうか、または開発者が QueryString を処理する独自のメソッドを作成する必要があるかどうかはわかりません。.NET は生の QueryString にアクセスできるので、そこから実行できます。これが私がしたことです。独自のメソッドを作成しましたが、それほど難しくはありませんでしたが、テストとデバッグに多くの時間がかかりました。その一部は、サロゲート ペアを処理する際に Web 標準に準拠していなかった Microsoft のせいでした。実装が、多言語面 (中国語や日本語の文字など) を含む Unicode 文字の全範囲で動作することを確認しました。
私自身の調査結果を追加する前に、Rawling、Jeevan、および BeniBela が Rowling の回答とそのような回答に対するコメントで指摘した素晴らしい情報を確認して含めたいと思います。HTML でそれらをエスケープしないのは正しくありませんが、通常は機能します。しかし、パーサーが非常に寛容だからです。その上で、なぜこれがこのような不適切なエンコーディングによるバグにつながる可能性があるのかについても説明します (おそらくほとんどの開発者が犠牲になります)。
QueryString でアンパサンドを不適切にエンコードするこの寛大さに頼ることはできません。たとえば、QueryString がランダムな ASCII 文字列 (またはユーザー入力) を渡し、それらが適切にエンコードされていないとします。次に「amp;」「&」に続くものはデコードされ、予期しない結果は「amp;」です。本質的に「飲み込まれる」。（飲み込むとは、「食べられる」か行方不明になることを意味します。）実用的な使用シナリオは、ユーザーがデータベースに入力するように求められ、ユーザーが HTML を入力する場合です（ここでは StackOverflow のように）が、そうではないためです。正しく投稿すると、厄介なバグが発生します。
「;」の本当の利点 アンパサンドで区切られた QueryString を適切にエンコードするには、HTML ページ (および XML) の URL 文字列に対して 2 つの複雑な手順が必要です。最初にキーと値を URL エンコードしてからすべて連結し、次に QueryString または URL 全体を HTML エンコードします (XML の場合は、HTML エンコードと非常によく似たエンコードでエンコードします)。また、HTML エンコーディングと URL エンコーディングのエンコーディング プロセスが異なることも忘れないでください。これらが異なることは重要です。開発者はこの 2 つに注意する必要があります。また、それらは似ているため、初心者のプログラマーがそれらを混同することも珍しくありません。
問題が発生する可能性がある URL の良い例は、QueryString で 2 つの名前/値を渡す場合です。
ここで、'&' をセパレーターとして使用すると、'?a=me+%26+you&b=you+%26+me' は適切なクエリ文字列ですが、HTML ソース コードに書き込まれる前に HTML エンコードされます。これは、バグをなくすために重要です。ほとんどの開発者は、最初にキーと値を URL エンコードし、次に HTML ソース内の完全な URL を HTML エンコードするという 2 段階のプロセスを慎重に行いません。座ってこのプロセスを真剣に考え、結論を徹底的にテストしなければならなかったのは当然のことです. name の値が 'year=año' の場合のイメージング、またはサロゲート ペアを使用して表現する中国語または日本語の文字が必要な場合のはるかに複雑なイメージング!
上記の a と b の同じキーと値のペアで、';' を使用する場合 セパレーターとして、プロセスははるかに簡単です。実際のところ、アンパサンド区切り記号を使用すると、セミコロン区切り記号を使用する場合の 2 倍以上のプロセスが複雑になります。「;」を使用して表された同じ情報を次に示します。セパレータとして: '?a=me+%26+you;b=you+%26+me'. 唯一の違いは、文字列に「&」がないことです。しかし、この「;」を使用して セパレーターは、URL または QueryString を HTML エンコードする 2 番目のプロセスが必要ないことを意味します。今、私が HTML を書いていて、正しい HTML が欲しくて、これらすべてを説明するために HTML を書く必要があると想像してみてください! この「&」を使用した HTML エンコーディングは、実際には多くの複雑さを追加します (そして、多くの開発者にとっては、かなりの混乱も引き起こします)。
初心者の開発者は、単に QueryString や URL を HTML エンコードしないことに注意してください。セパレーターです。ただし、アンパサンドが不適切にエンコードされると、バグの余地が残ります。したがって、「?someText=blah&blah」には適切なエンコードが必要です。
また、.NET では、メソッドの XML ドキュメントを作成できます。さて、ちょうど今日、上記の「a=me+%26+you&b=you+%26+me」の例を使ってちょっとした説明を書きました。そして、私の XML では、これらすべてを手動で入力する必要がありました。XML の文字エンティティ。XML ドキュメントでは、アンパサンドを正しくエンコードする必要があるため、うるさいです。しかし、HTML の寛大さがあいまいさを増しています。
おそらく、これはあまり混乱していませんでした。しかし、すべての混乱や困難は、区切り文字として HTML エンコードされた文字を使用しているためです。したがって、'&' が原因です。そして、セミコロンはそのすべての複雑さを軽減します。
最後の考慮事項: '&' セパレーターがこのプロセスをさらに複雑にしているため、QueryStrings でのサロゲート ペアの Microsoft 実装がまだ公式の仕様に従っていないのは不思議ではありません。また、独自のメソッドを作成する場合は、Microsoft によるパーセント エンコーディング サロゲート ペアの誤った使用を考慮する必要があります。公式仕様では、UTF-8 でのサロゲート ペアのパーセント エンコーディングが禁止されています。したがって、Unicode 文字の全範囲を処理する独自のメソッドを作成する人は、これに注意してください。