{
    "mode": "perldoc",
    "parameter": "URI::file",
    "section": "",
    "url": "https://www.chedong.com/phpMan.php/perldoc/URI%3A%3Afile/json",
    "generated": "2026-06-09T16:31:38Z",
    "synopsis": "use URI::file;\n$u1 = URI->new(\"file:/foo/bar\");\n$u2 = URI->new(\"foo/bar\", \"file\");\n$u3 = URI::file->new($path);\n$u4 = URI::file->new(\"c:\\\\windows\\\\\", \"win32\");\n$u1->file;\n$u1->file(\"mac\");",
    "sections": {
        "NAME": {
            "content": "URI::file - URI that maps to local file names\n",
            "subsections": []
        },
        "SYNOPSIS": {
            "content": "use URI::file;\n\n$u1 = URI->new(\"file:/foo/bar\");\n$u2 = URI->new(\"foo/bar\", \"file\");\n\n$u3 = URI::file->new($path);\n$u4 = URI::file->new(\"c:\\\\windows\\\\\", \"win32\");\n\n$u1->file;\n$u1->file(\"mac\");\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "The \"URI::file\" class supports \"URI\" objects belonging to the *file* URI scheme. This scheme\nallows us to map the conventional file names found on various computer systems to the URI name\nspace. An old specification of the *file* URI scheme is found in RFC 1738. Some older background\ninformation is also in RFC 1630. There are no newer specifications as far as I know.\n\nIf you simply want to construct *file* URI objects from URI strings, use the normal \"URI\"\nconstructor. If you want to construct *file* URI objects from the actual file names used by\nvarious systems, then use one of the following \"URI::file\" constructors:\n\n$u = URI::file->new( $filename, [$os] )\nMaps a file name to the *file:* URI name space, creates a URI object and returns it. The\n$filename is interpreted as belonging to the indicated operating system ($os), which\ndefaults to the value of the $^O variable. The $filename can be either absolute or relative,\nand the corresponding type of URI object for $os is returned.\n\n$u = URI::file->newabs( $filename, [$os] )\nSame as URI::file->new, but makes sure that the URI returned represents an absolute file\nname. If the $filename argument is relative, then the name is resolved relative to the\ncurrent directory, i.e. this constructor is really the same as:\n\nURI::file->new($filename)->abs(URI::file->cwd);\n\n$u = URI::file->cwd\nReturns a *file* URI that represents the current working directory. See Cwd.\n\nThe following methods are supported for *file* URI (in addition to the common and generic\nmethods described in URI):\n\n$u->file( [$os] )\nReturns a file name. It maps from the URI name space to the file name space of the indicated\noperating system.\n\nIt might return \"undef\" if the name can not be represented in the indicated file system.\n\n$u->dir( [$os] )\nSome systems use a different form for names of directories than for plain files. Use this\nmethod if you know you want to use the name for a directory.\n\nThe \"URI::file\" module can be used to map generic file names to names suitable for the current\nsystem. As such, it can work as a nice replacement for the \"File::Spec\" module. For instance,\nthe following code translates the UNIX-style file name Foo/Bar.pm to a name suitable for the\nlocal system:\n\n$file = URI::file->new(\"Foo/Bar.pm\", \"unix\")->file;\ndie \"Can't map filename Foo/Bar.pm for $^O\" unless defined $file;\nopen(FILE, $file) || die \"Can't open '$file': $!\";\n# do something with FILE\n",
            "subsections": []
        },
        "MAPPING NOTES": {
            "content": "Most computer systems today have hierarchically organized file systems. Mapping the names used\nin these systems to the generic URI syntax allows us to work with relative file URIs that behave\nas they should when resolved using the generic algorithm for URIs (specified in RFC 2396).\nMapping a file name to the generic URI syntax involves mapping the path separator character to\n\"/\" and encoding any reserved characters that appear in the path segments of the file name. If\npath segments consisting of the strings \".\" or \"..\" have a different meaning than what is\nspecified for generic URIs, then these must be encoded as well.\n\nIf the file system has device, volume or drive specifications as the root of the name space,\nthen it makes sense to map them to the authority field of the generic URI syntax. This makes\nsure that relative URIs can not be resolved \"above\" them, i.e. generally how relative file names\nwork in those systems.\n\nAnother common use of the authority field is to encode the host on which this file name is\nvalid. The host name \"localhost\" is special and generally has the same meaning as a missing or\nempty authority field. This use is in conflict with using it as a device specification, but can\noften be resolved for device specifications having characters not legal in plain host names.\n\nFile name to URI mapping in normally not one-to-one. There are usually many URIs that map to any\ngiven file name. For instance, an authority of \"localhost\" maps the same as a URI with a missing\nor empty authority.\n\nExample 1: The Mac classic (Mac OS 9 and earlier) used \":\" as path separator, but not in the\nsame way as a generic URI. \":foo\" was a relative name. \"foo:bar\" was an absolute name. Also,\npath segments could contain the \"/\" character as well as the literal \".\" or \"..\". So the mapping\nlooks like this:\n\nMac classic           URI\n----------            -------------------\n:foo:bar     <==>     foo/bar\n:            <==>     ./\n::foo:bar    <==>     ../foo/bar\n:::          <==>     ../../\nfoo:bar      <==>     file:/foo/bar\nfoo:bar:     <==>     file:/foo/bar/\n..           <==>     %2E%2E\n<undef>      <==      /\nfoo/         <==      file:/foo%2F\n./foo.txt    <==      file:/.%2Ffoo.txt\n\nNote that if you want a relative URL, you *must* begin the path with a :. Any path that begins\nwith [^:] is treated as absolute.\n\nExample 2: The UNIX file system is easy to map, as it uses the same path separator as URIs, has\na single root, and segments of \".\" and \"..\" have the same meaning. URIs that have the character\n\"\\0\" or \"/\" as part of any path segment can not be turned into valid UNIX file names.\n\nUNIX                  URI\n----------            ------------------\nfoo/bar      <==>     foo/bar\n/foo/bar     <==>     file:/foo/bar\n/foo/bar     <==      file://localhost/foo/bar\nfile:         ==>     ./file:\n<undef>      <==      file:/fo%00/bar\n/            <==>     file:/\n",
            "subsections": []
        },
        "CONFIGURATION VARIABLES": {
            "content": "The following configuration variables influence how the class and its methods behave:\n\n%URI::file::OSCLASS\nThis hash maps OS identifiers to implementation classes. You might want to add or modify\nthis if you want to plug in your own file handler class. Normally the keys should match the\n$^O values in use.\n\nIf there is no mapping then the \"Unix\" implementation is used.\n\n$URI::file::DEFAULTAUTHORITY\nThis determine what \"authority\" string to include in absolute file URIs. It defaults to \"\".\nIf you prefer verbose URIs you might set it to be \"localhost\".\n\nSetting this value to \"undef\" force behaviour compatible to URI v1.31 and earlier. In this\nmode host names in UNC paths and drive letters are mapped to the authority component on\nWindows, while we produce authority-less URIs on Unix.\n",
            "subsections": []
        },
        "SEE ALSO": {
            "content": "URI, File::Spec, perlport\n",
            "subsections": []
        },
        "COPYRIGHT": {
            "content": "Copyright 1995-1998,2004 Gisle Aas.\n\nThis library is free software; you can redistribute it and/or modify it under the same terms as\nPerl itself.\n",
            "subsections": []
        }
    },
    "summary": "URI::file - URI that maps to local file names",
    "flags": [],
    "examples": [],
    "see_also": []
}