Codificacion de caracteres explicada: de ASCII a UTF-8
Por que tu texto a veces se convierte en signos de interrogacion y simbolos raros. Guia practica de codificacion de caracteres.
Abres un archivo y ves ü en lugar de u. O una base de datos devuelve ???? donde deberia estar el nombre de alguien. O llega un email con =?UTF-8?B? esparcido por el asunto.
Bienvenido al maravilloso mundo de los problemas de codificacion de caracteres.
La historia corta
Los ordenadores almacenan numeros, no letras. Asi que alguien tuvo que decidir que numero significa que letra. En los anos 60, ASCII asigno los numeros 0-127 a las letras inglesas, digitos y simbolos basicos. La letra "A" es 65. Un espacio es 32. Simple.
Pero ASCII solo cubre 128 caracteres. Funciona para el ingles. No funciona para las tildes espanolas, los kanji japoneses, la escritura arabe o los miles de otros caracteres que los humanos realmente usan.
El caos antes de Unicode
Diferentes regiones inventaron sus propias codificaciones. Europa occidental tuvo ISO-8859-1. Japon tuvo Shift-JIS. Rusia tuvo KOI8-R. China tuvo GB2312. Cada una funcionaba bien dentro de su ecosistema. En cuanto las mezcabas, todo se rompia.
Un archivo guardado con una codificacion y abierto con otra produce mojibake -- esa mezcla incomprensible de caracteres incorrectos que probablemente ya has visto. cafe se convierte en café cuando un archivo UTF-8 se lee como ISO-8859-1.
Unicode resolvio el problema de mapeo
Unicode le dio a cada caracter un numero unico (llamado "punto de codigo"). La A latina es U+0041. El muneco de nieve es U+2603. Cada emoji, cada sistema de escritura, cada simbolo matematico tiene su propio punto de codigo. Mas de 150.000 caracteres y creciendo.
Pero Unicode es solo el mapeo. No dice como almacenar esos numeros como bytes. Eso es trabajo de la codificacion.
UTF-8: La codificacion que gano
UTF-8 es la forma en que la mayor parte de Internet almacena texto Unicode. Su truco clave: usa un numero variable de bytes por caracter.
- Caracteres ASCII (letras inglesas, digitos): 1 byte cada uno
- Caracteres europeos con acento: 2 bytes cada uno
- Caracteres asiaticos (CJK): 3 bytes cada uno
- Emojis y simbolos raros: 4 bytes cada uno
Esto significa que el texto en ingles en UTF-8 es identico a ASCII. Los sistemas antiguos no se rompen. Pero aun puedes representar cualquier caracter del mundo.
Actualmente, mas del 98% de los sitios web usan UTF-8. La guerra de codificaciones termino, y UTF-8 gano.
UTF-8 vs UTF-16 vs UTF-32
UTF-8: Ancho variable (1-4 bytes). Eficiente para texto mayormente en ingles. Estandar web.
UTF-16: Ancho variable (2 o 4 bytes). Usado internamente por JavaScript, Java y Windows. Cada caracter ocupa al menos 2 bytes, asi que es menos eficiente para texto ASCII.
UTF-32: Ancho fijo (4 bytes por caracter). Simple pero despilfarrador. Rara vez usado para almacenamiento o transmision.
El string.length de JavaScript cuenta unidades de codigo UTF-16, no caracteres. Por eso "😀".length devuelve 2, no 1.
Cuando la codificacion falla
Leer un archivo con la codificacion incorrecta. Los bytes estan bien, pero se interpretan mal. Solucion: especificar la codificacion correcta al abrir.
Desajuste de charset en la base de datos. Tu app envia UTF-8, pero la columna de la base de datos esta configurada como latin1. Los caracteres fuera de ASCII se corrompen. Solucion: configura tu base de datos en utf8mb4 (no solo utf8 en MySQL, que solo maneja caracteres de 3 bytes).
Falta el header charset en HTTP. Si el servidor no envia Content-Type: text/html; charset=utf-8, los navegadores tienen que adivinar. A veces adivinan mal.
Consejos practicos
Usa siempre UTF-8. A menos que tengas una razon muy especifica, UTF-8 es la eleccion correcta para todo.
Declara tu codificacion explicitamente. En HTML: <meta charset="utf-8">. En HTTP: Content-Type: text/html; charset=utf-8. No dejes que los sistemas adivinen.
Cuidado con la longitud de strings. En JavaScript, el conteo de caracteres se complica con emojis y caracteres combinados. Usa Array.from(str).length o la API Intl.Segmenter para conteos precisos.
Atencion al BOM. El Byte Order Mark (U+FEFF) a veces aparece al inicio de archivos UTF-8. Es invisible pero puede romper parsers. Algunos editores lo agregan silenciosamente.
La codificacion de caracteres no es emocionante, pero entenderla ahorra horas de depuracion. Usa UTF-8 en todas partes, declaralo explicitamente, y cuando veas texto corrupto, sabras exactamente donde buscar.