2026-06-13 12:27 @216.73.216.28
CrawledBy Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
URI(7) Linux Programmer's Manual URI(7) NAME uri, url, urn - uniform resource identifier (URI), including a URL or URN SYNOPSIS URI = [ absoluteURI | relativeURI ] [ "#" fragment ] absoluteURI = scheme ":" ( hierarchical_part | opaque_part ) relativeURI = ( net_path | absolute_path | relative_path ) [ "?" query ] scheme = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" | "file" | "man" | "info" | "whatis" | "ldap" | "wais" | ... hierarchical_part = ( net_path | absolute_path ) [ "?" query ] net_path = "//" authority [ absolute_path ] absolute_path = "/" path_segments relative_path = relative_segment [ absolute_path ] DESCRIPTION A Uniform Resource Identifier (URI) is a short string of characters identifying an abstract or physical resource (for example, a web page). A Uniform Resource Locator (URL) is a URI that identifies a resource through its primary access mechanism (e.g., its network "location"), rather than by name or some other attribute of that resource. A Uni- form Resource Name (URN) is a URI that must remain globally unique and persistent even when the resource ceases to exist or becomes unavail- able. URIs are the standard way to name hypertext link destinations for tools such as web browsers. The string "http://www.kernel.org" is a URL (and thus it is also a URI). Many people use the term URL loosely as a syn- onym for URI (though technically URLs are a subset of URIs). URIs can be absolute or relative. An absolute identifier refers to a resource independent of context, while a relative identifier refers to a resource by describing the difference from the current context. Within a relative path reference, the complete path segments "." and ".." have special meanings: "the current hierarchy level" and "the level above this hierarchy level", respectively, just like they do in UNIX-like systems. A path segment which contains a colon character can't be used as the first segment of a relative URI path (e.g., "this:that"), because it would be mistaken for a scheme name; precede such segments with ./ (e.g., "./this:that"). Note that descendants of MS-DOS (e.g., Microsoft Windows) replace devicename colons with the vertical bar ("|") in URIs, so "C:" becomes "C|". A fragment identifier, if included, refers to a particular named por- tion (fragment) of a resource; text after a '#' identifies the frag- ment. A URI beginning with '#' refers to that fragment in the current resource. Usage There are many different URI schemes, each with specific additional rules and meanings, but they are intentionally made to be as similar as possible. For example, many URL schemes permit the authority to be the following format, called here an ip_server (square brackets show what's optional): ip_server = [user [ : password ] @ ] host [ : port] This format allows you to optionally insert a username, a user plus password, and/or a port number. The host is the name of the host com- puter, either its name as determined by DNS or an IP address (numbers separated by periods). Thus the URI <http://fred:fredpassword@exam- ple.com:8080/> logs into a web server on host example.com as fred (us- ing fredpassword) using port 8080. Avoid including a password in a URI if possible because of the many security risks of having a password written down. If the URL supplies a username but no password, and the remote server requests a password, the program interpreting the URL should request one from the user. Here are some of the most common schemes in use on UNIX-like systems that are understood by many tools. Note that many tools using URIs also have internal schemes or specialized schemes; see those tools' documentation for information on those schemes. http - Web (HTTP) server http://ip_server/path http://ip_server/path?query This is a URL accessing a web (HTTP) server. The default port is 80. If the path refers to a directory, the web server will choose what to return; usually if there is a file named "index.html" or "index.htm" its content is returned, otherwise, a list of the files in the current directory (with appropriate links) is generated and returned. An exam- ple is <http://lwn.net>. A query can be given in the archaic "isindex" format, consisting of a word or phrase and not including an equal sign (=). A query can also be in the longer "GET" format, which has one or more query entries of the form key=value separated by the ampersand character (&). Note that key can be repeated more than once, though it's up to the web server and its application programs to determine if there's any meaning to that. There is an unfortunate interaction with HTML/XML/SGML and the GET query format; when such URIs with more than one key are embedded in SGML/XML documents (including HTML), the ampersand (&) has to be rewritten as &. Note that not all queries use this format; larger forms may be too long to store as a URI, so they use a different inter- action mechanism (called POST) which does not include the data in the URI. See the Common Gateway Interface specification at <http://www.w3.org/CGI> for more information. ftp - File Transfer Protocol (FTP) ftp://ip_server/path This is a URL accessing a file through the file transfer protocol (FTP). The default port (for control) is 21. If no username is in- cluded, the username "anonymous" is supplied, and in that case many clients provide as the password the requestor's Internet email address. An example is <ftp://ftp.is.co.za/rfc/rfc1808.txt>. gopher - Gopher server gopher://ip_server/gophertype selector gopher://ip_server/gophertype selector%09search gopher://ip_server/gophertype selector%09search%09gopher+_string The default gopher port is 70. gophertype is a single-character field to denote the Gopher type of the resource to which the URL refers. The entire path may also be empty, in which case the delimiting "/" is also optional and the gophertype defaults to "1". selector is the Gopher selector string. In the Gopher protocol, Gopher selector strings are a sequence of octets which may contain any octets except 09 hexadecimal (US-ASCII HT or tab), 0A hexadecimal (US-ASCII character LF), and 0D (US-ASCII character CR). mailto - Email address mailto:email-address This is an email address, usually of the form name@hostname. See mailaddr(7) for more information on the correct format of an email ad- dress. Note that any % character must be rewritten as %25. An example is <mailto:dwheeler AT dwheeler.com>. news - Newsgroup or News message news:newsgroup-name news:message-id A newsgroup-name is a period-delimited hierarchical name, such as "comp.infosystems.www.misc". If <newsgroup-name> is "*" (as in <news:*>), it is used to refer to "all available news groups". An ex- ample is <news:comp.lang.ada>. A message-id corresponds to the Message-ID of IETF RFC 1036, <http://www.ietf.org/rfc/rfc1036.txt> without the enclosing "<" and ">"; it takes the form unique@full_domain_name. A message identifier may be distinguished from a news group name by the presence of the "@" character. telnet - Telnet login telnet://ip_server/ The Telnet URL scheme is used to designate interactive text services that may be accessed by the Telnet protocol. The final "/" character may be omitted. The default port is 23. An example is <tel- net://melvyl.ucop.edu/>. file - Normal file file://ip_server/path_segments file:path_segments This represents a file or directory accessible locally. As a special case, ip_server can be the string "localhost" or the empty string; this is interpreted as "the machine from which the URL is being inter- preted". If the path is to a directory, the viewer should display the directory's contents with links to each containee; not all viewers cur- rently do this. KDE supports generated files through the URL <file:/cgi-bin>. If the given file isn't found, browser writers may want to try to expand the filename via filename globbing (see glob(7) and glob(3)). The second format (e.g., <file:/etc/passwd>) is a correct format for referring to a local file. However, older standards did not permit this format, and some programs don't recognize this as a URI. A more portable syntax is to use an empty string as the server name, for exam- ple, <file:///etc/passwd>; this form does the same thing and is easily recognized by pattern matchers and older programs as a URI. Note that if you really mean to say "start from the current location," don't specify the scheme at all; use a relative address like <../test.txt>, which has the side-effect of being scheme-independent. An example of this scheme is <file:///etc/passwd>. man - Man page documentation man:command-name man:command-name(section) This refers to local online manual (man) reference pages. The command name can optionally be followed by a parenthesis and section number; see man(7) for more information on the meaning of the section numbers. This URI scheme is unique to UNIX-like systems (such as Linux) and is not currently registered by the IETF. An example is <man:ls(1)>. info - Info page documentation info:virtual-filename info:virtual-filename#nodename info:(virtual-filename) info:(virtual-filename)nodename This scheme refers to online info reference pages (generated from tex- info files), a documentation format used by programs such as the GNU tools. This URI scheme is unique to UNIX-like systems (such as Linux) and is not currently registered by the IETF. As of this writing, GNOME and KDE differ in their URI syntax and do not accept the other's syn- tax. The first two formats are the GNOME format; in nodenames all spa- ces are written as underscores. The second two formats are the KDE format; spaces in nodenames must be written as spaces, even though this is forbidden by the URI standards. It's hoped that in the future most tools will understand all of these formats and will always accept un- derscores for spaces in nodenames. In both GNOME and KDE, if the form without the nodename is used the nodename is assumed to be "Top". Ex- amples of the GNOME format are <info:gcc> and <info:gcc#G++_and_GCC>. Examples of the KDE format are <info:(gcc)> and <info:(gcc)G++ and GCC>. whatis - Documentation search whatis:string This scheme searches the database of short (one-line) descriptions of commands and returns a list of descriptions containing that string. Only complete word matches are returned. See whatis(1). This URI scheme is unique to UNIX-like systems (such as Linux) and is not cur- rently registered by the IETF. ghelp - GNOME help documentation ghelp:name-of-application This loads GNOME help for the given application. Note that not much documentation currently exists in this format. ldap - Lightweight Directory Access Protocol ldap://hostport ldap://hostport/ ldap://hostport/dn ldap://hostport/dn?attributes ldap://hostport/dn?attributes?scope ldap://hostport/dn?attributes?scope?filter ldap://hostport/dn?attributes?scope?filter?extensions This scheme supports queries to the Lightweight Directory Access Proto- col (LDAP), a protocol for querying a set of servers for hierarchically organized information (such as people and computing resources). See RFC 2255 <http://www.ietf.org/rfc/rfc2255.txt> for more information on the LDAP URL scheme. The components of this URL are: hostport the LDAP server to query, written as a hostname optionally followed by a colon and the port number. The default LDAP port is TCP port 389. If empty, the client determines which the LDAP server to use. dn the LDAP Distinguished Name, which identifies the base ob- ject of the LDAP search (see RFC 2253 <http://www.ietf.org /rfc/rfc2253.txt> section 3). attributes a comma-separated list of attributes to be returned; see RFC 2251 section 4.1.5. If omitted, all attributes should be returned. scope specifies the scope of the search, which can be one of "base" (for a base object search), "one" (for a one-level search), or "sub" (for a subtree search). If scope is omitted, "base" is assumed. filter specifies the search filter (subset of entries to return). If omitted, all entries should be returned. See RFC 2254 <http://www.ietf.org/rfc/rfc2254.txt> section 4. extensions a comma-separated list of type=value pairs, where the =value portion may be omitted for options not requiring it. An extension prefixed with a '!' is critical (must be sup- ported to be valid), otherwise it is noncritical (op- tional). LDAP queries are easiest to explain by example. Here's a query that asks ldap.itd.umich.edu for information about the University of Michi- gan in the U.S.: ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US To just get its postal address attribute, request: ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress To ask a host.com at port 6666 for information about the person with common name (cn) "Babs Jensen" at University of Michigan, request: ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen) wais - Wide Area Information Servers wais://hostport/database wais://hostport/database?search wais://hostport/database/wtype/wpath This scheme designates a WAIS database, search, or document (see IETF RFC 1625 <http://www.ietf.org/rfc/rfc1625.txt> for more information on WAIS). Hostport is the hostname, optionally followed by a colon and port number (the default port number is 210). The first form designates a WAIS database for searching. The second form designates a particular search of the WAIS database database. The third form designates a particular document within a WAIS database to be retrieved. wtype is the WAIS designation of the type of the object and wpath is the WAIS document-id. other schemes There are many other URI schemes. Most tools that accept URIs support a set of internal URIs (e.g., Mozilla has the about: scheme for inter- nal information, and the GNOME help browser has the toc: scheme for various starting locations). There are many schemes that have been de- fined but are not as widely used at the current time (e.g., prospero). The nntp: scheme is deprecated in favor of the news: scheme. URNs are to be supported by the urn: scheme, with a hierarchical name space (e.g., urn:ietf:... would identify IETF documents); at this time URNs are not widely implemented. Not all tools support all schemes. Character encoding URIs use a limited number of characters so that they can be typed in and used in a variety of situations. The following characters are reserved, that is, they may appear in a URI but their use is limited to their reserved purpose (conflicting data must be escaped before forming the URI): ; / ? : @ & = + $ , Unreserved characters may be included in a URI. Unreserved characters include uppercase and lowercase English letters, decimal digits, and the following limited set of punctuation marks and symbols: - _ . ! ~ * ' ( ) All other characters must be escaped. An escaped octet is encoded as a character triplet, consisting of the percent character "%" followed by the two hexadecimal digits representing the octet code (you can use up- percase or lowercase letters for the hexadecimal digits). For example, a blank space must be escaped as "%20", a tab character as "%09", and the "&" as "%26". Because the percent "%" character always has the re- served purpose of being the escape indicator, it must be escaped as "%25". It is common practice to escape space characters as the plus symbol (+) in query text; this practice isn't uniformly defined in the relevant RFCs (which recommend %20 instead) but any tool accepting URIs with query text should be prepared for them. A URI is always shown in its "escaped" form. Unreserved characters can be escaped without changing the semantics of the URI, but this should not be done unless the URI is being used in a context that does not allow the unescaped character to appear. For ex- ample, "%7e" is sometimes used instead of "~" in an HTTP URL path, but the two are equivalent for an HTTP URL. For URIs which must handle characters outside the US ASCII character set, the HTML 4.01 specification (section B.2) and IETF RFC 2718 (sec- tion 2.2.5) recommend the following approach: 1. translate the character sequences into UTF-8 (IETF RFC 2279)--see utf-8(7)--and then 2. use the URI escaping mechanism, that is, use the %HH encoding for unsafe octets. Writing a URI When written, URIs should be placed inside double quotes (e.g., "http://www.kernel.org"), enclosed in angle brackets (e.g., <http://lwn.net>), or placed on a line by themselves. A warning for those who use double-quotes: never move extraneous punctuation (such as the period ending a sentence or the comma in a list) inside a URI, since this will change the value of the URI. Instead, use angle brack- ets instead, or switch to a quoting system that never includes extrane- ous characters inside quotation marks. This latter system, called the 'new' or 'logical' quoting system by "Hart's Rules" and the "Oxford Dictionary for Writers and Editors", is preferred practice in Great Britain and hackers worldwide (see the Jargon File's section on Hacker Writing Style, <http://www.fwi.uva.nl/~mes/jargon/h /HackerWritingStyle.html>, for more information). Older documents sug- gested inserting the prefix "URL:" just before the URI, but this form has never caught on. The URI syntax was designed to be unambiguous. However, as URIs have become commonplace, traditional media (television, radio, newspapers, billboards, etc.) have increasingly used abbreviated URI references consisting of only the authority and path portions of the identified resource (e.g., <www.w3.org/Addressing>). Such references are primar- ily intended for human interpretation rather than machine, with the as- sumption that context-based heuristics are sufficient to complete the URI (e.g., hostnames beginning with "www" are likely to have a URI pre- fix of "http://" and hostnames beginning with "ftp" likely to have a prefix of "ftp://"). Many client implementations heuristically resolve these references. Such heuristics may change over time, particularly when new schemes are introduced. Since an abbreviated URI has the same syntax as a relative URL path, abbreviated URI references cannot be used where relative URIs are permitted, and can be used only when there is no defined base (such as in dialog boxes). Don't use abbreviated URIs as hypertext links inside a document; use the standard format as described here. CONFORMING TO (IETF RFC 2396) <http://www.ietf.org/rfc/rfc2396.txt>, (HTML 4.0) <http://www.w3.org/TR/REC-html40>. NOTES Any tool accepting URIs (e.g., a web browser) on a Linux system should be able to handle (directly or indirectly) all of the schemes described here, including the man: and info: schemes. Handling them by invoking some other program is fine and in fact encouraged. Technically the fragment isn't part of the URI. For information on how to embed URIs (including URLs) in a data format, see documentation on that format. HTML uses the format <A HREF="uri"> text </A>. Texinfo files use the format @uref{uri}. Man and mdoc have the recently added UR macro, or just include the URI in the text (view- ers should be able to detect :// as part of a URI). The GNOME and KDE desktop environments currently vary in the URIs they accept, in particular in their respective help browsers. To list man pages, GNOME uses <toc:man> while KDE uses <man:(index)>, and to list info pages, GNOME uses <toc:info> while KDE uses <info:(dir)> (the au- thor of this man page prefers the KDE approach here, though a more reg- ular format would be even better). In general, KDE uses <file:/cgi- bin/> as a prefix to a set of generated files. KDE prefers documenta- tion in HTML, accessed via the <file:/cgi-bin/helpindex>. GNOME pre- fers the ghelp scheme to store and find documentation. Neither browser handles file: references to directories at the time of this writing, making it difficult to refer to an entire directory with a browsable URI. As noted above, these environments differ in how they handle the info: scheme, probably the most important variation. It is expected that GNOME and KDE will converge to common URI formats, and a future version of this man page will describe the converged result. Efforts to aid this convergence are encouraged. Security A URI does not in itself pose a security threat. There is no general guarantee that a URL, which at one time located a given resource, will continue to do so. Nor is there any guarantee that a URL will not lo- cate a different resource at some later point in time; such a guarantee can be obtained only from the person(s) controlling that namespace and the resource in question. It is sometimes possible to construct a URL such that an attempt to perform a seemingly harmless operation, such as the retrieval of an en- tity associated with the resource, will in fact cause a possibly damag- ing remote operation to occur. The unsafe URL is typically constructed by specifying a port number other than that reserved for the network protocol in question. The client unwittingly contacts a site that is in fact running a different protocol. The content of the URL contains instructions that, when interpreted according to this other protocol, cause an unexpected operation. An example has been the use of a gopher URL to cause an unintended or impersonating message to be sent via a SMTP server. Caution should be used when using any URL that specifies a port number other than the default for the protocol, especially when it is a number within the reserved space. Care should be taken when a URI contains escaped delimiters for a given protocol (for example, CR and LF characters for telnet protocols) that these are not unescaped before transmission. This might violate the protocol, but avoids the potential for such characters to be used to simulate an extra operation or parameter in that protocol, which might lead to an unexpected and possibly harmful remote operation to be per- formed. It is clearly unwise to use a URI that contains a password which is in- tended to be secret. In particular, the use of a password within the "userinfo" component of a URI is strongly recommended against except in those rare cases where the "password" parameter is intended to be pub- lic. BUGS Documentation may be placed in a variety of locations, so there cur- rently isn't a good URI scheme for general online documentation in ar- bitrary formats. References of the form <file:///usr/doc/ZZZ> don't work because different distributions and local installation require- ments may place the files in different directories (it may be in /usr/doc, or /usr/local/doc, or /usr/share, or somewhere else). Also, the directory ZZZ usually changes when a version changes (though file- name globbing could partially overcome this). Finally, using the file: scheme doesn't easily support people who dynamically load documentation from the Internet (instead of loading the files onto a local filesys- tem). A future URI scheme may be added (e.g., "userdoc:") to permit programs to include cross-references to more detailed documentation without having to know the exact location of that documentation. Al- ternatively, a future version of the filesystem specification may spec- ify file locations sufficiently so that the file: scheme will be able to locate documentation. Many programs and file formats don't include a way to incorporate or implement links using URIs. Many programs can't handle all of these different URI formats; there should be a standard mechanism to load an arbitrary URI that automati- cally detects the users' environment (e.g., text or graphics, desktop environment, local user preferences, and currently executing tools) and invokes the right tool for any URI. SEE ALSO lynx(1), man2html(1), mailaddr(7), utf-8(7) IETF RFC 2255 <http://www.ietf.org/rfc/rfc2255.txt> COLOPHON This page is part of release 5.10 of the Linux man-pages project. A description of the project, information about reporting bugs, and the latest version of this page, can be found at https://www.kernel.org/doc/man-pages/. Linux 2020-08-13 URI(7) URI(3pm) User Contributed Perl Documentation URI(3pm) NAME URI - Uniform Resource Identifiers (absolute and relative) SYNOPSIS use URI (); $u1 = URI->new("http://www.example.com"); $u2 = URI->new("foo", "http"); $u3 = $u2->abs($u1); $u4 = $u3->clone; $u5 = URI->new("HTTP://WWW.example.com:80")->canonical; $str = $u->as_string; $str = "$u"; $scheme = $u->scheme; $opaque = $u->opaque; $path = $u->path; $frag = $u->fragment; $u->scheme("ftp"); $u->host("ftp.example.com"); $u->path("cpan/"); DESCRIPTION This module implements the "URI" class. Objects of this class represent "Uniform Resource Identifier references" as specified in RFC 2396 (and updated by RFC 2732). A Uniform Resource Identifier is a compact string of characters that identifies an abstract or physical resource. A Uniform Resource Identifier can be further classified as either a Uniform Resource Locator (URL) or a Uniform Resource Name (URN). The distinction between URL and URN does not matter to the "URI" class interface. A "URI-reference" is a URI that may have additional information attached in the form of a fragment identifier. An absolute URI reference consists of three parts: a scheme, a scheme- specific part and a fragment identifier. A subset of URI references share a common syntax for hierarchical namespaces. For these, the scheme-specific part is further broken down into authority, path and query components. These URIs can also take the form of relative URI references, where the scheme (and usually also the authority) component is missing, but implied by the context of the URI reference. The three forms of URI reference syntax are summarized as follows: <scheme>:<scheme-specific-part>#<fragment> <scheme>://<authority><path>?<query>#<fragment> <path>?<query>#<fragment> The components into which a URI reference can be divided depend on the scheme. The "URI" class provides methods to get and set the individual components. The methods available for a specific "URI" object depend on the scheme. CONSTRUCTORS The following methods construct new "URI" objects: $uri = URI->new( $str ) $uri = URI->new( $str, $scheme ) Constructs a new URI object. The string representation of a URI is given as argument, together with an optional scheme specification. Common URI wrappers like "" and <>, as well as leading and trailing white space, are automatically removed from the $str argument before it is processed further. The constructor determines the scheme, maps this to an appropriate URI subclass, constructs a new object of that class and returns it. If the scheme isn't one of those that URI recognizes, you still get an URI object back that you can access the generic methods on. The "$uri->has_recognized_scheme" method can be used to test for this. The $scheme argument is only used when $str is a relative URI. It can be either a simple string that denotes the scheme, a string containing an absolute URI reference, or an absolute "URI" object. If no $scheme is specified for a relative URI $str, then $str is simply treated as a generic URI (no scheme-specific methods available). The set of characters available for building URI references is restricted (see URI::Escape). Characters outside this set are automatically escaped by the URI constructor. $uri = URI->new_abs( $str, $base_uri ) Constructs a new absolute URI object. The $str argument can denote a relative or absolute URI. If relative, then it is absolutized using $base_uri as base. The $base_uri must be an absolute URI. $uri = URI::file->new( $filename ) $uri = URI::file->new( $filename, $os ) Constructs a new file URI from a file name. See URI::file. $uri = URI::file->new_abs( $filename ) $uri = URI::file->new_abs( $filename, $os ) Constructs a new absolute file URI from a file name. See URI::file. $uri = URI::file->cwd Returns the current working directory as a file URI. See URI::file. $uri->clone Returns a copy of the $uri. COMMON METHODS The methods described in this section are available for all "URI" objects. Methods that give access to components of a URI always return the old value of the component. The value returned is "undef" if the component was not present. There is generally a difference between a component that is empty (represented as "") and a component that is missing (represented as "undef"). If an accessor method is given an argument, it updates the corresponding component in addition to returning the old value of the component. Passing an undefined argument removes the component (if possible). The description of each accessor method indicates whether the component is passed as an escaped (percent- encoded) or an unescaped string. A component that can be further divided into sub-parts are usually passed escaped, as unescaping might change its semantics. The common methods available for all URI are: $uri->scheme $uri->scheme( $new_scheme ) Sets and returns the scheme part of the $uri. If the $uri is relative, then $uri->scheme returns "undef". If called with an argument, it updates the scheme of $uri, possibly changing the class of $uri, and returns the old scheme value. The method croaks if the new scheme name is illegal; a scheme name must begin with a letter and must consist of only US-ASCII letters, numbers, and a few special marks: ".", "+", "-". This restriction effectively means that the scheme must be passed unescaped. Passing an undefined argument to the scheme method makes the URI relative (if possible). Letter case does not matter for scheme names. The string returned by $uri->scheme is always lowercase. If you want the scheme just as it was written in the URI in its original case, you can use the $uri->_scheme method instead. $uri->has_recognized_scheme Returns TRUE if the URI scheme is one that URI recognizes. It will also be TRUE for relative URLs where a recognized scheme was provided to the constructor, even if "$uri->scheme" returns "undef" for these. $uri->opaque $uri->opaque( $new_opaque ) Sets and returns the scheme-specific part of the $uri (everything between the scheme and the fragment) as an escaped string. $uri->path $uri->path( $new_path ) Sets and returns the same value as $uri->opaque unless the URI supports the generic syntax for hierarchical namespaces. In that case the generic method is overridden to set and return the part of the URI between the host name and the fragment. $uri->fragment $uri->fragment( $new_frag ) Returns the fragment identifier of a URI reference as an escaped string. $uri->as_string Returns a URI object to a plain ASCII string. URI objects are also converted to plain strings automatically by overloading. This means that $uri objects can be used as plain strings in most Perl constructs. $uri->as_iri Returns a Unicode string representing the URI. Escaped UTF-8 sequences representing non-ASCII characters are turned into their corresponding Unicode code point. $uri->canonical Returns a normalized version of the URI. The rules for normalization are scheme-dependent. They usually involve lowercasing the scheme and Internet host name components, removing the explicit port specification if it matches the default port, uppercasing all escape sequences, and unescaping octets that can be better represented as plain characters. For efficiency reasons, if the $uri is already in normalized form, then a reference to it is returned instead of a copy. $uri->eq( $other_uri ) URI::eq( $first_uri, $other_uri ) Tests whether two URI references are equal. URI references that normalize to the same string are considered equal. The method can also be used as a plain function which can also test two string arguments. If you need to test whether two "URI" object references denote the same object, use the '==' operator. $uri->abs( $base_uri ) Returns an absolute URI reference. If $uri is already absolute, then a reference to it is simply returned. If the $uri is relative, then a new absolute URI is constructed by combining the $uri and the $base_uri, and returned. $uri->rel( $base_uri ) Returns a relative URI reference if it is possible to make one that denotes the same resource relative to $base_uri. If not, then $uri is simply returned. $uri->secure Returns a TRUE value if the URI is considered to point to a resource on a secure channel, such as an SSL or TLS encrypted one. GENERIC METHODS The following methods are available to schemes that use the common/generic syntax for hierarchical namespaces. The descriptions of schemes below indicate which these are. Unrecognized schemes are assumed to support the generic syntax, and therefore the following methods: $uri->authority $uri->authority( $new_authority ) Sets and returns the escaped authority component of the $uri. $uri->path $uri->path( $new_path ) Sets and returns the escaped path component of the $uri (the part between the host name and the query or fragment). The path can never be undefined, but it can be the empty string. $uri->path_query $uri->path_query( $new_path_query ) Sets and returns the escaped path and query components as a single entity. The path and the query are separated by a "?" character, but the query can itself contain "?". $uri->path_segments $uri->path_segments( $segment, ... ) Sets and returns the path. In a scalar context, it returns the same value as $uri->path. In a list context, it returns the unescaped path segments that make up the path. Path segments that have parameters are returned as an anonymous array. The first element is the unescaped path segment proper; subsequent elements are escaped parameter strings. Such an anonymous array uses overloading so it can be treated as a string too, but this string does not include the parameters. Note that absolute paths have the empty string as their first path_segment, i.e. the path "/foo/bar" have 3 path_segments; "", "foo" and "bar". $uri->query $uri->query( $new_query ) Sets and returns the escaped query component of the $uri. $uri->query_form $uri->query_form( $key1 => $val1, $key2 => $val2, ... ) $uri->query_form( $key1 => $val1, $key2 => $val2, ..., $delim ) $uri->query_form( \@key_value_pairs ) $uri->query_form( \@key_value_pairs, $delim ) $uri->query_form( \%hash ) $uri->query_form( \%hash, $delim ) Sets and returns query components that use the application/x-www-form-urlencoded format. Key/value pairs are separated by "&", and the key is separated from the value by a "=" character. The form can be set either by passing separate key/value pairs, or via an array or hash reference. Passing an empty array or an empty hash removes the query component, whereas passing no arguments at all leaves the component unchanged. The order of keys is undefined if a hash reference is passed. The old value is always returned as a list of separate key/value pairs. Assigning this list to a hash is unwise as the keys returned might repeat. The values passed when setting the form can be plain strings or references to arrays of strings. Passing an array of values has the same effect as passing the key repeatedly with one value at a time. All the following statements have the same effect: $uri->query_form(foo => 1, foo => 2); $uri->query_form(foo => [1, 2]); $uri->query_form([ foo => 1, foo => 2 ]); $uri->query_form([ foo => [1, 2] ]); $uri->query_form({ foo => [1, 2] }); The $delim parameter can be passed as ";" to force the key/value pairs to be delimited by ";" instead of "&" in the query string. This practice is often recommended for URLs embedded in HTML or XML documents as this avoids the trouble of escaping the "&" character. You might also set the $URI::DEFAULT_QUERY_FORM_DELIMITER variable to ";" for the same global effect. The "URI::QueryParam" module can be loaded to add further methods to manipulate the form of a URI. See URI::QueryParam for details. $uri->query_keywords $uri->query_keywords( $keywords, ... ) $uri->query_keywords( \@keywords ) Sets and returns query components that use the keywords separated by "+" format. The keywords can be set either by passing separate keywords directly or by passing a reference to an array of keywords. Passing an empty array removes the query component, whereas passing no arguments at all leaves the component unchanged. The old value is always returned as a list of separate words. SERVER METHODS For schemes where the authority component denotes an Internet host, the following methods are available in addition to the generic methods. $uri->userinfo $uri->userinfo( $new_userinfo ) Sets and returns the escaped userinfo part of the authority component. For some schemes this is a user name and a password separated by a colon. This practice is not recommended. Embedding passwords in clear text (such as URI) has proven to be a security risk in almost every case where it has been used. $uri->host $uri->host( $new_host ) Sets and returns the unescaped hostname. If the $new_host string ends with a colon and a number, then this number also sets the port. For IPv6 addresses the brackets around the raw address is removed in the return value from $uri->host. When setting the host attribute to an IPv6 address you can use a raw address or one enclosed in brackets. The address needs to be enclosed in brackets if you want to pass in a new port value as well. $uri->ihost Returns the host in Unicode form. Any IDNA A-labels are turned into U-labels. $uri->port $uri->port( $new_port ) Sets and returns the port. The port is a simple integer that should be greater than 0. If a port is not specified explicitly in the URI, then the URI scheme's default port is returned. If you don't want the default port substituted, then you can use the $uri->_port method instead. $uri->host_port $uri->host_port( $new_host_port ) Sets and returns the host and port as a single unit. The returned value includes a port, even if it matches the default port. The host part and the port part are separated by a colon: ":". For IPv6 addresses the bracketing is preserved; thus URI->new("http://[::1]/")->host_port returns "[::1]:80". Contrast this with $uri->host which will remove the brackets. $uri->default_port Returns the default port of the URI scheme to which $uri belongs. For http this is the number 80, for ftp this is the number 21, etc. The default port for a scheme can not be changed. SCHEME-SPECIFIC SUPPORT Scheme-specific support is provided for the following URI schemes. For "URI" objects that do not belong to one of these, you can only use the common and generic methods. data: The data URI scheme is specified in RFC 2397. It allows inclusion of small data items as "immediate" data, as if it had been included externally. "URI" objects belonging to the data scheme support the common methods and two new methods to access their scheme-specific components: $uri->media_type and $uri->data. See URI::data for details. file: An old specification of the file URI scheme is found in RFC 1738. A new RFC 2396 based specification in not available yet, but file URI references are in common use. "URI" objects belonging to the file scheme support the common and generic methods. In addition, they provide two methods for mapping file URIs back to local file names; $uri->file and $uri->dir. See URI::file for details. ftp: An old specification of the ftp URI scheme is found in RFC 1738. A new RFC 2396 based specification in not available yet, but ftp URI references are in common use. "URI" objects belonging to the ftp scheme support the common, generic and server methods. In addition, they provide two methods for accessing the userinfo sub-components: $uri->user and $uri->password. gopher: The gopher URI scheme is specified in <draft-murali-url-gopher-1996-12-04> and will hopefully be available as a RFC 2396 based specification. "URI" objects belonging to the gopher scheme support the common, generic and server methods. In addition, they support some methods for accessing gopher-specific path components: $uri->gopher_type, $uri->selector, $uri->search, $uri->string. http: The http URI scheme is specified in RFC 2616. The scheme is used to reference resources hosted by HTTP servers. "URI" objects belonging to the http scheme support the common, generic and server methods. https: The https URI scheme is a Netscape invention which is commonly implemented. The scheme is used to reference HTTP servers through SSL connections. Its syntax is the same as http, but the default port is different. ldap: The ldap URI scheme is specified in RFC 2255. LDAP is the Lightweight Directory Access Protocol. An ldap URI describes an LDAP search operation to perform to retrieve information from an LDAP directory. "URI" objects belonging to the ldap scheme support the common, generic and server methods as well as ldap-specific methods: $uri->dn, $uri->attributes, $uri->scope, $uri->filter, $uri->extensions. See URI::ldap for details. ldapi: Like the ldap URI scheme, but uses a UNIX domain socket. The server methods are not supported, and the local socket path is available as $uri->un_path. The ldapi scheme is used by the OpenLDAP package. There is no real specification for it, but it is mentioned in various OpenLDAP manual pages. ldaps: Like the ldap URI scheme, but uses an SSL connection. This scheme is deprecated, as the preferred way is to use the start_tls mechanism. mailto: The mailto URI scheme is specified in RFC 2368. The scheme was originally used to designate the Internet mailing address of an individual or service. It has (in RFC 2368) been extended to allow setting of other mail header fields and the message body. "URI" objects belonging to the mailto scheme support the common methods and the generic query methods. In addition, they support the following mailto-specific methods: $uri->to, $uri->headers. Note that the "foo AT example.com" part of a mailto is not the "userinfo" and "host" but instead the "path". This allows a mailto URI to contain multiple comma separated email addresses. mms: The mms URL specification can be found at <http://sdp.ppona.com/>. "URI" objects belonging to the mms scheme support the common, generic, and server methods, with the exception of userinfo and query-related sub-components. news: The news, nntp and snews URI schemes are specified in <draft-gilman-news-url-01> and will hopefully be available as an RFC 2396 based specification soon. (Update: as of April 2010, they are in RFC 5538 <https://tools.ietf.org/html/rfc5538>. "URI" objects belonging to the news scheme support the common, generic and server methods. In addition, they provide some methods to access the path: $uri->group and $uri->message. nntp: See news scheme. nntps: See news scheme and RFC 5538 <https://tools.ietf.org/html/rfc5538>. pop: The pop URI scheme is specified in RFC 2384. The scheme is used to reference a POP3 mailbox. "URI" objects belonging to the pop scheme support the common, generic and server methods. In addition, they provide two methods to access the userinfo components: $uri->user and $uri->auth rlogin: An old specification of the rlogin URI scheme is found in RFC 1738. "URI" objects belonging to the rlogin scheme support the common, generic and server methods. rtsp: The rtsp URL specification can be found in section 3.2 of RFC 2326. "URI" objects belonging to the rtsp scheme support the common, generic, and server methods, with the exception of userinfo and query-related sub-components. rtspu: The rtspu URI scheme is used to talk to RTSP servers over UDP instead of TCP. The syntax is the same as rtsp. rsync: Information about rsync is available from <http://rsync.samba.org/>. "URI" objects belonging to the rsync scheme support the common, generic and server methods. In addition, they provide methods to access the userinfo sub- components: $uri->user and $uri->password. sip: The sip URI specification is described in sections 19.1 and 25 of RFC 3261. "URI" objects belonging to the sip scheme support the common, generic, and server methods with the exception of path related sub-components. In addition, they provide two methods to get and set sip parameters: $uri->params_form and $uri->params. sips: See sip scheme. Its syntax is the same as sip, but the default port is different. snews: See news scheme. Its syntax is the same as news, but the default port is different. telnet: An old specification of the telnet URI scheme is found in RFC 1738. "URI" objects belonging to the telnet scheme support the common, generic and server methods. tn3270: These URIs are used like telnet URIs but for connections to IBM mainframes. "URI" objects belonging to the tn3270 scheme support the common, generic and server methods. ssh: Information about ssh is available at <http://www.openssh.com/>. "URI" objects belonging to the ssh scheme support the common, generic and server methods. In addition, they provide methods to access the userinfo sub-components: $uri->user and $uri->password. sftp: "URI" objects belonging to the sftp scheme support the common, generic and server methods. In addition, they provide methods to access the userinfo sub-components: $uri->user and $uri->password. urn: The syntax of Uniform Resource Names is specified in RFC 2141. "URI" objects belonging to the urn scheme provide the common methods, and also the methods $uri->nid and $uri->nss, which return the Namespace Identifier and the Namespace-Specific String respectively. The Namespace Identifier basically works like the Scheme identifier of URIs, and further divides the URN namespace. Namespace Identifier assignments are maintained at <http://www.iana.org/assignments/urn-namespaces>. Letter case is not significant for the Namespace Identifier. It is always returned in lower case by the $uri->nid method. The $uri->_nid method can be used if you want it in its original case. urn:isbn: The "urn:isbn:" namespace contains International Standard Book Numbers (ISBNs) and is described in RFC 3187. A "URI" object belonging to this namespace has the following extra methods (if the Business::ISBN module is available): $uri->isbn, $uri->isbn_publisher_code, $uri->isbn_group_code (formerly isbn_country_code, which is still supported by issues a deprecation warning), $uri->isbn_as_ean. urn:oid: The "urn:oid:" namespace contains Object Identifiers (OIDs) and is described in RFC 3061. An object identifier consists of sequences of digits separated by dots. A "URI" object belonging to this namespace has an additional method called $uri->oid that can be used to get/set the oid value. In a list context, oid numbers are returned as separate elements. CONFIGURATION VARIABLES The following configuration variables influence how the class and its methods behave: $URI::ABS_ALLOW_RELATIVE_SCHEME Some older parsers used to allow the scheme name to be present in the relative URL if it was the same as the base URL scheme. RFC 2396 says that this should be avoided, but you can enable this old behaviour by setting the $URI::ABS_ALLOW_RELATIVE_SCHEME variable to a TRUE value. The difference is demonstrated by the following examples: URI->new("http:foo")->abs("http://host/a/b") ==> "http:foo" local $URI::ABS_ALLOW_RELATIVE_SCHEME = 1; URI->new("http:foo")->abs("http://host/a/b") ==> "http:/host/a/foo" $URI::ABS_REMOTE_LEADING_DOTS You can also have the abs() method ignore excess ".." segments in the relative URI by setting $URI::ABS_REMOTE_LEADING_DOTS to a TRUE value. The difference is demonstrated by the following examples: URI->new("../../../foo")->abs("http://host/a/b") ==> "http://host/../../foo" local $URI::ABS_REMOTE_LEADING_DOTS = 1; URI->new("../../../foo")->abs("http://host/a/b") ==> "http://host/foo" $URI::DEFAULT_QUERY_FORM_DELIMITER This value can be set to ";" to have the query form "key=value" pairs delimited by ";" instead of "&" which is the default. BUGS There are some things that are not quite right: o Using regexp variables like $1 directly as arguments to the URI accessor methods does not work too well with current perl implementations. I would argue that this is actually a bug in perl. The workaround is to quote them. Example: /(...)/ || die; $u->query("$1"); o The escaping (percent encoding) of chars in the 128 .. 255 range passed to the URI constructor or when setting URI parts using the accessor methods depend on the state of the internal UTF8 flag (see utf8::is_utf8) of the string passed. If the UTF8 flag is set the UTF-8 encoded version of the character is percent encoded. If the UTF8 flag isn't set the Latin-1 version (byte) of the character is percent encoded. This basically exposes the internal encoding of Perl strings. PARSING URIs WITH REGEXP As an alternative to this module, the following (official) regular expression can be used to decode a URI: my($scheme, $authority, $path, $query, $fragment) = $uri =~ m|(?:([^:/?#]+):)?(?://([^/?#]*))?([^?#]*)(?:\?([^#]*))?(?:#(.*))?|; The "URI::Split" module provides the function uri_split() as a readable alternative. SEE ALSO URI::file, URI::WithBase, URI::QueryParam, URI::Escape, URI::Split, URI::Heuristic RFC 2396: "Uniform Resource Identifiers (URI): Generic Syntax", Berners-Lee, Fielding, Masinter, August 1998. <http://www.iana.org/assignments/uri-schemes> <http://www.iana.org/assignments/urn-namespaces> <http://www.w3.org/Addressing/> COPYRIGHT Copyright 1995-2009 Gisle Aas. Copyright 1995 Martijn Koster. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. AUTHORS / ACKNOWLEDGMENTS This module is based on the "URI::URL" module, which in turn was (distantly) based on the "wwwurl.pl" code in the libwww-perl for perl4 developed by Roy Fielding, as part of the Arcadia project at the University of California, Irvine, with contributions from Brooks Cutter. "URI::URL" was developed by Gisle Aas, Tim Bunce, Roy Fielding and Martijn Koster with input from other people on the libwww-perl mailing list. "URI" and related subclasses was developed by Gisle Aas. perl v5.32.1 2021-10-26 URI(3pm)
Generated by phpman v3.7.12 Author: Che Dong Under GNU General Public License
2026-06-13 12:27 @216.73.216.28
CrawledBy Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)