Dados e planilhas · CSV Limpador
Como UTF-8 e Windows-1252 ficam confusos: consertando uma exportação de Mojibake CSV
· Como funciona
csv codificação limpeza de dados
Quando 'José' se torna 'José', os bytes estão corretos e a interpretação está errada. Esta postagem explica como as duas codificações mais comuns colidem, como reconhecer os sintomas e como a recodificação os repara.
Nomes acentuados e aspas curvas se transformaram em sopa de símbolos - os padrões reveladores de um arquivo UTF-8 lidos como Windows-1252 e vice-versa
Um nome de cliente que se torna diamantes de substituição após o carregamento não é evidência de que CSV Cleaner detectou a página de código herdada errada. A configuração diz o contrário: apenas UTF-8 é compreendido e um arquivo Windows-1252 ou Shift-JIS é lido como UTF-8. Sequências de bytes inválidas já podem ser substituídas antes que o analisador CSV veja os caracteres.
O esboço centrava-se em mojibake familiar, como José, mas o caminho de leitura do navegador usa `File.text()` e não fornece seletor de codificação. Este artigo corrige essa promessa. O sintoma acionável dentro desta ferramenta é a substituição de caracteres ou texto danificado, com os bytes do arquivo original preservados para recuperação em outro lugar.
Um arquivo não UTF-8 chega a esta ferramenta como caracteres de substituição, não como um padrão mojibake verificado
Um arquivo delimitado são bytes no disco, enquanto o analisador opera em uma string JavaScript. Uma codificação define o mapeamento entre essas camadas. A sintaxe CSV nomeia vírgulas, aspas e limites de registro, mas não carrega nenhuma declaração confiável no disco informando a `File.text()` qual mapeamento legado criou cada byte não ASCII.
Depois que a decodificação produziu caracteres de substituição U+FFFD, as operações CSV posteriores recebem esses espaços reservados como texto comum. O corte ou a exportação não podem inferir qual sequência de bytes ou caractere original pertencia a ele. É por isso que a fonte intacta é mais importante do que uma lista de localização e substituição montada a partir da tela danificada.
Os dois suspeitos usuais - sequências multibyte de UTF-8 e bytes únicos de Windows-1252, e por que eles produzem lixo previsível quando trocados
UTF-8 representa caracteres não ASCII com sequências multibyte. Windows-1252 atribui muitos caracteres ocidentais a valores de bytes individuais. A leitura de uma convenção sob outra pode falhar ou criar texto enganoso, mas esta rota não testa decodificadores alternativos, pontua linguagem plausível ou oferece uma seleção Windows-1252.
O único comportamento do analisador específico de codificação é a remoção de uma marca de ordem de byte U+FEFF UTF-8 inicial após a decodificação do texto. Isso evita que o marcador se junte ao primeiro cabeçalho. Não é uma detecção de codificação geral e não fornece suporte para Shift-JIS, UTF-16 ou páginas de código regionais mencionadas em nenhum lugar da implementação.
ToolAcre aceita texto UTF-8 e não compara candidatos Windows-1252
Caracteres de substituição indicam que o decodificador de texto não conseguiu mapear alguns bytes de entrada sob a interpretação escolhida. Os pontos de interrogação podem ter sido inseridos por uma exportação anterior com perdas e, nesse caso, o caractere original já poderia estar indisponível. Uma sequência à reconhecível pode surgir em outros fluxos de trabalho, mas esta página não diagnostica seu histórico.
Não decida a codificação de origem apenas com base em um sobrenome. Verifique a configuração do aplicativo de exportação, a origem do arquivo e um inspetor com reconhecimento de bytes que deixa a fonte intacta. Os avisos de linha do limpador dizem respeito ao fechamento da cotação e à largura da coluna; eles não são evidências de que a codificação de caracteres esteja correta.
Redecodificar, não localizar e substituir - por que a solução é ler os bytes com a codificação correta e escrever UTF-8, em vez de corrigir os caracteres um por um
O reparo confiável é retornar aos bytes originais e decodificá-los uma vez com a codificação de origem documentada e, em seguida, escrever UTF-8. Essa operação deve ocorrer antes de abrir por meio de um caminho de texto somente UTF-8. A substituição de fragmentos de lixo visíveis após a decodificação pode corromper ocorrências legítimas e não pode distinguir vários caracteres originais que foram recolhidos em um espaço reservado.
CSV Cleaner não tem controle de redecodificação em nível de byte, portanto, não pode realizar a conversão prometida do esboço. Use um método de conversão confiável com reconhecimento de fonte, compare nomes representativos com o sistema de origem e, em seguida, traga o resultado UTF-8 aqui para delimitador, cotação, espaço em branco e trabalho duplicado.
Recuperar dos bytes originais fora desta ferramenta; a substituição de caracteres aqui não pode restaurá-los
Para uma demonstração segura, crie um pequeno arquivo codificado herdado contendo um nome acentuado e guarde uma cópia hexadecimal. Carregue-o na ferramenta e observe se aparecem caracteres de substituição. Essa observação estabelece o limite UTF-8; ela não estabelece a página de código original apenas porque o nome esperado é conhecido.
Em seguida, converta os bytes intocados com um decodificador explicitamente selecionado fora de ToolAcre, salve UTF-8 e carregue esse resultado. O nome agora deve chegar intacto enquanto o analisador CSV trata os separadores normalmente. Comparar esses dois caminhos ensina a lição certa, sem afirmar que o próprio limpador executou a recuperação.
Exemplo resolvido: demonstre o limite UTF-8 sem reivindicar um reparo não suportado
Um arquivo com codificação dupla pode exigir a reconstrução de uma transformação anterior, e os dados já salvos com pontos de interrogação literais podem ser irrecuperáveis sem outra fonte. Este artigo não prescreve uma reversão universal porque a implementação não contém histórico de codificação ou função de recuperação de preservação de bytes.
Também evita reivindicar suporte para UTF-16, codificações do Leste Asiático ou formulários de normalização. Se isso for importante, escolha um conversor que os nomeie e teste. Uma análise CSV bem-sucedida apenas prova que a máquina de estado do delimitador encontrou linhas; não diz nada sobre se a decodificação de caracteres antes desse estágio era fiel.
Corrija a interpretação uma vez - como o reparo de codificação do limpador ToolAcre CSV recodifica e recodifica a exportação em seu dispositivo
ToolAcre pode remover um UTF-8 BOM inicial e serializar a string resultante como UTF-8 CSV por meio do caminho de download do navegador. Ele não pode transformar bytes herdados arbitrários em Unicode correto porque esses bytes já cruzaram o limite fixo de leitura de texto do navegador sem um decodificador selecionado pelo usuário.
Trate as marcas de substituição como um sinal de parada. Preserve a fonte, identifique sua codificação do produtor, converta uma vez com uma ferramenta apropriada com reconhecimento de bytes e verifique nomes importantes. Só então use o CSV Cleaner para os trabalhos estruturais que sua configuração realmente promete.