Decodifica dal 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: Nel caso di dati testuali, lo schema di codifica non contiene il set di caratteri, quindi è necessario specificare quale set di caratteri è stato utilizzato durante il processo di codifica. Di solito è UTF-8, ma può essere anche un altro; se non sei sicuro, prova le opzioni disponibili o l'opzione di rilevamento automatico. Queste informazioni vengono utilizzate per convertire i dati decodificati nel set di caratteri del nostro sito, in modo che tutte le lettere e i simboli possano essere visualizzati correttamente. Nota che questo non è rilevante per i file, poiché non è necessario applicare conversioni web-safe.
• Decodifica ogni riga separatamente: I dati codificati consistono generalmente in testo continuo, quindi anche i caratteri di nuova linea vengono convertiti nelle loro forme percent-encoded. Prima della decodifica, tutti gli spazi non codificati vengono rimossi dall'input per salvaguardarne l'integrità. Questa opzione è utile se intendi decodificare più voci di dati indipendenti separate da interruzioni di riga.
• Decodifica in modo ricorsivo: Alcuni dati possono essere codificati in URL più volte, risultando in livelli di codifica nidificati (per esempio "%2520", che decodifica a "%20" e poi a uno spazio). Quando questa opzione è abilitata, i dati vengono decodificati ripetutamente fino a quando non rimangono più pattern codificati validi, o fino al limite massimo di 16 cicli di decodifica. Questa opzione è utile per gestire dati codificati più volte, sia intenzionalmente sia a seguito di elaborazioni ripetute.
• Modalità Live: Quando attivi questa opzione, i dati inseriti vengono decodificati 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.

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.