uriのスキームが「ファイル」であると仮定します。また、パスが「。」で始まると仮定します。
パスの例は「./.bashrc」です。フルーリはどのように見えますか?'file://./。bashrc'は私には奇妙に見えます。
uriのスキームが「ファイル」であると仮定します。また、パスが「。」で始まると仮定します。
パスの例は「./.bashrc」です。フルーリはどのように見えますか?'file://./。bashrc'は私には奇妙に見えます。
つまり、ファイルのURLは次の形式になります。
file://localhost/absolute/path/to/file [ok]
または、ホストを省略できます(スラッシュは省略できます)。
file:///absolute/path/to/file [ok]
しかし、これではありません:
file://file_at_current_dir [no way]
これも:
file://./file_at_current_dir [no way]
Pythonのurllib2.urlopen()を介して確認しました
http://en.wikipedia.org/wiki/File_URI_schemeからの詳細:
"file:///foo.txt" is okay, while "file://foo.txt" is not,
although some interpreters manage to handle the latter
完全なファイルを使用することはできません:「。」を含むURI または、パスのルート部分のないパス内の「..」セグメント。'file://./。bashrc'または'file:///./。bashrc'のどちらを使用しても、これらのパスには意味がありません。相対リンクを使用する場合は、プロトコル/権限部分なしで使用します。
<a href="./.bashrc">link</a>
完全なURIを使用する場合は、相対パスが相対パスであるルートを指定する必要があります。
<a href="file:///home/kindrik/./.bashrc">link</a>
RFC3986による
The path segments "." and "..", also known as dot-segments, are
defined for relative reference within the path name hierarchy. They
are intended for use at the beginning of a relative-path reference
(Section 4.2) to indicate relative position within the hierarchical
tree of names. This is similar to their role within some operating
systems' file directory structures to indicate the current directory
and parent directory, respectively. However, unlike in a file
system, these dot-segments are only interpreted within the URI path
hierarchy and are removed as part of the resolution process (Section
5.2).
The complete path segments "." and ".." are intended only for use
within relative references (Section 4.1) and are removed as part of
the reference resolution process (Section 5.2). However, some
deployed implementations incorrectly assume that reference resolution
is not necessary when the reference is already a URI and thus fail to
remove dot-segments when they occur in non-relative paths. URI
normalizers should remove dot-segments by applying the
remove_dot_segments algorithm to the path, as described in Section 5.2.4.
The complete path segments "." and ".." are intended only for use
within relative references (Section 4.1) and are removed as part of
the reference resolution process (Section 5.2)
RFC 3986は、これらの「。」を削除するアルゴリズムについても説明しています。およびURIからの「..」。
ターミナルでは、「$ PWD」を使用して「file://$ PWD / .bashrc」と入力し、現在のディレクトリを参照できます。
あなたのユースケースはわかりません。
ノードコードにも同様のニーズがあるため、作業ディレクトリに相対的なファイルURLが必要な場合は、次のようなURLを作成します...
const url = "file://" + process.cwd() + "/" + ".bashrc";
UNIXシェルスクリプトでは、これを使用することができました。
file://`pwd`/relative-path
あなたの特定の場合:
file://`pwd`/.bashrc
URIは常に絶対です(スキーマのない別の獣である相対URIでない限り)。これは、サーバーの作業ディレクトリを参照しても意味がないサーバークライアントテクノロジであるためです。繰り返しになりますが、ファイルシステムを参照することは、サーバークライアントコンテキストでも意味がありません。それにもかかわらず、RFC8089は絶対パスのみを許可します。
パスコンポーネントは、ファイルシステム内のファイルへの絶対パスを表します。
ただし、非標準の拡張機能を想定する場合は、次の構文を選択します。
file:file.txt
file:./file.txt
説明は、RFC 8089が非ローカルパスfile://<FQDN of host>/path
とローカルパスfile:/path
、、、file://localhost/path
およびを指定していることfile:///path
です。ほぼ確実にローカル相対パスを指定しようとしているため(つまり、「ローカルファイルシステムAPI」からアクセス可能)、a.
はFQDNでもホスト名でもないため、単純なfile:
スキーム+スキーム固有の部分のURI構文は次のようになります。最も意味があります。