.\" -*- coding: UTF-8 -*-
.\" (C) Copyright 1999-2000 David A. Wheeler (dwheeler@dwheeler.com)
.\"
.\" SPDX-License-Identifier: Linux-man-pages-copyleft
.\"
.\" Fragments of this document are directly derived from IETF standards.
.\" For those fragments which are directly derived from such standards,
.\" the following notice applies, which is the standard copyright and
.\" rights announcement of The Internet Society:
.\"
.\" Copyright (C) The Internet Society (1998). All Rights Reserved.
.\" This document and translations of it may be copied and furnished to
.\" others, and derivative works that comment on or otherwise explain it
.\" or assist in its implementation may be prepared, copied, published
.\" and distributed, in whole or in part, without restriction of any
.\" kind, provided that the above copyright notice and this paragraph are
.\" included on all such copies and derivative works. However, this
.\" document itself may not be modified in any way, such as by removing
.\" the copyright notice or references to the Internet Society or other
.\" Internet organizations, except as needed for the purpose of
.\" developing Internet standards in which case the procedures for
.\" copyrights defined in the Internet Standards process must be
.\" followed, or as required to translate it into languages other than English.
.\"
.\" Modified Fri Jul 25 23:00:00 1999 by David A. Wheeler (dwheeler@dwheeler.com)
.\" Modified Fri Aug 21 23:00:00 1999 by David A. Wheeler (dwheeler@dwheeler.com)
.\" Modified Tue Mar 14 2000 by David A. Wheeler (dwheeler@dwheeler.com)
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH uri 7 "30 abril 2023" "Linux man\-pages 6.05.01"
.SH NOME
uri, url, urn \- identificador uniforme de recursos (URI), incluindo uma URL
ou URN
.SH SINOPSE
.SY "\fIURI\fP ="
[\~\fIabsoluteURI\fP | \fIrelativeURI\fP\~] [\~\[dq]\fB#\fP\[dq]\~ \fIfragment\fP\~]
.YS
.PP
.SY "\fIabsoluteURI\fP ="
\fIscheme\~\fP \[dq]\fB:\fP\[dq] (\~\fIhierarchical_part\fP | \fIopaque_part\fP\~)
.YS
.PP
.SY "\fIrelativeURI\fP ="
(\~\fInet_path\fP | \fIabsolute_path\fP | \fIrelative_path\fP\~) [\~\[dq]\fB?\fP\[dq]\~
\fIquery\fP\~]
.YS
.PP
.SY "\fIscheme\fP ="
\[dq]\fBhttp\fP\[dq] | \[dq]\fBftp\fP\[dq] | \[dq]\fBgopher\fP\[dq] |
\[dq]\fBmailto\fP\[dq] | \[dq]\fBnews\fP\[dq] | \[dq]\fBtelnet\fP\[dq] |
\[dq]\fBfile\fP\[dq] | \[dq]\fBftp\fP\[dq] | \[dq]\fBman\fP\[dq] | \[dq]\fBinfo\fP\[dq]
| \[dq]\fBwhatis\fP\[dq] | \[dq]\fBldap\fP\[dq] | \[dq]\fBwais\fP\[dq] | \&...
.YS
.PP
.SY "\fIhierarchical_part\fP ="
(\~\fInet_path\fP | \fIabsolute_path\fP\~) [\~\[dq]\fB?\fP\[dq]\~ \fIquery\fP\~]
.YS
.PP
.SY "\fInet_path\fP ="
\[dq]\fB//\fP\[dq]\~ \fIauthority\fP [\~\fIabsolute_path\fP\~]
.YS
.PP
.SY "\fIabsolute_path\fP ="
\[dq]\fB/\fP\[dq]\~ \fIpath_segments\fP
.YS
.PP
.SY "\fIrelative_path\fP ="
\fIrelative_segment\fP [\~\fIabsolute_path\fP\~]
.YS
.SH 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.
.PP
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).
.PP
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|'.
.PP
Um identificador de fragmento, se incluído, refere\-se a uma porção
particular nomeada (fragmento) de um recurso; textos depois de um
\[aq]#\[aq] identificam o fragmento. Uma URI começando com \[aq]#\[aq]
refere\-se a aquele fragmento no recurso atual.
.SS 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 \fIip_server\fP
(colchetes mostram o que é opcional):
.PP
\fIip_server = \fP[\fIuser\fP [ : \fIpassword\fP ] @ ] \fIhost\fP [ : \fIport\fP]
.PP
This format allows you to optionally insert a username, a user plus
password, and/or a port number. The \fIhost\fP 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
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.
.PP
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.
.PP
\fBhttp \- servidor Web (HTTP)\fP
.PP
http://\fIip_server\fP/\fIpath\fP
.br
http://\fIip_server\fP/\fIpath\fP?\fIquery\fP
.PP
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 é
.
.PP
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 \fIchave\fP=\fIvalor\fP, separadas pelo caractere (&). Note
que \fIchave\fP 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
.UR http://www.w3.org\:/CGI
.UE
para maiores informações.
.PP
\fBftp \- File Transfer Protocol (FTP)\fP
.PP
ftp://\fIip_server\fP/\fIpath\fP
.PP
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 é .
.PP
\fBgopher \- servidor Gopher\fP
.PP
gopher://\fIip_server\fP/\fIgophertype selector\fP
.br
gopher://\fIip_server\fP/\fIgophertype selector\fP%09\fIsearch\fP
.br
gopher://\fIip_server\fP/\fIgophertype selector\fP%09\fIsearch\fP%09\fIgopher+_string\fP
.br
.PP
A porta padrão do gopher é 70. \fIgophertype\fP é 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'.
.PP
\fIselector\fP é 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).
.PP
\fBmailto \- endereço de email\fP
.PP
mailto:\fIemail\-address\fP
.PP
Este é um endereço de e\-mail, geralmente no formato
\fIname\fP@\fIhostname\fP. Veja\fBmailaddr\fP(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 é .
.PP
\fBnews \- Newsgroup ou mensagem de notícias\fP
.PP
news:\fInewsgroup\-name\fP
.br
news:\fImessage\-id\fP
.PP
A \fInewsgroup\-name\fP é um nome delimitado por pontos, tal como
"comp.infosystems.www.misc". Se é '*' (como em
), ele é usado para se referir a 'todos os grupos de
notícias disponíveis'. Um exemplo é .
.PP
Um \fImessage\-id\fP corresponde ao ID de mensagem do
.UR http://www.ietf.org\:/rfc\:/rfc1036.txt
IETF RFC 1036,
.UE
sem os
contornantes '<' e '>'; ele toma a forma
\fIunique\fP@\fIfull_domain_name\fP. Um identificador de mensagem pode ser
distinguido de um nome de grupo de notícias pela presença do caractere '@'.
.PP
\fBtelnet \- Telnet login\fP
.PP
telnet://\fIip_server\fP/
.PP
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 é
.
.PP
\fBfile \- arquivo normal\fP
.PP
file://\fIip_server\fP/\fIpath_segments\fP
.br
file:\fIpath_segments\fP
.PP
Este representa um arquivo ou diretório acessível localmente. Como um caso
especial, \fIip_server\fP 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 . 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 \fBglob\fP(7) e \fBglob\fP(3)).
.PP
O segundo formato (por exemplo, ) é 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, ; 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 é
.
.PP
\fBman \- Documentação de páginas de manual\fP
.PP
man:\fIcommand\-name\fP
.br
man:\fIcommand\-name\fP(\fIsection\fP)
.PP
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 \fBman\fP(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 é
.
.PP
\fBinfo \- Documentação de páginas info\fP
.PP
info:\fIvirtual\-filename\fP
.br
info:\fIvirtual\-filename\fP#\fInodename\fP
.br
info:(\fIvirtual\-filename\fP)
.br
info:(\fIvirtual\-filename\fP)\fInodename\fP
.PP
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
e . Exemplos de formato KDE
são e .
.PP
\fBwhatis \- Busca de documentação\fP
.PP
whatis:\fIstring\fP
.PP
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 \fBwhatis\fP(1). Este
esquema de URI é único para sistemas do tipo UNIX (tais como o Linux) e não
é registrado atualmente pelo IETF.
.PP
\fBghelp \- documentação de ajuda do GNOME\fP
.PP
ghelp:\fInome\-da\-aplicação\fP
.PP
Isto carrega a ajuda do GNOME para a aplicação dada. Note que não existe
muita documentação atualmente neste formato.
.PP
\fBldap \- Lightweight Directory Access Protocol (Protocolo Leve de Acesso a Diretórios)\fP
.PP
ldap://\fIhostport\fP
.br
ldap://\fIhostport\fP/
.br
ldap://\fIhostport\fP/\fIdn\fP
.br
ldap://\fIhostport\fP/\fIdn\fP?\fIatributos\fP
.br
ldap://\fIhostport\fP/\fIdn\fP?\fIatributos\fP?\fIescopo\fP
.br
ldap://\fIhostport\fP/\fIdn\fP?\fIatributos\fP?\fIescopo\fP?\fIfiltro\fP
.br
ldap://\fIhostport\fP/\fIdn\fP?\fIatributos\fP?\fIescopo\fP?\fIfiltro\fP?\fIextensões\fP
.PP
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
.UR http://www.ietf.org\:/rfc\:/rfc2255.txt
RFC\ 2255
.UE
for more
information on the LDAP URL scheme. The components of this URL are:
.TP
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.
.TP
dn
o Nome Distinto do LDAP, que identifica o objeto\-base da busca LDAP (veja
.UR http://www.ietf.org\:/rfc\:/rfc2253.txt
RFC\ 2253
.UE
seção 3).
.TP
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.
.TP
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.
.TP
filtro
especifica o filtro de busca (subconjunto de entradas a serem
retornadas). Se omitido, todas as entradas devem ser retornadas. Veja
.UR http://www.ietf.org\:/rfc\:/rfc2254.txt
RFC\ 2254
.UE
seção 4.
.TP
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 \[aq]!\[aq] é crítica (deve ser suportada para ser válida), caso
contrário é não\-crítica (opcional).
.PP
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.:
.PP
.nf
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US
.fi
.PP
Para obter apenas seu atributo de endereço postal, peça:
.PP
.nf
ldap://ldap.itd.umich.edu/o=University%20of%20Michigan,c=US?postalAddress
.fi
.PP
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:
.PP
.nf
ldap://host.com:6666/o=University%20of%20Michigan,c=US??sub?(cn=Babs%20Jensen)
.fi
.PP
\fBwais \- Servidores de Informação de Grande Área (Wide Area Information Server)\fP
.PP
wais://\fIhostport\fP/\fIdatabase\fP
.br
wais://\fIhostport\fP/\fIdatabase\fP?\fIsearch\fP
.br
wais://\fIhostport\fP/\fIdatabase\fP/\fIwtype\fP/\fIwpath\fP
.PP
Este esquema designa um banco de dados WAIS, uma busca, ou um documento
(veja
.UR http://www.ietf.org\:/rfc\:/rfc1625.txt
IETF RFC\ 1625
.UE
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).
.PP
O primeiro formato designa um banco de dados WAIS para busca. O segundo
formato desgina uma busca particular do banco de dados WAIS \fIdatabase\fP. O
terceiro formato desgina um documento particular dentro de um banco de dados
WAIS a ser recuperado. \fIwtype\fP é a desginação WAIS do tipo de objeto e
\fIwpath\fP é o identificador de documento WAIS.
.PP
\fBoutros esquemas\fP
.PP
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.
.SS "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.
.PP
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):
.IP
.in +4n
.EX
; / ? : @ & = + $ ,
.EE
.in
.PP
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:
.IP
.in +4n
.EX
\- _ . ! \[ti] * ' ( )
.EE
.in
.PP
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.
.PP
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 '\[ti]' em um caminho de
diretório de URL do HTTP, mas os dois são equivalentes.
.PP
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:
.IP (1) 5
traduzir a seqüencia de caracteres em UTF\-8 (IETF RFC\~3629)\[em]veja
\fButf\-8\fP(7)\[em]e então
.IP (2)
use o mecanismo de 'fuga', que é, use a codificação %HH para os octetos
\&'inseguros'.
.SS "Writing a URI"
When written, URIs should be placed inside double quotes (e.g.,
"http://www.kernel.org"), enclosed in angle brackets (e.g.,
), or placed on a line by themselves. A warning for
those who use double\-quotes: \fBnever\fP 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.
.PP
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, ). 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.
.SH PADRÕES
.UR http://www.ietf.org\:/rfc\:/rfc2396.txt
(IETF RFC\ 2396)
.UE ,
.UR http://www.w3.org\:/TR\:/REC\-html40
(HTML 4.0)
.UE .
.SH 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.
.PP
Tecnicamente, o fragmento não é parte da URI.
.PP
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
\fItexto\fP . Arquivos do texinfo usam o
formato @uref{\fIuri\fP}. 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).
.PP
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 enquanto o KDE usa
, e para listar páginas 'info', o GNOME usa
enquanto o KDE usa (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
como um prefixo para um conjunto de arquivos
gerados. O KDE prefere documentação em HTML, acessada via
. 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.
.SS 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.
.PP
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.
.PP
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.
.PP
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.
.PP
É 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.
.SH 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 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.
.PP
Muitos programas e formatos de arquivos não incluem um meio de incorporar ou
implementar ligações usando URIs.
.PP
.\" .SH AUTHOR
.\" David A. Wheeler (dwheeler@dwheeler.com) wrote this man page.
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.
.SH "VEJA TAMBÉM"
\fBlynx\fP(1), \fBman2html\fP(1), \fBmailaddr\fP(7), \fButf\-8\fP(7)
.PP
.UR http://www.ietf.org\:/rfc\:/rfc2255.txt
IETF RFC\ 2255
.UE
.PP
.SH TRADUÇÃO
A tradução para português brasileiro desta página man foi criada por
Rubens de Jesus Nogueira
e
André Luiz Fassone
.
.PP
Esta tradução é uma documentação livre; leia a
.UR https://www.gnu.org/licenses/gpl-3.0.html
Licença Pública Geral GNU Versão 3
.UE
ou posterior para as condições de direitos autorais.
Nenhuma responsabilidade é aceita.
.PP
Se você encontrar algum erro na tradução desta página de manual,
envie um e-mail para
.MT debian-l10n-portuguese@lists.debian.org
a lista de discussão de tradutores
.ME .