NOME

uri, url, urn - identificador uniforme de recursos (URI), incluindo uma URL ou URN

SINOPSE

URI = [ absoluteURI | relativeURI ] [ "#" fragment ]

absoluteURI = scheme ":" ( hierarchical_part | opaque_part )

relativeURI = ( net_path | absolute_path | relative_path ) [ "?" query ]

scheme = "http" | "ftp" | "gopher" | "mailto" | "news" | "telnet" | "file" | "man" | "info" | "whatis" | "ldap" | "wais" | ...

hierarchical_part = ( net_path | absolute_path ) [ "?" query ]

net_path = "//" authority [ absolute_path ]

absolute_path = "/"  path_segments

relative_path = relative_segment [ absolute_path ]

DESCRIÇÃO

Um Identificador Uniforme de Recursos (Uniform Resource Identifier - URI) é uma string de caracteres curta que identifica um recurso abstrato ou físico (por exemplo, uma página da Web). Um Localizador Uniforme de Recursos (Uniform Resource Locator - URL) é uma URI que identifica um recurso através do seu mecanismo de acesso primário (por exemplo, sua "localização" de rede), em vez do nome ou algum outro atributo daquele recurso. Um Nome Uniforme de Recurso (Uniform Resource Name - URN) é uma URI que precisa manter-se única e persistente globalmente, mesmo quando o recurso deixa de existir ou se torna indisponível.

As URIs são o meio padrão de nomear destinos de links de hipertexto para ferramentas como os web browsers. A string "http://www.kernelnotes.org" é uma URL (e portanto é uma URI). Muitas pessoas usam o termo URL largamente como um sinônimo de URI (apesar de que, tecnicamente, as URLs formam um subconjunto das URIs).

As URIs podem ser absolutas ou relativas. Um identificador absoluto refere-se a um recurso independente de contexto, enquanto um identificador relativo refere-se a um recurso através da descrição de diferenças de um contexto corrente. Dentro de uma referência de caminho relativo, os segmentos completos de caminhos "." e ".." têm significados especiais: "o nível de hierarquia corrente" e "o nível acima deste nível de hierarquia", respectivamente, exatamente como são nos sistemas do tipo Unix. Um segmento de caminho que contém um caractere de dois-pontos não pode ser usado como o primeiro segmento de um caminho relativo de uma URI (por exemplo, "isto:aquilo"), porque ele poderia ser enganado por um nome de esquema; preceda tal segmento com ./ (por exemplo, "./isto:aquilo"). Note que os descendentes do MS-DOS (por exemplo, o Microsoft Windows) substituem os dois-pontos do nome do dispositivo por uma barra vertical("|") em URIs, de forma que "C:" se torna "C|".

Um identificador de fragmento, se incluído, refere-se a uma porção particular nomeada (fragmento) de um recurso; textos depois de um '#' identificam o fragmento. Uma URI começando com '#' refere-se a aquele fragmento no recurso corrente.

USO

Há muitos esquemas de URIs diferentes, cada um com regras e significados adicionais específicos, mas eles são feitos intencionalmente para serem tão similares quanto possível. Por exemplo, muitos esquemas de URL permitem que a autoridade tenha o seguinte formato, chamada aqui de ip_server (colchetes mostram o que é opcional):

ip_server = [user [ : password ] @ ] host [ : port]

Este formato permite que você insira opcionalmente um nome de usuário, um usuário mais senha, e/ou um número de porta. O host é o nome de um computador-host, ou seu nome, como determinado pelo DNS ou um endereço IP (números separados por pontos). Portanto, a URI <http://fred:fredpassword@xyz.com:8080/> loga em um servidor Web no host xyz.com como fred (usando a senha fredpassword) usando a porta 8080. Evite incluir uma senha em uma URI se possível, por causa dos muitos riscos de segurança por ter-se uma senha escrita. Se a URL fornece um nome de usuário mas nenhuma senha, e o servidor remoto pede uma senha, o programa interpretador da URL deve requerer uma do usuário.

Aqui estão alguns dos esquemas mais comuns em uso em sistemas tipo Unix, que são entendidos por muitas ferramentas. Note que muitas ferramentas usando URIs também têm esquemas internos ou especializados; veja a documentação dessas ferramentas para informações sobre esses esquemas.

CODIFICAÇÃO DOS CARACTERES

As URIs têm um número limitado de caracteres, de forma que elas podem ser digitadas e usadas em uma variedade de situações.

Os seguintes caracteres são reservados, isto é, eles podem aparecer em uma URI mas seu uso se limita ao seu propósito reservado (dados conflitantes precisam usar o caractere de escape antes de formar a URI):

; / ? : @ & = + $ ,

Caracteres não-reservados podem ser incluídos em uma URI. Caracteres não-reservados incluem letras latinas maiúsculas e minúsculas, dígitos decimais, e o seguinte conjunto limitado de caracteres de pontuação e símbolos:

- _ . ! ~ * ' ( )

Todos os outros caracteres devem ter o caractere de escape. Um octeto com escape é codificado como um trio de caracteres, consistindo de um caractere de porcentagem "%" seguido por dois dígitos hexadecimais representando o código do octeto (você pode usar letras maiúsculas e minúsculas para dígitos hexadecimais). Por exemplo, um espaço em branco precisa ter o escape "%20", um caractere de tabulação é "%09", e o "&" é "%26". Como o caractere de porcentagem "%" sempre tem o propósito reservado de ser o indicador de escape, ele deve ter o escape "%25". É prática comum usar como escape para o espaço em branco um sinal de mais (+) em textos de pesquisa; esta prática não é definida uniformemente nas RFCs relevantes (que recomendam %20 em seu lugar), mas qualquer ferramenta que aceita URIs com textos de pesquisa devem estar preparadas para isto. Uma URI sempre é mostrada na sua forma "escapada".

Caracteres não-reservados podem ser escapados sem mudança da semântica da URI, mas isto não deve ser feito a menos que o URI esteja sendo usada em um contexto que não permita que apareçam caracteres sem escape. Por exemplo, "%7e" é usado às vezes em lugar de "~" em um caminho de diretório de URL do http, mas os dois são equivalentes.

No momento em que este é escrito, não há nenhum padrão sobre como manipular caracteres não-ASCII em URIs arbitrárias. A especificação HTML 4.0, seção B.2, recomenda o seguinte, que deve ser considerado a melhor opção atualmente disponível:

1.

Representa cada caractere não-ASCII em UTF-8.

2.

O escape daqueles bytes com o mecanismo de escape de URIs, isto é, a conversão de cada byte para %HH, onde HH é a notação hexadecimal do valor do byte.

ESCREVENDO UMA URI

Quando escritas, as URIs devem ser colocadas dentro de aspas (por exemplo, "http://www.kernelnotes.org"), englobadas por sinais de "maior que" e "menor que" (por exemplo, <http://lwn.net>), ou colocadas em uma linha separada. Um alerta para aqueles que usam aspas: nunca mova a pontuação externa (tais como um ponto final terminando a sentença ou uma vírgula em uma lista) dentro de uma URI, pois isto mudará o valor da URI. Em vez disso, use sinais de "maior que" e "menor que", ou acione um sistema de aspas que nunca inclua caracteres externos dentro das aspas. Este sistema antigo, chamado de sistema de aspas 'novo' ou 'lógico' pelas "Regras de Hart" e pelo "Dicionário Oxford para Escritores e Editores", é a prática preferida na Grã-Bretanha e por hackers em todo o mundo (veja a seção do arquivo de jargões sobre Estilo de Escrita Hacker para mais informações). Outros documentos sugerem a inserção do prefixo "URL:" no início da URI, mas esta forma nunca foi abraçada.

A sintaxe de URI foi projetada para não ser ambígua. Porém, como as URIs se tornaram comuns, a mídia tradicional (televisão, rádio, jornais, revistas, etc.) tem usado cada vez mais referências de URIs abreviadas, consistindo somente nas porções da autoridade e do caminho do recurso identificado (por exemplo, <www.w3.org/Addressing>). Tais referências pretendem primariamente facilitar a interpretação humana em lugar da máquina, assumindo que a heurística baseada em contexto é suficiente para completar a URI (por exemplo, nomes de hosts que começam com "www" deveriam ter um prefixo de URI igual a "http://", e nomes de hosts começando com "ftp" deveriam ter o prefixo "ftp://"). Muitas implementações de clientes resolvem heuristicamente estas referências. Tais heurísticas podem mudar com o tempo, particularmente quando novos esquemas forem introduzidos. Como URIs abreviadas têm a mesma sintaxe que um caminho de URL relativo, referências a URIs abreviadas não podem ser usadas onde URIs relativas são permitidas, e só podem ser usadas quando não há base definida (como em caixas de diálogo). Não use URIs abreviadas como links de hipertexto dentro de um documento; use o formato padrão descrito acima.

NOTAS

Qualquer ferramenta que aceite URIs (por exemplo, um browser) em um sistema Linux deve ser capaz de manipular (diretamente ou indiretamente) todos os esquemas descritos aqui, incluindo os esquemas "man:" e "info:". A manipulação deles pela invocação de algum outro programa é bom e de fato encorajado.

Tecnicamente, o fragmento não é parte da URI.

Para informações sobre como embutir URIs (incluindo URLs) em um formato de dados, veja a documentação naquele formato. O HTML usa o formato <AHREF="uri"> texto </A>. Arquivos do texinfo usam o formato @uref{uri}. Man e mdoc têm a macro UR recém-adicionada, ou apenas incluem a URI no texto (visualizadores devem ser capazes de detectar :// como parte de uma URI).

Os ambientes de desktop GNOME e KDE variam atualmente sobre as URIs que eles aceitam, em particular nos seus respectivos browsers de ajuda. Para listar páginas de manual, o GNOME usa <toc:man> enquanto o KDE usa <man:(índice)>, e para listar páginas "info", o GNOME usa <toc:info> enquanto o KDE usa <info:(dir)> (o autor desta página de manual prefere a aproximação do KDE aqui, mas um formato mais regular seria realmente melhor). Em geral, o KDE usa <file:/cgi-bin/> como um prefixo para um conjunto de arquivos gerados. O KDE prefere documentação em HTML, acessada via <file:/cgi-bin/helpindex>. O GNOME prefere o esquema ghelp para armazenar e procurar documentação. Nenhum browser manipula referências "file:" a diretórios no momento em que este texto foi escrito, tornando-se difícil referir-se a um diretório completo com um URI compatível com um browser. Como se nota acima, esses ambientes diferem na forma como manipulam o esquema "info:", provavelmente a variação mais importante. Espera-se que o GNOME e o KDE irão convergir para formatos URI comuns, e uma futura versão desta página de manual descreverá o resultado convergido. Esforços para ajudar nessa convergência são encorajados.

SEGURANÇA

Uma URI não posa, por si mesma, com uma ameaça à segurança. Não há uma garantia geral de que uma URL, localizada em certo momento em um recurso dado, continuará ali. Nem há qualquer garantia de que uma URL não localizará um recurso diferente em algum lugar do passado; tal garantia só pode ser obtida da(s) pessoa(s) que controlam aquele espaço de nomes e o recurso em questão.

Algumas vezes é possível construir uma URL de forma que uma tentativa de realizar uma operação aparentemente inofensiva, como a recuperação de uma entidade associada ao recurso, provoque a ocorrência de uma operação remota possivelmente danosa. A URL insegura é construída tipicamente através da especificação de um número de porta diferente daquela reservada para o protocolo de rede em questão. O cliente inconscientemente contacta um site que está, na verdade, rodando um protocolo diferente. O conteúdo da URL contém instruções que, quando interpretada de acordo com este outro protocolo, causa uma operação inesperada. Um exemplo foi o uso de uma URL gopher para produzir uma mensagem não pretendida ou sem identificação, que fosse enviada através de um servidor SMTP.

Deve-se tomar cuidado no uso de qualquer URL que especifique um número de porta diferente do padrão para o protocolo, especialmente quando é um número do espaço reservado.

Deve-se tomar cuidado para que, quando uma URI contenha delimitadores com caracteres de escape para um dado protocolo (por exemplo, caracteres CR e LF para protocolos telnet), esses não percam os escapes antes da transmissão. Isto pode violar o protocolo, mas evita o possibilidade de que esses caracteres sejam usados para simular uma operação extra ou parâmetros naquele protocolo, o que pode fazer uma operação inesperada e possivelmente perigosa ser realizada.

É claramente uma tolice usar uma URI que contém uma senha, que pretende-se que seja secreta. Em particular, o uso de uma senha dentro do componente 'userinfo' de uma URI é fortemente não recomendada, exceto naqueles casos raros em que o parâmetro 'senha' pretende ser pública.

DE ACORDO COM

IETF RFC 2396, HTML 4.0.

PROBLEMAS

A documentação pode ser colocada em uma variedade de locais, tal que não há atualmente um bom esquema URI para documentação online geral em formatos arbitrários. Referências no formato <file:///usr/doc/ZZZ> não funcionam porque distribuições diferentes e requisitos de instalação local podem colocar os arquivos em diretórios diferentes (pode ser em /usr/doc, /usr/local/doc, /usr/share, ou em qualquer outro lugar). Também, o diretório ZZZ geralmente muda quando uma versão muda (apesar de que o englobamento do nome do arquivo poderia cobrir isso). Finalmente, o uso do esquema "file:" não dá suporte facilmente às pessoas que carregam documentação dinamicamente da Internet (em vez de carregar os arquivos para um sistema de arquivos local). Um esquema URI futuro pode ser acrescentado (por exemplo, "userdoc:") para permitir que programas incluam referências cruzadas a uma documentação mais detalhada, sem ter que saber o local exato daquela documentação. Alternativamene, uma versão futura da especificação de sistema de arquivo pode especificar locais de arquivos suficientemente, de forma que o esquema "file:" será capaz de localizar documentação.

Muitos programas e formatos de arquivos não incluem um meio de incorporar ou implementar links usando URIs.

Muitos programas não conseguem manipular todos esses diferentes formatos de URIs; deveria haver um mecanismo padrão para carregar uma URI arbitrária que detectasse automaticamente o ambiente do usuário (por exemplo, texto ou gráfico, ambiente de desktop, preferências do usuário local, e ferramentas em execução atualmente) e invocasse a ferramenta correta para qualquer URI.

AUTOR

David A. Wheeler (dwheeler@ida.org) escreveu esta página de manual.

VEJA TAMBÉM

lynx(1), mailaddr(7), utf-8(7), man2html(1), IETF RFC 2255.

TRADUZIDO POR LDP-BR em 21/08/2000.

Rubens de Jesus Nogueira <darkseid99@usa.net> (tradução) André L. Fassone Canova <lonelywolf@blv.com.br> (revisão)