Codifica degli URL: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Riga 60:
La procedura per codificare in percentuale dati binari è stata spesso estesa, talvolta in modo inappropriato o senza essere completamente specificata, per applicarsi ai dati basati su caratteri. Negli anni formativi del [[World Wide Web]], quando si trattava di caratteri dati nel repertorio ASCII e si utilizzavano i loro byte corrispondenti come base per determinare le sequenze percent-encoded, 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 il percent-encoding, portando a 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-encoded. Se lo schema non consente all'URI di fornire un'indicazione su quale codifica sia stata utilizzata, o se la codifica confligge con l'uso di ASCII per percent-encoded 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-encoded i caratteri dati che non rientrano né negli insiemi riservati né in quelli non riservati.
{| class="wikitable"
| |||