[126] 初期の URL の仕様書や RFC 1630、RFC 1738
と WWW 草創期の仕様書には file:
URL
の規定が含まれていましたが、その次の RFC 2396 世代以後 file:
URL の仕様書は更新されなくなってしまいました。
[174] 実際には様々なプラットフォームの様々な実装がそれぞれの自由な形で実装しており、 それら旧時代の仕様書も当時からほとんど有名無実化していました。
[7] file:
の構文や意味、処理は各システムそれぞれの実装や慣習その他の事情に依存するものであり、
一切標準化の対象とするべきではないと考える人もいます。
[175] IETF が file:
URL を規定しないまま旧仕様 RFC 1738
を廃止したため、名実ともに標準不在の状態が十数年続きましたが、
ついに、 (廃止された RFC 1738
を更新するという不思議な形で) RFC 8089 >>172 が出版されました。
[173] しかし、 RFC 8089 は若干当世の事情を注記しているとはいえ、 おおむね旧仕様の延長線上といえる内容で、混乱した現状を収拾できそうにはありません。
[176] WHATWG の URL Standard は file:
URL
も含む URLの構文解析の方法を規定しています >>177。
現実の Webブラウザーの実装状況を反映して、
他の URL scheme とはかなり異なる処理となっています。
[127] URL scheme である「file:
」の後にファイル名を指定しますが、
このファイル名は他の URL と似たものから各 OS のファイル名の表記法に従ったもの、
あるいはその混合や折衷など様々な形が知られています。
[128] ファイル名の部分はその環境におけるファイル・システム上の位置をそのまま表記することもあれば、 相対参照のようなものを使うことや、利用者エージェントが仮想的にファイルのように見せて提供するものを示す文字列であることもあります。
[129] 通常の URL の規則に従い素片識別子が利用可能であることが一般的ですが、
#
もファイル名の一部と解されることもあります。
[149] file:
URLの起源は、実装依存とされています。
[150] 古くは、ローカルファイルは遠隔サーバーの文書より安全とみなして、 通常の Web 上の文書より高い特権を与えるものもありました。 しかしトロイの木馬のような形で悪意ある文書を送り込まれたり、 利用者を巧みに誘導して悪意ある文書を作成させたりできて危険なので、 現在では行われなくなっています。
[151] 90年代や00年代初期には、 HTML 等一連のファイル群を CD-ROM で配布することがありました。そのような利用方法との互換性を考慮するなら、 ディスクを1つの起源とするのもありかもしれません。
[153] Webページ、完全で保存された HTML との互換性を考慮するなら、
ファイル本体と、
ファイルの名前 + .files
や _files
のディレクトリー内のファイルとは同じ起源として扱える必要がありそうです。
悪意ある文書が他のファイルに干渉できないよう、他のファイルとは異なる起源にするべきかもしれません。
[154] MHT ファイルもまた、内外で異なる起源にするべきかもしれません。
[155] 実装の中には、開発者の利便性とセキュリティーのバランスを取って、 同じディレクトリーにはアクセスでき、祖先にはアクセスできないような方法を採っているものもあるようです。
[158] Chrome は file://
を起源の直列化として返します。
(が、file:
全体を1つの起源として扱っているわけではないようです。)
[156] file:
の fetch は、実装依存とされています。
[157] Webブラウザーは、普通、ディレクトリーを fetch すると、 ディレクトリー内のファイルやディレクトリーの一覧を生成して返します。
[159] Windows の Chrome は file:///
や file://foo/
を (\\foo
が実在するかに関わらず) ネットワークエラーとして扱うようです。
[160] Windows の Chrome は存在しないファイルを開こうとすると
404
ではなくネットワークエラーとして扱うようです。
[91] IETF の RFC として最初に file:
URL
を定義したのは RFC 1630 でした。
[223]
RFC1630 は URI
に関する最初の RFC
ですが、 file:
URI 方式を定義した最初の RFC
でもあります。
[95] file:
は他の URL scheme とは違ってどこでも同義ではなく、
解釈するホストによって異なるという点が特殊です。しかしローカル・ファイル・システムのファイルを指す
URL は必要性があるために定義したとされています。
[92] 構文は ftp:
と同じながら、 /
はディレクトリーの分離子を表すものとされていました。
なぜか BNF 構文は示されていませんでした。
[93] authority については、 file:
URL
は解釈によりホストによって指すものが変わり混乱の元であり、
有害な場合もあるため、異なるホストのものを指すことを明確にするために利用可能となっている、
と説明されていました。また、他のホストのファイルにアクセスする手段があればそれを使ってもよいとされていました。
[94] 特別な authority である localhost
は、 authority
が空であるのと同義であり、どのホストであってもそのホストを表すとされていました。
[123] これはどのホストでも共通でマウントされているようなファイルや、
/etc/hosts
のようにおおくのホストで共通に存在するファイルに有用とされていました。
[224]
なぜか、 RFC 1630 の BNF
定義には file:
URI
は載っていません。
「構文は
ftp:
と同じ」
とされている
>>222
ことから推測してみます。
- ftpaddress f t p : / / login / path [ ftptype ]
- login [ user [ : password ] @ ] hostport
- hostport host [ : port ]
- host hostname | hostnumber
- hostname ialpha [ . hostname ]
- hostnumber digits . digits . digits . digits
- xalpha alpha | digit | safe | extra | escape
- xalphas xalpha [ xalphas ]
- xpalpha xalpha | +
- xpalphas xpalpha [ xpalphas ]
- ialpha alpha [ xalphas ]
- digits digit [ digits ]
- path void | xpalphas [ / path ]
[225]
ftptype
が file:
URI に不要なことは明らかです。
[226]
hostport
でなくて
login
を使うのかどうかも謎です。
後の ..//RFC1738
の定義に従うなら、これは前者です。
実際にも file access
に user@password までわざわざ記述する必要はないと思われます。
(ホスト名を指定可能にした理由は普遍性の確保ですが、 Un|x
などで login する利用者によってファイルシステムの木まで変わってしまうことは (~
を除いて)
ありませんから。 remote file
access は別の scheme が用意されているので対象外ですし。)
[227] 更に、 local file access に port なんて存在しませんからこれも削ります。
[229] RFC1738 が file:
URI 方式を定義しています。
[98] 次に file:
URL を定義したのは IETF 標準化過程 RFC であった RFC 1738
でした。 IANA にも登録されました。
[99] authority は FQDN、path はその FQDN で表されるホストにおけるパスを表すとされていました >>96。
[100] 構文は次のように定義されていました >>102。
fileurl = "file://" [ host | "localhost" ] "/" fpath
[103] localhost
や空文字列はやはりそのホストを表すとされていました >>96。
[302] RFC 1738 の5章では ABNF
定義が挙げられています。
file:
URI
に関係する部分だけを抜粋します:
- fileurl = "file://" [ host | "localhost" ] "/" fpath
- host = hostname | hostnumber
- hostname = *[ domainlabel "." ] toplabel
- domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit
- toplabel = alpha | alpha *[ alphadigit | "-" ] alphadigit
- alphadigit = alpha | digit
- hostnumber = digits "." digits "." digits "." digits
- digits = 1*digit
- fpath = fsegment *[ "/" fsegment ]
- fsegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ]
- escape = "%" hex hex
- unreserved = alpha | digit | safe | extra
- uchar = unreserved | escape
- safe = "$" | "-" | "_" | "." | "+"
- extra = "!" | "*" | "'" | "(" | ")" | ","
[303] この定義をちょっと見やすく書き直してみます。
[304] file:
の部分は小文字で書くのが正式ですが、実装は大文字も受け付けるべきとされています。その他の部分 (localhost
の部分も含む。) の大文字・小文字の区別についての言及はありません。
[305] >>304 あ、 escape
に大文字も小文字も使えることは明記されています。
[306] hostname
は FQDN ですから、大文字・小文字は区別されないと予想されます。ですから localhost
もされないと予想は出来ますが、定かではありません。 fpath
の部分はシステム依存でしょうが、 Un|x など多くのシステムで区別しないと現実的に使い物になりませんから、少なくても区別を無視しないといけないということはないでしょう。 (そんな重要な要求は書き忘れるはずがないし。)
[307] まあ明記されてないのは常識で判断して問題ないということでしょうな。
[107] RFC 1738 の次の RFC 2396 は URL scheme の定義を含んでおらず、
file:
URL についても個別の Internet Draft
が出版されましたが、 RFC 化には至らず現在まで放置されています。
[108] 現在では IETF 的には公式には RFC 1738 は廃止されており、
file:
URL は標準不在となっています。
[109] この Internet Draft は基本的には RFC 1738 の定義を引き継いでいますが、 次のような記述が追加されています。
[132] あくまで例示としてではありますが、 RFC 3986 は、 file:
URL
では authority の省略、空の host、 localhost
はいずれも当該利用者の計算機を指すものと定義されている、
と述べています。
[104] 遠隔のファイルにアクセスするプロトコルやファイル・システムは大抵専用の
URL scheme が存在しています。例: ftp:
, nfs:
,
afs:
, smb:
[105] Webブラウザーなどのシステムに組み込まれた特別なファイルについては専用の
URL scheme が存在することがあります。例: about:
,
res:
, resource:
, chrome:
,
chrome-extension:
, shell:
,
moz-icon:
, rom:
, device:
[57] DOS ・ Windows 系の file:
URI
の形式の色々:
authority
の部分authority
を使用 (file://host/path/to/file など)path
が実は相対参照)[59] 照会: 局所ファイルを実行させる機能がある利用者エージェントは
query
の使用を認めていることがあります。
[8] 特に Windoze 上の UA において、 file: 以下のあらわしかたには様々なものがありました。
UA | file: | file:// | file:/// | file://localhost/ | メモ | ||||||||
C|/ | C:/ | C:\ | C|/ | C:/ | C:\ | C|/ | C:/ | C:\ | C|/ | C:/ | C:\ | ||
M$IE2.0 | ○ | ○ | ○ | ○ | ○ | ○ | |||||||
11111 |
[220] A Guide to the Internet Connection Servers - SG244805.PDF, , http://ps-2.kev009.com/rs6000/redbook-cd/SG244805.PDF#page=32
[41] Windoze (WinIE) では、特殊フォルダをあらわす次のような形式 (file:///::{clsid}) が使えます。
この機能は遅くても Win2k で実装されています。
例:
フォルダによっては CLSID 表現ではなく、 shell: scheme が使用されます。
file://Folder Settings\folder.htt
とか file://folder.htt
とか書けるらしいです。。。
[162] プラットフォームによっては、ディスク上のオブジェクトではなく、 OS 上の装置を表す特殊なファイルが存在することがあります。
[163] これが file:
URL として利用できる場合、
利用者の意図せぬ (場合によっては実装の開発者も意図せぬ)
挙動となることがありますから、取り扱いには注意が必要です。
[17] >>16 の問題が広く取り上げられた例として、
CON
CON
問題がありました。
[19] Un|x でも、 Mozilla で file:///dev/zero
を見ようとすると困ったことになるとか、同様の問題があったりもします。
[164] Unix 系 CLI では擬似ファイル名 -
で標準入力を表したりしますが、
file:
URL では使えなそうです。
[13] 実験してみますた。 file:///
でドライブ一覧 (A|/
とかが並んでる。)
が出てきます。 Location: 欄に file:///C|/
, file:///C:/
,
file:///C%7C/
と入力すると望んだものが出てきますが、 file:///C:\
とすると busy で死んでしまいました。 file://
はだめでした。
[14] Lynx では HOME を表す ~ が使えます。
URL Schemes Supported in Lynx http://lynx.isc.org/release/lynx2-8-3/lynx_help/lynx_url_support.html#file
file:///c:/
と file:///C|/
は、得られる効果は同じですが、違うものとして扱われているようです。 (redirect みたいな関係にはないようです。) テ゛ィレクトリ /C%3A とか /%7C とか「ちゃんと」表示されます。[53]
Un|x 版 Mozilla 1.2.1 ですが、authority
は常に無視して localhost
であるかのように扱ってくれます。何か変ですし、
/
が3本のつもりで2本にしてしまっても間違いに気づかずに変な結果が出て萎えます。
他の版でも同様な結果だったような気がしますがたしかめていません。とりあえず手元の版ではこうなりました。 (名無しさん 2004-05-10 05:13:16 +00:00)
[42] ほとんど (すべて?) の実装では、ディレクトリ・
フォルダの最後に /
があってもなくても同義と解釈します。
[43] ハードリンク, シンボリックリンクは多分そのシステムでの普通の扱い同様追いかけてくれます (ハードリンクは本物と区別できないかもしれませんがね)。 ショートカット, エイリアス, シャドウなどについても同様の実装があるかもしれません。 (ないかもしれません。)
[46] Perl の実装である URI::file
は、
authority
で装置名その他
(DOS のドライブ名とか。) を書くのは良い考えじゃないか?
と述べています。このモジュールは意図的に file:/usr/bin/perl
みたいな書き方を使ってるみたいです。
cgi-bin
という仮想ディレクトリを設定で作れます。 file:///cgi-bin/foo.cgi を /path/to/foo.cgi に対応させられます。[51] そして注目すべきは、 w3m の local CGI 機能の都合上、
file:
URI でも照会が使われるのです。
[55] 絶対 URI だけではなくて、相対 URI もいろいろ。 RFC 1808/RFC 2396 的にはあってはならないことですが。
たとえば Windows では /
drive の根になるのか、その一つ上の階層(謎)になるのか、とか、 \
も path の区切りになるのか、とか。 c:/
みたいなのを file:///c:/
の意味にとるのもありそう。
[67] freedesktop.org - Standards/file-uri-spec http://freedesktop.org/wiki/Standards_2ffile_2duri_2dspec
UNIX環境におけるfile:
URIとファイル名の写像の仕様を作ろうとしているようですが、今のところ何もありません。
(名無しさん [sage] 2006-01-03 05:37:05 +00:00)
[68] Commons VFS - Supported File Systems http://jakarta.apache.org/commons/vfs/filesystems.html#Local%20Files
UNIXとWindowsのファイル名 (UNCを含みます。)
は、file://
を最初につけるだけでURIにしています。
(百分率符号化はします。) Windowsの場合、
\
と/
はどちらでもよいようです。
(名無しさん)
[69] Checking document() http://www.dpawson.co.uk/xsl/sect4/uriIncl.html
XSLTのdocument()
関数の実装状況
(名無しさん)
[71] The xdg April 2004 Archive by thread http://lists.freedesktop.org/archives/xdg/2004-April/thread.html#3678
>>67 についての議論です。
file:/path
形式も理解できるようにします。authority
を明示する時は
(localhost
か)
gethostbyname
で得られた値を使います。という感じのようです。
(名無しさん)
[72]
KDEは動的に生成された内容に対してfile:/cgi-bin/helpindex
のようなURIを使っています。
(名無しさん [sage])
[73] URL Schemes Supported in Lynx http://www.infobiogen.fr/doc/info/lynx_help_files/lynx_help/lynx_url_support.html#file (名無しさん [sage])
[76] IEBlog : File URIs in Windows http://blogs.msdn.com/ie/archive/2006/12/06/file-uris-in-windows.aspx (名無しさん 2006-12-06 23:31:28 +00:00)
[58] ここまで見てきたように、 file:
URI scheme
は標準不在の状況です。どうせ局所的にしか使わないのだからどうでもいいだろうという言い訳のもとに最早収拾がつかない状況に陥っています。
相互運用性なるものは期待するだけ無駄でしょう。
[16] 8-1. Windowsパス名の落とし穴 http://www.ipa.go.jp/security/awareness/vendor/programming/b08_01.html
Windows のファイル名の色々な表現について。この記事は直接
file:
の問題を扱ったものではありませんが、
余り気にせずに実装すると file:
URI
でも同じ問題を抱えることになります。
[20] 流石に WinIE6.0 でも Mozilla 1.4 でも、 file:///?/c:/windows/ とか \\?\c:\windows とかは機能しないみたい。
[60] 外部文書からの参照: 信頼できるか不明な相手から送られてきた文書中に
file:
URI が記述されていた場合、それをどう処理するかは注意が必要です。
例えば、埋込み画像として利用者の手元のファイルが指定されていると、
利用者は外部から送られてきた文書に自分の手元の画像が含まれていると思って混乱するかもしれません。
Webブラウザでディレクトリを指定すると手元のファイルの一覧表示が行われるように実装されていることを期待して、
利用者の環境が外部から丸見えであるかのように錯覚させて安全対策と称した怪しいソフトウェアを売り込む怪しい
Web サイトも実在します。
心理的な攻撃
だけではなく、実際に攻撃することも可能です。
例えば埋込み画像として PC/AT互換機+ DOS・Windows
ではフロッピー・ディスクのドライブを表す
file:///a:/fake.jpg のような指定を行うと、
(ファイルが実在するかに関わらず)
フロッピー・ディスクに探しに行くと思われるので、
突然カタカタと音が鳴り出して利用者は不安・不快に思うかもしれません。
数が多ければブラクラや DoS ともなり兼ねません。
[61] URI を指定できる公開サービス:
URI を指定して、その URI によって取出しできる資源に対して操作するような公開のサービスでは、
意図せずに file:
URI によって鯖内部のファイルを閲覧・
利用されてしまうことがないように注意が必要です。
特に URI から取出しを行うためにライブラリを使っている場合、
http:
URI だけを使うことを想定していても
file:
URI の場合の処理も実装されていることがよくあります。
[63] 外部への情報提供:
転送プロトコルやスクリプトなどを介して履歴情報などを提供する場合、
個人情報保護 (と場合によってはシステムの安全)
の観点から外部
と考えられるところには情報を送らない (取出せない)
ように配慮が必要です。
例えば、 HTTP にはリンク元の URI
を記述する Referer:
という頭欄がありますが、
file:
URI の文書から http:
URI の文書へのリンクを辿ったような場合には file:
URI を Referer
として送るべきではありません。
古い利用者エージェントはこの配慮を怠っていたものがありましたが、
最近の Webブラウザは注意しているようです。
文書内のリンク以外では栞や履歴や同時に表示している別の文書へのスクリプトからのアクセスなどで注意が必要です。
[64] file:
は安全とは限らない:
普通 file:
URI
は局所ファイルを表しますから比較的安全だと考えがちですが、
必ずしもそうとは言えません。 authority
は実は何でも書けますから近くのネットワーク上のホストかもしれませんし、
知らない遠くのファイル鯖かもしれません。
たとえ localhost
でも、局所ファイル・システム木に mount
されたネットワーク上のファイル庫である可能性はざらにあります。
file:/path/to/something
file:///Macintosh HD/書類/test.html
旧 Mac OSのファイル。
file:/Macintosh HD/Applications/
file://vms.host.edu/disk$user/my/notes/note12345.txt
VMS における DISK$USER:[MY.NOTES]NOTE123456.TXT
を表します >>96。
[115] localhost
と空文字列は等価です >>106。
file://localhost/path/to/file.txt file:///path/to/file.txt
file://usr/local/bin/
ディレクトリーを表すため /
で終わっています >>106。
file:///c:/windows/example.ini
file:////department/example.doc
共有ディレクトリー department
の example.doc
を表します >>106。
[120] Windows のドライブの表現方法は色々あります >>106。
file:///c|/tmp/test.txt file:///c:/tmp/test.txt file:///c/tmp/test.txt
file:/this/is/the/path
[62] Web で公開されている
著述工具によって作成されたとおぼしき HTML文書で、
画像の参照先やリンク先が file:
URI
で閲覧者には何も見れないことがしばしばあります
(製作者の手元では正しく表示されるので気づかないのでしょう)。
著述工具は普通作成した文書を何らかの形で公開することを想定しているはずですから、
URI が file:
であるなら保存時に警告するなど配慮するべきです。
また、著述工具や Web ブラウザは著者のために file:
URI が機能しないモードを (マークの誤り回復を行わないなどの機能と共に)
用意すると便利かもしれません。
[65] Firefox は各システム環境の標準の文字コードで百分率符号化するみたいです。 (名無しさん [sage] 2005-12-25 13:39:58 +00:00)
[66]
Firefox on Win32 でLAN上の別計算機のファイルを開くと、file://///host/path/to/file
のような、file:///
の後にUNCの\
を/
にしたようなものがURIとなるようです。
(名無しさん [sage])
[70] draft-hoffman-file-uri https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12228&rfc_flag=0
(名無しさん [sage])
[74] The 'file' URI Scheme Update Project. http://offset.skew.org/wiki/URI/File_scheme (名無しさん)
[77]
Windows Mobile ヒント集 - インターネットの参照 (2007-03-15 19:30:09 +09:00
版) http://www.microsoft.com/japan/windowsmobile/wm50/techinfo/tips/browseinternet.mspx
(名無しさん)
[79] Elements of an EmotionML 1.0 ( 版) http://www.w3.org/2005/Incubator/emotion/XGR-emotionml-20081120/#s6.1
<link role="expressedBy" uri="file:johnsParty.avi" start="10s" end="15s"/>
[80] ASR's Room NicoCache Proxy Auto Config ( 版) http://homepage1.nifty.com/asr/tools/nicocache-pac.html
IEの場合、「file://C:/path/to/xxx.pac」だとOKなのですが「file:///C:/path/to/xxx.pac」のように「///」で指定すると無視されるようなので気をつけてください。(ホームページの設定は「///」なのに…)
[81] Web Forms 2.0 ( 版) http://www.whatwg.org/specs/web-forms/current-work/#for-file
[82] localhost ( 版) http://www3.ocn.ne.jp/~miotti/ds/localhost.html
[83] XProc: An XML Pipeline Language ( 版) http://www.w3.org/TR/2010/REC-xproc-20100511/#binary
[84] IRC logs: freenode / #whatwg / 20101114 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20101114
[85] Standard for exchanging file: URIs ( 版) http://equinox-project.org/spec/file-uri-spec.txt
[86] freedesktop.org - Specifications/file-uri-spec ( ( 版)) http://freedesktop.org/wiki/Specifications/file-uri-spec
[89] IEのローカルファイルをXHRでどこまで読みとらせるか - 葉っぱ日記 ( 版) http://d.hatena.ne.jp/hasegawayosuke/20110426/p1
[122] File URI scheme - Wikipedia, the free encyclopedia ( ( 版)) http://en.wikipedia.org/wiki/File_URI_scheme
[124] Bug 66194 – file:// Correct URLs w/ UNC have *5* slashes ( ( 版)) https://bugzilla.mozilla.org/show_bug.cgi?id=66194
[130] authority にドライブの類を指定するのが良いとする人もいます。
[131] ファイル・システムによっては名前に /
や .
や ..
を認めていることがあり、パーセント符号化によりこれを表すことがあります。
[134] http://code.google.com/p/chromium/issues/detail?id=47416
[135] [whatwg] URL: file: URLs ( ( 版)) http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-October/037719.html
[136] IRC logs: freenode / #whatwg / 20121026 ( ( 版)) http://krijnhoetmer.nl/irc-logs/whatwg/20121026#l-669
[137] WWW-Talk Jan-Mar 1993: HTML todo list ( ( 版)) http://1997.webhistory.org/www.lists/www-talk.1993q1/0043.html
[138] WebKit組み込んでるアプリにおいて純粋にWebKit由来のバグであれば勝手に直ったりするけどWebKitをどういう設定で使っているかに起因する仕様上の欠陥は勝手に直らない - 金利0無利息キャッシング – キャッシングできます - subtech ( ( 版)) http://subtech.g.hatena.ne.jp/mala/20121025/1351159332
[139] Safariのfile://におけるSame origin policyについてのアップデート - 金利0無利息キャッシング – キャッシングできます - subtech ( ( 版)) http://subtech.g.hatena.ne.jp/mala/20121023/1351004574
[140] classic mozilla/cmd/winfe/fegui.cpp ( ( 版)) https://mxr.mozilla.org/classic/source/cmd/winfe/fegui.cpp#2531
[141] Issue 257354 - chromium - file URL parsing quirks - An open-source project to help move the web forward. - Google Project Hosting ( ( 版)) http://code.google.com/p/chromium/issues/detail?id=257354
[142] reviving the file URI scheme ( (Matthew Kerwin 著, 版)) http://lists.w3.org/Archives/Public/uri/2013Dec/0000.html
[143] URI/File scheme - Offset ( ( 版)) https://offset.skew.org/wiki/URI/File_scheme
[144] Orbeon Forms — Forms Everywhere: More secure file uploads ( ( 版)) http://blog.orbeon.com/2012/06/more-secure-file-uploads.html
[145] 新・OS X ハッキング! (84) 話題の「File:///」とURLスキーム | マイナビニュース ( (Mynavi Corporation 著, 版)) http://news.mynavi.jp/column/osxhack/084/
[146] ncsa-mosaic/CHANGES at master · alandipert/ncsa-mosaic ( ( 版)) https://github.com/alandipert/ncsa-mosaic/blob/master/CHANGES#L860
[147] draft-kerwin-file-scheme-13 - The file URI Scheme ( ( 版)) http://tools.ietf.org/html/draft-kerwin-file-scheme-13
[148] Re: URL Spec WorkMode (was: PSA: Sam Ruby is co-Editor of URL spec) ( (Jonas Sicking 著, 版)) http://lists.w3.org/Archives/Public/public-webapps/2014OctDec/0522.html
[21] WWW-Talk Jan-Mar 1994: file://localhost => local: ? ( 版) http://1997.webhistory.org/www.lists/www-talk.1994q1/0983.html
[22] Same-origin policy for file: URIs | MDN ( ( 版)) https://developer.mozilla.org/en-US/docs/Same-origin_policy_for_file:_URIs
[23] Enable paths starting with / to resolve within a volume on Windows · jsdom/whatwg-url@c13670d ( 版) https://github.com/jsdom/whatwg-url/commit/c13670dffdef1f31cb53d9c342076a27a5742760
[24] IRC logs: freenode / #whatwg / 20150430 ( 版) http://krijnhoetmer.nl/irc-logs/whatwg/20150430#l-348
[31] The File Content Provider (Kai Sommerfeld 著, 版) https://www.openoffice.org/ucb/docs/ucp-ref/file-ucp.html
[33] File URIs in Windows - IEBlog - Site Home - MSDN Blogs ( 版) http://blogs.msdn.com/b/ie/archive/2006/12/06/file-uris-in-windows.aspx
[35] Attempt to address various file URL issues. · whatwg/url@09cd673 ( 版) https://github.com/whatwg/url/commit/09cd673a338e7abc552140d950c4f34d7d71362a
[36] 27518 – remove any and all normative definition of file:// handling ( 版) https://www.w3.org/Bugs/Public/show_bug.cgi?id=27518
[37] Make file:/// and file://LOCALHOST/ parse identically. Fixes https://… · whatwg/url@bb36bd9 ( 版) https://github.com/whatwg/url/commit/bb36bd9f035be2e3904ddc8e4e8fd1e756ae8f1e
[38] 27517 – file: consider not supporting vertical bar Windows drive letter quirk for relative URLs ( 版) https://www.w3.org/Bugs/Public/show_bug.cgi?id=27517
[39] Define syntax for file URLs. Third part towards fixing #33. · whatwg/url@0755b48 ( 版) https://github.com/whatwg/url/commit/0755b4855187c94e1dfca900ba5122fa02a359ec
[40] The File: URL Scheme ( 版) https://technet.microsoft.com/ja-jp/sysinternals/aa123685
[161] Issue 406076 - chromium - window.location.origin is for file:// URLs; it should match ancestorOrigin's serialization and be 'null' - Monorail]] ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=406076
[165] URL.pathname getter for file URLs produces odd result on Windows · Issue #103 · whatwg/url ( ()) https://github.com/whatwg/url/issues/103
[167] 257354 - file URL parsing quirks - chromium - Monorail () https://bugs.chromium.org/p/chromium/issues/detail?id=257354
[170] File state did not correctly deal with lack of base URL (annevk著, ) https://github.com/whatwg/url/commit/698f3e8f1d7de6d84c78ac81209fd780aca5ab7e
[171] A file URL cannot have credentials (annevk著, ) https://github.com/whatwg/url/commit/9b2eb10eb8436adaf6620b1864b25442152f205b
[172] RFC 8089 - The "file" URI Scheme () https://tools.ietf.org/html/rfc8089
[179] Add empty host concept for file and non-special URLs (rmisev著, ) https://github.com/whatwg/url/commit/5807b28261e44a47e31683230137da395ddc79d8
[180] Restrict protocol around "file" (annevk著, ) https://github.com/whatwg/url/commit/462fdc14732aae4b0b9c5334f37962d8c235caf9
[181] URL: trim leading slashes of file URL paths (annevk著, ) https://github.com/whatwg/url/commit/6103e0a58eb2460d409056fb2b93b015941b64f2
[182] Re: [whatwg] Accessing local files with JavaScript portably and securely (Ian Hickson著, ) https://lists.w3.org/Archives/Public/public-whatwg-archive/2017Apr/0079.html
[183] Fix Windows drive letter handling in the file state (rmisev著, ) https://github.com/whatwg/url/commit/fe6b251739e225555f04319f19c70c031a5d99eb
[186] 122022 - (file://) [ISSUE] file:// URLs in a http | https page do not work (clicking does nothing, do not auto-load, etc.) [dupe to bug 84128] ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=122022
[187] 571846 - server name stripped from "file://" URI ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=571846
[188] 88293 - file:// URLs w/ UNCs do not work ( ()) https://bugzilla.mozilla.org/show_bug.cgi?id=88293
[189] 346744 - Security: download attribute allows download without user interaction - chromium - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=346744
[190] 455882 - Treat file:// URLs as having unique origin - chromium - Monorail ( ()) https://bugs.chromium.org/p/chromium/issues/detail?id=455882
[191] Understanding Web Proxy Configuration – IEInternals () https://blogs.msdn.microsoft.com/ieinternals/2013/10/11/understanding-web-proxy-configuration/
[192] The Bizarre and Unhappy Story of ‘file:’ URLs – Free Associations () https://blogs.msdn.microsoft.com/freeassociations/2005/05/19/the-bizarre-and-unhappy-story-of-file-urls/
[193] Fix Windows drive letter handling in the file slash state (rmisev著, ) https://github.com/whatwg/url/commit/2eef975e989cb5ae2d62467394778fd6778ddec9
[194] Drive letters get duplicated when resolving Windows file: URL with base · Issue #303 · whatwg/url () https://github.com/whatwg/url/issues/303
[195] remaining variable ambiguity · Issue #308 · whatwg/url () https://github.com/whatwg/url/issues/308
[196] Fix Windows drive letter handling in the file slash state by rmisev · Pull Request #343 · whatwg/url () https://github.com/whatwg/url/pull/343
[197] 760096 - Windows Chrome gets stuck on Local pages' Resource loading - chromium - Monorail () https://bugs.chromium.org/p/chromium/issues/detail?id=760096
[198] 756416 - cannot access cross access files in framesets when files saved in html format - chromium - Monorail () https://bugs.chromium.org/p/chromium/issues/detail?id=756416
[199] Define behavior for `file://` documents' origin. · Issue #3099 · whatwg/html () https://github.com/whatwg/html/issues/3099
[206] Node ecosystem might need to preserve using `file:` protocol · Issue #176 · WICG/webpackage () https://github.com/WICG/webpackage/issues/176
[207] new URL('file://').origin is 'null' · Issue #310 · whatwg/url () https://github.com/whatwg/url/issues/310
[208] Make it possible to run tests from file:/// · Issue #10185 · w3c/web-platform-tests () https://github.com/w3c/web-platform-tests/issues/10185
[209] No longer render resources requested via FTP (mikewest著, ) https://github.com/whatwg/fetch/commit/c6b3a750f811cb4f628def0313ac317d9dcec88a
[210] 1566172 - (file-fallout) Compare file:// behavior of all places that use same-origin-only or cors-only loads to other browsers () https://bugzilla.mozilla.org/show_bug.cgi?id=1566172
[211] 1565942 - Make woff and woff2 files exceptions to file_unique_origin (@font-face over file://) () https://bugzilla.mozilla.org/show_bug.cgi?id=1565942
[212] Warning: curl users on Windows using FILE:// | daniel.haxx.se () https://daniel.haxx.se/blog/2020/03/16/warning-curl-users-on-windows-using-file/
[213] 1月20日73.6kgさんはTwitterを使っています 「教科書の引用文献のURIに file://c:\… が登場しててワロタ https://t.co/45XefLKV6T」 / Twitter (午後9:28 · 2020年12月25日 , ) https://twitter.com/haruo31/status/1342447092170588161
[214] ファイルから AWS CLI パラメータをロードする - AWS Command Line Interface, , https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-usage-parameters-file.html#cli-usage-parameters-file-how
値を含むファイルを指定するには、次の形式でファイル URL を指定します。
file://complete/path/to/file
- 最初の 2 つのスラッシュ「/」文字は仕様の一部です。必要なパスが「/」で始まる場合、結果は 3 つのスラッシュ文字
file:///folder/file
になります。- この URI は、実際のパラメータコンテンツが含まれているファイルへのパスを示します。
- スペースまたは特殊文字を含むファイルを使用する場合は、お使いの端末の
引用符とエスケープのルール リンク に従ってください。
file://
プレフィックスオプションは、「~/
」、「./
」、および「../
」など、Unix 形式の拡張子をサポートしています。Windows では、「~/
」式は、%USERPROFILE%
環境変数に格納されているユーザーディレクトリに展開されます。例えば、Windows 10 では、一般にユーザーディレクトリはC:\Users\UserName\
にあります。
[217] OS X Mountain Lion のほぼ全てのアプリケーションをクラッシュさせる 8 文字 | スラド アップル, https://apple.srad.jp/story/13/02/05/0128241/
[218] 122022 - (file://) [ISSUE] file:// URLs in a http | https page do not work (clicking does nothing, do not auto-load, etc.) [dupe to bug 84128], https://bugzilla.mozilla.org/show_bug.cgi?id=122022