|
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 [[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 stess,ostesso in minuscolo <code>%2f</code>) devono essere usati al posto di un normale <code>/</code>.
{| class="wikitable"
==== 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 ====
===== 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"
=== 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 ==
{{portale|informatica}}
[[Categoria:Uniform Resource Identifier]]
| 