構文

[22] (他の URI scheme 同様) data: URI scheme の仕様は非常に曖昧です。古い時代の仕様書なので仕方がありませんが、 どこまでが規定でどこからが参考なのかも明確ではありません。

[12] 構文の概要: RFC 2397 の2章によると、 data: URI の構文を簡単にあらわすと

data:[<mediatype>][;base64],<data>

となります。

[13] 構文の定義: RFC 2397 の3章は更に詳しく

• dataurl := "data:" [ mediatype ] [ ";base64" ] "," data
• mediatype := [ type "/" subtype ] *( ";" parameter )
• data := *urlchar
• parameter := attribute "=" value

と定義しています。

[23] 構文の定義自体の問題: 自明だからどうでも良いと思ったのか、 この構文定義自体が何で書かれているのか説明がありませんwwwww ABNF の一種だろうと思いますが・・・。

[24] urlc: urlc は RFC 2396 の定義を参照していることになっていますが、 実のところ RFC 2396 で urlc は定義されていません。 おそらく uric の誤りなのでしょうが、これは致命的です。

[14] value: value は RFC 2045 で token または quoted-string と定義されています。しかし、 quoted-string は URI で直接使えない (unsafe な) " や \ を使います。 つまり、構文通り解釈すると使えるはずのものが URI 仕様との整合性を考慮すると使えないのです。

実は使えないのはこの2文字だけではなく、改行を含むC0制御文字や空白なども URI ではそのまま使えません。更に、この value や、 token として定義されている attribute には % を含めることができますが、 URI では % は百分率符号化のための特別な文字として使われます。

[25] 百分率符号化: RFC 2397 の著者も馬鹿ではありませんから、百分率符号化 (当時の名称は URI逃避符号化、RFC 2396 における呼称は URL逃避符号化) との関係に言及しています。

[26] まず一点目に、必要に応じて百分率符号化を用いて表現するとの旨が規定されています RFC 2397 3.:

   (ABNF 構文定義)
   where "urlchar" is imported from [RFC2396], and "type", "subtype",
   "attribute" and "value" are the corresponding tokens from [RFC2045],
   represented using URL escaped encoding of [RFC2396] as necessary.

この最後の部分がどこに係っているのかが曖昧なので、3通りの解釈が可能です:

• 百分率符号化は type, subtype, attribute, value で使用可能
• 百分率符号化は urlc, type, subtype, attribute, value で使用可能
• 百分率符号化は data: URI 全体で使用可能

普通修飾するのは直前のものでしょうから、3つ目の解釈は少々無理があるかもしれませんが、 あり得ないとまではいえません。ちなみに3つ目の解釈に従うなら base64 の部分に百分率符号化が使えます。 1つ目と2つ目の解釈の違いは urlc で百分率符号化が使えるか否かですが、 そもそも uric には escaped (百分率符号化) が含まれているので、どちらでも同じことになります。

as necessary というのも曲者で、穿った読み方をすれば、 必要でない場合には使ってもよいとされていないとも解釈し得ます。 (流石にこれは深読みしすぎでしょうが。)

[27] 2点目に、value での百分率符号化について、

   However, within a "data" URL, the
   "quoted-string" representation would be awkward, since the quote mark
   is itself not a valid urlchar. For this reason, parameter values
   should use the URL Escaped encoding instead of quoted string if the
   parameter values contain any "tspecial".

と言及しています RFC 2397 3.。ここで、 前述の構文が百分率符号化込みのものと理解するべきかという問題が発生します。 この引用部をそのまま解釈すると、 token の部分に百分率符号化が使えることになります。

token を定義している RFC 2045 は URI のことなど気にしていないので、当然百分率符号化が使えるかどうか、 その使い方には言及していません。ただし、token で使える文字には % が含まれています (この辺の事情は引用部の should not を無視して quoted-string を使う場合にも該当します)。 たとえば 100%! は妥当な token です。しかし、 16進数字が2つ続かない % を URI で使うことはできません。 URI の仕様に従うなら、 百分率記号を表したいときは %25 と書かなければなりません。

[28] また、百分率符号化を前述の部分のどんな文字にも使ってよいのかも明確ではありません。 たとえば subtype が svg+xml であったとして、 URI に svg+xm%6C と書いても、 (どんな URI scheme でも非予約な文字は百分率符号化してもしなくても等価なので) 問題ありません。 しかし、 svg%2Bxml が前2例と等価であるのか否かは明らかではありません。 (+ は reserved なので。) 意図としては百分率符号化を使っても構わないのでしょうが。。。

[15] Base64: また、 ";base64" が指定されると、 data は Base64 と解釈されます。 (この指定で大文字と小文字が区別されるかどうかがよくわからないのも問題です。)

ところが、その Base64 の定義が何を参照しているのかが全然書かれていません。 他のところで RFC 2045 を参照しているので、そこで定義されているものと解釈するのが一番もっともらしそうですが、 Base64 は色々な変種が知られているので、油断できません。 (その変種のほとんどが、 RFC 2045 の MIME にべったりな部分に手を加えたものです。)

たとえば、改行や空白の問題があります。 RFC 2045 の Base64 では一行の字数制限があるのですが、それが適用されるかどうかわかりません。

4. には次のような例が載っています。

   <IMG
   SRC="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw
   AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz
   ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp
   a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl
   ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis
   F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH
   hhx4dbgYKAAA7"
   ALT="Larry">

行頭の間隔は RFC としての余白です。 それを無視したとしても、行を折り返しているのが RFC としての行字数制約によるだけで本来いれてはならないものなのか、 RFC の制限だけど実際にも入れてもよい ものなのか、説明が全然ありません。 (かりに入れてもよいとしても、 URI 逃避符号化しない限り URI 全体の構文に違反しますがね。)

[16] >>15 のようなことが気になるのは、実際に生の改行入りで XLink の属性なんかに指定した例が存在するからです。 (XLink の xlink:href 属性値は URI参照そのものではなく、 URI 逃避符号化すれば URI 参照になるものなので、 XLink 的にも一般の URI 的にもこの指定自体は一応合法。)

[29] 空白: RFC 2045 MIME を RFC 822 電子メイルの文脈で使う場合、 構文定義上は明記されていませんが、字句間に空白 (RFC 822 では LWS や comment、後の RFC 2822 では CFWS) を挿入してもよいことになっています。 それに従えば type, subtype, attribute, value の前後に空白を挿入できることになりますが、 RFC 2397 ではそのことにまったく言及していません (>>23 で指摘したように、そもそも構文定義自体の記述方法の説明がありません)。

[30] RFC 2231 引数値拡張: RFC 2231 は RFC 2045 の Content-Type: 頭欄で用いられるような引数値の構文の拡張を定義しています。 data: URI scheme でこの拡張を使うことができるのかは不明です。

[31] 素片識別子: RFC 2397 は素片識別子にまったく言及していません。 RFC 2396 は素片識別子は URI の一部ではなく、 URI参照の一部であるという立場をとっていたので (後の RFC 3986 では素片識別子も URI の一部)、その考えに従っているのかもしれません。

Ian Hickson はかつて、 data: URI では素片識別子が使えないと主張していたように見えますが (>>21 にあるテストのソースを参照)、この事実以外に何か根拠があるのかは不明ですし、 現在もそのように主張しているのかは不明です。

[34] >>27 の引用部の本来の意図はどう読んでも quoted-string の代わりに token + 百分率符号化を使うのがよいなのですが、 >>27 のように解釈しても問題がありますし、value は (百分率符号化を前提としていない RFC 2045 の構文規則なので) 百分率符号化を解いた後の文字列に対する構文規則である、と解釈しても問題があります。 tspecials を含むような文字列は妥当な token ではありませんから、 a%40b を元に戻した a@b は token 足りえません (元の意図は、 a@b を "a@b" としなくてもよいとするもののはずです)。

処理モデル

[32] 他の URI scheme の仕様書と同様、 RFC 2397 は data: URI scheme の構文を定義するだけで (それすらも前述のように満足にできていないわけですが)、 どのように処理するべきか、構文的に誤った data: URI をどう扱うべきかに一切言及していません。

[33] 百分率符号化された8ビット部: 百分率符号化されたオクテットがあった場合、 data 部なら指定された媒体型に従って解釈するのでいいのでしょうが、 それ以外の部分ならどう解釈するべきなのかが問題になり得ます。 type や subtype や attribute の部分はそもそも ASCII 文字だけで定義されているので、 8ビット部が ASCII に写像されない限りどう解釈しようが問題にはなりません。

value の部分は任意の文字列を指定し得るので、 文字コードが問題となります。MIME 的に正しいのはそれでもやはり ASCII 文字だけですが。。。