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

«El carácter “葛” del listado de clientes se ve con una forma distinta en la pantalla y en el informe impreso. El cliente se quejó pensando que los datos estaban dañados.» En el mantenimiento de sistemas empresariales, este tipo de consulta no es raro. Otra muy habitual es: «En un documento que se presenta a la administración no aparece el carácter del nombre. En el PC antiguo sí salía, pero al cambiarlo se convirtió en □.»

En el trabajo diario, a ambos casos se les suele llamar «mojibake» (caracteres corruptos), pero son problemas distintos del mojibake que se produce por incompatibilidad de codificación. En el primer caso, los datos no han cambiado ni un solo bit y solo cambia el aspecto; en el segundo, se ha perdido un «carácter externo» que solo existía en ese PC.

flowchart TB
    accTitle: La verdadera naturaleza de dos consultas frecuentes
    accDescr: La consulta sobre la forma distinta de un kanji en pantalla e informe es un caso en el que los datos no cambian pero el aspecto sí, y la consulta sobre el carácter que se vuelve □ al cambiar de PC es un caso en el que se pierde un carácter externo que solo existía en ese PC; ambos son problemas distintos de los mojibake por incompatibilidad de codificación
    c1["Consulta 1: la forma difiere entre pantalla e informe"] --> r1["Los datos no cambian, solo el aspecto"]
    c2["Consulta 2: se volvió □ al cambiar de PC"] --> r2["Se perdió un carácter externo exclusivo de ese PC"]
    r1 --> diff["Problema distinto del mojibake por codificación"]
    r2 --> diff

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

La promesa de este artículo es sencilla. Si separa el código de carácter (la capa de datos) de la fuente (la capa de aspecto), la mayoría de los problemas de caracteres en japonés se pueden aclarar. Repasamos, en una forma útil para desarrolladores de sistemas empresariales y responsables de sistemas de información, el cambio de formas de JIS2004, el selector de variante de ideograma (IVS), los caracteres externos (EUDC), la infraestructura de caracteres de la administración, y la selección e incrustación de fuentes.

El «mojibake» propiamente dicho que se produce en la conversión entre Shift_JIS y UTF-8 ya se trata en otro artículo, así que este se centra en el problema de que «el código va y vuelve correctamente, pero el aspecto o la posibilidad de visualización se desajustan».

1. Conclusión inicial

• «Mojibake» y «diferencia de forma» son problemas distintos. El mojibake es un accidente de la capa de datos por una mala interpretación de la secuencia de bytes; la diferencia de forma es un accidente de la capa de aspecto debido a diferencias en los glifos de la fuente, y la solución es completamente distinta en cada caso.
• Aunque el punto de código Unicode sea el mismo, la forma que se muestra depende de la fuente. Con JIS X 0213:2004 se cambiaron las formas de ejemplo de 168 caracteres, entre ellos «葛», «辻» y «飴», a la forma estándar de imprenta, y desde Windows Vista las fuentes MS Gothic/MS Mincho adoptaron las formas de JIS2004 como predeterminadas.¹²
• El medio estándar para fijar la forma como dato es el selector de variante de ideograma (IVS). Se especifica la forma mediante la secuencia de carácter base más un selector a partir de U+E0100, y colecciones como Adobe-Japan1, Hanyo-Denshi y Moji_Joho están registradas en el IVD de Unicode.³⁴
• En entornos sin compatibilidad, lo correcto es que el selector de IVS se ignore y se muestre la forma predeterminada del carácter base. Sin embargo, un carácter con IVS puede ocupar hasta 4 unidades de código en UTF-16, por lo que hay que prestar atención al implementar el conteo y el recorte de caracteres.⁵
• El carácter externo (EUDC) tiene el destino de «solo poder mostrarse en ese PC». No hay ningún acuerdo de significado sobre los puntos de código del área de uso privado, y la forma registrada en eudc.tte no acompaña a los datos a otro PC, correo o PDF.⁶⁷
• Un sistema que trate nombres de personas debe decidir y dejar explícito el conjunto de caracteres que acepta. La administración avanza, sobre la base de los caracteres unificados del registro familiar y la Infraestructura de Información de Caracteres, hacia el uso de los «caracteres estándar de trámites administrativos» en los sistemas conformes al estándar.⁸⁹¹⁰
• En informes y PDF, lo básico es «alinear la fuente con la pantalla e incrustarla». Si se puede incrustar o no depende de la licencia de la fuente (fsType), y en PDF/A, para conservación a largo plazo, la incrustación de fuentes es obligatoria.¹¹¹²
• No aplique alegremente la normalización (NFKC) a los datos de nombres de personas. La unificación de ancho completo/medio y la sustitución de caracteres de compatibilidad pueden hacer perder distinciones que deben conservarse.¹³

Resumido en una frase: «qué secuencia de bytes se guarda» es un problema de diseño de datos, y «cómo se ve eso» es un problema de diseño de fuentes. Si se discuten estos dos aspectos mezclados, hasta los problemas que se pueden resolver dejan de poder resolverse.

2. Separar los datos del aspecto: puntos de código y glifos

En Unicode, cada carácter se representa mediante un número llamado punto de código. «葛» es U+845B, y ese número es el mismo en cualquier PC. En cambio, cómo se dibuja ese número en pantalla o en papel lo decide el glifo (la forma) que contiene la fuente. Que el mismo U+845B tenga detalles distintos en la Fuente A y en la Fuente B es un comportamiento normal.

Partiendo de estas dos capas, los síntomas que se ven en el trabajo diario se pueden clasificar así.

Como pista para distinguir uno de otro, conviene recordar la diferencia entre «�» y «□». El «�» de U+FFFD (REPLACEMENT CHARACTER) es el rastro de un fallo de conversión en la capa de datos, y el carácter original ya se ha perdido. En cambio, «□» suele significar que los datos siguen intactos pero la fuente no tiene el glifo, y cambiar de fuente puede resolverlo.

flowchart TB
    accTitle: Cómo distinguir el síntoma según se vea � o □
    accDescr: Cuando un carácter no se muestra bien, � es el rastro de un fallo de conversión en la capa de datos donde el carácter original ya se perdió, mientras que □ suele significar que los datos siguen intactos pero la fuente no tiene el glifo, por lo que cambiar de fuente puede resolverlo
    symptom["El carácter no se muestra bien"] --> which{"¿Qué se ve?"}
    which -->|Se ve �| datalayer["Incidente en la capa de datos"]
    datalayer -.-> lost["Rastro de un fallo de conversión（el carácter original se perdió）"]
    which -->|Se ve □| viewlayer["Incidente en la capa de aspecto"]
    viewlayer -.-> noglyph["La fuente simplemente no tiene el glifo"]
    noglyph --> fixable["Cambiar de fuente puede mostrarlo"]

Figura 2: El «�» es señal de un accidente en la capa de datos, y el «□» de un accidente en la capa de aspecto; según cuál se vea, cambia por dónde empezar a investigar.

Los fundamentos de la codificación en sí (CP932 y UTF-8, el BOM, los caracteres de fin de línea) se tratan en «Introducción a los códigos de caracteres de Windows - Mojibake al conectar con Linux» y en «Códigos de caracteres y fin de línea en Windows - Fundamentos de mojibake y CRLF/LF». De aquí en adelante nos ocupamos de la capa de aspecto y de los problemas que surgen en su frontera.

3. De JIS90 a JIS2004: la forma cambió con el mismo código

La verdadera causa de la consulta inicial, «la forma de “葛” es distinta entre la pantalla y el informe», suele estar aquí.

A raíz de la «Tabla de Formas de Kanji fuera de la Lista Estándar» que el Consejo de la Lengua Japonesa presentó en 2000, la revisión de 2004 de JIS X 0213:2004 (conocida como JIS2004) cambió las formas de ejemplo de 168 kanji a la forma estándar de imprenta, cercana a la llamada forma del Kangxi Zidian. «葛», «辻», «飴», «芦», «溢» y «餅» son ejemplos representativos.¹

Windows se alineó con esto, y desde Windows Vista las fuentes MS Gothic/MS Mincho (y la recién creada Meiryo) adoptaron las formas de JIS2004 como predeterminadas. La MS Gothic actual también tiene como forma predeterminada la basada en JIS2004, con acceso a las formas de la época JIS90 a través de la característica OpenType jp90.²¹

flowchart TB
    accTitle: Configuración actual de las formas de MS Gothic
    accDescr: Desde Vista, MS Gothic usa las formas de JIS2004 como predeterminadas, y a través de la característica OpenType jp90 se puede acceder a las formas de la época JIS90
    msg["MS Gothic（desde Vista）"] --> def["Forma predeterminada: basada en JIS2004"]
    msg --> feat["Vía característica jp90"]
    feat --> old["Formas de la época JIS90"]

Figura 3: La MS Gothic actual tiene como forma predeterminada la de JIS2004, y con la característica jp90 se puede cambiar a la forma JIS90.

Aquí lo importante es que lo único que cambió fue la fuente; los datos no cambiaron en absoluto.

• El punto de código de «葛» sigue siendo U+845B tanto en XP como en Windows 11
• En XP (forma JIS90) se mostraba una forma simplificada con «ヒ» dentro de «勹», y desde Vista (forma JIS2004) se muestra una forma que añade «人» en el interior
• Por eso, entre una imagen escaneada de un informe impreso con el sistema antiguo y la pantalla de un PC nuevo, la forma del carácter no coincide, aunque al comparar los datos coinciden por completo

Lo mismo ocurre con el número de puntos del radical shinnyō en «辻» o con la forma del radical de comida en «飴». Sin conocer esta historia, es fácil que la investigación derive erróneamente hacia «los datos se dañaron en la migración». Cuando le digan que el aspecto de un carácter cambió antes y después de una migración, lo correcto es comparar primero el punto de código, y si coincide, sospechar de una diferencia de forma en la fuente.

flowchart TB
    accTitle: El mismo punto de código puede cambiar de forma según la fuente
    accDescr: El punto de código U+845B es el mismo en XP y en Windows 11; solo cambia la forma mostrada entre una fuente con forma JIS90 y una con forma JIS2004, y al comparar los datos coinciden por completo
    cp["Punto de código U+845B"] --> f90["Fuente con forma JIS90（XP）"]
    cp --> f04["Fuente con forma JIS2004（desde Vista）"]
    f90 --> g90["Forma simplificada del radical interior"]
    f04 --> g04["Forma estándar de imprenta con el trazo interior completo"]
    g90 -.-> same["Los datos coinciden por completo"]
    g04 -.-> same

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

Cabe señalar que, como el carácter en sí no cambió, ambas formas son «el mismo carácter». Sin embargo, en el caso de los nombres de personas hay casos en los que el propio interesado o el ayuntamiento insiste en una forma concreta, y a esa necesidad de distinguirlo «como dato» responde el IVS, que se explica a continuación.

4. Selector de variante de ideograma (IVS): especificar la forma como dato

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» para especificar como dato la variante de forma. Como selectores se usan U+E0100–U+E01EF (VS17–VS256).³

Qué forma indica cada secuencia de «carácter base + selector» lo determina un registro llamado IVD (Ideographic Variation Database), gestionado por el Consorcio Unicode. Las colecciones principales son las siguientes.⁴

Por ejemplo, la documentación de Microsoft menciona el caso en el que U+845B por sí solo, «葛», se usa en la grafía de la estación Nishi-Kasai, mientras que U+845B seguido de U+E0100 (VS17) se usa en la grafía de la ciudad de Katsuragi, en la prefectura de Nara. Con el mismo «葛», se puede distinguir como dato de qué forma se trata.³

flowchart TB
    accTitle: Ejemplo de distinguir el mismo carácter como dato mediante IVS
    accDescr: U+845B solo se usa en la grafía de la estación Nishi-Kasai, y la secuencia U+845B seguida de VS17 se usa en la grafía de la ciudad de Katsuragi; qué secuencia corresponde a qué forma lo determina el registro llamado IVD
    seq1["U+845B solo"] --> gl1["Forma de la grafía de la estación Nishi-Kasai"]
    seq2["U+845B + VS17"] --> gl2["Forma de la grafía de la ciudad de Katsuragi"]
    ivd["IVD（registro）"] -.-> gl1
    ivd -.-> gl2

Figura 5: Aunque sea el mismo «葛», la presencia o ausencia del selector permite distinguir como dato de qué forma se trata.

4.1. Comportamiento en entornos sin compatibilidad

En el lado de la fuente, la correspondencia entre IVS y forma se implementa mediante la tabla cmap de OpenType (format 14).⁵ Si coinciden una fuente compatible (como IPAmj Mincho) y una aplicación compatible, se muestra la forma indicada; si no coinciden, ocurre lo siguiente.

• Comportamiento correcto según la especificación: el selector se ignora y se muestra la forma predeterminada del carácter base (el selector en sí no se ve)
• Aplicaciones antiguas o algunos motores de renderizado: el selector se trata como un carácter desconocido independiente, y aparece un □ adicional

Es decir, IVS está diseñado para que «aunque se degrade, el carácter base se siga leyendo», pero que se muestre según la forma indicada depende del entorno de quien lo recibe. En los sistemas de registro de residentes y de registro familiar de la administración se usa la combinación de fuentes basadas en la Infraestructura de Información de Caracteres más IVS, pero si un sistema empresarial general lo acepta sin más, la forma se pierde en algún punto de la visualización, la impresión o el enlace con otros sistemas.

flowchart TB
    accTitle: Cómo se muestran los datos con IVS
    accDescr: Si coinciden una fuente y una aplicación compatibles, se muestra la forma indicada; si no coinciden, el selector se ignora y se muestra la forma predeterminada del carácter base; en aplicaciones antiguas o algunos motores de renderizado, el selector se trata como carácter desconocido y aparece un □ adicional
    ivs["Carácter base + selector de variante"] --> env{"¿Coinciden fuente y aplicación compatibles?"}
    env -->|Sí| ok["Se muestra la forma indicada"]
    env -->|No| ignore["El selector se ignora y se muestra la forma predeterminada"]
    env -->|Aplicación antigua o cierto renderizado| tofu["Aparece un □ adicional"]
    ignore -.-> spec["Según la especificación, este es el comportamiento correcto"]

Figura 6: IVS permite que, aunque se degrade, el carácter base se siga leyendo, pero si se muestra con la forma indicada depende del entorno de quien lo recibe.

4.2. Consideraciones de implementación: un “carácter” puede ocupar hasta 4 unidades de código

Como los selectores de IVS a partir de U+E0100 son puntos de código de un plano suplementario, en UTF-16 siempre forman un par sustituto (2 unidades de código). Si el carácter base también es un kanji de un plano suplementario (por ejemplo, 𠮟 (U+20B9F), añadido en JIS2004), el carácter base por sí solo ya ocupa 2 unidades de código, de modo que la secuencia que el usuario percibe como «un carácter» llega hasta 4 unidades de código en UTF-16 y hasta 8 bytes en UTF-8.

• En C#, "葛󠄀" (葛 + VS17) da string.Length == 3. Un Substring o un recorte de longitud fija corre el riesgo de partir el carácter base y el selector
• La validación y el recorte del número de caracteres deben hacerse por unidad de grafema (con API como StringInfo), no por unidad de código
• La longitud de columna de la base de datos (en SQL Server, nvarchar(n) se mide en unidades de código UTF-16) debe preverse de 2 a 4 veces el número de caracteres aparente si se va a aceptar IVS
• En la búsqueda y la comparación, la presencia o ausencia del selector produce cadenas distintas. Si buscar «葛» debe encontrar también «葛 + VS17» es algo que hay que decidir como requisito e implementar en consecuencia

flowchart TB
    accTitle: Un "carácter" con IVS y las unidades de código UTF-16
    accDescr: En la secuencia de carácter base más selector de variante que el usuario percibe como un solo carácter, el selector siempre es un par sustituto, y si el carácter base es un kanji de un plano suplementario ocupa otras 2 unidades de código, con lo que el total llega a 4 unidades de código en UTF-16
    one["Carácter que el usuario percibe como uno solo"] --> base["Carácter base"]
    one --> vs["Selector de variante"]
    base -.-> bnote["2 unidades de código si es un kanji de plano suplementario"]
    vs -.-> vnote["Siempre un par sustituto（2 unidades de código）"]
    base --> total["Hasta 4 unidades de código en UTF-16"]
    vs --> total
    total -.-> risk["Riesgo de partirlo por la mitad al cortar en longitud fija"]

Figura 7: Un carácter con IVS puede ocupar hasta 4 unidades de código en UTF-16, y recortarlo por unidad de código es arriesgado.

5. Caracteres externos (EUDC): caracteres que solo se ven en ese PC

El carácter externo es un mecanismo por el cual el propio usuario asigna una forma a un punto de código del área de uso privado de Unicode (PUA: U+E000–U+F8FF, etc.). Los puntos de código del área de uso privado no tienen un significado común a nivel mundial, y el mismo U+E000 puede tener asignado un carácter distinto según el PC o la organización.⁶

En Windows, la forma se crea con el editor de caracteres externos (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 mediante el registro HKEY_CURRENT_USER\EUDC.⁷ En la época de Shift_JIS (CP932), el rango 0xF040–0xF9FC era el área de caracteres externos, y al convertirse a Unicode se corresponde con el área de uso privado.

La consecuencia de este mecanismo es clara.

• El eudc.tte pertenece a ese PC (a ese usuario) y no viaja junto con los datos hacia otra persona
• En el instante en que llega a un correo, PDF, sitio web u otro sistema, se convierte en □ o se ve como otro carácter externo distinto del lado receptor
• Si al migrar de sistema operativo o cambiar de PC se olvida trasladar el eudc.tte, ocurre lo de «el carácter que salía en el PC antiguo ya no aparece»

Aquí está la verdadera causa de la segunda consulta mencionada al principio.

flowchart TB
    accTitle: Por qué un carácter externo solo se ve en ese PC
    accDescr: La forma creada con el editor de caracteres externos se guarda en eudc.tte y se asocia a la fuente mediante el registro de ese PC, de modo que si solo viaja el código del área de uso privado a un correo, PDF u otro sistema, se convierte en □ o se ve como otro carácter
    edit["Crear la forma con el editor de caracteres externos"] --> tte["Guardar en eudc.tte"]
    tte --> reg["Asociar a la fuente mediante el registro"]
    reg --> local["Se puede mostrar en ese PC"]
    tte -.-> stay["eudc.tte no viaja junto con los datos"]
    send["Solo el código del área de uso privado llega al destino"] --> dest["Correo, PDF, otros sistemas"]
    dest --> broken["Se convierte en □ o se ve como otro carácter"]

Figura 8: La forma queda en eudc.tte, y en los datos solo permanece el número del área de uso privado, por lo que el carácter externo se ve roto al salir del PC.

5.1. Solución práctica para sistemas que ya recibieron caracteres externos

El problema surge cuando los datos heredados de un sistema legado ya incluyen caracteres externos mezclados. El procedimiento que nuestra empresa recomienda en proyectos de migración es el siguiente.

1. Investigación: escanear la base de datos y los archivos con una expresión regular sobre el área de uso privado (U+E000–U+F8FF) para identificar los códigos de caracteres externos en uso y su cantidad. Recopilar el eudc.tte de los PC de cada sede para confirmar las formas
2. Identificación: para cada carácter externo, investigar si «se puede representar con un carácter Unicode estándar», «se puede representar con IVS» o «existe un carácter correspondiente en la Infraestructura de Información de Caracteres (MJ)», y crear una tabla de correspondencia de caracteres sustitutos. En la práctica, la mayoría de los casos resultan ser simplemente formas antiguas que se habían creado como caracteres externos JIS
3. Sustitución: reemplazar los datos según la tabla de correspondencia. Solo cuando de verdad no exista un carácter correspondiente, conservarlo como imagen o añadir una nota al registro en cuestión
4. Bloqueo: en el sistema nuevo, rechazar mediante validación la entrada del área de uso privado y no crear caracteres externos nuevos

flowchart TB
    accTitle: Procedimiento de migración para datos que incluyen caracteres externos
    accDescr: Se identifican los caracteres externos en uso escaneando el área de uso privado y recopilando los eudc.tte, se crea una tabla de correspondencia con caracteres sustitutos y se reemplazan los datos, y en el sistema nuevo se bloquea con validación la entrada del área de uso privado para no crear caracteres externos nuevos
    st1["Investigación: escanear el área de uso privado"] --> st2["Identificación: crear tabla de caracteres sustitutos"]
    st2 --> st3["Sustitución: reemplazar según la tabla"]
    st3 --> st4["Bloqueo: no crear caracteres externos nuevos"]
    st1 -.-> tte["Recopilar eudc.tte de cada sede"]
    st2 -.-> nomap["Solo si no hay correspondencia: imagen o nota"]

Figura 9: La migración de caracteres externos avanza en cuatro etapas (investigación, identificación, sustitución y bloqueo), y no se crean caracteres externos nuevos.

En el lado de la administración la orientación es la misma: se ha planteado la política de identificar de forma unívoca los caracteres externos que cada ayuntamiento ha creado por su cuenta (se dice que en todo el país suman unos 2 millones) con los caracteres estándar de trámites administrativos que se mencionan más adelante, y dejar de usarlos.¹⁰ «No aumentar los caracteres externos e identificarlos con un conjunto de caracteres estandarizado» se está convirtiendo en la práctica habitual en las migraciones, tanto en el sector público como en el privado.

6. La infraestructura de caracteres de la administración: del Kosekitōitsu Moji al Gyōsei Jimu Hyōjun Moji

En el diseño de un sistema que trate nombres de personas, conocer la infraestructura de caracteres del lado de la administración sirve como criterio para decidir «hasta dónde aceptar».

En los sistemas centrales (sistemas conformes al estándar) de los ayuntamientos se ha convertido en especificación estándar un esquema de dos niveles: usar los caracteres estándar de trámites administrativos para el intercambio de información de nombres, y conectarse dentro del rango de JIS X 0213:2012 con sistemas externos que no tienen normas de enlace unificadas, como los smartphones.¹⁰ Esta misma estructura, «conservar internamente un conjunto de caracteres amplio e intercambiar con el exterior dentro de un rango que se pueda mostrar en un entorno común», también sirve de referencia para los sistemas del sector privado.

flowchart TB
    accTitle: El esquema de dos niveles de enlace de los sistemas conformes al estándar
    accDescr: Los sistemas conformes al estándar de los municipios usan los caracteres estándar de trámites administrativos para el intercambio de información de nombres, y con sistemas externos sin normas de enlace unificadas, como los smartphones, se conectan dentro del rango de JIS X 0213:2012
    sys["Sistema municipal conforme al estándar"] --> renkei["Intercambio de información de nombres"]
    sys --> gaibu["Enlace con sistemas externos"]
    renkei --> mjp["Caracteres estándar de trámites administrativos"]
    gaibu --> jis["Rango de JIS X 0213:2012"]
    gaibu -.-> sumaho["Contrapartes sin norma, como smartphones"]
    mjp -.-> naibu["Internamente se conserva un conjunto de caracteres amplio"]

Figura 10: El enlace con la administración usa los caracteres estándar de trámites administrativos, y el enlace externo sin normas usa el esquema de dos niveles de JIS X 0213:2012.

Como pauta práctica para un sistema empresarial general, recomendamos lo siguiente.

• Decidir el conjunto de caracteres aceptado y dejarlo explícito tanto en el documento de especificaciones como en la validación de entrada. Por ejemplo, «el rango de JIS X 0213:2012», «no se admiten el área de uso privado ni los caracteres combinados», «no se acepta IVS (o se acepta, pero la visualización solo se garantiza en un entorno con IPAmj Mincho)»
• No aceptar sin límite. Un diseño de tipo «como es Unicode, entra cualquier cosa» siempre acaba fallando en algún punto de la visualización, la impresión o el enlace
• Definir de antemano la operación para los caracteres fuera de rango. Desde la regla de sustitución por una grafía alternativa (kanji moderno, katakana) hasta el texto para explicárselo al interesado forman parte de la especificación del sistema
• Cuando la contraparte de enlace, como la administración o una entidad financiera, tenga su propia norma de conjunto de caracteres, tomarla como referencia y ajustarse a ella

flowchart TB
    accTitle: Diseño y operación del conjunto de caracteres aceptado
    accDescr: Se decide el conjunto de caracteres aceptado y se especifica tanto en el documento de especificaciones como en la validación de entrada; los caracteres dentro del rango se aceptan, y para los que quedan fuera se define la operación, incluida la regla de sustitución por una grafía alternativa y el texto para explicárselo a la persona
    decide["Decidir el conjunto de caracteres aceptado"] --> spec["Especificarlo en el documento"]
    decide --> valid["Especificarlo en la validación de entrada"]
    valid --> range{"¿Está dentro del rango?"}
    range -->|Sí| ok["Se acepta"]
    range -->|No| alt["Se sustituye por una grafía alternativa"]
    alt -.-> word["El texto para explicárselo a la persona también es parte de la especificación"]

Figura 11: El conjunto de caracteres aceptado se especifica tanto en el documento como en la validación de entrada, y se define de antemano la operación de los que quedan fuera de rango.

7. Selección e incrustación de fuentes: alinear pantalla e informes

7.1. Características de las fuentes habituales

Lo importante en la selección no es el gusto por el estilo, sino «si esa fuente existe en todos los entornos implicados en la visualización, la impresión y la generación de PDF». Las fuentes complementarias japonesas de Windows 10/11 (como BIZ UD) pueden no estar instaladas según la configuración, y en una arquitectura que genera PDF en el lado del servidor, la disponibilidad de la fuente en el servidor influye directamente.

flowchart TB
    accTitle: Entornos que hay que verificar al seleccionar una fuente
    accDescr: Al seleccionar una fuente, más que el gusto por el estilo, importa si esa fuente existe en todos los entornos implicados en la visualización, la impresión y la generación de PDF, y la disponibilidad de fuentes complementarias o de la fuente en el servidor influye directamente
    cand["Fuente candidata"] --> exist["¿Existe en todos los entornos?"]
    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 disponibilidad de la fuente en el servidor influye directamente"]

Figura 12: La fuente se elige más por si está presente en todos los entornos de visualización, impresión y generación de PDF que por el gusto tipográfico.

7.2. Fundamentos del diseño de informes: alinear e incrustar

• Especificar la misma fuente en pantalla y en el informe. Si la fuente es distinta, la forma puede verse distinta aunque los datos sean los mismos, y eso es lo que provoca la queja mencionada al principio. Una configuración como «pantalla en Meiryo, informe en MS Mincho» debería, como mínimo, verificarse para confirmar que no hay diferencia de forma en los 168 caracteres de JIS2004
• Incrustar la fuente en el PDF. Si no se incrusta, quien lo visualiza dibuja con la fuente que tenga a mano, y no solo la forma sino también el diseño puede cambiar
• Si se puede incrustar o no lo determina la licencia. Las fuentes OpenType declaran el permiso de incrustación (Installable / Restricted / Preview & Print / Editable, prohibición de subconjunto, etc.) en el campo fsType, y no se debe incrustar una fuente cuya incrustación no esté permitida.¹¹ En fuentes comerciales, es imprescindible verificar el contrato
• Usar la incrustación de subconjunto como norma. Incrustar solo los glifos de los caracteres usados evita cargar con toda la fuente japonesa (de varios MB a varias decenas de MB)
• Si hay requisito de conservación a largo plazo, usar PDF/A. PDF/A (ISO 19005) es un estándar que autocontiene dentro del archivo los recursos necesarios para la visualización, y exige la incrustación de fuentes.¹² Es también el método más seguro para evitar que «dentro de 10 años, al abrirlo, la forma haya cambiado»

flowchart TB
    accTitle: Flujo de decisión para incrustar fuentes
    accDescr: Antes de incrustar una fuente en un PDF se verifica la licencia de incrustación en fsType; si está permitida, lo habitual es la incrustación de subconjunto, y si hay requisito de conservación a largo plazo se considera PDF/A, que exige la incrustación
    emb["Incrustar la fuente en el PDF"] --> lic{"¿fsType permite la incrustación?"}
    lic -->|Permitida| sub["Lo habitual: incrustación de subconjunto"]
    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 parte de verificar la licencia en fsType, y la línea base es la incrustación de subconjunto junto con PDF/A.

La forma de elegir el mecanismo de implementación para la impresión y la salida a PDF se trata en detalle en «Impresión y salida a PDF en aplicaciones empresariales de Windows».

8. Vinculación y sustitución de fuentes: el fenómeno de “mezcla de fuentes distintas”

Cuando un carácter no tiene glifo en la fuente indicada, el comportamiento predeterminado de los motores de renderizado modernos no es dejarlo sin mostrar, sino dibujarlo con otra fuente. En GDI, esto lo gestiona la «vinculación de fuentes» definida en el registro (FontLink\SystemLink), y en DirectWrite, WPF o los navegadores, la «sustitución de fuentes» (font fallback).¹⁵

flowchart TB
    accTitle: Flujo de la vinculación y sustitución de fuentes
    accDescr: Si la fuente indicada tiene el glifo, se muestra tal cual; si no lo tiene, se dibuja con la fuente de vinculación o de sustitución, y si ninguna tiene el glifo aparece □, aunque en la mayoría de los casos los datos siguen intactos
    disp["Mostrar el carácter"] --> has{"¿La fuente indicada tiene el glifo?"}
    has -->|Sí| draw["Se muestra con la fuente indicada"]
    has -->|No| fb{"¿Está en la fuente vinculada o de sustitución?"}
    fb -->|Sí| alt["Se dibuja con otra fuente"]
    alt -.-> mixed["Causa de que el estilo tipográfico parezca mezclado"]
    fb -->|No| tofu["Se muestra □（tofu）"]
    tofu -.-> alive["Los datos suelen seguir intactos"]

Figura 14: El □ es el rastro de un fallo de sustitución, y el éxito o fracaso del dibujo alternativo marca la diferencia entre «se mezcla» y «tofu».

Conocer este mecanismo permite explicar los siguientes fenómenos frecuentes.

• Los números/letras latinas y el japonés tienen un estilo distinto: al indicar primero una fuente occidental, solo la parte en japonés se dibuja con la fuente japonesa de vinculación o de sustitución
• Dentro de un texto japonés, solo los kanji adquieren una forma de estilo chino: la sustitución se resolvió hacia una fuente china. Es frecuente en aplicaciones o páginas web que no transmiten correctamente la información de idioma (el atributo lang o la configuración regional)
• Aparece tofu (□): ni la fuente indicada ni las de sustitución tienen el glifo. Es decir, el □ es el «rastro de un fallo» de la sustitución, y en la mayoría de los casos los datos siguen intactos

La sustitución es un mecanismo de rescate, y no sustituye a elegir la fuente correcta desde el principio.¹⁵ En una aplicación empresarial, es sano plantear que «las rutas principales de visualización e impresión se completan solo con la fuente diseñada, y la sustitución es un seguro para caracteres imprevistos». Sobre el criterio de selección de fuentes en interfaces multilingües, consulte también «Localización de aplicaciones WinForms/WPF».

9. Lista de verificación de implementación para aplicaciones empresariales

Por último, resumimos en una tabla los puntos que hay que verificar en cada capa, desde la entrada hasta el enlace.

Especialmente la normalización es una trampa que encaja con el tema mismo de este artículo: un proceso aplicado «con buena intención» puede aplastar la distinción entre variantes y entre ancho completo y medio. El principio es el original tal cual, y el procesamiento sobre una copia. Los incidentes de código de caracteres en el enlace por CSV se tratan en detalle en «El CSV no es «solo texto»».

flowchart TB
    accTitle: Conservar el original tal cual y normalizar solo la copia
    accDescr: La cadena introducida se guarda como original tal como se ingresó, y la normalización se aplica solo a una copia limitada a usos como la generación de claves de búsqueda; aplicar NFKC al original hace que se pierdan distinciones entre variantes y entre caracteres de ancho completo y medio
    input["Cadena introducida"] --> orig["Original: se guarda tal cual"]
    input --> copy["Copia: se normaliza según el uso"]
    copy -.-> use["Por ejemplo, generación de claves de búsqueda"]
    orig -.-> ng["Aplicar NFKC al original destruye las distinciones"]

Figura 15: La normalización se aplica a una copia con un uso limitado, y el original se guarda tal como se ingresó.

10. Resumen

• Ante un problema de caracteres, sepárelo primero en «capa de datos (código de carácter)» y «capa de aspecto (fuente)». El «�» es señal de un accidente en la capa de datos, y el «□», de un accidente en la capa de aspecto.
• Con JIS X 0213:2004 cambiaron las formas de ejemplo de 168 caracteres, y desde Vista Windows adopta las formas de JIS2004 como predeterminadas. Que «葛», «辻» y «飴» tengan una forma distinta según el entorno no es una corrupción de datos, sino historia de fuentes.
• El medio estándar para fijar la forma como dato es IVS, pero si no coinciden una fuente compatible y una aplicación compatible, se cae a la forma predeterminada. No olvide tampoco el impacto en la implementación de que un carácter pueda ocupar hasta 4 unidades de código UTF-16.
• El carácter externo (EUDC) es un recurso propio de ese PC y no puede viajar junto con los datos. La solución práctica en la migración es identificarlo, sustituirlo mediante una tabla de correspondencia hacia caracteres estándar o hacia IVS, y dejar de crear nuevos.
• Un sistema que trate nombres de personas debe decidir y dejar explícito el conjunto de caracteres que acepta. La administración avanza hacia la estandarización con los caracteres estándar de trámites administrativos, tomando como base los caracteres unificados del registro familiar y la Infraestructura de Información de Caracteres, y los sistemas que se conectan con ella deben seguir esa evolución.
• En informes y PDF, lo básico es «alinear la fuente con la pantalla, verificar la licencia e incrustarla». 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 a CP932 son los tres puntos que silenciosamente dañan las variantes y los caracteres externos. Adopte como principio conservar el original y procesar por unidad de grafema.

La próxima vez que le digan que «el carácter es distinto», empiece por preguntarse esto: ¿el punto de código es el mismo o distinto? Si es el mismo, es un problema de fuente; si es distinto, es un problema de datos. Con este único paso, dejará de equivocarse en el punto de partida de la investigación.

flowchart TB
    accTitle: La primera pregunta que define el punto de partida de la investigación
    accDescr: Cuando alguien dice que un carácter se ve distinto, primero se compara si el punto de código es el mismo o diferente, y se investiga como problema de fuente si coincide o como problema de datos si no coincide
    said["Alguien dice que el carácter se ve distinto"] --> cmp{"¿El punto de código es el mismo?"}
    cmp -->|Mismo| fontp["Problema de fuente"]
    cmp -->|Diferente| datap["Problema de datos"]

Figura 16: Si el punto de código es el mismo, la investigación empieza como problema de fuente; si es distinto, como problema de datos.

Artículos relacionados

• Introducción a los códigos de caracteres de Windows - Mojibake al conectar con Linux
• Códigos de caracteres y fin de línea en Windows - Fundamentos de mojibake y CRLF/LF
• Impresión y salida a PDF en aplicaciones empresariales de Windows — Cómo elegir entre System.Drawing.Printing / WPF / librerías de informes
• Localización de aplicaciones WinForms/WPF — resx, ensamblados satélite y cambio de cultura en la práctica
• El CSV no es «solo texto» — Manejo práctico de CSV en aplicaciones C# (código de caracteres, compatibilidad con Excel, protección contra inyección)
• Introducción a la accesibilidad en aplicaciones de Windows — Preparándose para UI Automation y la obligatoriedad de los ajustes razonables

Áreas de consultoría relacionadas

KomuraSoft LLC se dedica al diseño e investigación en torno a los caracteres en sistemas empresariales. Abordamos, desde la capa de código y la de fuente a la vez, la separación de causas en síntomas como «el carácter es distinto entre pantalla e informe» o «tras la migración el nombre se volvió □», la investigación de caracteres externos y la creación de tablas de caracteres sustitutos al migrar desde sistemas legados, el diseño del conjunto de caracteres aceptado en sistemas que tratan nombres de personas, y la revisión de la configuración de incrustación de fuentes en informes y PDF.

• Desarrollo de aplicaciones Windows
• Aprovechamiento de activos existentes y soporte de migración
• 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 con una forma distinta según el PC o el informe?

Lo más probable es que no se trate de mojibake, sino de una diferencia de forma entre fuentes. Con la revisión JIS X 0213:2004 (JIS2004), las formas de ejemplo de 168 kanji se cambiaron a la forma estándar de imprenta, y desde Windows Vista las fuentes MS Gothic/MS Mincho, entre otras, adoptaron las formas de JIS2004 como predeterminadas. «葛», «辻» y «飴» son ejemplos representativos de este cambio: el punto de código Unicode (los datos) sigue siendo el mismo, y lo único que cambia es el glifo (el aspecto) que contiene la fuente. Por eso, al comparar los datos coinciden, y que la forma de una imagen escaneada de un informe de la época de XP no coincida con la pantalla de un PC nuevo es un comportamiento conforme a la especificación. Si quiere que las formas también coincidan, use la misma fuente en pantalla y en el informe, o especifique la forma mediante un selector de variante.

¿El uso del selector de variante de ideograma (IVS) resuelve por completo los problemas de forma de los nombres de personas?

No los resuelve. IVS es un mecanismo que especifica la forma como dato colocando un selector a partir de U+E0100 justo después del carácter base, y solo se muestra según lo indicado cuando coinciden una fuente compatible (como IPAmj Mincho) y una aplicación compatible. En un entorno no compatible, lo correcto según la especificación es que el selector se ignore y se muestre la forma predeterminada del carácter base; según el entorno, el selector incluso puede verse como un □. Además, un solo carácter con IVS puede ocupar hasta 4 unidades de código en UTF-16, lo que afecta también al conteo de caracteres, al recorte de cadenas y al diseño de la longitud de las columnas en la base de datos. Si va a introducirlo, hágalo tras confirmar el alcance de compatibilidad en visualización, impresión y en los sistemas con los que se conecta.

¿Se pueden mostrar en otros PC o en PDF los caracteres registrados como caracteres externos (EUDC)?

En principio, no se pueden mostrar. Los caracteres externos son un mecanismo por el cual el usuario registra una forma en el archivo eudc.tte de ese PC, dentro del área de uso privado de Unicode (U+E000 en adelante), de modo que el mismo punto de código puede quedar indefinido o corresponder a otra forma en un PC distinto. Por eso es inevitable que, al pasar por correo, PDF u otro sistema, se convierta en □ o se vea como un carácter distinto. Si ya tiene a su cargo datos que incluyen caracteres externos, lo más realista es, en el momento de la migración, identificar los usos del área de uso privado y crear una tabla de correspondencia hacia caracteres Unicode estándar o hacia selectores de variante para sustituirlos. En un sistema nuevo se debe evitar crear caracteres externos nuevos.

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

Lo primero es «decidir el conjunto de caracteres que se acepta y dejarlo explícito en la especificación». El registro familiar cuenta con unos 56.000 caracteres unificados del registro familiar, y los sistemas administrativos conformes al estándar tienen la política de usar los caracteres estándar de trámites administrativos, que amplían la Infraestructura de Información de Caracteres, pero un sistema empresarial general no tiene obligación de aceptar sin límite ese mismo nivel. Es realista, por ejemplo, definir el alcance como «hasta el rango de JIS X 0213» o «no se aceptan selectores de variante ni el área de uso privado», validar en la entrada y operar lo que quede fuera de rango con un aviso o una grafía alternativa. Solo los sistemas que se conectan con la administración o con ayuntamientos necesitan seguir de cerca la evolución de los caracteres estándar de trámites administrativos y de los requisitos de enlace basados en JIS X 0221.

¿Qué se debe hacer para que en los informes y PDF aparezca el mismo carácter que en pantalla?

Lo básico es especificar la misma fuente en pantalla y en el informe, e incrustar la fuente en el PDF. Si la fuente es distinta, la forma puede cambiar aunque los datos sean los mismos, y si el PC de quien lo visualiza no tiene esa fuente, se dibuja con una fuente sustituta y el aspecto se desajusta. Si se puede incrustar o no depende de la licencia de la fuente (el campo fsType de OpenType), así que no lo deje solo en manos de la librería de informes: verifíquelo usted mismo. La incrustación de subconjunto, que solo incluye los caracteres usados, también permite mantener el tamaño del archivo bajo control. Si hay un requisito de conservación a largo plazo, considere PDF/A, que exige la incrustación de fuentes.

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.