.\" -*- coding: UTF-8 -*-
.\" (C) Copyright 1999-2000 David A. Wheeler (dwheeler@dwheeler.com)
.\"
.\" SPDX-License-Identifier: Linux-man-pages-copyleft
.\"
.\" Fragments of this document are directly derived from IETF standards.
.\" For those fragments which are directly derived from such standards,
.\" the following notice applies, which is the standard copyright and
.\" rights announcement of The Internet Society:
.\"
.\" Copyright (C) The Internet Society (1998). All Rights Reserved.
.\" This document and translations of it may be copied and furnished to
.\" others, and derivative works that comment on or otherwise explain it
.\" or assist in its implementation may be prepared, copied, published
.\" and distributed, in whole or in part, without restriction of any
.\" kind, provided that the above copyright notice and this paragraph are
.\" included on all such copies and derivative works. However, this
.\" document itself may not be modified in any way, such as by removing
.\" the copyright notice or references to the Internet Society or other
.\" Internet organizations, except as needed for the purpose of
.\" developing Internet standards in which case the procedures for
.\" copyrights defined in the Internet Standards process must be
.\" followed, or as required to translate it into languages other than English.
.\"
.\" Modified Fri Jul 25 23:00:00 1999 by David A. Wheeler (dwheeler@dwheeler.com)
.\" Modified Fri Aug 21 23:00:00 1999 by David A. Wheeler (dwheeler@dwheeler.com)
.\" Modified Tue Mar 14 2000 by David A. Wheeler (dwheeler@dwheeler.com)
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH uri 7 "30 Abril 2023" "Páginas de manual de Linux 6.05.01"
.SH NOMBRE
uri, url, urn \- identificador uniforme de recursos (URI), incluido un URL o
URN
.SH SINOPSIS
.SY "\fIURI\fP ="
[\~\fIabsoluteURI\fP | \fIrelativeURI\fP\~] [\~\[dq]\fB#\fP\[dq]\~ \fIfragment\fP\~]
.YS
.PP
.SY "\fIabsoluteURI\fP ="
\fIscheme\~\fP \[dq]\fB:\fP\[dq] (\~\fIhierarchical_part\fP | \fIopaque_part\fP\~)
.YS
.PP
.SY "\fIrelativeURI\fP ="
(\~\fInet_path\fP | \fIabsolute_path\fP | \fIrelative_path\fP\~) [\~\[dq]\fB?\fP\[dq]\~
\fIquery\fP\~]
.YS
.PP
.SY "\fIscheme\fP ="
\[dq]\fBhttp\fP\[dq] | \[dq]\fBftp\fP\[dq] | \[dq]\fBgopher\fP\[dq] |
\[dq]\fBmailto\fP\[dq] | \[dq]\fBnews\fP\[dq] | \[dq]\fBtelnet\fP\[dq] |
\[dq]\fBfile\fP\[dq] | \[dq]\fBftp\fP\[dq] | \[dq]\fBman\fP\[dq] | \[dq]\fBinfo\fP\[dq]
| \[dq]\fBwhatis\fP\[dq] | \[dq]\fBldap\fP\[dq] | \[dq]\fBwais\fP\[dq] | \&...
.YS
.PP
.SY "\fIhierarchical_part\fP ="
(\~\fInet_path\fP | \fIabsolute_path\fP\~) [\~\[dq]\fB?\fP\[dq]\~ \fIquery\fP\~]
.YS
.PP
.SY "\fInet_path\fP ="
\[dq]\fB//\fP\[dq]\~ \fIauthority\fP [\~\fIabsolute_path\fP\~]
.YS
.PP
.SY "\fIabsolute_path\fP ="
\[dq]\fB/\fP\[dq]\~ \fIpath_segments\fP
.YS
.PP
.SY "\fIrelative_path\fP ="
\fIrelative_segment\fP [\~\fIabsolute_path\fP\~]
.YS
.SH 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.
.PP
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).
.PP
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|".
.PP
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
\[aq]#\[aq] identifica al fragmento. Un URI que comience con \[aq]#\[aq] se
refiere al fragmento del recurso actual.
.SS "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 \fIservidor_ip\fP (los corchetes muestran qué es opcional):
.PP
\fIservidor_ip = \fP[\fIusuario\fP [ : \fIcontraseña\fP ] @ ] \fIhost\fP [ : \fIpuerto\fP]
.PP
Este formato te permite opcionalmente insertar un nombre de usuario, una
contraseña y/o un número de puerto. El \fIhost\fP 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
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.
.PP
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.
.PP
\fBhttp \- Servidor (HTTP) Web\fP
.PP
http://\fIservidor_ip\fP/\fIruta\fP
.br
http://\fIservidor_ip\fP/\fIruta\fP?\fIcuestion\fP
.PP
Esto es un URL accediendo a un servidor (HTTP) Web. El puerto por defecto es
80. Si la ruta se refiere a un directorio, el servidor web elegirá que
devolver. Normalmente, si existe un fichero llamado "index.html" o
"index.htm" será mostrado, en otro caso, se devuelve una lista de los
ficheros del directorio actual (con los enlaces apropiados). Un ejemplo es
.
.PP
Una pregunta se puede dar en el formato obsoleto "isindex", constituido por
una palabra o frase y no incluyendo un signo igual(=). Una petición también
se puede dar en un formato más largo "GET", el cual tiene una o más
peticiones de entrada para el formulario \fIvariable\fP=\fIvalor\fP separadas por
el carácter ampersand (&). Advierta que \fIvariable\fP puede ser repetida más
de una vez, piense que son el servidor web y sus aplicaciones los encargados
de determinar si tiene significado. Existe una interacción desafortunada
entre HTML/XML/SGML y este formato. Cuando tales URI con más de una variable
se insertan en un documento SGML/XML (incluyendo HTML), el ampersand (&) es
reescrito como &. Advierta que no todas las preguntas tienen este
formato. Formatos más largos puede que sean demasiado largos para ser
almacenados como una URI, por lo que usan un mecanismo interactivo diferente
llamado POST, el cual no incluye los datos en el URI. Véase la
especificación del "Common Gateway Interface" en
.UR http://www.w3.org\:/CGI
.UE
para más información.
.PP
\fBftp \- Protocolo de Transferencia de Ficheros (FTP)\fP
.PP
ftp://\fIservidor_ip\fP/\fIruta\fP
.PP
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 .
.PP
\fBgopher \- servidor Gopher\fP
.PP
gopher://\fIservidor_ip\fP/\fIselector tipogopher\fP
.br
gopher://\fIservidor_ip\fP/\fIselector tipogopher\fP%09\fIsearch\fP
.br
gopher://\fIservidor_ip\fP/\fIselector tipogopher\fP%09\fIsearch\fP%09\fIgopher+_cadena\fP
.br
.PP
El puerto por defecto es el 70. \fItipogopher\fP es un campo de un sólo
carácter que indica el tipo de recurso Gopher al que se refiere el URL. La
ruta entera también puede estar vacía, y en tal caso el delimitador "/" es
también opcional, siendo el tipogopher por defecto "1".
.PP
\fIselector\fP 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).
.PP
\fBmailto \- dirección de correo\fP
.PP
mailto:\fIdirección_de_correo\fP
.PP
Esto es una dirección de correo electrónico, normalmente de la forma
\fInombre\fP@\fInombrehost\fP. Véase \fBmailaddr\fP(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
.
.PP
\fBnews \- Grupo de noticias o Mensaje de noticias\fP
.PP
news:\fInombre\-gruponoticias\fP
.br
news:\fIidentificador\-mensaje\fP
.PP
Un \fInombre\-gruponoticias\fP es un nombre jerárquico delimitado por puntos,
tal como "comp.infosystems.www.misc". Si es "*"
(como ), se usa para referirse a "todos los grupos de
noticias disponibles". Un ejemplo es .
.PP
Un \fIidentificador\-mensaje\fP corresponde a Message\-ID de
.UR http://www.ietf.org\:/rfc\:/rfc1036.txt
IETF RFC\ 1036,
.UE
sin
encerrarlo entre "<" y ">". Toma la forma
\fIunico\fP@\fInombre_completo_dominio\fP. Un identificador de mensaje puede ser
distinguido de un nombre de grupo de noticias por la presencia del carácter
"@".
.PP
\fBtelnet \- sesión Telnet\fP
.PP
telnet://\fIservidor_ip\fP/
.PP
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 .
.PP
\fBfile \- Fichero normal\fP
.PP
file://\fIservidor_ip\fP/\fIruta\fP
.br
file:\fIruta\fP
.PP
Esto representa un fichero o directorio que se puede acceder
localmente. Como caso especial, \fIservidor_ip\fP 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 . Si no se
encuentra el fichero indicado, los escritores de visualizadores pueden
querer el intentar expandir el nombre del fichero mediante comodines (vea
\fBglob\fP(7) y \fBglob\fP(3)).
.PP
El segundo formato (por ejemplo, ) 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, . 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 .
.PP
\fBman \- páginas man de documentación\fP
.PP
man:\fInombre\-orden\fP
.br
man:\fInombre\-orden\fP(\fIsección\fP)
.PP
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 \fBman\fP(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 .
.PP
\fBinfo \- Documentación en páginas info\fP
.PP
info:\fInombrefichero\-virtual\fP
.br
info:\fInombrefichero\-virtual\fP#\fInombrenodo\fP
.br
info:(\fInombrefichero\-virtual\fP)
.br
info:(\fInombrefichero\-virtual\fP)\fInombrenodo\fP
.PP
Este esquema hace referencia a las páginas de referencia en línea del
sistema info (generadas a partir de ficheros texinfo), un formato de
documentación usado por programas tales como las herramientas GNU. Este
modelo URI es único en los sistemas tipo UNIX (tales como Linux) y
actualmente no está registrado por el IETF. En el momento de escribir esto,
GOME y KDE difieren en sus sintáxis URI y no aceptan la sistáxis del
otro. Los primeros dos formatos son el formato de GNOME. Todos los espacios
en los nombres de los nodos se escriben como subrayados. Los otros dos
formatos son el formato de KDE. Los espacios en los nombres de los nodos se
escriben como espacios, aunque esto está prohibido por los estándares
URI. Se espera que en un futuro la mayoría de las herramientas comprendan
ambos formatos y que acepten subrayados para los espacios en los nombres de
los nodos. Tanto en GNOME como en KDE, si se usa la forma sin el nombre de
nodo, se asume "Top" como nombre de nodo. Ejemplos del formato de GNOME son
y .Ejemplos del formato de
KDE son y .
.PP
\fBwhatis \- búsqueda de documentación\fP
.PP
whatis:\fIcadena\fP
.PP
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 \fBwhatis\fP(1). Este
esquema URI es único en los sistemas al estilo UNIX (tales como Linux) y
actualmente no está registrado por el IETF.
.PP
\fBghelp \- documentación de ayuda de GNOME\fP
.PP
ghelp:\fIghelp: nombre\-de\-aplicación\fP
.PP
Carga la ayuda de GNOME para la aplicación dada. Dese cuenta que actualmente
no existe mucha documentación en este formato.
.PP
\fBldap \- Protocolo Ligero de Acceso a Directorios\fP
.PP
ldap://\fIhostport\fP
.br
ldap://\fIhostport\fP/
.br
ldap://\fIhostport\fP/\fIdn\fP
.br
ldap://\fIhostport\fP/\fIdn\fP?\fIattributes\fP
.br
ldap://\fIhostport\fP/\fIdn\fP?\fIattributes\fP?\fIscope\fP
.br
ldap://\fIhostport\fP/\fIdn\fP?\fIattributes\fP?\fIscope\fP?\fIfilter\fP
.br
ldap://\fIhostport\fP/\fIdn\fP?\fIattributes\fP?\fIscope\fP?\fIfilter\fP?\fIextensions\fP
.PP
Este esquema soporta consultas al protocolo LDAP (Lightweight Directory
Access Protocol), un protocolo para consultar a un conjunto de servidores
sobre información organizada jerárquicamente (como personas y recursos del
equipo). Puede encontrar más información sobre el esquema URL para LDAP en
.UR http://www.ietf.org\:/rfc/rfc2255.txt
RFC\ 2255
.UE
Los
componentes de esta URL son:
.TP
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.
.TP
dn
el Nombre LDAP Distinguido, que identifica el objeto base de la búsqueda
LDAP (vea
.UR http://www.ietf.org\:/rfc\:/rfc2253.txt
RFC\ 2253
.UE
sección 3).
.TP
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.
.TP
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".
.TP
filter
especifica el filtro de la búsqueda (subconjunto de entradas a devolver). Si
se omite, se deberían devolver todas las entradas. Vea
.UR http://www.ietf.org\:/rfc\:/rfc2254.txt
RFC\ 2254
.UE
sección 4.
.TP
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 \[aq]!\[aq] es crítica (debe estar soportada para ser
válida), en otro caso no es crítica (opcional).
.PP
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.:
.PP
.nf
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US
.fi
.PP
Para obtener simplemente su atributo de dirección postal, pregunte:
.PP
.nf
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress
.fi
.PP
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:
.PP
.nf
ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)
.fi
.PP
\fBwais \- Wide Area Information Servers (Servidores de Información de Área Amplia)\fP
.PP
wais://\fIhostport\fP/\fIdatabase\fP
.br
wais://\fIhostport\fP/\fIdatabase\fP?\fIsearch\fP
.br
wais://\fIhostport\fP/\fIdatabase\fP/\fIwtype\fP/\fIwpath\fP
.PP
Este esquema designa a una base de datos, búsqueda o documento WAIS (vea
.UR http://www.ietf.org\:/rfc\:/rfc1625.txt
IETF RFC\ 1625
.UE
para
obtener más información sobre WAIS). Hostport es el nombre del anfitrión,
seguido opcionalmente por dos puntos y un número de puerto (el número de
puerto por omisión es 210).
.PP
La primera forma designa a una base de datos WAIS en la que buscar. La
segunda forma designa una búsqueda particular en la base de datos WAIS
\fIdatabase\fP. La tercer forma designa un documento particular a recuperar
dentro de una base de datos WAIS. \fIwtype\fP es una designación WAIS del tipo
del objeto y \fIwpath\fP es el identificador de documento WAIS.
.PP
\fBOtros formatos\fP
.PP
Existen muchos otros esquemas URI diferentes. La mayoría de las herramientas
que aceptan URI, también soportan un conjunto de URI internos (por ejemplo,
Mozilla tiene el esquema about: para información interna, y el navegador de
ayuda de GNOME tiene el formato toc: para diversas localizaciones de
comienzo. Hay muchos esquemas que han sido definidos, pero que actualmente
no se usan de forma amplia. (por ejemplo, prospero). El esquema nntp: está
en desuso en favor del esquema news:. Las URNs van a ser soportadas por el
esquema urn:, con un espacio de nombres jerárquico (por ejemplo,
urn:ietf:... identificaría documentos IETF). En este momento, las URNs no
están ampliamente implementadas. No todas las herramientas soportan todos
los esquemas.
.SS "Codificación de caracteres"
Las URI usan un número limitado de caracteres que pueden ser tecleados y
usados multitud de situaciones.
.PP
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):
.IP
.in +4n
.EX
; / ? : @ & = + $ ,
.EE
.in
.PP
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:
.IP
.in +4n
.EX
\- _ . ! \[ti] * ' ( )
.EE
.in
.PP
Los demás caracteres se deben preceder con caracteres de escape. Un octeto
con escape se codifica como un carácter triple, constituido por el carácter
de porcentaje "%" seguido de dos dígitos hexadecimales que representan el
código del octeto (puede usar letras mayúsculas y minúsculas para los
dígitos hexadecimales). Por ejemplo, un espacio en blanco se debe
representar como "%20", el carácter tabulador como "%09", y el "&" como
"%26". Ya que el carácter de porcentaje siempre tiene el propósito reservado
de comenzar una secuencia de escape, se debe representar como "%25". Es una
práctica común indicar los caracteres de espacio con el símbolo (+) en
frases para consulta. Esta práctica no está definida de forma concisa en los
RFCs relevantes (los cuales recomiendan %20 en su lugar) pero cualquier
aplicación que reciba URI debería estar preparada para ellos. Un URI siempre
se muestra en su forma "de escape".
.PP
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 "\[ti]" en una ruta HTTP URL pero las dos
son equivalentes para una URL HTTP.
.PP
Para las URI que deban manejar caracteres fuera del conjunto de caracteres
US ASCII, la especificación HTML 4.01 (sección B.2) y el IETF RFC\~3986
(úlitmo párrafo de la sección 2.5) recomiendan lo siguiente:
.IP (1) 5
traducir las secuencias de caracteres a UTF\-8 (IETF RFC\~3629)\[em]consulte
\fButf\-8\fP(7) \[em]y a continuación
.IP (2)
usar el mecanismo de escape URI, es decir, usar la codificación %HH para
octetos problemáticos.
.SS "Escritura de URI"
Cuando son escritos, las URI deberían introducirse entre comillas (por
ejemplo, "http://www.kernel.org"), encerrados entre <> (por ejemplo,
), o situados en una línea solos. Una advertencia
para aquellos que usan comillas dobles: \fBnunca\fP 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.
.PP
La sintáxis URI se diseñó para que no fuera ambigua. Además, como las URI se
han convertido en un lugar común, los medios tradicionales (televisión,
radio, periódicos, vallas publicitarias, etc.) han incrementado el uso de
referencias abreviadas URI formadas sólo por la autoridad y partes de la
ruta del identificativo del recurso (por ejemplo,
). Tales referencias son principalmente
entendidas por la interpretación humana más que por las máquinas, asumiendo
que el estudio del contexto es suficiente para completar el URI (es decir,
nombres de host que comiencen por "www" son como tener un prefijo URI
"http://" y los host que comiencen con "ftp" usualmente tendrán un prefijo
"ftp://"). Algunas implementaciones de clientes resuelven heurísticamente
estas referncias. Tales heurísticas pueden cambiar con el tiempo,
particularmente cuando se introduzcan nuevos esquemas. Ya que un URI
abreviado tiene la misma sintaxis que una ruta URL relativa, la referencia
URI relativa no se puede usar donde los URI relativos son permitidos, y sólo
se pueden usar cuando no hay una base definida (como en cuadros de
diálogo). No use URI abreviados como enlaces de hipertexto dentro de un
documento. Use el formato estándar como se describe aquí.
.SH ESTÁNDARES
.UR http://www.ietf.org\:/rfc\:/rfc2396.txt
(IETF RFC\ 2396)
.UE ,
.UR http://www.w3.org\:/TR\:/REC\-html40
(HTML 4.0)
.UE .
.SH NOTAS
Algunas herramientas de un sistema Linux que aceptan URI (por ejemplo, un
navegador) deberían ser capaces de manejar (directa o indirectamente) todos
los esquemas aquí descritos, incluyendo los esquemas man: e
info:. Manejarlos invocando otros programas está bien, y de hecho es lo
apropiado.
.PP
Tecnicamente el fragmento no es parte del URI.
.PP
Para informarse sobre como incrustar URI (incluidos URLs) en formato de
datos, véase la documentación sobre ese formato. HTML usa el formato \fItexto\fP . Los archivos Textinfo usan el
formato @uref{\fIuri\fP}. Man y mdoc han añadido recientemente la macro UR, o
simplemente incluyendo el URI en el texto (los visores deben ser capaces de
detectar :// como parte de un URI).
.PP
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 mientras que KDE usa
(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 como prefijo para un conjunto de ficheros
generados. KDE prefiere la documentación en formato HTML, siendo accedida a
través de . 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.
.SS 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.
.PP
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.
.PP
Se debería llevar cuidado cuando se usa un URL que especifica un número de
puerto diferente del que viene por defecto para el protocolo, especialmente
cuando se trata de un número dentro del espacio reservado.
.PP
Se debería andar con precaución cuando se usa un URI que contiene
delimitadores de escape para un protocolo dado (por ejemplo, los caracteres
CR y LF para protocolos de telnet) ya que no son decodificados antes de la
transmisión. Esto puede violar el protocolo, pero evita el peligro de que
algunos caracteres sean usados para simular una operación o parámetro extra
en ese protocolo, el cual puede que conduzca a que se lleve a caba una
inesperada y posiblemente dañina operación.
.PP
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.
.SH ERRORES
La documentación puede estar situada en variedad de lugares, por lo que
actualmente no es un buen esuqema URI para la documentación en línea de
ámbito general con diferentes formatos. Referencias de la forma
no funcionan porque distribuciones diferentes
y requisitos de instalación locales diferentes puede que situen los archivos
en directorios diferentes (puede ser en /usr/doc, o /usr/local/doc, o
/usr/share, o cualquier otro sitio). Además, el directorio ZZZ normalmente
cambia con la versión. Por último, usar el esquema file: no es sencillo para
las personas que cargan documentación dinámica de Internet (en lugar de
cargar ficheros en un sistema de archivos local). Un futuro URI puede ser
añadido (por ejemplo "userdoc:") para permitirle a los programas incluir
referencias cruzadas a documentación con más detalle sin tener que saber la
posición exacta de dicha documentación. Alternativamente, una versión futura
de la especificación del sistema de ficheros puede que especifique
suficientemente las localizaciones de los ficheros para que el esquema file:
sea capaz de encontrar la documentación.
.PP
Muchos programas y formatos de ficheros no incluyen una forma de incorporar
o implementar enlaces usando URI.
.PP
.\" .SH AUTHOR
.\" David A. Wheeler (dwheeler@dwheeler.com) wrote this man page.
Algunos programas no pueden manejar todos los formatos URI. Debería haber un
mecanismo estándar, para cargar un URI, que automáticamente detectara el
entorno del usuario (por ejemplo, texto o gráfico, entorno de escritorio,
preferencias de usuario local, y herramientas que se ejecutan actualmente) y
que invocara la herramienta adecuada para cualquier URI.
.SH "VÉASE TAMBIÉN"
\fBlynx\fP(1), \fBman2html\fP(1), \fBmailaddr\fP(7), \fButf\-8\fP(7)
.PP
.UR http://www.ietf.org\:/rfc\:/rfc2255.txt
IETF RFC\ 2255
.UE
.PP
.SH TRADUCCIÓN
La traducción al español de esta página del manual fue creada por
Angel Bueno Pardo ,
Juan Piernas ,
Miguel Pérez Ibars
y
Marcos Fouces
.
.PP
Esta traducción es documentación libre; lea la
.UR https://www.gnu.org/licenses/gpl-3.0.html
GNU General Public License Version 3
.UE
o posterior con respecto a las condiciones de copyright.
No existe NINGUNA RESPONSABILIDAD.
.PP
Si encuentra algún error en la traducción de esta página del manual, envíe un
correo electrónico a
.MT debian-l10n-spanish@lists.debian.org
.ME .