🔡 Contador de Caracteres Japoneses (文字数・バイト数)

Contar texto en japonés no es tan simple como parece. Un solo "carácter" puede ser una letra latina de medio ancho (1 byte en Shift-JIS), un kana o kanji de ancho completo (2 bytes en Shift-JIS), o una letra latina de ancho completo (también 2 bytes). Los formularios, bases de datos y sistemas japoneses heredados a menudo tienen límites expresados en recuentos de bytes en lugar de caracteres, así que una cadena que cabe en 30 caracteres puede desbordar un campo de 30 bytes. Conocer tanto el recuento de caracteres como el de bytes (en UTF-8 y Shift-JIS) es esencial para rellenar formularios web japoneses, diseñar columnas de bases de datos y escribir textos de longitud limitada.

Este contador de caracteres japoneses informa del recuento de caracteres con y sin espacios, el número de líneas, el recuento de bytes en UTF-8, el recuento de bytes en Shift-JIS y un desglose de caracteres de ancho completo vs medio ancho.

El contador recorre la entrada una vez y, para cada carácter, registra su longitud en bytes UTF-8 (1 para ASCII, 2 para el suplemento Latin-1 y el griego, 3 para kana, kanji y la mayoría de símbolos, 4 para emoji) y su longitud en bytes Shift-JIS (1 para ASCII y katakana de medio ancho, 2 para kana de ancho completo, kanji y latinos de ancho completo). También clasifica cada carácter como ancho completo o medio ancho comprobando su bloque Unicode, y cuenta espacios y saltos de línea por separado.

1. Pega tu texto japonés (o mixto) en el cuadro de entrada.
2. Los contadores se actualizan al instante mientras escribes o pegas.
3. Comprueba el recuento de caracteres con y sin espacios.
4. Comprueba los recuentos de bytes UTF-8 y Shift-JIS para límites de formulario o base de datos.
5. Usa el desglose de ancho completo vs medio ancho para planificar la normalización.

¿Por qué hay dos recuentos de bytes diferentes?

Los diferentes sistemas codifican el japonés de forma distinta. Las páginas web modernas usan UTF-8 (donde un kanji son 3 bytes), mientras que muchos sistemas gubernamentales y bancarios japoneses más antiguos usan Shift-JIS (donde un kanji son 2 bytes). La herramienta muestra ambos para que coincidas con el sistema que comprueba tu entrada.

Cuando un formulario dice que admite 30 bytes, ¿qué codificación significa?

Casi siempre significa bytes Shift-JIS, porque esa es la codificación heredada que los sistemas internos japoneses todavía usan. Planifica 2 bytes por carácter de ancho completo en ese caso.

¿Cómo se cuentan los emoji?

Los emoji suelen ocupar 4 bytes en UTF-8 y no son representables en Shift-JIS básico, así que a menudo hacen que los formularios heredados rechacen la entrada. El contador muestra su coste en bytes UTF-8 para que puedas detectarlos.

¿Cuenta palabras además de caracteres?

Se centra en caracteres y bytes porque el japonés no tiene espacios entre palabras, lo que hace que un recuento de palabras por división de espacios no sea fiable. El recuento de caracteres es la métrica de longitud estándar para texto japonés.

¿Cuál es la diferencia entre ancho completo y medio ancho?

Los caracteres de medio ancho (A, 1, ｱ) son estrechos y cuestan 1 byte Shift-JIS; los de ancho completo (Ａ, １, ア, 日) son anchos y cuestan 2. Los latinos y dígitos de ancho completo los producen los IME japoneses y a menudo se normalizan a medio ancho antes del envío.

¿Mi texto se envía a un servidor?

No. Todo el recuento ocurre en tu navegador con JavaScript. Nada se sube, almacena ni registra, así que es seguro pegar texto privado o en borrador.

Cuando un formulario japonés dice que acepta "30 bytes", casi siempre significa bytes Shift-JIS, porque esa es la codificación heredada que la mayoría de los sistemas gubernamentales y bancarios todavía usan internamente: planifica 2 bytes por carácter de ancho completo. Los dígitos y letras latinas de ancho completo (０１２３, ＡＢＣ) cuestan 2 bytes Shift-JIS cada uno, mientras que sus equivalentes de medio ancho cuestan 1, así que normalizar a medio ancho antes de enviar suele ahorrar espacio. Los emoji cuentan como 4 bytes UTF-8 y suelen ser rechazados por los formularios heredados. Para tweets y otros sistemas compatibles con Unicode, el recuento UTF-8 es lo que importa.