Inspector Unicode
Muestra cada carácter de un texto con su código y nombre, y encuentra caracteres ocultos o parecidos.
Cargando Inspector Unicode… Si no ocurre nada, activa JavaScript.
Un texto que parece idéntico en pantalla puede ser muy distinto por dentro. Una palabra copiada de un PDF puede traer un guion suave, un nombre de usuario puede esconder un espacio de ancho cero, un enlace puede cambiar la a latina por la а cirílica, y una letra acentuada puede estar guardada como un solo carácter o como letra base más un acento combinatorio. El Inspector Unicode divide cualquier texto en los caracteres que ve el lector (agrupaciones de grafemas) y enumera cada punto de código que contienen con su número U+, su nombre oficial Unicode, su categoría general y su bloque, para que veas exactamente con qué estás tratando.
Ejemplos
é (one code point)
U+00E9 LATIN SMALL LETTER E WITH ACUTE
Forma NFC, 2 bytes en UTF-8.
é (two code points)
U+0065 + U+0301 COMBINING ACUTE ACCENT
Forma NFD: se ve idéntica, pero la comparación da distinto.
pаypal (with Cyrillic а)
U+0430 CYRILLIC SMALL LETTER A
Marcada como palabra con mezcla de escrituras.
Preguntas frecuentes
¿Cómo encuentro un espacio de ancho cero en mi texto?
¿Qué diferencia hay entre carácter, punto de código y byte?
¿Por qué dos cadenas que parecen iguales no coinciden?
¿Qué son NFC, NFD, NFKC y NFKD?
¿Qué es un ataque de homóglifos o de mezcla de escrituras?
¿Qué son los caracteres de control bidireccional y por qué se marcan?
¿Se sube mi texto a algún sitio?
¿De dónde salen los nombres de los caracteres?
Acerca de Inspector Unicode
La herramienta señala los caracteres que suelen dar problemas. Caracteres de formato invisibles como el espacio de ancho cero, el zero-width joiner, el word joiner y la marca de orden de bytes (BOM); controles bidireccionales como RLO y LRI, que pueden reordenar visualmente el texto y fueron la base del ataque "Trojan Source" contra código fuente; espacios de no separación, finos y otros espacios poco habituales que no coinciden con un espacio normal en código ni en búsquedas; letras con aspecto de espacio en blanco usadas para fingir nombres vacíos; y palabras que mezclan letras latinas con cirílicas o griegas, el clásico truco de los homóglifos detrás de los dominios de phishing. Las secuencias de emoji se reconocen, así que los joiners dentro de 👩🏽💻 no se marcan como sospechosos.
Haz clic en cualquier fila para ver todas las representaciones de ese punto de código: bytes UTF-8, unidades UTF-16, entidades HTML numéricas y con nombre, escapes de JavaScript, CSS y Python y la forma codificada para URL. Los contadores sobre la tabla muestran el número de grafemas, puntos de código, unidades UTF-16 (lo que devuelve length en JavaScript) y bytes UTF-8, lo que explica por qué una columna de base de datos, un SMS o un tuit cuentan tu texto de forma distinta a lo que ves.
El panel de normalización compara las cuatro formas de normalización Unicode (NFC, NFD, NFKC, NFKD) y te deja copiar o inspeccionar cualquiera de ellas, que es como se arreglan cadenas que parecen iguales pero fallan en una comparación. Por último, el panel de limpieza elimina caracteres invisibles y bidireccionales, cambia los espacios exóticos por un espacio normal, quita caracteres de control sueltos y, si quieres, normaliza el resultado, dejando los emoji intactos. Los nombres y bloques de los caracteres vienen de la Unicode Character Database oficial, y todo se ejecuta localmente en tu navegador.
UTF-8 se diseñó sobre un mantel de papel
En septiembre de 1992, Ken Thompson y Rob Pike, de Bell Labs, no estaban contentos con la codificación multibyte propuesta para el nuevo juego universal de caracteres. Durante una cena en un restaurante de Nueva Jersey, Thompson esbozó un esquema mejor sobre un mantel de papel: el ASCII sigue ocupando un byte, ningún byte de una secuencia multibyte puede confundirse con un carácter ASCII y siempre se puede encontrar el inicio de un carácter mirando los bits altos. Lo implementaron en el sistema operativo Plan 9 en pocos días.
Ese diseño es UTF-8, y su compatibilidad con ASCII es la razón por la que se impuso en la web, donde hoy lo usa la gran mayoría de las páginas. El propio Unicode había nacido unos años antes, con la propuesta de Joe Becker de 1988 de un juego de caracteres "Unicode" y la primera versión de la norma publicada en 1991.
La flexibilidad que hizo universal a Unicode también trajo nuevos problemas de seguridad. En 2017 un investigador registró un dominio escrito solo con letras cirílicas que los navegadores mostraban como apple.com, lo que llevó a los navegadores a presentar esos nombres en su forma punycode. En 2021, el artículo Trojan Source de la Universidad de Cambridge demostró que los caracteres de control bidireccional podían hacer que el código fuente se viera de forma distinta a como lo lee el compilador.