Caja de Herramientas

UTF-8 frente a ASCII: inclusión y contención en codificación

ASCII es un código de 7 bits definido en 1963 con solo 128 caracteres ingleses; UTF-8 es una codificación de longitud variable que cubre todo Unicode. El vínculo clave: UTF-8 trata los primeros 128 puntos de código exactamente igual que ASCII, permitiendo que décadas de texto legado sobrevivan sin fisuras.

DimensiónUTF-8ASCII
Cobertura de caracteresTodo Unicode: chino, japonés, árabe, emojis y símbolos matemáticos, más de 140.000 caracteresSolo 128: letras inglesas en ambos casos, dígitos, puntuación común y caracteres de control
Longitud de codificaciónVariable de 1 a 4 bytes: inglés 1 byte, hanzi comunes 3, emojis normalmente 4Un byte fijo (7 bits significativos), longitudes totalmente predecibles
Relación mutuaEs un superconjunto de ASCII: todo archivo ASCII válido ya es UTF-8 válido byte a byteUn subconjunto: cualquier carácter no inglés queda fuera de su alcance
Soporte multilingüeUn mismo documento mezcla chino, inglés, japonés, coreano y símbolos; la única opción realista para productos internacionalesNulo: nombres en chino o tildes españolas (á é ñ) se pierden o dan error
Tamaño en inglés puroIdéntico a ASCII: un byte exacto por carácter, sin sobrecosteLa referencia: un byte por carácter
Estado en protocolos y sistemasEl estándar de facto de internet: WHATWG obliga a usar UTF-8 por defecto; JSON, Linux moderno y Git lo asumenSobrevive como subconjunto seguro en palabras clave de protocolos: métodos HTTP, primeras normas de dominios y comandos SMTP
Ideal paraTodo texto orientado a usuarios: páginas web, APIs, bases de datos, código fuenteCampos de protocolo restringidos, identificadores de máquina y análisis que exigen bytes únicos

¿Cuándo elegir UTF-8?

Usa UTF-8 salvo que una restricción dura demuestre lo contrario. Es la única opción que alberga contenido multilingüe siendo plenamente compatible con datos ASCII antiguos, y la suposición integrada de JSON, HTML5 y los sistemas modernos.

¿Cuándo elegir ASCII?

Cuando sabes que los datos son solo inglés y quien parsea corta por bytes únicos —ciertas cabeceras antiguas, enlaces serie, ficheros de registros fijos— ASCII o una restricción equivalente evita bugs de truncado multibyte.

Herramientas relacionadas

Preguntas frecuentes

¿Hace falta BOM en archivos UTF-8?

Normalmente no; el BOM confunde a ciertas herramientas Unix y versiones viejas de PHP. La excepción habitual son los CSV para Excel en Windows, donde evita caracteres raros.

¿Por qué los sistemas antiguos mezclan ASCII y UTF-8?

Porque ambos coinciden byte a byte en inglés, los sistemas funcionan hasta que alguien escribe un nombre con tilde y aflora el fallo; por eso las pruebas de internacionalización deben usar datos no ingleses.

¿Cuántos bytes ocupa un carácter chino en UTF-8?

Los hanzi comunes (bloque básico U+4E00-U+9FFF) ocupan 3 bytes; los de bloques extendidos pueden llegar a 4. Por eso difieren los sistemas que facturan por caracteres y los que facturan por bytes.

Para saber más

El primer paso ante cualquier mojibake es confirmar qué codificación tiene realmente el flujo de bytes y cuál se usó al leerlo. La cadena típica: un archivo UTF-8 abierto como Latin-1 convierte cada carácter chino en dos o tres símbolos raros. Tratar UTF-8 como ASCII es aún más peligroso: truncar por número de bytes parte un hanzi por la mitad. Nuestro sitio ofrece códecs UTF-8 y conversión de texto a hex para ver byte a byte lo almacenado, todo local, localizando rápido dónde está el desajuste.

← Volver a las comparaciones