use URI::file; $u1 = URI->new("file:/foo/bar"); $u2 = URI->new("foo/bar", "file"); $u3 = URI::file->new($path); $u4 = URI::file->new("c:\\windows\\", "win32"); $u1->file; $u1->file("mac");
If you simply want to construct file URI objects from URI strings, use the normal "URI" constructor. If you want to construct file URI objects from the actual file names used by various systems, then use one of the following "URI::file" constructors:
The following methods are supported for file URI (in addition to the common and generic methods described in URI):
It might return "undef" if the name can not be represented in the indicated file system.
The "URI::file" module can be used to map generic file names to names suitable for the current system. As such, it can work as a nice replacement for the "File::Spec" module. For instance, the following code translates the UNIX-style file name Foo/Bar.pm to a name suitable for the local system:
$file = URI::file->new("Foo/Bar.pm", "unix")->file; die "Can't map filename Foo/Bar.pm for $^O" unless defined $file; open(FILE, $file) || die "Can't open '$file': $!"; # do something with FILE
If the file system has device, volume or drive specifications as the root of the name space, then it makes sense to map them to the authority field of the generic URI syntax. This makes sure that relative URIs can not be resolved ``above'' them, i.e. generally how relative file names work in those systems.
Another common use of the authority field is to encode the host on which this file name is valid. The host name ``localhost'' is special and generally has the same meaning as a missing or empty authority field. This use is in conflict with using it as a device specification, but can often be resolved for device specifications having characters not legal in plain host names.
File name to URI mapping in normally not one-to-one. There are usually many URIs that map to any given file name. For instance, an authority of ``localhost'' maps the same as a URI with a missing or empty authority.
Example 1: The Mac classic (Mac OS 9 and earlier) used ``:'' as path separator, but not in the same way as a generic URI. ``:foo'' was a relative name. ``foo:bar'' was an absolute name. Also, path segments could contain the ``/'' character as well as the literal ``.'' or ``..''. So the mapping looks like this:
Mac classic URI ---------- ------------------- :foo:bar <==> foo/bar : <==> ./ ::foo:bar <==> ../foo/bar ::: <==> ../../ foo:bar <==> file:/foo/bar foo:bar: <==> file:/foo/bar/ .. <==> %2E%2E <undef> <== / foo/ <== file:/foo%2F ./foo.txt <== file:/.%2Ffoo.txt
Note that if you want a relative URL, you *must* begin the path with a :. Any path that begins with [^:] is treated as absolute.
Example 2: The UNIX file system is easy to map, as it uses the same path separator as URIs, has a single root, and segments of ``.'' and ``..'' have the same meaning. URIs that have the character ``\0'' or ``/'' as part of any path segment can not be turned into valid UNIX file names.
UNIX URI ---------- ------------------ foo/bar <==> foo/bar /foo/bar <==> file:/foo/bar /foo/bar <== file://localhost/foo/bar file: ==> ./file: <undef> <== file:/fo%00/bar / <==> file:/
If there is no mapping then the ``Unix'' implementation is used.
Setting this value to "undef" force behaviour compatible to URI v1.31 and earlier. In this mode host names in UNC paths and drive letters are mapped to the authority component on Windows, while we produce authority-less URIs on Unix.
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.