Provided by: manpages-es_4.27.0-1_all 
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
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 <http://lwn.net>.
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 variable=valor separadas por el carácter
ampersand (&). Advierta que variable 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 http://www.w3.org/CGI para más
información.
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
El puerto por defecto es el 70. tipogopher 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".
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>.
Un identificador-mensaje corresponde a Message-ID de IETF RFC 1036, sin encerrarlo entre "<" y ">". Toma
la forma unico@nombre_completo_dominio. Un identificador de mensaje puede ser distinguido de un nombre de
grupo de noticias por la presencia del carácter "@".
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
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 <info:gcc> y
<info:gcc#G++_and_GCC>.Ejemplos del formato de KDE son <info:(gcc)> y <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
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 RFC 2255 Los
componentes de esta URL son:
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 el Nombre LDAP Distinguido, que identifica el objeto base de la búsqueda LDAP (vea RFC 2253
sección 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 especifica el filtro de la búsqueda (subconjunto de entradas a devolver). Si se omite, se deberían
devolver todas las entradas. Vea RFC 2254 sección 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
Este esquema designa a una base de datos, búsqueda o documento WAIS (vea IETF RFC 1625 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).
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 database. La tercer forma designa un documento particular a recuperar
dentro de una base de datos WAIS. wtype es una designación WAIS del tipo del objeto y wpath es el
identificador de documento WAIS.
Otros formatos
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.
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:
- _ . ! ~ * ' ( )
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".
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.
Para las URI que deben gestionar caracteres ajenos a ASCII de EE. UU., la especificación HTML 4.01
(sección B.2) y la RFC 3986 de IETF (último párrafo de la sección 2.5) recomiendan el siguiente enfoque:
(1) traducir las secuencias de caracteres a UTF-8 (RFC 3629 de IETF)—ver utf-8(7)—y luego
(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.
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, <www.w3.org/Addressing>). 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í.
ESTÁNDARES
(IETF RFC 2396), (HTML 4.0).
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.
Tecnicamente el fragmento no es parte del URI.
Para informarse sobre como incrustar URI (incluidos URLs) en formato de datos, véase la documentación
sobre ese formato. HTML usa el formato <A HREF="uri"> texto </A>. Los archivos Textinfo usan el formato
@uref{uri}. 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).
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.
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.
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.
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
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
<file:///usr/doc/ZZZ> 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.
Muchos programas y formatos de ficheros no incluyen una forma de incorporar o implementar enlaces usando
URI.
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.
VÉASE TAMBIÉN
lynx(1), man2html(1), mailaddr(7), utf-8(7)
IETF RFC 2255
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 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.
Páginas de Manual de Linux 6.9.1 2 Mayo 2024 uri(7)