[10] [DFN[[CODE(URI)[data:]]]] は、 [[fetch]] の結果得られるデータそのものを [[URL]] 中に含めることができる [[URL scheme]] です。 * 仕様書 [REFS[ - [96] [CITE@en[Fetch Standard]] ([TIME[2018-01-31 18:00:34 +09:00]]) - [97] '''[CITE@en[Fetch Standard]] ([TIME[2018-01-31 18:00:34 +09:00]]) ''' ]REFS] * データモデル [105] [DFN[[RUBYB[[CODE[data:]] URL構造体]@en[[CODE[data:]] URL struct]]]]は、 [F[MIME型]]と[F[本体][本体 (data:)]]を持つ[[構造体]]です [SRC[>>97]]。 * 構文 [129] [CODE[data:]] [[URL]] は、 [[URL scheme]] の後に [[MIME型]]、 [CODE[,]]、 [[本体][本体 (data:)]]を連結したものです。 他の [[URL scheme]] 同様に[[素片識別子]]を使うこともできます。 [FIG(railroad)[ = [CODE[data:]] = [[MIME型]] = [CODE[,]] = [[本体][本体 (data:)]] = ? == [[素片識別子]] ]FIG] [130] [CODE[data:]] [[URL]] における [[MIME型]]は、 [[URL]] に含まれるデータの [[MIME型]]を表しています。 一般的な [[MIME型]]とはいくつか異なる点があります。 - [131] [CODE[text/plain;charset=US-ASCII]] のとき、省略して[[空文字列]]にできます - [132] [[MIME型部分]]が [CODE[text/plain]] のとき、省略して[[引数]]のみとできます - [133] [[本体][本体 (data:)]]が [[Base64]] [[符号化]]されていることを表す特別な[[引数]] [CODE[;base64]] を末尾に指定できます。 [CODE[base64]] は[[大文字]]でも[[小文字]]でも構いません。 [FIG(railroad)[ = | == [[MIME型]] == = === [[空白][HTMLの空白]] === * ==== = ===== [CODE[;]] ===== [[空白][HTMLの空白]] ===== [[引数][引数 (HTTP)]] ===== [[空白][HTMLの空白]] = ? == [CODE[;]] == [[空白][HTMLの空白]] == [CODE[base64]] ]FIG] [135] [[本体][本体 (data)]]は、 [[URL]] に含まれるデータを表しています。 任意の[[バイト列]]を表現できますが、 [[URL]] の構文上の制約から適宜[[パーセント符号化]]が必要です。 [136] [CODE[;base64]] を指定した場合は、 表現する[[バイト列]]そのものではなく、 それを [[Base64]] で[[符号化]]した結果を使います。 ;; [[URL安全Base64]]などのバリエーションでは''なく''、 通常の [[Base64]] を使います。[[詰め]]は必須で、[[改行]]を挿入する必要はありません。 [137] [[仕様]]上は長さの制限もありませんが、 現実的には[[実装依存]]の [[URL]] の長さの制限を超えない必要があります。 ** 構文解析 [106] [CODE[data:]] [[URL]] の[[構文解析]]は、 まず[[URLの構文解析]]を行った後、 [[[CODE[data:]] URL処理器]]により処理させることで行なえます。 [107] [DFN[[RUBYB[[CODE[data:]] URL処理器]@en[[CODE[data:]] URL processor]]]]は、 [VAR[[[URL記録]]]]について、 次のようにします [SRC[>>97]]。 [FIG(steps)[ = [108] [VAR[入力]]を、 [VAR[URL記録]]に [[URL直列化器]]を[VAR[素片除外フラグ]]付きで適用した結果に設定します。 = [112] [VAR[入力]]に [CODE[,]] が含まれない場合、 == [113] [[失敗]]を返し、ここで停止します。 = [115] [VAR[入力]]を、最初の [CODE[,]] で分割し、 [VAR[MIME型文字列]]に直前までを、 [VAR[符号化本体]]に直後からを設定します。 = [116] [VAR[MIME型文字列]]の先頭から [CODE[data:]] を除去します。 = [111] [VAR[MIME型文字列]]の先頭と末尾の [[ASCII空白]]をすべて除去します。 = [109] [VAR[本体]]を、[VAR[符号化本体]]に[[文字列パーセント復号]]を適用した結果に設定します。 = [110] [VAR[MIME型文字列]]の末尾に [CODE[;]]、0個[[以上]]の [CODE[U+0020]]、 [[ASCII大文字・小文字不区別]]で [CODE[base64]] の列がある場合、 == [120] これを[VAR[MIME型文字列]]から除去します。 == [114] [VAR[文字列本体]]を、[VAR[本体]]に[[同型復号]]を適用した結果に設定します。 == [117] [VAR[本体]]を、[VAR[文字列本体]]に [[forgiving-base64 decode]] を適用した結果に設定します。 == [118] [VAR[本体]]が[[失敗]]の場合、 ==== [119] [[失敗]]を返し、ここで停止します。 = [121] [VAR[MIME型文字列]]の先頭が [CODE[;]] の場合、 == [122] [VAR[MIME型文字列]]の先頭に [CODE[text/plain]] を挿入します。 = [123] [VAR[MIME型]]を、[VAR[MIME型文字列]]に[[MIME型を構文解析]]する処理を適用した結果に設定します。 = [124] [VAR[MIME型]]が[[失敗]]の場合、 == [125] [VAR[MIME型]]を、 [CODE[text/plain;charset=US-ASCII]] に[[MIME型を構文解析]]する処理を適用した結果に設定します。 = [126] 新しい [[[CODE[data:]] URL構造体]]を返します。 [FIG(list members)[ [127] [[[CODE[data:]] URL構造体]] : [F[MIME型]] : [VAR[MIME型]] : [F[本体][本体 (data)]] : [VAR[本体]] ]FIG] ]FIG] ;; [128] [[URL記録]]をすぐに[[URL直列化器]]で[[文字列]]に戻していますが、 [[URLの構文解析]]の時点で[[正準化][URLの正準化]]が行われるため、 [CODE[data:]] [[URL文字列]]をそのまま与えるのとは違います。 [144] この処理は [[scheme fetch]] で呼び出されます。 * fetch [138] [CODE[data:]] [[URL]] についての [[scheme fetch]] は、[VAR[[[要求]]]]について次のようにします [SRC[>>96]]。 [FIG(steps)[ = [139] [VAR[構造体]]を、 [VAR[要求]]の[F[現在URL]]について [[[CODE[data:]] URL処理器]]を実行した結果に設定します。 = [140] [VAR[構造体]]が[[失敗]]の場合、 == [141] [[ネットワークエラー]]を返し、ここで停止します。 = [142] 新しい[[応答]]を返します。 [FIG(list members)[ [143] [[応答]] : [F[状態メッセージ]] : [CODE[OK][200]] : [F[ヘッダーリスト]] : [FIG(list members)[ : [CODE[Content-Type]] : [VAR[構造体]]の[F[MIME型]]に [[MIME型をバイト列に直列化]]する処理を適用した結果 ]FIG] : [F[本体][本体 (data)]] : [VAR[構造体]]の[F[本体][本体 (data)]] : [F[HTTPS状態]] : [VAR[要求]]の[F[クライアント][要求クライアント]]が [CODE[null]] でない場合、 [VAR[要求]]の[F[クライアント][要求クライアント]]の[F[HTTPS状態]] ]FIG] ]FIG] * テスト [104] [CITE@en[web-platform-tests/fetch/data-urls at master · w3c/web-platform-tests]] ([TIME[2018-02-05 17:33:21 +09:00]]) [19] [CITE[data: URL tests]] ([CODE[2008-05-15 05:24:13 +09:00]] 版) [20] [CITE[Opera Browser Wiki :: Data: URI Test Page]] ([CODE[2008-05-18 19:13:55 +09:00]] 版) [21] [CITE[Index of /tests/adhoc/data]] ([CODE[2008-05-18 19:24:49 +09:00]] 版) [35] [CITE@en[data: URIs]] ([CODE[2008-06-01 20:50:55 +09:00]] 版) * 関連 [47] [CODE(HTMLe)@en[[[canvas]]]] [[要素]]の [CODE(DOMm)@en[[[toDataURL]]]] [[メソッド]]は、 [[レンダリング]]されている[[画像]]を [CODE(URI)@en[[[data:]]]] [[URL]] として[[符号化]]して返します。 [[JavaScript]] には元々[[バイナリー]]を表す[[データ型]]がなかったので、 [[JavaScript]] / [[DOM]] で[[画像]]のデータを表現する唯一の方法として [CODE(URI)@en[[[data:]]]] [[URL]] の[[文字列]]が利用されています。 ;; [48] 現在では [CODE(DOMi)@en[[[Blob]]]] もありますが。 * セキュリティー [84] [[フィッシング]]に使われた例が報告されています [SRC[>>83]]。 [REFS[ - [83] [CITE@ja[Naomi Suzukiさんのツイート: "そうこうしていたら偽サイトを直接開くのを止め、data:スキームでアドレスバーを「https://t.co/BekqCCLtmB」に見せかける小細工をしてきましたよ。先ほどの偽サイト本体はフレーム内表示になり、ランディングページはこんな感じになります(アドレスバーに注目ね)。 https://t.co/R6v2bdmrGR"]] ( ([TIME[2017-02-06 17:37:19 +09:00]])) ]REFS] * 歴史 ** RFC 2397 時代 - [11] [CITE@en[RFC 2397 - The "data" URL scheme]] ([TIME[2011-04-10 20:12:40 +09:00]] 版) *** 構文 [22] (他の [[URI scheme]] 同様) [CODE(URI)@en[[[data]]:]] [[URI scheme]] の仕様は非常に曖昧です。古い時代の仕様書なので仕方がありませんが、 どこまでが[[規定]]でどこからが[[参考]]なのかも明確ではありません。 [12] '''構文の概要''': [[RFC 2397]] の2章によると、 [CODE(URI)@en[[[data]]:]] URI の構文を簡単にあらわすと > [CODE(URI)[data:[SPAN[''['']]<[VAR[mediatype]]>[SPAN['']'']]''['';base64'']'',<[VAR[data]]>]] となります。 [13] '''構文の定義''': [[RFC 2397]] の3章は更に詳しく > - dataurl := "data:" [ mediatype ] [ ";base64" ] "," data - mediatype := [ type "/" subtype ] *( ";" parameter ) - data := *urlchar - parameter := attribute "=" value ;; - [CODE(ABNF)@en[[[urlchar]]]]: [[RFC 2396]] の定義を参照 - [CODE(ABNF)@en[[[type]]]], [CODE(ABNF)@en[[[subtype]]]], [CODE(ABNF)@en[[[attribute]]]], [CODE(ABNF)@en[[[value]]]]: [[RFC 2045]] の定義を参照 と定義しています。 [23] '''構文の定義自体の問題''': 自明だからどうでも良いと思ったのか、 この構文定義自体が何で書かれているのか説明がありません[AA[wwwww]] [[ABNF]] の一種だろうと思いますが・・・。 [24] '''[CODE(ABNF)@en[[[urlc]]]]''': [CODE(ABNF)@en[[[urlc]]]] は [[RFC 2396]] の定義を参照していることになっていますが、 実のところ [[RFC 2396]] で [CODE(ABNF)@en[[[urlc]]]] は定義されていません。 おそらく [CODE(ABNF)@en[[[uric]]]] の誤りなのでしょうが、これは致命的です。 ;; そもそも、 [[RFC 2396]] を参照しておきながらなぜ [Q@en[[[UR''L'' scheme]]]] なのかが謎です。 [14] '''[CODE(ABNF)@en[[[value]]]]''': [CODE(ABNF)[[[value]]]] は [[RFC 2045]] で [CODE(ABMF)@en[[[token]]]] または [CODE(ABNF)@en[[[quoted-string]]]] と定義されています。しかし、 [CODE(ABNF)@en[[[quoted-string]]]] は URI で直接使えない ([CODE(ABNF)@en[[[unsafe]]]] な) [CODE(char)[[["]]]] や [CODE(char)[[[\]]]] を使います。 つまり、構文通り解釈すると使えるはずのものが [[URI]] 仕様との整合性を考慮すると使えないのです。 実は使えないのはこの2文字だけではなく、[[改行]]を含む[[C0制御文字]]や[[空白]]なども [[URI]] ではそのまま使えません。更に、この [CODE(ABNF)@en[[[value]]]] や、 [CODE(ABNF)@en[[[token]]]] として定義されている [CODE(ABNF)@en[[[attribute]]]] には [CODE(char)@en[[[%]]]] を含めることができますが、 [[URI]] では [CODE(char)@en[[[%]]]] は[[百分率符号化]]のための特別な文字として使われます。 [25] '''百分率符号化''': [[RFC 2397]] の[[著者]]も馬鹿ではありませんから、[[百分率符号化]] (当時の名称は [[URI逃避符号化]]、[[RFC 2396]] における呼称は [[URL逃避符号化]]) との関係に言及しています。 [26] まず一点目に、[Q[必要に応じて[[百分率符号化]]を用いて表現する]]との旨が規定されています [SRC@en[[[RFC 2397]] 3.]]: > [PRE[ [INS[(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. ]PRE] この最後の部分がどこに係っているのかが曖昧なので、3通りの解釈が可能です: - [[百分率符号化]]は [CODE(ABNF)@en[[[type]]]], [CODE(ABNF)@en[[[subtype]]]], [CODE(ABNF)@en[[[attribute]]]], [CODE(ABNF)@en[[[value]]]] で使用可能 - [[百分率符号化]]は [CODE(ABNF)@en[[[urlc]]]], [CODE(ABNF)@en[[[type]]]], [CODE(ABNF)@en[[[subtype]]]], [CODE(ABNF)@en[[[attribute]]]], [CODE(ABNF)@en[[[value]]]] で使用可能 - [[百分率符号化]]は [CODE(URI)@en[[[data]]:]] URI 全体で使用可能 普通修飾するのは直前のものでしょうから、3つ目の解釈は少々無理があるかもしれませんが、 あり得ないとまではいえません。ちなみに3つ目の解釈に従うなら [CODE(URI)@en[[[base64]]]] の部分に[[百分率符号化]]が使えます。 1つ目と2つ目の解釈の違いは [CODE(ABNF)@en[[[urlc]]]] で[[百分率符号化]]が使えるか否かですが、 そもそも [CODE(ABNF)@en[[[ur''i''c]]]] には [CODE(ABNF)@en[[[escaped]]]] ([[百分率符号化]]) が含まれているので、どちらでも同じことになります。 [Q@en[as necessary]] というのも曲者で、穿った読み方をすれば、 必要でない場合には使ってもよいとされていないとも解釈し得ます。 (流石にこれは深読みしすぎでしょうが。) [27] 2点目に、[CODE(ABNF)@en[[[value]]]] での[[百分率符号化]]について、 > [PRE[ 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". ]PRE] と言及しています [SRC@en[[[RFC 2397]] 3.]]。ここで、 前述の構文が[[百分率符号化]]込みのものと理解するべきかという問題が発生します。 この引用部をそのまま解釈すると、 [CODE(ABNF)@en[[[token]]]] の部分に[[百分率符号化]]が使えることになります。 [CODE(ABNF)@en[[[token]]]] を定義している [[RFC 2045]] は [[URI]] のことなど気にしていないので、当然[[百分率符号化]]が使えるかどうか、 その使い方には言及していません。ただし、[CODE(ABNF)@en[[[token]]]] で使える[[文字]]には [CODE(char)[[[%]]]] が含まれています (この辺の事情は引用部の [Q@en[should not]] を無視して [CODE(ABNF)@en[[[quoted-string]]]] を使う場合にも該当します)。 たとえば [CODE(example)@en[100%!]] は[[妥当]]な [CODE(ABNF)@en[[[token]]]] です。しかし、 [[16進数字]]が2つ続かない [CODE(char)[[[%]]]] を [[URI]] で使うことはできません。 [[URI]] の仕様に従うなら、 [[百分率記号]]を表したいときは [CODE(URI)[[[%]]25]] と書かなければなりません。 [28] また、[[百分率符号化]]を前述の部分のどんな[[文字]]にも使ってよいのかも明確ではありません。 たとえば [CODE(ABNF)@en[[[subtype]]]] が [SAMP(MIME example)@en[svg+xml]] であったとして、 [[URI]] に [CODE(example URI)[svg+xm%6C]] と書いても、 (どんな [[URI scheme]] でも[[非予約]]な[[文字]]は[[百分率符号化]]してもしなくても[[等価]]なので) 問題ありません。 しかし、 [CODE(URI example)[svg%2Bxml]] が前2例と[[等価]]であるのか否かは明らかではありません。 ([CODE(char)[+]] は [CODE(char)[[[reserved]]]] なので。) 意図としては[[百分率符号化]]を使っても構わないのでしょうが。。。 ;; URI の構文の一部に URI 以外のプロトコル要素の定義を引用することはよくありますが、 このような解釈の問題が起きないように、慎重に設計することをお願いしたいものです。 [15] '''Base64''': また、 [CODE(ABNF)[";base64"]] が指定されると、 [CODE(ABNF)[data]] は [[Base64]] と解釈されます。 (この指定で大文字と小文字が区別されるかどうかがよくわからないのも問題です。) ところが、その [Q[Base64]] の定義が何を参照しているのかが全然書かれていません。 他のところで RFC 2045 を参照しているので、そこで定義されているものと解釈するのが一番もっともらしそうですが、 Base64 は色々な変種が知られているので、油断できません。 (その変種のほとんどが、 RFC 2045 の [[MIME]] にべったりな部分に手を加えたものです。) たとえば、改行や空白の問題があります。 RFC 2045 の Base64 では一行の字数制限があるのですが、それが適用されるかどうかわかりません。 4. には次のような例が載っています。 > [PRE(HTML)[ Larry ]PRE] 行頭の[[間隔]]は RFC としての余白です。 それを無視したとしても、行を折り返しているのが RFC としての行字数制約によるだけで本来いれては'''ならない'''ものなのか、 RFC の制限だけど実際にも入れても'''よい''' '''ものなのか、説明が全然ありません。''' (かりに入れてもよいとしても、 URI 逃避符号化しない限り URI 全体の構文に違反しますがね。) [16] >>15 のようなことが気になるのは、実際に生の改行入りで [[XLink]] の属性なんかに指定した例が存在するからです。 (XLink の [CODE(XMLa)[[VAR[xlink:]][[href]]]] 属性値は [[URI参照]]そのものではなく、 [Q[URI 逃避符号化すれば URI 参照になるもの]]なので、 XLink 的にも一般の URI 的にもこの指定自体は一応合法。) [29] '''空白''': [[RFC 2045]] [[MIME]] を [[RFC 822]] [[電子メイル]]の文脈で使う場合、 [[構文]]定義上は明記されていませんが、[[字句]]間に[[空白]] ([[RFC 822]] では [CODE(ABNF)@en[[[LWS]]]] や [CODE(ABNF)@en[[[comment]]]]、後の [[RFC 2822]] では [CODE(ABNF)@en[[[CFWS]]]]) を挿入してもよいことになっています。 それに従えば [CODE(ABNF)@en[[[type]]]], [CODE(ABNF)@en[[[subtype]]]], [CODE(ABNF)@en[[[attribute]]]], [CODE(ABNF)@en[[[value]]]] の前後に[[空白]]を挿入できることになりますが、 [[RFC 2397]] ではそのことにまったく言及していません (>>23 で指摘したように、そもそも構文定義自体の記述方法の説明がありません)。 [30] '''[[RFC 2231]] [[引数値]]拡張''': [[RFC 2231]] は [[RFC 2045]] の [CODE(MIME)@en[[[Content-Type]]:]] [[頭欄]]で用いられるような[[引数値]]の構文の拡張を定義しています。 [CODE(URI)@en[[[data]]:]] [[URI scheme]] でこの拡張を使うことができるのかは不明です。 [31] '''素片識別子''': [[RFC 2397]] は[[素片識別子]]にまったく言及していません。 [[RFC 2396]] は[[素片識別子]]は [[URI]] の一部ではなく、 [[URI参照]]の一部であるという立場をとっていたので (後の [[RFC 3986]] では[[素片識別子]]も [[URI]] の一部)、その考えに従っているのかもしれません。 [[Ian Hickson]] はかつて、 [CODE(URI)@en[[[data]]:]] [[URI]] では[[素片識別子]]が使えないと主張していたように見えますが (>>21 にあるテストのソースを参照)、この事実以外に何か根拠があるのかは不明ですし、 現在もそのように主張しているのかは不明です。 [34] >>27 の引用部の本来の意図はどう読んでも [Q[[CODE(ABNF)@en[[[quoted-string]]]] の代わりに [CODE(ABNF)@en[[[token]]]] + [[百分率符号化]]を使うのがよい]]なのですが、 >>27 のように解釈しても問題がありますし、[CODE(ABNF)@en[[[value]]]] は [WEAK[([[百分率符号化]]を前提としていない [[RFC 2045]] の構文規則なので)]] [[百分率符号化]]を解いた後の[[文字列]]に対する構文規則である、と解釈しても問題があります。 [CODE(ABNF)@en[[[tspecials]]]] を含むような[[文字列]]は[[妥当]]な [CODE(ABNF)@en[[[token]]]] ではありませんから、 [CODE(example URI)@en[a%40b]] を元に戻した [CODE(example MIME)@en[a@b]] は [CODE(ABNF)@en[[[token]]]] 足りえません [WEAK[(元の意図は、 [CODE(example MIME)@en[a@b]] を [CODE(example URI)@en["a@b"]] としなくてもよいとするもののはずです)]]。 *** 処理モデル [32] 他の [[URI scheme]] の仕様書と同様、 [[RFC 2397]] は [CODE(URI)@en[[[data]]:]] [[URI scheme]] の構文を定義するだけで [WEAK[(それすらも前述のように満足にできていないわけですが)]]、 どのように処理するべきか、構文的に誤った [CODE(URI)@en[[[data]]:]] [[URI]] をどう扱うべきかに一切言及していません。 [33] '''百分率符号化された8ビット部''': [[百分率符号化]]された[[オクテット]]があった場合、 [CODE(ABNF)@en[[[data]]]] 部なら指定された[[媒体型]]に従って解釈するのでいいのでしょうが、 それ以外の部分ならどう解釈するべきなのかが問題になり得ます。 [CODE(ABNF)@en[[[type]]]] や [CODE(ABNF)@en[[[subtype]]]] や [CODE(ABNF)@en[[[attribute]]]] の部分はそもそも [[ASCII]] [[文字]]だけで定義されているので、 8ビット部が [[ASCII]] に写像されない限りどう解釈しようが問題にはなりません。 ;; たとえば8ビット目を落とすとか、[[UTF-8]] で [[Unicode case-insensitive]] に処理したりすると問題になりますが。 [CODE(ABNF)@en[[[value]]]] の部分は任意の文字列を指定し得るので、 [[文字コード]]が問題となります。[[MIME]] 的に正しいのはそれでもやはり [[ASCII]] [[文字]]だけですが。。。 ** フォーム提出 [38] [CITE@en-GB-x-Hixie[Web Forms 2.0]] ([TIME[2009-01-05 20:07:15 +09:00]] 版) ** [9] [CITE[The data: URI kitchen]] 任意のデータから [CODE(URI)[data:]] URI をつくってくれます。 [18] [CITE[Bug 16968 - Security violations in Acid3 test]] ([CODE[2008-01-22 20:19:03 +09:00]] 版) [36] 3ブラウザとも、 [CODE(MIME)@en[[[name]]]] [[引数]]を[[ファイル名]]に使うことはないようです。 ;; [CITE@en[data: URIs]] ([TIME[2008-06-01 21:08:32 +09:00]] 版) [37] [CITE@ja[Protocol Handlers for Microsoft Internet Explorer - misuzilla.org]] ([[Mayuki Sawatari]] 著, [TIME[2007-04-28 12:45:30 +09:00]] 版) [39] [CITE[IRC logs: freenode / #whatwg / 20090928]] ([TIME[2009-12-02 08:12:56 +09:00]] 版) [40] [CITE[IRC logs: freenode / #whatwg / 20091112]] ([TIME[2009-12-19 19:03:40 +09:00]] 版) [41] [CITE[IRC logs: freenode / #whatwg / 20100129]] ([TIME[2010-01-31 15:11:47 +09:00]] 版) [42] [CITE@en-us[data Protocol]] ([TIME[2010-02-26 22:33:41 +09:00]] 版) [43] [CITE[Inline Images on Web Pages]] ( ([TIME[2005-10-31 14:52:43 +09:00]] 版)) [44] [CODE(HTMLe)@en[[[img]]]] [[要素]]の [CODE(HTMLa)@en[[[src]]]] [[属性]]に設定すると、すぐに (おそらく同期的に) 読み込む [[Gecko]] のようなブラウザと、そうではない [[WebKit]] のようなブラウザがあります。 [45] [CITE@en[Re: Non-hierarchical base URLs (was Re: draft-abarth-url-01 uploaded)]] ( ([[Julian Reschke]] 著, [TIME[2011-04-27 01:03:23 +09:00]] 版)) [46] [CITE@en[Re: Non-hierarchical base URLs (was Re: draft-abarth-url-01 uploaded)]] ( ([[Boris Zbarsky]] 著, [TIME[2011-04-27 01:14:49 +09:00]] 版)) [49] [CITE[data url スキームとmidi]] ( ([TIME[2008-07-21 22:49:25 +09:00]] 版)) [50] [CITE@en[Web Applications 1.0 r6783 Drop