Provided by: manpages-pt_20040726-4_all bug

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  "&amp;".   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,  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-aplicao

       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?extenses

       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.  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 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 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 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 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, HTML 4.0.

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.

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)