Guide
Codificación de caracteres es un tutorial interactivo de 14 niveles que responde a varias preguntas que aparecen una y otra vez en el desarrollo y casi nadie explica bien: ¿cuántos bytes ocupa un carácter chino? ¿Por qué "😀".length es 2? ¿Para qué sirve el = del final de un Base64? ¿Y si el texto ilegible es un archivo roto o tiene arreglo? Cada nivel te da un texto de pruebas (puedes cambiarlo como quieras) y varias vistas: los bits, los bytes y el punto de código de cada carácter, el desglose byte a byte de UTF-8, los grupos de 6 bits de Base64, la codificación por ciento de las URL y «qué se ve si se interpreta con otra codificación». El objetivo es leer un número, escribir una cadena hexadecimal o introducir un carácter que cumpla una condición, y el evaluador responde al momento.
Actualizado el 2026-09-095 sources15 min read
Codificación de caracteres es un tutorial interactivo de 14 niveles que responde a varias preguntas que aparecen una y otra vez en el desarrollo y casi nadie explica bien: ¿cuántos bytes ocupa un carácter chino? ¿Por qué "😀".length es 2? ¿Para qué sirve el = del final de un Base64? ¿Y si el texto ilegible es un archivo roto o tiene arreglo? Cada nivel te da un texto de pruebas (puedes cambiarlo como quieras) y varias vistas: los bits, los bytes y el punto de código de cada carácter, el desglose byte a byte de UTF-8, los grupos de 6 bits de Base64, la codificación por ciento de las URL y «qué se ve si se interpreta con otra codificación». El objetivo es leer un número, escribir una cadena hexadecimal o introducir un carácter que cumpla una condición, y el evaluador responde al momento.
El orden del curso sigue la historia de la codificación: bits y bytes → los 128 acuerdos de ASCII → Unicode numerando cada carácter → cómo UTF-8 convierte ese número en 1 a 4 bytes → UTF-16 y la longitud de las cadenas de JavaScript → Base64 metiendo bytes en texto plano → codificación URL → y los dos últimos niveles dedicados al mojibake: cómo se produce y cómo pasar de 浣犲ソ a 你好.
Se completa en unos 40 minutos. Para desarrolladores de front-end y back-end, gente que procesa datos y cualquiera que se haya peleado con caracteres ilegibles, Base64 o la longitud de un emoji; solo hace falta saber contar en binario.
%XX; «Interpretado con otra codificación» enseña la misma cadena de bytes leída como GBK, Latin-1 o UTF-16.?lesson=n lleva directo a un nivel.Arriba está el curso completo: cambia el texto, lee las vistas y responde.
El nivel 6, «UTF-8 de dos bytes», usa café como muestra y pide escribir los dos bytes de é:
El nivel 14, «Deducir el mojibake», parte del texto ilegible 浣犲ソ (leído como GBK) y pide encontrar el original en el texto de pruebas:
Carácter Punto de código Código en binario Plantilla UTF-8 Bytes
c U+0063 1100011 0xxxxxxx 63
a U+0061 1100001 0xxxxxxx 61
f U+0066 1100110 0xxxxxxx 66
é U+00E9 000 1110 1001 110xxxxx 10xxxxxx C3 A9
→ 11 bits de carga 00011 101001 a la plantilla → 11000011 10101001
Respuesta C3 A9 ✓Texto 中文 Bytes UTF-8 E4 B8 AD E6 96 87 Leído como GBK → 涓枃
Texto 你好 Bytes UTF-8 E4 BD A0 E5 A5 BD Leído como GBK → 浣犲ソ ← coincide con el enunciado
Respuesta 你好 ✓El ordenador solo tiene 0 y 1. Un bit es un interruptor; 8 bits forman un byte y con ellos se representan valores distintos. Sumar los pesos de cada posición convierte el binario en decimal: 01000001 = 64 + 1 = 65. Todo texto es, al final, una cadena de bytes; una «codificación de caracteres» es una tabla que dice qué número representa a qué carácter, y cada tabla distinta es una codificación distinta.
El ASCII de 1963 definió 128 caracteres con 7 bits: de 0 a 31 son caracteres de control como el salto de línea, el tabulador o el timbre; de 48 a 57 están las cifras 0–9; de 65 a 90, las mayúsculas; y de 97 a 122, las minúsculas. La tabla no está puesta al azar: mayúsculas y minúsculas solo se diferencian en 32 (el sexto bit), así que c | 0x20 convierte una mayúscula en minúscula, y a un carácter de cifra le basta restarle 48 para obtener el valor. El hexadecimal es la forma habitual de leer bytes, dos dígitos por byte: 0x48 0x69 = Hi. ASCII solo usa 7 bits y deja el octavo libre; cada país lo fue rellenando a su manera (Latin-1, GBK, Shift_JIS…), de forma incompatible entre sí: ahí está la raíz histórica del mojibake.
Unicode asigna un número único a los caracteres de todo el mundo, el punto de código, escrito como U+ más hexadecimal: A es U+0041, 中 es U+4E2D y 😀 es U+1F600. El espacio va de U+0000 a U+10FFFF y se divide en 17 «planos»; los caracteres habituales están casi todos en el plano básico (U+0000–U+FFFF), y los emoji y los ideogramas poco frecuentes, en los planos suplementarios. La clave: el punto de código es solo un número; en qué bytes se convierte lo deciden las «formas de codificación» UTF-8, UTF-16 o UTF-32. Unicode no es una codificación: utf-8 sí.
UTF-8 (RFC 3629) representa un punto de código con 1 a 4 bytes y todas las reglas van escritas en el prefijo del primer byte:
| Rango de puntos de código | Bytes | Plantilla | Bits de carga |
|---|---|---|---|
| U+0000–U+007F | 1 | 0xxxxxxx |
7 |
| U+0080–U+07FF | 2 | 110xxxxx 10xxxxxx |
11 |
| U+0800–U+FFFF | 3 | 1110xxxx 10xxxxxx 10xxxxxx |
16 |
| U+10000–U+10FFFF | 4 | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |
21 |
Se rellena con ceros a la izquierda el binario del punto de código hasta el número de bits de carga y se van rellenando las x en orden: eso da los bytes. é = U+00E9 = 11101001; hasta 11 bits queda 00011 101001, y al meterlo en la plantilla de dos bytes sale 11000011 10101001 = C3 A9.
Este diseño tiene tres ventajas: el texto ASCII no cambia ni un byte al codificarse en UTF-8 (compatibilidad total hacia atrás); cualquier byte siguiente empieza por 10, así que desde cualquier punto del flujo se puede encontrar el inicio del carácter siguiente (autosincronía: perder un byte no descoloca todo lo demás); y las codificaciones de distinta longitud no se solapan, de modo que un byte cero como 00 siempre representa U+0000 (seguridad para las cadenas de C). El precio es que cada carácter chino ocupa 3 bytes, un 50 % más que los 2 de GBK; pero el inglés, los signos de puntuación y el código no se ven afectados, y por eso UTF-8 es hoy la codificación de más del 98 % de las páginas web.
Los niveles 7 y 8 piden introducir a mano un carácter de 3 bytes y otro de 4. Este último revela una trampa que sigue muy viva: el conjunto de caracteres utf8 de MySQL solo llega a 3 bytes, así que guardar un emoji da error o se trunca; hay que usar utf8mb4.
.lengthLas cadenas de JavaScript, Java, C# y la API de Windows usan UTF-16 por dentro: cada unidad de código son 16 bits. Un carácter del plano básico ocupa una unidad; un punto de código del plano suplementario se parte en dos unidades, lo que se llama par subrogado, en los rangos D800–DBFF y DC00–DFFF. Por eso "😀".length === 2, "😀".split("") lo corta en dos mitades sin sentido y str[0] devuelve el subrogado alto. Para contar caracteres reales, usa [...str].length (itera por puntos de código); para contar «una letra» tal como la percibe la persona (emoji compuestos, signos diacríticos), usa Intl.Segmenter.
Base64 (RFC 4648) no es cifrado, sino una forma de transportar cualquier byte convertido en 64 caracteres ASCII imprimibles (A–Z a–z 0–9 + /) para meter binario donde solo se acepta texto: archivos adjuntos de correo, campos JSON, URL data:, JWT. Se toman 3 bytes = 24 bits, se cortan en 4 trozos de 6 bits () y cada trozo se busca en la tabla: Man = 4D 61 6E = 01001101 01100001 01101110 → 010011 010110 000101 101110 → T W F u. El tamaño se hincha, por tanto, a 4/3 del original.
Cuando el número de bytes no es múltiplo de 3, el último grupo queda incompleto: si falta 1 byte se añade un =, y si faltan 2, dos =, para que la salida mida siempre un múltiplo de 4. A es un byte de 8 bits que se completa con ceros hasta 12: 010000 01(0000) → QQ, más ==. La variante URL-safe cambia + / por - _ (para no tener que escaparlos en una URL) y suele omitir el =; al decodificar se rellenan según la longitud.
En una URL solo puede aparecer tal cual una pequeña parte de los caracteres ASCII (RFC 3986 §2). Los caracteres reservados con significado sintáctico —espacio, &, =, ?, /— y todos los que no son ASCII deben escribirse como % + el hexadecimal del byte. Por eso la codificación URL es primero UTF-8 y después un % por byte: 中 → E4 B8 AD → %E4%B8%AD, y un solo carácter chino se convierte en 9 caracteres. En JavaScript, encodeURIComponent es la que más codifica (incluso / ? & =), ideal para meter valores en un parámetro, mientras que encodeURI conserva los caracteres estructurales y sirve para una dirección completa. El application/x-www-form-urlencoded de los formularios escribe además el espacio como +: es una convención histórica de los formularios HTML, no forma parte de RFC 3986.
El mojibake no es corrupción de datos, sino escribir con la codificación A y leer con la codificación B. El 中 de UTF-8 es E4 B8 AD:
ä¸, tres letras de Europa occidental: una ristra de letras con diacríticos es la señal de «UTF-8 leído como codificación occidental».E4 B8 es el carácter chino 涓 y sobra un AD suelto: «caracteres chinos raros + medio carácter» es la señal de «UTF-8 leído como GBK», y tanto 浣犲ソ como 涓枃 están en ese grupo.� (U+FFFD).Mientras no se hayan perdido los bytes originales, basta con reinterpretar con la codificación correcta y el texto queda intacto. Por eso la primera regla para arreglar mojibake es conservar el archivo original y no convertir una y otra vez: cada conversión puede sustituir bytes inválidos por ? o �, y eso sí es pérdida real de información. El nivel 14 propone hacer el camino inverso: coger el texto ilegible 浣犲ソ, devolverlo a los bytes E4 BD A0 E5 A5 BD según GBK y leerlo como UTF-8 para obtener 你好. La forma moderna de evitarlo es declarar UTF-8 en todas partes: cabeceras HTTP, <meta charset> del HTML, conexión de la base de datos y diálogo de guardado del editor, para que el desajuste no tenga ocasión de ocurrir.
UTF-16 tiene orden de bytes big-endian y little-endian, y al principio del archivo suele llevar una marca de orden de bytes (BOM, FE FF o FF FE). UTF-8 no tiene ese problema, pero el Bloc de notas de Windows escribía por defecto el BOM UTF-8 EF BB BF, y eso hacía que fallara la primera línea de un script de shell o que delante del primer nombre de columna de un CSV apareciera un carácter invisible. Si en la vista de desglose UTF-8 del curso ves esos tres bytes al principio, ya sabes de dónde salen.
TextDecoder del navegador y no se entra en la estructura interna de GB18030, Big5 o Shift_JIS.length es el número de caracteres»: en JavaScript es el número de unidades UTF-16, y un emoji o un ideograma poco común cuentan como 2; la n de un VARCHAR(n) puede ser bytes o caracteres según la base de datos.encodeURIComponent, o &, # y los espacios romperán la estructura.Ver %E4%B8%AD%E6%96%87 y reconocer al momento dos caracteres chinos en UTF-8; ver un JWT con sus tres tramos separados por . y saber cómo volver al JSON; entender por qué el backend trata + y %20 como cosas distintas en un parámetro.
Con el método de los niveles 13–14 puedes decidir si es «UTF-8 leído como GBK» o al revés y usar «volver a abrir con codificación» en el editor, nunca «convertir codificación»: conservar los bytes originales es la primera regla.
Para emoji, utf8mb4; para estimar el almacenamiento UTF-8, cuenta 3 bytes por carácter chino; y aclara si la longitud de VARCHAR se mide en bytes o en caracteres.
Para recortar el apodo de un usuario usa [...str].slice(0, n) y no str.slice(0, n), o cortarás un emoji por la mitad; al contar palabras, decide si quieres unidades de código, puntos de código o grupos de grafemas.
Los emoji con modificador de tono de piel o unidos con zero-width joiner (ZWJ), como 👍🏽 o 👨👩👧, se componen de varios puntos de código y la vista de puntos de código los lista uno a uno. El nivel 8 pide exactamente un carácter de 4 bytes: usa un emoji básico sin modificadores, como 😀.
No hace falta ni una cosa ni la otra: c3a9, C3 A9 y c3 a9 valen igual.
El curso usa el TextDecoder('gbk') del navegador (en realidad, un superconjunto de GB18030), que ante una secuencia inválida escribe �; otras herramientas escriben ? o se saltan los bytes. El dibujo cambia, pero el significado es el mismo: «aquí no se puede interpretar».
Si los bytes originales están completos y solo se interpretaron mal, sí: vuelve a abrirlo en el editor con la codificación correcta. Si el archivo ya se ha «convertido» y está lleno de ?, esa información se ha perdido y el curso tampoco puede recuperarla.
En el localStorage del navegador actual, sin subir nada; el enlace de «Compartir este nivel» solo lleva el número de nivel, no el progreso.
El curso funciona por completo en local: la codificación y decodificación del texto de pruebas, el Base64 y la codificación URL se hacen con TextEncoder / TextDecoder y funciones puras dentro de la página, sin enviar nada a ningún servidor; el progreso se guarda en el localStorage del equipo.
TextDecoder del navegador y sus algoritmos, y la norma de los decodificadores GBK / windows-1252 que usa la demostración de mojibake: https://encoding.spec.whatwg.org/(consultado el 2026-09-09)Actualizado el 2026-09-09
14 niveles para entender bits, bytes, ASCII, puntos de código Unicode, codificación UTF-8 de longitud variable, grupos Base64, codificación URL y el origen de los caracteres ilegibles
Esta herramienta no está traducida por completo; parte del contenido usa el idioma de origen o uno de reserva.
ObjetivoEl texto de muestra es la letra A, cuyo único byte se muestra como 01000001. Convierta este número binario a decimal e ingréselo.
| Carácter | Punto de código | Bytes UTF-8 | Unidades de código UTF-16 | Número de bytes |
|---|---|---|---|---|
| A | U+0041 | 41 | 0041 | 1 |
Las computadoras almacenan sólo 0 y 1. Un bit es un interruptor; 8 bits forman un byte, que puede contener entre 0 y 255.256 valores. Sumas binarias de valores posicionales: 01000001 = 64 + 1 = 65. Todo el texto, las imágenes y el sonido son, en última instancia, secuencias de bytes, y una "codificación" define qué número significa qué carácter.