ascript-build016/doc/htdocs/stylesheet.css 777 0 0 111 11377062653 14024 0 h1 {
color: #008800;
}
body {
margin: 3em 5em 1em 5em;
}
ascript-build016/doc/reference/ 777 0 0 0 11433577323 11535 5 ascript-build016/doc/reference/rfc1738.txt 777 0 0 144224 11421707665 13526 0
Network Working Group T. Berners-Lee
Request for Comments: 1738 CERN
Category: Standards Track L. Masinter
Xerox Corporation
M. McCahill
University of Minnesota
Editors
December 1994
Uniform Resource Locators (URL)
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document specifies a Uniform Resource Locator (URL), the syntax
and semantics of formalized information for location and access of
resources via the Internet.
1. Introduction
This document describes the syntax and semantics for a compact string
representation for a resource available via the Internet. These
strings are called "Uniform Resource Locators" (URLs).
The specification is derived from concepts introduced by the World-
Wide Web global information initiative, whose use of such objects
dates from 1990 and is described in "Universal Resource Identifiers
in WWW", RFC 1630. The specification of URLs is designed to meet the
requirements laid out in "Functional Requirements for Internet
Resource Locators" [12].
This document was written by the URI working group of the Internet
Engineering Task Force. Comments may be addressed to the editors, or
to the URI-WG . Discussions of the group are archived
at
Berners-Lee, Masinter & McCahill [Page 1]
RFC 1738 Uniform Resource Locators (URL) December 1994
2. General URL Syntax
Just as there are many different methods of access to resources,
there are several schemes for describing the location of such
resources.
The generic syntax for URLs provides a framework for new schemes to
be established using protocols other than those defined in this
document.
URLs are used to `locate' resources, by providing an abstract
identification of the resource location. Having located a resource,
a system may perform a variety of operations on the resource, as
might be characterized by such words as `access', `update',
`replace', `find attributes'. In general, only the `access' method
needs to be specified for any URL scheme.
2.1. The main parts of URLs
A full BNF description of the URL syntax is given in Section 5.
In general, URLs are written as follows:
:
A URL contains the name of the scheme being used () followed
by a colon and then a string (the ) whose
interpretation depends on the scheme.
Scheme names consist of a sequence of characters. The lower case
letters "a"--"z", digits, and the characters plus ("+"), period
("."), and hyphen ("-") are allowed. For resiliency, programs
interpreting URLs should treat upper case letters as equivalent to
lower case in scheme names (e.g., allow "HTTP" as well as "http").
2.2. URL Character Encoding Issues
URLs are sequences of characters, i.e., letters, digits, and special
characters. A URLs may be represented in a variety of ways: e.g., ink
on paper, or a sequence of octets in a coded character set. The
interpretation of a URL depends only on the identity of the
characters used.
In most URL schemes, the sequences of characters in different parts
of a URL are used to represent sequences of octets used in Internet
protocols. For example, in the ftp scheme, the host name, directory
name and file names are such sequences of octets, represented by
parts of the URL. Within those parts, an octet may be represented by
Berners-Lee, Masinter & McCahill [Page 2]
RFC 1738 Uniform Resource Locators (URL) December 1994
the chararacter which has that octet as its code within the US-ASCII
[20] coded character set.
In addition, octets may be encoded by a character triplet consisting
of the character "%" followed by the two hexadecimal digits (from
"0123456789ABCDEF") which forming the hexadecimal value of the octet.
(The characters "abcdef" may also be used in hexadecimal encodings.)
Octets must be encoded if they have no corresponding graphic
character within the US-ASCII coded character set, if the use of the
corresponding character is unsafe, or if the corresponding character
is reserved for some other interpretation within the particular URL
scheme.
No corresponding graphic US-ASCII:
URLs are written only with the graphic printable characters of the
US-ASCII coded character set. The octets 80-FF hexadecimal are not
used in US-ASCII, and the octets 00-1F and 7F hexadecimal represent
control characters; these must be encoded.
Unsafe:
Characters can be unsafe for a number of reasons. The space
character is unsafe because significant spaces may disappear and
insignificant spaces may be introduced when URLs are transcribed or
typeset or subjected to the treatment of word-processing programs.
The characters "<" and ">" are unsafe because they are used as the
delimiters around URLs in free text; the quote mark (""") is used to
delimit URLs in some systems. The character "#" is unsafe and should
always be encoded because it is used in World Wide Web and in other
systems to delimit a URL from a fragment/anchor identifier that might
follow it. The character "%" is unsafe because it is used for
encodings of other characters. Other characters are unsafe because
gateways and other transport agents are known to sometimes modify
such characters. These characters are "{", "}", "|", "\", "^", "~",
"[", "]", and "`".
All unsafe characters must always be encoded within a URL. For
example, the character "#" must be encoded within URLs even in
systems that do not normally deal with fragment or anchor
identifiers, so that if the URL is copied into another system that
does use them, it will not be necessary to change the URL encoding.
Berners-Lee, Masinter & McCahill [Page 3]
RFC 1738 Uniform Resource Locators (URL) December 1994
Reserved:
Many URL schemes reserve certain characters for a special meaning:
their appearance in the scheme-specific part of the URL has a
designated semantics. If the character corresponding to an octet is
reserved in a scheme, the octet must be encoded. The characters ";",
"/", "?", ":", "@", "=" and "&" are the characters which may be
reserved for special meaning within a scheme. No other characters may
be reserved within a scheme.
Usually a URL has the same interpretation when an octet is
represented by a character and when it encoded. However, this is not
true for reserved characters: encoding a character reserved for a
particular scheme may change the semantics of a URL.
Thus, only alphanumerics, the special characters "$-_.+!*'(),", and
reserved characters used for their reserved purposes may be used
unencoded within a URL.
On the other hand, characters that are not required to be encoded
(including alphanumerics) may be encoded within the scheme-specific
part of a URL, as long as they are not being used for a reserved
purpose.
2.3 Hierarchical schemes and relative links
In some cases, URLs are used to locate resources that contain
pointers to other resources. In some cases, those pointers are
represented as relative links where the expression of the location of
the second resource is in terms of "in the same place as this one
except with the following relative path". Relative links are not
described in this document. However, the use of relative links
depends on the original URL containing a hierarchical structure
against which the relative link is based.
Some URL schemes (such as the ftp, http, and file schemes) contain
names that can be considered hierarchical; the components of the
hierarchy are separated by "/".
Berners-Lee, Masinter & McCahill [Page 4]
RFC 1738 Uniform Resource Locators (URL) December 1994
3. Specific Schemes
The mapping for some existing standard and experimental protocols is
outlined in the BNF syntax definition. Notes on particular protocols
follow. The schemes covered are:
ftp File Transfer protocol
http Hypertext Transfer Protocol
gopher The Gopher protocol
mailto Electronic mail address
news USENET news
nntp USENET news using NNTP access
telnet Reference to interactive sessions
wais Wide Area Information Servers
file Host-specific file names
prospero Prospero Directory Service
Other schemes may be specified by future specifications. Section 4 of
this document describes how new schemes may be registered, and lists
some scheme names that are under development.
3.1. Common Internet Scheme Syntax
While the syntax for the rest of the URL may vary depending on the
particular scheme selected, URL schemes that involve the direct use
of an IP-based protocol to a specified host on the Internet use a
common syntax for the scheme-specific data:
//:@:/
Some or all of the parts ":@", ":",
":", and "/" may be excluded. The scheme specific
data start with a double slash "//" to indicate that it complies with
the common Internet scheme syntax. The different components obey the
following rules:
user
An optional user name. Some schemes (e.g., ftp) allow the
specification of a user name.
password
An optional password. If present, it follows the user
name separated from it by a colon.
The user name (and password), if present, are followed by a
commercial at-sign "@". Within the user and password field, any ":",
"@", or "/" must be encoded.
Berners-Lee, Masinter & McCahill [Page 5]
RFC 1738 Uniform Resource Locators (URL) December 1994
Note that an empty user name or password is different than no user
name or password; there is no way to specify a password without
specifying a user name. E.g., has an empty
user name and no password, has no user name,
while has a user name of "foo" and an
empty password.
host
The fully qualified domain name of a network host, or its IP
address as a set of four decimal digit groups separated by
".". Fully qualified domain names take the form as described
in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123
[5]: a sequence of domain labels separated by ".", each domain
label starting and ending with an alphanumerical character and
possibly also containing "-" characters. The rightmost domain
label will never start with a digit, though, which
syntactically distinguishes all domain names from the IP
addresses.
port
The port number to connect to. Most schemes designate
protocols that have a default port number. Another port number
may optionally be supplied, in decimal, separated from the
host by a colon. If the port is omitted, the colon is as well.
url-path
The rest of the locator consists of data specific to the
scheme, and is known as the "url-path". It supplies the
details of how the specified resource can be accessed. Note
that the "/" between the host (or port) and the url-path is
NOT part of the url-path.
The url-path syntax depends on the scheme being used, as does the
manner in which it is interpreted.
3.2. FTP
The FTP URL scheme is used to designate files and directories on
Internet hosts accessible using the FTP protocol (RFC959).
A FTP URL follow the syntax described in Section 3.1. If : is
omitted, the port defaults to 21.
Berners-Lee, Masinter & McCahill [Page 6]
RFC 1738 Uniform Resource Locators (URL) December 1994
3.2.1. FTP Name and Password
A user name and password may be supplied; they are used in the ftp
"USER" and "PASS" commands after first making the connection to the
FTP server. If no user name or password is supplied and one is
requested by the FTP server, the conventions for "anonymous" FTP are
to be used, as follows:
The user name "anonymous" is supplied.
The password is supplied as the Internet e-mail address
of the end user accessing the resource.
If the URL supplies a user name but no password, and the remote
server requests a password, the program interpreting the FTP URL
should request one from the user.
3.2.2. FTP url-path
The url-path of a FTP URL has the following syntax:
//...//;type=
Where through and are (possibly encoded) strings
and is one of the characters "a", "i", or "d". The part
";type=" may be omitted. The and parts may be
empty. The whole url-path may be omitted, including the "/"
delimiting it from the prefix containing user, password, host, and
port.
The url-path is interpreted as a series of FTP commands as follows:
Each of the elements is to be supplied, sequentially, as the
argument to a CWD (change working directory) command.
If the typecode is "d", perform a NLST (name list) command with
as the argument, and interpret the results as a file
directory listing.
Otherwise, perform a TYPE command with as the argument,
and then access the file whose name is (for example, using
the RETR command.)
Within a name or CWD component, the characters "/" and ";" are
reserved and must be encoded. The components are decoded prior to
their use in the FTP protocol. In particular, if the appropriate FTP
sequence to access a particular file requires supplying a string
containing a "/" as an argument to a CWD or RETR command, it is
Berners-Lee, Masinter & McCahill [Page 7]
RFC 1738 Uniform Resource Locators (URL) December 1994
necessary to encode each "/".
For example, the URL is
interpreted by FTP-ing to "host.dom", logging in as "myname"
(prompting for a password if it is asked for), and then executing
"CWD /etc" and then "RETR motd". This has a different meaning from
which would "CWD etc" and then
"RETR motd"; the initial "CWD" might be executed relative to the
default directory for "myname". On the other hand,
, would "CWD " with a null
argument, then "CWD etc", and then "RETR motd".
FTP URLs may also be used for other operations; for example, it is
possible to update a file on a remote file server, or infer
information about it from the directory listings. The mechanism for
doing so is not spelled out here.
3.2.3. FTP Typecode is Optional
The entire ;type= part of a FTP URL is optional. If it is
omitted, the client program interpreting the URL must guess the
appropriate mode to use. In general, the data content type of a file
can only be guessed from the name, e.g., from the suffix of the name;
the appropriate type code to be used for transfer of the file can
then be deduced from the data content of the file.
3.2.4 Hierarchy
For some file systems, the "/" used to denote the hierarchical
structure of the URL corresponds to the delimiter used to construct a
file name hierarchy, and thus, the filename will look similar to the
URL path. This does NOT mean that the URL is a Unix filename.
3.2.5. Optimization
Clients accessing resources via FTP may employ additional heuristics
to optimize the interaction. For some FTP servers, for example, it
may be reasonable to keep the control connection open while accessing
multiple URLs from the same server. However, there is no common
hierarchical model to the FTP protocol, so if a directory change
command has been given, it is impossible in general to deduce what
sequence should be given to navigate to another directory for a
second retrieval, if the paths are different. The only reliable
algorithm is to disconnect and reestablish the control connection.
Berners-Lee, Masinter & McCahill [Page 8]
RFC 1738 Uniform Resource Locators (URL) December 1994
3.3. HTTP
The HTTP URL scheme is used to designate Internet resources
accessible using HTTP (HyperText Transfer Protocol).
The HTTP protocol is specified elsewhere. This specification only
describes the syntax of HTTP URLs.
An HTTP URL takes the form:
http://:/?
where and are as described in Section 3.1. If :
is omitted, the port defaults to 80. No user name or password is
allowed. is an HTTP selector, and is a query
string. The is optional, as is the and its
preceding "?". If neither nor is present, the "/"
may also be omitted.
Within the and components, "/", ";", "?" are
reserved. The "/" character may be used within HTTP to designate a
hierarchical structure.
3.4. GOPHER
The Gopher URL scheme is used to designate Internet resources
accessible using the Gopher protocol.
The base Gopher protocol is described in RFC 1436 and supports items
and collections of items (directories). The Gopher+ protocol is a set
of upward compatible extensions to the base Gopher protocol and is
described in [2]. Gopher+ supports associating arbitrary sets of
attributes and alternate data representations with Gopher items.
Gopher URLs accommodate both Gopher and Gopher+ items and item
attributes.
3.4.1. Gopher URL syntax
A Gopher URL takes the form:
gopher://:/
where is one of
%09%09%09
Berners-Lee, Masinter & McCahill [Page 9]
RFC 1738 Uniform Resource Locators (URL) December 1994
If : is omitted, the port defaults to 70. is a
single-character field to denote the Gopher type of the resource to
which the URL refers. The entire may also be empty, in
which case the delimiting "/" is also optional and the
defaults to "1".
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).
Gopher clients specify which item to retrieve by sending the Gopher
selector string to a Gopher server.
Within the , no characters are reserved.
Note that some Gopher strings begin with a copy of the
character, in which case that character will occur twice
consecutively. The Gopher selector string may be an empty string;
this is how Gopher clients refer to the top-level directory on a
Gopher server.
3.4.2 Specifying URLs for Gopher Search Engines
If the URL refers to a search to be submitted to a Gopher search
engine, the selector is followed by an encoded tab (%09) and the
search string. To submit a search to a Gopher search engine, the
Gopher client sends the string (after decoding), a tab,
and the search string to the Gopher server.
3.4.3 URL syntax for Gopher+ items
URLs for Gopher+ items have a second encoded tab (%09) and a Gopher+
string. Note that in this case, the %09 string must be
supplied, although the element may be the empty string.
The is used to represent information required for
retrieval of the Gopher+ item. Gopher+ items may have alternate
views, arbitrary sets of attributes, and may have electronic forms
associated with them.
To retrieve the data associated with a Gopher+ URL, a client will
connect to the server and send the Gopher selector, followed by a tab
and the search string (which may be empty), followed by a tab and the
Gopher+ commands.
Berners-Lee, Masinter & McCahill [Page 10]
RFC 1738 Uniform Resource Locators (URL) December 1994
3.4.4 Default Gopher+ data representation
When a Gopher server returns a directory listing to a client, the
Gopher+ items are tagged with either a "+" (denoting Gopher+ items)
or a "?" (denoting Gopher+ items which have a +ASK form associated
with them). A Gopher URL with a Gopher+ string consisting of only a
"+" refers to the default view (data representation) of the item
while a Gopher+ string containing only a "?" refer to an item with a
Gopher electronic form associated with it.
3.4.5 Gopher+ items with electronic forms
Gopher+ items which have a +ASK associated with them (i.e. Gopher+
items tagged with a "?") require the client to fetch the item's +ASK
attribute to get the form definition, and then ask the user to fill
out the form and return the user's responses along with the selector
string to retrieve the item. Gopher+ clients know how to do this but
depend on the "?" tag in the Gopher+ item description to know when to
handle this case. The "?" is used in the Gopher+ string to be
consistent with Gopher+ protocol's use of this symbol.
3.4.6 Gopher+ item attribute collections
To refer to the Gopher+ attributes of an item, the Gopher URL's
Gopher+ string consists of "!" or "$". "!" refers to the all of a
Gopher+ item's attributes. "$" refers to all the item attributes for
all items in a Gopher directory.
3.4.7 Referring to specific Gopher+ attributes
To refer to specific attributes, the URL's gopher+_string is
"!" or "$". For example, to refer to
the attribute containing the abstract of an item, the gopher+_string
would be "!+ABSTRACT".
To refer to several attributes, the gopher+_string consists of the
attribute names separated by coded spaces. For example,
"!+ABSTRACT%20+SMELL" refers to the +ABSTRACT and +SMELL attributes
of an item.
3.4.8 URL syntax for Gopher+ alternate views
Gopher+ allows for optional alternate data representations (alternate
views) of items. To retrieve a Gopher+ alternate view, a Gopher+
client sends the appropriate view and language identifier (found in
the item's +VIEW attribute). To refer to a specific Gopher+ alternate
view, the URL's Gopher+ string would be in the form:
Berners-Lee, Masinter & McCahill [Page 11]
RFC 1738 Uniform Resource Locators (URL) December 1994
+%20
For example, a Gopher+ string of "+application/postscript%20Es_ES"
refers to the Spanish language postscript alternate view of a Gopher+
item.
3.4.9 URL syntax for Gopher+ electronic forms
The gopher+_string for a URL that refers to an item referenced by a
Gopher+ electronic form (an ASK block) filled out with specific
values is a coded version of what the client sends to the server.
The gopher+_string is of the form:
+%091%0D%0A+-1%0D%0A%0D%0A%0D%0A.%0D%0A
To retrieve this item, the Gopher client sends:
+1
+-1
.
to the Gopher server.
3.5. MAILTO
The mailto URL scheme is used to designate the Internet mailing
address of an individual or service. No additional information other
than an Internet mailing address is present or implied.
A mailto URL takes the form:
mailto:
where is (the encoding of an) addr-spec, as
specified in RFC 822 [6]. Within mailto URLs, there are no reserved
characters.
Note that the percent sign ("%") is commonly used within RFC 822
addresses and must be encoded.
Unlike many URLs, the mailto scheme does not represent a data object
to be accessed directly; there is no sense in which it designates an
object. It has a different use than the message/external-body type in
MIME.
Berners-Lee, Masinter & McCahill [Page 12]
RFC 1738 Uniform Resource Locators (URL) December 1994
3.6. NEWS
The news URL scheme is used to refer to either news groups or
individual articles of USENET news, as specified in RFC 1036.
A news URL takes one of two forms:
news:
news:
A is a period-delimited hierarchical name, such as
"comp.infosystems.www.misc". A corresponds to the
Message-ID of section 2.1.5 of RFC 1036, without the enclosing "<"
and ">"; it takes the form @. A message
identifier may be distinguished from a news group name by the
presence of the commercial at "@" character. No additional characters
are reserved within the components of a news URL.
If is "*" (as in ), it is used to refer
to "all available news groups".
The news URLs are unusual in that by themselves, they do not contain
sufficient information to locate a single resource, but, rather, are
location-independent.
3.7. NNTP
The nntp URL scheme is an alternative method of referencing news
articles, useful for specifying news articles from NNTP servers (RFC
977).
A nntp URL take the form:
nntp://://
where and are as described in Section 3.1. If :
is omitted, the port defaults to 119.
The is the name of the group, while the is the numeric id of the article within that newsgroup.
Note that while nntp: URLs specify a unique location for the article
resource, most NNTP servers currently on the Internet today are
configured only to allow access from local clients, and thus nntp
URLs do not designate globally accessible resources. Thus, the news:
form of URL is preferred as a way of identifying news articles.
Berners-Lee, Masinter & McCahill [Page 13]
RFC 1738 Uniform Resource Locators (URL) December 1994
3.8. TELNET
The Telnet URL scheme is used to designate interactive services that
may be accessed by the Telnet protocol.
A telnet URL takes the form:
telnet://:@:/
as specified in Section 3.1. The final "/" character may be omitted.
If : is omitted, the port defaults to 23. The : can
be omitted, as well as the whole : part.
This URL does not designate a data object, but rather an interactive
service. Remote interactive services vary widely in the means by
which they allow remote logins; in practice, the and
supplied are advisory only: clients accessing a telnet URL
merely advise the user of the suggested username and password.
3.9. WAIS
The WAIS URL scheme is used to designate WAIS databases, searches, or
individual documents available from a WAIS database. WAIS is
described in [7]. The WAIS protocol is described in RFC 1625 [17];
Although the WAIS protocol is based on Z39.50-1988, the WAIS URL
scheme is not intended for use with arbitrary Z39.50 services.
A WAIS URL takes one of the following forms:
wais://:/
wais://:/?
wais://:///
where and are as described in Section 3.1. If :
is omitted, the port defaults to 210. The first form designates a
WAIS database that is available for searching. The second form
designates a particular search. is the name of the WAIS
database being queried.
The third form designates a particular document within a WAIS
database to be retrieved. In this form is the WAIS
designation of the type of the object. Many WAIS implementations
require that a client know the "type" of an object prior to
retrieval, the type being returned along with the internal object
identifier in the search response. The is included in the
URL in order to allow the client interpreting the URL adequate
information to actually retrieve the document.
Berners-Lee, Masinter & McCahill [Page 14]
RFC 1738 Uniform Resource Locators (URL) December 1994
The of a WAIS URL consists of the WAIS document-id, encoded
as necessary using the method described in Section 2.2. The WAIS
document-id should be treated opaquely; it may only be decomposed by
the server that issued it.
3.10 FILES
The file URL scheme is used to designate files accessible on a
particular host computer. This scheme, unlike most other URL schemes,
does not designate a resource that is universally accessible over the
Internet.
A file URL takes the form:
file:///
where is the fully qualified domain name of the system on
which the is accessible, and is a hierarchical
directory path of the form //.../.
For example, a VMS file
DISK$USER:[MY.NOTES]NOTE123456.TXT
might become
As a special case, can be the string "localhost" or the empty
string; this is interpreted as `the machine from which the URL is
being interpreted'.
The file URL scheme is unusual in that it does not specify an
Internet protocol or access method for such files; as such, its
utility in network protocols between hosts is limited.
3.11 PROSPERO
The Prospero URL scheme is used to designate resources that are
accessed via the Prospero Directory Service. The Prospero protocol is
described elsewhere [14].
A prospero URLs takes the form:
prospero://:/;=
where and are as described in Section 3.1. If :
is omitted, the port defaults to 1525. No username or password is
Berners-Lee, Masinter & McCahill [Page 15]
RFC 1738 Uniform Resource Locators (URL) December 1994
allowed.
The is the host-specific object name in the Prospero
protocol, suitably encoded. This name is opaque and interpreted by
the Prospero server. The semicolon ";" is reserved and may not
appear without quoting in the .
Prospero URLs are interpreted by contacting a Prospero directory
server on the specified host and port to determine appropriate access
methods for a resource, which might themselves be represented as
different URLs. External Prospero links are represented as URLs of
the underlying access method and are not represented as Prospero
URLs.
Note that a slash "/" may appear in the without quoting and
no significance may be assumed by the application. Though slashes
may indicate hierarchical structure on the server, such structure is
not guaranteed. Note that many s begin with a slash, in
which case the host or port will be followed by a double slash: the
slash from the URL syntax, followed by the initial slash from the
. (E.g., designates a
of "/pros/name".)
In addition, after the , optional fields and values
associated with a Prospero link may be specified as part of the URL.
When present, each field/value pair is separated from each other and
from the rest of the URL by a ";" (semicolon). The name of the field
and its value are separated by a "=" (equal sign). If present, these
fields serve to identify the target of the URL. For example, the
OBJECT-VERSION field can be specified to identify a specific version
of an object.
4. REGISTRATION OF NEW SCHEMES
A new scheme may be introduced by defining a mapping onto a
conforming URL syntax, using a new prefix. URLs for experimental
schemes may be used by mutual agreement between parties. Scheme names
starting with the characters "x-" are reserved for experimental
purposes.
The Internet Assigned Numbers Authority (IANA) will maintain a
registry of URL schemes. Any submission of a new URL scheme must
include a definition of an algorithm for accessing of resources
within that scheme and the syntax for representing such a scheme.
URL schemes must have demonstrable utility and operability. One way
to provide such a demonstration is via a gateway which provides
objects in the new scheme for clients using an existing protocol. If
Berners-Lee, Masinter & McCahill [Page 16]
RFC 1738 Uniform Resource Locators (URL) December 1994
the new scheme does not locate resources that are data objects, the
properties of names in the new space must be clearly defined.
New schemes should try to follow the same syntactic conventions of
existing schemes, where appropriate. It is likewise recommended
that, where a protocol allows for retrieval by URL, that the client
software have provision for being configured to use specific gateway
locators for indirect access through new naming schemes.
The following scheme have been proposed at various times, but this
document does not define their syntax or use at this time. It is
suggested that IANA reserve their scheme names for future definition:
afs Andrew File System global file names.
mid Message identifiers for electronic mail.
cid Content identifiers for MIME body parts.
nfs Network File System (NFS) file names.
tn3270 Interactive 3270 emulation sessions.
mailserver Access to data available from mail servers.
z39.50 Access to ANSI Z39.50 services.
5. BNF for specific URL schemes
This is a BNF-like description of the Uniform Resource Locator
syntax, using the conventions of RFC822, except that "|" is used to
designate alternatives, and brackets [] are used around optional or
repeated elements. Briefly, literals are quoted with "", optional
elements are enclosed in [brackets], and elements may be preceded
with * to designate n or more repetitions of the following
element; n defaults to 0.
; The generic form of a URL is:
genericurl = scheme ":" schemepart
; Specific predefined schemes are defined here; new schemes
; may be registered with IANA
url = httpurl | ftpurl | newsurl |
nntpurl | telneturl | gopherurl |
waisurl | mailtourl | fileurl |
prosperourl | otherurl
; new schemes follow the general syntax
otherurl = genericurl
; the scheme is in lower case; interpreters should use case-ignore
scheme = 1*[ lowalpha | digit | "+" | "-" | "." ]
Berners-Lee, Masinter & McCahill [Page 17]
RFC 1738 Uniform Resource Locators (URL) December 1994
schemepart = *xchar | ip-schemepart
; URL schemeparts for ip based protocols:
ip-schemepart = "//" login [ "/" urlpath ]
login = [ user [ ":" password ] "@" ] hostport
hostport = host [ ":" port ]
host = hostname | hostnumber
hostname = *[ domainlabel "." ] toplabel
domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit
toplabel = alpha | alpha *[ alphadigit | "-" ] alphadigit
alphadigit = alpha | digit
hostnumber = digits "." digits "." digits "." digits
port = digits
user = *[ uchar | ";" | "?" | "&" | "=" ]
password = *[ uchar | ";" | "?" | "&" | "=" ]
urlpath = *xchar ; depends on protocol see section 3.1
; The predefined schemes:
; FTP (see also RFC959)
ftpurl = "ftp://" login [ "/" fpath [ ";type=" ftptype ]]
fpath = fsegment *[ "/" fsegment ]
fsegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ]
ftptype = "A" | "I" | "D" | "a" | "i" | "d"
; FILE
fileurl = "file://" [ host | "localhost" ] "/" fpath
; HTTP
httpurl = "http://" hostport [ "/" hpath [ "?" search ]]
hpath = hsegment *[ "/" hsegment ]
hsegment = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
search = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
; GOPHER (see also RFC1436)
gopherurl = "gopher://" hostport [ / [ gtype [ selector
[ "%09" search [ "%09" gopher+_string ] ] ] ] ]
gtype = xchar
selector = *xchar
gopher+_string = *xchar
Berners-Lee, Masinter & McCahill [Page 18]
RFC 1738 Uniform Resource Locators (URL) December 1994
; MAILTO (see also RFC822)
mailtourl = "mailto:" encoded822addr
encoded822addr = 1*xchar ; further defined in RFC822
; NEWS (see also RFC1036)
newsurl = "news:" grouppart
grouppart = "*" | group | article
group = alpha *[ alpha | digit | "-" | "." | "+" | "_" ]
article = 1*[ uchar | ";" | "/" | "?" | ":" | "&" | "=" ] "@" host
; NNTP (see also RFC977)
nntpurl = "nntp://" hostport "/" group [ "/" digits ]
; TELNET
telneturl = "telnet://" login [ "/" ]
; WAIS (see also RFC1625)
waisurl = waisdatabase | waisindex | waisdoc
waisdatabase = "wais://" hostport "/" database
waisindex = "wais://" hostport "/" database "?" search
waisdoc = "wais://" hostport "/" database "/" wtype "/" wpath
database = *uchar
wtype = *uchar
wpath = *uchar
; PROSPERO
prosperourl = "prospero://" hostport "/" ppath *[ fieldspec ]
ppath = psegment *[ "/" psegment ]
psegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ]
fieldspec = ";" fieldname "=" fieldvalue
fieldname = *[ uchar | "?" | ":" | "@" | "&" ]
fieldvalue = *[ uchar | "?" | ":" | "@" | "&" ]
; Miscellaneous definitions
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
"i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
"q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
"y" | "z"
hialpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
Berners-Lee, Masinter & McCahill [Page 19]
RFC 1738 Uniform Resource Locators (URL) December 1994
alpha = lowalpha | hialpha
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
safe = "$" | "-" | "_" | "." | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
national = "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`"
punctuation = "<" | ">" | "#" | "%" | <">
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "="
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f"
escape = "%" hex hex
unreserved = alpha | digit | safe | extra
uchar = unreserved | escape
xchar = unreserved | reserved | escape
digits = 1*digit
6. Security Considerations
The URL scheme does not in itself pose a security threat. Users
should beware that there is no general guarantee that a URL which at
one time points to a given object continues to do so, and does not
even at some later time point to a different object due to the
movement of objects on servers.
A URL-related security threat is that it is sometimes possible to
construct a URL such that an attempt to perform a harmless idempotent
operation such as the retrieval of the object will in fact cause a
possibly damaging 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 server which is in fact running a different
protocol. The content of the URL contains instructions which when
interpreted according to this other protocol cause an unexpected
operation. An example has been the use of gopher URLs to cause a rude
message to be sent via a SMTP server. Caution should be used when
using any URL which 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 URLs contain embedded encoded delimiters
for a given protocol (for example, CR and LF characters for telnet
protocols) that these are not unencoded before transmission. This
would violate the protocol but could be used to simulate an extra
operation or parameter, again causing an unexpected and possible
harmful remote operation to be performed.
Berners-Lee, Masinter & McCahill [Page 20]
RFC 1738 Uniform Resource Locators (URL) December 1994
The use of URLs containing passwords that should be secret is clearly
unwise.
7. Acknowledgements
This paper builds on the basic WWW design (RFC 1630) and much
discussion of these issues by many people on the network. The
discussion was particularly stimulated by articles by Clifford Lynch,
Brewster Kahle [10] and Wengyik Yeong [18]. Contributions from John
Curran, Clifford Neuman, Ed Vielmetti and later the IETF URL BOF and
URI working group were incorporated.
Most recently, careful readings and comments by Dan Connolly, Ned
Freed, Roy Fielding, Guido van Rossum, Michael Dolan, Bert Bos, John
Kunze, Olle Jarnefors, Peter Svanberg and many others have helped
refine this RFC.
Berners-Lee, Masinter & McCahill [Page 21]
RFC 1738 Uniform Resource Locators (URL) December 1994
APPENDIX: Recommendations for URLs in Context
URIs, including URLs, are intended to be transmitted through
protocols which provide a context for their interpretation.
In some cases, it will be necessary to distinguish URLs from other
possible data structures in a syntactic structure. In this case, is
recommended that URLs be preceeded with a prefix consisting of the
characters "URL:". For example, this prefix may be used to
distinguish URLs from other kinds of URIs.
In addition, there are many occasions when URLs are included in other
kinds of text; examples include electronic mail, USENET news
messages, or printed on paper. In such cases, it is convenient to
have a separate syntactic wrapper that delimits the URL and separates
it from the rest of the text, and in particular from punctuation
marks that might be mistaken for part of the URL. For this purpose,
is recommended that angle brackets ("<" and ">"), along with the
prefix "URL:", be used to delimit the boundaries of the URL. This
wrapper does not form part of the URL and should not be used in
contexts in which delimiters are already specified.
In the case where a fragment/anchor identifier is associated with a
URL (following a "#"), the identifier would be placed within the
brackets as well.
In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may
need to be added to break long URLs across lines. The whitespace
should be ignored when extracting the URL.
No whitespace should be introduced after a hyphen ("-") character.
Because some typesetters and printers may (erroneously) introduce a
hyphen at the end of line when breaking a line, the interpreter of a
URL containing a line break immediately after a hyphen should ignore
all unencoded whitespace around the line break, and should be aware
that the hyphen may or may not actually be part of the URL.
Examples:
Yes, Jim, I found it under but you can probably pick it up from . Note the warning in .
Berners-Lee, Masinter & McCahill [Page 22]
RFC 1738 Uniform Resource Locators (URL) December 1994
References
[1] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., and B. Alberti, "The Internet Gopher Protocol
(a distributed document search and retrieval protocol)",
RFC 1436, University of Minnesota, March 1993.
[2] Anklesaria, F., Lindner, P., McCahill, M., Torrey, D.,
Johnson, D., and B. Alberti, "Gopher+: Upward compatible
enhancements to the Internet Gopher protocol",
University of Minnesota, July 1993.
[3] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
Unifying Syntax for the Expression of Names and Addresses of
Objects on the Network as used in the World-Wide Web", RFC
1630, CERN, June 1994.
[4] Berners-Lee, T., "Hypertext Transfer Protocol (HTTP)",
CERN, November 1993.
[5] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, IETF, October 1989.
[6] Crocker, D. "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, April 1982.
[7] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype
Functional Specification", (v1.5), Thinking Machines
Corporation, April 1990.
[8] Horton, M. and R. Adams, "Standard For Interchange of USENET
Messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic
Studies, December 1987.
[9] Huitema, C., "Naming: Strategies and Techniques", Computer
Networks and ISDN Systems 23 (1991) 107-110.
Berners-Lee, Masinter & McCahill [Page 23]
RFC 1738 Uniform Resource Locators (URL) December 1994
[10] Kahle, B., "Document Identifiers, or International Standard
Book Numbers for the Electronic Age", 1991.
[11] Kantor, B. and P. Lapsley, "Network News Transfer Protocol:
A Proposed Standard for the Stream-Based Transmission of News",
RFC 977, UC San Diego & UC Berkeley, February 1986.
[12] Kunze, J., "Functional Requirements for Internet Resource
Locators", Work in Progress, December 1994.
[13] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, USC/Information Sciences Institute,
November 1987.
[14] Neuman, B., and S. Augart, "The Prospero Protocol",
USC/Information Sciences Institute, June 1993.
[15] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)",
STD 9, RFC 959, USC/Information Sciences Institute,
October 1985.
[16] Sollins, K. and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation,
December 1994.
[17] St. Pierre, M, Fullton, J., Gamiel, K., Goldman, J., Kahle, B.,
Kunze, J., Morris, H., and F. Schiettecatte, "WAIS over
Z39.50-1988", RFC 1625, WAIS, Inc., CNIDR, Thinking Machines
Corp., UC Berkeley, FS Consulting, June 1994.
[18] Yeong, W. "Towards Networked Information Retrieval", Technical
report 91-06-25-01, Performance Systems International, Inc.
, June 1991.
[19] Yeong, W., "Representing Public Archives in the Directory",
Work in Progress, November 1991.
Berners-Lee, Masinter & McCahill [Page 24]
RFC 1738 Uniform Resource Locators (URL) December 1994
[20] "Coded Character Set -- 7-bit American Standard Code for
Information Interchange", ANSI X3.4-1986.
Editors' Addresses
Tim Berners-Lee
World-Wide Web project
CERN,
1211 Geneva 23,
Switzerland
Phone: +41 (22)767 3755
Fax: +41 (22)767 7155
EMail: timbl@info.cern.ch
Larry Masinter
Xerox PARC
3333 Coyote Hill Road
Palo Alto, CA 94034
Phone: (415) 812-4365
Fax: (415) 812-4333
EMail: masinter@parc.xerox.com
Mark McCahill
Computer and Information Services,
University of Minnesota
Room 152 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
Phone: (612) 625 1300
EMail: mpm@boombox.micro.umn.edu
Berners-Lee, Masinter & McCahill [Page 25]
ascript-build016/doc/reference/rfc3986.txt 777 0 0 424763 11423230515 13531 0
Network Working Group T. Berners-Lee
Request for Comments: 3986 W3C/MIT
STD: 66 R. Fielding
Updates: 1738 Day Software
Obsoletes: 2732, 2396, 1808 L. Masinter
Category: Standards Track Adobe Systems
January 2005
Uniform Resource Identifier (URI): Generic Syntax
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
A Uniform Resource Identifier (URI) is a compact sequence of
characters that identifies an abstract or physical resource. This
specification defines the generic URI syntax and a process for
resolving URI references that might be in relative form, along with
guidelines and security considerations for the use of URIs on the
Internet. The URI syntax defines a grammar that is a superset of all
valid URIs, allowing an implementation to parse the common components
of a URI reference without knowing the scheme-specific requirements
of every possible identifier. This specification does not define a
generative grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
Berners-Lee, et al. Standards Track [Page 1]
RFC 3986 URI Generic Syntax January 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overview of URIs . . . . . . . . . . . . . . . . . . . . 4
1.1.1. Generic Syntax . . . . . . . . . . . . . . . . . 6
1.1.2. Examples . . . . . . . . . . . . . . . . . . . . 7
1.1.3. URI, URL, and URN . . . . . . . . . . . . . . . 7
1.2. Design Considerations . . . . . . . . . . . . . . . . . 8
1.2.1. Transcription . . . . . . . . . . . . . . . . . 8
1.2.2. Separating Identification from Interaction . . . 9
1.2.3. Hierarchical Identifiers . . . . . . . . . . . . 10
1.3. Syntax Notation . . . . . . . . . . . . . . . . . . . . 11
2. Characters . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1. Percent-Encoding . . . . . . . . . . . . . . . . . . . . 12
2.2. Reserved Characters . . . . . . . . . . . . . . . . . . 12
2.3. Unreserved Characters . . . . . . . . . . . . . . . . . 13
2.4. When to Encode or Decode . . . . . . . . . . . . . . . . 14
2.5. Identifying Data . . . . . . . . . . . . . . . . . . . . 14
3. Syntax Components . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Scheme . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Authority . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1. User Information . . . . . . . . . . . . . . . . 18
3.2.2. Host . . . . . . . . . . . . . . . . . . . . . . 18
3.2.3. Port . . . . . . . . . . . . . . . . . . . . . . 22
3.3. Path . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4. Query . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5. Fragment . . . . . . . . . . . . . . . . . . . . . . . . 24
4. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1. URI Reference . . . . . . . . . . . . . . . . . . . . . 25
4.2. Relative Reference . . . . . . . . . . . . . . . . . . . 26
4.3. Absolute URI . . . . . . . . . . . . . . . . . . . . . . 27
4.4. Same-Document Reference . . . . . . . . . . . . . . . . 27
4.5. Suffix Reference . . . . . . . . . . . . . . . . . . . . 27
5. Reference Resolution . . . . . . . . . . . . . . . . . . . . . 28
5.1. Establishing a Base URI . . . . . . . . . . . . . . . . 28
5.1.1. Base URI Embedded in Content . . . . . . . . . . 29
5.1.2. Base URI from the Encapsulating Entity . . . . . 29
5.1.3. Base URI from the Retrieval URI . . . . . . . . 30
5.1.4. Default Base URI . . . . . . . . . . . . . . . . 30
5.2. Relative Resolution . . . . . . . . . . . . . . . . . . 30
5.2.1. Pre-parse the Base URI . . . . . . . . . . . . . 31
5.2.2. Transform References . . . . . . . . . . . . . . 31
5.2.3. Merge Paths . . . . . . . . . . . . . . . . . . 32
5.2.4. Remove Dot Segments . . . . . . . . . . . . . . 33
5.3. Component Recomposition . . . . . . . . . . . . . . . . 35
5.4. Reference Resolution Examples . . . . . . . . . . . . . 35
5.4.1. Normal Examples . . . . . . . . . . . . . . . . 36
5.4.2. Abnormal Examples . . . . . . . . . . . . . . . 36
Berners-Lee, et al. Standards Track [Page 2]
RFC 3986 URI Generic Syntax January 2005
6. Normalization and Comparison . . . . . . . . . . . . . . . . . 38
6.1. Equivalence . . . . . . . . . . . . . . . . . . . . . . 38
6.2. Comparison Ladder . . . . . . . . . . . . . . . . . . . 39
6.2.1. Simple String Comparison . . . . . . . . . . . . 39
6.2.2. Syntax-Based Normalization . . . . . . . . . . . 40
6.2.3. Scheme-Based Normalization . . . . . . . . . . . 41
6.2.4. Protocol-Based Normalization . . . . . . . . . . 42
7. Security Considerations . . . . . . . . . . . . . . . . . . . 43
7.1. Reliability and Consistency . . . . . . . . . . . . . . 43
7.2. Malicious Construction . . . . . . . . . . . . . . . . . 43
7.3. Back-End Transcoding . . . . . . . . . . . . . . . . . . 44
7.4. Rare IP Address Formats . . . . . . . . . . . . . . . . 45
7.5. Sensitive Information . . . . . . . . . . . . . . . . . 45
7.6. Semantic Attacks . . . . . . . . . . . . . . . . . . . . 45
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.1. Normative References . . . . . . . . . . . . . . . . . . 46
10.2. Informative References . . . . . . . . . . . . . . . . . 47
A. Collected ABNF for URI . . . . . . . . . . . . . . . . . . . . 49
B. Parsing a URI Reference with a Regular Expression . . . . . . 50
C. Delimiting a URI in Context . . . . . . . . . . . . . . . . . 51
D. Changes from RFC 2396 . . . . . . . . . . . . . . . . . . . . 53
D.1. Additions . . . . . . . . . . . . . . . . . . . . . . . 53
D.2. Modifications . . . . . . . . . . . . . . . . . . . . . 53
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 61
Berners-Lee, et al. Standards Track [Page 3]
RFC 3986 URI Generic Syntax January 2005
1. Introduction
A Uniform Resource Identifier (URI) provides a simple and extensible
means for identifying a resource. This specification of URI syntax
and semantics is derived from concepts introduced by the World Wide
Web global information initiative, whose use of these identifiers
dates from 1990 and is described in "Universal Resource Identifiers
in WWW" [RFC1630]. The syntax is designed to meet the
recommendations laid out in "Functional Recommendations for Internet
Resource Locators" [RFC1736] and "Functional Requirements for Uniform
Resource Names" [RFC1737].
This document obsoletes [RFC2396], which merged "Uniform Resource
Locators" [RFC1738] and "Relative Uniform Resource Locators"
[RFC1808] in order to define a single, generic syntax for all URIs.
It obsoletes [RFC2732], which introduced syntax for an IPv6 address.
It excludes portions of RFC 1738 that defined the specific syntax of
individual URI schemes; those portions will be updated as separate
documents. The process for registration of new URI schemes is
defined separately by [BCP35]. Advice for designers of new URI
schemes can be found in [RFC2718]. All significant changes from RFC
2396 are noted in Appendix D.
This specification uses the terms "character" and "coded character
set" in accordance with the definitions provided in [BCP19], and
"character encoding" in place of what [BCP19] refers to as a
"charset".
1.1. Overview of URIs
URIs are characterized as follows:
Uniform
Uniformity provides several benefits. It allows different types
of resource identifiers to be used in the same context, even when
the mechanisms used to access those resources may differ. It
allows uniform semantic interpretation of common syntactic
conventions across different types of resource identifiers. It
allows introduction of new types of resource identifiers without
interfering with the way that existing identifiers are used. It
allows the identifiers to be reused in many different contexts,
thus permitting new applications or protocols to leverage a pre-
existing, large, and widely used set of resource identifiers.
Berners-Lee, et al. Standards Track [Page 4]
RFC 3986 URI Generic Syntax January 2005
Resource
This specification does not limit the scope of what might be a
resource; rather, the term "resource" is used in a general sense
for whatever might be identified by a URI. Familiar examples
include an electronic document, an image, a source of information
with a consistent purpose (e.g., "today's weather report for Los
Angeles"), a service (e.g., an HTTP-to-SMS gateway), and a
collection of other resources. A resource is not necessarily
accessible via the Internet; e.g., human beings, corporations, and
bound books in a library can also be resources. Likewise,
abstract concepts can be resources, such as the operators and
operands of a mathematical equation, the types of a relationship
(e.g., "parent" or "employee"), or numeric values (e.g., zero,
one, and infinity).
Identifier
An identifier embodies the information required to distinguish
what is being identified from all other things within its scope of
identification. Our use of the terms "identify" and "identifying"
refer to this purpose of distinguishing one resource from all
other resources, regardless of how that purpose is accomplished
(e.g., by name, address, or context). These terms should not be
mistaken as an assumption that an identifier defines or embodies
the identity of what is referenced, though that may be the case
for some identifiers. Nor should it be assumed that a system
using URIs will access the resource identified: in many cases,
URIs are used to denote resources without any intention that they
be accessed. Likewise, the "one" resource identified might not be
singular in nature (e.g., a resource might be a named set or a
mapping that varies over time).
A URI is an identifier consisting of a sequence of characters
matching the syntax rule named in Section 3. It enables
uniform identification of resources via a separately defined
extensible set of naming schemes (Section 3.1). How that
identification is accomplished, assigned, or enabled is delegated to
each scheme specification.
This specification does not place any limits on the nature of a
resource, the reasons why an application might seek to refer to a
resource, or the kinds of systems that might use URIs for the sake of
identifying resources. This specification does not require that a
URI persists in identifying the same resource over time, though that
is a common goal of all URI schemes. Nevertheless, nothing in this
Berners-Lee, et al. Standards Track [Page 5]
RFC 3986 URI Generic Syntax January 2005
specification prevents an application from limiting itself to
particular types of resources, or to a subset of URIs that maintains
characteristics desired by that application.
URIs have a global scope and are interpreted consistently regardless
of context, though the result of that interpretation may be in
relation to the end-user's context. For example, "http://localhost/"
has the same interpretation for every user of that reference, even
though the network interface corresponding to "localhost" may be
different for each end-user: interpretation is independent of access.
However, an action made on the basis of that reference will take
place in relation to the end-user's context, which implies that an
action intended to refer to a globally unique thing must use a URI
that distinguishes that resource from all other things. URIs that
identify in relation to the end-user's local context should only be
used when the context itself is a defining aspect of the resource,
such as when an on-line help manual refers to a file on the end-
user's file system (e.g., "file:///etc/hosts").
1.1.1. Generic Syntax
Each URI begins with a scheme name, as defined in Section 3.1, that
refers to a specification for assigning identifiers within that
scheme. As such, the URI syntax is a federated and extensible naming
system wherein each scheme's specification may further restrict the
syntax and semantics of identifiers using that scheme.
This specification defines those elements of the URI syntax that are
required of all URI schemes or are common to many URI schemes. It
thus defines the syntax and semantics needed to implement a scheme-
independent parsing mechanism for URI references, by which the
scheme-dependent handling of a URI can be postponed until the
scheme-dependent semantics are needed. Likewise, protocols and data
formats that make use of URI references can refer to this
specification as a definition for the range of syntax allowed for all
URIs, including those schemes that have yet to be defined. This
decouples the evolution of identification schemes from the evolution
of protocols, data formats, and implementations that make use of
URIs.
A parser of the generic URI syntax can parse any URI reference into
its major components. Once the scheme is determined, further
scheme-specific parsing can be performed on the components. In other
words, the URI generic syntax is a superset of the syntax of all URI
schemes.
Berners-Lee, et al. Standards Track [Page 6]
RFC 3986 URI Generic Syntax January 2005
1.1.2. Examples
The following example URIs illustrate several URI schemes and
variations in their common syntax components:
ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc2396.txt
ldap://[2001:db8::7]/c=GB?objectClass?one
mailto:John.Doe@example.com
news:comp.infosystems.www.servers.unix
tel:+1-816-555-1212
telnet://192.0.2.16:80/
urn:oasis:names:specification:docbook:dtd:xml:4.1.2
1.1.3. URI, URL, and URN
A URI can be further classified as a locator, a name, or both. The
term "Uniform Resource Locator" (URL) refers to the subset of URIs
that, in addition to identifying a resource, provide a means of
locating the resource by describing its primary access mechanism
(e.g., its network "location"). The term "Uniform Resource Name"
(URN) has been used historically to refer to both URIs under the
"urn" scheme [RFC2141], which are required to remain globally unique
and persistent even when the resource ceases to exist or becomes
unavailable, and to any other URI with the properties of a name.
An individual scheme does not have to be classified as being just one
of "name" or "locator". Instances of URIs from any given scheme may
have the characteristics of names or locators or both, often
depending on the persistence and care in the assignment of
identifiers by the naming authority, rather than on any quality of
the scheme. Future specifications and related documentation should
use the general term "URI" rather than the more restrictive terms
"URL" and "URN" [RFC3305].
Berners-Lee, et al. Standards Track [Page 7]
RFC 3986 URI Generic Syntax January 2005
1.2. Design Considerations
1.2.1. Transcription
The URI syntax has been designed with global transcription as one of
its main considerations. A URI is a sequence of characters from a
very limited set: the letters of the basic Latin alphabet, digits,
and a few special characters. A URI may be represented in a variety
of ways; e.g., ink on paper, pixels on a screen, or a sequence of
character encoding octets. The interpretation of a URI depends only
on the characters used and not on how those characters are
represented in a network protocol.
The goal of transcription can be described by a simple scenario.
Imagine two colleagues, Sam and Kim, sitting in a pub at an
international conference and exchanging research ideas. Sam asks Kim
for a location to get more information, so Kim writes the URI for the
research site on a napkin. Upon returning home, Sam takes out the
napkin and types the URI into a computer, which then retrieves the
information to which Kim referred.
There are several design considerations revealed by the scenario:
o A URI is a sequence of characters that is not always represented
as a sequence of octets.
o A URI might be transcribed from a non-network source and thus
should consist of characters that are most likely able to be
entered into a computer, within the constraints imposed by
keyboards (and related input devices) across languages and
locales.
o A URI often has to be remembered by people, and it is easier for
people to remember a URI when it consists of meaningful or
familiar components.
These design considerations are not always in alignment. For
example, it is often the case that the most meaningful name for a URI
component would require characters that cannot be typed into some
systems. The ability to transcribe a resource identifier from one
medium to another has been considered more important than having a
URI consist of the most meaningful of components.
In local or regional contexts and with improving technology, users
might benefit from being able to use a wider range of characters;
such use is not defined by this specification. Percent-encoded
octets (Section 2.1) may be used within a URI to represent characters
outside the range of the US-ASCII coded character set if this
Berners-Lee, et al. Standards Track [Page 8]
RFC 3986 URI Generic Syntax January 2005
representation is allowed by the scheme or by the protocol element in
which the URI is referenced. Such a definition should specify the
character encoding used to map those characters to octets prior to
being percent-encoded for the URI.
1.2.2. Separating Identification from Interaction
A common misunderstanding of URIs is that they are only used to refer
to accessible resources. The URI itself only provides
identification; access to the resource is neither guaranteed nor
implied by the presence of a URI. Instead, any operation associated
with a URI reference is defined by the protocol element, data format
attribute, or natural language text in which it appears.
Given a URI, a system may attempt to perform a variety of operations
on the resource, as might be characterized by words such as "access",
"update", "replace", or "find attributes". Such operations are
defined by the protocols that make use of URIs, not by this
specification. However, we do use a few general terms for describing
common operations on URIs. URI "resolution" is the process of
determining an access mechanism and the appropriate parameters
necessary to dereference a URI; this resolution may require several
iterations. To use that access mechanism to perform an action on the
URI's resource is to "dereference" the URI.
When URIs are used within information retrieval systems to identify
sources of information, the most common form of URI dereference is
"retrieval": making use of a URI in order to retrieve a
representation of its associated resource. A "representation" is a
sequence of octets, along with representation metadata describing
those octets, that constitutes a record of the state of the resource
at the time when the representation is generated. Retrieval is
achieved by a process that might include using the URI as a cache key
to check for a locally cached representation, resolution of the URI
to determine an appropriate access mechanism (if any), and
dereference of the URI for the sake of applying a retrieval
operation. Depending on the protocols used to perform the retrieval,
additional information might be supplied about the resource (resource
metadata) and its relation to other resources.
URI references in information retrieval systems are designed to be
late-binding: the result of an access is generally determined when it
is accessed and may vary over time or due to other aspects of the
interaction. These references are created in order to be used in the
future: what is being identified is not some specific result that was
obtained in the past, but rather some characteristic that is expected
to be true for future results. In such cases, the resource referred
to by the URI is actually a sameness of characteristics as observed
Berners-Lee, et al. Standards Track [Page 9]
RFC 3986 URI Generic Syntax January 2005
over time, perhaps elucidated by additional comments or assertions
made by the resource provider.
Although many URI schemes are named after protocols, this does not
imply that use of these URIs will result in access to the resource
via the named protocol. URIs are often used simply for the sake of
identification. Even when a URI is used to retrieve a representation
of a resource, that access might be through gateways, proxies,
caches, and name resolution services that are independent of the
protocol associated with the scheme name. The resolution of some
URIs may require the use of more than one protocol (e.g., both DNS
and HTTP are typically used to access an "http" URI's origin server
when a representation isn't found in a local cache).
1.2.3. Hierarchical Identifiers
The URI syntax is organized hierarchically, with components listed in
order of decreasing significance from left to right. For some URI
schemes, the visible hierarchy is limited to the scheme itself:
everything after the scheme component delimiter (":") is considered
opaque to URI processing. Other URI schemes make the hierarchy
explicit and visible to generic parsing algorithms.
The generic syntax uses the slash ("/"), question mark ("?"), and
number sign ("#") characters to delimit components that are
significant to the generic parser's hierarchical interpretation of an
identifier. In addition to aiding the readability of such
identifiers through the consistent use of familiar syntax, this
uniform representation of hierarchy across naming schemes allows
scheme-independent references to be made relative to that hierarchy.
It is often the case that a group or "tree" of documents has been
constructed to serve a common purpose, wherein the vast majority of
URI references in these documents point to resources within the tree
rather than outside it. Similarly, documents located at a particular
site are much more likely to refer to other resources at that site
than to resources at remote sites. Relative referencing of URIs
allows document trees to be partially independent of their location
and access scheme. For instance, it is possible for a single set of
hypertext documents to be simultaneously accessible and traversable
via each of the "file", "http", and "ftp" schemes if the documents
refer to each other with relative references. Furthermore, such
document trees can be moved, as a whole, without changing any of the
relative references.
A relative reference (Section 4.2) refers to a resource by describing
the difference within a hierarchical name space between the reference
context and the target URI. The reference resolution algorithm,
Berners-Lee, et al. Standards Track [Page 10]
RFC 3986 URI Generic Syntax January 2005
presented in Section 5, defines how such a reference is transformed
to the target URI. As relative references can only be used within
the context of a hierarchical URI, designers of new URI schemes
should use a syntax consistent with the generic syntax's hierarchical
components unless there are compelling reasons to forbid relative
referencing within that scheme.
NOTE: Previous specifications used the terms "partial URI" and
"relative URI" to denote a relative reference to a URI. As some
readers misunderstood those terms to mean that relative URIs are a
subset of URIs rather than a method of referencing URIs, this
specification simply refers to them as relative references.
All URI references are parsed by generic syntax parsers when used.
However, because hierarchical processing has no effect on an absolute
URI used in a reference unless it contains one or more dot-segments
(complete path segments of "." or "..", as described in Section 3.3),
URI scheme specifications can define opaque identifiers by
disallowing use of slash characters, question mark characters, and
the URIs "scheme:." and "scheme:..".
1.3. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC2234], including the following core ABNF syntax rules
defined by that specification: ALPHA (letters), CR (carriage return),
DIGIT (decimal digits), DQUOTE (double quote), HEXDIG (hexadecimal
digits), LF (line feed), and SP (space). The complete URI syntax is
collected in Appendix A.
2. Characters
The URI syntax provides a method of encoding data, presumably for the
sake of identifying a resource, as a sequence of characters. The URI
characters are, in turn, frequently encoded as octets for transport
or presentation. This specification does not mandate any particular
character encoding for mapping between URI characters and the octets
used to store or transmit those characters. When a URI appears in a
protocol element, the character encoding is defined by that protocol;
without such a definition, a URI is assumed to be in the same
character encoding as the surrounding text.
The ABNF notation defines its terminal values to be non-negative
integers (codepoints) based on the US-ASCII coded character set
[ASCII]. Because a URI is a sequence of characters, we must invert
that relation in order to understand the URI syntax. Therefore, the
Berners-Lee, et al. Standards Track [Page 11]
RFC 3986 URI Generic Syntax January 2005
integer values used by the ABNF must be mapped back to their
corresponding characters via US-ASCII in order to complete the syntax
rules.
A URI is composed from a limited set of characters consisting of
digits, letters, and a few graphic symbols. A reserved subset of
those characters may be used to delimit syntax components within a
URI while the remaining characters, including both the unreserved set
and those reserved characters not acting as delimiters, define each
component's identifying data.
2.1. Percent-Encoding
A percent-encoding mechanism is used to represent a data octet in a
component when that octet's corresponding character is outside the
allowed set or is being used as a delimiter of, or within, the
component. A percent-encoded octet is encoded as a character
triplet, consisting of the percent character "%" followed by the two
hexadecimal digits representing that octet's numeric value. For
example, "%20" is the percent-encoding for the binary octet
"00100000" (ABNF: %x20), which in US-ASCII corresponds to the space
character (SP). Section 2.4 describes when percent-encoding and
decoding is applied.
pct-encoded = "%" HEXDIG HEXDIG
The uppercase hexadecimal digits 'A' through 'F' are equivalent to
the lowercase digits 'a' through 'f', respectively. If two URIs
differ only in the case of hexadecimal digits used in percent-encoded
octets, they are equivalent. For consistency, URI producers and
normalizers should use uppercase hexadecimal digits for all percent-
encodings.
2.2. Reserved Characters
URIs include components and subcomponents that are delimited by
characters in the "reserved" set. These characters are called
"reserved" because they may (or may not) be defined as delimiters by
the generic syntax, by each scheme-specific syntax, or by the
implementation-specific syntax of a URI's dereferencing algorithm.
If data for a URI component would conflict with a reserved
character's purpose as a delimiter, then the conflicting data must be
percent-encoded before the URI is formed.
Berners-Lee, et al. Standards Track [Page 12]
RFC 3986 URI Generic Syntax January 2005
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
The purpose of reserved characters is to provide a set of delimiting
characters that are distinguishable from other data within a URI.
URIs that differ in the replacement of a reserved character with its
corresponding percent-encoded octet are not equivalent. Percent-
encoding a reserved character, or decoding a percent-encoded octet
that corresponds to a reserved character, will change how the URI is
interpreted by most applications. Thus, characters in the reserved
set are protected from normalization and are therefore safe to be
used by scheme-specific and producer-specific algorithms for
delimiting data subcomponents within a URI.
A subset of the reserved characters (gen-delims) is used as
delimiters of the generic URI components described in Section 3. A
component's ABNF syntax rule will not use the reserved or gen-delims
rule names directly; instead, each syntax rule lists the characters
allowed within that component (i.e., not delimiting it), and any of
those characters that are also in the reserved set are "reserved" for
use as subcomponent delimiters within the component. Only the most
common subcomponents are defined by this specification; other
subcomponents may be defined by a URI scheme's specification, or by
the implementation-specific syntax of a URI's dereferencing
algorithm, provided that such subcomponents are delimited by
characters in the reserved set allowed within that component.
URI producing applications should percent-encode data octets that
correspond to characters in the reserved set unless these characters
are specifically allowed by the URI scheme to represent data in that
component. If a reserved character is found in a URI component and
no delimiting role is known for that character, then it must be
interpreted as representing the data octet corresponding to that
character's encoding in US-ASCII.
2.3. Unreserved Characters
Characters that are allowed in a URI but do not have a reserved
purpose are called unreserved. These include uppercase and lowercase
letters, decimal digits, hyphen, period, underscore, and tilde.
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
Berners-Lee, et al. Standards Track [Page 13]
RFC 3986 URI Generic Syntax January 2005
URIs that differ in the replacement of an unreserved character with
its corresponding percent-encoded US-ASCII octet are equivalent: they
identify the same resource. However, URI comparison implementations
do not always perform normalization prior to comparison (see Section
6). For consistency, percent-encoded octets in the ranges of ALPHA
(%41-%5A and %61-%7A), DIGIT (%30-%39), hyphen (%2D), period (%2E),
underscore (%5F), or tilde (%7E) should not be created by URI
producers and, when found in a URI, should be decoded to their
corresponding unreserved characters by URI normalizers.
2.4. When to Encode or Decode
Under normal circumstances, the only time when octets within a URI
are percent-encoded is during the process of producing the URI from
its component parts. This is when an implementation determines which
of the reserved characters are to be used as subcomponent delimiters
and which can be safely used as data. Once produced, a URI is always
in its percent-encoded form.
When a URI is dereferenced, the components and subcomponents
significant to the scheme-specific dereferencing process (if any)
must be parsed and separated before the percent-encoded octets within
those components can be safely decoded, as otherwise the data may be
mistaken for component delimiters. The only exception is for
percent-encoded octets corresponding to characters in the unreserved
set, which can be decoded at any time. For example, the octet
corresponding to the tilde ("~") character is often encoded as "%7E"
by older URI processing implementations; the "%7E" can be replaced by
"~" without changing its interpretation.
Because the percent ("%") character serves as the indicator for
percent-encoded octets, it must be percent-encoded as "%25" for that
octet to be used as data within a URI. Implementations must not
percent-encode or decode the same string more than once, as decoding
an already decoded string might lead to misinterpreting a percent
data octet as the beginning of a percent-encoding, or vice versa in
the case of percent-encoding an already percent-encoded string.
2.5. Identifying Data
URI characters provide identifying data for each of the URI
components, serving as an external interface for identification
between systems. Although the presence and nature of the URI
production interface is hidden from clients that use its URIs (and is
thus beyond the scope of the interoperability requirements defined by
this specification), it is a frequent source of confusion and errors
in the interpretation of URI character issues. Implementers have to
be aware that there are multiple character encodings involved in the
Berners-Lee, et al. Standards Track [Page 14]
RFC 3986 URI Generic Syntax January 2005
production and transmission of URIs: local name and data encoding,
public interface encoding, URI character encoding, data format
encoding, and protocol encoding.
Local names, such as file system names, are stored with a local
character encoding. URI producing applications (e.g., origin
servers) will typically use the local encoding as the basis for
producing meaningful names. The URI producer will transform the
local encoding to one that is suitable for a public interface and
then transform the public interface encoding into the restricted set
of URI characters (reserved, unreserved, and percent-encodings).
Those characters are, in turn, encoded as octets to be used as a
reference within a data format (e.g., a document charset), and such
data formats are often subsequently encoded for transmission over
Internet protocols.
For most systems, an unreserved character appearing within a URI
component is interpreted as representing the data octet corresponding
to that character's encoding in US-ASCII. Consumers of URIs assume
that the letter "X" corresponds to the octet "01011000", and even
when that assumption is incorrect, there is no harm in making it. A
system that internally provides identifiers in the form of a
different character encoding, such as EBCDIC, will generally perform
character translation of textual identifiers to UTF-8 [STD63] (or
some other superset of the US-ASCII character encoding) at an
internal interface, thereby providing more meaningful identifiers
than those resulting from simply percent-encoding the original
octets.
For example, consider an information service that provides data,
stored locally using an EBCDIC-based file system, to clients on the
Internet through an HTTP server. When an author creates a file with
the name "Laguna Beach" on that file system, the "http" URI
corresponding to that resource is expected to contain the meaningful
string "Laguna%20Beach". If, however, that server produces URIs by
using an overly simplistic raw octet mapping, then the result would
be a URI containing "%D3%81%87%A4%95%81@%C2%85%81%83%88". An
internal transcoding interface fixes this problem by transcoding the
local name to a superset of US-ASCII prior to producing the URI.
Naturally, proper interpretation of an incoming URI on such an
interface requires that percent-encoded octets be decoded (e.g.,
"%20" to SP) before the reverse transcoding is applied to obtain the
local name.
In some cases, the internal interface between a URI component and the
identifying data that it has been crafted to represent is much less
direct than a character encoding translation. For example, portions
of a URI might reflect a query on non-ASCII data, or numeric
Berners-Lee, et al. Standards Track [Page 15]
RFC 3986 URI Generic Syntax January 2005
coordinates on a map. Likewise, a URI scheme may define components
with additional encoding requirements that are applied prior to
forming the component and producing the URI.
When a new URI scheme defines a component that represents textual
data consisting of characters from the Universal Character Set [UCS],
the data should first be encoded as octets according to the UTF-8
character encoding [STD63]; then only those octets that do not
correspond to characters in the unreserved set should be percent-
encoded. For example, the character A would be represented as "A",
the character LATIN CAPITAL LETTER A WITH GRAVE would be represented
as "%C3%80", and the character KATAKANA LETTER A would be represented
as "%E3%82%A2".
3. Syntax Components
The generic URI syntax consists of a hierarchical sequence of
components referred to as the scheme, authority, path, query, and
fragment.
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
The scheme and path components are required, though the path may be
empty (no characters). When authority is present, the path must
either be empty or begin with a slash ("/") character. When
authority is not present, the path cannot begin with two slash
characters ("//"). These restrictions result in five different ABNF
rules for a path (Section 3.3), only one of which will match any
given URI reference.
The following are two example URIs and their component parts:
foo://example.com:8042/over/there?name=ferret#nose
\_/ \______________/\_________/ \_________/ \__/
| | | | |
scheme authority path query fragment
| _____________________|__
/ \ / \
urn:example:animal:ferret:nose
Berners-Lee, et al. Standards Track [Page 16]
RFC 3986 URI Generic Syntax January 2005
3.1. Scheme
Each URI begins with a scheme name that refers to a specification for
assigning identifiers within that scheme. As such, the URI syntax is
a federated and extensible naming system wherein each scheme's
specification may further restrict the syntax and semantics of
identifiers using that scheme.
Scheme names consist of a sequence of characters beginning with a
letter and followed by any combination of letters, digits, plus
("+"), period ("."), or hyphen ("-"). Although schemes are case-
insensitive, the canonical form is lowercase and documents that
specify schemes must do so with lowercase letters. An implementation
should accept uppercase letters as equivalent to lowercase in scheme
names (e.g., allow "HTTP" as well as "http") for the sake of
robustness but should only produce lowercase scheme names for
consistency.
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
Individual schemes are not specified by this document. The process
for registration of new URI schemes is defined separately by [BCP35].
The scheme registry maintains the mapping between scheme names and
their specifications. Advice for designers of new URI schemes can be
found in [RFC2718]. URI scheme specifications must define their own
syntax so that all strings matching their scheme-specific syntax will
also match the grammar, as described in Section 4.3.
When presented with a URI that violates one or more scheme-specific
restrictions, the scheme-specific resolution process should flag the
reference as an error rather than ignore the unused parts; doing so
reduces the number of equivalent URIs and helps detect abuses of the
generic syntax, which might indicate that the URI has been
constructed to mislead the user (Section 7.6).
3.2. Authority
Many URI schemes include a hierarchical element for a naming
authority so that governance of the name space defined by the
remainder of the URI is delegated to that authority (which may, in
turn, delegate it further). The generic syntax provides a common
means for distinguishing an authority based on a registered name or
server address, along with optional port and user information.
The authority component is preceded by a double slash ("//") and is
terminated by the next slash ("/"), question mark ("?"), or number
sign ("#") character, or by the end of the URI.
Berners-Lee, et al. Standards Track [Page 17]
RFC 3986 URI Generic Syntax January 2005
authority = [ userinfo "@" ] host [ ":" port ]
URI producers and normalizers should omit the ":" delimiter that
separates host from port if the port component is empty. Some
schemes do not allow the userinfo and/or port subcomponents.
If a URI contains an authority component, then the path component
must either be empty or begin with a slash ("/") character. Non-
validating parsers (those that merely separate a URI reference into
its major components) will often ignore the subcomponent structure of
authority, treating it as an opaque string from the double-slash to
the first terminating delimiter, until such time as the URI is
dereferenced.
3.2.1. User Information
The userinfo subcomponent may consist of a user name and, optionally,
scheme-specific information about how to gain authorization to access
the resource. The user information, if present, is followed by a
commercial at-sign ("@") that delimits it from the host.
userinfo = *( unreserved / pct-encoded / sub-delims / ":" )
Use of the format "user:password" in the userinfo field is
deprecated. Applications should not render as clear text any data
after the first colon (":") character found within a userinfo
subcomponent unless the data after the colon is the empty string
(indicating no password). Applications may choose to ignore or
reject such data when it is received as part of a reference and
should reject the storage of such data in unencrypted form. The
passing of authentication information in clear text has proven to be
a security risk in almost every case where it has been used.
Applications that render a URI for the sake of user feedback, such as
in graphical hypertext browsing, should render userinfo in a way that
is distinguished from the rest of a URI, when feasible. Such
rendering will assist the user in cases where the userinfo has been
misleadingly crafted to look like a trusted domain name
(Section 7.6).
3.2.2. Host
The host subcomponent of authority is identified by an IP literal
encapsulated within square brackets, an IPv4 address in dotted-
decimal form, or a registered name. The host subcomponent is case-
insensitive. The presence of a host subcomponent within a URI does
not imply that the scheme requires access to the given host on the
Internet. In many cases, the host syntax is used only for the sake
Berners-Lee, et al. Standards Track [Page 18]
RFC 3986 URI Generic Syntax January 2005
of reusing the existing registration process created and deployed for
DNS, thus obtaining a globally unique name without the cost of
deploying another registry. However, such use comes with its own
costs: domain name ownership may change over time for reasons not
anticipated by the URI producer. In other cases, the data within the
host component identifies a registered name that has nothing to do
with an Internet host. We use the name "host" for the ABNF rule
because that is its most common purpose, not its only purpose.
host = IP-literal / IPv4address / reg-name
The syntax rule for host is ambiguous because it does not completely
distinguish between an IPv4address and a reg-name. In order to
disambiguate the syntax, we apply the "first-match-wins" algorithm:
If host matches the rule for IPv4address, then it should be
considered an IPv4 address literal and not a reg-name. Although host
is case-insensitive, producers and normalizers should use lowercase
for registered names and hexadecimal addresses for the sake of
uniformity, while only using uppercase letters for percent-encodings.
A host identified by an Internet Protocol literal address, version 6
[RFC3513] or later, is distinguished by enclosing the IP literal
within square brackets ("[" and "]"). This is the only place where
square bracket characters are allowed in the URI syntax. In
anticipation of future, as-yet-undefined IP literal address formats,
an implementation may use an optional version flag to indicate such a
format explicitly rather than rely on heuristic determination.
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
The version flag does not indicate the IP version; rather, it
indicates future versions of the literal format. As such,
implementations must not provide the version flag for the existing
IPv4 and IPv6 literal address forms described below. If a URI
containing an IP-literal that starts with "v" (case-insensitive),
indicating that the version flag is present, is dereferenced by an
application that does not know the meaning of that version flag, then
the application should return an appropriate error for "address
mechanism not supported".
A host identified by an IPv6 literal address is represented inside
the square brackets without a preceding version flag. The ABNF
provided here is a translation of the text definition of an IPv6
literal address provided in [RFC3513]. This syntax does not support
IPv6 scoped addressing zone identifiers.
Berners-Lee, et al. Standards Track [Page 19]
RFC 3986 URI Generic Syntax January 2005
A 128-bit IPv6 address is divided into eight 16-bit pieces. Each
piece is represented numerically in case-insensitive hexadecimal,
using one to four hexadecimal digits (leading zeroes are permitted).
The eight encoded pieces are given most-significant first, separated
by colon characters. Optionally, the least-significant two pieces
may instead be represented in IPv4 address textual format. A
sequence of one or more consecutive zero-valued 16-bit pieces within
the address may be elided, omitting all their digits and leaving
exactly two consecutive colons in their place to mark the elision.
IPv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
ls32 = ( h16 ":" h16 ) / IPv4address
; least-significant 32 bits of address
h16 = 1*4HEXDIG
; 16 bits of address represented in hexadecimal
A host identified by an IPv4 literal address is represented in
dotted-decimal notation (a sequence of four decimal numbers in the
range 0 to 255, separated by "."), as described in [RFC1123] by
reference to [RFC0952]. Note that other forms of dotted notation may
be interpreted on some platforms, as described in Section 7.4, but
only the dotted-decimal form of four octets is allowed by this
grammar.
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
A host identified by a registered name is a sequence of characters
usually intended for lookup within a locally defined host or service
name registry, though the URI's scheme-specific semantics may require
that a specific registry (or fixed name table) be used instead. The
most common name registry mechanism is the Domain Name System (DNS).
A registered name intended for lookup in the DNS uses the syntax
Berners-Lee, et al. Standards Track [Page 20]
RFC 3986 URI Generic Syntax January 2005
defined in Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].
Such a name consists of a sequence of domain labels separated by ".",
each domain label starting and ending with an alphanumeric character
and possibly also containing "-" characters. The rightmost domain
label of a fully qualified domain name in DNS may be followed by a
single "." and should be if it is necessary to distinguish between
the complete domain name and some local domain.
reg-name = *( unreserved / pct-encoded / sub-delims )
If the URI scheme defines a default for host, then that default
applies when the host subcomponent is undefined or when the
registered name is empty (zero length). For example, the "file" URI
scheme is defined so that no authority, an empty host, and
"localhost" all mean the end-user's machine, whereas the "http"
scheme considers a missing authority or empty host invalid.
This specification does not mandate a particular registered name
lookup technology and therefore does not restrict the syntax of reg-
name beyond what is necessary for interoperability. Instead, it
delegates the issue of registered name syntax conformance to the
operating system of each application performing URI resolution, and
that operating system decides what it will allow for the purpose of
host identification. A URI resolution implementation might use DNS,
host tables, yellow pages, NetInfo, WINS, or any other system for
lookup of registered names. However, a globally scoped naming
system, such as DNS fully qualified domain names, is necessary for
URIs intended to have global scope. URI producers should use names
that conform to the DNS syntax, even when use of DNS is not
immediately apparent, and should limit these names to no more than
255 characters in length.
The reg-name syntax allows percent-encoded octets in order to
represent non-ASCII registered names in a uniform way that is
independent of the underlying name resolution technology. Non-ASCII
characters must first be encoded according to UTF-8 [STD63], and then
each octet of the corresponding UTF-8 sequence must be percent-
encoded to be represented as URI characters. URI producing
applications must not use percent-encoding in host unless it is used
to represent a UTF-8 character sequence. When a non-ASCII registered
name represents an internationalized domain name intended for
resolution via the DNS, the name must be transformed to the IDNA
encoding [RFC3490] prior to name lookup. URI producers should
provide these registered names in the IDNA encoding, rather than a
percent-encoding, if they wish to maximize interoperability with
legacy URI resolvers.
Berners-Lee, et al. Standards Track [Page 21]
RFC 3986 URI Generic Syntax January 2005
3.2.3. Port
The port subcomponent of authority is designated by an optional port
number in decimal following the host and delimited from it by a
single colon (":") character.
port = *DIGIT
A scheme may define a default port. For example, the "http" scheme
defines a default port of "80", corresponding to its reserved TCP
port number. The type of port designated by the port number (e.g.,
TCP, UDP, SCTP) is defined by the URI scheme. URI producers and
normalizers should omit the port component and its ":" delimiter if
port is empty or if its value would be the same as that of the
scheme's default.
3.3. Path
The path component contains data, usually organized in hierarchical
form, that, along with data in the non-hierarchical query component
(Section 3.4), serves to identify a resource within the scope of the
URI's scheme and naming authority (if any). The path is terminated
by the first question mark ("?") or number sign ("#") character, or
by the end of the URI.
If a URI contains an authority component, then the path component
must either be empty or begin with a slash ("/") character. If a URI
does not contain an authority component, then the path cannot begin
with two slash characters ("//"). In addition, a URI reference
(Section 4.1) may be a relative-path reference, in which case the
first path segment cannot contain a colon (":") character. The ABNF
requires five separate rules to disambiguate these cases, only one of
which will match the path substring within a given URI reference. We
use the generic term "path component" to describe the URI substring
matched by the parser to one of these rules.
path = path-abempty ; begins with "/" or is empty
/ path-absolute ; begins with "/" but not "//"
/ path-noscheme ; begins with a non-colon segment
/ path-rootless ; begins with a segment
/ path-empty ; zero characters
path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0
Berners-Lee, et al. Standards Track [Page 22]
RFC 3986 URI Generic Syntax January 2005
segment = *pchar
segment-nz = 1*pchar
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
; non-zero-length segment without any colon ":"
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
A path consists of a sequence of path segments separated by a slash
("/") character. A path is always defined for a URI, though the
defined path may be empty (zero length). Use of the slash character
to indicate hierarchy is only required when a URI will be used as the
context for relative references. For example, the URI
has a path of "fred@example.com", whereas
the URI has an empty path.
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).
Aside from dot-segments in hierarchical paths, a path segment is
considered opaque by the generic syntax. URI producing applications
often use the reserved characters allowed in a segment to delimit
scheme-specific or dereference-handler-specific subcomponents. For
example, the semicolon (";") and equals ("=") reserved characters are
often used to delimit parameters and parameter values applicable to
that segment. The comma (",") reserved character is often used for
similar purposes. For example, one URI producer might use a segment
such as "name;v=1.1" to indicate a reference to version 1.1 of
"name", whereas another might use a segment such as "name,1.1" to
indicate the same. Parameter types may be defined by scheme-specific
semantics, but in most cases the syntax of a parameter is specific to
the implementation of the URI's dereferencing algorithm.
3.4. Query
The query component contains non-hierarchical data that, along with
data in the path component (Section 3.3), serves to identify a
resource within the scope of the URI's scheme and naming authority
(if any). The query component is indicated by the first question
mark ("?") character and terminated by a number sign ("#") character
or by the end of the URI.
Berners-Lee, et al. Standards Track [Page 23]
RFC 3986 URI Generic Syntax January 2005
query = *( pchar / "/" / "?" )
The characters slash ("/") and question mark ("?") may represent data
within the query component. Beware that some older, erroneous
implementations may not handle such data correctly when it is used as
the base URI for relative references (Section 5.1), apparently
because they fail to distinguish query data from path data when
looking for hierarchical separators. However, as query components
are often used to carry identifying information in the form of
"key=value" pairs and one frequently used value is a reference to
another URI, it is sometimes better for usability to avoid percent-
encoding those characters.
3.5. Fragment
The fragment identifier component of a URI allows indirect
identification of a secondary resource by reference to a primary
resource and additional identifying information. The identified
secondary resource may be some portion or subset of the primary
resource, some view on representations of the primary resource, or
some other resource defined or described by those representations. A
fragment identifier component is indicated by the presence of a
number sign ("#") character and terminated by the end of the URI.
fragment = *( pchar / "/" / "?" )
The semantics of a fragment identifier are defined by the set of
representations that might result from a retrieval action on the
primary resource. The fragment's format and resolution is therefore
dependent on the media type [RFC2046] of a potentially retrieved
representation, even though such a retrieval is only performed if the
URI is dereferenced. If no such representation exists, then the
semantics of the fragment are considered unknown and are effectively
unconstrained. Fragment identifier semantics are independent of the
URI scheme and thus cannot be redefined by scheme specifications.
Individual media types may define their own restrictions on or
structures within the fragment identifier syntax for specifying
different types of subsets, views, or external references that are
identifiable as secondary resources by that media type. If the
primary resource has multiple representations, as is often the case
for resources whose representation is selected based on attributes of
the retrieval request (a.k.a., content negotiation), then whatever is
identified by the fragment should be consistent across all of those
representations. Each representation should either define the
fragment so that it corresponds to the same secondary resource,
regardless of how it is represented, or should leave the fragment
undefined (i.e., not found).
Berners-Lee, et al. Standards Track [Page 24]
RFC 3986 URI Generic Syntax January 2005
As with any URI, use of a fragment identifier component does not
imply that a retrieval action will take place. A URI with a fragment
identifier may be used to refer to the secondary resource without any
implication that the primary resource is accessible or will ever be
accessed.
Fragment identifiers have a special role in information retrieval
systems as the primary form of client-side indirect referencing,
allowing an author to specifically identify aspects of an existing
resource that are only indirectly provided by the resource owner. As
such, the fragment identifier is not used in the scheme-specific
processing of a URI; instead, the fragment identifier is separated
from the rest of the URI prior to a dereference, and thus the
identifying information within the fragment itself is dereferenced
solely by the user agent, regardless of the URI scheme. Although
this separate handling is often perceived to be a loss of
information, particularly for accurate redirection of references as
resources move over time, it also serves to prevent information
providers from denying reference authors the right to refer to
information within a resource selectively. Indirect referencing also
provides additional flexibility and extensibility to systems that use
URIs, as new media types are easier to define and deploy than new
schemes of identification.
The characters slash ("/") and question mark ("?") are allowed to
represent data within the fragment identifier. Beware that some
older, erroneous implementations may not handle this data correctly
when it is used as the base URI for relative references (Section
5.1).
4. Usage
When applications make reference to a URI, they do not always use the
full form of reference defined by the "URI" syntax rule. To save
space and take advantage of hierarchical locality, many Internet
protocol elements and media type formats allow an abbreviation of a
URI, whereas others restrict the syntax to a particular form of URI.
We define the most common forms of reference syntax in this
specification because they impact and depend upon the design of the
generic syntax, requiring a uniform parsing algorithm in order to be
interpreted consistently.
4.1. URI Reference
URI-reference is used to denote the most common usage of a resource
identifier.
URI-reference = URI / relative-ref
Berners-Lee, et al. Standards Track [Page 25]
RFC 3986 URI Generic Syntax January 2005
A URI-reference is either a URI or a relative reference. If the
URI-reference's prefix does not match the syntax of a scheme followed
by its colon separator, then the URI-reference is a relative
reference.
A URI-reference is typically parsed first into the five URI
components, in order to determine what components are present and
whether the reference is relative. Then, each component is parsed
for its subparts and their validation. The ABNF of URI-reference,
along with the "first-match-wins" disambiguation rule, is sufficient
to define a validating parser for the generic syntax. Readers
familiar with regular expressions should see Appendix B for an
example of a non-validating URI-reference parser that will take any
given string and extract the URI components.
4.2. Relative Reference
A relative reference takes advantage of the hierarchical syntax
(Section 1.2.3) to express a URI reference relative to the name space
of another hierarchical URI.
relative-ref = relative-part [ "?" query ] [ "#" fragment ]
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty
The URI referred to by a relative reference, also known as the target
URI, is obtained by applying the reference resolution algorithm of
Section 5.
A relative reference that begins with two slash characters is termed
a network-path reference; such references are rarely used. A
relative reference that begins with a single slash character is
termed an absolute-path reference. A relative reference that does
not begin with a slash character is termed a relative-path reference.
A path segment that contains a colon character (e.g., "this:that")
cannot be used as the first segment of a relative-path reference, as
it would be mistaken for a scheme name. Such a segment must be
preceded by a dot-segment (e.g., "./this:that") to make a relative-
path reference.
Berners-Lee, et al. Standards Track [Page 26]
RFC 3986 URI Generic Syntax January 2005
4.3. Absolute URI
Some protocol elements allow only the absolute form of a URI without
a fragment identifier. For example, defining a base URI for later
use by relative references calls for an absolute-URI syntax rule that
does not allow a fragment.
absolute-URI = scheme ":" hier-part [ "?" query ]
URI scheme specifications must define their own syntax so that all
strings matching their scheme-specific syntax will also match the
grammar. Scheme specifications will not define
fragment identifier syntax or usage, regardless of its applicability
to resources identifiable via that scheme, as fragment identification
is orthogonal to scheme definition. However, scheme specifications
are encouraged to include a wide range of examples, including
examples that show use of the scheme's URIs with fragment identifiers
when such usage is appropriate.
4.4. Same-Document Reference
When a URI reference refers to a URI that is, aside from its fragment
component (if any), identical to the base URI (Section 5.1), that
reference is called a "same-document" reference. The most frequent
examples of same-document references are relative references that are
empty or include only the number sign ("#") separator followed by a
fragment identifier.
When a same-document reference is dereferenced for a retrieval
action, the target of that reference is defined to be within the same
entity (representation, document, or message) as the reference;
therefore, a dereference should not result in a new retrieval action.
Normalization of the base and target URIs prior to their comparison,
as described in Sections 6.2.2 and 6.2.3, is allowed but rarely
performed in practice. Normalization may increase the set of same-
document references, which may be of benefit to some caching
applications. As such, reference authors should not assume that a
slightly different, though equivalent, reference URI will (or will
not) be interpreted as a same-document reference by any given
application.
4.5. Suffix Reference
The URI syntax is designed for unambiguous reference to resources and
extensibility via the URI scheme. However, as URI identification and
usage have become commonplace, traditional media (television, radio,
newspapers, billboards, etc.) have increasingly used a suffix of the
Berners-Lee, et al. Standards Track [Page 27]
RFC 3986 URI Generic Syntax January 2005
URI as a reference, consisting of only the authority and path
portions of the URI, such as
www.w3.org/Addressing/
or simply a DNS registered name on its own. Such references are
primarily intended for human interpretation rather than for machines,
with the assumption that context-based heuristics are sufficient to
complete the URI (e.g., most registered names beginning with "www"
are likely to have a URI prefix of "http://"). Although there is no
standard set of heuristics for disambiguating a URI suffix, many
client implementations allow them to be entered by the user and
heuristically resolved.
Although this practice of using suffix references is common, it
should be avoided whenever possible and should never be used in
situations where long-term references are expected. The heuristics
noted above will change over time, particularly when a new URI scheme
becomes popular, and are often incorrect when used out of context.
Furthermore, they can lead to security issues along the lines of
those described in [RFC1535].
As a URI suffix has the same syntax as a relative-path reference, a
suffix reference cannot be used in contexts where a relative
reference is expected. As a result, suffix references are limited to
places where there is no defined base URI, such as dialog boxes and
off-line advertisements.
5. Reference Resolution
This section defines the process of resolving a URI reference within
a context that allows relative references so that the result is a
string matching the syntax rule of Section 3.
5.1. Establishing a Base URI
The term "relative" implies that a "base URI" exists against which
the relative reference is applied. Aside from fragment-only
references (Section 4.4), relative references are only usable when a
base URI is known. A base URI must be established by the parser
prior to parsing URI references that might be relative. A base URI
must conform to the syntax rule (Section 4.3). If the
base URI is obtained from a URI reference, then that reference must
be converted to absolute form and stripped of any fragment component
prior to its use as a base URI.
Berners-Lee, et al. Standards Track [Page 28]
RFC 3986 URI Generic Syntax January 2005
The base URI of a reference can be established in one of four ways,
discussed below in order of precedence. The order of precedence can
be thought of in terms of layers, where the innermost defined base
URI has the highest precedence. This can be visualized graphically
as follows:
.----------------------------------------------------------.
| .----------------------------------------------------. |
| | .----------------------------------------------. | |
| | | .----------------------------------------. | | |
| | | | .----------------------------------. | | | |
| | | | | | | | | |
| | | | `----------------------------------' | | | |
| | | | (5.1.1) Base URI embedded in content | | | |
| | | `----------------------------------------' | | |
| | | (5.1.2) Base URI of the encapsulating entity | | |
| | | (message, representation, or none) | | |
| | `----------------------------------------------' | |
| | (5.1.3) URI used to retrieve the entity | |
| `----------------------------------------------------' |
| (5.1.4) Default Base URI (application-dependent) |
`----------------------------------------------------------'
5.1.1. Base URI Embedded in Content
Within certain media types, a base URI for relative references can be
embedded within the content itself so that it can be readily obtained
by a parser. This can be useful for descriptive documents, such as
tables of contents, which may be transmitted to others through
protocols other than their usual retrieval context (e.g., email or
USENET news).
It is beyond the scope of this specification to specify how, for each
media type, a base URI can be embedded. The appropriate syntax, when
available, is described by the data format specification associated
with each media type.
5.1.2. Base URI from the Encapsulating Entity
If no base URI is embedded, the base URI is defined by the
representation's retrieval context. For a document that is enclosed
within another entity, such as a message or archive, the retrieval
context is that entity. Thus, the default base URI of a
representation is the base URI of the entity in which the
representation is encapsulated.
Berners-Lee, et al. Standards Track [Page 29]
RFC 3986 URI Generic Syntax January 2005
A mechanism for embedding a base URI within MIME container types
(e.g., the message and multipart types) is defined by MHTML
[RFC2557]. Protocols that do not use the MIME message header syntax,
but that do allow some form of tagged metadata to be included within
messages, may define their own syntax for defining a base URI as part
of a message.
5.1.3. Base URI from the Retrieval URI
If no base URI is embedded and the representation is not encapsulated
within some other entity, then, if a URI was used to retrieve the
representation, that URI shall be considered the base URI. Note that
if the retrieval was the result of a redirected request, the last URI
used (i.e., the URI that resulted in the actual retrieval of the
representation) is the base URI.
5.1.4. Default Base URI
If none of the conditions described above apply, then the base URI is
defined by the context of the application. As this definition is
necessarily application-dependent, failing to define a base URI by
using one of the other methods may result in the same content being
interpreted differently by different types of applications.
A sender of a representation containing relative references is
responsible for ensuring that a base URI for those references can be
established. Aside from fragment-only references, relative
references can only be used reliably in situations where the base URI
is well defined.
5.2. Relative Resolution
This section describes an algorithm for converting a URI reference
that might be relative to a given base URI into the parsed components
of the reference's target. The components can then be recomposed, as
described in Section 5.3, to form the target URI. This algorithm
provides definitive results that can be used to test the output of
other implementations. Applications may implement relative reference
resolution by using some other algorithm, provided that the results
match what would be given by this one.
Berners-Lee, et al. Standards Track [Page 30]
RFC 3986 URI Generic Syntax January 2005
5.2.1. Pre-parse the Base URI
The base URI (Base) is established according to the procedure of
Section 5.1 and parsed into the five main components described in
Section 3. Note that only the scheme component is required to be
present in a base URI; the other components may be empty or
undefined. A component is undefined if its associated delimiter does
not appear in the URI reference; the path component is never
undefined, though it may be empty.
Normalization of the base URI, as described in Sections 6.2.2 and
6.2.3, is optional. A URI reference must be transformed to its
target URI before it can be normalized.
5.2.2. Transform References
For each URI reference (R), the following pseudocode describes an
algorithm for transforming R into its target URI (T):
-- The URI reference is parsed into the five URI components
--
(R.scheme, R.authority, R.path, R.query, R.fragment) = parse(R);
-- A non-strict parser may ignore a scheme in the reference
-- if it is identical to the base URI's scheme.
--
if ((not strict) and (R.scheme == Base.scheme)) then
undefine(R.scheme);
endif;
Berners-Lee, et al. Standards Track [Page 31]
RFC 3986 URI Generic Syntax January 2005
if defined(R.scheme) then
T.scheme = R.scheme;
T.authority = R.authority;
T.path = remove_dot_segments(R.path);
T.query = R.query;
else
if defined(R.authority) then
T.authority = R.authority;
T.path = remove_dot_segments(R.path);
T.query = R.query;
else
if (R.path == "") then
T.path = Base.path;
if defined(R.query) then
T.query = R.query;
else
T.query = Base.query;
endif;
else
if (R.path starts-with "/") then
T.path = remove_dot_segments(R.path);
else
T.path = merge(Base.path, R.path);
T.path = remove_dot_segments(T.path);
endif;
T.query = R.query;
endif;
T.authority = Base.authority;
endif;
T.scheme = Base.scheme;
endif;
T.fragment = R.fragment;
5.2.3. Merge Paths
The pseudocode above refers to a "merge" routine for merging a
relative-path reference with the path of the base URI. This is
accomplished as follows:
o If the base URI has a defined authority component and an empty
path, then return a string consisting of "/" concatenated with the
reference's path; otherwise,
Berners-Lee, et al. Standards Track [Page 32]
RFC 3986 URI Generic Syntax January 2005
o return a string consisting of the reference's path component
appended to all but the last segment of the base URI's path (i.e.,
excluding any characters after the right-most "/" in the base URI
path, or excluding the entire base URI path if it does not contain
any "/" characters).
5.2.4. Remove Dot Segments
The pseudocode also refers to a "remove_dot_segments" routine for
interpreting and removing the special "." and ".." complete path
segments from a referenced path. This is done after the path is
extracted from a reference, whether or not the path was relative, in
order to remove any invalid or extraneous dot-segments prior to
forming the target URI. Although there are many ways to accomplish
this removal process, we describe a simple method using two string
buffers.
1. The input buffer is initialized with the now-appended path
components and the output buffer is initialized to the empty
string.
2. While the input buffer is not empty, loop as follows:
A. If the input buffer begins with a prefix of "../" or "./",
then remove that prefix from the input buffer; otherwise,
B. if the input buffer begins with a prefix of "/./" or "/.",
where "." is a complete path segment, then replace that
prefix with "/" in the input buffer; otherwise,
C. if the input buffer begins with a prefix of "/../" or "/..",
where ".." is a complete path segment, then replace that
prefix with "/" in the input buffer and remove the last
segment and its preceding "/" (if any) from the output
buffer; otherwise,
D. if the input buffer consists only of "." or "..", then remove
that from the input buffer; otherwise,
E. move the first path segment in the input buffer to the end of
the output buffer, including the initial "/" character (if
any) and any subsequent characters up to, but not including,
the next "/" character or the end of the input buffer.
3. Finally, the output buffer is returned as the result of
remove_dot_segments.
Berners-Lee, et al. Standards Track [Page 33]
RFC 3986 URI Generic Syntax January 2005
Note that dot-segments are intended for use in URI references to
express an identifier relative to the hierarchy of names in the base
URI. The remove_dot_segments algorithm respects that hierarchy by
removing extra dot-segments rather than treat them as an error or
leaving them to be misinterpreted by dereference implementations.
The following illustrates how the above steps are applied for two
examples of merged paths, showing the state of the two buffers after
each step.
STEP OUTPUT BUFFER INPUT BUFFER
1 : /a/b/c/./../../g
2E: /a /b/c/./../../g
2E: /a/b /c/./../../g
2E: /a/b/c /./../../g
2B: /a/b/c /../../g
2C: /a/b /../g
2C: /a /g
2E: /a/g
STEP OUTPUT BUFFER INPUT BUFFER
1 : mid/content=5/../6
2E: mid /content=5/../6
2E: mid/content=5 /../6
2C: mid /6
2E: mid/6
Some applications may find it more efficient to implement the
remove_dot_segments algorithm by using two segment stacks rather than
strings.
Note: Beware that some older, erroneous implementations will fail
to separate a reference's query component from its path component
prior to merging the base and reference paths, resulting in an
interoperability failure if the query component contains the
strings "/../" or "/./".
Berners-Lee, et al. Standards Track [Page 34]
RFC 3986 URI Generic Syntax January 2005
5.3. Component Recomposition
Parsed URI components can be recomposed to obtain the corresponding
URI reference string. Using pseudocode, this would be:
result = ""
if defined(scheme) then
append scheme to result;
append ":" to result;
endif;
if defined(authority) then
append "//" to result;
append authority to result;
endif;
append path to result;
if defined(query) then
append "?" to result;
append query to result;
endif;
if defined(fragment) then
append "#" to result;
append fragment to result;
endif;
return result;
Note that we are careful to preserve the distinction between a
component that is undefined, meaning that its separator was not
present in the reference, and a component that is empty, meaning that
the separator was present and was immediately followed by the next
component separator or the end of the reference.
5.4. Reference Resolution Examples
Within a representation with a well defined base URI of
http://a/b/c/d;p?q
a relative reference is transformed to its target URI as follows.
Berners-Lee, et al. Standards Track [Page 35]
RFC 3986 URI Generic Syntax January 2005
5.4.1. Normal Examples
"g:h" = "g:h"
"g" = "http://a/b/c/g"
"./g" = "http://a/b/c/g"
"g/" = "http://a/b/c/g/"
"/g" = "http://a/g"
"//g" = "http://g"
"?y" = "http://a/b/c/d;p?y"
"g?y" = "http://a/b/c/g?y"
"#s" = "http://a/b/c/d;p?q#s"
"g#s" = "http://a/b/c/g#s"
"g?y#s" = "http://a/b/c/g?y#s"
";x" = "http://a/b/c/;x"
"g;x" = "http://a/b/c/g;x"
"g;x?y#s" = "http://a/b/c/g;x?y#s"
"" = "http://a/b/c/d;p?q"
"." = "http://a/b/c/"
"./" = "http://a/b/c/"
".." = "http://a/b/"
"../" = "http://a/b/"
"../g" = "http://a/b/g"
"../.." = "http://a/"
"../../" = "http://a/"
"../../g" = "http://a/g"
5.4.2. Abnormal Examples
Although the following abnormal examples are unlikely to occur in
normal practice, all URI parsers should be capable of resolving them
consistently. Each example uses the same base as that above.
Parsers must be careful in handling cases where there are more ".."
segments in a relative-path reference than there are hierarchical
levels in the base URI's path. Note that the ".." syntax cannot be
used to change the authority component of a URI.
"../../../g" = "http://a/g"
"../../../../g" = "http://a/g"
Berners-Lee, et al. Standards Track [Page 36]
RFC 3986 URI Generic Syntax January 2005
Similarly, parsers must remove the dot-segments "." and ".." when
they are complete components of a path, but not when they are only
part of a segment.
"/./g" = "http://a/g"
"/../g" = "http://a/g"
"g." = "http://a/b/c/g."
".g" = "http://a/b/c/.g"
"g.." = "http://a/b/c/g.."
"..g" = "http://a/b/c/..g"
Less likely are cases where the relative reference uses unnecessary
or nonsensical forms of the "." and ".." complete path segments.
"./../g" = "http://a/b/g"
"./g/." = "http://a/b/c/g/"
"g/./h" = "http://a/b/c/g/h"
"g/../h" = "http://a/b/c/h"
"g;x=1/./y" = "http://a/b/c/g;x=1/y"
"g;x=1/../y" = "http://a/b/c/y"
Some applications fail to separate the reference's query and/or
fragment components from the path component before merging it with
the base path and removing dot-segments. This error is rarely
noticed, as typical usage of a fragment never includes the hierarchy
("/") character and the query component is not normally used within
relative references.
"g?y/./x" = "http://a/b/c/g?y/./x"
"g?y/../x" = "http://a/b/c/g?y/../x"
"g#s/./x" = "http://a/b/c/g#s/./x"
"g#s/../x" = "http://a/b/c/g#s/../x"
Some parsers allow the scheme name to be present in a relative
reference if it is the same as the base URI scheme. This is
considered to be a loophole in prior specifications of partial URI
[RFC1630]. Its use should be avoided but is allowed for backward
compatibility.
"http:g" = "http:g" ; for strict parsers
/ "http://a/b/c/g" ; for backward compatibility
Berners-Lee, et al. Standards Track [Page 37]
RFC 3986 URI Generic Syntax January 2005
6. Normalization and Comparison
One of the most common operations on URIs is simple comparison:
determining whether two URIs are equivalent without using the URIs to
access their respective resource(s). A comparison is performed every
time a response cache is accessed, a browser checks its history to
color a link, or an XML parser processes tags within a namespace.
Extensive normalization prior to comparison of URIs is often used by
spiders and indexing engines to prune a search space or to reduce
duplication of request actions and response storage.
URI comparison is performed for some particular purpose. Protocols
or implementations that compare URIs for different purposes will
often be subject to differing design trade-offs in regards to how
much effort should be spent in reducing aliased identifiers. This
section describes various methods that may be used to compare URIs,
the trade-offs between them, and the types of applications that might
use them.
6.1. Equivalence
Because URIs exist to identify resources, presumably they should be
considered equivalent when they identify the same resource. However,
this definition of equivalence is not of much practical use, as there
is no way for an implementation to compare two resources unless it
has full knowledge or control of them. For this reason,
determination of equivalence or difference of URIs is based on string
comparison, perhaps augmented by reference to additional rules
provided by URI scheme definitions. We use the terms "different" and
"equivalent" to describe the possible outcomes of such comparisons,
but there are many application-dependent versions of equivalence.
Even though it is possible to determine that two URIs are equivalent,
URI comparison is not sufficient to determine whether two URIs
identify different resources. For example, an owner of two different
domain names could decide to serve the same resource from both,
resulting in two different URIs. Therefore, comparison methods are
designed to minimize false negatives while strictly avoiding false
positives.
In testing for equivalence, applications should not directly compare
relative references; the references should be converted to their
respective target URIs before comparison. When URIs are compared to
select (or avoid) a network action, such as retrieval of a
representation, fragment components (if any) should be excluded from
the comparison.
Berners-Lee, et al. Standards Track [Page 38]
RFC 3986 URI Generic Syntax January 2005
6.2. Comparison Ladder
A variety of methods are used in practice to test URI equivalence.
These methods fall into a range, distinguished by the amount of
processing required and the degree to which the probability of false
negatives is reduced. As noted above, false negatives cannot be
eliminated. In practice, their probability can be reduced, but this
reduction requires more processing and is not cost-effective for all
applications.
If this range of comparison practices is considered as a ladder, the
following discussion will climb the ladder, starting with practices
that are cheap but have a relatively higher chance of producing false
negatives, and proceeding to those that have higher computational
cost and lower risk of false negatives.
6.2.1. Simple String Comparison
If two URIs, when considered as character strings, are identical,
then it is safe to conclude that they are equivalent. This type of
equivalence test has very low computational cost and is in wide use
in a variety of applications, particularly in the domain of parsing.
Testing strings for equivalence requires some basic precautions.
This procedure is often referred to as "bit-for-bit" or
"byte-for-byte" comparison, which is potentially misleading. Testing
strings for equality is normally based on pair comparison of the
characters that make up the strings, starting from the first and
proceeding until both strings are exhausted and all characters are
found to be equal, until a pair of characters compares unequal, or
until one of the strings is exhausted before the other.
This character comparison requires that each pair of characters be
put in comparable form. For example, should one URI be stored in a
byte array in EBCDIC encoding and the second in a Java String object
(UTF-16), bit-for-bit comparisons applied naively will produce
errors. It is better to speak of equality on a character-for-
character basis rather than on a byte-for-byte or bit-for-bit basis.
In practical terms, character-by-character comparisons should be done
codepoint-by-codepoint after conversion to a common character
encoding.
False negatives are caused by the production and use of URI aliases.
Unnecessary aliases can be reduced, regardless of the comparison
method, by consistently providing URI references in an already-
normalized form (i.e., a form identical to what would be produced
after normalization is applied, as described below).
Berners-Lee, et al. Standards Track [Page 39]
RFC 3986 URI Generic Syntax January 2005
Protocols and data formats often limit some URI comparisons to simple
string comparison, based on the theory that people and
implementations will, in their own best interest, be consistent in
providing URI references, or at least consistent enough to negate any
efficiency that might be obtained from further normalization.
6.2.2. Syntax-Based Normalization
Implementations may use logic based on the definitions provided by
this specification to reduce the probability of false negatives.
This processing is moderately higher in cost than character-for-
character string comparison. For example, an application using this
approach could reasonably consider the following two URIs equivalent:
example://a/b/c/%7Bfoo%7D
eXAMPLE://a/./b/../b/%63/%7bfoo%7d
Web user agents, such as browsers, typically apply this type of URI
normalization when determining whether a cached response is
available. Syntax-based normalization includes such techniques as
case normalization, percent-encoding normalization, and removal of
dot-segments.
6.2.2.1. Case Normalization
For all URIs, the hexadecimal digits within a percent-encoding
triplet (e.g., "%3a" versus "%3A") are case-insensitive and therefore
should be normalized to use uppercase letters for the digits A-F.
When a URI uses components of the generic syntax, the component
syntax equivalence rules always apply; namely, that the scheme and
host are case-insensitive and therefore should be normalized to
lowercase. For example, the URI is
equivalent to . The other generic syntax
components are assumed to be case-sensitive unless specifically
defined otherwise by the scheme (see Section 6.2.3).
6.2.2.2. Percent-Encoding Normalization
The percent-encoding mechanism (Section 2.1) is a frequent source of
variance among otherwise identical URIs. In addition to the case
normalization issue noted above, some URI producers percent-encode
octets that do not require percent-encoding, resulting in URIs that
are equivalent to their non-encoded counterparts. These URIs should
be normalized by decoding any percent-encoded octet that corresponds
to an unreserved character, as described in Section 2.3.
Berners-Lee, et al. Standards Track [Page 40]
RFC 3986 URI Generic Syntax January 2005
6.2.2.3. Path Segment Normalization
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.
6.2.3. Scheme-Based Normalization
The syntax and semantics of URIs vary from scheme to scheme, as
described by the defining specification for each scheme.
Implementations may use scheme-specific rules, at further processing
cost, to reduce the probability of false negatives. For example,
because the "http" scheme makes use of an authority component, has a
default port of "80", and defines an empty path to be equivalent to
"/", the following four URIs are equivalent:
http://example.com
http://example.com/
http://example.com:/
http://example.com:80/
In general, a URI that uses the generic syntax for authority with an
empty path should be normalized to a path of "/". Likewise, an
explicit ":port", for which the port is empty or the default for the
scheme, is equivalent to one where the port and its ":" delimiter are
elided and thus should be removed by scheme-based normalization. For
example, the second URI above is the normal form for the "http"
scheme.
Another case where normalization varies by scheme is in the handling
of an empty authority component or empty host subcomponent. For many
scheme specifications, an empty authority or host is considered an
error; for others, it is considered equivalent to "localhost" or the
end-user's host. When a scheme defines a default for authority and a
URI reference to that default is desired, the reference should be
normalized to an empty authority for the sake of uniformity, brevity,
and internationalization. If, however, either the userinfo or port
subcomponents are non-empty, then the host should be given explicitly
even if it matches the default.
Normalization should not remove delimiters when their associated
component is empty unless licensed to do so by the scheme
Berners-Lee, et al. Standards Track [Page 41]
RFC 3986 URI Generic Syntax January 2005
specification. For example, the URI "http://example.com/?" cannot be
assumed to be equivalent to any of the examples above. Likewise, the
presence or absence of delimiters within a userinfo subcomponent is
usually significant to its interpretation. The fragment component is
not subject to any scheme-based normalization; thus, two URIs that
differ only by the suffix "#" are considered different regardless of
the scheme.
Some schemes define additional subcomponents that consist of case-
insensitive data, giving an implicit license to normalizers to
convert this data to a common case (e.g., all lowercase). For
example, URI schemes that define a subcomponent of path to contain an
Internet hostname, such as the "mailto" URI scheme, cause that
subcomponent to be case-insensitive and thus subject to case
normalization (e.g., "mailto:Joe@Example.COM" is equivalent to
"mailto:Joe@example.com", even though the generic syntax considers
the path component to be case-sensitive).
Other scheme-specific normalizations are possible.
6.2.4. Protocol-Based Normalization
Substantial effort to reduce the incidence of false negatives is
often cost-effective for web spiders. Therefore, they implement even
more aggressive techniques in URI comparison. For example, if they
observe that a URI such as
http://example.com/data
redirects to a URI differing only in the trailing slash
http://example.com/data/
they will likely regard the two as equivalent in the future. This
kind of technique is only appropriate when equivalence is clearly
indicated by both the result of accessing the resources and the
common conventions of their scheme's dereference algorithm (in this
case, use of redirection by HTTP origin servers to avoid problems
with relative references).
Berners-Lee, et al. Standards Track [Page 42]
RFC 3986 URI Generic Syntax January 2005
7. Security Considerations
A URI does not in itself pose a security threat. However, as URIs
are often used to provide a compact set of instructions for access to
network resources, care must be taken to properly interpret the data
within a URI, to prevent that data from causing unintended access,
and to avoid including data that should not be revealed in plain
text.
7.1. Reliability and Consistency
There is no guarantee that once a URI has been used to retrieve
information, the same information will be retrievable by that URI in
the future. Nor is there any guarantee that the information
retrievable via that URI in the future will be observably similar to
that retrieved in the past. The URI syntax does not constrain how a
given scheme or authority apportions its namespace or maintains it
over time. Such guarantees can only be obtained from the person(s)
controlling that namespace and the resource in question. A specific
URI scheme may define additional semantics, such as name persistence,
if those semantics are required of all naming authorities for that
scheme.
7.2. Malicious Construction
It is sometimes possible to construct a URI so that an attempt to
perform a seemingly harmless, idempotent operation, such as the
retrieval of a representation, will in fact cause a possibly damaging
remote operation. The unsafe URI is typically constructed by
specifying a port number other than that reserved for the network
protocol in question. The client unwittingly contacts a site running
a different protocol service, and data within the URI contains
instructions that, when interpreted according to this other protocol,
cause an unexpected operation. A frequent example of such abuse has
been the use of a protocol-based scheme with a port component of
"25", thereby fooling user agent software into sending an unintended
or impersonating message via an SMTP server.
Applications should prevent dereference of a URI that specifies a TCP
port number within the "well-known port" range (0 - 1023) unless the
protocol being used to dereference that URI is compatible with the
protocol expected on that well-known port. Although IANA maintains a
registry of well-known ports, applications should make such
restrictions user-configurable to avoid preventing the deployment of
new services.
Berners-Lee, et al. Standards Track [Page 43]
RFC 3986 URI Generic Syntax January 2005
When a URI contains percent-encoded octets that match the delimiters
for a given resolution or dereference protocol (for example, CR and
LF characters for the TELNET protocol), these percent-encodings must
not be decoded before transmission across that protocol. Transfer of
the percent-encoding, which might violate the protocol, is less
harmful than allowing decoded octets to be interpreted as additional
operations or parameters, perhaps triggering an unexpected and
possibly harmful remote operation.
7.3. Back-End Transcoding
When a URI is dereferenced, the data within it is often parsed by
both the user agent and one or more servers. In HTTP, for example, a
typical user agent will parse a URI into its five major components,
access the authority's server, and send it the data within the
authority, path, and query components. A typical server will take
that information, parse the path into segments and the query into
key/value pairs, and then invoke implementation-specific handlers to
respond to the request. As a result, a common security concern for
server implementations that handle a URI, either as a whole or split
into separate components, is proper interpretation of the octet data
represented by the characters and percent-encodings within that URI.
Percent-encoded octets must be decoded at some point during the
dereference process. Applications must split the URI into its
components and subcomponents prior to decoding the octets, as
otherwise the decoded octets might be mistaken for delimiters.
Security checks of the data within a URI should be applied after
decoding the octets. Note, however, that the "%00" percent-encoding
(NUL) may require special handling and should be rejected if the
application is not expecting to receive raw data within a component.
Special care should be taken when the URI path interpretation process
involves the use of a back-end file system or related system
functions. File systems typically assign an operational meaning to
special characters, such as the "/", "\", ":", "[", and "]"
characters, and to special device names like ".", "..", "...", "aux",
"lpt", etc. In some cases, merely testing for the existence of such
a name will cause the operating system to pause or invoke unrelated
system calls, leading to significant security concerns regarding
denial of service and unintended data transfer. It would be
impossible for this specification to list all such significant
characters and device names. Implementers should research the
reserved names and characters for the types of storage device that
may be attached to their applications and restrict the use of data
obtained from URI components accordingly.
Berners-Lee, et al. Standards Track [Page 44]
RFC 3986 URI Generic Syntax January 2005
7.4. Rare IP Address Formats
Although the URI syntax for IPv4address only allows the common
dotted-decimal form of IPv4 address literal, many implementations
that process URIs make use of platform-dependent system routines,
such as gethostbyname() and inet_aton(), to translate the string
literal to an actual IP address. Unfortunately, such system routines
often allow and process a much larger set of formats than those
described in Section 3.2.2.
For example, many implementations allow dotted forms of three
numbers, wherein the last part is interpreted as a 16-bit quantity
and placed in the right-most two bytes of the network address (e.g.,
a Class B network). Likewise, a dotted form of two numbers means
that the last part is interpreted as a 24-bit quantity and placed in
the right-most three bytes of the network address (Class A), and a
single number (without dots) is interpreted as a 32-bit quantity and
stored directly in the network address. Adding further to the
confusion, some implementations allow each dotted part to be
interpreted as decimal, octal, or hexadecimal, as specified in the C
language (i.e., a leading 0x or 0X implies hexadecimal; a leading 0
implies octal; otherwise, the number is interpreted as decimal).
These additional IP address formats are not allowed in the URI syntax
due to differences between platform implementations. However, they
can become a security concern if an application attempts to filter
access to resources based on the IP address in string literal format.
If this filtering is performed, literals should be converted to
numeric form and filtered based on the numeric value, and not on a
prefix or suffix of the string form.
7.5. Sensitive Information
URI producers should not provide a URI that contains a username or
password that is intended to be secret. URIs are frequently
displayed by browsers, stored in clear text bookmarks, and logged by
user agent history and intermediary applications (proxies). A
password appearing within the userinfo component is deprecated and
should be considered an error (or simply ignored) except in those
rare cases where the 'password' parameter is intended to be public.
7.6. Semantic Attacks
Because the userinfo subcomponent is rarely used and appears before
the host in the authority component, it can be used to construct a
URI intended to mislead a human user by appearing to identify one
(trusted) naming authority while actually identifying a different
authority hidden behind the noise. For example
Berners-Lee, et al. Standards Track [Page 45]
RFC 3986 URI Generic Syntax January 2005
ftp://cnn.example.com&story=breaking_news@10.0.0.1/top_story.htm
might lead a human user to assume that the host is 'cnn.example.com',
whereas it is actually '10.0.0.1'. Note that a misleading userinfo
subcomponent could be much longer than the example above.
A misleading URI, such as that above, is an attack on the user's
preconceived notions about the meaning of a URI rather than an attack
on the software itself. User agents may be able to reduce the impact
of such attacks by distinguishing the various components of the URI
when they are rendered, such as by using a different color or tone to
render userinfo if any is present, though there is no panacea. More
information on URI-based semantic attacks can be found in [Siedzik].
8. IANA Considerations
URI scheme names, as defined by in Section 3.1, form a
registered namespace that is managed by IANA according to the
procedures defined in [BCP35]. No IANA actions are required by this
document.
9. Acknowledgements
This specification is derived from RFC 2396 [RFC2396], RFC 1808
[RFC1808], and RFC 1738 [RFC1738]; the acknowledgements in those
documents still apply. It also incorporates the update (with
corrections) for IPv6 literals in the host syntax, as defined by
Robert M. Hinden, Brian E. Carpenter, and Larry Masinter in
[RFC2732]. In addition, contributions by Gisle Aas, Reese Anschultz,
Daniel Barclay, Tim Bray, Mike Brown, Rob Cameron, Jeremy Carroll,
Dan Connolly, Adam M. Costello, John Cowan, Jason Diamond, Martin
Duerst, Stefan Eissing, Clive D.W. Feather, Al Gilman, Tony Hammond,
Elliotte Harold, Pat Hayes, Henry Holtzman, Ian B. Jacobs, Michael
Kay, John C. Klensin, Graham Klyne, Dan Kohn, Bruce Lilly, Andrew
Main, Dave McAlpin, Ira McDonald, Michael Mealling, Ray Merkert,
Stephen Pollei, Julian Reschke, Tomas Rokicki, Miles Sabin, Kai
Schaetzl, Mark Thomson, Ronald Tschalaer, Norm Walsh, Marc Warne,
Stuart Williams, and Henry Zongaro are gratefully acknowledged.
10. References
10.1. Normative References
[ASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
Berners-Lee, et al. Standards Track [Page 46]
RFC 3986 URI Generic Syntax January 2005
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[STD63] Yergeau, F., "UTF-8, a transformation format of
ISO 10646", STD 63, RFC 3629, November 2003.
[UCS] International Organization for Standardization,
"Information Technology - Universal Multiple-Octet Coded
Character Set (UCS)", ISO/IEC 10646:2003, December 2003.
10.2. Informative References
[BCP19] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000.
[BCP35] Petke, R. and I. King, "Registration Procedures for URL
Scheme Names", BCP 35, RFC 2717, November 1999.
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet
host table specification", RFC 952, October 1985.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction
With Widely Deployed DNS Software", RFC 1535,
October 1993.
[RFC1630] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
Unifying Syntax for the Expression of Names and Addresses
of Objects on the Network as used in the World-Wide Web",
RFC 1630, June 1994.
[RFC1736] Kunze, J., "Functional Recommendations for Internet
Resource Locators", RFC 1736, February 1995.
[RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, December 1994.
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, December 1994.
[RFC1808] Fielding, R., "Relative Uniform Resource Locators",
RFC 1808, June 1995.
Berners-Lee, et al. Standards Track [Page 47]
RFC 3986 URI Generic Syntax January 2005
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
Jensen, "HTTP Extensions for Distributed Authoring --
WEBDAV", RFC 2518, February 1999.
[RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME
Encapsulation of Aggregate Documents, such as HTML
(MHTML)", RFC 2557, March 1999.
[RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
"Guidelines for new URL Schemes", RFC 2718, November 1999.
[RFC2732] Hinden, R., Carpenter, B., and L. Masinter, "Format for
Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[RFC3305] Mealling, M. and R. Denenberg, "Report from the Joint
W3C/IETF URI Planning Interest Group: Uniform Resource
Identifiers (URIs), URLs, and Uniform Resource Names
(URNs): Clarifications and Recommendations", RFC 3305,
August 2002.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[Siedzik] Siedzik, R., "Semantic Attacks: What's in a URL?",
April 2001, .
Berners-Lee, et al. Standards Track [Page 48]
RFC 3986 URI Generic Syntax January 2005
Appendix A. Collected ABNF for URI
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
hier-part = "//" authority path-abempty
/ path-absolute
/ path-rootless
/ path-empty
URI-reference = URI / relative-ref
absolute-URI = scheme ":" hier-part [ "?" query ]
relative-ref = relative-part [ "?" query ] [ "#" fragment ]
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty
scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
authority = [ userinfo "@" ] host [ ":" port ]
userinfo = *( unreserved / pct-encoded / sub-delims / ":" )
host = IP-literal / IPv4address / reg-name
port = *DIGIT
IP-literal = "[" ( IPv6address / IPvFuture ) "]"
IPvFuture = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )
IPv6address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IPv4address
IPv4address = dec-octet "." dec-octet "." dec-octet "." dec-octet
Berners-Lee, et al. Standards Track [Page 49]
RFC 3986 URI Generic Syntax January 2005
dec-octet = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
reg-name = *( unreserved / pct-encoded / sub-delims )
path = path-abempty ; begins with "/" or is empty
/ path-absolute ; begins with "/" but not "//"
/ path-noscheme ; begins with a non-colon segment
/ path-rootless ; begins with a segment
/ path-empty ; zero characters
path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0
segment = *pchar
segment-nz = 1*pchar
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
; non-zero-length segment without any colon ":"
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
query = *( pchar / "/" / "?" )
fragment = *( pchar / "/" / "?" )
pct-encoded = "%" HEXDIG HEXDIG
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
reserved = gen-delims / sub-delims
gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
Appendix B. Parsing a URI Reference with a Regular Expression
As the "first-match-wins" algorithm is identical to the "greedy"
disambiguation method used by POSIX regular expressions, it is
natural and commonplace to use a regular expression for parsing the
potential five components of a URI reference.
The following line is the regular expression for breaking-down a
well-formed URI reference into its components.
Berners-Lee, et al. Standards Track [Page 50]
RFC 3986 URI Generic Syntax January 2005
^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
12 3 4 5 6 7 8 9
The numbers in the second line above are only to assist readability;
they indicate the reference points for each subexpression (i.e., each
paired parenthesis). We refer to the value matched for subexpression
as $. For example, matching the above expression to
http://www.ics.uci.edu/pub/ietf/uri/#Related
results in the following subexpression matches:
$1 = http:
$2 = http
$3 = //www.ics.uci.edu
$4 = www.ics.uci.edu
$5 = /pub/ietf/uri/
$6 =
$7 =
$8 = #Related
$9 = Related
where indicates that the component is not present, as is
the case for the query component in the above example. Therefore, we
can determine the value of the five components as
scheme = $2
authority = $4
path = $5
query = $7
fragment = $9
Going in the opposite direction, we can recreate a URI reference from
its components by using the algorithm of Section 5.3.
Appendix C. Delimiting a URI in Context
URIs are often transmitted through formats that do not provide a
clear context for their interpretation. For example, there are many
occasions when a URI is included in plain text; examples include text
sent in email, USENET news, and on printed paper. In such cases, it
is important to be able to delimit the URI from the rest of the text,
and in particular from punctuation marks that might be mistaken for
part of the URI.
In practice, URIs are delimited in a variety of ways, but usually
within double-quotes "http://example.com/", angle brackets
, or just by using whitespace:
Berners-Lee, et al. Standards Track [Page 51]
RFC 3986 URI Generic Syntax January 2005
http://example.com/
These wrappers do not form part of the URI.
In some cases, extra whitespace (spaces, line-breaks, tabs, etc.) may
have to be added to break a long URI across lines. The whitespace
should be ignored when the URI is extracted.
No whitespace should be introduced after a hyphen ("-") character.
Because some typesetters and printers may (erroneously) introduce a
hyphen at the end of line when breaking it, the interpreter of a URI
containing a line break immediately after a hyphen should ignore all
whitespace around the line break and should be aware that the hyphen
may or may not actually be part of the URI.
Using <> angle brackets around each URI is especially recommended as
a delimiting style for a reference that contains embedded whitespace.
The prefix "URL:" (with or without a trailing space) was formerly
recommended as a way to help distinguish a URI from other bracketed
designators, though it is not commonly used in practice and is no
longer recommended.
For robustness, software that accepts user-typed URI should attempt
to recognize and strip both delimiters and embedded whitespace.
For example, the text
Yes, Jim, I found it under "http://www.w3.org/Addressing/",
but you can probably pick it up from . Note the warning in .
contains the URI references
http://www.w3.org/Addressing/
ftp://foo.example.com/rfc/
http://www.ics.uci.edu/pub/ietf/uri/historical.html#WARNING
Berners-Lee, et al. Standards Track [Page 52]
RFC 3986 URI Generic Syntax January 2005
Appendix D. Changes from RFC 2396
D.1. Additions
An ABNF rule for URI has been introduced to correspond to one common
usage of the term: an absolute URI with optional fragment.
IPv6 (and later) literals have been added to the list of possible
identifiers for the host portion of an authority component, as
described by [RFC2732], with the addition of "[" and "]" to the
reserved set and a version flag to anticipate future versions of IP
literals. Square brackets are now specified as reserved within the
authority component and are not allowed outside their use as
delimiters for an IP literal within host. In order to make this
change without changing the technical definition of the path, query,
and fragment components, those rules were redefined to directly
specify the characters allowed.
As [RFC2732] defers to [RFC3513] for definition of an IPv6 literal
address, which, unfortunately, lacks an ABNF description of
IPv6address, we created a new ABNF rule for IPv6address that matches
the text representations defined by Section 2.2 of [RFC3513].
Likewise, the definition of IPv4address has been improved in order to
limit each decimal octet to the range 0-255.
Section 6, on URI normalization and comparison, has been completely
rewritten and extended by using input from Tim Bray and discussion
within the W3C Technical Architecture Group.
D.2. Modifications
The ad-hoc BNF syntax of RFC 2396 has been replaced with the ABNF of
[RFC2234]. This change required all rule names that formerly
included underscore characters to be renamed with a dash instead. In
addition, a number of syntax rules have been eliminated or simplified
to make the overall grammar more comprehensible. Specifications that
refer to the obsolete grammar rules may be understood by replacing
those rules according to the following table:
Berners-Lee, et al. Standards Track [Page 53]
RFC 3986 URI Generic Syntax January 2005
+----------------+--------------------------------------------------+
| obsolete rule | translation |
+----------------+--------------------------------------------------+
| absoluteURI | absolute-URI |
| relativeURI | relative-part [ "?" query ] |
| hier_part | ( "//" authority path-abempty / |
| | path-absolute ) [ "?" query ] |
| | |
| opaque_part | path-rootless [ "?" query ] |
| net_path | "//" authority path-abempty |
| abs_path | path-absolute |
| rel_path | path-rootless |
| rel_segment | segment-nz-nc |
| reg_name | reg-name |
| server | authority |
| hostport | host [ ":" port ] |
| hostname | reg-name |
| path_segments | path-abempty |
| param | * |
| | |
| uric | unreserved / pct-encoded / ";" / "?" / ":" |
| | / "@" / "&" / "=" / "+" / "$" / "," / "/" |
| | |
| uric_no_slash | unreserved / pct-encoded / ";" / "?" / ":" |
| | / "@" / "&" / "=" / "+" / "$" / "," |
| | |
| mark | "-" / "_" / "." / "!" / "~" / "*" / "'" |
| | / "(" / ")" |
| | |
| escaped | pct-encoded |
| hex | HEXDIG |
| alphanum | ALPHA / DIGIT |
+----------------+--------------------------------------------------+
Use of the above obsolete rules for the definition of scheme-specific
syntax is deprecated.
Section 2, on characters, has been rewritten to explain what
characters are reserved, when they are reserved, and why they are
reserved, even when they are not used as delimiters by the generic
syntax. The mark characters that are typically unsafe to decode,
including the exclamation mark ("!"), asterisk ("*"), single-quote
("'"), and open and close parentheses ("(" and ")"), have been moved
to the reserved set in order to clarify the distinction between
reserved and unreserved and, hopefully, to answer the most common
question of scheme designers. Likewise, the section on
percent-encoded characters has been rewritten, and URI normalizers
are now given license to decode any percent-encoded octets
Berners-Lee, et al. Standards Track [Page 54]
RFC 3986 URI Generic Syntax January 2005
corresponding to unreserved characters. In general, the terms
"escaped" and "unescaped" have been replaced with "percent-encoded"
and "decoded", respectively, to reduce confusion with other forms of
escape mechanisms.
The ABNF for URI and URI-reference has been redesigned to make them
more friendly to LALR parsers and to reduce complexity. As a result,
the layout form of syntax description has been removed, along with
the uric, uric_no_slash, opaque_part, net_path, abs_path, rel_path,
path_segments, rel_segment, and mark rules. All references to
"opaque" URIs have been replaced with a better description of how the
path component may be opaque to hierarchy. The relativeURI rule has
been replaced with relative-ref to avoid unnecessary confusion over
whether they are a subset of URI. The ambiguity regarding the
parsing of URI-reference as a URI or a relative-ref with a colon in
the first segment has been eliminated through the use of five
separate path matching rules.
The fragment identifier has been moved back into the section on
generic syntax components and within the URI and relative-ref rules,
though it remains excluded from absolute-URI. The number sign ("#")
character has been moved back to the reserved set as a result of
reintegrating the fragment syntax.
The ABNF has been corrected to allow the path component to be empty.
This also allows an absolute-URI to consist of nothing after the
"scheme:", as is present in practice with the "dav:" namespace
[RFC2518] and with the "about:" scheme used internally by many WWW
browser implementations. The ambiguity regarding the boundary
between authority and path has been eliminated through the use of
five separate path matching rules.
Registry-based naming authorities that use the generic syntax are now
defined within the host rule. This change allows current
implementations, where whatever name provided is simply fed to the
local name resolution mechanism, to be consistent with the
specification. It also removes the need to re-specify DNS name
formats here. Furthermore, it allows the host component to contain
percent-encoded octets, which is necessary to enable
internationalized domain names to be provided in URIs, processed in
their native character encodings at the application layers above URI
processing, and passed to an IDNA library as a registered name in the
UTF-8 character encoding. The server, hostport, hostname,
domainlabel, toplabel, and alphanum rules have been removed.
The resolving relative references algorithm of [RFC2396] has been
rewritten with pseudocode for this revision to improve clarity and
fix the following issues:
Berners-Lee, et al. Standards Track [Page 55]
RFC 3986 URI Generic Syntax January 2005
o [RFC2396] section 5.2, step 6a, failed to account for a base URI
with no path.
o Restored the behavior of [RFC1808] where, if the reference
contains an empty path and a defined query component, the target
URI inherits the base URI's path component.
o The determination of whether a URI reference is a same-document
reference has been decoupled from the URI parser, simplifying the
URI processing interface within applications in a way consistent
with the internal architecture of deployed URI processing
implementations. The determination is now based on comparison to
the base URI after transforming a reference to absolute form,
rather than on the format of the reference itself. This change
may result in more references being considered "same-document"
under this specification than there would be under the rules given
in RFC 2396, especially when normalization is used to reduce
aliases. However, it does not change the status of existing
same-document references.
o Separated the path merge routine into two routines: merge, for
describing combination of the base URI path with a relative-path
reference, and remove_dot_segments, for describing how to remove
the special "." and ".." segments from a composed path. The
remove_dot_segments algorithm is now applied to all URI reference
paths in order to match common implementations and to improve the
normalization of URIs in practice. This change only impacts the
parsing of abnormal references and same-scheme references wherein
the base URI has a non-hierarchical path.
Index
A
ABNF 11
absolute 27
absolute-path 26
absolute-URI 27
access 9
authority 17, 18
B
base URI 28
C
character encoding 4
character 4
characters 8, 11
coded character set 4
Berners-Lee, et al. Standards Track [Page 56]
RFC 3986 URI Generic Syntax January 2005
D
dec-octet 20
dereference 9
dot-segments 23
F
fragment 16, 24
G
gen-delims 13
generic syntax 6
H
h16 20
hier-part 16
hierarchical 10
host 18
I
identifier 5
IP-literal 19
IPv4 20
IPv4address 19, 20
IPv6 19
IPv6address 19, 20
IPvFuture 19
L
locator 7
ls32 20
M
merge 32
N
name 7
network-path 26
P
path 16, 22, 26
path-abempty 22
path-absolute 22
path-empty 22
path-noscheme 22
path-rootless 22
path-abempty 16, 22, 26
path-absolute 16, 22, 26
path-empty 16, 22, 26
Berners-Lee, et al. Standards Track [Page 57]
RFC 3986 URI Generic Syntax January 2005
path-rootless 16, 22
pchar 23
pct-encoded 12
percent-encoding 12
port 22
Q
query 16, 23
R
reg-name 21
registered name 20
relative 10, 28
relative-path 26
relative-ref 26
remove_dot_segments 33
representation 9
reserved 12
resolution 9, 28
resource 5
retrieval 9
S
same-document 27
sameness 9
scheme 16, 17
segment 22, 23
segment-nz 23
segment-nz-nc 23
sub-delims 13
suffix 27
T
transcription 8
U
uniform 4
unreserved 13
URI grammar
absolute-URI 27
ALPHA 11
authority 18
CR 11
dec-octet 20
DIGIT 11
DQUOTE 11
fragment 24
gen-delims 13
Berners-Lee, et al. Standards Track [Page 58]
RFC 3986 URI Generic Syntax January 2005
h16 20
HEXDIG 11
hier-part 16
host 19
IP-literal 19
IPv4address 20
IPv6address 20
IPvFuture 19
LF 11
ls32 20
OCTET 11
path 22
path-abempty 22
path-absolute 22
path-empty 22
path-noscheme 22
path-rootless 22
pchar 23
pct-encoded 12
port 22
query 24
reg-name 21
relative-ref 26
reserved 13
scheme 17
segment 23
segment-nz 23
segment-nz-nc 23
SP 11
sub-delims 13
unreserved 13
URI 16
URI-reference 25
userinfo 18
URI 16
URI-reference 25
URL 7
URN 7
userinfo 18
Berners-Lee, et al. Standards Track [Page 59]
RFC 3986 URI Generic Syntax January 2005
Authors' Addresses
Tim Berners-Lee
World Wide Web Consortium
Massachusetts Institute of Technology
77 Massachusetts Avenue
Cambridge, MA 02139
USA
Phone: +1-617-253-5702
Fax: +1-617-258-5999
EMail: timbl@w3.org
URI: http://www.w3.org/People/Berners-Lee/
Roy T. Fielding
Day Software
5251 California Ave., Suite 110
Irvine, CA 92617
USA
Phone: +1-949-679-2960
Fax: +1-949-679-2972
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/
Larry Masinter
Adobe Systems Incorporated
345 Park Ave
San Jose, CA 95110
USA
Phone: +1-408-536-3024
EMail: LMM@acm.org
URI: http://larry.masinter.net/
Berners-Lee, et al. Standards Track [Page 60]
RFC 3986 URI Generic Syntax January 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Berners-Lee, et al. Standards Track [Page 61]
ascript-build016/doc/releasenote-build006.txt 777 0 0 715 11375412211 14224 0 * ̃Ce[gł悤ɂȂ܂
{{{
str = "hoge"
for (ch in str) { println(ch) }
}}}
* range() interval() Ce[^Ԃ悤ɕύX܂B
* win32ole W[ǂ܂
* 쒆 COM T[oɂȂ win32ole.connect()
* win32ole.new():import_const Œ萔lǂݍ
* Ow
* Ce[^ԂIuWFNgɑăo}bsOL
{{{
worksheet.Range("A1:A4")::Value = [1, 2, 3, 4]
}}}
ascript-build016/doc/releasenote-build007.txt 777 0 0 1764 11375422712 14261 0 * SQLite3 W[쐬܂B''͂܂g܂B''
{{{
import(sqlite3)
Person = struct(name:string, email:string,
gender:string, age:number, birthday:string, mobile:string)
sqlite3.open("50records-en.sqlite3") {|db|
println(Person * db.query("select * from people"))
}
}}}
* Ce[^Ԃo}bsOIy[^ {{{:*}}} lj܂BXgԂo}bsOIy[^ {{{::}}} ёxȂ܂B
{{{
>>> rtn = ["first", "second", "third"]::len()
[5, 6, 5]
>>> rtn = ["first", "second", "third"]:*len()
>>> [rtn]
[5, 6, 5]
}}}
* E̊Ce[^Ԃ悤ɂ܂: {{{file#readlines()}}},
{{{csv.readlines()}}}, {{{reverse()}}}
* E̊Ce[^ɂƂ悤ɂ܂: {{{min()}}}, {{{max()}}},
{{{sum()}}}, {{{average()}}}, {{{len()}}}
* Xg̓eJԂ round() lj܂BCe[^Ԃ܂B
{{{
>>> [round([1, 2, 3], 10)]
[1, 2, 3, 1, 2, 3, 1, 2, 3, 1]
}}}
ascript-build016/doc/releasenote-build008.txt 777 0 0 1450 11400753772 14254 0 XgCe[^ŕ\镡f[^xɏłuÖٓI}bsOvƁuo}bsOvƂXNvgłB
* Linux ɑΉ܂BUbuntu 8.1.0 SourceForge.JP ̃RpCt@[œmFĂ܂B
{{{
$ tar xvfz ascript-build008-src.tar.gz
$ cd ascript-build008/src
$ ./configure
$ make
$ sudo make install
}}}
* Ce[^Iy[^ {{{..}}} ŏI[w肵ȂƂ͖ɂȂ@\lj܂B
{{{
>>> printf("%7d %s", (1..), open("hoge.txt").readlines())
}}}
* CX^X\bhւ̎QƂϐɑł悤ɂ܂B
{{{
>>> f = "hello world".left
>>> f(5)
"hello"
}}}
* Ce[^̑lj܂: {{{iterator#offset(n:number)}}},
{{{iterator#skip(n:number)}}}, {{{iterator#align(n:number, value?)}}}
ascript-build016/doc/releasenote-build009.txt 777 0 0 1552 11403260660 14250 0 XgCe[^ŕ\镡f[^xɏłuÖٓI}bsOv
uo}bsOvƂXNvgłB
* ̕R[h UTF-8 ɂ܂B
* \[Xt@C̕R[hw {{{"-*- coding: xxxx -*-"}}}B
* t@CI[v open ɕR[hẅlj:
{{{open(filename, mode, encoding)}}}B
̗ test/test-string.az QƂB
* sqlite3 W[œ{ꂪg悤ɂȂ܂B
* Pʂň悤ɏC
{{{
>>> "".len()
5
>>> ""[0]
""
>>> "".right(2)
""
}}}
* ёgݍ킹̌Ԃ List#permutation(), List#combination() lj
{{{
>>> [1, 2, 3].permutation():list
[[1, 2, 3], [1, 3, 2], [2, 1, 3], [2, 3, 1], [3, 1, 2], [3, 2, 1]]
>>> [1, 2, 3].combination(2):list
[[1, 2], [1, 3], [2, 3]]
}}}
ascript-build016/doc/releasenote-build010.txt 777 0 0 2432 11406424372 14243 0 XgCe[^ŕ\镡f[^xɏłuÖٓI}bsOv
uo}bsOvƂXNvgłB
* ticket:22136 C܂ (thanks for your report > yu-tang )
* oCif[^ bytes ^lj܂B
* f[^̐ {{{b"..."}}}
* f[^̍\zƒo pack()/unpack() ܂B
Python ƎtH[}bgŗpł܂B
{{{
>>> buff = pack(">BHL", 0x11, 0x2233, 0x01234567)
>>> buff.dump()
11 22 33 01 23 45 67
}}}
* f[^̃ItZbgǗ bytesptr ^lj܂B
f[^olĵɗpł܂B
{{{
>>> buff = b"\x00\x00\x10\x00\x20\x00\x30\x00\x40\x00\x50\x00"
>>> p = buff.pointer()
>>> p.unpack(">HH")
[0, 4096]
>>> p.unpack(">HH")
[8192, 12288]
}}}
* ̋̓IȎgp {{{test/test-bytes.az}}} QƂB
* R[fbNɈȉ̂̂lj܂BXNvgt@C̕R[hw
({{{# -*- coding: xxx -*-}}}) At@CI[v {{{open()}}} Ɏwł܂B
* euc-jp
* iso-8859-1 .. 16
* us-ascii
* utf-16
* ̓Ԃ {{{time.monthdays()}}}AjvZ {{{time.weekday()}}}A
邤N̔ {{{time.isleap()}}} lj܂B
g {{{sample/calendar.az}}} QƂĂB
ascript-build016/doc/releasenote-build011.txt 777 0 0 2607 11412675466 14261 0 XgCe[^ŕ\镡f[^xɏłuÖٓI}bsOv
uo}bsOvƂXNvgłB
* ɖߍނƂł镶^܂B
̐擪 {{{e}}} ƁA {{{${..} }}} ň͂܂ꂽ]܂B
{{{
>>> var = "hoge"
>>> text = e"hello ${var}-san"
"hello hoge-san"
}}}
sɂߍނƂł܂B
{{{
>>> [var1, var2] = ["hoge", "foo"]
>>> print(e"""\
... hello,
... ${var1}-san
... ${var2}-san
... """)
hello,
hoge-san
foo-san
}}}
* Xg̈WJ@\܂B
{{{
>>> f(x*) = println(x.join(" "))
>>> list1 = [3, 4]
>>> list2 = [6, 7, 8]
>>> f(1, 2, list1*, 5, list2*)
1 2 3 4 5 6 7 8
}}}
* 2 ȏ̃Xg܂̓Ce[^̑gݍ킹ɑČJԂ
t[ {{{cross()}}} lj܂B
{{{
>>> vec1 = [2, 4, 6]
>>> vec2 = [4, 3, -9]
>>> cross (x in vec1, y in vec2):list { x * y }
[8, 6, -18, 16, 12, -36, 24, 18, -54]
>>> cross (x in ["A", "B"], y in ["a", "b"], z in [1, 2]):list {
... format("%s:%s:%d", x, y, z)
... }
["A:a:1", "A:a:2", "A:b:1", "A:b:2", "B:a:1", "B:a:2", "B:b:1", "B:b:2"]
}}}
* ϐ̌^̈܂B
* W[Œ`ꂽ^QƂł悤ɉ
* ^̕ύX: List -> list, Dict -> dict, File -> file etc.
* XML W[ shift_jist euc-jp GR[fBOɑΉ܂B
* `Pbg #21810 C܂
ascript-build016/doc/releasenote-build012.txt 777 0 0 1753 11415715453 14255 0 XgCe[^ŕ\镡f[^xɏłuÖٓI}bsOv
uo}bsOvƂXNvgłB
* ŏ@ŋߎȐ̊ math.least_square() ܂B
Cӂ̎wł܂B
{{{
x = [1, 3, 5, 7, 9]
y = [3, 6, 5.5, 5, 7]
# generates: f(x) = 3.55 + 0.35 * x
f = math.least_square(x, y, 1)
# generates: g(x) = 2.94286 + 0.707143 * x - 0.0357143 * x ** 2
g = math.least_square(x, y, 2)
}}}
* }gNXNX܂B}gNXƃXg̎lZA
ыts̎Zoł܂BgṕA\[XfBNg
test/test-matrix.az QƂB
{{{
>>> m = @@{{2, 3, 1}, {1, 1, 0}, {1, -1, -1}}
>>> minv = m.inverse()
@@{{1, -2, 1}, {-1, 3, -1}, {2, -5, 1}}
>>> m * minv
@@{{1, 0, 0}, {-1.11022e-16, 1, 0}, {0, 0, 1}}
>>> minv * [2, 3, 1]
[-3, 6, -10]
>>> m[0][1] = 99
>>> m
@@{{2, 99, 1}, {1, 1, 0}, {1, -1, -1}}
}}}
* XgECe[^ɑ鑀܂B
* `Pbg #22035, #21694 ܂B
ascript-build016/doc/releasenote-build013.txt 777 0 0 2472 11417767430 14261 0 XgCe[^ŕ\镡f[^xɏłuÖٓI}bsOv
uo}bsOvƂXNvgłB
* xWGȐ̊ math.bezier() ܂
{{{
# generates bezier functions f_x(t:number) and f_y(t:number)
# from a list of points:
# [6, 12], [10, 4], [16, 6], [20, 10]
[f_x, f_y] = math.bezier([6, 10, 16, 20], [12, 4, 6, 10])
# prints a list of points on a bezier curve
t = interval(0, 1, 50) # 0 <= t <= 1, 50 samples
println(format("[%f,%f]", f_x(t), f_y(t)).join(", "))
}}}
* math.diff() ܂B
{{{
>>> f = `(x ** 2 * math.sin(x))
>>> math.diff(f, `x)
`(2 * x * math.sin(x) + x ** 2 * math.cos(x))
>>> g(x) = !!math.diff(f, `x) # use !! operator to force evaluation before function assignment
}}}
* œK math.optimize() ܂ (܂ł悭܂)B
* xNg̃hbgςvZ math.dot_product() ܂B
* xNg̃NXςvZ math.cross_product() ܂B
* UlvZ list#variance(), iterator#variance() ܂B
* JԂ for(), cross() ɂāAzvf̓WJł悤ɂ܂B
{{{
for ([x, y] in [[1, 2], [3, 4], [5, 6]]) { printf("%d-%d\n", x, y) }
}}}
* ɃXgw肳ꂽɃCe[^nƂALXg@\lj܂B
ascript-build016/doc/releasenote-build014.txt 777 0 0 1710 11422672402 14242 0 XgCe[^ŕ\镡f[^xɏłuÖٓI}bsOv
uo}bsOvƂXNvgłB
* ̃wv\ {{{help(func:function)}}} lj܂B
ɊIuWFNgn܂B\bh̏ꍇ́AKȃIuWFNg
help ɓnAclassref g܂B
{{{
>>> help([].len)
>>> help(classref(`list).len)
}}}
AScript ͌ 300 قǂ̊у\bhĂ܂A
wv̎ 30% łBAg[Ă܂B
* time.timedelta ^ljA^ time.datetime ̉Z܂B
{{{
>>> time.now()
>>> time.today()
>>> printf("hot days:%d\n", (time.datetime(2010, 9, 23) - time.today()).days())
60
}}}
* URI uri NX܂B
* WlvZ {{{list#stddev()}}}, {{{iterator#stddev()}}} lj܂
* UlvZ {{{math.covariance()}}} lj܂
ascript-build016/doc/releasenote-build015.txt 777 0 0 1467 11426460355 14262 0 XgCe[^ŕ\镡f[^xɏłuÖٓI}bsOv
uo}bsOvƂXNvgłB
* Win32 p̃oCiŁAXNvg̖{̂ DLL ܂B
* JԂ repeat(), while(), for(), cross() ɃAgr[g
:iter, :xiter w肵ƂACe[^Ԃ@\lj܂B
{{{
>>> i = for (x in 1..10):iter { x * 2 }
>>> i.next()
2
>>> i.next()
4
}}}
gƁAPython generator ̂悤ȋ@\ł܂B
ȉ͑f̖̗łB
{{{
primes() = {
p = []
for (n in 2..):xiter {
if (!(n % p == 0).or()) {
p.add!(n)
n
}
}
}
}}}
L̊gāA100 Ԗڂ܂ł̑f\܂B
{{{
println(primes().head(100))
}}}
100 ̑f\܂B
{{{
p = primes()
println(p.while(p < 100))
}}}
ascript-build016/doc/releasenote-build016.txt 777 0 0 2560 11433577267 14267 0 XgCe[^ŕ\镡f[^xɏłuÖٓI}bsOv
uo}bsOvƂXNvgłB
* GUI œ삷VF쐬܂B
ascript-build016-win32.zip ascriptshell.exe sĂB
݂̂Ƃ Win32 p݂̂łB
* Ctrl+D Ŏs̃XNvg𒆒fł܂B
* [File]-[Open] ŃXNvgt@Cs܂B
* [Window]-[Config] Ń|bvAbvRtBO[VEBhE
tHg̑傫Fς܂B
* [Window]-[Scribble] ŃOtBbN`łEBhEJ܂B
fvOȉɎ܂ (VFɃy[Xg Return ͂Ǝsł܂)B
{{{
create_object() = {
[size, theta] = [rand(100) + 50, rand(2 * math.pi)]
[x, y] = [rand(400), rand(300)]
[x0, y0] = [x + size / 2, y + size / 2]
repeat ():iter {
x1 = x0 + math.cos(theta) * size / 2
y1 = y0 + math.sin(theta) * size / 2
scribble.setpen("green", 2)
scribble.ellipse(x, y, size, size)
scribble.setpen("black", 2)
scribble.line(x0, y0, x1, y1)
scribble.setpen("red")
scribble.setbrush("red")
scribble.rectangle(x1 - 5, y1 - 5, 10, 10):fill
theta += math.pi / 30
}
}
objs = repeat(10):list { create_object() }
repeat {
scribble.burst {
scribble.clear()
objs::next()
}
time.sleep(.01)
}
}}}
* os.getcwd(), os.chdir() lj܂B
ascript-build016/lib/ 777 0 0 0 11433577324 7601 5 ascript-build016/lib/calendar.az 777 0 0 2634 11421472570 11770 0 #!/usr/bin/env ascript
calendar(year:number, weekoffset:number => 0, ncols:number => 3) = {
calOfMonth(year:number, month:number) = {
offsetFirst = (time.weekday(year, month, 1) + 7 - weekoffset) % 7
days = [fill(offsetFirst, " "),
(1..time.monthdays(year, month)).format("%2d")]
days.fold(7).align(6, []):*align(7, " "):*join(" ")
}
monthNames = [
"", "January", "February", "March", "April", "May", "June",
"July", "August", "September", "October", "November", "December",
]
weekAbbrs = ["Su", "Mo", "Tu", "We", "Th", "Fr", "Sa"]
weekAbbrs = weekAbbrs.round(7 + weekoffset).offset(weekoffset):list
weekLine = weekAbbrs.join(" ")
wdPerMonth = 3 * 7 - 1
wdSep = 6
sep = " " * wdSep
rtn = []
rtn.add!(format("%04d", year).align((wdPerMonth + wdSep) * ncols - wdSep):center)
rtn.add!("")
repeat (math.ceil(12 / ncols)) {|iRow|
month = iRow * ncols + 1
ncolsCur = min(ncols, 12 - month + 1)
months = [month..(month + ncolsCur - 1)]
rtn.add!((monthNames[months]:*align(wdPerMonth):center).join(sep))
rtn.add!(repeat(ncolsCur):list { weekLine }.join(sep))
lines = repeat(6):list { "" }
repeat (ncolsCur) {|iCol|
if (iCol > 0) { lines += sep }
lines += calOfMonth(year, month + iCol)
}
rtn.add!(lines)
}
}
calendar.help("""\
""")
if (__name__ == "__main__") {
year = if (sys.argv.len() < 2) {
time.localtime().year()
} else {
tonumber(sys.argv[1])
}
println(calendar(year))
}
ascript-build016/lib/graph.az 777 0 0 6503 11421226726 11317 0 import(canvas)
create_emf = canvas.create_emf
Item = struct(x:iterator, y:iterator, style:symbol, color => `black)
draw(c:canvas.canvas, items+:Item) {block?:inside_scope} = {
xCollect = items:*x:*each():list
yCollect = items:*y:*each():list
[xMax, xMin] = [xCollect::max().max(), xCollect::min().min()]
[yMax, yMin] = [yCollect::max().max(), yCollect::min().min()]
[wdMgn, htMgn] = [c.width() * .1, c.height() * .05]
[wdGraph, htGraph] = [c.width() - wdMgn * 2, c.height() - htMgn * 2]
[xOff, yOff] = [wdMgn, htMgn]
nScales = [1, 2, 5, 10, 20, 50, 100, 200, 500, 1000]
xRange = xMax - xMin
yRange = yMax - yMin
if (xRange == 0) { xRange = 1 }
if (yRange == 0) { yRange = 1 }
screen_x(x):map = (x - xMin) * wdGraph / xRange + xOff
screen_y(y):map = (y - yMin) * htGraph / yRange + yOff
DrawText(x, y, str) = c.moveto(screen_x(x), screen_y(y)).text(str)
DrawTicks(tMin:number, tMax:number, tRange:number, DrawTick:function) = {
tStepBase = 10 ** (int(math.log10(tRange)) - 2)
for (nScale in nScales) {
tStep = tStepBase * nScale
if (tRange / tStep < 20) { break() }
}
if (tMin > 0) {
DrawTick(range(math.floor(tMin / tStep) * tStep, tMax, tStep))
} elsif (tMax < 0) {
DrawTick(range(math.floor(tMax / tStep) * tStep, tMin, -tStep))
} else {
if (tMax > 0) {
DrawTick(range(tStep, tMax, tStep))
}
if (tMin < 0) {
DrawTick(range(-tStep, tMin, -tStep))
}
}
}
DrawTickX(x:number, str:string => nil):map:void = {
if (str == nil) { str = tostring(x) }
c.moveto(screen_x(x), screen_y(0) - 1).text(str):n
c.line(screen_x(x), screen_y(0) - 1, screen_x(x), screen_y(0) + 1)
}
DrawTickY(y:number, str:string => nil):map:void = {
if (str == nil) { str = tostring(y) }
c.moveto(screen_x(0) - 1, screen_y(y)).text(str):e
c.line(screen_x(0), screen_y(y), screen_x(0) + 1, screen_y(y))
}
DrawTicksX() = DrawTicks(xMin, xMax, xRange, DrawTickX)
DrawTicksY() = DrawTicks(yMin, yMax, yRange, DrawTickY)
DrawAxis() = {
c.setpen(`black, 1, `solid)
c.line(screen_x(0), yOff, screen_x(0), yOff + htGraph)
c.line(xOff, screen_y(0), xOff + wdGraph, screen_y(0))
}
for (item in items) {
if (item.style == `circle) {
c.setpen(nil)
c.setbrush(item.color, `solid)
for (x in item.x, y in item.y) {
c.moveto(screen_x(x) - 1, screen_y(y) - 1).ellipse(2, 2)
}
} elsif (item.style == `box) {
c.setpen(nil)
c.setbrush(item.color, `solid)
for (x in item.x, y in item.y) {
c.moveto(screen_x(x) - 1, screen_y(y) - 1).rectangle(2, 2)
}
} else {
c.setpen(item.color, 1, item.style)
c.polyline(screen_x(item.x):list, screen_y(item.y):list)
}
}
c.setfont(c.height() / 30, family => `swiss)
if (block != nil) { block(c) }
c.close()
}
draw.help("""\
Draw dots or lines on a canvas for specified items. Each item contains
x and y coordinates, style and color. style takes one of: `circle, `box,
`solid, `dot, `dash and `dot_dash. color takes a list of RGB values, a string
or a symbol, and they're like [128, 64, 255], "#8040ff" and `black.
Symbols for colors are: `black, `blue, `green, `light_green, `red, `cyan,
`yellow, `white and `grey.
Example:
graph.draw(c, Item(x, y, `solid, `black))
""")
if (__name__ == "__main__") {
x = interval(-10, 10, 100)
create_emf("test.emf", 150, 150) {|c|
draw(c, Item(x, x * x / 10, `solid, `black)) {
DrawAxis()
DrawTicksX()
DrawTicksY()
}
}
} ascript-build016/sample/ 777 0 0 0 11433577323 10313 5 ascript-build016/sample/dump.az 777 0 0 1024 11415015314 11657 0 #!/usr/bin/env ascript
# dump
dump(fileName:string, nCols:number => 16) = {
tochar(num:number):map = {
if (0x20 <= num && num < 0x7f) { chr(num) } else { "." }
}
wdAddr = 6
wdData = nCols * 3
open(fileName, "rb") {|f|
while (buff = f.read(nCols)) {|iRow|
addr = iRow * nCols
printf("%0*x %-*s %s\n", wdAddr, addr, wdData,
format("%02x", buff.each()).join(" "),
tochar(buff.each()).join())
}
}
}
if (sys.argv.len() < 2) {
sys.stderr.println("usage: dump.az file")
sys.exit()
}
dump(sys.argv[1], 16)
ascript-build016/sample/eightqueen-resolver.az 777 0 0 2551 11417263154 14726 0 # not work yet!!
Board = class {
__init__() = {
self.cells = repeat (8 * 8):list { 0 }
}
PutQueen(id:number, iCell0:number) = {
bit = 1 << id
[iCol0, iRow0] = [iCell0 % 8, int(iCell0 / 8)]
iCell = iRow0 * 8
repeat (8) { self.cells[iCell] |= bit, iCell += 1 }
iCell = iCol0
repeat (8) { self.cells[iCell] |= bit, iCell += 8 }
if (iCol0 <= iRow0) {
nOffset = iRow0 - iCol0
iCell = nOffset * 8
} else {
nOffset = iCol0 - iRow0
iCell = nOffset
}
repeat (8 - nOffset) { self.cells[iCell] |= bit, iCell += 9 }
if (iCol0 <= 7 - iRow0) {
nOffset = 7 - iRow0 - iCol0
iCell = (7 - nOffset) * 8
} else {
nOffset = iCol0 - (7 - iRow0)
iCell = nOffset
}
repeat (8 - nOffset) { self.cells[iCell] |= bit, iCell -= 7 }
}
RemoveQueen(id:number) = {
mask = ~(1 << id)
repeat (8 * 8) {|iCell| self.cells[iCell] &= mask }
}
Print() = {
self.cells.fold(8) {|nums|
println(chooseif(nums == 0, ".", "*").join(" "))
}
}
SeekEmpty(iCell:number) = {
while (iCell < 8 * 8) {
(self.cells[iCell] == 0) && break
iCell += 1
}
iCell
}
}
board = Board()
Solve(id:number, iCell:number) = {
if (id == 8) {
board.Print()
return(true)
}
iCell = board.SeekEmpty(iCell)
(iCell >= 8 * 8) && return(false)
board.PutQueen(id, iCell)
board.Print()
rtn = Solve(id + 1, iCell + 1)
!rtn && board.RemoveQueen(id)
rtn
}
Solve(0, 0)
ascript-build016/sample/hello.az 777 0 0 61 11405765430 11767 0 #!/usr/bin/env ascript
printf("Hello World\n")
ascript-build016/sample/parse-services.az 777 0 0 656 11416753252 13652 0 import(re)
fileName = "services"
protocolNameMap = %{
"tcp" => "IPPROTO_TCP"
"udp" => "IPPROTO_UDP"
}
lines = open(fileName).readlines()
for ([serviceName, portNumber, protocol] in \
re.match(r"^(\w+)\s+(\d+)/(\w+)", lines).skipnil():*group(1, 2, 3)) {
text = format('{ "%s",', serviceName)
tabs = "\t" * (6 - (int(text.len() / 4) + 1))
printf('%s%s%4d, %s },\n', text, tabs, int(portNumber), protocolNameMap[protocol])
}
ascript-build016/sample/resolver.az 777 0 0 6663 11406305600 12571 0 #!/usr/bin/env ascript
lambda {
sys.echo(true)
Coord = struct(x:number, y:number) {
__str__() = format("[%d,%d]", self.x, self.y)
}
Piece = class {
__init__(patterns[]) = {
self.patterns = Coord * patterns
}
print() = println(self.patterns):nomap
}
pieces = [
// *****
Piece([
[[0, 0], [0, 1], [0, 2], [0, 3], [0, 4]],
[[0, 0], [1, 0], [2, 0], [3, 0], [4, 0]],
]),
// ****
// *
Piece([
[[0, 0], [0, 1], [0, 2], [0, 3], [1, 3]],
[[0, 0], [0, 1], [0, 2], [0, 3], [-1, 3]],
[[0, 0], [0, 1], [0, 2], [0, 3], [1, 0]],
[[0, 0], [1, 0], [1, 1], [1, 2], [1, 3]],
[[0, 0], [1, 0], [2, 0], [3, 0], [3, 1]],
[[0, 0], [1, 0], [2, 0], [3, 0], [0, 1]],
[[0, 0], [0, 1], [1, 1], [2, 1], [3, 1]],
[[0, 0], [-3, 1], [-2, 1], [-1, 1], [0, 1]],
]),
// ****
// *
Piece([
[[0, 0], [0, 1], [0, 2], [0, 3], [1, 2]],
[[0, 0], [0, 1], [0, 2], [0, 3], [-1, 2]],
[[0, 0], [0, 1], [0, 2], [0, 3], [1, 1]],
[[0, 0], [0, 1], [0, 2], [0, 3], [-1, 1]],
[[0, 0], [1, 0], [2, 0], [3, 0], [2, 1]],
[[0, 0], [1, 0], [2, 0], [3, 0], [1, 1]],
[[0, 0], [-1, 1], [0, 1], [1, 1], [2, 1]],
[[0, 0], [-2, 1], [-1, 1], [0, 1], [1, 1]],
]),
// ***
// *
// *
Piece([
[[0, 0], [1, 0], [2, 0], [1, 1], [1, 2]],
[[0, 0], [0, 1], [1, 1], [2, 1], [0, 2]],
[[0, 0], [0, 1], [0, 2], [-1, 2], [1, 2]],
[[0, 0], [0, 1], [0, 2], [-1, 1], [-2, 1]],
]),
// *
// ***
// *
Piece([
[[0, 0], [0, 1], [1, 1], [2, 1], [2, 2]],
[[0, 0], [-2, 1], [-1, 1], [0, 1], [-2, 2]],
[[0, 0], [0, 1], [0, 2], [1, 0], [-1, 2]],
[[0, 0], [1, 0], [1, 1], [1, 2], [2, 2]],
]),
// *
// ***
// *
Piece([
[[0, 0], [0, 1], [1, 1], [2, 1], [1, 2]],
[[0, 0], [-2, 1], [-1, 1], [0, 1], [-1, 2]],
[[0, 0], [0, 1], [0, 2], [1, 0], [-1, 1]],
[[0, 0], [1, 0], [1, 1], [1, 2], [2, 1]],
]),
// *
// ***
// *
Piece([
[[0, 0], [0, 1], [0, 2], [-1, 1], [1, 1]],
]),
// *
// **
// **
Piece([
[[0, 0], [0, 1], [0, 2], [1, 1], [1, 2]],
[[0, 0], [0, 1], [0, 2], [-1, 1], [-1, 2]],
[[0, 0], [0, 1], [0, 2], [1, 0], [1, 1]],
[[0, 0], [0, 1], [1, 0], [1, 1], [1, 2]],
[[0, 0], [1, 0], [2, 0], [0, 1], [1, 1]],
[[0, 0], [1, 0], [2, 0], [1, 1], [2, 1]],
[[0, 0], [1, 0], [0, 1], [1, 1], [2, 1]],
[[0, 0], [1, 0], [-1, 1], [0, 1], [1, 1]],
]),
// * *
// ***
Piece([
[[0, 0], [2, 0], [0, 1], [1, 1], [2, 1]],
[[0, 0], [1, 0], [2, 0], [0, 1], [2, 1]],
[[0, 0], [0, 2], [1, 0], [1, 1], [1, 2]],
[[0, 0], [0, 1], [0, 2], [1, 0], [1, 2]],
]),
// *
// *
// ***
Piece([
[[0, 0], [0, 1], [0, 2], [1, 2], [2, 2]],
[[0, 0], [0, 1], [0, 2], [-2, 2], [-1, 2]],
[[0, 0], [0, 1], [0, 2], [1, 0], [2, 0]],
[[0, 0], [1, 0], [2, 0], [2, 1], [2, 2]],
]),
// **
// ***
Piece([
[[0, 0], [1, 0], [-2, 1], [-1, 1], [0, 1]],
[[0, 0], [1, 0], [1, 1], [2, 1], [3, 1]],
[[0, 0], [1, 0], [2, 0], [2, 1], [3, 1]],
[[0, 0], [1, 0], [2, 0], [-1, 1], [0, 1]],
[[0, 0], [0, 1], [1, 1], [1, 2], [1, 3]],
[[0, 0], [0, 1], [-1, 1], [-1, 2], [-1, 3]],
[[0, 0], [0, 1], [0, 2], [-1, 2], [-1, 3]],
[[0, 0], [0, 1], [0, 2], [1, 2], [1, 3]],
]),
// *
// **
// **
Piece([
[[0, 0], [0, 1], [1, 1], [1, 2], [2, 2]],
[[0, 0], [0, 1], [-1, 1], [-1, 2], [-2, 2]],
[[0, 0], [1, 0], [-1, 1], [0, 1], [-1, 2]],
[[0, 0], [1, 0], [1, 1], [2, 1], [2, 2]],
]),
// **
// **
Piece([
[[0, 0], [1, 0], [0, 1], [1, 1]],
])
]
pieces::print()
}()
ascript-build016/sample/services 777 0 0 27130 11416753252 12165 0 # Copyright (c) 1993-1999 Microsoft Corp.
#
# This file contains port numbers for well-known services defined by IANA
#
# Format:
#
# / [aliases...] [#]
#
echo 7/tcp
echo 7/udp
discard 9/tcp sink null
discard 9/udp sink null
systat 11/tcp users #Active users
systat 11/tcp users #Active users
daytime 13/tcp
daytime 13/udp
qotd 17/tcp quote #Quote of the day
qotd 17/udp quote #Quote of the day
chargen 19/tcp ttytst source #Character generator
chargen 19/udp ttytst source #Character generator
ftp-data 20/tcp #FTP, data
ftp 21/tcp #FTP. control
telnet 23/tcp
smtp 25/tcp mail #Simple Mail Transfer Protocol
time 37/tcp timserver
time 37/udp timserver
rlp 39/udp resource #Resource Location Protocol
nameserver 42/tcp name #Host Name Server
nameserver 42/udp name #Host Name Server
nicname 43/tcp whois
domain 53/tcp #Domain Name Server
domain 53/udp #Domain Name Server
bootps 67/udp dhcps #Bootstrap Protocol Server
bootpc 68/udp dhcpc #Bootstrap Protocol Client
tftp 69/udp #Trivial File Transfer
gopher 70/tcp
finger 79/tcp
http 80/tcp www www-http #World Wide Web
kerberos 88/tcp krb5 kerberos-sec #Kerberos
kerberos 88/udp krb5 kerberos-sec #Kerberos
hostname 101/tcp hostnames #NIC Host Name Server
iso-tsap 102/tcp #ISO-TSAP Class 0
rtelnet 107/tcp #Remote Telnet Service
pop2 109/tcp postoffice #Post Office Protocol - Version 2
pop3 110/tcp #Post Office Protocol - Version 3
sunrpc 111/tcp rpcbind portmap #SUN Remote Procedure Call
sunrpc 111/udp rpcbind portmap #SUN Remote Procedure Call
auth 113/tcp ident tap #Identification Protocol
uucp-path 117/tcp
nntp 119/tcp usenet #Network News Transfer Protocol
ntp 123/udp #Network Time Protocol
epmap 135/tcp loc-srv #DCE endpoint resolution
epmap 135/udp loc-srv #DCE endpoint resolution
netbios-ns 137/tcp nbname #NETBIOS Name Service
netbios-ns 137/udp nbname #NETBIOS Name Service
netbios-dgm 138/udp nbdatagram #NETBIOS Datagram Service
netbios-ssn 139/tcp nbsession #NETBIOS Session Service
imap 143/tcp imap4 #Internet Message Access Protocol
pcmail-srv 158/tcp #PCMail Server
snmp 161/udp #SNMP
snmptrap 162/udp snmp-trap #SNMP trap
print-srv 170/tcp #Network PostScript
bgp 179/tcp #Border Gateway Protocol
irc 194/tcp #Internet Relay Chat Protocol
ipx 213/udp #IPX over IP
ldap 389/tcp #Lightweight Directory Access Protocol
https 443/tcp MCom
https 443/udp MCom
microsoft-ds 445/tcp
microsoft-ds 445/udp
kpasswd 464/tcp # Kerberos (v5)
kpasswd 464/udp # Kerberos (v5)
isakmp 500/udp ike #Internet Key Exchange
exec 512/tcp #Remote Process Execution
biff 512/udp comsat
login 513/tcp #Remote Login
who 513/udp whod
cmd 514/tcp shell
syslog 514/udp
printer 515/tcp spooler
talk 517/udp
ntalk 518/udp
efs 520/tcp #Extended File Name Server
router 520/udp route routed
timed 525/udp timeserver
tempo 526/tcp newdate
courier 530/tcp rpc
conference 531/tcp chat
netnews 532/tcp readnews
netwall 533/udp #For emergency broadcasts
uucp 540/tcp uucpd
klogin 543/tcp #Kerberos login
kshell 544/tcp krcmd #Kerberos remote shell
new-rwho 550/udp new-who
remotefs 556/tcp rfs rfs_server
rmonitor 560/udp rmonitord
monitor 561/udp
ldaps 636/tcp sldap #LDAP over TLS/SSL
doom 666/tcp #Doom Id Software
doom 666/udp #Doom Id Software
kerberos-adm 749/tcp #Kerberos administration
kerberos-adm 749/udp #Kerberos administration
kerberos-iv 750/udp #Kerberos version IV
kpop 1109/tcp #Kerberos POP
phone 1167/udp #Conference calling
ms-sql-s 1433/tcp #Microsoft-SQL-Server
ms-sql-s 1433/udp #Microsoft-SQL-Server
ms-sql-m 1434/tcp #Microsoft-SQL-Monitor
ms-sql-m 1434/udp #Microsoft-SQL-Monitor
wins 1512/tcp #Microsoft Windows Internet Name Service
wins 1512/udp #Microsoft Windows Internet Name Service
ingreslock 1524/tcp ingres
l2tp 1701/udp #Layer Two Tunneling Protocol
pptp 1723/tcp #Point-to-point tunnelling protocol
radius 1812/udp #RADIUS authentication protocol
radacct 1813/udp #RADIUS accounting protocol
nfsd 2049/udp nfs #NFS server
knetd 2053/tcp #Kerberos de-multiplexor
man 9535/tcp #Remote Man Server
sapdp00 3200/tcp
sapdp01 3201/tcp
sapdp02 3202/tcp
sapdp03 3203/tcp
sapdp04 3204/tcp
sapdp05 3205/tcp
sapdp06 3206/tcp
sapdp07 3207/tcp
sapdp08 3208/tcp
sapdp09 3209/tcp
sapdp10 3210/tcp
sapdp11 3211/tcp
sapdp12 3212/tcp
sapdp13 3213/tcp
sapdp14 3214/tcp
sapdp15 3215/tcp
sapdp16 3216/tcp
sapdp17 3217/tcp
sapdp18 3218/tcp
sapdp19 3219/tcp
sapdp20 3220/tcp
sapdp21 3221/tcp
sapdp22 3222/tcp
sapdp23 3223/tcp
sapdp24 3224/tcp
sapdp25 3225/tcp
sapdp26 3226/tcp
sapdp27 3227/tcp
sapdp28 3228/tcp
sapdp29 3229/tcp
sapdp30 3230/tcp
sapdp31 3231/tcp
sapdp32 3232/tcp
sapdp33 3233/tcp
sapdp34 3234/tcp
sapdp35 3235/tcp
sapdp36 3236/tcp
sapdp37 3237/tcp
sapdp38 3238/tcp
sapdp39 3239/tcp
sapdp40 3240/tcp
sapdp41 3241/tcp
sapdp42 3242/tcp
sapdp43 3243/tcp
sapdp44 3244/tcp
sapdp45 3245/tcp
sapdp46 3246/tcp
sapdp47 3247/tcp
sapdp48 3248/tcp
sapdp49 3249/tcp
sapdp50 3250/tcp
sapdp51 3251/tcp
sapdp52 3252/tcp
sapdp53 3253/tcp
sapdp54 3254/tcp
sapdp55 3255/tcp
sapdp56 3256/tcp
sapdp57 3257/tcp
sapdp58 3258/tcp
sapdp59 3259/tcp
sapdp60 3260/tcp
sapdp61 3261/tcp
sapdp62 3262/tcp
sapdp63 3263/tcp
sapdp64 3264/tcp
sapdp65 3265/tcp
sapdp66 3266/tcp
sapdp67 3267/tcp
sapdp68 3268/tcp
sapdp69 3269/tcp
sapdp70 3270/tcp
sapdp71 3271/tcp
sapdp72 3272/tcp
sapdp73 3273/tcp
sapdp74 3274/tcp
sapdp75 3275/tcp
sapdp76 3276/tcp
sapdp77 3277/tcp
sapdp78 3278/tcp
sapdp79 3279/tcp
sapdp80 3280/tcp
sapdp81 3281/tcp
sapdp82 3282/tcp
sapdp83 3283/tcp
sapdp84 3284/tcp
sapdp85 3285/tcp
sapdp86 3286/tcp
sapdp87 3287/tcp
sapdp88 3288/tcp
sapdp89 3289/tcp
sapdp90 3290/tcp
sapdp91 3291/tcp
sapdp92 3292/tcp
sapdp93 3293/tcp
sapdp94 3294/tcp
sapdp95 3295/tcp
sapdp96 3296/tcp
sapdp97 3297/tcp
sapdp98 3298/tcp
sapdp99 3299/tcp
sapgw00 3300/tcp
sapgw01 3301/tcp
sapgw02 3302/tcp
sapgw03 3303/tcp
sapgw04 3304/tcp
sapgw05 3305/tcp
sapgw06 3306/tcp
sapgw07 3307/tcp
sapgw08 3308/tcp
sapgw09 3309/tcp
sapgw10 3310/tcp
sapgw11 3311/tcp
sapgw12 3312/tcp
sapgw13 3313/tcp
sapgw14 3314/tcp
sapgw15 3315/tcp
sapgw16 3316/tcp
sapgw17 3317/tcp
sapgw18 3318/tcp
sapgw19 3319/tcp
sapgw20 3320/tcp
sapgw21 3321/tcp
sapgw22 3322/tcp
sapgw23 3323/tcp
sapgw24 3324/tcp
sapgw25 3325/tcp
sapgw26 3326/tcp
sapgw27 3327/tcp
sapgw28 3328/tcp
sapgw29 3329/tcp
sapgw30 3330/tcp
sapgw31 3331/tcp
sapgw32 3332/tcp
sapgw33 3333/tcp
sapgw34 3334/tcp
sapgw35 3335/tcp
sapgw36 3336/tcp
sapgw37 3337/tcp
sapgw38 3338/tcp
sapgw39 3339/tcp
sapgw40 3340/tcp
sapgw41 3341/tcp
sapgw42 3342/tcp
sapgw43 3343/tcp
sapgw44 3344/tcp
sapgw45 3345/tcp
sapgw46 3346/tcp
sapgw47 3347/tcp
sapgw48 3348/tcp
sapgw49 3349/tcp
sapgw50 3350/tcp
sapgw51 3351/tcp
sapgw52 3352/tcp
sapgw53 3353/tcp
sapgw54 3354/tcp
sapgw55 3355/tcp
sapgw56 3356/tcp
sapgw57 3357/tcp
sapgw58 3358/tcp
sapgw59 3359/tcp
sapgw60 3360/tcp
sapgw61 3361/tcp
sapgw62 3362/tcp
sapgw63 3363/tcp
sapgw64 3364/tcp
sapgw65 3365/tcp
sapgw66 3366/tcp
sapgw67 3367/tcp
sapgw68 3368/tcp
sapgw69 3369/tcp
sapgw70 3370/tcp
sapgw71 3371/tcp
sapgw72 3372/tcp
sapgw73 3373/tcp
sapgw74 3374/tcp
sapgw75 3375/tcp
sapgw76 3376/tcp
sapgw77 3377/tcp
sapgw78 3378/tcp
sapgw79 3379/tcp
sapgw80 3380/tcp
sapgw81 3381/tcp
sapgw82 3382/tcp
sapgw83 3383/tcp
sapgw84 3384/tcp
sapgw85 3385/tcp
sapgw86 3386/tcp
sapgw87 3387/tcp
sapgw88 3388/tcp
sapgw89 3389/tcp
sapgw90 3390/tcp
sapgw91 3391/tcp
sapgw92 3392/tcp
sapgw93 3393/tcp
sapgw94 3394/tcp
sapgw95 3395/tcp
sapgw96 3396/tcp
sapgw97 3397/tcp
sapgw98 3398/tcp
sapgw99 3399/tcp
sapmsD90 3615/tcp
sapmsP58 3600/tcp
sapmsP87 3665/tcp
sapmsQ87 3621/tcp
sapmsPC1 3670/tcp
sapmsPBG 3675/tcp
sapmsPCM 3685/tcp
sapmsQCM 3654/tcp
sapmsP27 3602/tcp
sapmsQ98 3652/tcp
sapmsPBD 3655/tcp
sapmsD33 3600/tcp
sapmsP98 3650/tcp
sapmsKP1 3607/tcp
sapmsDBT 3630/tcp
sapmsQBT 3635/tcp
sapmsPBT 3605/tcp
sapmsQGJ 3650/tcp
sapmsPB7 3609/tcp
sapmsQB7 3607/tcp
sapmsE87 3663/tcp
sapmsP13 3600/tcp
sapmsP82 3665/tcp
sapmsP72 3625/tcp
sapmsSIP 3680/tcp
sapmsSIQ 3685/tcp
sapmsQ74 3602/tcp
sapmsP74 3604/tcp
sapmsQ38 3600/tcp
sapmsP38 3610/tcp
sapmsLBV 3620/tcp
sapmsPBV 3600/tcp
sapmsP81 3600/tcp
sapmsP62 3680/tcp
sapmsP64 3600/tcp
sapmsP67 3600/tcp
sapmsP97 3605/tcp
sapmsPGJ 3610/tcp
sapmsPCH 3615/tcp
sapmsQ97 3625/tcp
sapmsP90 3600/tcp
sapmsQBV 3625/tcp
sapmsPR1 3602/tcp
sapmsPR2 3603/tcp
sapmsPQI 3605/tcp
sapmsQ90 3620/tcp
sapmsPBF 3660/tcp
sapmsPB8 3610/tcp
sapmsPBE 3612/tcp
sapmsP23 3600/tcp
ascript-build016/sample/standalone-sample.bat 777 0 0 655 11374652327 14465 0 @rem /*
@echo off
if "%OS%" == "Windows_NT" goto WinNT
ascript "%0" %1 %2 %3 %4 %5 %6 %7 %8 %9
goto end_of_ascript
:WinNT
ascript standalone-sample.bat %*
goto end_of_ascript
rem */
//-----------------------------------------------------------------------------
sys.echo(true)
repeat(100):list { rand(10) }
//-----------------------------------------------------------------------------
/*
:end_of_ascript
rem */
ascript-build016/sample/sudoku-resolver.az 777 0 0 5616 11415475750 14114 0 #!/usr/bin/env ascript
// this script has been inspired by the following site.
// problems have also been picked up there.
// http://homepage1.nifty.com/~tetsu/ruby/puzzle/sudoku.html
import(canvas)
convToNumber(str:string):map = if (str == " ") { nil } else { tonumber(str):raise }
makeBoard(boardRaw:string) = convToNumber(boardRaw.split("\n")::split())
getBox(board, iRow:number, iCol:number) = {
iRow = int(iRow / 3) * 3, iCol = int(iCol / 3) * 3
list % board[iRow..(iRow + 2)]::get([iCol..(iCol + 2)]):list
}
solve(board, iCell:number) = {
repeat {
(iCell >= 9 * 9) && return(true)
[iRow, iCol] = [int(iCell / 9), iCell % 9]
(board[iRow][iCol] == nil) && break
iCell += 1
}
candidates = set(xset(1..9, board[iRow]):xor,
xset(1..9, board::get(iCol)):xor,
xset(1..9, getBox(board, iRow, iCol)):xor):and
(candidates.len() == 0) && return(false)
for (digit in candidates) {
board[iRow][iCol] = digit
solve(board, iCell + 1) && return(true)
}
board[iRow][iCol] = nil
false
}
printBoard(board) = {
println("+-----+-----+-----+")
for (line in board) {|i|
fields = [line[0..2], line[3..5], line[6..8]]::nilto(" "):map
println("|", fields::join(" ").join("|"), "|")
((i + 1) % 3 == 0) && println("+-----+-----+-----+")
}
}
drawBoard(filename:string, width:number, height:number, board) = {
canvas.create_emf(filename, width, height) {|c|
size = min(c.width(), c.height()) * .95
[x0, y0] = [(c.width() - size) / 2, (c.height() - size) / 2]
sizeGrid = size / 9
calcX(i:number):map = x0 + i * sizeGrid
calcY(i:number):map = y0 + i * sizeGrid
repeat(10) {|i|
c.setpen(`black, chooseif(i % 3 == 0, 4, 1), `solid)
c.line(calcX(i), calcY(0), calcX(i), calcY(9))
}
repeat(10) {|i|
c.setpen(`black, chooseif(i % 3 == 0, 4, 1), `solid)
c.line(calcX(0), calcY(i), calcX(9), calcY(i))
}
for (line in board) {|i|
for (digit in line) {|j|
(digit == nil) && continue
c.moveto(calcX(j), calcY(8 - i)).text("%d" % digit, sizeGrid, sizeGrid)
}
}
}
}
boardRaws = [
" 39 2\n" \
"6 9 2 7 \n" \
" 6 9\n" \
" 8673 1 \n" \
" 3 4 \n" \
" 5 4863 \n" \
"5 2 \n" \
" 4 7 9 1\n" \
"3 51 ",
" 41 39 \n" \
" 4 7 \n" \
"35 8 64\n" \
" 93 46 \n" \
"2 3\n" \
" 71 68 \n" \
"47 5 89\n" \
" 8 3 \n" \
" 86 23 ",
" 9647\n" \
"1 7 4 8 \n" \
"2 385 \n" \
" 5 92 8\n" \
"9 1 4 6\n" \
"6 71 3 \n" \
" 956 2\n" \
" 6 8 1 9\n" \
"7351 ",
"8 4 69\n" \
"24 5 1 \n" \
" 98 24 \n" \
" 8 1 64 \n" \
"7 4 8 5\n" \
" 23 9 8 \n" \
" 21 67 \n" \
" 1 4 23\n" \
"59 3 6",
"35 1 6\n" \
" 765 84\n" \
"2 41 3 \n" \
" 2 167 \n" \
" 1 9 3 \n" \
" 278 3 \n" \
" 4 29 5\n" \
"98 721 \n" \
"6 2 49"
]
for (boardRaw in boardRaws) {
board = makeBoard(boardRaw)
printBoard(board)
if (solve(board, 0)) {
printBoard(board)
//drawBoard("a.emf", 100, 100, board)
} else {
println("can't find answer for it")
}
}
ascript-build016/sample/svnlog.az 777 0 0 2217 11405763273 12244 0 #!/usr/bin/env ascript
import(re)
if (sys.argv.len() < 2) {
sys.stderr.printf("usage: svnlog.az file\n")
sys.exit(1)
}
isSeparator(line:string) = re.match("-{72,}", line)
isBlank(line:string) = re.match("^$", line)
stat = `STAT_Start
lineInfo = ""
header = ""
headerBlank = " " * 10
for (line in open(sys.argv[1]).readlines()) {
if (stat == `STAT_Start) {
if (isSeparator(line)) {
stat = `STAT_Info
}
} elsif (stat == `STAT_Info) {
lineInfo = line
stat = `STAT_Comment
} elsif (stat == `STAT_Comment) {
if (isSeparator(line)) {
stat = `STAT_Info
} elsif (isBlank(line)) {
// nothing to do
} else {
fields = re.split(r" \| ", lineInfo):list
if (m = re.match(r"\d{4}-\d{2}-\d{2}", fields[2])) {
headerNew = m.group(0)
if (header == headerNew) {
print(headerBlank, " ", line)
} else {
header = headerNew
print(header, " ", line)
}
} else {
print(headerBlank, " ", line)
}
stat = `STAT_CommentCont
}
} elsif (stat == `STAT_CommentCont) {
if (isSeparator(line)) {
stat = `STAT_Info
} elsif (isBlank(line)) {
// nothing to do
} else {
print(headerBlank, " ", line)
}
}
}
ascript-build016/sample/wc.az 777 0 0 521 11415474230 11312 0 if (sys.argv.len() < 2) {
println("usage: wc.az file [file..]")
sys.exit(0)
}
fileNames = os.glob([sys.argv[1..]]):list
lenMax = fileNames:*len().max()
nlinesSum = 0
for (fileName in fileNames) {
nlines = open(fileName).readlines().len()
printf("%-*s %d\n", lenMax, fileName, nlines)
nlinesSum += nlines
}
printf("%d\n", nlinesSum)
ascript-build016/src/ 777 0 0 0 11433577362 7624 5 ascript-build016/src/aclocal.m4 777 0 0 76746 11400227575 11603 0 # generated automatically by aclocal 1.10.1 -*- Autoconf -*-
# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
# 2005, 2006, 2007, 2008 Free Software Foundation, Inc.
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
m4_ifndef([AC_AUTOCONF_VERSION],
[m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl
m4_if(AC_AUTOCONF_VERSION, [2.61],,
[m4_warning([this file was generated for autoconf 2.61.
You have another version of autoconf. It may work, but is not guaranteed to.
If you have problems, you may need to regenerate the build system entirely.
To do so, use the procedure documented by the package, typically `autoreconf'.])])
# Copyright (C) 2002, 2003, 2005, 2006, 2007 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# AM_AUTOMAKE_VERSION(VERSION)
# ----------------------------
# Automake X.Y traces this macro to ensure aclocal.m4 has been
# generated from the m4 files accompanying Automake X.Y.
# (This private macro should not be called outside this file.)
AC_DEFUN([AM_AUTOMAKE_VERSION],
[am__api_version='1.10'
dnl Some users find AM_AUTOMAKE_VERSION and mistake it for a way to
dnl require some minimum version. Point them to the right macro.
m4_if([$1], [1.10.1], [],
[AC_FATAL([Do not call $0, use AM_INIT_AUTOMAKE([$1]).])])dnl
])
# _AM_AUTOCONF_VERSION(VERSION)
# -----------------------------
# aclocal traces this macro to find the Autoconf version.
# This is a private macro too. Using m4_define simplifies
# the logic in aclocal, which can simply ignore this definition.
m4_define([_AM_AUTOCONF_VERSION], [])
# AM_SET_CURRENT_AUTOMAKE_VERSION
# -------------------------------
# Call AM_AUTOMAKE_VERSION and AM_AUTOMAKE_VERSION so they can be traced.
# This function is AC_REQUIREd by AC_INIT_AUTOMAKE.
AC_DEFUN([AM_SET_CURRENT_AUTOMAKE_VERSION],
[AM_AUTOMAKE_VERSION([1.10.1])dnl
m4_ifndef([AC_AUTOCONF_VERSION],
[m4_copy([m4_PACKAGE_VERSION], [AC_AUTOCONF_VERSION])])dnl
_AM_AUTOCONF_VERSION(AC_AUTOCONF_VERSION)])
# AM_AUX_DIR_EXPAND -*- Autoconf -*-
# Copyright (C) 2001, 2003, 2005 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# For projects using AC_CONFIG_AUX_DIR([foo]), Autoconf sets
# $ac_aux_dir to `$srcdir/foo'. In other projects, it is set to
# `$srcdir', `$srcdir/..', or `$srcdir/../..'.
#
# Of course, Automake must honor this variable whenever it calls a
# tool from the auxiliary directory. The problem is that $srcdir (and
# therefore $ac_aux_dir as well) can be either absolute or relative,
# depending on how configure is run. This is pretty annoying, since
# it makes $ac_aux_dir quite unusable in subdirectories: in the top
# source directory, any form will work fine, but in subdirectories a
# relative path needs to be adjusted first.
#
# $ac_aux_dir/missing
# fails when called from a subdirectory if $ac_aux_dir is relative
# $top_srcdir/$ac_aux_dir/missing
# fails if $ac_aux_dir is absolute,
# fails when called from a subdirectory in a VPATH build with
# a relative $ac_aux_dir
#
# The reason of the latter failure is that $top_srcdir and $ac_aux_dir
# are both prefixed by $srcdir. In an in-source build this is usually
# harmless because $srcdir is `.', but things will broke when you
# start a VPATH build or use an absolute $srcdir.
#
# So we could use something similar to $top_srcdir/$ac_aux_dir/missing,
# iff we strip the leading $srcdir from $ac_aux_dir. That would be:
# am_aux_dir='\$(top_srcdir)/'`expr "$ac_aux_dir" : "$srcdir//*\(.*\)"`
# and then we would define $MISSING as
# MISSING="\${SHELL} $am_aux_dir/missing"
# This will work as long as MISSING is not called from configure, because
# unfortunately $(top_srcdir) has no meaning in configure.
# However there are other variables, like CC, which are often used in
# configure, and could therefore not use this "fixed" $ac_aux_dir.
#
# Another solution, used here, is to always expand $ac_aux_dir to an
# absolute PATH. The drawback is that using absolute paths prevent a
# configured tree to be moved without reconfiguration.
AC_DEFUN([AM_AUX_DIR_EXPAND],
[dnl Rely on autoconf to set up CDPATH properly.
AC_PREREQ([2.50])dnl
# expand $ac_aux_dir to an absolute path
am_aux_dir=`cd $ac_aux_dir && pwd`
])
# AM_CONDITIONAL -*- Autoconf -*-
# Copyright (C) 1997, 2000, 2001, 2003, 2004, 2005, 2006
# Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 8
# AM_CONDITIONAL(NAME, SHELL-CONDITION)
# -------------------------------------
# Define a conditional.
AC_DEFUN([AM_CONDITIONAL],
[AC_PREREQ(2.52)dnl
ifelse([$1], [TRUE], [AC_FATAL([$0: invalid condition: $1])],
[$1], [FALSE], [AC_FATAL([$0: invalid condition: $1])])dnl
AC_SUBST([$1_TRUE])dnl
AC_SUBST([$1_FALSE])dnl
_AM_SUBST_NOTMAKE([$1_TRUE])dnl
_AM_SUBST_NOTMAKE([$1_FALSE])dnl
if $2; then
$1_TRUE=
$1_FALSE='#'
else
$1_TRUE='#'
$1_FALSE=
fi
AC_CONFIG_COMMANDS_PRE(
[if test -z "${$1_TRUE}" && test -z "${$1_FALSE}"; then
AC_MSG_ERROR([[conditional "$1" was never defined.
Usually this means the macro was only invoked conditionally.]])
fi])])
# Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006
# Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 9
# There are a few dirty hacks below to avoid letting `AC_PROG_CC' be
# written in clear, in which case automake, when reading aclocal.m4,
# will think it sees a *use*, and therefore will trigger all it's
# C support machinery. Also note that it means that autoscan, seeing
# CC etc. in the Makefile, will ask for an AC_PROG_CC use...
# _AM_DEPENDENCIES(NAME)
# ----------------------
# See how the compiler implements dependency checking.
# NAME is "CC", "CXX", "GCJ", or "OBJC".
# We try a few techniques and use that to set a single cache variable.
#
# We don't AC_REQUIRE the corresponding AC_PROG_CC since the latter was
# modified to invoke _AM_DEPENDENCIES(CC); we would have a circular
# dependency, and given that the user is not expected to run this macro,
# just rely on AC_PROG_CC.
AC_DEFUN([_AM_DEPENDENCIES],
[AC_REQUIRE([AM_SET_DEPDIR])dnl
AC_REQUIRE([AM_OUTPUT_DEPENDENCY_COMMANDS])dnl
AC_REQUIRE([AM_MAKE_INCLUDE])dnl
AC_REQUIRE([AM_DEP_TRACK])dnl
ifelse([$1], CC, [depcc="$CC" am_compiler_list=],
[$1], CXX, [depcc="$CXX" am_compiler_list=],
[$1], OBJC, [depcc="$OBJC" am_compiler_list='gcc3 gcc'],
[$1], UPC, [depcc="$UPC" am_compiler_list=],
[$1], GCJ, [depcc="$GCJ" am_compiler_list='gcc3 gcc'],
[depcc="$$1" am_compiler_list=])
AC_CACHE_CHECK([dependency style of $depcc],
[am_cv_$1_dependencies_compiler_type],
[if test -z "$AMDEP_TRUE" && test -f "$am_depcomp"; then
# We make a subdir and do the tests there. Otherwise we can end up
# making bogus files that we don't know about and never remove. For
# instance it was reported that on HP-UX the gcc test will end up
# making a dummy file named `D' -- because `-MD' means `put the output
# in D'.
mkdir conftest.dir
# Copy depcomp to subdir because otherwise we won't find it if we're
# using a relative directory.
cp "$am_depcomp" conftest.dir
cd conftest.dir
# We will build objects and dependencies in a subdirectory because
# it helps to detect inapplicable dependency modes. For instance
# both Tru64's cc and ICC support -MD to output dependencies as a
# side effect of compilation, but ICC will put the dependencies in
# the current directory while Tru64 will put them in the object
# directory.
mkdir sub
am_cv_$1_dependencies_compiler_type=none
if test "$am_compiler_list" = ""; then
am_compiler_list=`sed -n ['s/^#*\([a-zA-Z0-9]*\))$/\1/p'] < ./depcomp`
fi
for depmode in $am_compiler_list; do
# Setup a source with many dependencies, because some compilers
# like to wrap large dependency lists on column 80 (with \), and
# we should not choose a depcomp mode which is confused by this.
#
# We need to recreate these files for each test, as the compiler may
# overwrite some of them when testing with obscure command lines.
# This happens at least with the AIX C compiler.
: > sub/conftest.c
for i in 1 2 3 4 5 6; do
echo '#include "conftst'$i'.h"' >> sub/conftest.c
# Using `: > sub/conftst$i.h' creates only sub/conftst1.h with
# Solaris 8's {/usr,}/bin/sh.
touch sub/conftst$i.h
done
echo "${am__include} ${am__quote}sub/conftest.Po${am__quote}" > confmf
case $depmode in
nosideeffect)
# after this tag, mechanisms are not by side-effect, so they'll
# only be used when explicitly requested
if test "x$enable_dependency_tracking" = xyes; then
continue
else
break
fi
;;
none) break ;;
esac
# We check with `-c' and `-o' for the sake of the "dashmstdout"
# mode. It turns out that the SunPro C++ compiler does not properly
# handle `-M -o', and we need to detect this.
if depmode=$depmode \
source=sub/conftest.c object=sub/conftest.${OBJEXT-o} \
depfile=sub/conftest.Po tmpdepfile=sub/conftest.TPo \
$SHELL ./depcomp $depcc -c -o sub/conftest.${OBJEXT-o} sub/conftest.c \
>/dev/null 2>conftest.err &&
grep sub/conftst1.h sub/conftest.Po > /dev/null 2>&1 &&
grep sub/conftst6.h sub/conftest.Po > /dev/null 2>&1 &&
grep sub/conftest.${OBJEXT-o} sub/conftest.Po > /dev/null 2>&1 &&
${MAKE-make} -s -f confmf > /dev/null 2>&1; then
# icc doesn't choke on unknown options, it will just issue warnings
# or remarks (even with -Werror). So we grep stderr for any message
# that says an option was ignored or not supported.
# When given -MP, icc 7.0 and 7.1 complain thusly:
# icc: Command line warning: ignoring option '-M'; no argument required
# The diagnosis changed in icc 8.0:
# icc: Command line remark: option '-MP' not supported
if (grep 'ignoring option' conftest.err ||
grep 'not supported' conftest.err) >/dev/null 2>&1; then :; else
am_cv_$1_dependencies_compiler_type=$depmode
break
fi
fi
done
cd ..
rm -rf conftest.dir
else
am_cv_$1_dependencies_compiler_type=none
fi
])
AC_SUBST([$1DEPMODE], [depmode=$am_cv_$1_dependencies_compiler_type])
AM_CONDITIONAL([am__fastdep$1], [
test "x$enable_dependency_tracking" != xno \
&& test "$am_cv_$1_dependencies_compiler_type" = gcc3])
])
# AM_SET_DEPDIR
# -------------
# Choose a directory name for dependency files.
# This macro is AC_REQUIREd in _AM_DEPENDENCIES
AC_DEFUN([AM_SET_DEPDIR],
[AC_REQUIRE([AM_SET_LEADING_DOT])dnl
AC_SUBST([DEPDIR], ["${am__leading_dot}deps"])dnl
])
# AM_DEP_TRACK
# ------------
AC_DEFUN([AM_DEP_TRACK],
[AC_ARG_ENABLE(dependency-tracking,
[ --disable-dependency-tracking speeds up one-time build
--enable-dependency-tracking do not reject slow dependency extractors])
if test "x$enable_dependency_tracking" != xno; then
am_depcomp="$ac_aux_dir/depcomp"
AMDEPBACKSLASH='\'
fi
AM_CONDITIONAL([AMDEP], [test "x$enable_dependency_tracking" != xno])
AC_SUBST([AMDEPBACKSLASH])dnl
_AM_SUBST_NOTMAKE([AMDEPBACKSLASH])dnl
])
# Generate code to set up dependency tracking. -*- Autoconf -*-
# Copyright (C) 1999, 2000, 2001, 2002, 2003, 2004, 2005
# Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
#serial 3
# _AM_OUTPUT_DEPENDENCY_COMMANDS
# ------------------------------
AC_DEFUN([_AM_OUTPUT_DEPENDENCY_COMMANDS],
[for mf in $CONFIG_FILES; do
# Strip MF so we end up with the name of the file.
mf=`echo "$mf" | sed -e 's/:.*$//'`
# Check whether this is an Automake generated Makefile or not.
# We used to match only the files named `Makefile.in', but
# some people rename them; so instead we look at the file content.
# Grep'ing the first line is not enough: some people post-process
# each Makefile.in and add a new line on top of each file to say so.
# Grep'ing the whole file is not good either: AIX grep has a line
# limit of 2048, but all sed's we know have understand at least 4000.
if sed -n 's,^#.*generated by automake.*,X,p' "$mf" | grep X >/dev/null 2>&1; then
dirpart=`AS_DIRNAME("$mf")`
else
continue
fi
# Extract the definition of DEPDIR, am__include, and am__quote
# from the Makefile without running `make'.
DEPDIR=`sed -n 's/^DEPDIR = //p' < "$mf"`
test -z "$DEPDIR" && continue
am__include=`sed -n 's/^am__include = //p' < "$mf"`
test -z "am__include" && continue
am__quote=`sed -n 's/^am__quote = //p' < "$mf"`
# When using ansi2knr, U may be empty or an underscore; expand it
U=`sed -n 's/^U = //p' < "$mf"`
# Find all dependency output files, they are included files with
# $(DEPDIR) in their names. We invoke sed twice because it is the
# simplest approach to changing $(DEPDIR) to its actual value in the
# expansion.
for file in `sed -n "
s/^$am__include $am__quote\(.*(DEPDIR).*\)$am__quote"'$/\1/p' <"$mf" | \
sed -e 's/\$(DEPDIR)/'"$DEPDIR"'/g' -e 's/\$U/'"$U"'/g'`; do
# Make sure the directory exists.
test -f "$dirpart/$file" && continue
fdir=`AS_DIRNAME(["$file"])`
AS_MKDIR_P([$dirpart/$fdir])
# echo "creating $dirpart/$file"
echo '# dummy' > "$dirpart/$file"
done
done
])# _AM_OUTPUT_DEPENDENCY_COMMANDS
# AM_OUTPUT_DEPENDENCY_COMMANDS
# -----------------------------
# This macro should only be invoked once -- use via AC_REQUIRE.
#
# This code is only required when automatic dependency tracking
# is enabled. FIXME. This creates each `.P' file that we will
# need in order to bootstrap the dependency handling code.
AC_DEFUN([AM_OUTPUT_DEPENDENCY_COMMANDS],
[AC_CONFIG_COMMANDS([depfiles],
[test x"$AMDEP_TRUE" != x"" || _AM_OUTPUT_DEPENDENCY_COMMANDS],
[AMDEP_TRUE="$AMDEP_TRUE" ac_aux_dir="$ac_aux_dir"])
])
# Do all the work for Automake. -*- Autoconf -*-
# Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004,
# 2005, 2006, 2008 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 13
# This macro actually does too much. Some checks are only needed if
# your package does certain things. But this isn't really a big deal.
# AM_INIT_AUTOMAKE(PACKAGE, VERSION, [NO-DEFINE])
# AM_INIT_AUTOMAKE([OPTIONS])
# -----------------------------------------------
# The call with PACKAGE and VERSION arguments is the old style
# call (pre autoconf-2.50), which is being phased out. PACKAGE
# and VERSION should now be passed to AC_INIT and removed from
# the call to AM_INIT_AUTOMAKE.
# We support both call styles for the transition. After
# the next Automake release, Autoconf can make the AC_INIT
# arguments mandatory, and then we can depend on a new Autoconf
# release and drop the old call support.
AC_DEFUN([AM_INIT_AUTOMAKE],
[AC_PREREQ([2.60])dnl
dnl Autoconf wants to disallow AM_ names. We explicitly allow
dnl the ones we care about.
m4_pattern_allow([^AM_[A-Z]+FLAGS$])dnl
AC_REQUIRE([AM_SET_CURRENT_AUTOMAKE_VERSION])dnl
AC_REQUIRE([AC_PROG_INSTALL])dnl
if test "`cd $srcdir && pwd`" != "`pwd`"; then
# Use -I$(srcdir) only when $(srcdir) != ., so that make's output
# is not polluted with repeated "-I."
AC_SUBST([am__isrc], [' -I$(srcdir)'])_AM_SUBST_NOTMAKE([am__isrc])dnl
# test to see if srcdir already configured
if test -f $srcdir/config.status; then
AC_MSG_ERROR([source directory already configured; run "make distclean" there first])
fi
fi
# test whether we have cygpath
if test -z "$CYGPATH_W"; then
if (cygpath --version) >/dev/null 2>/dev/null; then
CYGPATH_W='cygpath -w'
else
CYGPATH_W=echo
fi
fi
AC_SUBST([CYGPATH_W])
# Define the identity of the package.
dnl Distinguish between old-style and new-style calls.
m4_ifval([$2],
[m4_ifval([$3], [_AM_SET_OPTION([no-define])])dnl
AC_SUBST([PACKAGE], [$1])dnl
AC_SUBST([VERSION], [$2])],
[_AM_SET_OPTIONS([$1])dnl
dnl Diagnose old-style AC_INIT with new-style AM_AUTOMAKE_INIT.
m4_if(m4_ifdef([AC_PACKAGE_NAME], 1)m4_ifdef([AC_PACKAGE_VERSION], 1), 11,,
[m4_fatal([AC_INIT should be called with package and version arguments])])dnl
AC_SUBST([PACKAGE], ['AC_PACKAGE_TARNAME'])dnl
AC_SUBST([VERSION], ['AC_PACKAGE_VERSION'])])dnl
_AM_IF_OPTION([no-define],,
[AC_DEFINE_UNQUOTED(PACKAGE, "$PACKAGE", [Name of package])
AC_DEFINE_UNQUOTED(VERSION, "$VERSION", [Version number of package])])dnl
# Some tools Automake needs.
AC_REQUIRE([AM_SANITY_CHECK])dnl
AC_REQUIRE([AC_ARG_PROGRAM])dnl
AM_MISSING_PROG(ACLOCAL, aclocal-${am__api_version})
AM_MISSING_PROG(AUTOCONF, autoconf)
AM_MISSING_PROG(AUTOMAKE, automake-${am__api_version})
AM_MISSING_PROG(AUTOHEADER, autoheader)
AM_MISSING_PROG(MAKEINFO, makeinfo)
AM_PROG_INSTALL_SH
AM_PROG_INSTALL_STRIP
AC_REQUIRE([AM_PROG_MKDIR_P])dnl
# We need awk for the "check" target. The system "awk" is bad on
# some platforms.
AC_REQUIRE([AC_PROG_AWK])dnl
AC_REQUIRE([AC_PROG_MAKE_SET])dnl
AC_REQUIRE([AM_SET_LEADING_DOT])dnl
_AM_IF_OPTION([tar-ustar], [_AM_PROG_TAR([ustar])],
[_AM_IF_OPTION([tar-pax], [_AM_PROG_TAR([pax])],
[_AM_PROG_TAR([v7])])])
_AM_IF_OPTION([no-dependencies],,
[AC_PROVIDE_IFELSE([AC_PROG_CC],
[_AM_DEPENDENCIES(CC)],
[define([AC_PROG_CC],
defn([AC_PROG_CC])[_AM_DEPENDENCIES(CC)])])dnl
AC_PROVIDE_IFELSE([AC_PROG_CXX],
[_AM_DEPENDENCIES(CXX)],
[define([AC_PROG_CXX],
defn([AC_PROG_CXX])[_AM_DEPENDENCIES(CXX)])])dnl
AC_PROVIDE_IFELSE([AC_PROG_OBJC],
[_AM_DEPENDENCIES(OBJC)],
[define([AC_PROG_OBJC],
defn([AC_PROG_OBJC])[_AM_DEPENDENCIES(OBJC)])])dnl
])
])
# When config.status generates a header, we must update the stamp-h file.
# This file resides in the same directory as the config header
# that is generated. The stamp files are numbered to have different names.
# Autoconf calls _AC_AM_CONFIG_HEADER_HOOK (when defined) in the
# loop where config.status creates the headers, so we can generate
# our stamp files there.
AC_DEFUN([_AC_AM_CONFIG_HEADER_HOOK],
[# Compute $1's index in $config_headers.
_am_arg=$1
_am_stamp_count=1
for _am_header in $config_headers :; do
case $_am_header in
$_am_arg | $_am_arg:* )
break ;;
* )
_am_stamp_count=`expr $_am_stamp_count + 1` ;;
esac
done
echo "timestamp for $_am_arg" >`AS_DIRNAME(["$_am_arg"])`/stamp-h[]$_am_stamp_count])
# Copyright (C) 2001, 2003, 2005 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# AM_PROG_INSTALL_SH
# ------------------
# Define $install_sh.
AC_DEFUN([AM_PROG_INSTALL_SH],
[AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
install_sh=${install_sh-"\$(SHELL) $am_aux_dir/install-sh"}
AC_SUBST(install_sh)])
# Copyright (C) 2003, 2005 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 2
# Check whether the underlying file-system supports filenames
# with a leading dot. For instance MS-DOS doesn't.
AC_DEFUN([AM_SET_LEADING_DOT],
[rm -rf .tst 2>/dev/null
mkdir .tst 2>/dev/null
if test -d .tst; then
am__leading_dot=.
else
am__leading_dot=_
fi
rmdir .tst 2>/dev/null
AC_SUBST([am__leading_dot])])
# Check to see how 'make' treats includes. -*- Autoconf -*-
# Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 3
# AM_MAKE_INCLUDE()
# -----------------
# Check to see how make treats includes.
AC_DEFUN([AM_MAKE_INCLUDE],
[am_make=${MAKE-make}
cat > confinc << 'END'
am__doit:
@echo done
.PHONY: am__doit
END
# If we don't find an include directive, just comment out the code.
AC_MSG_CHECKING([for style of include used by $am_make])
am__include="#"
am__quote=
_am_result=none
# First try GNU make style include.
echo "include confinc" > confmf
# We grep out `Entering directory' and `Leaving directory'
# messages which can occur if `w' ends up in MAKEFLAGS.
# In particular we don't look at `^make:' because GNU make might
# be invoked under some other name (usually "gmake"), in which
# case it prints its new name instead of `make'.
if test "`$am_make -s -f confmf 2> /dev/null | grep -v 'ing directory'`" = "done"; then
am__include=include
am__quote=
_am_result=GNU
fi
# Now try BSD make style include.
if test "$am__include" = "#"; then
echo '.include "confinc"' > confmf
if test "`$am_make -s -f confmf 2> /dev/null`" = "done"; then
am__include=.include
am__quote="\""
_am_result=BSD
fi
fi
AC_SUBST([am__include])
AC_SUBST([am__quote])
AC_MSG_RESULT([$_am_result])
rm -f confinc confmf
])
# Fake the existence of programs that GNU maintainers use. -*- Autoconf -*-
# Copyright (C) 1997, 1999, 2000, 2001, 2003, 2004, 2005
# Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 5
# AM_MISSING_PROG(NAME, PROGRAM)
# ------------------------------
AC_DEFUN([AM_MISSING_PROG],
[AC_REQUIRE([AM_MISSING_HAS_RUN])
$1=${$1-"${am_missing_run}$2"}
AC_SUBST($1)])
# AM_MISSING_HAS_RUN
# ------------------
# Define MISSING if not defined so far and test if it supports --run.
# If it does, set am_missing_run to use it, otherwise, to nothing.
AC_DEFUN([AM_MISSING_HAS_RUN],
[AC_REQUIRE([AM_AUX_DIR_EXPAND])dnl
AC_REQUIRE_AUX_FILE([missing])dnl
test x"${MISSING+set}" = xset || MISSING="\${SHELL} $am_aux_dir/missing"
# Use eval to expand $SHELL
if eval "$MISSING --run true"; then
am_missing_run="$MISSING --run "
else
am_missing_run=
AC_MSG_WARN([`missing' script is too old or missing])
fi
])
# Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# AM_PROG_MKDIR_P
# ---------------
# Check for `mkdir -p'.
AC_DEFUN([AM_PROG_MKDIR_P],
[AC_PREREQ([2.60])dnl
AC_REQUIRE([AC_PROG_MKDIR_P])dnl
dnl Automake 1.8 to 1.9.6 used to define mkdir_p. We now use MKDIR_P,
dnl while keeping a definition of mkdir_p for backward compatibility.
dnl @MKDIR_P@ is magic: AC_OUTPUT adjusts its value for each Makefile.
dnl However we cannot define mkdir_p as $(MKDIR_P) for the sake of
dnl Makefile.ins that do not define MKDIR_P, so we do our own
dnl adjustment using top_builddir (which is defined more often than
dnl MKDIR_P).
AC_SUBST([mkdir_p], ["$MKDIR_P"])dnl
case $mkdir_p in
[[\\/$]]* | ?:[[\\/]]*) ;;
*/*) mkdir_p="\$(top_builddir)/$mkdir_p" ;;
esac
])
# Helper functions for option handling. -*- Autoconf -*-
# Copyright (C) 2001, 2002, 2003, 2005 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 3
# _AM_MANGLE_OPTION(NAME)
# -----------------------
AC_DEFUN([_AM_MANGLE_OPTION],
[[_AM_OPTION_]m4_bpatsubst($1, [[^a-zA-Z0-9_]], [_])])
# _AM_SET_OPTION(NAME)
# ------------------------------
# Set option NAME. Presently that only means defining a flag for this option.
AC_DEFUN([_AM_SET_OPTION],
[m4_define(_AM_MANGLE_OPTION([$1]), 1)])
# _AM_SET_OPTIONS(OPTIONS)
# ----------------------------------
# OPTIONS is a space-separated list of Automake options.
AC_DEFUN([_AM_SET_OPTIONS],
[AC_FOREACH([_AM_Option], [$1], [_AM_SET_OPTION(_AM_Option)])])
# _AM_IF_OPTION(OPTION, IF-SET, [IF-NOT-SET])
# -------------------------------------------
# Execute IF-SET if OPTION is set, IF-NOT-SET otherwise.
AC_DEFUN([_AM_IF_OPTION],
[m4_ifset(_AM_MANGLE_OPTION([$1]), [$2], [$3])])
# Check to make sure that the build environment is sane. -*- Autoconf -*-
# Copyright (C) 1996, 1997, 2000, 2001, 2003, 2005
# Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 4
# AM_SANITY_CHECK
# ---------------
AC_DEFUN([AM_SANITY_CHECK],
[AC_MSG_CHECKING([whether build environment is sane])
# Just in case
sleep 1
echo timestamp > conftest.file
# Do `set' in a subshell so we don't clobber the current shell's
# arguments. Must try -L first in case configure is actually a
# symlink; some systems play weird games with the mod time of symlinks
# (eg FreeBSD returns the mod time of the symlink's containing
# directory).
if (
set X `ls -Lt $srcdir/configure conftest.file 2> /dev/null`
if test "$[*]" = "X"; then
# -L didn't work.
set X `ls -t $srcdir/configure conftest.file`
fi
rm -f conftest.file
if test "$[*]" != "X $srcdir/configure conftest.file" \
&& test "$[*]" != "X conftest.file $srcdir/configure"; then
# If neither matched, then we have a broken ls. This can happen
# if, for instance, CONFIG_SHELL is bash and it inherits a
# broken ls alias from the environment. This has actually
# happened. Such a system could not be considered "sane".
AC_MSG_ERROR([ls -t appears to fail. Make sure there is not a broken
alias in your environment])
fi
test "$[2]" = conftest.file
)
then
# Ok.
:
else
AC_MSG_ERROR([newly created file is older than distributed files!
Check your system clock])
fi
AC_MSG_RESULT(yes)])
# Copyright (C) 2001, 2003, 2005 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# AM_PROG_INSTALL_STRIP
# ---------------------
# One issue with vendor `install' (even GNU) is that you can't
# specify the program used to strip binaries. This is especially
# annoying in cross-compiling environments, where the build's strip
# is unlikely to handle the host's binaries.
# Fortunately install-sh will honor a STRIPPROG variable, so we
# always use install-sh in `make install-strip', and initialize
# STRIPPROG with the value of the STRIP variable (set by the user).
AC_DEFUN([AM_PROG_INSTALL_STRIP],
[AC_REQUIRE([AM_PROG_INSTALL_SH])dnl
# Installed binaries are usually stripped using `strip' when the user
# run `make install-strip'. However `strip' might not be the right
# tool to use in cross-compilation environments, therefore Automake
# will honor the `STRIP' environment variable to overrule this program.
dnl Don't test for $cross_compiling = yes, because it might be `maybe'.
if test "$cross_compiling" != no; then
AC_CHECK_TOOL([STRIP], [strip], :)
fi
INSTALL_STRIP_PROGRAM="\$(install_sh) -c -s"
AC_SUBST([INSTALL_STRIP_PROGRAM])])
# Copyright (C) 2006 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# _AM_SUBST_NOTMAKE(VARIABLE)
# ---------------------------
# Prevent Automake from outputting VARIABLE = @VARIABLE@ in Makefile.in.
# This macro is traced by Automake.
AC_DEFUN([_AM_SUBST_NOTMAKE])
# Check how to create a tarball. -*- Autoconf -*-
# Copyright (C) 2004, 2005 Free Software Foundation, Inc.
#
# This file is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# serial 2
# _AM_PROG_TAR(FORMAT)
# --------------------
# Check how to create a tarball in format FORMAT.
# FORMAT should be one of `v7', `ustar', or `pax'.
#
# Substitute a variable $(am__tar) that is a command
# writing to stdout a FORMAT-tarball containing the directory
# $tardir.
# tardir=directory && $(am__tar) > result.tar
#
# Substitute a variable $(am__untar) that extract such
# a tarball read from stdin.
# $(am__untar) < result.tar
AC_DEFUN([_AM_PROG_TAR],
[# Always define AMTAR for backward compatibility.
AM_MISSING_PROG([AMTAR], [tar])
m4_if([$1], [v7],
[am__tar='${AMTAR} chof - "$$tardir"'; am__untar='${AMTAR} xf -'],
[m4_case([$1], [ustar],, [pax],,
[m4_fatal([Unknown tar format])])
AC_MSG_CHECKING([how to create a $1 tar archive])
# Loop over all known methods to create a tar archive until one works.
_am_tools='gnutar m4_if([$1], [ustar], [plaintar]) pax cpio none'
_am_tools=${am_cv_prog_tar_$1-$_am_tools}
# Do not fold the above two line into one, because Tru64 sh and
# Solaris sh will not grok spaces in the rhs of `-'.
for _am_tool in $_am_tools
do
case $_am_tool in
gnutar)
for _am_tar in tar gnutar gtar;
do
AM_RUN_LOG([$_am_tar --version]) && break
done
am__tar="$_am_tar --format=m4_if([$1], [pax], [posix], [$1]) -chf - "'"$$tardir"'
am__tar_="$_am_tar --format=m4_if([$1], [pax], [posix], [$1]) -chf - "'"$tardir"'
am__untar="$_am_tar -xf -"
;;
plaintar)
# Must skip GNU tar: if it does not support --format= it doesn't create
# ustar tarball either.
(tar --version) >/dev/null 2>&1 && continue
am__tar='tar chf - "$$tardir"'
am__tar_='tar chf - "$tardir"'
am__untar='tar xf -'
;;
pax)
am__tar='pax -L -x $1 -w "$$tardir"'
am__tar_='pax -L -x $1 -w "$tardir"'
am__untar='pax -r'
;;
cpio)
am__tar='find "$$tardir" -print | cpio -o -H $1 -L'
am__tar_='find "$tardir" -print | cpio -o -H $1 -L'
am__untar='cpio -i -H $1 -d'
;;
none)
am__tar=false
am__tar_=false
am__untar=false
;;
esac
# If the value was cached, stop now. We just wanted to have am__tar
# and am__untar set.
test -n "${am_cv_prog_tar_$1}" && break
# tar/untar a dummy directory, and stop if the command works
rm -rf conftest.dir
mkdir conftest.dir
echo GrepMe > conftest.dir/file
AM_RUN_LOG([tardir=conftest.dir && eval $am__tar_ >conftest.tar])
rm -rf conftest.dir
if test -s conftest.tar; then
AM_RUN_LOG([$am__untar