Codifica degli URL: differenze tra le versioni

Versione delle 22:40, 9 ott 2024

Versione attuale delle 13:22, 20 feb 2025

(14 versioni intermedie di 5 utenti non mostrate)

Riga 1:

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 [[ASCII|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 <code>application/x-www-form-urlencoded</code>, come spesso avviene nell'invio di dati di [[form]] [[HTML]] in richieste [[Hypertext Transfer Protocol|HTTP]].

== Tipi ==

Riga 27:

=== 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 [[Sistema numerico esadecimale|cifre esadecimali]] (se c'è una sola cifra esadecimale, si aggiunge uno zero iniziale di riempimento). Le cifre, precedute da un [[Simbolosimbolo di percentuale]] (<code>%</code>) come [[Carattere di escape|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.

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 <code>/</code>, per esempio, se utilizzato nel "path" di un [[Uniform Resource Identifier|URI]], ha il significato speciale di essere un [[Barra_obliqua#In_informatica|delimitatore]] ''tra'' i segmenti del percorso. Se, secondo un dato schema URI, <code>/</code> deve essere ''in'' un segmento di percorso, allora i tre caratteri <code>%2F</code> (o che è lo stesso in minuscolo <code>%2f</code>) devono essere usati al posto di un normale <code>/</code>.

Il carattere riservato <code>/</code>, per esempio, se utilizzato nel "path" di un [[Uniform Resource Identifier|URI]], ha il significato speciale di essere un [[Barra_obliqua#In_informatica|delimitatore]] ''tra'' i segmenti del [[Path (informatica)|percorso]]. Se, secondo un dato schema URI, <code>/</code> deve essere ''in'' un segmento di percorso, allora i tre caratteri <code>%2F</code> (o, che è lo stesso in minuscolo <code>%2f</code>) devono essere usati al posto di un normale <code>/</code>.

{| class="wikitable"

Riga 49 ⟶ 51:

==== Carattere percentuale ====

Poiché il carattere percentuale (<code>%</code>) indica [[Ottetto (informatica)|ottetti]] codificati in percentuale, deve essere a sua volta codificato in percentuale come <code>%25</code> per essere utilizzato come carattere all'interno di un URI.

==== Dati arbitrari ====

Riga 58 ⟶ 60:

===== Dati carattere =====

La procedura per codificare in percentuale dati binari è stata spesso estesa, talvolta in modo inappropriato o senza essere completamente specificata, per applicarsiessere aiapplicata a dati basati su caratteri. Negli anni formativiiniziali del [[World Wide Web]], quando sivenivano trattava ditrattati caratteri dati neldel repertorio ASCII e si utilizzavano i loro byte corrispondenti come base per determinare le sequenze percent-encodedper 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, [[state (informatica)|stateful]], e altre codifiche non compatibili con ASCII come base per illa percent-encodingcodifica percentuale, portando aad 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 dati verranno convertiti in byte secondo una [[codifica dei caratteri]] non specificata prima di essere rappresentati in un URI tramite caratteri non riservati o byte percent-encodedcodificati in percentuale. Se lo schema non consente all'URI di fornire un'indicazione su quale codifica sia stata utilizzata, o se la codifica confliggedovesse andare in conflitto con l'uso di ASCII per percent-encodedcodifica 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 percent-encodedcodificare iin percentuale caratteri dati che non rientrano né negli insiemi riservati né in quelli non riservati.

{| class="wikitable"

Riga 82 ⟶ 84:

=== Il tipo application/x-www-form-urlencoded ===

Quando i dati inseriti in un [[form|modulo]] HTML vengono inviati, i nomi e i valori dei [[Campo (informatica)|campi]] del modulo vengono codificati e inviati al [[server]] in un messaggio di richiesta [[Hypertext Transfer Protocol|HTTP]] utilizzando i metodi [[Hypertext Transfer Protocol#Riga di richiesta|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,<ref>{{cita pubblicazione|url=https://tools.ietf.org/html/rfc1630|titolo=RFC 1630|cognome=Berners-Lee|nome=T.|wkautore=Tim Berners-Lee|data=giugno 1994|websitesito=IETF Tools|editore=IETF|access-dateaccesso=29 giugno 2016|archive-date=21 giugno 2016|archive-urlurlarchivio=https://web.archive.org/web/20160621035940/https://tools.ietf.org/html/rfc1630|url-statusurlmorto=liveno}}</ref>, con diverse modifiche come la normalizzazione del [[ritorno a capo]] e la sostituzione degli spazi con <code>+</code> anziché con <code>%20</code>. Il [[media type]] dei dati codificati in questo modo è <code>application/x-www-form-urlencoded</code>, ed è attualmente definito nelle specifiche HTML e [[XForms]]. Inoltre, la specifica [[Common Gateway Interface|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 <code>application/x-www-form-urlencoded</code> è incluso nell'[[Hypertext Transfer Protocol#Gli header della richiesta|intestazione]] Content-Type della richiesta.

== Note ==

Riga 90 ⟶ 92:

{{portale|informatica}}

[[Categoria:Uniform Resource Identifier]]