Contador de bytes por codificación

Mide cuántos bytes ocupa tu texto en UTF-8, Shift_JIS, EUC-JP, UTF-16 y JIS (ISO-2022-JP). Útil para verificar los límites de columnas de base de datos y los límites de formularios antiguos.

Consejos

  • En UTF-8, los caracteres alfanuméricos de ancho medio ocupan 1 byte cada uno, mientras que los caracteres japoneses (hiragana, katakana, kanji) suelen ocupar 3 bytes cada uno, por lo que el mismo número de caracteres puede significar cantidades de bytes muy distintas entre un texto en inglés y uno en japonés.
  • Los sistemas antiguos que aplican límites basados en bytes a columnas como VARCHAR(255) alcanzan su límite mucho antes con texto japonés que con un texto en inglés de la misma longitud en caracteres.
  • La mayoría de los emojis se representan mediante un par sustituto de dos unidades de código, ocupando 4 bytes tanto en UTF-8 como en UTF-16, lo que explica por qué los contadores de caracteres de las redes sociales a veces alcanzan su límite antes de lo esperado.
  • Si ya conoces una cantidad de bytes y quieres convertirla a KB, MB u otras unidades, usa nuestra herramienta hermana "Conversor de unidades de bytes": esta herramienta se encarga del cálculo inverso, de texto a cantidad de bytes.

Preguntas frecuentes

La longitud en caracteres cuenta cuántos caracteres visibles hay en una cadena, mientras que la longitud en bytes indica cuántos bytes (octetos) se necesitan para almacenar o transmitir esa cadena como datos informáticos. En texto ASCII puro ambos valores coinciden, pero en textos con caracteres multibyte como el japonés, la longitud en bytes puede ser varias veces mayor que la longitud en caracteres.

UTF-8 utiliza una codificación de longitud variable de 1 a 4 bytes por carácter, y la mayoría de los caracteres japoneses (hiragana, katakana, kanji comunes) ocupan 3 bytes. Shift_JIS, en cambio, codifica la mayoría de los caracteres japoneses en 2 bytes, por lo que el mismo texto japonés suele ocupar más espacio en UTF-8 que en Shift_JIS.

Depende del motor de base de datos y de la configuración del juego de caracteres de la columna. El VARCHAR(n) de MySQL generalmente se limita a "n caracteres", pero también existen límites internos basados en bytes (como la longitud máxima de clave indexable), por lo que un texto con emojis a veces puede provocar errores. Consulta la documentación específica de tu sistema de gestión de bases de datos para conocer el comportamiento exacto.

Los caracteres alfanuméricos y símbolos de ancho medio ocupan solo 1 byte tanto en UTF-8 como en Shift_JIS y EUC-JP, mientras que los caracteres de ancho completo (hiragana, katakana, kanji, símbolos de ancho completo) ocupan de 2 a 3 bytes según la codificación. Una cadena de 10 caracteres puede ocupar solo 10 bytes si son todos de ancho medio, o de 20 a 30 bytes si son todos de ancho completo.

Esta herramienta toma una cadena de texto como entrada y calcula su longitud en bytes para cada codificación. La herramienta "Conversor de unidades de bytes", en cambio, toma una cantidad de bytes que ya conoces (por ejemplo, 1.500.000 bytes) y la convierte a unidades como KB, MB o GB. Usa esta herramienta cuando quieras pasar de "texto a bytes", y la otra cuando quieras pasar de "bytes a otras unidades".
ツールくん

A propósito — La relación oculta entre los límites de caracteres en redes sociales y el número de bytes

Las versiones antiguas del juego de caracteres "utf8" de MySQL tenían una limitación sorprendente: en realidad no podían almacenar emojis de Unicode (caracteres suplementarios a partir de U+10000). UTF-8 en sí es una codificación de longitud variable que admite hasta 4 bytes por carácter, pero el "utf8" de MySQL estaba históricamente limitado a 3 bytes por carácter, lo que provocaba errores al insertar texto con emojis. Migrar a "utf8mb4", que sí admite correctamente el rango completo de 4 bytes, es ahora la solución recomendada: un ejemplo muy conocido de por qué comprender la relación entre la codificación de caracteres y el número de bytes importa en la práctica.

Cuando Twitter (ahora X) aplicaba su famoso límite de 140 caracteres, hubo un largo debate sobre la equidad entre idiomas: los usuarios japoneses podían expresar una idea bastante completa en 140 caracteres, mientras que los usuarios de inglés apenas podían escribir 20 o 30 palabras en el mismo límite. Esto se debe a que un solo carácter kanji japonés puede transmitir mucha más información que una sola letra en inglés. Twitter acabó introduciendo un sistema de conteo ponderado en el que idiomas como el japonés contaban como "1 carácter = 1 punto", mientras que otros contaban ciertos caracteres como "2 bytes = 1 punto", en un intento de equilibrar la balanza entre idiomas.

Los SMS en móviles tienen una peculiaridad similar. Un SMS codificado con el estándar GSM permite hasta 160 caracteres por mensaje, pero en cuanto incluye un solo carácter fuera del juego de caracteres GSM de 7 bits —como un emoji o un carácter japonés—, la codificación cambia a UCS-2 (aproximadamente equivalente a UTF-16) y el límite cae en picado a solo 70 caracteres. El hecho de que usar un solo carácter japonés pueda reducir a más de la mitad la longitud disponible del mensaje es un ejemplo perfecto y real de la relación entre codificación de caracteres y número de bytes que esta herramienta está pensada para medir.

Más herramientas en esta categoría