最近、WebサービスアクセスインターフェイスAPIの可能性について考えながら、HTTPクエリ文字列を調査していました。そして、それは非常に過小評価されているようです。
実際、RFC 3986（Uniform Resource Identifier（URI）：Generic Syntax）は、クエリ文字列フラグメントの形式については何も述べておらず、許可される文字と他の文字のエンコード方法の定義で終わります。（後でこれに戻ります。）
私が見つけた唯一のことは、フォームがクエリ文字列にどのようにマングルされるかに関するHTML仕様でした（HTML 4.01; 17.13.4フォームコンテンツタイプ、application / x-www-form-urlencoded）。HTML 5アルゴリズムは十分に近いようです（4.10.22.5 URLエンコードされたフォームデータ）。
これは問題ないように見えるかもしれません。結局のところ、なぜ誰もが他のすべての人にクエリ文字列形式を設定したいと思うのでしょうか。何のために？しかし、（HTML以外の）十分に確立された標準はありますか？他に別のフォーマットを使用している人はいますか？
ここでの副次的な質問は、フォームフィールド名の[]を扱うことです。PHPはこれを使用して、フィールドの複数のオカレンスがすべて$_GETスーパーグローバル変数に存在することを確認します。（それ以外の場合は、最後のオカレンスのみが存在します。）
しかし、RFC 3986から、クエリ文字列では許可されてい[ないようです。]それでも、さまざまなブラウザでの私の実験では、これらの文字をエンコードするブラウザはなく、そのようにURIに存在することが示唆されました...
これは実際の習慣ですか？それとも私はそれを間違ってテストしていますか？IIS7でPHP5.3.17を使用してテストしました。InternetExplorer、Firefox、およびChromeを使用します。$_SERVER['QUERY_STRING']次に、何が入っているかを比較しました$_GET。
もう1つの質問は、セミコロン分離の実際のサポートです。
HTML 4.01仕様（URI属性値のB.2.2アンパサンド;）では、HTTPサーバーがパラメーター区切り文字（アンパサンドではなく）としてセミコロン（）を受け入れることを推奨しています&。
それをサポートしているサーバーはありますか？これを使っている人はいますか？（Webサービスで許可されているクエリ文字列の形式を検討する場合）それを気にする価値はありますか？
では、非ASCII文字のサポートはどうですか？
HTML 4.01仕様（B.2.1 URI属性値の非ASCII文字）は、最初にRFCを説明するURIを明確に言い換えています。非ASCII文字はURIで許可されていません。ただし、仕様では、既存の慣行（不正なURIの使用）と、そのような文字をUTF-8エンコーディングに変更し、各バイトをURI標準の16進エンコーディングで処理するためのアドバイスが考慮されています。
私のテストから、たとえばChromeとFirefoxはそうしているようです。しかし、Internet Explorerは送信せず、それらの文字をそのまま送信しました。PHPは部分的にそれに対処しました。$_SERVER['QUERY_STRING']そして$_GETそれらの文字が含まれていました。しかし、代わりに$_SERVER['REQUEST_URI']含まれています。?
そのような場合にどのようにアプローチするかについての基準や慣行はありますか？
そして、別の関連する質問は、著者が非ASCII（たとえば国別）文字を含む名前で（URIによって）リソースをどのように公開する必要があるかということです。さまざまな関係者（HTMLコード、ブラウザー送信要求、ブラウザー保存ファイルdoディスク、サーバー受信および処理要求、サーバー保管）を考慮すると、一貫して機能させることはほぼ不可能のようです。または、少なくとも私は管理しませんでした。
Webページに関しては、私はすでにそれに慣れており、常に国別文字を対応するラテン語の基本文字に置き換えています。しかし、外部ファイル（PDF、画像など）に関しては、名前を「ダウングレード」するのはどういうわけか「間違っている」と感じます。特に、ユーザーがそれらのファイルをディスクに保存することを期待している場合..この問題に対処するにはどうすればよいですか？