Codifica in formato URL codificato

Panoramica

Scopri Decodifica e Codifica URL, uno strumento online semplice che fa esattamente ciò che promette: decodifica dalla codifica URL e codifica in essa rapidamente e facilmente. Codifica i tuoi dati in URL senza problemi o decodificali in un formato leggibile dall'uomo.

La codifica URL, nota anche come "percent-encoding", è un meccanismo per codificare informazioni in un Uniform Resource Identifier (URI). Sebbene sia nota come codifica URL, è in realtà utilizzata più generalmente nell'insieme principale di Uniform Resource Identifier (URI), che include sia Uniform Resource Locator (URL) sia Uniform Resource Name (URN). Come tale, è anche utilizzata nella preparazione dei dati del tipo media "application/x-www-form-urlencoded", spesso impiegata per l'invio di dati da moduli HTML nelle richieste HTTP.

Opzioni avanzate

• Set di caratteri: Il nostro sito utilizza il set di caratteri UTF-8, quindi i dati in input vengono trasmessi in tale formato. Modifica questa opzione se vuoi convertire i dati in un altro set di caratteri prima della codifica. Nota che nel caso di dati testuali, lo schema di codifica non contiene il set di caratteri, quindi potrebbe essere necessario specificare il set appropriato durante il processo di decodifica. Per quanto riguarda i file, l'opzione binaria è quella predefinita, che omette qualsiasi conversione; questa opzione è richiesta per tutto tranne i documenti di testo semplice.
• Separatore di nuova linea: I sistemi Unix e Windows utilizzano caratteri di interruzione di riga differenti, quindi prima della codifica ogni variante verrà sostituita nei dati dall'opzione selezionata. Per la sezione file, questo è parzialmente irrilevante poiché i file contengono già i separatori corrispondenti, ma puoi definire quale utilizzare per le funzioni "codifica ogni riga separatamente" e "dividi righe in blocchi".
• Codifica ogni riga separatamente: Anche i caratteri di nuova linea vengono convertiti nelle loro forme percent-encoded. Usa questa opzione se vuoi codificare più voci di dati indipendenti separate da interruzioni di riga. (*)
• Dividi le righe in blocchi di 76 caratteri: I dati codificati diventeranno un testo continuo senza spazi, quindi seleziona questa opzione se vuoi dividerli in più righe. Il limite di caratteri applicato è definito nella specifica MIME (RFC 2045), che stabilisce che le righe codificate non devono superare i 76 caratteri. (*)
• Modalità Live: Quando attivi questa opzione, i dati inseriti vengono codificati immediatamente con le funzioni JavaScript integrate del browser, senza inviare alcuna informazione ai nostri server. Attualmente questa modalità supporta solo il set di caratteri UTF-8.

(*) Queste opzioni non possono essere abilitate simultaneamente, poiché l'output risultante non sarebbe valido per la maggior parte delle applicazioni.

Sicuro e protetto

Tutte le comunicazioni con i nostri server avvengono tramite connessioni SSL sicure (https). Eliminiamo i file caricati dai nostri server subito dopo la loro elaborazione, e il file scaricabile risultante viene eliminato subito dopo il primo tentativo di download o dopo 15 minuti di inattività (a seconda di quale si verifica prima). Non conserviamo né ispezioniamo in alcun modo il contenuto dei dati inviati o dei file caricati. Leggi la nostra privacy policy qui sotto per maggiori dettagli.

Completamente gratuito

Il nostro strumento è gratuito. Da ora non è più necessario scaricare alcun software per operazioni così semplici.

Dettagli della codifica URL

Tipi di caratteri URI

I caratteri consentiti in un URI sono riservati o non riservati (o un carattere percentuale come parte di una percent-encoding). I caratteri riservati sono caratteri che a volte hanno un significato speciale. Per 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. Usando il percent-encoding, i caratteri riservati sono rappresentati tramite sequenze di caratteri speciali. I set di caratteri riservati e non riservati e le circostanze in cui certi caratteri riservati hanno significato speciale sono cambiati leggermente ad ogni nuova revisione delle specifiche che regolano gli URI e gli schemi URI.

Altri caratteri in un URI devono essere codificati tramite percent-encoding.

Percent-encoding dei caratteri riservati

Quando un carattere del set riservato (un "carattere riservato") ha un significato speciale (uno "scopo riservato") in un contesto particolare e uno schema URI stabilisce che è necessario usare quel carattere per un altro scopo, allora il carattere deve essere percent-encoded. Percent-encoding di un carattere riservato significa convertire il carattere nel corrispondente valore byte in ASCII e poi rappresentare tale valore come una coppia di cifre esadecimali. Le cifre, precedute da un segno di percentuale ("%"), vengono poi utilizzate nell'URI al posto del carattere riservato. (Per un carattere non ASCII, di solito viene convertito nella sequenza di byte in UTF-8 e ciascun byte è rappresentato come sopra.)

Il carattere riservato "/", per esempio, se usato nella componente "path" di un URI, ha il significato speciale di delimitatore tra segmenti del path. Se, secondo uno schema URI, "/" deve essere presente in un segmento del path, allora i tre caratteri "%2F" (o "%2f") devono essere utilizzati nel segmento al posto di "/".

I caratteri riservati che non hanno uno scopo riservato in un contesto particolare possono anche essere percent-encoded, ma non sono semanticamente diversi dagli altri caratteri.

Nel componente "query" di un URI (la parte dopo il carattere "?"), ad esempio, "/" è ancora considerato un carattere riservato, ma normalmente non ha uno scopo riservato (a meno che uno schema URI particolare non dica diversamente). Il carattere non deve essere percent-encoded quando non ha uno scopo riservato.

Gli URI che differiscono solo per il fatto che un carattere riservato sia percent-encoded o meno sono normalmente considerati non equivalenti (indicando la stessa risorsa), a meno che i caratteri riservati in questione non abbiano uno scopo riservato. Questa determinazione dipende dalle regole stabilite per i caratteri riservati dai singoli schemi URI.

Percent-encoding dei caratteri non riservati

I caratteri del set non riservato non devono mai essere percent-encoded.

Gli URI che differiscono solo per il fatto che un carattere non riservato sia percent-encoded o meno sono equivalenti per definizione, ma i processori URI, in pratica, potrebbero non trattarli sempre in modo equivalente. Ad esempio, i consumatori di URI non dovrebbero trattare "%41" diversamente da "A" ("%41" è il percent-encoding di "A") o "%7E" diversamente da "~", ma alcuni lo fanno. Per la massima interoperabilità, si sconsiglia quindi ai produttori di URI di percent-encodare caratteri non riservati.

Percent-encoding del carattere percentuale

Poiché il carattere percentuale ("%") serve come indicatore per gli ottetti percent-encoded, deve essere percent-encoded come "%25" affinché tale ottetto possa essere utilizzato come dato all'interno di un URI.

Percent-encoding di dati arbitrari

La maggior parte degli schemi URI comporta la rappresentazione di dati arbitrari, come un indirizzo IP o un percorso del file system, 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 dei dati rappresentati da quei caratteri.

Dati binari

Dalla pubblicazione del RFC 1738 nel 1994, è stato specificato che gli schemi che prevedono la rappresentazione di dati binari in un URI devono dividere i dati in byte da 8 bit e percent-encodare ciascun byte nello stesso modo descritto sopra. Ad esempio, il valore del byte 0F (esadecimale) dovrebbe essere rappresentato come "%0F", mentre il valore del byte 41 (esadecimale) può essere rappresentato come "A" o "%41". L'uso di caratteri non codificati per caratteri alfanumerici e altri caratteri non riservati è generalmente preferito perché produce URL più brevi.

Dati basati su caratteri

La procedura per il percent-encoding dei dati binari è spesso stata estrapolata, talvolta in modo inappropriato o senza specifica completa, per essere applicata ai dati basati su caratteri. Nei primi anni del World Wide Web, quando si trattavano caratteri del repertorio ASCII e si utilizzavano i byte corrispondenti in ASCII come base per determinare le sequenze percent-encoded, questa pratica era relativamente innocua; molti presumevano che caratteri e byte corrispondessero uno a uno e fossero intercambiabili. Tuttavia, la necessità di rappresentare caratteri al di fuori dell'intervallo ASCII è cresciuta rapidamente e gli schemi e protocolli URI spesso non fornivano regole standard per preparare i dati basati su caratteri per l'inclusione in un URI. Di conseguenza, le applicazioni web hanno iniziato a utilizzare diverse codifiche multi-byte, 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 sui RFC 1738 e 2396 presumono che i caratteri dei dati vengano 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 permette all'URI di fornire un'indicazione sulla codifica utilizzata, o se la codifica è in conflitto con l'uso di ASCII per percent-encodare caratteri riservati e non riservati, l'URI non può essere interpretato in modo affidabile. Alcuni schemi non tengono affatto conto della codifica e suggeriscono semplicemente che i caratteri dei dati siano mappati direttamente ai caratteri URI, lasciando all'utente la decisione se e come percent-encodare caratteri dei dati che non appartengono né al set riservato né a quello non riservato.

I dati carattere arbitrari sono talvolta percent-encoded e utilizzati in situazioni non URI, come programmi per offuscamento delle password o altri protocolli di traduzione specifici del sistema.