Dati e fogli di calcolo · CSV Pulitore
Come si confondono UTF-8 e Windows-1252: riparare un Mojibake CSV Esporta
· Come funziona
csv codifica pulizia dei dati
Quando 'José' diventa 'José', i byte vanno bene e l'interpretazione è sbagliata. Questo post spiega come le due codifiche più comuni entrano in collisione, come riconoscere i sintomi e come la ricodifica li ripara.
Nomi accentati e virgolette graffe trasformati in una zuppa di simboli: gli schemi rivelatori di un file UTF-8 vengono letti come Windows-1252 e il contrario
Un nome cliente che diventa rombi sostitutivi dopo il caricamento non è una prova che CSV Cleaner abbia rilevato la codepage legacy errata. La configurazione dice il contrario: viene compreso solo UTF-8 e un file Windows-1252 o Shift-JIS viene letto come UTF-8. Le sequenze di byte non valide possono quindi già essere sostituite prima che il parser CSV veda i caratteri.
La struttura è incentrata su mojibake familiari come José, ma il percorso di lettura del browser utilizza `File.text()` e non fornisce alcun selettore di codifica. Questo articolo corregge quella promessa. Il sintomo utilizzabile all'interno di questo strumento è la sostituzione di caratteri o testo danneggiato in altro modo, con i byte del file originale conservati per il ripristino altrove.
Un file nonUTF-8 raggiunge questo strumento come caratteri sostitutivi, non come modello mojibake verificato
Un file delimitato è costituito da byte sul disco, mentre il parser opera su una stringa JavaScript. Una codifica definisce la mappatura tra questi livelli. La sintassi CSV nomina virgole, virgolette e limiti di record ma non contiene alcuna dichiarazione su disco affidabile che indichi a `File.text()` quale mappatura legacy ha creato ogni byte nonASCII.
Una volta che la decodifica ha prodotto i caratteri sostitutivi U+FFFD, le operazioni CSV successive ricevono tali segnaposto come testo normale. Il taglio o l'esportazione non possono dedurre quale sequenza di byte o carattere originale vi apparteneva. Ecco perché la fonte intatta conta più di un elenco di ricerca e sostituzione assemblato dal display danneggiato.
I due soliti sospetti: le sequenze multibyte di UTF-8 e i byte singoli di Windows-1252 e il motivo per cui producono spazzatura prevedibile quando vengono scambiati
UTF-8 rappresenta caratteri nonASCII con sequenze multibyte. Windows-1252 assegna molti caratteri occidentali a singoli valori di byte. Leggere una convenzione sotto un'altra può fallire o creare testo fuorviante, ma questo percorso non testa decodificatori alternativi, non valuta un linguaggio plausibile né offre una selezione Windows-1252.
L'unico comportamento del parser specifico della codifica è la rimozione del segno di ordine dei byte U+FEFF UTF-8 iniziale dopo la decodifica del testo. Ciò impedisce al marcatore di unirsi alla prima intestazione. Non si tratta di un rilevamento della codifica generale e non fornisce supporto per Shift-JIS, UTF-16 o pagine di codici regionali menzionate da nessuna parte nell'implementazione.
ToolAcre accetta testo UTF-8 e non confronta i candidati Windows-1252
I caratteri sostitutivi indicano che il decodificatore di testo non è riuscito a mappare alcuni byte di input secondo l'interpretazione scelta. I punti interrogativi potrebbero essere stati inseriti da una precedente esportazione con perdita, nel qual caso il carattere originale potrebbe già non essere disponibile. Una sequenza à riconoscibile può verificarsi in altri flussi di lavoro, ma questa pagina non ne diagnostica la cronologia.
Non decidere la codifica della fonte da un solo cognome. Controlla le impostazioni dell'applicazione di esportazione, la provenienza del file e un ispettore in grado di riconoscere i byte che lascia intatta la fonte. Gli avvisi di riga del pulitore riguardano la chiusura delle virgolette e la larghezza della colonna; non sono la prova che la codifica dei caratteri sia corretta.
Ricodifica, non trova e sostituisci: perché la soluzione è leggere i byte con la codifica corretta e scrivere UTF-8, anziché applicare patch ai caratteri uno per uno
La riparazione affidabile consiste nel tornare ai byte originali e decodificarli una volta con la codifica sorgente documentata, quindi scrivere UTF-8. Tale operazione deve essere eseguita prima dell'apertura tramite un percorso di solo testo UTF-8. La sostituzione dei frammenti visibili dopo la decodifica può corrompere le occorrenze legittime e non è in grado di distinguere diversi caratteri originali compressi in un segnaposto.
CSV Cleaner non ha alcun controllo di ricodifica a livello di byte, quindi non può eseguire la conversione promessa dalla struttura. Utilizza un metodo di conversione attendibile in grado di riconoscere l'origine, confronta i nomi rappresentativi con il sistema di origine, quindi porta qui il risultato UTF-8 per delimitatore, virgolette, spazi bianchi e lavoro duplicato.
Recupera dai byte originali all'esterno di questo strumento; la sostituzione dei caratteri qui non può ripristinarli
Per una dimostrazione sicura, crea un piccolo file con codifica legacy contenente un nome accentato e conserva una copia esadecimale. Caricalo nello strumento e osserva se compaiono caratteri sostitutivi. Questa osservazione stabilisce il confine UTF-8; non stabilisce la tabella codici originale semplicemente perché il nome previsto è noto.
Successivamente converti i byte non toccati con un decoder selezionato esplicitamente all'esterno di ToolAcre, salva UTF-8 e carica il risultato. Il nome ora dovrebbe arrivare intatto mentre il parser CSV gestisce normalmente i separatori. Confrontando questi due percorsi si insegna la lezione giusta senza affermare che è stato l'addetto alle pulizie a eseguire il ripristino da solo.
Esempio realizzato: dimostrare il limite UTF-8 senza richiedere una riparazione non supportata
Un file con doppia codifica potrebbe richiedere la ricostruzione di una trasformazione precedente e i dati già salvati con punti interrogativi letterali potrebbero essere irrecuperabili senza un'altra fonte. Questo articolo non prescrive un'inversione universale perché l'implementazione non contiene cronologia di codifica o funzione di ripristino con conservazione dei byte.
Evita inoltre di rivendicare il supporto per UTF-16, codifiche dell'Asia orientale o moduli di normalizzazione. Se sono importanti, scegli un convertitore che li nomina e li testa. Un'analisi CSV riuscita dimostra solo che la macchina a stati delimitatrice ha trovato le righe; non dice nulla sul fatto che la decodificazione dei caratteri prima di quella fase fosse fedele.
Correggi l'interpretazione una volta: in che modo la riparazione della codifica di ToolAcre CSV Cleaner decodifica e ricodifica l'esportazione sul tuo dispositivo
ToolAcre può eliminare un UTF-8 BOM iniziale e serializzare la stringa risultante come UTF-8 CSV attraverso il percorso di download del browser. Non può trasformare byte legacy arbitrari in Unicode corretto perché tali byte hanno già oltrepassato il limite fisso di lettura del testo del browser senza un decodificatore selezionato dall'utente.
Tratta i segni di sostituzione come un segnale di stop. Conserva la fonte, identifica la sua codifica dal produttore, convertila una volta con uno strumento appropriato in grado di riconoscere i byte e verifica i nomi importanti. Solo allora utilizza CSV Cleaner per i lavori strutturali che la sua configurazione effettivamente promette.