Longitud de una cadena: caracteres, bytes y grafemas

Hay tres respuestas habituales a «cuánto mide esta cadena», y miden cosas distintas. Los bytes miden almacenamiento: cuántas unidades de 8 bits ocupa el texto en una codificación dada. Los puntos de código miden valores Unicode: cuántas entradas numeradas usa el texto. Los grafemas miden percepción: cuántos caracteres ve un lector humano.

Toma la palabra café. Un lector ve 4 grafemas. En su forma compuesta son 4 puntos de código, pero en UTF-8 ocupa 5 bytes, porque la é necesita 2 bytes. Toma una bandera en emoji: 1 grafema para el usuario, 2 puntos de código por dentro, 8 bytes en UTF-8 y 4 unidades de código UTF-16. Misma cadena, cuatro números.

Dos hechos explican casi todos los bugs de longitud. Primero, los contadores ingenuos eligen una unidad y fingen que vale para las tres — el .length de JavaScript cuenta unidades UTF-16, el strlen de C cuenta bytes, y ninguno es «la» longitud. Segundo, los límites eligen su propia unidad — una columna de base de datos cuenta caracteres, un payload de API cuenta bytes, un SMS cuenta símbolos codificados — y el bug es siempre un desajuste entre el contador y el límite.

El resto de este artículo cubre las tres unidades en detalle, por qué los emoji y los acentos rompen los contadores ingenuos, las maths UTF-8 vs UTF-16, los límites prácticos que realmente rechazan tu texto, cuándo validar por caracteres y cuándo por bytes, y qué cambia con el árabe y el texto bidireccional. Si solo necesitas los números, la herramienta de longitud de cadena muestra caracteres, palabras y bytes lado a lado. Forma parte del conjunto más amplio de string tools junto al contador de palabras.

Caracteres, bytes y grafemas — con ejemplos

Aplicadas a las mismas cadenas, esto es lo que reporta cada unidad y qué herramienta o límite la usa:

El patrón: el texto ASCII hace que todos los contadores coincidan, por eso las diferencias se esconden hasta que llega el texto real — acentos, emoji, escrituras no latinas. Prueba tu contador con café 😀 y sabrás de inmediato qué unidad reporta.

Por qué los emoji y los acentos rompen los contadores ingenuos

Dos mecanismos causan casi todas las sorpresas. El primero son los caracteres multibyte: en UTF-8, las letras ASCII ocupan 1 byte, las latinas acentuadas 2, la mayoría de las escrituras no latinas 2–3, y los emoji 4. Cualquier contador que reporte bytes crece más rápido que el texto visible en cuanto sales del inglés simple.

El segundo son las secuencias combinantes: caracteres construidos con varios puntos de código que se muestran como un solo glifo. Una é puede ser un punto de código precompuesto o la letra e más un acento combinante — idénticas en pantalla, cuentas distintas. Los emoji son peor: las banderas son pares de indicadores regionales, y las familias son cadenas enteras unidas por joiners sin ancho. Un solo «carácter» visible puede tener ocho puntos de código.

• El .length de JavaScript cuenta unidades de código UTF-16. Todo lo fuera del plano multilingüe básico — casi todos los emoji — cuenta como 2. Usa Array.from(str).length para puntos de código o Intl.Segmenter para grafemas.
• El len() de Python cuenta puntos de código. Mejor, pero aún no grafemas: una bandera reporta 2, una familia con joiners 7+.
• La normalización cambia la cuenta. Las formas NFC (compuesta) y NFD (descompuesta) de la misma palabra tienen distintos números de puntos de código. Dos bases que guardan el mismo nombre en formas distintas discrepan sobre su longitud.

La solución no es un mejor número único — es el número correcto para cada uso, por eso la herramienta de longitud de cadena muestra juntos caracteres, palabras y bytes UTF-8 en vez de fingir que uno de ellos es «la» longitud.

Las maths de bytes UTF-8 vs UTF-16

Las codificaciones de almacenamiento convierten los mismos puntos de código en distintos números de bytes. UTF-8 usa 1 byte para ASCII, 2 para latín acentuado, griego, cirílico, hebreo y árabe, 3 para la mayoría de las escrituras asiáticas, y 4 para emoji. UTF-16 usa 2 bytes para todo el plano multilingüe básico y 4 bytes (un par subrogado) para todo lo de fuera.

Consecuencia práctica: una descripción de producto en español mide casi lo mismo en ambas codificaciones, un catálogo árabe también, pero una bio social llena de emoji es más grande en UTF-8 (4 bytes por emoji) de lo que el .length de JavaScript sugiere (2 unidades por emoji).

Para desarrolladores, las conversiones son one-liners: new TextEncoder().encode(str).length da los bytes UTF-8 en el navegador, len(s.encode("utf-8")) en Python, y Buffer.byteLength(str, "utf8") en Node.js. Cuando una API documenta un tope en bytes, este es el número a comprobar — no el del contador de caracteres del campo.

Los límites que realmente rechazan tu texto

La longitud solo importa porque algo la impone. Los cuatro límites que más muerden:

• Columnas de bases de datos. Un límite VARCHAR(255) suele ser en caracteres, pero los tipos limitados en bytes y las viejas columnas MySQL utf8 (3 bytes) rechazan por completo los emoji de 4 bytes. El error aparece al enviar, mucho después de que el usuario pasara la validación del frontend.
• Segmentación SMS. 160 caracteres GSM-7 por segmento, o 70 en UCS-2 en cuanto aparece un carácter fuera del alfabeto — luego 153/67 por segmento concatenado tras el primero. Un solo emoji puede convertir un mensaje de 1 segmento en 3.
• Topes de campos de API. Muchas APIs topan campos en bytes (límites de payload) mientras los documentan en caracteres. Un campo documentado como «32 caracteres» puede rechazar 32 emoji porque superan el presupuesto de bytes subyacente.
• Validación de formularios. El maxlength del frontend cuenta unidades UTF-16 en la mayoría de los navegadores — coincide con el .length de JavaScript pero no con el backend, la base de datos ni los ojos del usuario.

La regla: averigua qué unidad cuenta la capa que impone el límite, y valida en esa unidad. Cuando la documentación calla, prueba con emoji — separan los contadores de caracteres de los de bytes más rápido que cualquier documentación.

Cuándo validar por caracteres, cuándo por bytes

Valida por grafemas o puntos de código cuando el límite trata de contenido humano: nombres visibles, bios, títulos, comentarios, metadescripciones. El usuario piensa en caracteres visibles, así que el contador también debería.

Valida por bytes cuando el límite trata de transporte o almacenamiento: topes de payload de peticiones, columnas limitadas en bytes, límites de tamaño de webhooks, longitud de URL codificada. Aquí la longitud visible es irrelevante — lo que importa es lo que cruza el cable.

Y valida siempre en ambos lados en la misma unidad. Un frontend que cuenta grafemas mientras el backend cuenta bytes es la forma más común de este bug, y solo aparece con entrada no ASCII — justo la que probablemente falta en tu suite de tests.

Texto árabe y caracteres bidireccionales

El árabe añade dos matices. Primero, los diacríticos (harakat): la misma palabra visible puede almacenarse con o sin marcas de vocal, y de forma precompuesta o descompuesta, así que dos cadenas «idénticas» reportan longitudes distintas. Normalizar a NFC antes de contar elimina la mayoría de los desacuerdos.

Segundo, la direccionalidad: el texto mixto árabe y latino contiene caracteres de control bidireccionales invisibles que afectan el orden de visualización. Son invisibles en pantalla pero cuentan en todas las unidades — bytes, puntos de código, longitud UTF-16, todas. Un título de producto copiado que «parece» de 30 caracteres puede ser de 34 por dos marcas ocultas.

La escritura árabe en sí no tiene mayúsculas/minúsculas, así que los convertidores de mayúsculas no operan en ella — pero los contadores de longitud la tratan como cualquier otra escritura no ASCII: 2 bytes por letra en UTF-8, 1 unidad UTF-16 por letra. Un texto árabe pegado que falla un límite suele fallar en bytes, no en longitud visible.

Cuenta sin adivinanzas

Sea cual sea el límite a comprobar, el conteo en sí debería estar a un pegado de distancia:

• Un contador de longitud de cadena gratuito que muestra caracteres, palabras y bytes UTF-8 lado a lado.
• Se ejecuta por completo en tu navegador — nada de lo que pegas se sube.
• Se combina con el contador de palabras cuando también necesitas palabras y tiempo de lectura.
• Parte del conjunto más amplio de string tools : contador de palabras, convertidor de mayúsculas, codificador de URLs y codificador Base64.

Preguntas frecuentes