11

進化する仕様を読んでから何年にもわたって、私はRFC 3986が最終的にエスケープ オクテット シーケンスの UTF-8 エンコーディングに落ち着いたと思っていました。つまり、私の URI が持っている場合、%XX%YY%ZZ(スキーム固有の部分の任意の URI に対して) デコードされたオクテットのシーケンスを取得し、結果のバイトを UTF-8 として解釈して、デコードされた情報が意図されているものを見つけることができます。decodeURIComponent()実際には、このデコードを自動的に行うJavaScript を呼び出すことができます。

data:次に、 URIの仕様であるRFC 2397charsetを読みました。これには、 (当然のことながら) エンコードされたデータの文字セットを示す引数が含まれています。しかし、それはどのように機能しますか？URI に2 オクテットのエンコードされたシーケンスがある場合%XX%YY、デコードされた 2 つのオクテットは UTF-8 シーケンスとして解釈されるべきではなく、2 つの別個のラテン文字として解釈されるべきであることを示します (ISO-8859-1 の各バイトが表すように)キャラクター）？RFC 2397 は、「ギリシャ語 [sic] 文字」の例を示しているため、これを示しているようです。data:charset=iso-8859-1

data:text/plain;charset=iso-8859-7,%be%fg%be

しかしこれは、JavaScript decodeURIComponent()(UTF-8 でエンコードされたオクテットを想定) を使用してデータ URI から文字列を抽出できないことを意味しますね。これは、文字セットが UTF-8 以外の場合、データ URI の独自のデコードを作成する必要があるということですか?

さらに、これは RFC 2397 が現在 RFC 3986 と競合していることを意味しますが、これは UTF-8 が想定されていることを示しているようです? それとも、RFC 3986 は「新しい URI スキーム [s]」のみを参照していますか? つまり、data:URI スキームは適用されず、エンコードされたオクテットが何を意味するかを指定するための独自の手法を持っていますか?

現時点での私の最善の推測ではdata:、独自のルールに従って動作し、UTF-8 以外の文字セットを示している場合はdecodeURIComponent()、JavaScript 以外のものを使用する必要があります。交換方法に関する推奨事項も歓迎します。

4

1 に答える 1

7

URIdata:スキームは、あたかもhttp:URI (同じバイトストリームですが、HTTP サーバーに格納されている) またはftp:URI (同じバイトストリームですが、 FTP サーバーに保存されている) またはfile:URI (同じバイトストリームですが、ローカルのファイルシステムに保存されています)。ファイルに添付されたメタデータだけがバイトストリームの意味を与えます。

RFC 2397 では、このバイトストリームを URI 自体に埋め込む方法について明確な仕様が示されています (他の URI スキームとは対照的に、URI はバイトストリームに含まれるものではなく、バイトストリームを取得する場所を指示します)。base64 である場合もあれば、RFC で指定されているパーセント エンコーディング メソッドである場合もあります。バイトストリームに man 非 ASCII バイトが含まれている場合、Base64 はよりコンパクトになります。

URIはdata:、バイトストリームの意図した解釈を提供する独自の Content-Type も記述します。この場合、 を使用しているためtext/plain;charset=iso-8859-7、バイトは正しくエンコードされた ISO-8859-7 テキストでなければなりません。バイトは、UTF-8 またはその他の文字エンコーディングとして決定されることは絶対にありません。指定した文字エンコーディングを使用して明確にデコードされます。

于 2013-05-25T19:02:11.370 に答える