unicode - Unicode URL デコード

Question

Unicode 文字を URL エンコードする通常の方法は、2 つの %HH コードに分割することです。( \u4161 => %41%61 )

しかし、デコード時にユニコードはどのように区別されるのでしょうか? %41%61が\u4161対\x41\x61 ("Aa")であることをどのように知っていますか?

エンコーディングが必要な 8 ビット文字の前に%00がありますか?

それとも、ユニコード文字が失われる/分割されるはずのポイントですか?

Answer 1

ウィキペディアによると：

現在の基準

汎用 URI 構文では、URI 内の文字データの表現を提供する新しい URI スキームは、実際には、予約されていないセットの文字を変換せずに表現し、他のすべての文字を UTF-8 に従ってバイトに変換する必要があることを義務付けています。これらの値をパーセント エンコードします。この要件は、RFC 3986 の発行により 2005 年 1 月に導入されました。この日付より前に導入された URI スキームは影響を受けません。

現在の仕様では、エンコードされた文字データをどうするかについては触れられていません。たとえば、コンピュータでは、文字データはあるレベルでエンコードされた形式で明示されるため、バイナリ データとして、または URI 文字にマッピングされるときに文字データとして扱うことができます。おそらく、この可能性を説明し、どちらか一方を要求するのは URI スキームの仕様次第ですが、実際には、実際に実行するものはほとんどありません。

非標準の実装

Unicode 文字の非標準エンコーディング %uxxxx が存在します。ここで、xxxx は 4 桁の 16 進数で表される Unicode 値です。この動作はどの RFC でも指定されておらず、W3C によって拒否されています。ECMA-262 の第 3 版には、この構文を使用する escape(string) 関数が含まれていますが、UTF-8 に変換して各オクテットをパーセント エンコードする encodeURI(uri) 関数も含まれています。

つまり、それは unencode メソッドを書いている人次第のように見えます... 標準は楽しいものではありませんか?

Answer 2

私が常に行ってきたことは、最初に Unicode 文字列を UTF-8 エンコードして一連の 8 ビット文字にしてから、%HHでエスケープすることです。

PS - 非標準の実装 (%uxxxx) がほとんどないことを願うばかりです。

Answer 3

URI は Unicode が登場する前に導入されたか、少なくとも広く使用されていたため、これは非常に実装固有の質問だと思います。テキストを UTF-8 でエンコードし、それを通常どおりにエスケープするのが最良のアイデアのように聞こえます。これは、適切な ASCII/ANSI システムと完全に後方互換性があるためです。

一方、デコードするには、テキストをエスケープ解除し、UTF-8 文字列を取得します。古いシステムを使用している誰かがあなたのデータを ASCII/ANSI で送信しようとしても、(ほとんど) UTF-8 でエンコードされているため、害はありません。