Perché il tuo CSV mostra caratteri strani in Excel e come risolvere il problema di codifica (Guida 2026)

Diagnosi in 30 secondi: i tuoi dati non sono danneggiati, sono letti male

La prima cosa da stabilire quando un CSV si apre con caratteri strani è se i dati sono danneggiati o solo mostrati in modo sbagliato, perché i due casi hanno soluzioni molto diverse, e la soluzione sbagliata può trasformare un problema di visualizzazione in una vera perdita di dati. Ecco il test di 30 secondi. Apri lo stesso file in un semplice editor di testo, Blocco note su Windows oppure TextEdit in modalità solo testo su Mac, oppure in Fogli Google tramite File e poi Importa. Se i caratteri sembrano corretti in quel caso, i tuoi dati sono intatti e solo la visualizzazione di Excel è sbagliata. Il file sul disco contiene i byte giusti, ed Excel li sta semplicemente decodificando con la codifica sbagliata. Questo è il caso più comune, e ogni soluzione di questa guida parte da qui.

Il secondo indizio è quali caratteri sono sbagliati. Se il semplice testo in inglese, i numeri e la punteggiatura sembrano a posto, ma le lettere accentate, le dieresi, le cediglie, il simbolo dell'euro e gli alfabeti non latini sembrano sbagliati, stai guardando un problema di codifica, non un problema di delimitatore e non un danneggiamento. Un problema di delimitatore mette intere righe in una sola colonna. Un danneggiamento rovina tutto oppure fa sparire delle righe. Un problema di codifica è preciso: rompe esattamente i caratteri che hanno bisogno di più di un byte in UTF-8, e lascia tutto il resto intatto. Se il tuo file mostra José dove dovrebbe mostrare José, oppure München dove dovrebbe mostrare München, quello schema è l'impronta digitale dei byte UTF-8 letti come una vecchia codifica a un solo byte, e ti dice sia la causa sia la soluzione.

Il terzo controllo decide se il recupero è ancora possibile. Se i caratteri rovinati sono visibili anche nell'editor di testo, il file stesso potrebbe essere stato salvato di nuovo dopo la lettura sbagliata, e i caratteri sbagliati potrebbero ora essere scritti dentro il file. Non farti prendere dal panico, e soprattutto non salvare di nuovo sopra l'originale. La sezione sul recupero più avanti in questa guida tratta esattamente questo caso, compreso l'unica situazione in cui i caratteri sono davvero irrecuperabili: quando un carattere è stato sostituito da un punto interrogativo o da un simbolo di sostituzione durante un salvataggio, l'informazione originale è sparita da quella copia, e solo i dati di origine possono rigenerarla. Finché non hai controllato, tieni intatto il file originale, lavora su una copia, e non salvare mai un file rovinato sopra quello buono.

Perché Excel indovina male: un file CSV non porta nessuna etichetta di codifica

Per capire perché questo continua a succedere, ti serve un fatto sul formato CSV: un file CSV è semplice testo senza nessuna intestazione che dice quale codifica usa. Un file di foglio di calcolo porta con sé la sua struttura e la sua codifica del testo. Un file CSV non porta nessuna delle due. Sono solo byte, virgole e interruzioni di riga. Quando un programma lo apre, il programma deve decidere come trasformare quei byte in caratteri, e programmi diversi decidono in modo diverso. Gli editor di testo moderni e Fogli Google rilevano UTF-8 automaticamente nella maggior parte dei casi, ed è per questo che lo stesso file sembra corretto in essi. Excel, quando fai doppio clic su un file CSV, non rileva nulla. Dà per scontata la codifica predefinita del tuo sistema, che su molti sistemi Windows è una vecchia pagina di codice come Windows-1252, e non controlla se quella supposizione era giusta.

Quella supposizione è tutto il problema. UTF-8 rappresenta un carattere come é con due byte, e un carattere come € con tre byte. Una vecchia codifica a un solo byte legge ogni byte come un carattere a sé, quindi una é diventa due caratteri sbagliati, é, e un € diventa tre caratteri, €. Il file non è cambiato. È il lettore che ha cambiato il significato dei byte. Questo è anche il motivo per cui il problema segue uno schema per regione e per macchina. Un collega su un sistema la cui codifica predefinita corrisponde al file lo vede correttamente, mentre tu vedi caratteri sballati, e lo stesso file può sembrare a posto su un computer e rotto su un altro. Nessun computer è rotto, e il file non è danneggiato. I due lettori semplicemente non sono d'accordo su cosa significano i byte, e Excel al doppio clic si fida della sua impostazione predefinita senza chiedere.

Questo spiega anche perché il problema appare così spesso con i file convertiti da JSON. JSON è UTF-8 per definizione, quindi una conversione da JSON a CSV produce naturalmente un CSV UTF-8, comprese tutte le lettere accentate, le città e i simboli di valuta presenti nei dati di origine. La conversione è corretta. L'apertura non corrisponde. Il convertitore di questa pagina, per esempio, scarica semplice UTF-8 senza marca di ordine dei byte, che è la scelta corretta per i caricamenti web, i database, Fogli Google e Python, ma significa che un doppio clic in Excel su Windows può indovinare la codifica sbagliata. Sapere che il problema sta nel passaggio di apertura, non nel passaggio di conversione, ti dice dove risolverlo: all'importazione, oppure con un BOM, come mostrano le prossime sezioni.

Leggi i caratteri sballati: cosa ti dicono i caratteri strani

Il testo rovinato non è casuale, e imparare a leggerlo ti dice qual era il carattere originale e conferma la diagnosi prima che tu tocchi qualsiasi cosa. Lo schema tipico è à seguita da un altro carattere. Ogni volta che vedi é, ä, ü oppure ç, stai guardando un carattere UTF-8 letto come Windows-1252. La à è il primo byte della sequenza UTF-8, letto male come un carattere a sé, e il secondo carattere è il secondo byte, anch'esso letto male. Una volta che conosci lo schema, puoi decodificare i caratteri sballati a mente: é era é, ü era ü, ç era ç, ão era ão, come in São Paulo che appare come São Paulo. Il simbolo dell'euro è il caso più evidente: € è di tre byte in UTF-8, quindi appare come i tre caratteri €. Un trattino lungo appare come â€, e un apostrofo tipografico appare come ’.

Lo schema cambia con l'alfabeto, e anche quel cambiamento è utile per la diagnosi. I nomi in alfabeto latino producono lo schema à visto sopra. Il giapponese, il coreano e altri alfabeti non latini producono caratteri sballati più lunghi, perché ogni carattere è di tre byte in UTF-8, quindi un carattere diventa tre caratteri sbagliati: Tokyo scritta come 東京 appare come una serie di caratteri come æ±äº¬, e un nome coreano diventa una serie simile. Se vedi quel tipo di caratteri sballati lunghi, la diagnosi è la stessa, UTF-8 letto come una codifica a un solo byte, solo che i caratteri coinvolti sono di tre byte. Se invece vedi punti interrogativi oppure simboli di sostituzione a forma di rombo nero dove dovrebbero esserci dei caratteri, la diagnosi è diversa: quei simboli significano che l'informazione è andata già persa durante un salvataggio, non solo letta male durante la visualizzazione, e la sezione sul recupero spiega cosa fare in quel caso.

Il blocco di codice qui sotto mostra le letture sbagliate esatte, ottenute prendendo del testo UTF-8 corretto e decodificandolo come Windows-1252, nel modo in cui fa Excel al doppio clic. Questi non sono esempi inventati. Ogni coppia è stata generata in modo meccanico, quindi puoi confrontare il tuo file con esse e confermare la diagnosi prima di risolvere qualsiasi cosa. Se il tuo file mostra il lato sinistro di una di queste coppie dove dovrebbe mostrare il lato destro, hai un problema di codifica, e la soluzione di importazione della prossima sezione riparerà la visualizzazione senza cambiare il file.

Correct text  ->  What Excel shows\nJosé García  ->  José GarcÃ\u00ada\nMünchen      ->  München\nFrançois     ->  François\nSão Paulo    ->  São Paulo\n€50,000      ->  €50,000\ncafé — ok    ->  café — ok\n東京 (Tokyo)  ->  æ\u00b1京\n김민준        ->  김민준

Nota cosa dimostra la tabella: non manca nulla. Ogni carattere sbagliato corrisponde a un byte reale dell'originale, solo decodificato con la tabella sbagliata. Per questo la soluzione di importazione funziona in modo così completo. Quando dici a Excel che il file è UTF-8, esso decodifica gli stessi byte con la tabella giusta, e ogni carattere torna a essere se stesso, senza modifiche, senza trova e sostituisci e senza inserimento di dati. Se il tuo file corrisponde a questo schema, salta la sezione sul recupero e vai direttamente alla soluzione di importazione. Non hai un file danneggiato. Hai un file letto male.

Correzione 1: importa il file e di' a Excel che è UTF-8

Questa è la soluzione da provare per prima, perché non cambia nulla del tuo sistema, nulla del file, e funziona su qualsiasi CSV UTF-8 qualunque sia il suo delimitatore. Invece di fare doppio clic sul file, apri prima Excel, poi importa il file tramite l'importazione guidata, dove scegli tu stesso la codifica. L'anteprima nella finestra di importazione ti mostra subito se hai scelto bene: i caratteri vengono mostrati correttamente nell'anteprima esattamente come appariranno sul foglio. Se l'anteprima mostra ancora caratteri sballati, non hai ancora cambiato nulla, e puoi provare un'altra origine del file prima di caricare.

• ▸In Excel vai su Dati, poi su Da testo/CSV, e seleziona il tuo file.
• ▸Nella finestra di anteprima imposta l'origine del file su 65001: Unicode (UTF-8). Nelle versioni più vecchie di Excel la stessa opzione appare come Unicode (UTF-8) nella procedura guidata di importazione del testo.
• ▸Controlla l'anteprima. Se i caratteri ora si leggono correttamente, continua. Se sembrano ancora sbagliati, il file potrebbe non essere affatto UTF-8, quindi prova le altre origini dell'elenco una alla volta e guarda l'anteprima.
• ▸Imposta il delimitatore sul carattere usato dal file, virgola, punto e virgola, tabulazione oppure barra verticale, e controlla che le colonne si dividano correttamente nella stessa anteprima.
• ▸Fai clic su Carica. Per le colonne che devono restare testo, come i codici con zeri iniziali, imposta quelle colonne su Testo nel passaggio di importazione, prima di caricare.

Fai di questo il tuo modo abituale di aprire i file CSV, non solo la tua mossa di emergenza. Il doppio clic è una supposizione sia sul delimitatore sia sulla codifica. L'importazione è una scelta su entrambi, e la scelta richiede circa dieci secondi in più. La stessa soluzione funziona su Mac, dove anche il percorso di importazione è quello affidabile: apri una cartella di lavoro vuota, vai su Dati, poi su Da testo, scegli il file, scegli Unicode (UTF-8) come origine del file e finisci. Fogli Google non ha bisogno di nessuna soluzione nella maggior parte dei casi, perché File e poi Importa rileva UTF-8 automaticamente, ed è per questo che un file che sembra rotto in Excel spesso sembra perfetto in Fogli. Quella differenza è di per sé una diagnosi: se Fogli lo mostra bene ed Excel lo mostra male, il file è a posto ed Excel ha indovinato male.

Correzione 2: aggiungi un BOM in modo che il doppio clic funzioni

Se apri lo stesso tipo di file ogni giorno, importarlo ogni volta diventa noioso, e la soluzione duratura è dare a Excel l'indizio di cui ha bisogno al doppio clic. Quell'indizio è un BOM, una marca di ordine dei byte: tre byte invisibili proprio all'inizio del file che dicono che questo file è UTF-8. Excel controlla la presenza di un BOM prima di tirare a indovinare, quindi un file UTF-8 con un BOM si apre correttamente al doppio clic anche su un sistema Windows la cui codifica predefinita è Windows-1252. Il BOM è invisibile in Excel e nella maggior parte degli editor, e non cambia nessuna riga di dati. Riguarda solo i primi tre byte del file.

Il modo più facile per aggiungerne uno non richiede codice. Apri il file nel Blocco note, vai su File e poi su Salva con nome, e imposta il menu a tendina della codifica su UTF-8 con BOM, poi salva. Il file ora si apre correttamente al doppio clic in Excel. Se produci file da uno script, aggiungi il BOM al momento della scrittura invece di correggere i file dopo. In Python è una sola parola: apri il file con la codifica utf-8-sig invece di utf-8, e Python scrive il BOM per te. Lo snippet qui sotto lo mostra, e i byte che produce sono stati verificati: il file inizia con i tre byte del BOM, seguiti dai dati in semplice UTF-8.

with open("customers.csv", "w", encoding="utf-8-sig", newline="") as f:\n    f.write("name,city\n")\n    f.write("José García,München\n")\n# First bytes of the file: EF BB BF, then the UTF-8 data.\n# Excel now opens it correctly on double-click.

Due avvertenze prima di aggiungere un BOM ovunque. Primo, alcuni strumenti trattano un BOM come dati, non come un indicatore. Un parser CSV rigido potrebbe leggere la prima intestazione come BOM più nome invece che come nome, e questo rompe una ricerca per intestazione. Il convertitore di questa pagina scarica volutamente senza BOM proprio per questo motivo: il semplice UTF-8 è corretto per i caricamenti web, i database e Python, e il BOM è solo una comodità per il doppio clic in Excel. Quindi aggiungi un BOM alle copie destinate a Excel, non al file principale che alimenta altri strumenti. Secondo, un BOM non ripara un file che non è UTF-8. Se il file è stato scritto in Windows-1252, aggiungere un BOM sopra di esso peggiora le cose, perché Excel decodificherà allora i dati a un solo byte come UTF-8 e produrrà nuovi caratteri sballati. Aggiungi un BOM solo a un file che sai essere UTF-8, cosa che puoi confermare con il test dell'editor di testo della sezione sulla diagnosi.

Recupera un file che sembra già rovinato

Finora ogni soluzione ha dato per scontato che il file sul disco sia ancora corretto e che solo la visualizzazione sia sbagliata. Ma a volte la versione rovinata è già stata salvata, e la domanda diventa se i caratteri originali si possono ancora recuperare dalla copia salvata. La risposta dipende da cosa ha fatto esattamente il salvataggio, e ci sono due casi da distinguere. Nel primo caso, il file sul disco contiene ancora i byte UTF-8 originali, e solo la visualizzazione di Excel è sbagliata. Questo è il caso che il test dell'editor di testo individua: l'editor mostra i caratteri correttamente, quindi non si è perso nulla, e la Correzione 1 ripara la visualizzazione. Nel secondo caso, il file sul disco ora contiene i caratteri sbagliati stessi, perché qualcuno lo ha aperto in Excel, ha visto i caratteri sballati e lo ha salvato di nuovo in CSV, scrivendo i caratteri letti male dentro il file.

Il secondo caso spesso è ancora recuperabile, e il test è se i caratteri sballati seguono lo schema à della sezione sul decodificatore. Se il file salvato contiene letteralmente i caratteri é dove dovrebbe esserci é, il recupero è una ricodifica: leggi il file come se fosse Windows-1252, che recupera i byte UTF-8 originali, poi decodifica quei byte come UTF-8, che recupera i caratteri originali. Lo snippet qui sotto fa esattamente questo, ed è stato verificato su un file reale: un nome scritto come José, letto male come José, è tornato a essere José dopo il viaggio di andata e ritorno, byte per byte. Lavora su una copia, mai sull'unica versione, e controlla il risultato in un editor di testo prima di aprirlo di nuovo in Excel.

with open("mangled.csv", "r", encoding="cp1252") as f:\n    text = f.read()\n# Encode back to the bytes Excel misread, then decode as UTF-8.\nfixed = text.encode("cp1252").decode("utf-8")\nwith open("fixed.csv", "w", encoding="utf-8") as f:\n    f.write(fixed)\n# Verified: José -> José, München -> München.

Il trucco della ricodifica ha un limite rigido, ed è importante rispettarlo. Funziona solo quando i caratteri letti male sono sopravvissuti intatti al salvataggio, come é e i suoi compagni. Se il salvataggio ha sostituito i caratteri con punti interrogativi, oppure con il simbolo di sostituzione a rombo nero, l'informazione originale è sparita da quella copia. Nessuna decodifica può recuperare un carattere sostituito da un segnaposto, perché il segnaposto non porta nessuna informazione su quale carattere abbia sostituito. In quel caso, smetti di riparare la copia e rigenera il file dalla sua origine: esportalo di nuovo dal database, dallo strumento oppure dal JSON da cui proveniva, e questa volta aprilo con la Correzione 1 oppure dagli un BOM con la Correzione 2. E qualunque cosa tu faccia, tieni da parte la copia danneggiata finché il file rigenerato non risulta a posto. Cancellare l'unica copia prima di verificare la sostituzione è il modo in cui un problema recuperabile diventa un insieme di dati perso.

Cosa significa per i file del convertitore di questa pagina

Il convertitore di questa pagina produce esattamente il tipo di file di cui parla questa guida, quindi vale la pena di dichiarare il suo comportamento in modo chiaro. Lo scaricamento è semplice UTF-8 senza BOM. Questo è stato verificato sul codice reale, non dato per scontato: lo scaricamento crea un Blob text/csv con charset=utf-8 e non scrive nessuna marca iniziale, e il motore di conversione stesso è stato eseguito su un campione contenente José García, München, François, Łódź, São Paulo, un importo in euro, Tokyo in giapponese e nomi coreani, e ha prodotto ogni carattere in modo identico ai byte, senza BOM all'inizio dell'output. Quindi se il tuo file convertito mostra caratteri strani in Excel, la conversione non ha danneggiato nulla. Il file è UTF-8 corretto, ed Excel ha indovinato la codifica sbagliata al doppio clic.

Questo ti dà due opzioni pulite per i file convertiti. La prima è il percorso di importazione: apri il file scaricato con Dati e poi Da testo/CSV, imposta l'origine del file su 65001: Unicode (UTF-8) e carica. I caratteri si leggeranno correttamente, e non hai cambiato nulla del file, quindi resta valido per ogni altro strumento. La seconda è il percorso del BOM: apri il file scaricato nel Blocco note, salvalo come UTF-8 con BOM, e tieni quella copia per Excel, mentre tieni lo scaricamento originale per qualsiasi altra cosa. Non convertire di nuovo i dati per risolvere un problema di visualizzazione della codifica, e non far passare l'output convertito attraverso un foglio di calcolo per poi salvarlo di nuovo, perché quel viaggio di andata e ritorno può introdurre esattamente i problemi di delimitatore e di codifica che questa guida esiste per prevenire. Risolvi l'apertura, non i dati.

Un altro dettaglio del convertitore conta qui. Il convertitore ti permette di scegliere il delimitatore prima di scaricare, e quella scelta è indipendente dalla codifica. Un file può avere il delimitatore giusto e la visualizzazione di codifica sbagliata allo stesso tempo, oppure la codifica giusta e il delimitatore sbagliato, oppure entrambi sbagliati insieme. Se il tuo file convertito si apre in una sola colonna e i caratteri sembrano sbagliati, risolvi entrambe le impostazioni nella stessa importazione: scegli il delimitatore scelto al momento della conversione, e imposta l'origine del file su 65001. La guida compagna sul problema della colonna unica tratta la metà del delimitatore in dettaglio, ed è collegata nelle guide correlate qui sotto.

Lista di controllo per la prevenzione: esportalo bene così nessuno dovrà sistemarlo

I problemi di codifica sono un disaccordo tra chi scrive e chi legge, quindi la prevenzione significa far dichiarare a chi scrive cosa ha scritto, in un modo che il lettore rispetterà. Scorri questa lista di controllo quando produci un CSV, e la prossima persona che lo aprirà non avrà bisogno di questa guida. Primo, conosci la tua codifica al momento dell'esportazione. Se i tuoi dati contengono qualcosa oltre il semplice ASCII, esporta come UTF-8, e dillo nel nome del file oppure nella nota che viaggia con esso, perché un file CSV non può dirlo da solo. Secondo, se il pubblico è Excel su Windows, aggiungi un BOM alla copia per Excel, oppure esporta con il formato CSV UTF-8 da Salva con nome di Excel, che scrive un BOM per te. Terzo, se il file alimenta anche altri strumenti, tieni una copia in semplice UTF-8 senza BOM per loro, perché alcuni parser trattano un BOM come parte della prima intestazione.

Quarto, non salvare mai un file recuperato sopra l'originale finché non hai verificato il recupero in un editor di testo. Un salvataggio da Excel riscrive sia il delimitatore sia la codifica con le impostazioni predefinite di Excel, che possono reintrodurre il disaccordo per il lettore successivo, oppure trasformare un problema di visualizzazione in una vera perdita di dati. Quinto, quando ricevi un file, aprilo prima in un editor di testo se qualcosa sembra strano, e conferma la codifica prima di lasciare che un foglio di calcolo lo salvi sopra di esso. E sesto, conserva i dati di origine. Un CSV è un'istantanea appiattita, non i dati stessi, quindi se un recupero va storto, l'origine ti permette di esportare di nuovo in modo pulito invece di riparare una copia danneggiata. La maggior parte delle storie horror sulla codifica finisce con qualcuno che scopre troppo tardi che il CSV danneggiato era l'unica copia. Non lasciare che sia il tuo file.

Guide correlate

• Il file CSV si apre in un'unica colonna in Excel: perché succede e come correggerlo (Guida 2026) →
• Come posso convertire un file JSON in un file CSV online? (Guida 2026) →
• Quali sono i modi per convertire JSON in CSV in locale? 6 metodi a confronto (Guida 2026) →
• Perché Excel elimina gli zeri iniziali dai codici del tuo CSV e come conservarli (Guida 2026) →
• Perché Excel cambia le date del CSV e come mantenerle invariate (Guida 2026) →
• Perché salvare un CSV in Excel lo modifica e come tenere al sicuro l'originale (Guida 2026) →
• Perché Excel non apre il tuo file CSV troppo grande e cosa fare invece (Guida 2026) →

Domande frequenti