Partire dai byte originali
Lo strumento di analisi della codifica e conversione in UTF-8, legge un file locale prima che un altro programma lo decodifichi. Scegli l’esportazione originale invece di copiare testo illeggibile da un editor. Un file può contenere byte UTF-8 validi senza che questo dimostri che UTF-8 fosse la codifica prevista.
Un piccolo esempio riproducibile
Seleziona Carica un esempio Windows-1252. Il file sintetico contiene esattamente otto byte: 43 61 66 E9 20 80 0D 0A. Windows-1252 viene selezionato esplicitamente. Il testo Unicode atteso è Café €\r\n: la notazione finale indica un vero CR seguito da LF, non quattro caratteri letterali.
I punti di codice Unicode sono U+0043 U+0061 U+0066 U+00E9 U+0020 U+20AC U+000D U+000A. La decodifica rigorosa in UTF-8 dei byte originali non riesce: E9 non è seguito dai byte di continuazione richiesti. È un motivo per verificare la codifica di origine, non una prova che ogni file di questo tipo sia Windows-1252.
- Mantieni Windows-1252 selezionato e fai clic su Anteprima della conversione.
- Controlla che l’anteprima mostri Café €, con un CRLF e un’interruzione di riga finale nei dettagli.
- Lascia deselezionato il BOM in uscita, a meno che l’applicazione di destinazione non lo richieda esplicitamente.
- Scarica il file UTF-8. I suoi undici byte esatti sono
43 61 66 C3 A9 20 E2 82 AC 0D 0A. - Con l’opzione BOM selezionata, genera di nuovo l’anteprima: il risultato contiene quattordici byte, iniziando con
EF BB BFprima degli undici byte precedenti.
Perché “ANSI” non basta
L’etichetta “ANSI” di un’applicazione è ambigua. Windows-1252 associa il byte 80 al simbolo dell’euro; ISO-8859-1 lo associa a U+0080, un carattere di controllo C1 che questo strumento rifiuta. I byte 81, 8D, 8F, 90 e 9D non sono definiti nella mappatura rigorosa Windows-1252 dello strumento e interrompono la conversione. Chiedi a chi ha prodotto l’esportazione quale sia la codifica effettiva, invece di provare opzioni finché il testo sembra plausibile.
BOM, UTF-16 e sequenze finali danneggiate
FF FE 41 00 0D 00 0A 00 è un esempio UTF-16LE con BOM. Diventa 41 0D 0A in UTF-8 senza BOM: A più CRLF. Senza BOM, UTF-16 deve essere selezionato esplicitamente. Un byte finale spaiato o un surrogato non accoppiato interrompe la conversione, anche oltre l’anteprima visibile. Un BOM UTF-32 viene riconosciuto ma rifiutato.
Cosa conserva la conversione e cosa non può riparare
Vengono conservati spazi, tabulazioni, fine riga misti CRLF/LF/CR, presenza o assenza di un’interruzione di riga finale e rappresentazioni Unicode precomposte o con caratteri combinanti. Viene rimosso solo il BOM iniziale del file di origine; scegli tu se aggiungerne uno in uscita. Se U+FFFD è già presente nell’origine, rimane. Convertire un testo già corrotto come “Café” non recupera i byte originali.
Il limite è 5 MiB (5.242.880 byte); l’anteprima mostra al massimo 16.000 unità di codice UTF-16, mentre la validazione e l’esportazione riguardano l’intero file. Le firme binarie note e i controlli NUL/C0/C1 diversi da tabulazione, CR e LF vengono rifiutati. Questa protezione prudenziale può rifiutare testi insoliti ma legittimi. I download usano l’estensione .utf8.txt e contenuto di testo semplice. Il file di origine non viene sovrascritto.
Per lavorare con un CSV, converti prima la codifica, poi usa il convertitore da CSV a JSON, per modificarne la struttura. Lo strumento di codifica non interpreta il CSV e non cambia i separatori. L’elaborazione avviene nella memoria del browser, senza richieste di rete né salvataggi da parte dello strumento; le normali richieste del sito caricano comunque pagine e risorse. Torna allo strumento di analisi della codifica, per provare l’esempio esatto.