uri(7)

NOMBRE
uri, url, urn - identificador uniforme de recursos (URI), incluido un URL o URN

SINOPSIS
URI = [ URIabsoluta | URIrelativa ] [ "#" fragmento ]

URIabsoluta = esquema .RB " : " ( parte_jerárquica | parte_opaca )

URIrelativa = ( ruta_de_red | ruta_absoluta | ruta_relativa ) [ "?" consulta ]

Esquema = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" | "file" | "ftp" | "man" | "info" | "whatis" | "ldap" | "wais" | ...

Parte_jerárquica = ( ruta_de_red | ruta_absoluta ) [ "?" consulta ]

Ruta_red = "//" autoridad [ ruta_absoluta ]

Ruta_absoluta = "/" segmentos_de_ruta

ruta_relativa = segmento_relativo [ ruta_absoluta ]

DESCRIPCIÓN
Un identificador uniforme de recursos (URI) es una cadena de caracteres corta que identifica un recurso abstracto o físico (por ejemplo, una página web). Localizador de Recursos Uniforme (URL) es un URI que identifica un recurso por su mecanismo de acceso primario (por ejemplo, su ubicación de), antes que por su nombre o algún otro atributo del recurso. Un Nombre de Recurso Uniforme (URN) es un URI que debe ser globalmente único y permanecer aun cuando el recurso deja de existir o pasa a ser inaccesible.

Los URI son la forma estándar de nombrar los destinos de los hiperenlaces para herramientas tales como los navegadores web. La cadena "http://www.kernel.org" es un URL (y también un URI). Algunas personas usan el término URL únicamente como sinónimo de URI (aunque técnicamente URLs son parte de los URI).

Los URI pueden ser absolutos o relativos. Un identificador absoluto se refiere a un recurso independiente del contexto, mientras que un identificador relativo apunta a un recurso a través de las diferencias del contexto actual. Dentro de una referencia a una ruta relativa, los segmentos de ruta completos "." y ".." tienen significados especiales: "el nivel jerárquico actual" y "el nivel superior a este nivel jerárquico", respectivamente, Tal y como lo hacen los sistemas al estilo UNIX. Un segmento de ruta que contiene el carácter ":" no puede ser usado como el primer segmento de ruta relativa URI (por ejemplo, "esto:aquello"), porque sería erróneo para el esquema de nombres. Preceda tales segmentos con ./ ((por ejemplo "./esto:aquello"). Advierta que los descendientes de MS-DOS (por ejemplo, Microsoft Windows) reemplazan los dos puntos de los nombres de dispositivo con la barra vertical ("|") en URI, por lo que "C:" se convierten en "C|".

Un identificador de fragmento, si es incluido, se refiere a una porción particular identificada (fragmento) de un recurso. El texto después de un '#' identifica al fragmento. Un URI que comience con '#' se refiere al fragmento del recurso actual.

  Modo de empleo
Hay diferentes esquemas URI, cada uno con reglas y significados adicionales, pero intencionadamente se hacen tan similares como sea posible. Por ejemplo, muchos esquemas URL permiten que la autoridad tenga el siguiente formato, llamado aquí un servidor_ip (los corchetes muestran qué es opcional):

servidor_ip = [usuario [ : contraseña ] @ ] host [ : puerto]

Este formato te permite opcionalmente insertar un nombre de usuario, una contraseña y/o un número de puerto. El host es el nombre del ordenador que hace de anfitrión, y su nombre se puede determinar mediante su DNS o una dirección IP (números separados por puntos). Por lo que el URI <http://fred:fredcontraseña@example.com:8080/> se introduce en el servidor web del anfitrión example.com como fred (usando fredcontraseña) usando el puerto 8080. Evite incluir contraseñas en un URI si es posible debido a los muchos riesgos para la seguridad que supone tener un password escrito. Si el URL facilita el nombre de usuario, pero no la contraseña, y el servidor remoto pide la contraseña, el programa que interpreta el URL debe requerir una del usuario.

Aquí hay algunos de los esquemas más comunes usados por sistemas al estilo UNIX, los cuales son comprendidos por muchas aplicaciones. Advierta que algunas aplicaciones usan URI y también tienen esquemas internos o esquemas especializados. Vea en esas aplicaciones la documentación para informarse sobre esos esquemas.

http - Servidor (HTTP) Web

http://servidor_ip/ruta
http://servidor_ip/ruta?cuestion

This is a URL accessing a web (HTTP) server. The default port is 80. If the path refers to a directory, the web server will choose what to return; usually if there is a file named "index.html" or "index.htm", its content is returned; otherwise, a list of the files in the current directory (with appropriate links) is generated and returned. An example is <http://lwn.net>.

A query can be given in the archaic "isindex" format, consisting of a word or phrase and not including an equal sign (=). A query can also be in the longer "GET" format, which has one or more query entries of the form key=value separated by the ampersand character (&). Note that key can be repeated more than once, though it's up to the web server and its application programs to determine if there's any meaning to that. There is an unfortunate interaction with HTML/XML/SGML and the GET query format; when such URIs with more than one key are embedded in SGML/XML documents (including HTML), the ampersand (&) has to be rewritten as &amp;. Note that not all queries use this format; larger forms may be too long to store as a URI, so they use a different interaction mechanism (called POST) which does not include the data in the URI. See the Common Gateway Interface specification at http://www.w3.org/CGI for more information.

ftp - Protocolo de Transferencia de Ficheros (FTP)

ftp://servidor_ip/ruta

Este es un URL de acceso a ficheros a través del protocolo de transferencia de ficheros (FTP). El puerto por defecto (para control) es el 21. Si no se incluye un nombre de usuario, se introduce el usuario llamado "anonymous", y en ese caso algunos clientes dan como contraseña su dirección de correo electrónico. Un ejemplo es <ftp://ftp.is.co.za/rfc/rfc1808.txt>.

gopher - servidor Gopher

gopher://servidor_ip/selector tipogopher
gopher://servidor_ip/selector tipogopher%09search
gopher://servidor_ip/selector tipogopher%09search%09gopher+_cadena

The default gopher port is 70. gophertype is a single-character field to denote the Gopher type of the resource to which the URL refers. The entire path may also be empty, in which case the delimiting "/" is also optional, and the gophertype defaults to "1".

selector es la cadena de selección Gopher. En el protocolo Gopher, las cadenas de selección Gopher son una secuencia de octetos que pueden contener cualquier octeto excepto el 09 en hexadecimal (US-ASCII HT o tab), 0A en hexadecimal (US-ASCII carácter LF) y 0D (US-ASCII carácter CR).

mailto - dirección de correo

mailto:dirección_de_correo

Esto es una dirección de correo electrónico, normalmente de la forma nombre@nombrehost. Véase mailaddr(7) para más información acerca del formato correcto de la dirección de correo electrónico. Advierta que cualquier carácter % debe ser reescrito como %25. Un ejemplo es <mailto:dwheeler@dwheeler.com>.

news - Grupo de noticias o Mensaje de noticias

news:nombre-gruponoticias
news:identificador-mensaje

Un nombre-gruponoticias es un nombre jerárquico delimitado por puntos, tal como "comp.infosystems.www.misc". Si <newsgroup-name> es "*" (como <news:*>), se usa para referirse a "todos los grupos de noticias disponibles". Un ejemplo es <news:comp.lang.ada>.

A message-id corresponds to the Message-ID of IETF RFC 1036, (http://www.ietf.org/rfc/rfc1036.txt) without the enclosing "<" and ">"; it takes the form unique@full_domain_name. A message identifier may be distinguished from a news group name by the presence of the "@" character.

telnet - sesión Telnet

telnet://servidor_ip/

El esquema de una URL de telnet se usa para designar servicios de texto interactivos a los que se puede acceder a través del protocolo Telnet. El carácter final "/" se puede omitir. El puerto por defecto es el 23. Un ejemplo es <telnet://melvyl.ucop.edu/>.

file - Fichero normal

file://servidor_ip/ruta
file:ruta

Esto representa un fichero o directorio que se puede acceder localmente. Como caso especial, servidor_ip puede ser la cadena "localhost" o una cadena vacía. Esto se interpreta como `la máquina desde la que el URL está siendo interpretado'. Si la ruta es hacia un directorio, el visor debería mostrar el contenido del directorio con enlaces a cada uno de los contenidos. Actualmente, no todos los visores hacen esto. KDE suporta ficheros generados a través del URL <file:/cgi-bin>. Si no se encuentra el fichero indicado, los escritores de visualizadores pueden querer el intentar expandir el nombre del fichero mediante comodines (vea glob(7) y glob(3)).

El segundo formato (por ejemplo, <file:/etc/passwd>) es correcto para referirse a archivos locales. Sin embargo, los estándares más antiguos no permitían este formato, y algunos programas no lo reconocen como un URI. Una sintaxis más portable es usar una cadena vacía como nombre del servidor, por ejemplo, <file:///etc/passwd>. Esto hace lo mismo y es más sencillo de reconocer para las expresiones regulares y los programas más antiguos como un URI. Advierta que si lo que realmente quiere decir es "comienza desde la posición actual," no especificas todo el esquema. En cambio, usa la dirección relativa como <../test.txt> que tiene el efecto colateral de ser independiente del esquema. Un ejemplo de este esquema es <file:///etc/passwd>.

man - páginas man de documentación

man:nombre-orden
man:nombre-orden(sección)

Esto se refiere a las páginas de referencia en línea del manual local. El nombre de la orden opcionalmente puede ir precedido por un paréntesis y un número de sección. Véase man(7) para más información sobre el significado de los números de sección. Este modelo URI es único en los sistemas tipo UNIX (como Linux) y actualmente no está registrado por la IETF. Un ejemplo es <man:ls(1)>.

info - Documentación en páginas info

info:nombrefichero-virtual
info:nombrefichero-virtual#nombrenodo
info:(nombrefichero-virtual)
info:(nombrefichero-virtual)nombrenodo

This scheme refers to online info reference pages (generated from texinfo files), a documentation format used by programs such as the GNU tools. This URI scheme is unique to UNIX-like systems (such as Linux) and is not currently registered by the IETF. As of this writing, GNOME and KDE differ in their URI syntax and do not accept the other's syntax. The first two formats are the GNOME format; in nodenames, all spaces are written as underscores. The second two formats are the KDE format; spaces in nodenames must be written as spaces, even though this is forbidden by the URI standards. It's hoped that in the future most tools will understand all of these formats and will always accept underscores for spaces in nodenames. In both GNOME and KDE, if the form without the nodename is used, the nodename is assumed to be "Top". Examples of the GNOME format are <info:gcc> and <info:gcc#G++_and_GCC>. Examples of the KDE format are <info:(gcc)> and <info:(gcc)G++ and GCC>.

whatis - búsqueda de documentación

whatis:cadena

Busca en la base de datos de descripciones cortas (una línea) de órdenes y devuelve una lista con las descripciones que contienen esa cadena. Sólo se muestran coincidencias de palabras completas. Véase whatis(1). Este esquema URI es único en los sistemas al estilo UNIX (tales como Linux) y actualmente no está registrado por el IETF.

ghelp - documentación de ayuda de GNOME

ghelp:ghelp: nombre-de-aplicación

Carga la ayuda de GNOME para la aplicación dada. Dese cuenta que actualmente no existe mucha documentación en este formato.

ldap - Protocolo Ligero de Acceso a Directorios

ldap://hostport
ldap://hostport/
ldap://hostport/dn
ldap://hostport/dn?attributes
ldap://hostport/dn?attributes?scope
ldap://hostport/dn?attributes?scope?filter
ldap://hostport/dn?attributes?scope?filter?extensions

This scheme supports queries to the Lightweight Directory Access Protocol (LDAP), a protocol for querying a set of servers for hierarchically organized information (such as people and computing resources). See RFC 2255 (http://www.ietf.org/rfc/rfc2255.txt) for more information on the LDAP URL scheme. The components of this URL are:

hostport
    el servidor LDAP a consultar, escrito como un nombre de anfitrión seguiro por dos puntos y un número de puerto. El puerto LDAP por omisión es el puerto TCP 389. Si no se indica, el cliente determina qué servidor LDAP usar.

dn  the LDAP Distinguished Name, which identifies the base object of the LDAP search (see RFC 2253 (http://www.ietf.org/rfc/rfc2253.txt) section 3).

attributes
    una lista de atributos, separados por comas, a devolver. Vea RFC 2251 sección 4.1.5. Si se omite, se deberían devolver todos los atributos.

scope
    especifica el ámbito de la búsqueda, que puede ser "base" (para una búsqueda de objetos base), "one" (para una búsqueda de un nivel) o "sub" (para una búsqueda de subárbol). Si se omite el ámbito, se asume "base".

filter
    specifies the search filter (subset of entries to return). If omitted, all entries should be returned. See RFC 2254 (http://www.ietf.org/rfc/rfc2254.txt) section 4.

extensions
    Una lista de parejas tipo=valor, separadas por comas, donde la porción =valor se puede omitir para opciones que no la necesiten. Una extensión prefijada con un '!' es crítica (debe estar soportada para ser válida), en otro caso no es crítica (opcional).

Las consultas LDAP son más fáciles de explicar mediante ejemplos. Aquí tiene una consulta que pide a ldap.itd.umich.edu información sobre la Universidad de Michigan en los EE.UU.:

ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US

Para obtener simplemente su atributo de dirección postal, pregunte:

ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress

Para pedir información a host.com en el puerto 6666 sobre la persona de nombre común (common name, cn) "Babs Jensen" de la Universidad de Michigan, pregunte:

ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)

wais - Wide Area Information Servers (Servidores de Información de Área Amplia)

wais://hostport/database
wais://hostport/database?search
wais://hostport/database/wtype/wpath

This scheme designates a WAIS database, search, or document (see IETF RFC 1625 (http://www.ietf.org/rfc/rfc1625.txt) for more information on WAIS). Hostport is the hostname, optionally followed by a colon and port number (the default port number is 210).

The first form designates a WAIS database for searching. The second form designates a particular search of the WAIS database database. The third form designates a particular document within a WAIS database to be retrieved. wtype is the WAIS designation of the type of the object, and wpath is the WAIS document-id.

Otros formatos

There are many other URI schemes. Most tools that accept URIs support a set of internal URIs (e.g., Mozilla has the about: scheme for internal information, and the GNOME help browser has the toc: scheme for various starting locations). There are many schemes that have been defined but are not as widely used at the current time (e.g., prospero). The nntp: scheme is deprecated in favor of the news: scheme. URNs are to be supported by the urn: scheme, with a hierarchical name space (e.g., urn:ietf:... would identify IETF documents); at this time, URNs are not widely implemented. Not all tools support all schemes.

  Codificación de caracteres
Las URI usan un número limitado de caracteres que pueden ser tecleados y usados multitud de situaciones.

Los siguientes caracteres son reservados, es decir, pueden aparecer en un URI, pero su uso está limitado a su propósito específico (los datos conflictivos deben ser precedidos por una carácter de escape antes de formar el URI):

        ; / ? : @ & = + $ ,

Los caracteres no reservados se pueden incluir en un URI. Los caracteres no reservados incluyen las letras del alfabeto latino en mayúsculas y minúscula, los dígitos, y el siguiente conjunto de marcas de puntuación y símbolos:

        - _ . ! ~ * ' ( )

All other characters must be escaped. An escaped octet is encoded as a character triplet, consisting of the percent character "%" followed by the two hexadecimal digits representing the octet code (you can use uppercase or lowercase letters for the hexadecimal digits). For example, a blank space must be escaped as "%20", a tab character as "%09", and the "&" as "%26". Because the percent "%" character always has the reserved purpose of being the escape indicator, it must be escaped as "%25". It is common practice to escape space characters as the plus symbol (+) in query text; this practice isn't uniformly defined in the relevant RFCs (which recommend %20 instead) but any tool accepting URIs with query text should be prepared for them. A URI is always shown in its "escaped" form.

Los caracteres no reservados se pueden escapar sin cambiar la semántica de la URI, pero esto no se debería hacer a menos que la URI se esté usando en un contexto que no permite que aparezcan caracteres sin escapar. Por ejemplo, se usa "%7e" en lugar de "~" en una ruta HTTP URL pero las dos son equivalentes para una URL HTTP.

For URIs which must handle characters outside the US ASCII character set, the HTML 4.01 specification (section B.2) and IETF RFC 3986 (last paragraph of section 2.5) recommend the following approach:

(1) translate the character sequences into UTF-8 (IETF RFC 3629) —see utf-8(7)— and then

(2) usar el mecanismo de escape URI, es decir, usar la codificación %HH para octetos problemáticos.

  Escritura de URI
Cuando son escritos, las URI deberían introducirse entre comillas (por ejemplo, "http://www.kernel.org"), encerrados entre <> (por ejemplo, <http://lwn.net>), o situados en una línea solos. Una advertencia para aquellos que usan comillas dobles: nunca mueva símbolos de puntuación que no pertenezcan a la URI (tales como el punto y final de una frase o la coma en una lista) dentro de ella, ya que esto cambiará su valor. En lugar de eso, use "<>", o cambie a un sistema de notación para no incluir nunca en él caracteres extraños. Este último sistema, llamado el 'nuevo' o 'lógico' sistema de entrecomillado mediante "Las reglas de Hart"y el "Diccionario Oxford para Ecritores y Editores", se considera una buena práctica en Gran Bretaña y en varios idiomas europeos. Algunos documentos más antiguos sugerían añadir el prefijo "URL" justo antes de la URI, pero esta solución nunca llegó a adoptarse mayoritariamente.

The URI syntax was designed to be unambiguous. However, as URIs have become commonplace, traditional media (television, radio, newspapers, billboards, etc.) have increasingly used abbreviated URI references consisting of only the authority and path portions of the identified resource (e.g., <www.w3.org/Addressing>). Such references are primarily intended for human interpretation rather than machine, with the assumption that context-based heuristics are sufficient to complete the URI (e.g., hostnames beginning with "www" are likely to have a URI prefix of "http://" and hostnames beginning with "ftp" likely to have a prefix of "ftp://"). Many client implementations heuristically resolve these references. Such heuristics may change over time, particularly when new schemes are introduced. Since an abbreviated URI has the same syntax as a relative URL path, abbreviated URI references cannot be used where relative URIs are permitted, and can be used only when there is no defined base (such as in dialog boxes). Don't use abbreviated URIs as hypertext links inside a document; use the standard format as described here.

ESTÁNDARES
(IETF RFC 2396) (http://www.ietf.org/rfc/rfc2396.txt), (HTML 4.0) (http://www.w3.org/TR/REC-html40).

NOTAS
Any tool accepting URIs (e.g., a web browser) on a Linux system should be able to handle (directly or indirectly) all of the schemes described here, including the man: and info: schemes. Handling them by invoking some other program is fine and in fact encouraged.

Technically, the fragment isn't part of the URI.

Para obtener información sobre cómo incrustar URI (incluidas URL) en un formato de datos, consulte la documentación sobre ese formato. HTML usa el formato <A HREF="uri"> text </A>. Los archivos Texinfo usan el formato @uref{uri}. Man y mdoc incluyen la macro UR recientemente añadida, o simplemente incluyen la URI en el texto (los lectores deberían poder detectar :// como parte de una URI).

Los gestores de escritorio KDE y GNOME actualmente varían en los URI que aceptan, en particular en sus respectivos navegadores de ayuda. Para listar las páginas del manual, GNOME usa <toc:man> mientras que KDE usa <info:(dir)> (el autor de esta página prefiere el sistema KDE mostrado aquí, aunque un formato más regular sería mejor). En general, KDE usa <file:/cgi-bin/> como prefijo para un conjunto de ficheros generados. KDE prefiere la documentación en formato HTML, siendo accedida a través de <file:/cgi-bin/helpindex>. GNOME prefiere el esquema ghelp para almacenar y encontrar documentación. Ningún navegador maneja referencias de tipo file: a directorios en el momento de crear este documento, haciendo difícil la referencia a entradas de directorio con un navegador URI. Como se ha indicado antes, estos entornos difieren sobre cómo manejar el esquema info:, probablemente es la mayor diferencia. Se espera que GNOME y KDE converjan a un mismo formato URI, y en el futuro esta página describirá el resultado de esa convergencia. Los esfuerzos para ayudar a esta convergencia son admirables.

  Seguridad
Un URI no posee por sí mismo un tratamiento de seguridad. No hay garantía general de que un URI, que en un tiempo localizó un recurso dado, continue haciéndolo. Ni hay ninguna garantía de que tal URL no localizará un recurso diferente pasado un tiempo. Tal garantía sólo se puede obtener de la(s) persona(s) que mantiene(n) el nombre y el recurso en cuestión.

A veces es posible construir un URL tal que al intentar realizar una operación aparentemente inofensiva, como la recuperación de una entidad asociada con el recurso, se produzca una posible operación remota peligrosa. El URL no seguro se construye típicamente especificando un número de puerto distinto del reservado por el protocolo de red en cuestión. El cliente, inconscientemente contacta con un sitio que de hecho está ejecutando un protocolo diferente. El contenido del URL contiene instrucciones que, cuando son interpretadas de acuerdo con este otro protocolo, causan una operación inexperada. Un ejemplo ha sido el uso de un URL gopher para enviar, a través de un servidor SMTP, un mensaje no intencionado o anónimo.

Caution should be used when using any URL that specifies a port number other than the default for the protocol; especially, when it is a number within the reserved space.

Care should be taken when a URI contains escaped delimiters for a given protocol (for example, CR and LF characters for telnet protocols) that these are not unescaped before transmission. This might violate the protocol, but avoids the potential for such characters to be used to simulate an extra operation or parameter in that protocol, which might lead to an unexpected and possibly harmful remote operation to be performed.

Es claramente una mala idea el uso de un URI que contenga una contraseña, la cual es -supuestamente- secreta. En particular, el uso de una contraseña con el componente 'userinfo' de un URI está muy desaconsejada excepto en el infrecuente supuesto de una contraseña para uso público.

ERRORES
Documentation may be placed in a variety of locations, so there currently isn't a good URI scheme for general online documentation in arbitrary formats. References of the form <file:///usr/doc/ZZZ> don't work, because different distributions and local installation requirements may place the files in different directories (it may be in /usr/doc, or /usr/local/doc, or /usr/share, or somewhere else). Also, the directory ZZZ usually changes when a version changes (though filename globbing could partially overcome this). Finally, using the file: scheme doesn't easily support people who dynamically load documentation from the Internet (instead of loading the files onto a local filesystem). A future URI scheme may be added (e.g., "userdoc:") to permit programs to include cross-references to more detailed documentation without having to know the exact location of that documentation. Alternatively, a future version of the filesystem specification may specify file locations sufficiently so that the file: scheme will be able to locate documentation.

Muchos programas y formatos de ficheros no incluyen una forma de incorporar o implementar enlaces usando URI.

Many programs can't handle all of these different URI formats; there should be a standard mechanism to load an arbitrary URI that automatically detects the users' environment (e.g., text or graphics, desktop environment, local user preferences, and currently executing tools) and invokes the right tool for any URI.

VÉASE TAMBIÉN
lynx(1), man2html(1), mailaddr(7), utf-8(7)

IETF RFC 2255 (http://www.ietf.org/rfc/rfc2255.txt)

TRADUCCIÓN
La traducción al español de esta página del manual fue creada por Angel Bueno Pardo <buenpar@teleline.es>, Juan Piernas <piernas@ditec.um.es>, Miguel Pérez Ibars <mpi79470@alu.um.es> y Marcos Fouces <marcos@debian.org>

Esta traducción es documentación libre; lea la GNU General Public License Version 3 (https://www.gnu.org/licenses/gpl-3.0.html) o posterior con respecto a las condiciones de copyright. No existe NINGUNA RESPONSABILIDAD.

Si encuentra algún error en la traducción de esta página del manual, envíe un correo electrónico a debian-l10n-spanish@lists.debian.org.