Ho cercato di trovare una soluzione / spiegazione ragionevole (senza esito positivo) per scoprire perché Excel utilizza per impostazione predefinita la rimozione della distinta componenti quando si salva un file nel tipo CSV.
Per favore, perdonami se trovi questo un duplicato di questa domanda. Questo gestisce la lettura di file CSV con codifica non ASCII, ma non copre il salvataggio del file (che è dove si trova il problema più grande).
Ecco la mia situazione attuale (che ho intenzione di raccogliere è comune tra i software localizzati che si occupano di caratteri Unicode e un formato CSV):
Esportiamo i dati in un formato CSV utilizzando UTF-16LE, assicurandoci che la DBA sia impostata (0xFFFE). Convalidiamo dopo che il file è stato generato con un editor esadecimale per assicurarci che sia stato impostato correttamente.
Apri il file in Excel (per questo esempio stiamo esportando caratteri giapponesi) e testimonia che Excel gestisce il caricamento del file con la codifica corretta.
I tentativi di salvare questo file ti chiederanno un messaggio di avviso che indica che il file potrebbe contenere funzionalità che potrebbero non essere compatibili con la codifica Unicode, ma ti chiederà se desideri comunque salvare.
Se si seleziona la finestra di dialogo Salva con nome, verrà immediatamente richiesto di salvare il file come "Testo Unicode" anziché CSV. Se selezioni l'estensione "CSV" e salvi il file rimuove la DBA (ovviamente insieme a tutti i caratteri giapponesi).
Perché dovrebbe succedere? Esiste una soluzione a questo problema o si tratta di un "bug" / limitazione noto di Excel?
Inoltre (come problema secondario) sembra che Excel, durante il caricamento di file CSV codificati UTF-16LE, utilizzi solo i delimitatori TAB. Ancora una volta, si tratta di un altro "bug" / limitazione noto di Excel?