Datos y hojas de cálculo · CSV Limpiador
Cómo se confunden UTF-8 y Windows-1252: reparar una exportación Mojibake CSV
· Cómo funciona
csv codificación limpieza de datos
Cuando 'José' se convierte en 'José', los bytes están bien y la interpretación es incorrecta. Esta publicación explica cómo chocan las dos codificaciones más comunes, cómo reconocer los síntomas y cómo la redecodificación los repara.
Nombres acentuados y comillas rizadas convertidas en sopa de símbolos: los patrones reveladores de un archivo UTF-8 leídos como Windows-1252, y al revés
Un nombre de cliente que se convierte en diamantes de reemplazo después de la carga no es evidencia de que CSV Cleaner detectó la página de códigos heredada incorrecta. La configuración dice lo contrario: solo se entiende UTF-8 y un archivo Windows-1252 o Shift-JIS se lee como UTF-8. Por lo tanto, las secuencias de bytes no válidas ya se pueden reemplazar antes de que el analizador CSV vea los caracteres.
El esquema se centró en mojibake familiar como José, pero la ruta de lectura del navegador usa `File.text()` y no proporciona ningún selector de codificación. Este artículo corrige esa promesa. El síntoma procesable dentro de esta herramienta es el reemplazo de caracteres o texto dañado, con los bytes del archivo original conservados para su recuperación en otro lugar.
Un archivo que no es UTF-8 llega a esta herramienta como caracteres de reemplazo, no como un patrón mojibake verificado
Un archivo delimitado son bytes en el disco, mientras que el analizador opera en una cadena de JavaScript. Una codificación define el mapeo entre esas capas. La sintaxis de CSV nombra comas, comillas y límites de registros, pero no incluye ninguna declaración confiable en el disco que indique a `File.text()` qué asignación heredada creó cada byte no ASCII.
Una vez que la decodificación ha producido caracteres de reemplazo U+FFFD, las operaciones posteriores CSV reciben esos marcadores de posición como texto normal. Recortar o exportar no puede inferir qué secuencia de bytes o carácter original pertenecía allí. Es por eso que la fuente intacta es más importante que una lista de búsqueda y reemplazo recopilada a partir de la pantalla dañada.
Los dos sospechosos habituales: las secuencias multibyte de UTF-8 y los bytes únicos de Windows-1252, y por qué producen basura predecible cuando se intercambian
UTF-8 representa caracteres no ASCII con secuencias multibyte. Windows-1252 asigna muchos caracteres occidentales a valores de bytes individuales. Leer una convención bajo otra puede fallar o crear texto engañoso, pero esta ruta no prueba descodificadores alternativos, no califica lenguaje plausible ni ofrece una selección de Windows-1252.
El único comportamiento del analizador específico de codificación es la eliminación de una marca de orden de bytes U+FEFF UTF-8 inicial después de la decodificación del texto. Eso impide que el marcador se sume al primer cabezazo. No es una detección de codificación general y no proporciona soporte para Shift-JIS, UTF-16 o páginas de códigos regionales que no se mencionan en ninguna parte de la implementación.
ToolAcre acepta texto UTF-8 y no compara candidatos de Windows-1252
Los caracteres de reemplazo indican que el decodificador de texto no pudo asignar algunos bytes de entrada según la interpretación elegida. Es posible que se hayan insertado signos de interrogación en una exportación anterior con pérdida, en cuyo caso es posible que el carácter original ya no esté disponible. Puede surgir una secuencia à reconocible en otros flujos de trabajo, pero esta página no diagnostica su historial.
No decida la codificación fuente a partir de un solo apellido. Verifique la configuración de la aplicación de exportación, la procedencia del archivo y un inspector con reconocimiento de bytes que deja la fuente intacta. Las advertencias de fila del limpiador se refieren al cierre de comillas y al ancho de columna; no son evidencia de que la codificación de caracteres sea correcta.
Redecodificar, no buscar y reemplazar: por qué la solución es leer los bytes con la codificación correcta y escribir UTF-8, en lugar de parchear los caracteres uno por uno
La reparación confiable es volver a los bytes originales y decodificarlos una vez con la codificación fuente documentada, luego escribir UTF-8. Esa operación debe realizarse antes de abrir a través de una ruta de texto de solo UTF-8. Reemplazar fragmentos de basura visibles después de la decodificación puede dañar ocurrencias legítimas y no puede distinguir varios caracteres originales que se colapsaron en un marcador de posición.
CSV Cleaner no tiene control de recodificación a nivel de bytes, por lo que no puede realizar la conversión prometida del esquema. Utilice un método de conversión confiable que tenga en cuenta la fuente, compare los nombres representativos con el sistema fuente y luego traiga el resultado UTF-8 aquí para delimitadores, comillas, espacios en blanco y trabajo duplicado.
Recuperar de los bytes originales fuera de esta herramienta; El reemplazo de personajes aquí no puede restaurarlos.
Para una demostración segura, cree un pequeño archivo codificado heredado que contenga un nombre acentuado y conserve una copia hexadecimal. Cárguelo en la herramienta y observe si aparecen caracteres de reemplazo. Esa observación establece el límite UTF-8; no establece la página de códigos original simplemente porque se conoce el nombre esperado.
Luego convierta los bytes intactos con un decodificador seleccionado explícitamente fuera de ToolAcre, guarde UTF-8 y cargue ese resultado. El nombre ahora debería llegar intacto mientras el analizador CSV maneja los separadores normalmente. Comparar estos dos caminos enseña la lección correcta sin afirmar que el limpiador realizó la recuperación por sí mismo.
Ejemplo resuelto: demostrar el límite UTF-8 sin reclamar una reparación no respaldada
Un archivo con doble codificación puede requerir la reconstrucción de una transformación anterior, y los datos ya guardados con signos de interrogación literales pueden ser irrecuperables sin otra fuente. Este artículo no prescribe una reversión universal porque la implementación no contiene historial de codificación ni función de recuperación de preservación de bytes.
También evita reclamar soporte para UTF-16, codificaciones de Asia Oriental o formularios de normalización. Si eso es importante, elija un convertidor que los nombre y los pruebe. Un análisis CSV exitoso solo prueba que la máquina de estado delimitadora encontró filas; no dice nada sobre si la decodificación de caracteres antes de esa etapa era fiel.
Corrija la interpretación una vez: cómo la reparación de codificación del limpiador ToolAcre CSV redecodifica y codifica la exportación en su dispositivo
ToolAcre puede eliminar una lista de materiales UTF-8 principal y serializar la cadena resultante como UTF-8 CSV a través de la ruta de descarga del navegador. No puede convertir bytes heredados arbitrarios en Unicode correcto porque esos bytes ya han cruzado el límite fijo de lectura de texto del navegador sin un decodificador seleccionado por el usuario.
Trate las marcas de reemplazo como una señal de alto. Conserve la fuente, identifique su codificación del productor, convierta una vez con una herramienta adecuada de bytes y verifique los nombres importantes. Sólo entonces utilice CSV Cleaner para los trabajos estructurales que su configuración realmente promete.