Codificação percentual - Percent-encoding
A codificação percentual , também conhecida como codificação de URL , é um método para codificar dados arbitrários em um URI ( Uniform Resource Identifier ) usando apenas os caracteres US-ASCII limitados que são permitidos em um URI. Embora seja conhecido como codificação de URL, também é usado de forma mais geral no conjunto principal de Uniform Resource Identifier (URI), que inclui o Uniform Resource Locator (URL) e o Uniform Resource Name (URN). Como tal, ele também é usado na preparação de dados do application/x-www-form-urlencoded
tipo de mídia , como é frequentemente usado no envio de dados de formulário HTML em solicitações HTTP .
Codificação percentual em um URI
Tipos de caracteres URI
Os caracteres permitidos em um URI são reservados ou não reservados (ou um caractere de porcentagem como parte de uma codificação de porcentagem). Os caracteres reservados são aqueles que às vezes têm um significado especial. Por exemplo, caracteres de barra são usados para separar diferentes partes de um URL (ou mais geralmente, um URI). Os caracteres não reservados não têm tais significados. Usando a codificação de porcentagem, os caracteres reservados são representados por meio de sequências de caracteres especiais. Os conjuntos de caracteres reservados e não reservados e as circunstâncias sob as quais certos caracteres reservados têm significado especial mudaram ligeiramente com cada revisão das especificações que governam URIs e esquemas de URI.
! |
# |
$ |
& |
' |
( |
) |
* |
+ |
, |
/ |
: |
; |
= |
? |
@ |
[ |
]
|
A |
B |
C |
D |
E |
F |
G |
H |
I |
J |
K |
L |
M |
N |
O |
P |
Q |
R |
S |
T |
U |
V |
W |
X |
Y |
Z
|
|
a |
b |
c |
d |
e |
f |
g |
h |
i |
j |
k |
l |
m |
n |
o |
p |
q |
r |
s |
t |
u |
v |
w |
x |
y |
z
|
|
0 |
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9
|
- |
_ |
. |
~ |
Outros caracteres em um URI devem ser codificados em porcentagem.
Caracteres reservados
Quando um caractere do conjunto reservado (um "caractere reservado") tem um significado especial (um "propósito reservado") em um determinado contexto, e um esquema de URI diz que é necessário usar esse caractere para algum outro propósito, então o caractere deve ser codificado em porcentagem . A codificação percentual de um caractere reservado envolve a conversão do caractere em seu valor de byte correspondente em ASCII e a representação desse valor como um par de dígitos hexadecimais . Os dígitos, precedidos por um sinal de porcentagem ( %
) que é usado como um caractere de escape , são então usados no URI no lugar do caractere reservado. (Para um caractere não ASCII, ele é normalmente convertido em sua sequência de bytes em UTF-8 e, em seguida, cada valor de byte é representado como acima.)
O caractere reservado /
, por exemplo, se usado no componente "caminho" de um URI , tem o significado especial de ser um delimitador entre segmentos de caminho. Se, de acordo com um determinado esquema de URI, /
precisa estar em um segmento de caminho, então os três caracteres %2F
ou %2f
devem ser usados no segmento em vez de um bruto /
.
! |
# |
$ |
% |
& |
' |
( |
) |
* |
+ |
, |
/ |
: |
; |
= |
? |
@ |
[ |
]
|
%21 |
%23 |
%24 |
%25 |
%26 |
%27 |
%28 |
%29 |
%2A |
%2B |
%2C |
%2F |
%3A |
%3B |
%3D |
%3F |
%40 |
%5B |
%5D
|
Os caracteres reservados que não têm finalidade reservada em um determinado contexto também podem ser codificados por porcentagem, mas não são semanticamente diferentes daqueles que não o são.
No componente " consulta " de um URI (a parte após um caractere?), Por exemplo, /
ainda é considerado um caractere reservado, mas normalmente não tem propósito reservado, a menos que um determinado esquema de URI diga o contrário. O caractere não precisa ser codificado em porcentagem quando não tem um propósito reservado.
URIs que diferem apenas pelo fato de um caractere reservado ser codificado por porcentagem ou aparecer literalmente são normalmente considerados não equivalentes (denotando o mesmo recurso), a menos que possa ser determinado que os caracteres reservados em questão não têm propósito reservado. Essa determinação depende das regras estabelecidas para caracteres reservados por esquemas de URI individuais.
Carateres não reservados
Os caracteres do conjunto não reservado nunca precisam ser codificados por cento.
URIs que diferem apenas pelo fato de um caractere não reservado ser codificado por porcentagem ou aparecer literalmente são equivalentes por definição, mas os processadores de URI, na prática, podem nem sempre reconhecer essa equivalência. Por exemplo, os consumidores de URI não devem tratar de maneira %41
diferente A
ou %7E
diferente de ~
, mas alguns o fazem. Para máxima interoperabilidade, os produtores de URI são desencorajados de caracteres não reservados com codificação percentual.
Caráter percentual
Como o caractere de porcentagem ( %
) serve como indicador para octetos codificados por porcentagem, ele deve ser codificado por porcentagem %25
para que esse octeto seja usado como dados em um URI.
Dados arbitrários
A maioria dos esquemas de URI envolve a representação de dados arbitrários, como um endereço IP ou caminho do sistema de arquivos , como componentes de um URI. As especificações do esquema URI devem, mas geralmente não fornecem, um mapeamento explícito entre os caracteres URI e todos os valores de dados possíveis sendo representados por esses caracteres.
Dados binários
Desde a publicação da RFC 1738 em 1994, foi especificado que os esquemas que fornecem a representação de dados binários em um URI devem dividir os dados em bytes de 8 bits e codificar por cento cada byte da mesma maneira que acima. O valor do byte 0x0F, por exemplo, deve ser representado por %0F
, mas o valor do byte 0x41 pode ser representado por A
, ou %41
. O uso de caracteres não codificados para caracteres alfanuméricos e outros caracteres não reservados é geralmente preferido, pois resulta em URLs mais curtos.
Dados do personagem
O procedimento de codificação de porcentagem de dados binários foi frequentemente extrapolado, às vezes de forma inadequada ou sem ser totalmente especificado, para ser aplicado a dados baseados em caracteres. Nos anos de formação da World Wide Web , ao lidar com caracteres de dados no repertório ASCII e usar seus bytes correspondentes em ASCII como base para determinar sequências codificadas por cento, essa prática era relativamente inofensiva; presumia-se apenas que os caracteres e bytes eram mapeados um a um e eram intercambiáveis. A necessidade de representar caracteres fora do intervalo ASCII, no entanto, cresceu rapidamente e os esquemas e protocolos de URI muitas vezes falharam em fornecer regras padrão para preparar dados de caracteres para inclusão em um URI. Consequentemente, os aplicativos da Web começaram a usar diferentes codificações multibyte, stateful e outras não compatíveis com ASCII como base para a codificação percentual, levando a ambigüidades e dificuldade de interpretar URIs de maneira confiável.
Por exemplo, muitos esquemas de URI e protocolos baseados em RFCs 1738 e 2396 presumem que os caracteres de dados serão convertidos em bytes de acordo com alguma codificação de caracteres não especificada antes de serem representados em um URI por caracteres não reservados ou bytes codificados por porcentagem. Se o esquema não permitir que o URI forneça uma dica sobre qual codificação foi usada, ou se a codificação entrar em conflito com o uso de ASCII para codificar por cento os caracteres reservados e não reservados, o URI não poderá ser interpretado de forma confiável. Alguns esquemas não conseguem levar em conta a codificação e, em vez disso, apenas sugerem que os caracteres de dados sejam mapeados diretamente para os caracteres URI, o que deixa para as implementações decidir se e como codificar por cento os caracteres de dados que não estão nos conjuntos reservados nem não reservados.
newline |
space |
" |
% |
- |
. |
< |
> |
\ |
^ |
_ |
` |
{ |
| |
} |
~ |
£ |
円
|
%0A ou %0D ou %0D%0A
|
%20 |
%22 |
%25 |
%2D |
%2E |
%3C |
%3E |
%5C |
%5E |
%5F |
%60 |
%7B |
%7C |
%7D |
%7E |
%C2%A3 |
%E5%86%86
|
Os dados de caracteres arbitrários às vezes são codificados por porcentagem e usados em situações não URI, como para programas de ofuscação de senha ou outros protocolos de conversão específicos do sistema.
Padrão atual
A sintaxe genérica de URI recomenda que novos esquemas de URI que fornecem a representação de dados de caracteres em um URI devem, na verdade, representar caracteres do conjunto não reservado sem tradução e devem converter todos os outros caracteres em bytes de acordo com UTF-8 , e então codifique por cento esses valores. Essa sugestão foi introduzida em janeiro de 2005 com a publicação do RFC 3986. Os esquemas de URI introduzidos antes dessa data não são afetados.
Não abordado pela especificação atual é o que fazer com dados de caracteres codificados. Por exemplo, em computadores, os dados de caracteres se manifestam na forma codificada, em algum nível e, portanto, podem ser tratados como dados binários ou de caracteres ao serem mapeados para caracteres URI. Presumivelmente, cabe às especificações do esquema de URI levar em conta essa possibilidade e exigir uma ou outra, mas, na prática, poucos, se houver, realmente o fazem.
Implementações fora do padrão
Existe uma codificação não padrão para caracteres Unicode :, onde xxxx é uma unidade de código UTF-16 representada como quatro dígitos hexadecimais. Este comportamento não é especificado por nenhum RFC e foi rejeitado pelo W3C. A oitava edição do ECMA-262 ainda inclui uma função que usa essa sintaxe, junto com as funções e , que aplicam a codificação UTF-8 a uma string e, em seguida, escapam por cento dos bytes resultantes.
%uxxxx
escape
encodeURI
encodeURIComponent
O tipo application / x-www-form-urlencoded
Quando os dados inseridos em formulários HTML são enviados, os nomes e valores dos campos do formulário são codificados e enviados ao servidor em uma mensagem de solicitação HTTP usando o método GET ou POST ou, historicamente, por e - mail . A codificação usado por padrão é baseado em uma versão inicial das regras gerais de codificação por cento URI, com uma série de modificações, como nova linha normalização e substituindo os espaços com +
em vez de %20
. O tipo de mídia dos dados codificados dessa maneira é application/x-www-form-urlencoded
e está atualmente definido nas especificações HTML e XForms . Além disso, a especificação CGI contém regras sobre como os servidores da web decodificam dados desse tipo e os disponibilizam para os aplicativos.
Quando os dados do formulário HTML são enviados em uma solicitação HTTP GET, eles são incluídos no componente de consulta do URI da solicitação usando a mesma sintaxe descrita acima. Quando enviados em uma solicitação HTTP POST ou via e-mail, os dados são colocados no corpo da mensagem e application/x-www-form-urlencoded
incluídos no cabeçalho Content-Type da mensagem.
Veja também
- Identificador de recurso internacionalizado
- Punycode
- Codificação binário para texto para uma comparação de vários algoritmos de codificação
- Shellcode
Referências
links externos
- DevPal URL encoder - ferramentas de desenvolvedor online que suportam codificação de URL.
Todas as especificações a seguir discutem e definem caracteres reservados, caracteres não reservados e codificação de porcentagem, de uma forma ou de outra:
- RFC 3986 / STD 66 (mais errata ), a especificação de sintaxe URI genérica atual.
- RFC 2396 (obsoleto, mais errata ) e RFC 2732 (mais errata ) juntos constituíam a versão anterior da especificação de sintaxe URI genérica.
- Codificação e decodificação de URL - Online - um site com várias opções para converter arquivos ou textos em formato codificado por URL.
- RFC 1738 (principalmente obsoleto) e RFC 1808 (obsoleto), que definem URLs .
- RFC 1630 (obsoleto), a primeira especificação de sintaxe URI genérica.
- Diretrizes W3C sobre nomenclatura e endereçamento: URIs, URLs, ...
- Explicação W3C de UTF-8 em URIs
- Tipos de conteúdo de formulário HTML W3C