Las falsas fuentes de tu biografía no son fuentes: qué son en realidad esos caracteres

Qué hace realmente el generador

Una fuente es un archivo. Contiene contornos y asocia la letra A con una forma. Elegir una fuente en negrita no cambia la letra A; cambia cómo se dibuja la letra A. Todos los estilos que ofrece un generador de biografías funcionan al revés: se sustituye la letra, y el dibujo es el que la fuente de la plataforma ya tenía para el sustituto.

Imprime los puntos de código y la sustitución salta a la vista. La palabra OneKitly en estilo negrita es U+1D400 U+1D425 U+1D425 U+1D422 U+1D427; en doble trazo U+1D538 U+1D55D U+1D55D U+1D55A U+1D55F; en monoespaciado U+1D670 U+1D695 U+1D695 U+1D692 U+1D697. Cinco letras visibles, cinco puntos de código, ninguno en el rango ASCII. En JavaScript la cadena declara .length 10, porque cada uno de estos caracteres ocupa dos unidades UTF-16.

También cuestan más de almacenar. La frase «Building tools for six languages.» tiene 33 caracteres y 33 bytes UTF-8 porque es ASCII puro. La misma frase en negrita sigue teniendo 33 caracteres, pero 61 unidades UTF-16 y 117 bytes UTF-8: tres veces y media la carga para las mismas palabras. En una plataforma que mide una biografía en bytes en vez de caracteres, eso es casi todo tu presupuesto gastado en nada.

Todo lo que compara texto deja de coincidir

La búsqueda de subcadena falla primero. "OneKitly".includes(negrita) devuelve false, y al revés también, porque no comparten ni un punto de código. Una búsqueda interna, el buscar-en-la-página del navegador, una cláusula LIKE de base de datos y un índice de etiquetas se reducen a la misma comparación, y todos fallan. Si tu nombre visible está escrito en negrita matemática, quien escriba tu nombre real en el buscador no te encontrará.

La conversión de mayúsculas y minúsculas no hace nada. negrita.toLowerCase() devuelve exactamente la misma cadena, porque las correspondencias de caja de Unicode para los alfanuméricos matemáticos asocian cada carácter consigo mismo. Así que una búsqueda insensible a la caja que pasa ambos lados a minúsculas también falla. Lo único que sí funciona es la colación: Intl.Collator("en", { sensitivity: "base" }).compare("𝐀", "A") devuelve 0, porque las tablas de colación de ICU pliegan las letras estilizadas sobre sus letras base. Conviene saberlo, porque explica por qué la misma cadena se encuentra en un producto y es invisible en otro: depende de si la ruta de búsqueda pasó por un colador o por una igualdad de cadenas.

Las clases de caracteres se contradicen. /[a-zA-Z]/.test("𝐀") es falso, /\w/u.test("𝐀") es falso, pero /\p{L}/u.test("𝐀") es verdadero: el carácter sí es una letra según la categoría general de Unicode (Lu para la mayúscula, Ll para la minúscula), simplemente no es una letra ASCII. Los dígitos se comportan igual: /\d/u.test("𝟏") es falso mientras que /\p{Nd}/u.test("𝟏") es verdadero, y Number("𝟏𝟐𝟑") es NaN aunque la misma cadena tras NFKC se analiza como 123. Dos validadores escritos por dos equipos llegarán a veredictos opuestos sobre la misma biografía.

La ordenación reparte la diferencia. Un Array.prototype.sort() pelado compara unidades UTF-16, así que ["𝐁rown", "Adams", "Clark"] sale como Adams, Clark, 𝐁rown: el nombre estilizado queda desterrado al final porque U+1D400 es numéricamente mayor que cualquier letra ASCII. Cambia a localeCompare y esos mismos tres salen Adams, 𝐁rown, Clark, que es lo que espera un lector. Ninguno se equivoca; responden a preguntas distintas, y un directorio que use el rápido no te archivará en ninguna parte.

El coste de accesibilidad, dicho sin rodeos

Un lector de pantalla no ve tu biografía. Recibe la secuencia de caracteres que la plataforma guardó y se la entrega a un sintetizador de voz, que busca cada carácter en un diccionario de pronunciación. Ese diccionario está hecho para las letras con las que se escribe. U+1D400 no es una de ellas. El sintetizador tiene tres opciones: leer en voz alta el nombre Unicode del carácter, leer un marcador genérico, u omitirlo. Las tres ocurren en la práctica, y cuál te toca depende del lector, la voz y el nivel de verbosidad, no de nada que controle quien escribe.

El coste es fácil de subestimar porque el fallo es invisible para quien lo causó. Tú ves un nombre elegante. Un lector ciego puede oír treinta nombres de caracteres seguidos, o ver desaparecer el nombre de tu cuenta por completo, dejando una tarjeta con una imagen y ningún título. No hay ajuste que ese lector pueda cambiar para arreglarlo, porque para la máquina el texto realmente dice otra cosa. Ese es todo el argumento; no necesita ninguna moraleja encima.

Una familia es peor que las demás. Los conjuntos encerrados en círculo y en círculo invertido —Ⓐ U+24B6, 🅐 U+1F150— no son letras en absoluto: su categoría general es So, símbolo/otro. Un software que filtre un campo dejando solo letras y espacios los eliminará, y uno que cuente letras contará cero.

Los 28 huecos del bloque, y por qué todo generador lleva una tabla de parches

El bloque Mathematical Alphanumeric Symbols va de U+1D400 a U+1D7FF, es decir 1024 puntos de código. Al escanearlo buscando caracteres asignados aparecen 996, así que 28 casillas están vacías: quedan 652 letras latinas (trece estilos de 52, menos las que faltan), 294 caracteres griegos y afines, y 50 dígitos en cinco estilos.

Cuatro de los 28 son simple relleno reservado: U+1D6A6 y U+1D6A7 están entre la j cursiva sin punto y el alfa mayúscula en negrita, y U+1D7CC y U+1D7CD entre la digamma minúscula en negrita y el dígito cero en negrita. Los otros 24 son casillas de letras dejadas vacías a propósito porque ese carácter exacto ya se había codificado años antes en el bloque Letterlike Symbols, en U+2100–U+214F.

La lista es lo bastante corta para darla entera. Falta la h cursiva porque ya existía como U+210E PLANCK CONSTANT. A la script le faltan B, E, F, H, I, L, M, R (viven en U+212C, U+2130, U+2131, U+210B, U+2110, U+2112, U+2133, U+211B) y las minúsculas e, g, o (U+212F, U+210A, U+2134). A la fraktur le faltan C, H, I, R, Z (U+212D, U+210C, U+2111, U+211C, U+2128). A la de doble trazo le faltan C, H, N, P, Q, R, Z (U+2102, U+210D, U+2115, U+2119, U+211A, U+211D, U+2124): las letras de teoría de conjuntos que todo matemático ya tenía.

Por eso el bloque delata su origen. Un generador que asigna letras por simple aritmética —tomar el punto de código de la A y sumar el desplazamiento del estilo— produce puntos de código sin asignar para esas 24 letras, y un punto de código sin asignar se dibuja como un recuadro vacío. Un generador bien hecho lleva la tabla de parches. Uno rápido no, y por eso el texto script tiene tan a menudo un agujero justo donde debería ir una E o una R.

Dónde estos caracteres son la respuesta correcta

Nada de esto convierte a esos caracteres en un error. Existen porque en matemáticas el estilo es el significado. Una R en negrita y una R en cursiva no son el mismo símbolo leído de dos formas; son dos símbolos. ℝ son los reales, R puede ser un anillo, y un vector en negrita no es el escalar escrito con la misma letra. Codificar los estilos como caracteres distintos es lo que permite que una fórmula sobreviva a copiarse de un artículo a un correo sin perder su contenido.

Ese es también el criterio para saber si los usas bien. Si el estilo lleva información que se perdería sin él, el carácter es la herramienta correcta. Si el estilo es adorno sobre prosa ordinaria, entonces letras normales más formato de verdad —la negrita que produce tu editor, que deja la letra A siendo la letra A— es la herramienta correcta, y es la única que un lector de pantalla, un índice de búsqueda y una rutina de ordenación pueden manejar todos.

NFKC, y las plataformas que borran el efecto sin avisarte

Unicode define una descomposición de compatibilidad para cada uno de estos caracteres: el propio estándar registra que U+1D400 es una variante de formato de A. La forma de normalización NFKC aplica esas descomposiciones y luego recompone, así que negrita.normalize("NFKC") sobre nuestra frase de prueba devuelve el original ASCII, carácter por carácter: comparamos ambas cadenas y son iguales. Lo mismo le pasa al texto de ancho completo (U+FF21 se vuelve A), a las letras encerradas (U+24B6 se vuelve A) y a las letras modificadoras voladas (U+1D2C se vuelve A).

Muchos servicios normalizan a la entrada, casi siempre para impedir que dos cuentas tengan nombres de aspecto idéntico. Cuando lo hacen, el estilo que pegaste ya no existe en el momento de guardar, y nada te lo dice: envías una biografía estilizada y te devuelven una normal. Nada está roto; la plataforma simplemente preguntó a la base de caracteres qué decía realmente tu texto y guardó esa respuesta.

Dos familias sobreviven a NFKC, y saber cuáles es útil. Las versalitas —ᴀ es U+1D00 LATIN LETTER SMALL CAPITAL A— son letras fonéticas de las extensiones AFI, sin ninguna descomposición de compatibilidad, así que atraviesan la normalización intactas. También las letras encerradas en círculo invertido, 🅐 U+1F150 y compañía. A ojos del estándar no son variantes estilísticas de A; son caracteres por derecho propio. Eso las hace más duraderas y no más legibles, que es el canje sobre el que se sostiene toda la categoría.

Una regla práctica para un perfil

Mantén en letras normales los campos por los que se busca: tu nombre, tu usuario, las palabras que alguien escribiría para encontrarte. Ahí es donde la sustitución te cuesta algo medible. Si quieres un adorno, ponlo donde nadie consulta —un separador, un único carácter decorativo— y deja en claro las palabras de alrededor.

Y guarda una copia de la versión normal. Como la transformación es una tabla de correspondencia, la vuelta también lo es: normaliza con NFKC y recuperas exactamente el original para las familias matemática, de ancho completo, encerrada y volada. Para las versalitas y las encerradas en círculo invertido necesitas un mapa inverso, porque la normalización no lo hará por ti.

Preguntas frecuentes

¿Una biografía en falsa fuente perjudica mi alcance?

Te saca de la búsqueda textual sobre esas palabras, lo cual es medible e independiente de cualquier algoritmo de posicionamiento. "OneKitly".includes(negrita) es falso, así que una consulta con tu nombre normal no puede coincidir con uno estilizado por subcadena. Que una plataforma concreta lo compense depende de si normaliza o colaciona antes de indexar, y las plataformas no lo publican. La lectura prudente: toda palabra por la que quieras ser encontrado debe ir en letras normales.

¿Por qué algunas letras aparecen como recuadros vacíos?

Dos razones distintas con el mismo aspecto. O el generador emitió uno de los 28 puntos de código sin asignar del bloque —lo más común, una letra script, fraktur o de doble trazo de entre los 24 huecos— o el carácter existe pero la fuente del dispositivo del lector no tiene glifo para él. Lo primero es un fallo del generador y se ve en todos; lo segundo depende del dispositivo, y por eso el mismo mensaje se ve bien en tu móvil y roto en el de otra persona.

¿Cómo convierto texto estilizado de vuelta a letras normales?

Para las familias matemática, de ancho completo, encerrada y volada, basta una llamada: texto.normalize("NFKC"). Comprobamos que devuelve una frase entera exactamente: la frase en negrita normalizada resulta igual al original ASCII. Las versalitas y las encerradas en círculo invertido no tienen descomposición de compatibilidad y sobreviven a la normalización, así que requieren una tabla inversa explícita. Una herramienta de conversión trae ambos caminos; un normalize de una línea cubre la mayoría.

¿Hay algún estilo que sea seguro usar?

No en el sentido de ser invisible para el software: todos cambian los puntos de código, y ese es todo el mecanismo. Lo que varía es cuánto pierdes. Sustituir un carácter decorativo entre dos palabras normales no cuesta casi nada. Sustituir un nombre visible entero cuesta la búsqueda, la ordenación y la capacidad de la tecnología de apoyo para leerlo. La magnitud del daño sigue al número de letras sustituidas: úsalos por carácter, no por frase.

¿Por qué mi texto estilizado a veces vuelve normal tras guardarlo?

El servicio lo normalizó. NFKC es la forma estándar de decidir si dos cadenas son «el mismo texto», y las plataformas la aplican a nombres visibles y usuarios para impedir la suplantación por parecido. Una vez aplicada, U+1D400 se vuelve A y ya no queda nada que deshacer. Nada está roto y no se muestra ningún error, porque desde el punto de vista de la plataforma guardó exactamente lo que escribiste, según la definición de «lo que escribiste» que da la base de caracteres.

¿Estos caracteres cuentan para un límite de caracteres?

Depende por completo de qué cuente el límite, que es el problema de siempre de los límites de caracteres. Por puntos de código, nuestra frase de prueba son 33 en ambos casos. Por unidades UTF-16 —lo que devuelve .length en JavaScript y lo que usan muchos validadores de formulario— la frase normal son 33 y la de negrita 61. Por bytes UTF-8 son 33 frente a 117. Un formulario que te deja escribir 33 caracteres normales puede aceptar solo 16 estilizados, y el contador junto al campo no lo explicará.