oracular (7) urn.7.gz

Provided by: manpages-pt-br_4.23.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 .RB " : " ( 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 ]

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)  translate the character sequences into UTF-8 (IETF RFC 3629)—see utf-8(7)—and then

       (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⟩.