uri(7) Miscellaneous Information Manual uri(7)
NOMBRE
uri, url, urn - identificador uniforme de recursos (URI), incluido un
URL o URN
SINOPSIS
URI = [ absoluteURI | relativeURI ] [ "#" fragment ]
absoluteURI = scheme ":" ( hierarchical_part | opaque_part )
relativeURI = ( net_path | absolute_path | relative_path ) [ "?"
query ]
scheme = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" |
"file" | "ftp" | "man" | "info" | "whatis" | "ldap" | "wais" |
...
hierarchical_part = ( net_path | absolute_path ) [ "?" query ]
net_path = "//" authority [ absolute_path ]
absolute_path = "/" path_segments
relative_path = relative_segment [ absolute_path ]
DESCRIPCION
Un identificador uniforme de recursos (URI) es una cadena de caracteres
corta que identifica un recurso abstracto o fisico (por ejemplo, una
pagina web). Localizador de Recursos Uniforme (URL) es un URI que
identifica un recurso por su mecanismo de acceso primario (por ejemplo,
su ubicacion de), antes que por su nombre o algun otro atributo del
recurso. Un Nombre de Recurso Uniforme (URN) es un URI que debe ser
globalmente unico y permanecer aun cuando el recurso deja de existir o
pasa a ser inaccesible.
Los URI son la forma estandar de nombrar los destinos de los
hiperenlaces para herramientas tales como los navegadores web. La
cadena "http://www.kernel.org" es un URL (y tambien un URI). Algunas
personas usan el termino URL unicamente como sinonimo de URI (aunque
tecnicamente 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 traves 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 jerarquico actual" y "el nivel superior a este nivel
jerarquico", respectivamente, Tal y como lo hacen los sistemas al
estilo UNIX. Un segmento de ruta que contiene el caracter ":" no puede
ser usado como el primer segmento de ruta relativa URI (por ejemplo,
"esto:aquello"), porque seria erroneo 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 porcion
particular identificada (fragmento) de un recurso. El texto despues 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 aqui un servidor_ip (los corchetes
muestran que es opcional):
servidor_ip = [usuario [ : contrasena ] @ ] host [ : puerto]
Este formato te permite opcionalmente insertar un nombre de usuario,
una contrasena y/o un numero de puerto. El host es el nombre del
ordenador que hace de anfitrion, y su nombre se puede determinar
mediante su DNS o una direccion IP (numeros separados por puntos). Por
lo que el URI se
introduce en el servidor web del anfitrion example.com como fred
(usando fredcontrasena) usando el puerto 8080. Evite incluir
contrasenas 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 contrasena, y el servidor remoto pide la
contrasena, el programa que interpreta el URL debe requerir una del
usuario.
Aqui hay algunos de los esquemas mas comunes usados por sistemas al
estilo UNIX, los cuales son comprendidos por muchas aplicaciones.
Advierta que algunas aplicaciones usan URI y tambien tienen esquemas
internos o esquemas especializados. Vea en esas aplicaciones la
documentacion 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
elegira que devolver. Normalmente, si existe un fichero llamado
"index.html" o "index.htm" sera mostrado, en otro caso, se devuelve una
lista de los ficheros del directorio actual (con los enlaces
apropiados). Un ejemplo es .
Una pregunta se puede dar en el formato obsoleto "isindex", constituido
por una palabra o frase y no incluyendo un signo igual(=). Una peticion
tambien se puede dar en un formato mas largo "GET", el cual tiene una o
mas peticiones de entrada para el formulario variable=valor separadas
por el caracter ampersand (&). Advierta que variable puede ser repetida
mas de una vez, piense que son el servidor web y sus aplicaciones los
encargados de determinar si tiene significado. Existe una interaccion
desafortunada entre HTML/XML/SGML y este formato. Cuando tales URI con
mas 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 mas 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. Vease la especificacion del "Common Gateway Interface"
en para mas informacion.
ftp - Protocolo de Transferencia de Ficheros (FTP)
ftp://servidor_ip/ruta
Este es un URL de acceso a ficheros a traves 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
contrasena su direccion de correo electronico. Un ejemplo es
.
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 solo
caracter que indica el tipo de recurso Gopher al que se refiere el URL.
La ruta entera tambien puede estar vacia, y en tal caso el delimitador
"/" es tambien opcional, siendo el tipogopher por defecto "1".
selector es la cadena de seleccion Gopher. En el protocolo Gopher, las
cadenas de seleccion 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 caracter LF) y 0D (US-ASCII caracter
CR).
mailto - direccion de correo
mailto:direccion_de_correo
Esto es una direccion de correo electronico, normalmente de la forma
nombre@nombrehost. Vease mailaddr(7) para mas informacion acerca del
formato correcto de la direccion de correo electronico. Advierta que
cualquier caracter % debe ser reescrito como %25. Un ejemplo es
.
news - Grupo de noticias o Mensaje de noticias
news:nombre-gruponoticias
news:identificador-mensaje
Un nombre-gruponoticias es un nombre jerarquico 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 .
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 caracter "@".
telnet - sesion 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 traves del protocolo Telnet.
El caracter final "/" se puede omitir. El puerto por defecto es el 23.
Un ejemplo es .
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 vacia. Esto se interpreta como `la maquina
desde la que el URL esta siendo interpretado'. Si la ruta es hacia un
directorio, el visor deberia 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 traves 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 glob(7) y glob(3)).
El segundo formato (por ejemplo, ) es correcto para
referirse a archivos locales. Sin embargo, los estandares mas antiguos
no permitian este formato, y algunos programas no lo reconocen como un
URI. Una sintaxis mas portable es usar una cadena vacia como nombre del
servidor, por ejemplo, . Esto hace lo mismo y es
mas sencillo de reconocer para las expresiones regulares y los
programas mas antiguos como un URI. Advierta que si lo que realmente
quiere decir es "comienza desde la posicion actual," no especificas
todo el esquema. En cambio, usa la direccion relativa como
<../test.txt> que tiene el efecto colateral de ser independiente del
esquema. Un ejemplo de este esquema es .
man - paginas man de documentacion
man:nombre-orden
man:nombre-orden(seccion)
Esto se refiere a las paginas de referencia en linea del manual local.
El nombre de la orden opcionalmente puede ir precedido por un
parentesis y un numero de seccion. Vease man(7) para mas informacion
sobre el significado de los numeros de seccion. Este modelo URI es
unico en los sistemas tipo UNIX (como Linux) y actualmente no esta
registrado por la IETF. Un ejemplo es .
info - Documentacion en paginas info
info:nombrefichero-virtual
info:nombrefichero-virtual#nombrenodo
info:(nombrefichero-virtual)
info:(nombrefichero-virtual)nombrenodo
Este esquema hace referencia a las paginas de referencia en linea del
sistema info (generadas a partir de ficheros texinfo), un formato de
documentacion usado por programas tales como las herramientas GNU. Este
modelo URI es unico en los sistemas tipo UNIX (tales como Linux) y
actualmente no esta registrado por el IETF. En el momento de escribir
esto, GOME y KDE difieren en sus sintaxis URI y no aceptan la sistaxis
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 esta prohibido por
los estandares URI. Se espera que en un futuro la mayoria 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
.
whatis - busqueda de documentacion
whatis:cadena
Busca en la base de datos de descripciones cortas (una linea) de
ordenes y devuelve una lista con las descripciones que contienen esa
cadena. Solo se muestran coincidencias de palabras completas. Vease
whatis(1). Este esquema URI es unico en los sistemas al estilo UNIX
(tales como Linux) y actualmente no esta registrado por el IETF.
ghelp - documentacion de ayuda de GNOME
ghelp:ghelp: nombre-de-aplicacion
Carga la ayuda de GNOME para la aplicacion dada. Dese cuenta que
actualmente no existe mucha documentacion 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 informacion organizada jerarquicamente (como personas
y recursos del equipo). Puede encontrar mas informacion 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
anfitrion seguiro por dos puntos y un numero de puerto. El
puerto LDAP por omision es el puerto TCP 389. Si no se indica,
el cliente determina que servidor LDAP usar.
dn el Nombre LDAP Distinguido, que identifica el objeto base de la
busqueda LDAP (vea RFC 2253 seccion 3).
attributes
una lista de atributos, separados por comas, a devolver. Vea
RFC 2251 seccion 4.1.5. Si se omite, se deberian devolver todos
los atributos.
scope especifica el ambito de la busqueda, que puede ser "base" (para
una busqueda de objetos base), "one" (para una busqueda de un
nivel) o "sub" (para una busqueda de subarbol). Si se omite el
ambito, se asume "base".
filter especifica el filtro de la busqueda (subconjunto de entradas a
devolver). Si se omite, se deberian devolver todas las entradas.
Vea RFC 2254 seccion 4.
extensions
Una lista de parejas tipo=valor, separadas por comas, donde la
porcion =valor se puede omitir para opciones que no la
necesiten. Una extension prefijada con un '!' es critica (debe
estar soportada para ser valida), en otro caso no es critica
(opcional).
Las consultas LDAP son mas faciles de explicar mediante ejemplos. Aqui
tiene una consulta que pide a ldap.itd.umich.edu informacion 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 direccion postal, pregunte:
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress
Para pedir informacion a host.com en el puerto 6666 sobre la persona de
nombre comun (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 Informacion de Area
Amplia)
wais://hostport/database
wais://hostport/database?search
wais://hostport/database/wtype/wpath
Este esquema designa a una base de datos, busqueda o documento WAIS
(vea IETF RFC 1625 para obtener
mas informacion sobre WAIS). Hostport es el nombre del anfitrion,
seguido opcionalmente por dos puntos y un numero de puerto (el numero
de puerto por omision es 210).
La primera forma designa a una base de datos WAIS en la que buscar. La
segunda forma designa una busqueda 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 designacion WAIS del
tipo del objeto y wpath es el identificador de documento WAIS.
Otros formatos
Existen muchos otros esquemas URI diferentes. La mayoria de las
herramientas que aceptan URI, tambien soportan un conjunto de URI
internos (por ejemplo, Mozilla tiene el esquema about: para informacion
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: esta en desuso en favor del
esquema news:. Las URNs van a ser soportadas por el esquema urn:, con
un espacio de nombres jerarquico (por ejemplo, urn:ietf:...
identificaria documentos IETF). En este momento, las URNs no estan
ampliamente implementadas. No todas las herramientas soportan todos los
esquemas.
Codificacion de caracteres
Las URI usan un numero 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 esta limitado a su proposito especifico (los datos
conflictivos deben ser precedidos por una caracter 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
mayusculas y minuscula, los digitos, y el siguiente conjunto de marcas
de puntuacion y simbolos:
- _ . ! ~ * ' ( )
Los demas caracteres se deben preceder con caracteres de escape. Un
octeto con escape se codifica como un caracter triple, constituido por
el caracter de porcentaje "%" seguido de dos digitos hexadecimales que
representan el codigo del octeto (puede usar letras mayusculas y
minusculas para los digitos hexadecimales). Por ejemplo, un espacio en
blanco se debe representar como "%20", el caracter tabulador como
"%09", y el "&" como "%26". Ya que el caracter de porcentaje siempre
tiene el proposito reservado de comenzar una secuencia de escape, se
debe representar como "%25". Es una practica comun indicar los
caracteres de espacio con el simbolo (+) en frases para consulta. Esta
practica no esta definida de forma concisa en los RFCs relevantes (los
cuales recomiendan %20 en su lugar) pero cualquier aplicacion que
reciba URI deberia estar preparada para ellos. Un URI siempre se
muestra en su forma "de escape".
Los caracteres no reservados se pueden escapar sin cambiar la semantica
de la URI, pero esto no se deberia hacer a menos que la URI se este
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 deban manejar caracteres fuera del conjunto de
caracteres US ASCII, la especificacion HTML 4.01 (seccion B.2) y el
IETF RFC 3986 (ulitmo parrafo de la seccion 2.5) recomiendan lo
siguiente:
(1) traducir las secuencias de caracteres a UTF-8 (IETF
RFC 3629)--consulte utf-8(7) --y a continuacion
(2) usar el mecanismo de escape URI, es decir, usar la codificacion
%HH para octetos problematicos.
Escritura de URI
Cuando son escritos, las URI deberian introducirse entre comillas (por
ejemplo, "http://www.kernel.org"), encerrados entre <> (por ejemplo,
), o situados en una linea solos. Una advertencia para
aquellos que usan comillas dobles: nunca mueva simbolos de puntuacion
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 cambiara su valor. En
lugar de eso, use "<>", o cambie a un sistema de notacion para no
incluir nunca en el caracteres extranos. Este ultimo sistema, llamado
el 'nuevo' o 'logico' sistema de entrecomillado mediante "Las reglas de
Hart"y el "Diccionario Oxford para Ecritores y Editores", se considera
una buena practica en Gran Bretana y en varios idiomas europeos.
Algunos documentos mas antiguos sugerian anadir el prefijo "URL" justo
antes de la URI, pero esta solucion nunca llego a adoptarse
mayoritariamente.
La sintaxis URI se diseno para que no fuera ambigua. Ademas, como las
URI se han convertido en un lugar comun, los medios tradicionales
(television, radio, periodicos, vallas publicitarias, etc.) han
incrementado el uso de referencias abreviadas URI formadas solo por la
autoridad y partes de la ruta del identificativo del recurso (por
ejemplo, ). Tales referencias son principalmente
entendidas por la interpretacion humana mas que por las maquinas,
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
tendran un prefijo "ftp://"). Algunas implementaciones de clientes
resuelven heuristicamente estas referncias. Tales heuristicas 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 solo se pueden usar cuando no hay una base
definida (como en cuadros de dialogo). No use URI abreviados como
enlaces de hipertexto dentro de un documento. Use el formato estandar
como se describe aqui.
ESTANDARES
(IETF RFC 2396) , (HTML 4.0)
.
NOTAS
Algunas herramientas de un sistema Linux que aceptan URI (por ejemplo,
un navegador) deberian ser capaces de manejar (directa o
indirectamente) todos los esquemas aqui descritos, incluyendo los
esquemas man: e info:. Manejarlos invocando otros programas esta 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, vease la documentacion sobre ese formato. HTML usa el formato texto . Los archivos Textinfo usan el formato
@uref{uri}. Man y mdoc han anadido 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 varian en los URI
que aceptan, en particular en sus respectivos navegadores de ayuda.
Para listar las paginas del manual, GNOME usa mientras que
KDE usa (el autor de esta pagina prefiere el sistema KDE
mostrado aqui, aunque un formato mas regular seria mejor). En general,
KDE usa como prefijo para un conjunto de ficheros
generados. KDE prefiere la documentacion en formato HTML, siendo
accedida a traves de . GNOME prefiere el
esquema ghelp para almacenar y encontrar documentacion. Ningun
navegador maneja referencias de tipo file: a directorios en el momento
de crear este documento, haciendo dificil la referencia a entradas de
directorio con un navegador URI. Como se ha indicado antes, estos
entornos difieren sobre como 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 pagina describira el resultado de esa
convergencia. Los esfuerzos para ayudar a esta convergencia son
admirables.
Seguridad
Un URI no posee por si mismo un tratamiento de seguridad. No hay
garantia general de que un URI, que en un tiempo localizo un recurso
dado, continue haciendolo. Ni hay ninguna garantia de que tal URL no
localizara un recurso diferente pasado un tiempo. Tal garantia solo se
puede obtener de la(s) persona(s) que mantiene(n) el nombre y el
recurso en cuestion.
A veces es posible construir un URL tal que al intentar realizar una
operacion aparentemente inofensiva, como la recuperacion de una entidad
asociada con el recurso, se produzca una posible operacion remota
peligrosa. El URL no seguro se construye tipicamente especificando un
numero de puerto distinto del reservado por el protocolo de red en
cuestion. El cliente, inconscientemente contacta con un sitio que de
hecho esta ejecutando un protocolo diferente. El contenido del URL
contiene instrucciones que, cuando son interpretadas de acuerdo con
este otro protocolo, causan una operacion inexperada. Un ejemplo ha
sido el uso de un URL gopher para enviar, a traves de un servidor SMTP,
un mensaje no intencionado o anonimo.
Se deberia llevar cuidado cuando se usa un URL que especifica un numero
de puerto diferente del que viene por defecto para el protocolo,
especialmente cuando se trata de un numero dentro del espacio
reservado.
Se deberia andar con precaucion 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 transmision. Esto puede violar el protocolo,
pero evita el peligro de que algunos caracteres sean usados para
simular una operacion o parametro extra en ese protocolo, el cual puede
que conduzca a que se lleve a caba una inesperada y posiblemente danina
operacion.
Es claramente una mala idea el uso de un URI que contenga una
contrasena, la cual es -supuestamente- secreta. En particular, el uso
de una contrasena con el componente 'userinfo' de un URI esta muy
desaconsejada excepto en el infrecuente supuesto de una contrasena para
uso publico.
ERRORES
La documentacion puede estar situada en variedad de lugares, por lo que
actualmente no es un buen esuqema URI para la documentacion en linea de
ambito general con diferentes formatos. Referencias de la forma
no funcionan porque distribuciones diferentes y
requisitos de instalacion 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). Ademas, el
directorio ZZZ normalmente cambia con la version. Por ultimo, usar el
esquema file: no es sencillo para las personas que cargan documentacion
dinamica de Internet (en lugar de cargar ficheros en un sistema de
archivos local). Un futuro URI puede ser anadido (por ejemplo
"userdoc:") para permitirle a los programas incluir referencias
cruzadas a documentacion con mas detalle sin tener que saber la
posicion exacta de dicha documentacion. Alternativamente, una version
futura de la especificacion del sistema de ficheros puede que
especifique suficientemente las localizaciones de los ficheros para que
el esquema file: sea capaz de encontrar la documentacion.
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. Deberia
haber un mecanismo estandar, para cargar un URI, que automaticamente
detectara el entorno del usuario (por ejemplo, texto o grafico, entorno
de escritorio, preferencias de usuario local, y herramientas que se
ejecutan actualmente) y que invocara la herramienta adecuada para
cualquier URI.
VEASE TAMBIEN
lynx(1), man2html(1), mailaddr(7), utf-8(7)
IETF RFC 2255
TRADUCCION
La traduccion al espanol de esta pagina del manual fue creada por Angel
Bueno Pardo , Juan Piernas ,
Miguel Perez Ibars y Marcos Fouces
Esta traduccion es documentacion libre; lea la GNU General Public
License Version 3 o
posterior con respecto a las condiciones de copyright. No existe
NINGUNA RESPONSABILIDAD.
Si encuentra algun error en la traduccion de esta pagina del manual,
envie un correo electronico a .
Paginas de manual de Linux 6.06 31 Octubre 2023 uri(7)