86

uriのスキームが「ファイル」であると仮定します。また、パスが「。」で始まると仮定します。

パスの例は「./.bashrc」です。フルーリはどのように見えますか?'file://./。bashrc'は私には奇妙に見えます。

4

7 に答える 7

86

つまり、ファイルの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
于 2013-03-04T02:40:30.727 に答える
25

完全なファイルを使用することはできません:「。」を含む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からの「..」。

于 2013-10-06T00:49:24.497 に答える
20

ターミナルでは、「$ PWD」を使用して「file://$ PWD / .bashrc」と入力し、現在のディレクトリを参照できます。

于 2014-12-14T17:07:29.233 に答える
19

の後にダブルスラッシュを付けないでくださいfile:。正しい形式は

'file:.bashrc'

RFC 3986path-rootless定義を参照してください

于 2018-10-31T12:06:15.987 に答える
6

あなたのユースケースはわかりません。

ノードコードにも同様のニーズがあるため、作業ディレクトリに相対的なファイルURLが必要な場合は、次のようなURLを作成します...

const url = "file://" + process.cwd() + "/" + ".bashrc";
于 2018-04-18T12:59:51.567 に答える
1

UNIXシェルスクリプトでは、これを使用することができました。

file://`pwd`/relative-path

あなたの特定の場合:

file://`pwd`/.bashrc
于 2018-11-03T16:20:59.673 に答える
0

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構文は次のようになります。最も意味があります。

于 2021-11-19T08:34:53.807 に答える