675.txt

[10] [DFN[[CODE(URI)[data:]]]] は、[[実体]]を直接記述する [[URI scheme]] です。

* 仕様書

- [11] [CITE@en[RFC 2397 - The "data" URL scheme]] ([TIME[2011-04-10 20:12:40 +09:00]] 版) <http://tools.ietf.org/html/rfc2397>

* 構文

[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)[
   <IMG
   SRC="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw
   AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz
   ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp
   a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl
   ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis
   F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH
   hhx4dbgYKAAA7"
   ALT="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"]] としなくてもよいとするもののはずです)]]。

([[名無しさん]])

[[#comment]]


** 処理モデル

[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]] 版) <http://www.whatwg.org/specs/web-forms/current-work/#for-data>

* テスト

[19]
[CITE[data: URL tests]] ([CODE[2008-05-15 05:24:13 +09:00]] 版) <http://www.mozilla.org/quality/networking/testing/datatests.html>

[20]
[CITE[Opera Browser Wiki :: Data: URI Test Page]] ([CODE[2008-05-18 19:13:55 +09:00]] 版) <http://operawiki.info/DataURIs>

[21]
[CITE[Index of /tests/adhoc/data]] ([CODE[2008-05-18 19:24:49 +09:00]] 版) <http://www.hixie.ch/tests/adhoc/data/>

[35]
[CITE@en[data: URIs]] ([CODE[2008-06-01 20:50:55 +09:00]] 版) <http://suika.fam.cx/~wakaba/-temp/test/uri/data/test.cgi#>

* 関連

[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]]))
<https://twitter.com/NaomiSuzuki_/status/828321751109033985>
]REFS]

* メモ

[9]
[CITE[The data: URI kitchen]] <http://software.hixie.ch/utilities/cgi/data/data>
任意のデータから [CODE(URI)[data:]] URI をつくってくれます。

[18]
[CITE[Bug 16968 - Security violations in Acid3 test]] ([CODE[2008-01-22 20:19:03 +09:00]] 版) <http://bugs.webkit.org/show_bug.cgi?id=16968>


[36]
3ブラウザとも、 [CODE(MIME)@en[[[name]]]] [[引数]]を[[ファイル名]]に使うことはないようです。

;; [CITE@en[data: URIs]] ([TIME[2008-06-01 21:08:32 +09:00]] 版) <http://suika.fam.cx/~wakaba/-temp/test/uri/data/test.cgi#tag=name%20parameter>

[37] 
[CITE@ja[Protocol Handlers for Microsoft Internet Explorer - misuzilla.org]] ([[Mayuki Sawatari]] 著, [TIME[2007-04-28 12:45:30 +09:00]] 版) <http://www.misuzilla.org/dist/net/mphandler/>


[39] [CITE[IRC logs: freenode / #whatwg / 20090928]]
([TIME[2009-12-02 08:12:56 +09:00]] 版)
<http://krijnhoetmer.nl/irc-logs/whatwg/20090928#l-763>

[40] [CITE[IRC logs: freenode / #whatwg / 20091112]]
([TIME[2009-12-19 19:03:40 +09:00]] 版)
<http://krijnhoetmer.nl/irc-logs/whatwg/20091112#l-546>

[41] [CITE[IRC logs: freenode / #whatwg / 20100129]]
([TIME[2010-01-31 15:11:47 +09:00]] 版)
<http://krijnhoetmer.nl/irc-logs/whatwg/20100129>

[42] [CITE@en-us[data Protocol]]
([TIME[2010-02-26 22:33:41 +09:00]] 版)
<http://msdn.microsoft.com/en-us/library/cc848897(VS.85).aspx>

[43] [CITE[Inline Images on Web Pages]]
( ([TIME[2005-10-31 14:52:43 +09:00]] 版))
<http://elf.org/essay/inline-image.html>

[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]] 版))
<http://lists.w3.org/Archives/Public/public-iri/2011Apr/0066.html>

[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]] 版))
<http://lists.w3.org/Archives/Public/public-iri/2011Apr/0067.html>

[49] [CITE[data url スキームとmidi]]
( ([TIME[2008-07-21 22:49:25 +09:00]] 版))
<http://members3.jcom.home.ne.jp/nakamura7/dataurlschememidi.html>

[50] [CITE@en[Web Applications 1.0 r6783        Drop <time> and replace it with <data>. Drop the Atom conversion section entirely. Convert a bunch of examples that used to use <time pubdate> to using schema.org, to show how to annotate publication dates and the like in a machine-processable way.]]
( ([TIME[2011-10-29 14:38:00 +09:00]] 版))
<http://html5.org/tools/web-apps-tracker?from=6782&to=6783>

[51] [CITE@en[Web Applications 1.0 r6855 Bring W3C specs back to tip of tree per chair request.]]
( ([TIME[2011-12-10 03:38:00 +09:00]] 版))
<http://html5.org/tools/web-apps-tracker?from=6854&to=6855>

[52] [CITE[IRC logs: freenode / #whatwg / 20120216]]
( ([TIME[2012-02-18 19:53:35 +09:00]] 版))
<http://krijnhoetmer.nl/irc-logs/whatwg/20120216>

[53] [CITE@en-US[XMLHttpRequest]]
( ([TIME[2012-02-19 14:13:42 +09:00]] 版))
<http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#data:-urls-and-http>

[54] [CITE@en[Web Applications 1.0 r7180     Make data: URLs officially work in Workers.]]
( ([TIME[2012-07-18 06:53:00 +09:00]] 版))
<http://html5.org/tools/web-apps-tracker?from=7179&to=7180>

[55] [CITE@ja[DataURI Maximum length - latest log]]
( ([TIME[2012-08-10 00:51:04 +09:00]] 版))
<http://uupaa.hatenablog.com/entry/2012/08/09/165800>

[56] [CITE[''''''[''''''whatwg'''''']'''''' data URLs and XMLHttpRequest]]
( ([TIME[2012-09-07 04:22:04 +09:00]] 版))
<http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037188.html>

[57] [CITE[''''''[''''''whatwg'''''']'''''' Security restriction allows content thievery]]
( ([TIME[2012-09-07 03:47:04 +09:00]] 版))
<http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037187.html>

[58] [CITE[IRC logs: freenode / #whatwg / 20121126]]
( ([TIME[2012-12-09 01:19:22 +09:00]] 版))
<http://krijnhoetmer.nl/irc-logs/whatwg/20121126>

[59] [CITE@en[The "data" URL scheme]]
( ([TIME[2012-12-02 21:03:47 +09:00]] 版))
<http://simonsapin.github.com/data-urls/>

[60] [CITE[SimonSapin/data-urls · GitHub]]
( ([TIME[2012-12-09 12:55:55 +09:00]] 版))
<https://github.com/SimonSapin/data-urls>

[61] [CITE[IRC logs: freenode / #whatwg / 20121203]]
( ([TIME[2012-12-14 21:57:27 +09:00]] 版))
<http://krijnhoetmer.nl/irc-logs/whatwg/20121203>

[62] [CITE[IRC logs: freenode / #whatwg / 20121205]]
( ([TIME[2012-12-16 00:14:26 +09:00]] 版))
<http://krijnhoetmer.nl/irc-logs/whatwg/20121205>

[63] [CITE[IRC logs: freenode / #whatwg / 20130313]]
( ([TIME[2013-03-23 12:00:18 +09:00]] 版))
<http://krijnhoetmer.nl/irc-logs/whatwg/20130313>

[64] [CITE[Fetch defines data URL handling. · a64eb7c · whatwg/xhr]]
( ([TIME[2013-10-30 06:09:19 +09:00]] 版))
<https://github.com/whatwg/xhr/commit/a64eb7c2985d5ab83dca0c840ec1a95378935e11>

[65] [CITE[Fetch defines data URL handling. · a64eb7c · whatwg/xhr]]
( ([TIME[2014-01-08 07:23:40 +09:00]] 版))
<https://github.com/whatwg/xhr/commit/a64eb7c2985d5ab83dca0c840ec1a95378935e11>

[66] [CITE[SVG2 Requirements Input - SVG]]
( ([TIME[2013-06-13 12:01:58 +09:00]] 版))
<http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Gzip-compressed_svg_in_data_URIs>

[67] [CITE[Clarify data URL dependency https://www.w3.org/Bugs/Public/show_bug.cgi?... · 13cbf9d · whatwg/fetch]]
( ([TIME[2014-05-21 03:29:25 +09:00]] 版))
<https://github.com/whatwg/fetch/commit/13cbf9d18b70314dba5ed89251ed026d6d7b1dcf>

[68] [CITE[Data URL loading is now controlled through a flag. Blob URLs have an ori... · 5b64685 · whatwg/fetch]]
( ([TIME[2014-06-03 03:28:10 +09:00]] 版))
<https://github.com/whatwg/fetch/commit/5b64685a97a7d6f24814172de68399d0225a4cae>

[69] [CITE[''''''[''''''whatwg'''''']'''''' Stricter data URL policy]]
( ([TIME[2014-06-02 19:22:53 +09:00]] 版))
<http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-June/296963.html>

[70] [CITE@en[RFC 6170 - Internet X.509 Public Key Infrastructure -- Certificate Image]]
( ([TIME[2014-10-27 13:42:42 +09:00]] 版))
<https://tools.ietf.org/html/rfc6170#section-4>

[1] [CITE@en[Ambiguities in the "data" URL scheme]]
([TIME[2014-11-11 20:05:54 +09:00]] 版)
<https://simonsapin.github.io/data-urls/>

[2] [CITE@en[Set the same-origin data-URL flag. Set request's destination rather t… · whatwg/xhr@59d4f5b]]
([TIME[2015-08-19 23:48:35 +09:00]] 版)
<https://github.com/whatwg/xhr/commit/59d4f5b4b49b3ba0f0a491dbdf83865cf3d285b7>

[3] [CITE@en[Fix #111: forbid redirects to data URLs · whatwg/fetch@f986c43]]
([TIME[2015-09-23 13:41:29 +09:00]] 版)
<https://github.com/whatwg/fetch/commit/f986c43f958a0f7ffdc46553d5a53a0c56a89a32>

[4] [CITE@en[1018872 – Implement stricter data URL policy]]
([TIME[2015-09-23 13:46:53 +09:00]] 版)
<https://bugzilla.mozilla.org/show_bug.cgi?id=1018872>

[5] [CITE@en[Fix #337: perform origin checks for workers in Fetch · whatwg/html@e86b2e4]]
([TIME[2015-11-19 16:19:19 +09:00]] 版)
<https://github.com/whatwg/html/commit/e86b2e4b8fdef45404c61c1a85c40da7edf8b561>

[6] [CITE@en[Revert #111: allow redirects to data URLs · whatwg/fetch@31f65e4]]
([TIME[2016-01-09 12:01:03 +09:00]] 版)
<https://github.com/whatwg/fetch/commit/31f65e4625eacb3a74b5d1eba905d0600040c6ce>

[7] [CITE@en[Fix #176: set request's same-origin data-URL flag for <img> · whatwg/html@b09402f]]
([TIME[2016-01-20 17:32:50 +09:00]] 版)
<https://github.com/whatwg/html/commit/b09402f7f1f910bcb6025cfd255b0b7291f300a6>

[8] [CITE@en[Give user entered data: URI documents the HTTPS state 'modern' · Issue #243 · whatwg/fetch]]
( ([TIME[2016-05-04 00:43:08 +09:00]]))
<https://github.com/whatwg/fetch/issues/243>

[17] [CITE@en[Remove the note about data: and blob URLs (fixes #35)]]
( ([[fmarier]]著, [TIME[2016-05-19 06:48:47 +09:00]]))
<https://github.com/w3c/webappsec-subresource-integrity/commit/ef5f92bbe1a7a849b215bc1761cee41e8a01824e>

[71] [CITE@en[Fix form submission for the data URL scheme]]
( ([[annevk]]著, [TIME[2016-05-27 17:47:54 +09:00]]))
<https://github.com/whatwg/html/commit/e2d80d9285976c6c38bda188c59e97456006d0a3>

[FIG(quote)[
[FIGCAPTION[
[72] [CITE[Androidの標準ブラウザでbase64の画像を保存しようとすると落ちる問題 - Qiita]]
( ([TIME[2016-06-10 16:31:37 +09:00]]))
<http://qiita.com/mo49/items/4957acea626c9e07cee3>
]FIGCAPTION]

> base64はURLが長すぎるので、一部Androidの標準ブラウザでは画像を長押し保存できない

]FIG]


[73] [CITE@en[Remove the GET method restriction for data URLs]]
([[annevk]]著, [TIME[2016-08-23 22:36:24 +09:00]])
<https://github.com/whatwg/fetch/commit/c4cb4f4a5fa90a72f1000449495aec04f6c8c96b>

[FIG(quote)[
[FIGCAPTION[
[74] [CITE@en[How to: Add Silverlight to a Web Page by Using HTML]]
([TIME[2016-09-01 16:09:55 +09:00]])
<https://msdn.microsoft.com/en-us/library/cc189089(v=vs.95).aspx>
]FIGCAPTION]

> <object width="300" height="300"
>     data="data:application/x-silverlight-2," 
>     type="application/x-silverlight-2" >
>     <param name="source" value="SilverlightApplication1.xap"/>
> </object>

]FIG]


[75] [CITE@en[Set same-origin data-URL flag for <img> when environment changes]]
([[zcorpan]]著, [TIME[2016-09-08 17:52:20 +09:00]])
<https://github.com/whatwg/html/commit/208ff6e3bb16b6c31c0dd3f19ed70370cc5aa628>

[76] [CITE@en[Treat 'data:' documents as unique, opaque origins (#1756)]]
([[mikewest]]著, [TIME[2016-09-13 18:20:33 +09:00]])
<https://github.com/whatwg/html/commit/00769464e80149368672b894b50881134da4602f>

[77] [CITE@en[Fiddle with progress events]]
([[annevk]]著, [TIME[2016-09-15 22:29:05 +09:00]])
<https://github.com/whatwg/xhr/commit/01da69fb27d10a3315f9bf8259cc7074713379ee>

[78] [CITE@en[Treat data URLs as same-origin]]
([[annevk]]著, [TIME[2016-09-16 02:50:19 +09:00]])
<https://github.com/whatwg/fetch/commit/6f223de29733e64dbe1dfc6028c6e0a4a5d89398>

[79] [CITE@en[Define how data URLs affect workers]]
([[annevk]]著, [TIME[2016-09-15 19:34:58 +09:00]])
<https://github.com/whatwg/html/commit/c592f62985ab9aa0e26c111a9823de5101d58c96>

[80] [CITE@en[Remove Fetch's same-origin data URL flag]]
([[annevk]]著, [TIME[2016-09-14 23:11:01 +09:00]])
<https://github.com/whatwg/html/commit/7204ca9d0f6ac8b2439c9b77a1c4ff988de0b7e3>

[81] [CITE@en[123004 - incorrect handling of fragment identifiers in data: URIs - chromium - Monorail]]
([TIME[2016-11-02 09:48:44 +09:00]])
<https://bugs.chromium.org/p/chromium/issues/detail?id=123004>

[82] [CITE@en[Re: Bug in Acid3 test #72 (race condition when images decode asynchronously)]]
([[Simon Pieters]]著, [TIME[2017-01-02 22:22:24 +09:00]])
<https://lists.w3.org/Archives/Public/www-archive/2017Jan/0000.html>



[85] [CITE@en[New in Chrome 58  |  Web  |  Google Developers]]
([TIME[2017-04-20 02:52:31 +09:00]])
<https://developers.google.com/web/updates/2017/04/nic58>

[86] [CITE@en[737419 - Implement <data> element - chromium - Monorail]]
([TIME[2017-07-12 18:43:03 +09:00]])
<https://bugs.chromium.org/p/chromium/issues/detail?id=737419>

[87] [CITE@en[Deprecations and Removals in Chrome 60  |  Web  |  Google Developers]]
([TIME[2017-06-15 00:01:43 +09:00]])
<https://developers.google.com/web/updates/2017/06/chrome-60-deprecations>

[88] [CITE@en[684011 - Remove: Top frame navigations to data URLs - chromium - Monorail]]
([TIME[2017-07-16 00:17:05 +09:00]])
<https://bugs.chromium.org/p/chromium/issues/detail?id=684011&desc=2>

[89] [CITE@en[Testing data URLs]]
([TIME[2017-08-15 17:05:57 +09:00]])
<https://gist.github.com/annevk/4287452653921b2b7de35e4208b4a985>

[90] [CITE@en[Ambiguities in the "data" URL scheme]]
([TIME[2014-11-11 20:05:54 +09:00]])
<https://simonsapin.github.io/data-urls/>

[91] [CITE@en[SimonSapin/data-urls: Filling the gaps in RFC 2397.]]
([TIME[2017-08-18 19:30:04 +09:00]])
<https://github.com/SimonSapin/data-urls>

[92] [CITE@en[175568 – data: URL base64 handling different from atob()]]
([TIME[2017-08-23 22:41:49 +09:00]])
<https://bugs.webkit.org/show_bug.cgi?id=175568>