Fuentes japonesas y las trampas de los caracteres — JIS2004, selectores de variantes de ideogramas y gaiji en aplicaciones empresariales

«El nombre es el mismo, pero la forma del carácter difiere entre la pantalla y el informe impreso.» «Después de cambiar el PC, un carácter que se mostraba se convirtió en □.» Los sistemas empresariales que tratan japonés atraen consultas de este tipo.

Lo primero que hay que comprobar es si cambiaron los datos del carácter o si solo cambió el aspecto de los mismos datos. Si se intenta corregirlo como «mojibake» sin separar ambas cosas, se entra en la investigación por la puerta equivocada.

Este artículo parte de dos consultas: un 葛 de un listado de clientes que se ve distinto en pantalla y en el informe impreso, y un nombre en un documento presentado a una administración que dejó de poder mostrarse tras un cambio de PC.

Ninguna de estas dos consultas es el mojibake que provoca un desajuste de codificación. En la primera, los datos no han cambiado ni un bit y solo ha cambiado el aspecto; en la segunda se ha perdido un «gaiji» (carácter definido por el usuario, EUDC) que solo existía en ese PC.

flowchart TB
    accTitle: Qué son en realidad las dos consultas frecuentes
    accDescr: La consulta de que 葛 se ve distinto en pantalla y en el informe impreso es un caso en el que solo cambió el aspecto mientras los datos siguieron iguales; la consulta de que un carácter se volvió □ tras un cambio de PC es un caso en el que se perdió un gaiji que solo existía en ese PC; ambas son un problema distinto del mojibake por desajuste de codificación
    c1["Consulta 1: la forma difiere entre pantalla e informe"] --> r1["Los datos no cambian; solo cambió el aspecto"]
    c2["Consulta 2: se volvió □ tras cambiar el PC"] --> r2["Se perdió un gaiji que solo existía en ese PC"]
    r1 --> diff["Un problema distinto del mojibake de codificación"]
    r2 --> diff

Figura 1: Las dos consultas que suelen llamarse «mojibake» son, en ambos casos, un problema distinto de un desajuste de codificación.

Separe el código de carácter (la capa de datos) de la fuente (la capa de aspecto) y la mayoría de los problemas de caracteres en japonés se aclaran. Este artículo está dirigido a desarrolladores de sistemas empresariales y al personal de sistemas, y recorre en orden el aislamiento del síntoma, el funcionamiento de JIS2004, IVS y los gaiji, el rango de caracteres que se aceptan y el diseño de informes y PDF.

El garabateo que se produce en la conversión entre Shift_JIS y UTF-8 se trata en artículos existentes, así que este se centra en el problema de que los códigos van y vuelven correctamente, pero el aspecto, o la posibilidad misma de mostrar el carácter, no encaja.

1. Primero, lo esencial

«Qué secuencia de bytes guardar» es una cuestión de diseño de datos; «cómo se ve» es una cuestión de diseño de fuentes. Al decidir cómo responder, separe las tres cosas siguientes.

Primero, confirmar si los datos son los mismos

El «mojibake» es un problema de la capa de datos: una secuencia de bytes interpretada mal. En cambio, el mismo punto de código Unicode puede tener un glifo distinto en una fuente distinta. JIS2004 cambió los glifos de ejemplo de 168 caracteres, entre ellos 葛, 辻 y 飴, y a partir de Vista los glifos JIS2004 son el valor predeterminado en MS Gothic y MS Mincho de Windows.¹²

No confundir la especificación de un glifo con el transporte de gaiji

IVS es el medio estándar de especificar un glifo como dato. Sin embargo, necesita una fuente compatible y una aplicación compatible, y en un entorno sin ellas el comportamiento correcto es ignorar el selector y mostrar el glifo predeterminado del carácter base. Como lo que parece un carácter puede ocupar hasta cuatro unidades de código UTF-16, afecta no solo a la visualización, sino también al recuento de caracteres y al recorte.³⁴

Los gaiji (EUDC, caracteres definidos por el usuario) son otro asunto: un número del área de uso privado no tiene un significado compartido en todo el mundo. El glifo de eudc.tte no viaja a la otra parte con los datos, así que una migración necesita un inventario y una correspondencia hacia caracteres de sustitución.⁵⁶

Dejar por escrito en la especificación los caracteres aceptados y el entorno de salida

Un sistema que trata nombres de personas decide el conjunto de caracteres que acepta y lo deja explícito. Donde el sistema intercambia datos con la administración, observe también los caracteres estándar de trámites administrativos, que se apoyan en los caracteres unificados del koseki y en la plataforma de información de caracteres.⁷⁸⁹ En informes y PDF, la base es usar la misma fuente que en pantalla, confirmar la licencia e incrustar la fuente. Para conservación a largo plazo, considere PDF/A.¹⁰¹¹

Además, no aplique a la ligera la normalización NFKC al original de un nombre de persona. Sustituir las formas de ancho completo y medio y los caracteres de compatibilidad pierde distinciones que deben conservarse.¹²

Elegir por dónde leer según el síntoma o el objetivo

Para entender el conjunto, lea a partir del capítulo 2 en orden; para investigar el síntoma que tiene delante, empiece por el apartado correspondiente de la tabla. Cuando implemente una contramedida, compruebe al final en el capítulo 9 también el efecto sobre las demás capas.

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (14 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

2. Pensar los datos y el aspecto por separado — Puntos de código y glifos

El número y la forma dibujada son cosas distintas

En Unicode, un carácter se representa con un número llamado punto de código. 葛 es U+845B, y ese número es el mismo en cualquier PC.

Cómo se dibuja ese número en pantalla o en papel, en cambio, lo decide el glifo que contiene la fuente. Es normal que el mismo U+845B difiera en los detalles de la forma entre la fuente A y la fuente B.

Separar la capa que hay que investigar según el síntoma

Con estas dos capas como premisa, los síntomas que se encuentran en el trabajo se reparten así.

Como pista para la separación, conviene recordar la diferencia entre «�» y «□».

«�» es la huella de una conversión fallida. En cuanto se ha sustituido por U+FFFD (REPLACEMENT CHARACTER), el carácter original ya se ha perdido. Investigue la capa de datos.

«□» es, en la mayoría de los casos, una visualización de «glifo no encontrado». Si los datos siguen ahí y a la fuente simplemente le falta un glifo, cambiar de fuente puede hacer que se muestre. Investigue la capa de aspecto.

flowchart TB
    accTitle: Separar el síntoma según � frente a □
    accDescr: Cuando un carácter no se muestra correctamente, � es la huella de un fallo de conversión en la capa de datos en el que el carácter original se ha perdido, mientras que □ significa solo que los datos siguen ahí pero la fuente no tiene el glifo, y cambiar de fuente puede hacer que se muestre
    symptom["Un carácter no se muestra correctamente"] --> which{"¿Qué se ve?"}
    which -->|Se ve �| datalayer["Fallo de la capa de datos"]
    datalayer -.-> lost["Huella de una conversión fallida (el carácter original se ha perdido)"]
    which -->|Se ve □| viewlayer["Fallo de la capa de aspecto"]
    viewlayer -.-> noglyph["A la fuente simplemente le falta un glifo"]
    noglyph --> fixable["Cambiar de fuente puede hacer que se muestre"]

Figura 2: � señala un fallo de la capa de datos y □ uno de la capa de aspecto, y el punto de entrada de la investigación cambia en consecuencia.

Los fundamentos de las propias codificaciones (CP932 y UTF-8, BOM, finales de línea) se tratan en «Introducción a la codificación de texto en Windows - Mojibake al integrar con Linux» y «Codificación de caracteres y saltos de línea en Windows - Fundamentos de los caracteres corruptos y CRLF/LF». A partir de aquí, el tema es la capa de aspecto y los problemas que ocurren en su frontera.

3. De JIS90 a JIS2004 — El glifo cambió y el código se quedó igual

La causa real detrás del «葛 se ve distinto en pantalla y en el informe» de la apertura está, en la mayoría de los casos, aquí.

Lo que cambió: los glifos predeterminados de la fuente

Tras la Hyogai Kanji Jitaihyo (la tabla de formas de caracteres para kanji fuera de la lista Jōyō) informada por el Consejo de la Lengua Nacional en 2000, la revisión de 2004 JIS X 0213:2004 (conocida como JIS2004) cambió los glifos de ejemplo de 168 kanji a las formas estándar de imprenta, próximas a las llamadas formas del diccionario Kangxi. 葛, 辻, 飴, 芦, 溢 y 餅 son ejemplos representativos.¹

Windows siguió esa línea e hizo de los glifos JIS2004 el valor predeterminado en MS Gothic y MS Mincho (y en Meiryo, de nueva introducción) a partir de Windows Vista. La MS Gothic actual también tiene glifos predeterminados basados en JIS2004; los glifos de la época JIS90 se alcanzan a través de la característica OpenType jp90.²¹

flowchart TB
    accTitle: Cómo están organizados los glifos de la MS Gothic actual
    accDescr: MS Gothic a partir de Vista tiene los glifos JIS2004 como valor predeterminado, y los glifos de la época JIS90 se alcanzan a través de la característica OpenType jp90
    msg["MS Gothic (a partir de Vista)"] --> def["Glifos predeterminados: basados en JIS2004"]
    msg --> feat["A través de la característica jp90"]
    feat --> old["Glifos de la época JIS90"]

Figura 3: La MS Gothic actual tiene los glifos JIS2004 como valor predeterminado y puede cambiar a los glifos JIS90 con la característica jp90.

Lo que no cambió: el punto de código del carácter

Lo que importa aquí es que solo cambió la fuente; los datos no cambiaron en absoluto.

• El punto de código de 葛 es U+845B tanto en XP como en Windows 11
• XP (glifos JIS90) muestra la forma en la que el interior del 勹 se simplifica a ヒ; a partir de Vista (glifos JIS2004) se muestra la forma que escribe también 人 en el interior
• Por eso una imagen escaneada de un informe impreso por el sistema antiguo y la pantalla del PC nuevo no coinciden en la forma del carácter. Una comparación de los datos coincide por completo

Que el radical shinnyō de 辻 tenga un punto o dos, y la forma del radical de la comida en 飴, son del mismo tipo. Sin conocer esta historia, una investigación tiende a ir en la dirección equivocada: «la migración corrompió los datos».

El orden de investigación es: comparar los puntos de código antes y después de la migración → si coinciden, sospechar una diferencia de glifo entre fuentes. No concluya que los datos están corruptos solo porque se vean distintos.

flowchart TB
    accTitle: El mismo punto de código, un glifo distinto según la fuente
    accDescr: El punto de código U+845B de 葛 sigue siendo el mismo en XP y en Windows 11, solo cambia la forma mostrada entre una fuente con glifos JIS90 y una fuente con glifos JIS2004, y una comparación de los datos coincide por completo
    cp["Punto de código U+845B de 葛"] --> f90["Fuente con glifos JIS90 (XP)"]
    cp --> f04["Fuente con glifos JIS2004 (a partir de Vista)"]
    f90 --> g90["Forma con el interior de 勹 simplificado a ヒ"]
    f04 --> g04["Forma estándar de imprenta que escribe 人 en el interior"]
    g90 -.-> same["La comparación de los datos coincide por completo"]
    g04 -.-> same

Figura 4: Solo cambió la fuente; el punto de código U+845B sigue siendo el mismo en cualquier entorno.

Como el carácter en sí no cambió, ambos glifos son «el mismo carácter». En los nombres de personas, sin embargo, la persona o la administración a veces insiste en una forma concreta, y responder a la exigencia de distinguir eso «como dato» es el trabajo del siguiente tema, IVS.

4. Selectores de variantes de ideogramas (IVS) — Especificar un glifo como dato

Este capítulo mira por separado el mecanismo que especifica un glifo, las condiciones en las que puede mostrarse y el impacto en la implementación.

Una IVS (Ideographic Variation Sequence) es un mecanismo que coloca justo después de un kanji un punto de código invisible llamado «selector de variante de ideograma» para especificar una variante de glifo como dato. Los selectores usados van de U+E0100 a U+E01EF (VS17 a VS256).³

La correspondencia de glifos la decide el registro IVD

Qué secuencia «carácter base + selector» apunta a qué glifo lo decide un registro llamado IVD (Ideographic Variation Database), gestionado por el Unicode Consortium.

Las colecciones principales son las siguientes.¹³

Por ejemplo, la documentación de Microsoft da U+845B solo (葛) como la forma usada en el nombre de la estación de Nishi-Kasai, y U+845B seguido de U+E0100 (VS17) como la forma usada en el nombre de la ciudad de Katsuragi, en la prefectura de Nara. El mismo 葛, y aun así los datos pueden decir qué glifo se pretende.³

flowchart TB
    accTitle: Un ejemplo de distinguir el mismo 葛 como dato con IVS
    accDescr: 葛 como U+845B solo se usa en el nombre de la estación de Nishi-Kasai, la secuencia de U+845B seguida de VS17 se usa en el nombre de la ciudad de Katsuragi, y qué secuencia apunta a qué glifo lo decide el registro IVD
    seq1["U+845B solo"] --> gl1["Glifo usado en el nombre de la estación de Nishi-Kasai"]
    seq2["U+845B + VS17"] --> gl2["Glifo usado en el nombre de la ciudad de Katsuragi"]
    ivd["IVD (registro)"] -.-> gl1
    ivd -.-> gl2

Figura 5: Incluso para el mismo 葛, la presencia o ausencia de un selector permite que los datos digan qué glifo se pretende.

4.1. Comportamiento en un entorno que no lo admite

En el lado de la fuente, la correspondencia entre una IVS y un glifo se implementa en la tabla cmap de OpenType (formato 14).⁴ Cuando coinciden una fuente compatible (como IPAmj Mincho) y una aplicación compatible, aparece el glifo especificado.

Cuando no coinciden, no hay garantía de que el glifo especificado sobreviva. Separe los dos casos siguientes.

• El comportamiento correcto según la especificación: se ignora el selector y se muestra el glifo predeterminado del carácter base (el selector en sí es invisible)
• Aplicaciones antiguas y algunas pilas de renderizado: el selector se trata como un carácter desconocido independiente, y se muestra un □ extra

En otras palabras, IVS está diseñado para que «aunque se degrade, el carácter base siga siendo legible», pero si «siempre se muestra en el glifo especificado» depende del entorno receptor.

Los sistemas administrativos de registro de residentes y de registro familiar usan la combinación de una fuente de la plataforma de información de caracteres más IVS, pero si un sistema empresarial general lo acepta a la ligera, el glifo se pierde en algún punto del camino de visualización, impresión o un sistema posterior.

flowchart TB
    accTitle: Cómo se muestran los datos con IVS
    accDescr: Cuando coinciden una fuente compatible y una aplicación compatible se muestra en el glifo especificado; cuando no, se ignora el selector y se muestra el glifo predeterminado del carácter base; en aplicaciones antiguas y algunas pilas de renderizado el selector se trata como un carácter desconocido y se muestra un □ extra
    ivs["Carácter base + selector de variante de ideograma"] --> env{"¿Coinciden fuente y aplicación compatibles?"}
    env -->|Sí| ok["Se muestra en el glifo especificado"]
    env -->|No| ignore["Selector ignorado; se muestra el glifo predeterminado"]
    env -->|Aplicaciones antiguas o algunas pilas de renderizado| tofu["Se muestra un □ extra"]
    ignore -.-> spec["Este es el comportamiento correcto según la especificación"]

Figura 6: IVS sigue siendo legible como carácter base aunque se degrade, pero si aparece el glifo especificado depende del entorno receptor.

4.2. Precauciones de implementación — «Un carácter» puede ocupar hasta cuatro unidades de código

Los selectores IVS a partir de U+E0100 son puntos de código del plano suplementario, así que en UTF-16 son siempre un par subrogado (dos unidades de código). Si el carácter base es a su vez un kanji del plano suplementario (por ejemplo 𠮟 (U+20B9F), añadido en JIS2004), la base sola son dos unidades de código, y la secuencia que un usuario percibe como «un carácter» ocupa hasta cuatro unidades de código en UTF-16 y hasta ocho bytes en UTF-8.

Recuento de caracteres y subcadenas: no partir el carácter aparente

En C#, "葛󠄀" (葛 + VS17) tiene string.Length == 3. Substring y el recorte a longitud fija corren el riesgo de separar el carácter base de su selector.

Valide el recuento de caracteres y extraiga subcadenas en unidades de grafema, con API como StringInfo, no en unidades de código.

Almacenamiento: comprobar la unidad de la longitud de columna

El nvarchar(n) de SQL Server se mide en unidades de código UTF-16. Si acepta IVS, planifique longitudes de columna de la base de datos de dos a cuatro veces el recuento aparente de caracteres.

Búsqueda y comparación: decidir si se distinguen los selectores

La presencia o ausencia de un selector hace una cadena distinta. Si una búsqueda de «葛» debe encontrar también «葛 + VS17» es algo que hay que decidir como requisito e implementar.

flowchart TB
    accTitle: Un carácter con IVS y las unidades de código UTF-16
    accDescr: La secuencia de un carácter base y un selector de variante de ideograma que un usuario percibe como un carácter tiene un selector que es siempre un par subrogado, más dos unidades de código si el carácter base es un kanji del plano suplementario, hasta cuatro unidades de código en UTF-16
    one["Un carácter tal como lo percibe el usuario"] --> base["Carácter base"]
    one --> vs["Selector de variante de ideograma"]
    base -.-> bnote["Dos unidades de código si es un kanji del plano suplementario"]
    vs -.-> vnote["Siempre un par subrogado (dos unidades de código)"]
    base --> total["Hasta cuatro unidades de código en UTF-16"]
    vs --> total
    total -.-> risk["El recorte a longitud fija corre el riesgo de separarlos"]

Figura 7: Un carácter con IVS puede ocupar hasta cuatro unidades de código UTF-16, así que recortar por unidad de código es peligroso.

5. Gaiji (EUDC) — Caracteres que solo se muestran en ese PC

Los gaiji son un mecanismo por el que un usuario asigna un glifo propio a un punto de código del área de uso privado de Unicode (PUA: U+E000 a U+F8FF y otros rangos). Un punto de código del área de uso privado no tiene un significado compartido en todo el mundo; al mismo U+E000 se le puede asignar un carácter distinto en cada PC y en cada organización.⁵

El glifo vive en la fuente gaiji; en los datos solo queda el número

En Windows se crea el glifo en el Editor de caracteres privados (eudcedit.exe), y se guarda en un archivo de fuente llamado eudc.tte.

Este archivo se instala como fuente oculta y se asocia a cada fuente a través de la clave de registro HKEY_CURRENT_USER\EUDC.⁶ En la época de Shift_JIS (CP932) el rango gaiji iba de 0xF040 a 0xF9FC, y la conversión a Unicode lo hace corresponder con el área de uso privado.

Un número en los datos no significa que la otra parte tenga el mismo glifo. Este mecanismo da lugar a los problemas siguientes.

• eudc.tte pertenece a ese PC (ese usuario) y no viaja a la otra parte con los datos
• En el momento en que los datos llegan al correo, a un PDF, a la web o a otro sistema, el carácter se vuelve □ o se ve como otro gaiji del otro lado
• Si se olvida mover eudc.tte en una migración de SO o un cambio de PC, ocurre «un carácter que se mostraba en el PC antiguo ya no se muestra»

Esa es la causa real detrás de la segunda consulta de la apertura.

flowchart TB
    accTitle: Por qué los gaiji solo se muestran en ese PC
    accDescr: Un glifo creado en el Editor de caracteres privados se guarda en eudc.tte y se asocia a las fuentes a través del registro de ese PC, de modo que cuando solo el código del área de uso privado viaja al correo, a un PDF o a otro sistema, se vuelve □ o se ve como otro carácter
    edit["Crear el glifo en el Editor de caracteres privados"] --> tte["Guardado en eudc.tte"]
    tte --> reg["Asociado a las fuentes a través del registro"]
    reg --> local["Se muestra en ese PC"]
    tte -.-> stay["eudc.tte no viaja con los datos"]
    send["Solo el código del área de uso privado llega a la otra parte"] --> dest["Correo, PDF, otros sistemas"]
    dest --> broken["Se vuelve □ o se ve como otro carácter"]

Figura 8: El glifo vive en eudc.tte y en los datos solo queda un número del área de uso privado, así que los gaiji se ven rotos en cuanto salen del PC.

5.1. Una respuesta realista para un sistema que ya ha recibido gaiji

El problema aparece cuando los datos heredados de un sistema legado ya contienen gaiji. Lo que recomendamos en los encargos de migración es un procedimiento en cuatro etapas: inventariar → identificar → sustituir → bloquear.

1. Inventariar: reunir los números en uso y los glifos originales

Recorra bases de datos y archivos con una expresión regular del área de uso privado (U+E000 a U+F8FF) e inventaríe los códigos gaiji en uso y sus recuentos. Recoja eudc.tte de los PC de cada sede y compruebe los glifos.

2. Identificar: construir una tabla de correspondencia hacia caracteres de sustitución

Para cada gaiji, compruebe si se puede representar con un carácter Unicode ordinario, si se puede representar con IVS y si la plataforma de información de caracteres (MJ) tiene un carácter correspondiente, y construya una tabla de correspondencia hacia caracteres de sustitución. En la práctica, la mayoría de los casos resultan no ser más que una forma antigua de carácter que se había creado como gaiji JIS.

3. Sustituir: sustituir los datos según la tabla

Sustituya los datos según la tabla de correspondencia. Solo cuando no exista en absoluto un carácter correspondiente, conserve el carácter como imagen o adjunte una nota al registro en cuestión.

4. Bloquear: no añadir gaiji nuevos

En el sistema nuevo, rechace en la validación las entradas del área de uso privado y no cree gaiji nuevos.

flowchart TB
    accTitle: Procedimiento para migrar datos que contienen gaiji
    accDescr: Inventaríe los gaiji en uso recorriendo el área de uso privado y recogiendo eudc.tte, construya una tabla de correspondencia hacia caracteres de sustitución y sustituya, y en el sistema nuevo rechace en la validación las entradas del área de uso privado y no cree gaiji nuevos
    st1["Inventariar: recorrer el área de uso privado"] --> st2["Identificar: construir la tabla de correspondencia hacia caracteres de sustitución"]
    st2 --> st3["Sustituir: sustituir según la tabla"]
    st3 --> st4["Bloquear: no crear gaiji nuevos"]
    st1 -.-> tte["Recoger eudc.tte de cada sede"]
    st2 -.-> nomap["Imagen o nota solo donde no exista correspondencia"]

Figura 9: Migre los gaiji en cuatro etapas — inventariar, identificar, sustituir y bloquear — y no cree gaiji nuevos.

La dirección es la misma en el lado de la administración: la política declarada es identificar de forma unívoca los gaiji que los ayuntamientos han creado por su cuenta (se dice que son unos dos millones de caracteres en todo el país) frente a los caracteres estándar de trámites administrativos descritos más abajo, y dejar de usarlos.⁹ «No añadir gaiji; identificarlos frente a un conjunto de caracteres estandarizado» se está convirtiendo en el patrón de migración asentado tanto en el sector público como en el privado.

6. La plataforma de caracteres de la administración — De los caracteres unificados del koseki a los caracteres estándar de trámites administrativos

Al diseñar un sistema que trata nombres de personas, conocer la plataforma de caracteres de la administración da material para decidir «hasta dónde aceptar».

Primero, separar los nombres y los roles de las plataformas de caracteres

Separar el intercambio dentro de la administración del intercambio con el exterior general

Para los sistemas de negocio núcleo de los ayuntamientos (sistemas conformes al estándar), la especificación estándar es un arreglo de dos niveles: usar los caracteres estándar de trámites administrativos para el intercambio de información de nombres y similares, e intercambiar en el rango de JIS X 0213:2012 con sistemas externos que no tienen reglas de intercambio unificadas, como los teléfonos inteligentes.⁹

Este arreglo, «mantener internamente un conjunto de caracteres amplio e intercambiar con el exterior en el rango que un entorno general puede mostrar», es en sí una referencia útil para los sistemas del sector privado.

flowchart TB
    accTitle: El intercambio de dos niveles de un sistema conforme al estándar
    accDescr: Un sistema municipal conforme al estándar usa los caracteres estándar de trámites administrativos para el intercambio de información de nombres y similares, e intercambia en el rango de JIS X 0213:2012 con sistemas externos como los teléfonos inteligentes que no tienen reglas de intercambio unificadas
    sys["Sistema municipal conforme al estándar"] --> renkei["Intercambio de información de nombres y similares"]
    sys --> gaibu["Intercambio con sistemas externos"]
    renkei --> mjp["Caracteres estándar de trámites administrativos"]
    gaibu --> jis["Rango de JIS X 0213:2012"]
    gaibu -.-> sumaho["Contrapartes sin reglas, como los teléfonos inteligentes"]
    mjp -.-> naibu["En el interior se mantiene un conjunto de caracteres amplio"]

Figura 10: Un arreglo de dos niveles: el intercambio administrativo usa los caracteres estándar de trámites administrativos, y el intercambio externo sin reglas usa JIS X 0213:2012.

Decidir el rango que acepta el propio sistema

Como orientación práctica para un sistema empresarial general, recomendamos lo siguiente.

• Decida el conjunto de caracteres aceptado y déjelo explícito tanto en la especificación como en la validación de entrada. Por ejemplo, «el rango de JIS X 0213:2012», «sin área de uso privado ni caracteres combinantes», o «IVS no aceptado (o aceptado, con visualización garantizada solo en un entorno IPAmj Mincho)»
• No acepte sin límite. Un diseño de «es Unicode, así que cabe todo» se romperá en algún punto del camino de visualización, impresión o integración
• Decida de antemano cómo se tratan los caracteres fuera de rango. La regla para sustituir una representación alternativa (una forma de estilo nuevo o katakana) y el texto con el que se explica a la persona forman parte de la especificación del sistema
• Donde una parte posterior como una administración o una entidad financiera tenga reglas de conjunto de caracteres, considérelas autoritativas y ajústese a ellas

flowchart TB
    accTitle: Diseñar y operar el conjunto de caracteres aceptado
    accDescr: Decida el conjunto de caracteres aceptado y déjelo explícito tanto en la especificación como en la validación de entrada, acepte los caracteres dentro de rango, y para los que queden fuera decida de antemano la operación, incluida la regla para sustituir una representación alternativa y el texto con el que se explica a la persona
    decide["Decidir el conjunto de caracteres aceptado"] --> spec["Dejarlo explícito en la especificación"]
    decide --> valid["Dejarlo explícito en la validación de entrada"]
    valid --> range{"¿Dentro de rango?"}
    range -->|Sí| ok["Aceptar"]
    range -->|No| alt["Sustituir una representación alternativa"]
    alt -.-> word["El texto explicado a la persona también forma parte de la especificación"]

Figura 11: Deje el conjunto de caracteres aceptado explícito tanto en la especificación como en la validación de entrada, y decida también el trato de los caracteres fuera de rango.

7. Elegir e incrustar fuentes — Alinear la pantalla y el informe impreso

Aquí el orden de pensamiento es: confirmar que la fuente existe en los entornos que se usan → usar la misma fuente en pantalla y en el informe → confirmar la licencia e incrustarla en el PDF.

7.1. El carácter de las fuentes habituales

Comprobar los entornos en uso, no solo el nombre de la fuente

Lo que importa en la elección no es la preferencia de tipografía, sino si la fuente existe en cada entorno implicado en la visualización, la impresión y la generación de PDF.

Las fuentes japonesas complementarias de Windows 10/11 (BIZ UD y otras) pueden no estar instaladas según la configuración, y en una configuración que genera PDF en el servidor, la presencia de la fuente en el servidor tiene un efecto directo.

flowchart TB
    accTitle: Los entornos que hay que comprobar al elegir una fuente
    accDescr: Al elegir una fuente, lo que importa no es la preferencia de tipografía sino si la fuente existe en cada entorno implicado en la visualización, la impresión y la generación de PDF, y la configuración de las fuentes complementarias y si la fuente está en el servidor tienen un efecto directo
    cand["Fuente candidata"] --> exist["¿Presente en cada entorno?"]
    exist --> scr["Entorno de visualización"]
    exist --> prn["Entorno de impresión"]
    exist --> srv["Servidor de generación de PDF"]
    scr -.-> hojo["Las fuentes complementarias pueden faltar según la configuración"]
    srv -.-> eikyo["La presencia de la fuente en el servidor tiene un efecto directo"]

Figura 12: Elija una fuente no por preferencia de tipografía, sino por si está presente en cada entorno de visualización, impresión y generación de PDF.

7.2. Lo básico del diseño de informes — alinear, luego incrustar

Usar la misma fuente en pantalla y en el informe

Especifique la misma fuente en pantalla y en el informe. Si las fuentes difieren, los mismos datos pueden verse como un glifo distinto, y aparece la queja de la apertura. Una configuración como «Meiryo en pantalla, MS Mincho en el informe» debería comprobarse al menos por diferencias de glifo en los 168 caracteres de JIS2004.

Incrustar en el PDF, tras confirmar la licencia

Incruste la fuente en el PDF. Si no lo hace, el lado que visualiza dibuja con la fuente que tenga a mano, y no solo los glifos, sino también la maquetación, pueden cambiar.

Si se puede incrustar o no lo decide la licencia. Una fuente OpenType declara sus permisos de incrustación en el campo fsType (Installable, Restricted, Preview & Print, Editable, sin subconjunto, etc.), y no debe incrustar una fuente cuya incrustación no esté permitida.¹⁰ En las fuentes comerciales, comprobar el contrato es obligatorio.

Haga de la incrustación de subconjunto el valor predeterminado. Si solo incrusta los glifos de los caracteres usados, no tiene que cargar una fuente japonesa entera (varios MB hasta decenas de MB).

Considerar PDF/A para la conservación a largo plazo

Si hay un requisito de conservación a largo plazo, use PDF/A. PDF/A (ISO 19005) es una norma que hace autónomos dentro del archivo los recursos necesarios para la visualización, y la incrustación de fuentes es obligatoria.¹¹ También es el modo más fiable de impedir «lo abrimos diez años después y los glifos habían cambiado».

flowchart TB
    accTitle: El flujo de decisión para la incrustación de fuentes
    accDescr: Antes de incrustar una fuente en un PDF, compruebe la licencia de incrustación en fsType, haga de la incrustación de subconjunto el valor predeterminado si está permitida, y considere PDF/A, donde la incrustación es obligatoria, si hay un requisito de conservación a largo plazo
    emb["Incrustar la fuente en el PDF"] --> lic{"¿Incrustación permitida por fsType?"}
    lic -->|Permitida| sub["La incrustación de subconjunto es el valor predeterminado"]
    lic -->|No permitida| ng["No se debe incrustar"]
    sub -.-> gly["Solo los glifos de los caracteres usados"]
    sub -->|Requisito de conservación a largo plazo| pdfa["Considerar PDF/A"]
    pdfa -.-> must["La incrustación de fuentes es obligatoria"]

Figura 13: La incrustación presupone comprobar la licencia fsType; la incrustación de subconjunto y PDF/A son la base.

Cómo elegir un enfoque de implementación para la impresión y la salida PDF se trata en detalle en «Impresión y salida en PDF en aplicaciones empresariales de Windows».

8. Enlace de fuentes y reserva — El fenómeno «se mezcla otra fuente»

Un carácter para el que la fuente especificada no tiene glifo no se deja en blanco; el comportamiento predeterminado de las pilas de renderizado modernas es dibujarlo en su lugar con otra fuente.

En GDI lo hace el «enlace de fuentes» definido en el registro (FontLink\SystemLink); en DirectWrite, WPF y los navegadores, la «reserva de fuentes».¹⁵

flowchart TB
    accTitle: El flujo del enlace de fuentes y la reserva
    accDescr: Si la fuente especificada tiene el glifo se muestra tal cual; si no, se dibuja con una fuente enlazada o de reserva; y si no existe el glifo en ninguna parte se vuelve □, pero los datos suelen seguir intactos
    disp["Mostrar un carácter"] --> has{"¿La fuente especificada tiene el glifo?"}
    has -->|Sí| draw["Se muestra en la fuente especificada"]
    has -->|No| fb{"¿Lo tiene una fuente enlazada o de reserva?"}
    fb -->|Sí| alt["Se dibuja en su lugar con otra fuente"]
    alt -.-> mixed["La causa de una sensación de tipografía mezclada"]
    fb -->|No| tofu["Se muestra □ (tofu)"]
    tofu -.-> alive["Los datos suelen seguir intactos"]

Figura 14: □ es la huella de una reserva fallida; si el dibujo de sustitución tiene éxito es la horquilla entre «mezclado» y «tofu».

Leer el resultado del dibujo de sustitución a partir del síntoma

Conocer este mecanismo permite explicar los casos familiares siguientes.

• La sensación de tipografía difiere entre alfanuméricos y japonés: se especificó primero una fuente latina, así que solo la parte japonesa se dibuja en la fuente japonesa enlazada o de reserva
• Solo los kanji de una frase japonesa toman glifos de aspecto chino: la reserva se resolvió a una fuente china. Ocurre con facilidad en páginas web y aplicaciones que no pasan correctamente la información de idioma (un atributo lang o una configuración regional)
• Aparece tofu (□): ni la fuente especificada ni la de reserva tienen el glifo. En otras palabras, □ es la «huella de una reserva fallida», y los datos suelen seguir intactos

La reserva no sustituye al diseño

La reserva es una red de seguridad; no es un sustituto de elegir la fuente correcta desde el principio.¹⁵

En una aplicación empresarial, la postura sana es «las rutas principales de visualización e impresión se cierran solo con las fuentes diseñadas, y la reserva es un seguro frente a caracteres inesperados». Sobre cómo pensar la elección de fuente en una interfaz de usuario multilingüe, véase también «Internacionalización de aplicaciones WinForms/WPF».

9. Una lista de comprobación de implementación para aplicaciones empresariales

Por último, la tabla siguiente resume los puntos que hay que comprobar en cada capa, de la entrada a la integración. No se quede en «se muestra en pantalla»; compruebe también el almacenamiento, la impresión y la integración.

Separar el almacenamiento del original del procesamiento para la búsqueda

La normalización en particular es la trampa que es el propio tema de este artículo: un proceso aplicado «con buena intención» que aplana las distinciones entre caracteres variantes y entre ancho completo y medio. Dejar el original tal cual; procesar una copia es el principio.

Los accidentes de codificación en la integración CSV se tratan en detalle en «El CSV no es «solo texto»».

flowchart TB
    accTitle: Dejar el original tal cual y procesar una copia
    accDescr: Almacene la cadena introducida como original exactamente tal como se introdujo, aplique la normalización a una copia limitada a usos como generar claves de búsqueda, y tenga en cuenta que aplicar NFKC al original aplana las distinciones entre caracteres variantes y entre ancho completo y medio
    input["Cadena introducida"] --> orig["Original: almacenado tal como se introdujo"]
    input --> copy["Copia: normalizada para un uso limitado"]
    copy -.-> use["Generar claves de búsqueda y similares"]
    orig -.-> ng["NFKC sobre el original aplana las distinciones"]

Figura 15: Limite la normalización a un uso concreto y aplíquela a una copia; almacene el original tal como se introdujo.

10. Resumen

Investigación: separar los datos del aspecto

• Divida primero los problemas de caracteres en la «capa de datos (codificación de caracteres)» y la «capa de aspecto (fuentes)». � señala un fallo de la capa de datos, □ uno de la capa de aspecto.
• JIS X 0213:2004 cambió los glifos de ejemplo de 168 caracteres, y Windows tiene los glifos JIS2004 como valor predeterminado a partir de Vista. Que 葛, 辻 y 飴 se vean distintos según el entorno es historia de las fuentes, no corrupción de datos.

Diseño: decidir cómo se especifican los glifos y qué se acepta

• El medio estándar de fijar un glifo en los datos es IVS, pero sin una fuente compatible y una aplicación compatible cae al glifo predeterminado. No olvide el impacto de implementación de que un carácter puede ocupar hasta cuatro unidades de código UTF-16.
• Los gaiji (EUDC) son activos propios de ese PC y no pueden viajar con los datos. La respuesta realista es inventariarlos en la migración, sustituirlos mediante una tabla de correspondencia hacia caracteres ordinarios o IVS, y dejar de crear otros nuevos.
• Un sistema que trata nombres de personas decide el conjunto de caracteres aceptado y lo deja explícito. La administración estandariza hacia los caracteres estándar de trámites administrativos sobre la base de los caracteres unificados del koseki y de la plataforma de información de caracteres, y los sistemas que intercambian datos con ella necesitan seguir ese movimiento.

Implementación y salida: proteger el original y alinear las rutas de visualización

• En informes y PDF, la base es «usar la misma fuente que en pantalla, confirmar la licencia e incrustar». Considere PDF/A para la conservación a largo plazo.
• La normalización NFKC, el recorte por unidad de código y la conversión CP932 son los tres puntos grandes que rompen en silencio los caracteres variantes y los gaiji. Haga del almacenamiento del original y del procesamiento en unidades de grafema la regla.

La próxima vez que le digan «el carácter es distinto», empiece por esta pregunta: ¿los puntos de código son los mismos o distintos? Si son los mismos, es un problema de fuente; si difieren, es un problema de datos. Este solo movimiento evita entrar en la investigación por la puerta equivocada.

flowchart TB
    accTitle: La primera pregunta que decide el punto de entrada de la investigación
    accDescr: Cuando se dice que un carácter es distinto, compare primero si los puntos de código son los mismos o distintos, y empiece la investigación como un problema de fuente si son los mismos y como un problema de datos si difieren
    said["Se ha dicho que el carácter es distinto"] --> cmp{"¿Los puntos de código son los mismos?"}
    cmp -->|Los mismos| fontp["Problema de fuente"]
    cmp -->|Distintos| datap["Problema de datos"]

Figura 16: Si los puntos de código son los mismos, empiece la investigación como un problema de fuente; si difieren, como un problema de datos.

Artículos relacionados

• Introducción a la codificación de texto en Windows - Mojibake al integrar con Linux
• Codificación de caracteres y saltos de línea en Windows - Fundamentos de los caracteres corruptos y CRLF/LF
• Impresión y salida en PDF en aplicaciones empresariales de Windows ── cómo elegir entre System.Drawing.Printing, WPF y bibliotecas de informes
• Internacionalización de aplicaciones WinForms/WPF — la práctica de resx, ensamblados satélite y el cambio de cultura
• El CSV no es «solo texto»: guía práctica del manejo de CSV en aplicaciones empresariales con C# (codificación de caracteres, compatibilidad con Excel, protección contra inyección)
• Introducción a la accesibilidad en aplicaciones Windows — UI Automation y cómo prepararse para la obligatoriedad del ajuste razonable

Ámbitos de consultoría relacionados

KomuraSoft LLC se ocupa del diseño y la investigación del tratamiento de caracteres en sistemas empresariales. Trabajamos desde la capa de código y desde la capa de fuente: aislar la causa de síntomas como «el carácter difiere en pantalla y en el informe» o «un nombre se volvió □ tras la migración», inventariar gaiji y construir tablas de caracteres de sustitución en la migración desde sistemas legado, diseñar el conjunto de caracteres aceptado para sistemas que tratan nombres de personas, y revisar la configuración de incrustación de fuentes de informes y PDF.

• Desarrollo de aplicaciones Windows
• Reutilización y migración de activos existentes
• Consultoría técnica y revisión de diseño
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Por qué el mismo carácter 葛 se ve distinto según el PC o el informe impreso?

Lo más probable es que sea una diferencia de glifos de fuente, no mojibake. JIS X 0213:2004 (JIS2004) cambió los glifos de ejemplo de 168 kanji a las formas estándar de imprenta, y Windows también hizo de los glifos JIS2004 el valor predeterminado en MS Gothic, MS Mincho y otras a partir de Vista. 葛, 辻 y 飴 son ejemplos representativos: el punto de código Unicode (los datos) sigue siendo el mismo, y solo cambia el glifo que contiene la fuente (el aspecto). Compare los datos y coinciden; que una imagen de informe de la época de XP y la pantalla de un PC nuevo no coincidan en la forma es el comportamiento especificado. Si quiere que los glifos también coincidan, use la misma fuente en pantalla y en el informe, o especifique el glifo con un selector de variante de ideograma.

¿Si usamos selectores de variantes de ideogramas (IVS), se resuelve todo problema de glifo en los nombres de personas?

No. IVS es un mecanismo que coloca un selector a partir de U+E0100 justo después del carácter base para especificar el glifo como dato, y el glifo indicado solo se muestra cuando coinciden una fuente compatible como IPAmj Mincho y una aplicación compatible. En un entorno sin compatibilidad, el comportamiento correcto es que el selector se ignore y se muestre el glifo predeterminado del carácter base; en algunos entornos el selector también puede verse como □. Además, un carácter con IVS puede ocupar hasta cuatro unidades de código en UTF-16, lo que afecta al recuento de caracteres, al recorte y al diseño de la longitud de las columnas de la base de datos. Si lo introduce, confirme el alcance de compatibilidad en visualización, impresión y cada sistema posterior antes de usarlo.

¿Se puede mostrar en otro PC o en un PDF un carácter registrado como gaiji (EUDC)?

En principio, no. Un gaiji es un mecanismo en el que el usuario registra un glifo en el archivo eudc.tte de ese PC en un punto de código del área de uso privado de Unicode (a partir de U+E000), de modo que en otro PC el mismo punto de código está indefinido o es otro glifo. Por eso el destino de los gaiji es convertirse en □ o verse como otro carácter en cuanto llegan al correo, a un PDF o a otro sistema. Si ya tiene datos que contienen gaiji, el camino realista en la migración es localizar cada uso del área de uso privado, construir una tabla de correspondencia hacia caracteres Unicode ordinarios o selectores de variantes de ideogramas, y sustituirlos. En un sistema nuevo se debe evitar crear gaiji nuevos.

¿Hasta dónde debería aceptar un sistema empresarial los caracteres de los nombres de personas?

El primer paso es decidir el conjunto de caracteres que se acepta y dejarlo explícito como especificación. El registro familiar contiene unos 56.000 caracteres unificados del koseki, y los sistemas gubernamentales conformes al estándar avanzan hacia los caracteres estándar de trámites administrativos, una ampliación de la plataforma de información de caracteres, pero un sistema empresarial general no tiene obligación de aceptar el mismo nivel sin límite. Un diseño realista decide un alcance como «hasta el rango de JIS X 0213» o «sin selectores de variantes de ideogramas ni área de uso privado», valida en la entrada y trata lo que quede fuera de rango con un aviso o una representación alternativa. Solo los sistemas que intercambian datos con sistemas de la administración o con ayuntamientos necesitan seguir la evolución de los caracteres estándar de trámites administrativos y los requisitos de intercambio basados en JIS X 0221.

¿Cómo hacemos para que un informe impreso o un PDF muestre los mismos caracteres que la pantalla?

Lo básico es especificar la misma fuente en pantalla y en el informe, e incrustar la fuente en el PDF. Si las fuentes difieren, los mismos datos pueden producir glifos distintos, y si el PC de quien visualiza no tiene la fuente, se dibuja con una fuente sustituta y el aspecto se rompe. Si se puede incrustar o no lo decide la licencia de la fuente (OpenType fsType); compruébelo usted mismo en lugar de dejarlo en manos de la biblioteca de informes. La incrustación de subconjunto, que solo incrusta los caracteres usados, también mantiene el tamaño del archivo bajo control. Si hay un requisito de conservación a largo plazo, considere PDF/A, donde la incrustación de fuentes es obligatoria.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.