Provided by: manpages-pt-br_4.21.0-2_all 
NOME
uri, url, urn - identificador uniforme de recursos (URI), incluindo uma URL ou URN
SINOPSE
URI = [ absoluteURI | relativeURI ] [ "#" fragment ]
absoluteURI = scheme ":" ( hierarchical_part | opaque_part )
relativeURI = ( net_path | absolute_path | relative_path ) [ "?" query ]
scheme = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" |
"file" | "man" | "info" | "whatis" | "ldap" | "wais" | ...
hierarchical_part = ( net_path | absolute_path ) [ "?" query ]
net_path = "//" authority [ absolute_path ]
absolute_path = "/" path_segments
relative_path = relative_segment [ absolute_path ]
DESCRIÇÃO
Um Identificador Uniforme de Recursos (Uniform Resource Identifier - URI) é uma 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 '&'. 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, 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 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 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 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 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), (HTML 4.0).
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
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 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.
Linux man-pages 6.03 5 fevereiro 2023 uri(7)