Provided by: manpages-pt-br_4.18.1-1_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 cadeia 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 (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 "http://www.kernel.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 do contexto atual. Dentro de uma referência de  caminho
       relativo,  os  segmentos  completos  de caminhos '.' e '..' têm significados especiais: 'o
       nível de hierarquia atual' 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 atual.

   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]

       This  format  allows  you  to optionally insert a username, a user plus password, and/or a
       port number.  The host is the name of the host computer, either its name as determined  by
       DNS    or    an   IP   address   (numbers   separated   by   periods).    Thus   the   URI
       <http://fred:fredpassword@example.com:8080/> logs into a web server on host example.com as
       fred  (using  fredpassword)  using  port  8080.   Avoid  including  a password in a URI if
       possible because of the many security risks of having a password written down.  If the URL
       supplies  a  username  but  no  password,  and  the remote server requests a password, the
       program interpreting the URL should request one from the user.

       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 atual (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 é o seletor do Gopher. No protocolo Gopher, os seletores  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.  Vejamailaddr(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,
       ip_server pode ser 'localhost' ou vazio; 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
       cadeia 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 'inicie do local atual', 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 atualmente 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 atualmente 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 atualmente 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 atualmente neste formato.

       ldap - Lightweight Directory Access Protocol (Protocolo Leve de Acesso a Diretórios)

       ldap://hostport
       ldap://hostport/
       ldap://hostport/dn
       ldap://hostport/dn?atributos
       ldap://hostport/dn?atributos?escopo
       ldap://hostport/dn?atributos?escopo?filtro
       ldap://hostport/dn?atributos?escopo?filtro?extensões

       This scheme supports queries to  the  Lightweight  Directory  Access  Protocol  (LDAP),  a
       protocol  for  querying a set of servers for hierarchically organized information (such as
       people and computing resources).  See RFC 2255  ⟨http://www.ietf.org/rfc/rfc2255.txt⟩  for
       more information on the LDAP URL scheme.  The components of this URL are:

       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.

       escopo 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  amplamente
       implementadas. Nem todas as ferramentas suportam todos os esquemas.

   Character encoding
       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
       'fuga' antes de formar a URI):

                  ; / ? : @ & = + $ ,

       Unreserved characters may be included in a URI.  Unreserved characters  include  uppercase
       and  lowercase Latin letters, decimal digits, and the following limited set of punctuation
       marks and symbols:

                  - _ . ! ~ * ' ( )

       All other characters must be escaped.  An escaped octet is encoded as a character triplet,
       consisting   of  the  percent  character  "%"  followed  by  the  two  hexadecimal  digits
       representing the  octet  code  (you  can  use  uppercase  or  lowercase  letters  for  the
       hexadecimal digits).  For example, a blank space must be escaped as "%20", a tab character
       as "%09", and the "&" as "%26".  Because the percent "%" character always has the reserved
       purpose of being the escape indicator, it must be escaped as "%25".  It is common practice
       to escape space characters as the plus symbol (+)  in  query  text;  this  practice  isn't
       uniformly  defined  in  the  relevant  RFCs  (which  recommend  %20  instead) but any tool
       accepting URIs with query text should be prepared for them.  A URI is always shown in  its
       "escaped" form.

       Caracteres não-reservados podem ser do tipo de 'fuga' 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 'fuga'. 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.

       For URIs which must handle characters outside the US ASCII character set,  the  HTML  4.01
       specification  (section  B.2) and IETF RFC 3986 (last paragraph of section 2.5)  recommend
       the following approach:

       (1)  traduzir a seqüencia de caracteres em UTF-8 (IETF RFC 3629)—veja utf-8(7)—e então

       (2)  use o mecanismo de 'fuga', que é, use a codificação %HH para os octetos 'inseguros'.

   Writing a URI
       When written, URIs should be placed inside double quotes (e.g.,  "http://www.kernel.org"),
       enclosed in angle brackets (e.g., <http://lwn.net>), or placed on a line by themselves.  A
       warning for those who use double-quotes: never move extraneous punctuation  (such  as  the
       period ending a sentence or the comma in a list)  inside a URI, since this will change the
       value of the URI.  Instead, use angle brackets instead, or switch to a quoting system that
       never  includes  extraneous characters inside quotation marks.  This latter system, called
       the 'new' or 'logical' quoting system by "Hart's Rules" and  the  "Oxford  Dictionary  for
       Writers  and  Editors",  is  preferred  practice  in Great Britain and in various European
       languages.  Older documents suggested inserting the prefix "URL:" just before the URI, but
       this form has never caught on.

       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.

PADRÕES

       (IETF RFC 2396) ⟨http://www.ietf.org/rfc/rfc2396.txt⟩,  (HTML  4.0)  ⟨http://www.w3.org/TR
       /REC-html40⟩.

NOTAS

       Qualquer  ferramenta  que aceite URIs (por exemplo, um navegador) 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 navegador. 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.

   Security
       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
       'fuga'  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.

BUGS

       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
       ligações 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.

VEJA TAMBÉM

       lynx(1), man2html(1), mailaddr(7), utf-8(7)

       IETF RFC 2255 ⟨http://www.ietf.org/rfc/rfc2255.txt

TRADUÇÃO

       A tradução para português brasileiro desta página man  foi  criada  por  Rubens  de  Jesus
       Nogueira <darkseid99@usa.net> e André Luiz Fassone <lonely_wolf@ig.com.br>

       Esta  tradução  é  uma  documentação  livre;  leia  a  Licença  Pública Geral GNU Versão 3
       ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ ou posterior para  as  condições  de  direitos
       autorais.  Nenhuma responsabilidade é aceita.

       Se  você  encontrar  algum erro na tradução desta página de manual, envie um e-mail para a
       lista de discussão de tradutores ⟨debian-l10n-portuguese@lists.debian.org⟩.