Codifica degli URL

La codifica degli URL, nota anche come codifica percentuale, è un metodo per codificare dati arbitrari in un Uniform Resource Identifier (URI) utilizzando solo i caratteri US ASCII all'interno di un URI. Sebbene sia conosciuta come codifica degli URL, è utilizzata nell'ambito del più generale Uniform Resource Identifier (URI), che comprende sia Uniform Resource Locator (URL) che Uniform Resource Name (URN). Di conseguenza, è anche utilizzata nella preparazione di dati di tipo application/x-www-form-urlencoded, come spesso avviene nell'invio di dati di form HTML in richieste HTTP.

Tipi

Codifica percentuale in un URI

Tipi di caratteri URI

I caratteri ammessi in un URI sono riservati o non riservati. I caratteri riservati sono quei caratteri che a volte hanno un significato speciale. Ad esempio, il carattere slash viene utilizzato per separare diverse parti di un URL (o, più in generale, di un URI). I caratteri non riservati non hanno significati speciali. Utilizzando la codifica percentuale, i caratteri riservati sono rappresentati utilizzando sequenze di caratteri speciali. I set di caratteri riservati e non riservati e le circostanze in cui alcuni caratteri riservati hanno un significato speciale sono cambiati leggermente con ogni revisione delle specifiche inerenti gli URI ed i relativi schemi.

Sezione 2.2 di RFC 3986 Caratteri riservati (Gennaio 2005)

!

#

$

&

'

(

)

*

+

,

/

:

;

=

?

@

[

]

Sezione 2.3 di RFC 3986 Caratteri non riservati (Gennaio 2005)

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

-

.

_

~

Altri caratteri in un URI devono essere resi in codifica percentuale.

Caratteri riservati

Quando un carattere dell'insieme riservato (un "carattere riservato") ha un significato speciale (dunque uno "scopo riservato") in un certo contesto, e uno schema URI stabilisce che è necessario utilizzare quel carattere per un altro scopo, allora il carattere deve essere reso in codifica percentuale. La codifica percentuale di un carattere riservato comporta la conversione del carattere nel suo corrispondente valore byte in ASCII, e poi la rappresentazione di quel valore come coppia di cifre esadecimali (se c'è una sola cifra esadecimale, si aggiunge uno zero iniziale di riempimento). Le cifre, precedute da un simbolo di percentuale (%) come carattere di escape, vengono quindi utilizzate nell'URI al posto del carattere riservato.

Un carattere non ASCII viene tipicamente convertito nella sua sequenza di byte in UTF-8, e poi ciascun valore byte è rappresentato come descritto sopra.

Il carattere riservato /, per esempio, se utilizzato nel "path" di un URI, ha il significato speciale di essere un delimitatore tra i segmenti del percorso. Se, secondo un dato schema URI, / deve essere in un segmento di percorso, allora i tre caratteri %2F (o, che è lo stess,o in minuscolo %2f) devono essere usati al posto di un normale /.

Caratteri riservati dopo la codifica percentuale

!

#

$

&

'

(

)

*

+

,

/

:

;

=

?

@

[

]

%21

%23

%24

%26

%27

%28

%29

%2A

%2B

%2C

%2F

%3A

%3B

%3D

%3F

%40

%5B

%5D

I caratteri riservati che non hanno uno scopo riservato in un contesto particolare possono comunque essere codificati in percentuale, ma non sono semanticamente diversi da quelli che non lo sono.

Nella componente "query" di un URI (la parte dopo un ?), per esempio, / è ancora considerato un carattere riservato, ma normalmente non ha uno scopo riservato, a meno che un particolare schema URI non dica il contrario. Il carattere non deve essere codificato in percentuale quando non ha uno scopo riservato.

Caratteri non riservati

I caratteri dell'insieme non riservato non devono mai essere codificati in percentuale.

Gli URI che differiscono solo per il fatto che un carattere non riservato è codificato in percentuale o appare letteralmente sono equivalenti per definizione, ma i software che elaborano gli URI, nella pratica, potrebbero non riconoscere sempre questa equivalenza. Ad esempio, gli utilizzatori di URI non dovrebbero trattare %41 in modo diverso da A o %7E in modo diverso da ~, ma alcuni lo fanno. Per massima interoperabilità, si sconsiglia di codificati in percentuale caratteri non riservati.

Carattere percentuale

Poiché il carattere percentuale (%) indica ottetti codificati in percentuale, deve essere a sua volta codificato in percentuale come %25 per essere utilizzato come carattere all'interno di un URI.

Dati arbitrari

La maggior parte degli schemi URI comporta la rappresentazione di dati arbitrari, come un indirizzo IP o un path, come componenti di un URI. Le specifiche degli schemi URI dovrebbero, ma spesso non lo fanno, fornire una mappatura esplicita tra i caratteri URI e tutti i possibili valori di dati rappresentati da quei caratteri.

Dati binari

Dalla pubblicazione dell'RFC 1738 nel 1994, è stato specificato che gli schemi che prevedono la rappresentazione di dati binari in un URI devono suddividere i dati in byte e codificare in percentuale ciascun byte nello stesso modo descritto precedentemente. Ad esempio, il valore del byte 0x0F dovrebbe essere rappresentato come %0F, mentre il valore del byte 0x41 può essere rappresentato come A o %41. L'uso di caratteri non codificati per caratteri alfanumerici e altri caratteri non riservati è tipicamente preferito, poiché consente di ottenere URL più brevi.

Dati carattere

La procedura per codificare in percentuale dati binari è stata estesa, talvolta in modo inappropriato o senza essere completamente specificata, per essere applicata a dati basati su caratteri. Negli anni iniziali del World Wide Web, quando venivano trattati caratteri del repertorio ASCII e si utilizzavano i loro byte corrispondenti come base per determinare le sequenze per la codifica in percentuale, questa pratica era relativamente innocua: si assumeva semplicemente che i caratteri e i byte si mappassero uno a uno e fossero intercambiabili. Tuttavia, la necessità di rappresentare caratteri al di fuori dell'intervallo ASCII crebbe rapidamente, e gli schemi e i protocolli URI spesso non fornivano regole standard per preparare i dati carattere per l'inclusione in un URI. Di conseguenza, le applicazioni web iniziarono a utilizzare diverse codifiche multi-byte e altre non compatibili con ASCII come base per la codifica percentuale, portando ad ambiguità e difficoltà nell'interpretazione affidabile degli URI.

Ad esempio, molti schemi e protocolli URI basati sugli RFC 1738 e RFC 2396 presumono che i caratteri verranno convertiti in byte secondo una codifica dei caratteri non specificata prima di essere rappresentati in un URI tramite caratteri non riservati o byte codificati in percentuale. Se lo schema non consente all'URI di fornire un'indicazione su quale codifica sia stata utilizzata, o se la codifica dovesse andare in conflitto con l'uso di ASCII per codifica in percentuale di caratteri riservati e non riservati, allora l'URI non può essere interpretato in modo affidabile. Alcuni schemi non considerano affatto la codifica e suggeriscono invece che i caratteri dati si mappino direttamente sui caratteri URI, lasciando così alle implementazioni decidere se e come codificare in percentuale caratteri che non rientrano né negli insiemi riservati né in quelli non riservati.

Caratteri comuni dopo codifica percentuale (basati su ASCII o UTF-8)

␣

"

%

-

.

<

>

\

^

_

`

{

|

}

~

£

€

%20

%22

%25

%2D

%2E

%3C

%3E

%5C

%5E

%5F

%60

%7B

%7C

%7D

%7E

%C2%A3

%E2%82%AC

Standard attuale

La sintassi generica degli URI raccomanda che i nuovi schemi URI che prevedono la rappresentazione di dati carattere in un URI dovrebbero, di fatto, rappresentare i caratteri dell'insieme non riservato senza traduzione e convertire tutti gli altri caratteri in byte secondo UTF-8, per poi codificare in percentuale quei valori. Questo suggerimento è stato introdotto nel gennaio 2005 con la pubblicazione dell'RFC 3986. Gli schemi URI introdotti prima di questa data non ne sono influenzati.

Non viene affrontato dalla specifica attuale cosa fare con i dati carattere codificati. Ad esempio, nei computer, i dati carattere si manifestano in forma codificata, a un certo livello, e quindi potrebbero essere trattati come dati binari o carattere quando vengono mappati ai caratteri URI. Presumibilmente, spetta alle specifiche degli schemi URI tenere conto di questa possibilità e richiedere uno o l'altro, ma in pratica, pochi, se non nessuno, lo fanno.

Il tipo application/x-www-form-urlencoded

Quando i dati inseriti in un modulo HTML vengono inviati, i nomi e i valori dei campi del modulo vengono codificati e inviati al server in un messaggio di richiesta HTTP utilizzando i metodi HTTP GET o POST, oppure, storicamente, tramite email. La codifica utilizzata per impostazione predefinita si basa su una versione iniziale delle regole generali di codifica percentuale di URI,, con diverse modifiche come la normalizzazione del ritorno a capo e la sostituzione degli spazi con + anziché con %20. Il media type dei dati codificati in questo modo è application/x-www-form-urlencoded, ed è attualmente definito nelle specifiche HTML e XForms. Inoltre, la specifica CGI contiene regole su come i server web decodificano i dati di questo tipo e li rendono disponibili alle applicazioni.

Quando i dati del modulo HTML vengono inviati in una richiesta HTTP GET, sono inclusi nella query string dell'URI di richiesta utilizzando la stessa sintassi descritta sopra. Quando vengono inviati in una richiesta HTTP di tipo POST o tramite email, i dati sono posizionati nel corpo del messaggio, e application/x-www-form-urlencoded è incluso nell'intestazione Content-Type della richiesta.