573 taiwaneses tienen un apellido que Unicode no puede codificar

El Ministerio del Interior de Taiwán publica un registro de apellidos sin umbral de privacidad. Cada apellido figura con su número exacto de portadores, hasta los 643 apellidos que lleva exactamente una persona de entre 23,4 millones. Es uno de los conjuntos de datos nacionales sobre nombres más completos que existen.

Léalo hasta el final y se topará con filas en las que la columna del apellido no contiene un apellido. Contiene un punto de código que Unicode nunca ha asignado a nada.

Hay 23 filas de este tipo, que suman 573 personas. Esos 573 ciudadanos tienen un apellido legal, inscrito y reconocido por el Estado que ningún programa conforme con las normas puede mostrar ni transmitir, y sobre el que dos programas no pueden ponerse de acuerdo.

Esta página trata de esas 23 filas y de una segunda clase, más discreta, de 14 filas de nuestro propio corpus que parecen correctas hasta que algo las normaliza.

Lo que hemos medido

Verificado contra tw_surname_112.csv (la publicación en datos abiertos del ministerio, fecha de referencia 30 de junio de 2023) el 21 de julio de 2026. Veintidós puntos de código distintos repartidos en veintitrés entradas, porque U+FD13A se usa en dos apellidos compuestos diferentes.

Qué es un punto de código de la Private Use Area

Unicode reserva tres regiones en las que promete no asignar nunca un carácter:

No son «caracteres a los que Unicode todavía no ha llegado». Son puntos de código que Unicode ha renunciado definitivamente a definir, para que las partes privadas puedan acordar entre ellas qué significan. El logotipo de Apple está en U+F8FF en las tipografías de Apple y es una caja vacía en cualquier otro sitio. Eso no es un fallo; es todo el diseño.

La consecuencia es que un punto de código PUA no tiene ningún significado fuera del sistema que se lo asignó. No tiene nombre, ni propiedades de carácter en las que merezca la pena apoyarse, ni forma canónica, ni garantía alguna de que la próxima versión de lo que sea lo represente igual. Dos sistemas pueden ser ambos perfectamente correctos y discrepar por completo sobre qué es U+FBF33.

Las 23 entradas taiwanesas se sitúan todas en el plano 15, entre U+F9000 y U+FFFEE.

Por qué un registro estatal los contiene

El registro de hogares taiwanés (戶籍) consigna la forma escrita de un nombre, no su pronunciación. Si el apellido de una familia es un carácter raro que apareció en los registros de la época Qing y nunca llegó a ninguna norma de caracteres moderna, el sistema de registro de hogares tiene que almacenarlo igualmente — el ciudadano existe, el nombre figura en su documento de identidad y «no podemos codificarlo» no es una opción administrativa.

Así que el ministerio hizo lo que ha hecho todo registro de Asia Oriental desde los años 1980: asignó puntos de código internos para los caracteres que necesitaba y los colocó en el espacio que Unicode reservó precisamente para esto. El 住基ネット japonés, el área definida por el usuario de la norma china GB 18030 y los conjuntos suplementarios de Hong Kong anteriores al HKSCS hicieron todos lo mismo. El registro no es defectuoso. Va por delante de Unicode, y tiene la obligación legal de no esperar.

Las cifras son pequeñas, pero no despreciables:

Cinco de las 23 son apellidos compuestos que mezclan un ideograma ordinario con uno privado, algo que vale la pena ver porque acaba con la idea de que se trate de filas basura:

Los dos últimos son reconociblemente apellidos de patrón japonés (飯?谷, ?原), portados por una persona cada uno — exactamente el tipo de residuo que un registro de hogares acumula y una norma de caracteres no.

El apellido de 179 portadores no es una curiosidad. En el registro ocuparía el puesto 458 por número de portadores. Eso lo sitúa justo por debajo de 諸葛 (180 portadores — el apellido de Zhuge Liang, que conoce todo lector de los Tres Reinos) y holgadamente por encima de 皇甫 (115), 尉遲 (63) y 司馬 (49). El apellido más frecuente que Unicode no puede codificar es más frecuente que varios apellidos que cualquiera sabría nombrar.

Qué aspecto tiene en un navegador

Ninguno. Un punto de código PUA sin cobertura tipográfica se representa como el glifo de reemplazo — la caja notdef, llamada universalmente «tofu» (豆腐), a veces con los dígitos hexadecimales impresos dentro. Cuál de los dos vea usted depende de la pila de tipografías, no de los datos.

Hay un caso peor que una caja vacía, y es la razón por la que no entregamos estas filas en absoluto. Como la PUA es privada, alguna tipografía en alguna máquina puede muy bien tener un glifo ahí — uno distinto. Segoe UI Emoji, las tipografías de sistema de Apple, una tipografía de iconos corporativa, una tipografía Big5 heredada de un fabricante taiwanés y el área de caracteres definidos por el usuario de un IME chino reclaman todos porciones solapadas de la PUA. Un apellido almacenado como U+F9000 puede representarse como una caja en una máquina, como un ideograma raro en una segunda y como un dingbat en una tercera. Los bytes son idénticos. El nombre, no.

Ese es el verdadero modo de fallo: no «ilegible», sino legible en silencio como otra cosa.

Qué hacemos con ellas

Las excluimos todas. Nuestro corpus taiwanés contiene 2.707 de los 2.731 apellidos del registro, y las 24 filas excluidas son estas 23 más la fila agregada 其他 («otros», 5.174 personas), que es una categoría estadística y no un nombre.

Medido sobre el fichero entregado:

La regla es estrecha y merece enunciarse con precisión: no borramos apellidos raros, borramos apellidos que no podemos representar. 慕容 (1 portador), 呼延 (1), 公羊 (1) y 澹臺 (2) están todos en el fichero. La rareza nunca es motivo para descartar una fila; una fila que produce una caja vacía en la pantalla del lector, sí.

Aquí no hay alternativa honesta. No podemos sustituirlos por un carácter de aspecto similar, porque «de aspecto similar» es un juicio sobre un glifo que nunca hemos visto. No podemos transliterar, porque no hay nada de lo que transliterar. No podemos inventar un valor de relleno, porque una identidad generada que lleve U+F9000 es peor que una que lleve un apellido real. Las 573 personas están simplemente fuera de lo que un sistema basado en texto puede representar, y la respuesta correcta es decirlo en lugar de aproximarlo.

La segunda clase: 14 apellidos que sobreviven hasta que algo los normaliza

Ningún punto de código PUA llega a nuestro fichero entregado. Pero el fichero sí contiene 1.780 puntos de código distintos, y no todos están en el bloque que cabría esperar:

Los 14 del CJK Compatibility Ideographs Supplement (U+2F800–U+2FA1F) son los interesantes. Ese bloque existe únicamente para la compatibilidad de ida y vuelta con normas más antiguas, y todos los caracteres que contiene tienen una descomposición canónica singleton: la norma dice que cada uno se descompone en exactamente un carácter distinto, y el paso de composición nunca lo restituye.

La traducción práctica: NFC, NFD, NFKC y NFKD convierten todos estos caracteres en un ideograma unificado ordinario. No «pueden» — la norma Unicode lo exige.

Para los 14, el gemelo unificado ya es una fila aparte en el mismo fichero, con su propio número de portadores:

Las dos columnas parecen idénticas porque en su pantalla son idénticas — mismo glifo, misma forma, punto de código distinto. 284 portadores están en el lado izquierdo, un 0,0012 % del peso del corpus.

No son defectos. El ministerio las mantiene como filas separadas porque, para el registro de hogares, son formas escritas separadas, y nuestro fichero refleja el registro. Pero son un arma cargada apuntando al consumidor.

Por qué la parte peligrosa es la normalización, no la codificación

Un apellido no codificable falla ruidosamente. Usted ve una caja y abre un informe de error. Un ideograma de compatibilidad falla en silencio, y solo en algunas capas de su pila.

Considere una sola entrada que atraviesa una aplicación web corriente:

1. La base de datos guarda 周 U+2F83F (25 portadores) y 周 U+5468 (282.185 portadores) como dos filas.
2. Un front-end JavaScript ejecuta name.normalize() antes de enviar una consulta de búsqueda — la práctica actual y recomendada. U+2F83F se convierte en U+5468. Dos apellidos son ahora uno.
3. Un back-end PHP sin la extensión intl no puede normalizar en absoluto: Normalizer no existe. (Nuestra instalación local de PHP 8.5.8 es exactamente este caso — lo hemos verificado.) Así que la misma cadena que viaja en sentido contrario sigue siendo U+2F83F.
4. Un índice de búsqueda con un filtro de normalización ICU los fusiona; una consulta LIKE, no.
5. Un cliente macOS que escribe el nombre en un nombre de fichero obtiene NFD del sistema de ficheros; un cliente Linux, no.

Nada en esa cadena es erróneo. Cada componente se comporta como está documentado. La entrada acaba de todos modos con dos identidades distintas según la puerta por la que haya entrado.

Dos síntomas concretos más:

La longitud no es la longitud. 周 U+2F83F ocupa 4 bytes en UTF-8 y 2 unidades de código en UTF-16; 周 U+5468 ocupa 3 bytes y 1 unidad de código. Así que LENGTH() en MySQL devuelve 4 frente a 3, el .length de JavaScript devuelve 2 frente a 1, y una columna VARCHAR(1) rechazará uno de los dos. Un apellido «de un carácter» no pasa una validación de un carácter.

Los índices únicos pueden ir en cualquiera de los dos sentidos y usted no puede saber cuál. Que utf8mb4_unicode_ci los trate o no como iguales depende de la versión de la UCA que implemente su servidor y de si la intercalación normaliza siquiera — y deliberadamente no hemos probado una MariaDB en funcionamiento para esta página, así que no vamos a decirle qué hace la suya. Lo que sí podemos decirle es que la respuesta no es evidente, que puede cambiar con una actualización del servidor y que, si su restricción de unicidad sobre una columna de nombres empieza silenciosamente a rechazar una inserción tras un salto de versión menor, esta es la familia de razones por las que ocurre.

La fila que mejor lo ilustra es 丸: U+2F801 tiene un portador y U+4E38 tiene un portador. Normalice, y obtendrá un apellido con dos portadores y ninguna constancia de que dos hogares distintos inscribieron dos glifos diferentes. La aritmética se conserva. El hecho ha desaparecido.

Qué hacer

Decida dónde ocurre la normalización, una sola vez, y déjelo por escrito. No «usamos NFC» — qué capa la aplica, en la escritura o en la lectura, y cuál es la forma de almacenamiento. Un sistema en el que tres capas normalizan cada una por su cuenta es un sistema en el que la forma de almacenamiento es la del último que haya escrito.

Almacene la forma inscrita; derive de ella la forma de búsqueda. La misma estructura que el problema de ordenación de los apellidos europeos con prefijo: la visualización y la comparación quieren dos cadenas distintas. Guarde en una columna la secuencia de bytes que le dio el registro y construya en otra una clave explícitamente normalizada para las consultas, las uniones y la unicidad. No haga de la forma normalizada la única forma.

No normalice los nombres como paso de limpieza. Aplicar NFC a un texto proporcionado por el usuario en la frontera de su API es razonable; aplicar NFC a una columna de nombres en una migración es una pérdida de datos con mensaje de commit. Las 14 filas de arriba son 284 personas cuyo apellido inscrito se diferencia de otro apellido solo en el punto de código, y un único UPDATE ... SET name = NORMALIZE(name) los fusiona sin error y sin vuelta atrás.

Valide sobre la posibilidad de representación, no sobre la plausibilidad. Si aplica algún filtro a la entrada de nombres, una regla razonable es «rechazar los puntos de código situados en las Private Use Areas» — no porque sean inválidos, sino porque no puede prometer que el destinatario vea lo que tecleó el remitente. Esa regla es estrecha, defendible y no rechaza por accidente 慕容 ni 澹臺.

Espere que el registro tenga razón y que la norma vaya por detrás. Cada vez que hemos encontrado un nombre que nuestras herramientas no sabían manejar, el problema eran las herramientas. U+FBF33 son 179 personas vivas; el hecho de que ISO 10646 no tenga un punto de código para su apellido es un hecho sobre ISO 10646.

Limitaciones conocidas

• No podemos decirle qué aspecto tienen los 23 caracteres. Tenemos sus puntos de código, no sus glifos. El ministerio no publica una correspondencia de glifos junto con el conjunto de datos abierto, así que podemos informar de que estas personas existen, pero no de cuál es su apellido.
• No hemos probado el comportamiento de la intercalación en una base de datos en funcionamiento. La afirmación de esta página sobre MariaDB es deliberadamente una admisión de incertidumbre, no un hallazgo.
• Las 14 filas compat se entregan sin fusionar, a propósito. Fusionarlas cambiaría 14 números de portadores y destruiría una distinción que el registro establece. Nuestra postura es que un consumidor que las necesite fusionadas debe fusionarlas con conocimiento de causa, en su propia columna de clave.
• La conciliación interna del propio registro no está explicada. El ministerio afirma en otro lugar que Taiwán tiene 1.785 apellidos, mientras que el conjunto de datos abierto contiene 2.731 filas. Tenemos una lectura plausible de esa diferencia y ninguna confirmación de ella.

Datos actualizados a 2026-07-21

Fecha de referencia del registro: 30 de junio de 2023 (民國112年6月30日), publicado por 內政部戶政司 bajo la Government Open Data Licence v1. Todas las cifras de esta página se recalcularon el 21 de julio de 2026 a partir del CSV en bruto y de nuestro fichero de pesos entregado; los ficheros de apellidos masculinos y femeninos son idénticos byte a byte, porque los apellidos taiwaneses no flexionan por género.

Fuentes

• data.gov.tw conjunto de datos 126774 — 姓氏排名與人數按三階段年齡分
• Unicode Standard Annex #15: Unicode Normalization Forms
• Unicode Standard, Chapter 23.5: Private-Use Characters
• CJK Compatibility Ideographs Supplement (U+2F800–U+2FA1F) code chart