Provided by: manpages-pt_20040726-4_all 
NOME
uri, url, urn - identificador uniforme de recursos (URI), incluindo uma URL ou URN
SINOPSE
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" | "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 ]
DESCRIÇÃO
Um Identificador Uniforme de Recursos (Uniform Resource Identifier - URI) é uma string de
caracteres curta que identifica um recurso abstrato ou físico (por exemplo, uma página da
Web). Um Localizador Uniforme de Recursos (Uniform Resource Locator - URL) é uma URI que
identifica um recurso através do seu mecanismo de acesso primário (por exemplo, sua
"localização" de rede), em vez do nome ou algum outro atributo daquele recurso. Um Nome
Uniforme de Recurso (Uniform Resource Name - URN) é uma URI que precisa manter-se única e
persistente globalmente, mesmo quando o recurso deixa de existir ou se torna indisponível.
As URIs são o meio padrão de nomear destinos de links de hipertexto para ferramentas como
os web browsers. A string "http://www.kernelnotes.org" é uma URL (e portanto é uma URI).
Muitas pessoas usam o termo URL largamente como um sinônimo de URI (apesar de que,
tecnicamente, as URLs formam um subconjunto das URIs).
As URIs podem ser absolutas ou relativas. Um identificador absoluto refere-se a um
recurso independente de contexto, enquanto um identificador relativo refere-se a um
recurso através da descrição de diferenças de um contexto corrente. Dentro de uma
referência de caminho relativo, os segmentos completos de caminhos "." e ".." têm
significados especiais: "o nível de hierarquia corrente" e "o nível acima deste nível de
hierarquia", respectivamente, exatamente como são nos sistemas do tipo Unix. Um segmento
de caminho que contém um caractere de dois-pontos não pode ser usado como o primeiro
segmento de um caminho relativo de uma URI (por exemplo, "isto:aquilo"), porque ele
poderia ser enganado por um nome de esquema; preceda tal segmento com ./ (por exemplo,
"./isto:aquilo"). Note que os descendentes do MS-DOS (por exemplo, o Microsoft Windows)
substituem os dois-pontos do nome do dispositivo por uma barra vertical("|") em URIs, de
forma que "C:" se torna "C|".
Um identificador de fragmento, se incluído, refere-se a uma porção particular nomeada
(fragmento) de um recurso; textos depois de um '#' identificam o fragmento. Uma URI
começando com '#' refere-se a aquele fragmento no recurso corrente.
USO
Há muitos esquemas de URIs diferentes, cada um com regras e significados adicionais
específicos, mas eles são feitos intencionalmente para serem tão similares quanto
possível. Por exemplo, muitos esquemas de URL permitem que a autoridade tenha o seguinte
formato, chamada aqui de ip_server (colchetes mostram o que é opcional):
ip_server = [user [ : password ] @ ] host [ : port]
Este formato permite que você insira opcionalmente um nome de usuário, um usuário mais
senha, e/ou um número de porta. O host é o nome de um computador-host, ou seu nome, como
determinado pelo DNS ou um endereço IP (números separados por pontos). Portanto, a URI
<http://fred:fredpassword@xyz.com:8080/> loga em um servidor Web no host xyz.com como fred
(usando a senha fredpassword) usando a porta 8080. Evite incluir uma senha em uma URI se
possível, por causa dos muitos riscos de segurança por ter-se uma senha escrita. Se a URL
fornece um nome de usuário mas nenhuma senha, e o servidor remoto pede uma senha, o
programa interpretador da URL deve requerer uma do usuário.
Aqui estão alguns dos esquemas mais comuns em uso em sistemas tipo Unix, que são
entendidos por muitas ferramentas. Note que muitas ferramentas usando URIs também têm
esquemas internos ou especializados; veja a documentação dessas ferramentas para
informações sobre esses esquemas.
http - servidor Web (HTTP)
http://ip_server/path
http://ip_server/path?query
Esta é uma URL acessando um servidor web (HTTP). A porta padrão é 80. Se o caminho se
refere a um diretório, o servidor Web escolherá qual retorna; geralmente, se há um arquivo
denominado "index.html" ou "index.htm", seu conteúdo é retornado, caso contrário, uma
lista de arquivos no diretório corrente (com links apropriados) é gerada e retornada. Um
exemplo é <http://lwn.net>.
Uma pesquisa pode ser dada no formato "isindex" arcaico, consistindo em uma palavra ou
frase, e não incluindo um sinal de igual. Uma pesquisa também pode ser no formato "GET",
mais longo, que tem uma ou mais entradas de pesquisa no formato chave=valor , separadas
pelo caractere "&". Note que chave pode ser repetida mais de uma vez, porém cabe ao
servidor web e seus programas aplicativos determinar se há algum significado para aquilo.
Há uma infeliz interação com HTML/XML/SGML e o formato de pesquisa GET; quando tais URIs
com mais de uma chave são embutidas em documentos SGML/XML (incluindo HTML), o "&" tem que
ser reescrito como "&". Note que nem todas as pesquisas usam este formato; formas
maiores podem ser muito longas para se armazenar como uma URI, de forma que eles usam um
mecanismo de interação diferente (chamado POST) que não inclui os dados na URI. Veja a
especificação do CGI (Common Gateway Interface) em <http://www.w3.org/CGI> para maiores
informações.
ftp - File Transfer Protocol (FTP)
ftp://ip_server/path
Esta é uma URL acessando um arquivo através de um protocolo de transferência de arquivo
(FTP). A porta padrão (para controle) é 21. Se nenhum nome de usuário é incluído, é
fornecido o nome de usuário "anonymous" (anônimo), e neste caso muitos clientes fornecem
como a senha o correio eletrônico do requerente. Um exemplo é
<ftp://ftp.is.co.za/rfc/rfc1808.txt>.
gopher - servidor Gopher
gopher://ip_server/gophertype selector
gopher://ip_server/gophertype selector%09search
gopher://ip_server/gophertype selector%09search%09gopher+_string
A porta padrão do gopher é 70. gophertype é um campo de caractere único que denota o tipo
Gopher do recurso ao qual a URL se refere. O caminho inteiro também pode ser vazio, caso
em que o delimitador "/" também é opcional e o padrão de gophertype é "1".
selector é a string do seletor do Gopher. No protocolo Gopher, as strings do seletor do
Gopher são uma sequência de octetos que podem conter quaisquer octetos, exceto o
hexadecimal 09 (HT do US-ASCII, ou tabulação), hexadecimal 0A (caractere LF do US-ASCII),
e 0D (caractere CR do US-ASCII).
mailto - endereço de email
mailto:email-address
Este é um endereço de e-mail, geralmente no formato name@hostname. Veja mailaddr(7) para
mais informações sobre o formato correto de um endereço de e-mail. Note que qualquer
caractere % deve ser reescrito como %25. Um exemplo é <mailto:dwheeler@ida.org>.
news - Newsgroup ou mensagem de notícias
news:newsgroup-name
news:message-id
A newsgroup-name é um nome delimitado por pontos, tal como "comp.infosystems.www.misc".
Se <newsgroup-name> é "*" (como em <news:*>), ele é usado para se referir a "todos os
grupos de notícias disponíveis". Um exemplo é <news:comp.lang.ada>.
Um message-id corresponde ao ID de mensagem do IETF RFC 1036,
⟨http://www.ietf.org/rfc/rfc1036.txt⟩ sem os contornantes "<" e ">"; ele toma a forma
unique@full_domain_name. Um identificador de mensagem pode ser distinguido de um nome de
grupo de notícias pela presença do caractere "@".
telnet - Telnet login
telnet://ip_server/
O esquema de URL Telnet é usado para designar serviços de texto interativos que podem ser
acessados pelo protocolo Telnet. O caractere final "/" pode ser omitido. A porta padrão é
23. Um exemplo é <telnet://melvyl.ucop.edu/>.
file - arquivo normal
file://ip_server/path_segments
file:path_segments
Este representa um arquivo ou diretório acessível localmente. Como um caso especial, host
pode ser a string "localhost" ou uma string vazia; isto é interpretado como 'a máquina da
qual a URL está sendo interpretada'. Se o caminho é para um diretório, o visualizador
deve mostrar o conteúdo do diretório com links para cada item; nem todos os visualizadores
fazem isso. O KDE suporta arquivos gerados através da URL <file:/cgi-bin>. Se o arquivo
dado não é encontrado, os escritores do browser podem querer tentar expandir o nome do
arquivo através de um englobamento (veja glob(7) e glob(3)).
O segundo formato (por exemplo, <file:/etc/passwd>) é um formato correto para se referir
ao arquivo local. Porém, padrões mais antigos não permitiam este formato, e alguns
programas não reconhecem isto como uma URI. Uma sintaxe mais portável é o uso de uma
string vazia como o nome do servidor, por exemplo, <file:///etc/passwd>; este formato faz
a mesma coisa e é facilmente reconhecido como uma URI por buscadores de padrões e
programas mais antigos. Note que se você realmente quer dizer "comece do local corrente",
não especifique o esquema de jeito nenhum; use um endereço relativo, como <../test.txt>,
que tem o efeito colateral de ser independente de esquema. Um exemplo deste esquema é
<file:///etc/passwd>.
man - Documentação de páginas de manual
man:command-name
man:command-name(section)
Isto se refere às páginas de referência do manual (man) online local. O nome do comando
pode opcionalmente ser seguido por parênteses e pelo número da seção; veja man(7) para
mais informações sobre o significado dos números de seção. Este esquema de URI é único
para sistemas do tipo Unix (tais como o Linux) e não é registrado correntemente pelo IETF.
Um exemplo é <man:ls(1)>.
info - Documentação de páginas info
info:virtual-filename
info:virtual-filename#nodename
info:(virtual-filename)
info:(virtual-filename)nodename
Este esquema se refere às páginas de referência info online (geradas dos arquivos
texinfo), um formato de documentação usado por programas como as ferramentas GNU. Este
esquema de URI é exclusivo para sistemas do tipo Unix (tais como o Linux) e não é
registrado correntemente pelo IETF. No momento em que este é escrito, o GNOME e o KDE
diferem em suas sintaxes de URI, e não aceitam a sintaxe do outro. O primeiro dos dois
formatos são o formato GNOME; um nomes de nós todos os espaços são escritos como
sublinhados. O segundo dos dois formatos é o formato KDE; os espaços nos nomes de nós
devem ser escritos como espaços, mesmo isso sendo proibido pelos padrões da URI. Espera-
se que no futuro muitas ferramentas entenderão todos estes formatos e sempre aceitarão
sublinhados para espaços nos nomes dos nós. Tanto no GNOME quanto no KDE, se o formato
sem o nome do nó é usado, o nome do nó é assumido como sendo "Top". Exemplos de formato
GNOME são <info:gcc> e <info:gcc#G++_e_GCC>. Exemplos de formato KDE são <info:(gcc)> e
<info:(gcc)G++ e GCC>.
whatis - Busca de documentação
whatis:string
Este esquema busca no banco de dados de descrições curtas (de uma linha) de comandos e
retorna uma lista de descrições contendo aquela string. Somente encontros de palavras
completas são retornados. Veja whatis(1). Este esquema de URI é único para sistemas do
tipo Unix (tais como o Linux) e não é registrado correntemente pelo IETF.
ghelp - documentação de ajuda do GNOME
ghelp:nome-da-aplicação
Isto carrega a ajuda do GNOME para a aplicação dada. Note que não existe muita
documentação correntemente neste formato.
ldap - Lightweight Directory Access Protocol (Protocolo Leve de Acesso a Diretórios)
ldap://hostport
ldap://hostport/
ldap://hostport/dn
ldap://hostport/dn?attributos
ldap://hostport/dn?attributos?escopo
ldap://hostport/dn?atributos?escopo?filtro
ldap://hostport/dn?atributos?escopo?filtro?extensões
Este esquema suporta pesquisas no Protocolo Leve de Acesso a Diretórios (LDAP), um
protocolo para pesquisa de um conjunto de servidores para informações organizadas
hierarquicamente (tal como recursos pessoais e computacionais). Mais informações sobre o
esquema de URL do LDAP estão disponíveis em RFC 2255.
⟨http://www.ietf.org/rfc/rfc2255.txt⟩ Os componentes desta URL são:
hostport o servidor LDAP a se pesquisar, escrito como um nome de host, seguido
opcionalmente por dois-pontos e a número de porta. O padrão de porta LDAP é a
porta TCP 389. Se vazio, o cliente determina qual o servidor usar.
dn o Nome Distinto do LDAP, que identifica o objeto-base da busca LDAP (veja RFC
2253 ⟨http://www.ietf.org/rfc/rfc2253.txt⟩ seção 3).
atributos uma lista de atributos, separados por vírgulas, a serem retornados; veja a RFC
2251, seção 4.1.5. Se omitido, todos os atributos devem ser retornados.
scope especifica o escopo da busca, que pode ser uma da "base" (para uma busca de
objeto-base), "um" (para uma busca de um nível), ou "sub" (para uma busca em
sub-árvores). Se o escopo é omitido, "base" é assumido.
filtro especifica o filtro de busca (subconjunto de entradas a serem retornadas). Se
omitido, todas as entradas devem ser retornadas. Veja RFC 2254
⟨http://www.ietf.org/rfc/rfc2254.txt⟩ seção 4.
extensões uma lista, separada por vírgulas, de pares tipo=valor, onde a porção =valor
pode ser omitida para opções que não a requerem. Uma extensão prefixada com um
'!' é crítica (deve ser suportada para ser válida), caso contrário é não-
crítica (opcional).
Pesquisas LDAP são as mais fáceis de explicar com exemplos. Aqui está uma pesquisa que
pede ao ldap.itd.umich.edu informações sobre a Universidade de Michigan, nos E.U.A.:
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US
Para obter apenas seu atributo de endereço postal, peça:
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress
Para pedir a um host.com porta 6666 por informações sobre a pessoa com nome comum (cn)
"Babs Jensen" na Universidade de Michigan, peça:
ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)
wais - Servidores de Informação de Grande Área (Wide Area Information Server)
wais://hostport/database
wais://hostport/database?search
wais://hostport/database/wtype/wpath
Este esquema designa um banco de dados WAIS, uma busca, ou um documento (veja IETF RFC
1625 ⟨http://www.ietf.org/rfc/rfc1625.txt⟩ para mais informações sobre WAIS). Hostport é
o nome do host, opcionalmente seguido por dois-pontos e um número de porta (o número de
porta padrão é 210).
O primeiro formato designa um banco de dados WAIS para busca. O segundo formato desgina
uma busca particular do banco de dados WAIS database. O terceiro formato desgina um
documento particular dentro de um banco de dados WAIS a ser recuperado. wtype é a
desginação WAIS do tipo de objeto e wpath é o identificador de documento WAIS.
outros esquemas
Há muitos outros esquemas URI. Muitas ferramentas que aceitam URIs suportam um conjunto
de URIs internos (por exemplo, o Mozilla tem o esquema "about:" para informação interna, e
o browser de ajuda do GNOME tem o esquema "toc:" para vários locais de início). Há muitos
esquemas que foram definidos mas não são usados largamente na atualidade (por exemplo,
prospero). O esquema "nntp:" se tornou obsoleto em favor do esquema "news:". As URNs
devem ser suportadas pelo esquema "urn:", com um espaço de nomes hierárquico (por exemplo,
urn:ietf:... identificaria documentos IETF); atualmente as URNs não são implementadas
largamente. Nem todas as ferramentas suportam todos os esquemas.
CODIFICAÇÃO DOS CARACTERES
As URIs têm um número limitado de caracteres, de forma que elas podem ser digitadas e
usadas em uma variedade de situações.
Os seguintes caracteres são reservados, isto é, eles podem aparecer em uma URI mas seu uso
se limita ao seu propósito reservado (dados conflitantes precisam usar o caractere de
escape antes de formar a URI):
; / ? : @ & = + $ ,
Caracteres não-reservados podem ser incluídos em uma URI. Caracteres não-reservados
incluem letras latinas maiúsculas e minúsculas, dígitos decimais, e o seguinte conjunto
limitado de caracteres de pontuação e símbolos:
- _ . ! ~ * ' ( )
Todos os outros caracteres devem ter o caractere de escape. Um octeto com escape é
codificado como um trio de caracteres, consistindo de um caractere de porcentagem "%"
seguido por dois dígitos hexadecimais representando o código do octeto (você pode usar
letras maiúsculas e minúsculas para dígitos hexadecimais). Por exemplo, um espaço em
branco precisa ter o escape "%20", um caractere de tabulação é "%09", e o "&" é "%26".
Como o caractere de porcentagem "%" sempre tem o propósito reservado de ser o indicador de
escape, ele deve ter o escape "%25". É prática comum usar como escape para o espaço em
branco um sinal de mais (+) em textos de pesquisa; esta prática não é definida
uniformemente nas RFCs relevantes (que recomendam %20 em seu lugar), mas qualquer
ferramenta que aceita URIs com textos de pesquisa devem estar preparadas para isto. Uma
URI sempre é mostrada na sua forma "escapada".
Caracteres não-reservados podem ser escapados sem mudança da semântica da URI, mas isto
não deve ser feito a menos que o URI esteja sendo usada em um contexto que não permita que
apareçam caracteres sem escape. Por exemplo, "%7e" é usado às vezes em lugar de "~" em um
caminho de diretório de URL do http, mas os dois são equivalentes.
No momento em que este é escrito, não há nenhum padrão sobre como manipular caracteres
não-ASCII em URIs arbitrárias. A especificação HTML 4.0, seção B.2, recomenda o seguinte,
que deve ser considerado a melhor opção atualmente disponível:
1. Representa cada caractere não-ASCII em UTF-8.
2. O escape daqueles bytes com o mecanismo de escape de URIs, isto é, a conversão de cada
byte para %HH, onde HH é a notação hexadecimal do valor do byte.
ESCREVENDO UMA URI
Quando escritas, as URIs devem ser colocadas dentro de aspas (por exemplo,
"http://www.kernelnotes.org"), englobadas por sinais de "maior que" e "menor que" (por
exemplo, <http://lwn.net>), ou colocadas em uma linha separada. Um alerta para aqueles
que usam aspas: nunca mova a pontuação externa (tais como um ponto final terminando a
sentença ou uma vírgula em uma lista) dentro de uma URI, pois isto mudará o valor da URI.
Em vez disso, use sinais de "maior que" e "menor que", ou acione um sistema de aspas que
nunca inclua caracteres externos dentro das aspas. Este sistema antigo, chamado de
sistema de aspas 'novo' ou 'lógico' pelas "Regras de Hart" e pelo "Dicionário Oxford para
Escritores e Editores", é a prática preferida na Grã-Bretanha e por hackers em todo o
mundo (veja a seção do arquivo de jargões sobre Estilo de Escrita Hacker
⟨http://www.fwi.uva.nl/~mes/jargon/h/HackerWritingStyle.html⟩ para mais informações).
Outros documentos sugerem a inserção do prefixo "URL:" no início da URI, mas esta forma
nunca foi abraçada.
A sintaxe de URI foi projetada para não ser ambígua. Porém, como as URIs se tornaram
comuns, a mídia tradicional (televisão, rádio, jornais, revistas, etc.) tem usado cada vez
mais referências de URIs abreviadas, consistindo somente nas porções da autoridade e do
caminho do recurso identificado (por exemplo, <www.w3.org/Addressing>). Tais referências
pretendem primariamente facilitar a interpretação humana em lugar da máquina, assumindo
que a heurística baseada em contexto é suficiente para completar a URI (por exemplo, nomes
de hosts que começam com "www" deveriam ter um prefixo de URI igual a "http://", e nomes
de hosts começando com "ftp" deveriam ter o prefixo "ftp://"). Muitas implementações de
clientes resolvem heuristicamente estas referências. Tais heurísticas podem mudar com o
tempo, particularmente quando novos esquemas forem introduzidos. Como URIs abreviadas têm
a mesma sintaxe que um caminho de URL relativo, referências a URIs abreviadas não podem
ser usadas onde URIs relativas são permitidas, e só podem ser usadas quando não há base
definida (como em caixas de diálogo). Não use URIs abreviadas como links de hipertexto
dentro de um documento; use o formato padrão descrito acima.
NOTAS
Qualquer ferramenta que aceite URIs (por exemplo, um browser) em um sistema Linux deve ser
capaz de manipular (diretamente ou indiretamente) todos os esquemas descritos aqui,
incluindo os esquemas "man:" e "info:". A manipulação deles pela invocação de algum outro
programa é bom e de fato encorajado.
Tecnicamente, o fragmento não é parte da URI.
Para informações sobre como embutir URIs (incluindo URLs) em um formato de dados, veja a
documentação naquele formato. O HTML usa o formato <AHREF="uri"> texto </A>. Arquivos do
texinfo usam o formato @uref{uri}. Man e mdoc têm a macro UR recém-adicionada, ou apenas
incluem a URI no texto (visualizadores devem ser capazes de detectar :// como parte de uma
URI).
Os ambientes de desktop GNOME e KDE variam atualmente sobre as URIs que eles aceitam, em
particular nos seus respectivos browsers de ajuda. Para listar páginas de manual, o GNOME
usa <toc:man> enquanto o KDE usa <man:(índice)>, e para listar páginas "info", o GNOME usa
<toc:info> enquanto o KDE usa <info:(dir)> (o autor desta página de manual prefere a
aproximação do KDE aqui, mas um formato mais regular seria realmente melhor). Em geral, o
KDE usa <file:/cgi-bin/> como um prefixo para um conjunto de arquivos gerados. O KDE
prefere documentação em HTML, acessada via <file:/cgi-bin/helpindex>. O GNOME prefere o
esquema ghelp para armazenar e procurar documentação. Nenhum browser manipula referências
"file:" a diretórios no momento em que este texto foi escrito, tornando-se difícil
referir-se a um diretório completo com um URI compatível com um browser. Como se nota
acima, esses ambientes diferem na forma como manipulam o esquema "info:", provavelmente a
variação mais importante. Espera-se que o GNOME e o KDE irão convergir para formatos URI
comuns, e uma futura versão desta página de manual descreverá o resultado convergido.
Esforços para ajudar nessa convergência são encorajados.
SEGURANÇA
Uma URI não posa, por si mesma, com uma ameaça à segurança. Não há uma garantia geral de
que uma URL, localizada em certo momento em um recurso dado, continuará ali. Nem há
qualquer garantia de que uma URL não localizará um recurso diferente em algum lugar do
passado; tal garantia só pode ser obtida da(s) pessoa(s) que controlam aquele espaço de
nomes e o recurso em questão.
Algumas vezes é possível construir uma URL de forma que uma tentativa de realizar uma
operação aparentemente inofensiva, como a recuperação de uma entidade associada ao
recurso, provoque a ocorrência de uma operação remota possivelmente danosa. A URL insegura
é construída tipicamente através da especificação de um número de porta diferente daquela
reservada para o protocolo de rede em questão. O cliente inconscientemente contacta um
site que está, na verdade, rodando um protocolo diferente. O conteúdo da URL contém
instruções que, quando interpretada de acordo com este outro protocolo, causa uma operação
inesperada. Um exemplo foi o uso de uma URL gopher para produzir uma mensagem não
pretendida ou sem identificação, que fosse enviada através de um servidor SMTP.
Deve-se tomar cuidado no uso de qualquer URL que especifique um número de porta diferente
do padrão para o protocolo, especialmente quando é um número do espaço reservado.
Deve-se tomar cuidado para que, quando uma URI contenha delimitadores com caracteres de
escape para um dado protocolo (por exemplo, caracteres CR e LF para protocolos telnet),
esses não percam os escapes antes da transmissão. Isto pode violar o protocolo, mas evita
o possibilidade de que esses caracteres sejam usados para simular uma operação extra ou
parâmetros naquele protocolo, o que pode fazer uma operação inesperada e possivelmente
perigosa ser realizada.
É claramente uma tolice usar uma URI que contém uma senha, que pretende-se que seja
secreta. Em particular, o uso de uma senha dentro do componente 'userinfo' de uma URI é
fortemente não recomendada, exceto naqueles casos raros em que o parâmetro 'senha'
pretende ser pública.
DE ACORDO COM
IETF RFC 2396, ⟨http://www.ietf.org/rfc/rfc2396.txt⟩ HTML 4.0. ⟨http://www.w3.org/TR/REC-
html40⟩
PROBLEMAS
A documentação pode ser colocada em uma variedade de locais, tal que não há atualmente um
bom esquema URI para documentação online geral em formatos arbitrários. Referências no
formato <file:///usr/doc/ZZZ> não funcionam porque distribuições diferentes e requisitos
de instalação local podem colocar os arquivos em diretórios diferentes (pode ser em
/usr/doc, /usr/local/doc, /usr/share, ou em qualquer outro lugar). Também, o diretório
ZZZ geralmente muda quando uma versão muda (apesar de que o englobamento do nome do
arquivo poderia cobrir isso). Finalmente, o uso do esquema "file:" não dá suporte
facilmente às pessoas que carregam documentação dinamicamente da Internet (em vez de
carregar os arquivos para um sistema de arquivos local). Um esquema URI futuro pode ser
acrescentado (por exemplo, "userdoc:") para permitir que programas incluam referências
cruzadas a uma documentação mais detalhada, sem ter que saber o local exato daquela
documentação. Alternativamene, uma versão futura da especificação de sistema de arquivo
pode especificar locais de arquivos suficientemente, de forma que o esquema "file:" será
capaz de localizar documentação.
Muitos programas e formatos de arquivos não incluem um meio de incorporar ou implementar
links usando URIs.
Muitos programas não conseguem manipular todos esses diferentes formatos de URIs; deveria
haver um mecanismo padrão para carregar uma URI arbitrária que detectasse automaticamente
o ambiente do usuário (por exemplo, texto ou gráfico, ambiente de desktop, preferências do
usuário local, e ferramentas em execução atualmente) e invocasse a ferramenta correta para
qualquer URI.
AUTOR
David A. Wheeler (dwheeler@ida.org) escreveu esta página de manual.
VEJA TAMBÉM
lynx(1), mailaddr(7), utf-8(7), man2html(1), IETF RFC 2255.
⟨http://www.ietf.org/rfc/rfc2255.txt⟩
TRADUZIDO POR LDP-BR em 21/08/2000.
Rubens de Jesus Nogueira <darkseid99@usa.net> (tradução) André L. Fassone Canova
<lonelywolf@blv.com.br> (revisão)