¡Resuelve completamente los problemas de codificación de caracteres CSV! Conocimiento fundamental de códigos de caracteres, BOM y finales de línea

La mayoría de los desarrolladores han experimentado abrir un archivo CSV solo para encontrar que contiene caracteres corrompidos. Particularmente con archivos CSV que contienen texto en japonés, los problemas surgen frecuentemente debido a diferencias en la codificación de caracteres. Este artículo consolida el conocimiento para entender fundamentalmente las causas de la corrupción de caracteres y proporcionar soluciones para resolverlas de manera confiable.

Conceptos Básicos de Codificación de Caracteres: <code>UTF-8</code> vs <code>Shift_JIS</code>

Las codificaciones de caracteres que causan problemas en archivos CSV en japonés son principalmente las siguientes dos:

UTF-8

El estándar web actual y una codificación de caracteres basada en Unicode capaz de manejar caracteres de todo el mundo. UTF-8 es el estándar en Linux, macOS y aplicaciones web modernas. Utiliza codificación de longitud variable de 1 a 4 bytes por carácter, con caracteres ASCII representados como un byte único.

Shift_JIS（CP932）

Un código de caracteres japonés utilizado en aplicaciones legacy de Windows y versiones antiguas de Excel. Para ser precisos, en entornos Windows se utiliza CP932 (extensión de Shift_JIS de Microsoft), y algunos caracteres dependientes de la plataforma (números circulados, números romanos, etc.) solo pueden manejarse con CP932.

Por qué ocurre la corrupción de caracteres

La causa raíz de la corrupción de caracteres es simple: la codificación de caracteres utilizada al escribir el archivo no coincide con la codificación utilizada al leerlo.

Por ejemplo, cuando una aplicación web exporta un CSV en UTF-8 y un usuario lo abre en Excel, los caracteres se corrompen. Esto se debe a que Excel interpreta el archivo como Shift_JIS (CP932) por defecto en entornos japoneses.

Función de BOM (Byte Order Mark)

La BOM es un marcador de varios bytes añadido al inicio de un archivo que indica la codificación de caracteres. La BOM UTF-8 tiene 3 bytes: <code>0xEF 0xBB 0xBF</code>.

El punto importante es que <strong>se requiere una BOM para abrir correctamente archivos CSV UTF-8 en Excel</strong>. Abrir un CSV UTF-8 sin BOM en Excel hará que se interprete como Shift_JIS, lo que resulta en caracteres distorsionados.

// PHP で BOM 付き UTF-8 CSV を出力する例
header('Content-Type: text/csv; charset=UTF-8');
header('Content-Disposition: attachment; filename="data.csv"');

// BOM を出力
echo "\xEF\xBB\xBF";

$fp = fopen('php://output', 'w');
fputcsv($fp, ['名前', 'メール', '部署']);
fputcsv($fp, ['田中太郎', 'tanaka@example.com', '開発部']);
fclose($fp);

# Python で BOM 付き UTF-8 CSV を出力する例
import csv

with open('data.csv', 'w', encoding='utf-8-sig', newline='') as f:
    writer = csv.writer(f)
    writer.writerow(['名前', 'メール', '部署'])
    writer.writerow(['田中太郎', 'tanaka@example.com', '開発部'])

Sin embargo, hay precauciones a tener en cuenta respecto a la BOM. Algunos programas y scripts de shell tratan la BOM como un carácter inválido, lo que puede causar errores. Es más seguro no incluir una BOM en los archivos CSV devueltos por respuestas de API o procesados por programas.

Problemas de Código de Salto de Línea

Junto con los caracteres garrapateados en CSV, un problema común es la diferencia en los códigos de final de línea.

• <strong>CRLF</strong> (<code>\r\n</code>) — Estándar de Windows
• <strong>LF</strong> (<code>\n</code>) — Estándar de Linux / macOS
• <strong>CR</strong> (<code>\r</code>) — Mac OS heredado (raramente usado hoy en día)

RFC 4180 especifica que los saltos de línea en CSV deben ser CRLF. Sin embargo, en la práctica, muchas herramientas pueden manejar archivos CSV con solo LF sin problemas. Los problemas son más probables con Excel y algunos sistemas heredados.

Las herramientas de línea de comandos son convenientes para verificar los códigos de salto de línea.

# file コマンドで確認
file data.csv
# 出力例: data.csv: UTF-8 Unicode (with BOM) text, with CRLF line terminators

# xxd で先頭バイトを確認（BOM の有無）
xxd data.csv | head -3

Gráfico de solución práctica

A continuación se resume la configuración óptima según el uso previsto del CSV.

Archivo CSV de prueba

Para verificar que su aplicación maneja correctamente archivos CSV con diversas codificaciones de caracteres, utilice los archivos de prueba disponibles en DevLab.

• <a href="/ja/files/encoding/">Archivos CSV de prueba por codificación de caracteres</a> — UTF-8 (con/sin BOM), Shift_JIS, EUC-JP y más
• <a href="/ja/files/newline/">Archivos de prueba por código de salto de línea</a> — Diversos archivos CRLF, LF y CR
• <a href="/ja/files/csv/">Lista de archivos de prueba CSV</a> — Archivos CSV de varios tamaños

Resumen

Los problemas de codificación de caracteres en CSV se pueden resolver de manera confiable comprendiendo correctamente tres elementos clave: codificación de caracteres, BOM (Marca de Orden de Byte) y terminaciones de línea. Para Excel, el estándar es UTF-8 con BOM usando terminaciones de línea CRLF; para procesamiento programático, use UTF-8 sin BOM usando terminaciones de línea LF. Usando varios archivos de prueba de DevLab, verifique que su aplicación maneje correctamente cada patrón.