Pièges des polices et des caractères japonais — Traiter JIS2004, IVS et les gaiji dans les applications métier

« Le caractère 葛 de la liste clients n’a pas le même aspect à l’écran et sur le formulaire imprimé. Le client s’est plaint que les données doivent être corrompues. » — Dans la maintenance des systèmes métier, ce type de consultation n’est pas rare. Une autre, fréquente, est « un caractère d’un nom de personne ne s’affiche pas sur un document que nous soumettons à l’administration. Il s’affichait sur l’ancien PC ; après le remplacement, il est devenu □. »

Les deux tendent à être appelées « mojibake » sur le terrain, mais ce sont un problème différent du mojibake qui vient d’un décalage d’encodage. Dans le premier cas, pas un bit des données n’a changé et seule l’apparence a changé ; dans le second, un « gaiji » qui n’existait que sur ce PC a été perdu.

flowchart TB
    accTitle: Ce que sont vraiment les deux consultations courantes
    accDescr: La consultation selon laquelle 葛 a un aspect différent à l'écran et sur le formulaire est un cas où seule l'apparence a changé alors que les données sont restées les mêmes ; la consultation selon laquelle un caractère est devenu □ après un remplacement de PC est un cas où un gaiji qui n'existait que sur ce PC a été perdu ; les deux sont un problème différent du mojibake par décalage d'encodage
    c1["Consultation 1 : la forme diffère à l'écran et sur le formulaire"] --> r1["Les données sont inchangées ; seule l'apparence a changé"]
    c2["Consultation 2 : il est devenu □ après un remplacement"] --> r2["Un gaiji qui n'existait que sur ce PC a été perdu"]
    r1 --> diff["Un problème différent du mojibake d'encodage"]
    r2 --> diff

Figure 1 : Les deux consultations que l’on tend à appeler « mojibake » sont toutes deux un problème différent d’un décalage d’encodage.

La promesse de cet article est simple. Si vous séparez la couche code de caractère (données) de la couche police (apparence), la plupart des problèmes de caractères japonais deviennent traitables. Du changement de glyphe JIS2004, des sélecteurs de variation idéographique (IVS) et des gaiji (EUDC), en passant par la plateforme de caractères du gouvernement, jusqu’au choix et à l’embarquement des polices, le tout est organisé sous une forme que les développeurs de systèmes métier et le personnel informatique peuvent utiliser pour décider.

Le « mojibake » lui-même qui survient dans la conversion Shift_JIS ↔ UTF-8 est couvert dans des articles existants, donc cet article se concentre sur le problème « les codes font l’aller-retour correctement, mais l’apparence ou l’affichabilité est fausse ».

1. La conclusion, d’abord

• « Mojibake » et « le glyphe est différent » sont des problèmes différents. Le mojibake est un accident à la couche données d’une mauvaise interprétation d’une séquence d’octets ; une différence de glyphe est un accident à la couche apparence d’une différence dans les glyphes qu’une police détient ; les remèdes sont complètement différents.
• Même avec le même point de code Unicode, le glyphe affiché dépend de la police. JIS X 0213:2004 a révisé les glyphes exemplaires de 168 caractères tels que 葛, 辻 et 飴 vers les formes d’impression standard, et Windows aussi a fait des glyphes JIS2004 le défaut dans MS Gothic / MS Mincho à partir de Vista.¹²
• Le moyen standard de figer un glyphe comme donnée est un sélecteur de variation idéographique (IVS). Vous spécifiez un glyphe par la séquence d’un caractère de base plus un sélecteur à partir de U+E0100 ; des collections telles que Adobe-Japan1, Hanyo-Denshi et Moji_Joho (la plateforme d’information sur les caractères) sont enregistrées dans l’IVD d’Unicode.³⁴
• Dans un environnement non compatible, le comportement spécifié d’IVS est que le sélecteur est ignoré et que le glyphe par défaut du caractère de base s’affiche. Un caractère porteur d’IVS, toutefois, peut occuper jusqu’à quatre unités de code en UTF-16, donc les implémentations de comptage de caractères et de découpage demandent de l’attention.⁵
• Les gaiji (EUDC) ont le destin « ils ne peuvent s’afficher que sur ce PC ». Il n’y a pas de signification convenue pour un point de code de la zone à usage privé, et un glyphe enregistré dans eudc.tte ne voyage pas vers un autre PC, vers le courrier, ni vers un PDF.⁶⁷
• Un système qui traite des noms de personnes doit décider du jeu de caractères accepté et le déclarer. Côté gouvernement, en s’appuyant sur les caractères unifiés Koseki et la plateforme d’information sur les caractères, les systèmes conformes à la norme évoluent vers l’usage des « caractères standard pour les affaires administratives ».⁸⁹¹⁰
• Pour les formulaires et les PDF, « aligner la police avec l’écran, et l’embarquer » est la base. Le droit d’embarquement est déterminé par la licence de la police (fsType), et PDF/A pour la conservation à long terme exige l’embarquement de polices.¹¹¹²
• N’appliquez pas à la légère une normalisation (NFKC) aux données de noms de personnes. Unifier pleine chasse et demi-chasse, et remplacer les caractères de compatibilité, fait perdre des distinctions que vous devez conserver.¹³

En une phrase : « quelle séquence d’octets vous stockez » est un problème de conception des données ; « à quoi ça ressemble » est un problème de conception des polices. Si vous discutez les deux mélangés, même les problèmes que vous pourriez corriger deviennent incorrigibles.

2. Penser les données et l’apparence séparément — Points de code et glyphes

En Unicode, un caractère est représenté par un nombre appelé point de code. 葛 est U+845B, et ce nombre est le même sur chaque PC. Comment ce nombre est dessiné à l’écran ou sur le papier, en revanche, est décidé par le glyphe que la police détient. Il est normal que le même U+845B diffère dans les détails de sa forme entre la police A et la police B.

Avec ces deux couches comme prémisse, les symptômes de terrain peuvent se scinder comme suit.

Comme indice pour la scission, il est utile de retenir la différence entre « � » et « □ ». Le « � » de U+FFFD (REPLACEMENT CHARACTER) est une trace d’un échec de conversion à la couche données, et le caractère d’origine est déjà perdu. Le « □ », en revanche, n’est dans beaucoup de cas que le fait que les données sont encore là mais que la police n’a pas de glyphe, et changer la police peut le rendre affichable.

flowchart TB
    accTitle: Scinder le symptôme par � versus □
    accDescr: Lorsqu'un caractère ne s'affiche pas correctement, � est une trace d'un échec de conversion à la couche données dans lequel le caractère d'origine a été perdu ; □ n'est que le fait que les données sont encore là mais que la police n'a pas de glyphe, et changer la police peut le rendre affichable
    symptom["Un caractère ne s'affiche pas correctement"] --> which{"Que voyez-vous ?"}
    which -->|Vous voyez �| datalayer["Un accident à la couche données"]
    datalayer -.-> lost["Une trace d'échec de conversion （le caractère d'origine est perdu）"]
    which -->|Vous voyez □| viewlayer["Un accident à la couche apparence"]
    viewlayer -.-> noglyph["Seulement que la police n'a pas de glyphe"]
    noglyph --> fixable["Changer la police peut le rendre affichable"]

Figure 2 : � est le signe d’un accident à la couche données, □ d’un accident à la couche apparence, et le point d’entrée de l’investigation change.

Les bases des encodages eux-mêmes (CP932 et UTF-8, BOM, codes de fin de ligne) sont couvertes dans « Introduction à l’encodage des caractères sous Windows - Le mojibake qui survient avec Linux » et « Encodage des caractères et fins de ligne sous Windows - Les bases du mojibake et de CRLF/LF ». À partir d’ici, c’est la couche apparence, et les problèmes qui surviennent à sa frontière.

3. De JIS90 à JIS2004 — Le glyphe a changé alors que le code est resté le même

L’identité du « 葛 a un aspect différent à l’écran et sur le formulaire » de l’ouverture est, dans beaucoup de cas, ici.

Suivant le rapport 2000 du Conseil de la langue nationale « Hyogai Kanji Jitaihyo » (la table des formes de caractères pour les kanji hors de la liste joyo), la révision 2004 JIS X 0213:2004 (communément JIS2004) a révisé les glyphes exemplaires de 168 kanji vers les formes d’impression standard, proches des formes dites du dictionnaire Kangxi. 葛, 辻, 飴, 芦, 溢, 餅 et d’autres en sont des exemples représentatifs.¹

Windows s’est aligné et a fait des glyphes JIS2004 le défaut dans MS Gothic / MS Mincho (et le Meiryo nouvellement introduit) à partir de Windows Vista. Le MS Gothic actuel, lui aussi, a un glyphe par défaut fondé sur JIS2004, avec la structure que les glyphes de l’ère JIS90 sont accessibles via la fonctionnalité OpenType jp90.²¹

flowchart TB
    accTitle: La structure des glyphes du MS Gothic actuel
    accDescr: À partir de Vista, MS Gothic a des glyphes JIS2004 comme défaut, et accéder aux glyphes de l'ère JIS90 via la fonctionnalité OpenType jp90 est la structure
    msg["MS Gothic （à partir de Vista）"] --> def["Glyphe par défaut : fondé sur JIS2004"]
    msg --> feat["Via la fonctionnalité jp90"]
    feat --> old["Glyphes de l'ère JIS90"]

Figure 3 : Le MS Gothic actuel a des glyphes JIS2004 comme défaut, et peut basculer vers les glyphes JIS90 avec la fonctionnalité jp90.

Ce qui importe ici, c’est que seule la police a changé ; les données n’ont pas changé du tout.

• Le point de code de 葛 est U+845B à la fois sur XP et sur Windows 11
• Sur XP (glyphes JIS90) il s’affiche dans la forme qui simplifie l’intérieur du radical enveloppant en ヒ ; à partir de Vista (glyphes JIS2004) il s’affiche dans la forme qui écrit aussi 人 à l’intérieur
• Par conséquent, l’image numérisée d’un formulaire imprimé sur l’ancien système et l’affichage à l’écran sur un nouveau PC ne sont pas d’accord sur la forme du caractère. Une comparaison des données correspond complètement

Que le radical shinnyo de 辻 ait un point ou deux, la forme du radical « manger » de 飴, et d’autres, sont la même chose. Si vous ne connaissez pas cette histoire, l’investigation tend à partir dans la mauvaise direction « les données ont été corrompues à la migration ». Quand on vous dit que l’apparence d’un caractère diffère avant et après une migration, comparez d’abord les points de code, et s’ils correspondent, soupçonnez une différence de glyphe de police — c’est le bon ordre.

flowchart TB
    accTitle: Le même point de code, un glyphe différent selon la police
    accDescr: Le point de code U+845B de 葛 reste le même sur XP et sur Windows 11 ; seule la forme affichée change entre une police à glyphes JIS90 et une police à glyphes JIS2004, et une comparaison des données correspond complètement
    cp["Point de code U+845B （葛）"] --> f90["Une police à glyphes JIS90 （XP）"]
    cp --> f04["Une police à glyphes JIS2004 （à partir de Vista）"]
    f90 --> g90["La forme qui simplifie l'intérieur en ヒ"]
    f04 --> g04["La forme d'impression standard qui écrit 人 à l'intérieur"]
    g90 -.-> same["Une comparaison des données correspond complètement"]
    g04 -.-> same

Figure 4 : Seule la police a changé ; le point de code U+845B reste le même dans chaque environnement.

Notez que, parce que le caractère lui-même n’a pas changé, les deux glyphes sont « le même caractère ». Dans les noms de personnes, toutefois, la personne ou une administration insiste parfois sur une forme particulière, et répondre à la demande de distinguer cela « comme donnée » est le sujet suivant, IVS.

4. Sélecteurs de variation idéographique (IVS) — Spécifier un glyphe comme donnée

IVS (Ideographic Variation Sequence) est un mécanisme qui place un point de code invisible appelé « sélecteur de variation idéographique » immédiatement après un kanji, pour spécifier une variante de glyphe comme donnée. Les sélecteurs utilisés sont U+E0100–U+E01EF (VS17–VS256).³

Quelle séquence « caractère de base + sélecteur » renvoie à quel glyphe est décidé par un registre appelé IVD (Ideographic Variation Database), géré par le Unicode Consortium. Les collections principales sont les suivantes.⁴

La documentation de Microsoft, par exemple, donne l’exemple de U+845B seul (葛) utilisé dans l’écriture de la gare de Nishi-Kasai, et de U+845B+U+E0100 (VS17) utilisé dans l’écriture de la ville de Katsuragi, Nara. Le même 葛, mais quel glyphe c’est peut se distinguer comme donnée.³

flowchart TB
    accTitle: Un exemple de distinction du même 葛 comme donnée avec IVS
    accDescr: 葛 comme U+845B seul est utilisé dans l'écriture de la gare de Nishi-Kasai ; la séquence de U+845B suivi de VS17 est utilisée dans l'écriture de la ville de Katsuragi ; quelle séquence renvoie à quel glyphe est décidé par le registre IVD
    seq1["U+845B seul"] --> gl1["Le glyphe utilisé dans l'écriture de la gare de Nishi-Kasai"]
    seq2["U+845B + VS17"] --> gl2["Le glyphe utilisé dans l'écriture de la ville de Katsuragi"]
    ivd["IVD （le registre）"] -.-> gl1
    ivd -.-> gl2

Figure 5 : Même avec le même 葛, la présence ou l’absence d’un sélecteur permet de l’identifier comme donnée.

4.1. Comportement dans un environnement qui ne le prend pas en charge

Côté police, la correspondance entre un IVS et un glyphe est implémentée dans la table cmap OpenType (format 14).⁵ Lorsqu’une police compatible (IPAmj Mincho et d’autres) et une application compatible sont toutes deux présentes, le glyphe spécifié apparaît ; lorsqu’elles ne le sont pas, cela se passe comme suit.

• Le comportement correct spécifié : le sélecteur est ignoré et le glyphe par défaut du caractère de base s’affiche (le sélecteur lui-même est invisible)
• Applications plus anciennes et certaines piles de dessin : le sélecteur est traité comme un caractère inconnu indépendant, et un □ supplémentaire s’affiche

Autrement dit, IVS est conçu pour que « même s’il se dégrade, le caractère de base reste lisible », mais une garantie que « il s’affichera toujours dans le glyphe spécifié » dépend de l’environnement du destinataire. Les systèmes gouvernementaux de registre des résidents et d’état civil utilisent la combinaison d’une police de la plateforme d’information sur les caractères plus IVS, mais si un système métier général l’accepte à la légère, le glyphe tombera quelque part dans l’affichage, l’impression ou un système aval.

flowchart TB
    accTitle: Comment les données porteuses d'IVS s'affichent
    accDescr: Lorsqu'une police compatible et une application compatible sont toutes deux présentes, cela s'affiche dans le glyphe spécifié ; lorsqu'elles ne le sont pas, le sélecteur est ignoré et le glyphe par défaut du caractère de base s'affiche ; dans les applications plus anciennes et certaines piles de dessin, le sélecteur est traité comme un caractère inconnu et un □ supplémentaire s'affiche
    ivs["Base + sélecteur IVS"] --> env{"Police + application compatibles ?"}
    env -->|Oui| ok["Glyphe spécifié"]
    env -->|Non| other{"Comment est-ce dessiné ?"}
    other -->|Ignoré| ignore["Glyphe par défaut"]
    other -->|Ancien / certaines piles| tofu["Un □ supplémentaire"]
    ignore -.-> spec["Correct spécifié"]

Figure 6 : IVS reste lisible comme le caractère de base même s’il se dégrade, mais que le glyphe spécifié apparaisse dépend de l’environnement du destinataire.

4.2. Une mise en garde d’implémentation — « Un caractère » peut occuper jusqu’à quatre unités de code

Les sélecteurs IVS à partir de U+E0100 sont des points de code sur un plan supplémentaire, donc en UTF-16 ils sont toujours une paire de substituts (deux unités de code). Si le caractère de base est un kanji de plan supplémentaire (par exemple 𠮟 (U+20B9F), ajouté dans JIS2004), la base seule est déjà deux unités de code, et la séquence qu’un utilisateur reconnaît comme « un caractère » fait jusqu’à quatre unités de code en UTF-16, et jusqu’à huit octets en UTF-8.

• En C#, "葛󠄀" (葛+VS17) a string.Length == 3. Substring et un découpage à longueur fixe risquent de séparer le caractère de base du sélecteur
• La validation du nombre de caractères et le découpage devraient se faire en unités de graphème (API telles que StringInfo), pas en unités de code
• Pour la longueur de colonne de base de données (nvarchar(n) de SQL Server est en unités de code UTF-16), si vous acceptez IVS, prévoyez deux à quatre fois le nombre apparent de caractères
• Dans la recherche et la comparaison, la présence ou l’absence d’un sélecteur fait une chaîne différente. Qu’une recherche de « 葛 » trouve « 葛+VS17 » est quelque chose que vous devez décider comme exigence et implémenter

flowchart TB
    accTitle: Un caractère porteur d'IVS et les unités de code UTF-16
    accDescr: La séquence d'un caractère de base et d'un sélecteur de variation idéographique qu'un utilisateur reconnaît comme un caractère est toujours une paire de substituts pour le sélecteur, et si le caractère de base est un kanji de plan supplémentaire deux unités de code de plus, pour un maximum de quatre unités de code en UTF-16
    one["Un caractère visible"] --> base["Caractère de base"]
    one --> vs["Sélecteur de variation"]
    base -.-> bnote["+2 si supplémentaire"]
    vs -.-> vnote["Toujours 2 unités de code"]
    base --> total["Jusqu'à 4 unités UTF-16"]
    vs --> total
    total -.-> risk["Coupé dans un découpage fixe"]

Figure 7 : Un caractère porteur d’IVS peut occuper jusqu’à quatre unités de code en UTF-16 ; le découpage par unité de code est dangereux.

5. Gaiji (EUDC) — Des caractères qui ne s’affichent que sur ce PC

Un gaiji est un mécanisme dans lequel un utilisateur assigne un glyphe de son cru à un point de code de la zone à usage privé Unicode (PUA : U+E000–U+F8FF et d’autres). Un point de code de la zone à usage privé n’a pas de signification convenue mondialement ; le même U+E000 peut se voir assigner un caractère différent par PC et par organisation.⁶

Sous Windows, vous créez le glyphe avec l’Éditeur de caractères privés (eudcedit.exe), et il est enregistré dans un fichier de police appelé eudc.tte. Ce fichier est installé comme police cachée et associé à chaque police dans le registre HKEY_CURRENT_USER\EUDC.⁷ À l’ère Shift_JIS (CP932), la plage gaiji était 0xF040–0xF9FC, et à la conversion vers Unicode elle est mappée vers la zone à usage privé.

La conséquence de ce mécanisme est claire.

• eudc.tte appartient à ce PC (cet utilisateur) et ne voyage pas vers l’autre partie avec les données
• Dès qu’il est passé au courrier, à un PDF, au Web ou à un autre système, il devient □ ou ressemble au gaiji différent de l’autre côté
• Si vous oubliez de migrer eudc.tte dans une migration d’OS ou un remplacement de PC, « un caractère qui s’affichait sur l’ancien PC ne s’affiche plus » survient

C’est l’identité de la deuxième consultation de l’ouverture.

flowchart TB
    accTitle: Pourquoi les gaiji ne s'affichent que sur ce PC
    accDescr: Un glyphe créé dans l'Éditeur de caractères privés est enregistré dans eudc.tte et associé aux polices dans le registre de ce PC, donc si seul le code de la zone à usage privé est passé au courrier, à un PDF ou à un autre système, il devient □ ou ressemble à un caractère différent
    edit["Créer un glyphe PUA"] --> tte["Enregistrer dans eudc.tte"]
    edit -.-> editN["Éditeur de car. privés"]
    tte --> reg["Association de police du registre"]
    reg --> local["S'affiche sur ce PC"]
    tte -.-> stay["eudc.tte reste derrière"]
    send["Seul le code PUA part"] --> dest["Courrier / PDF / autre sys"]
    dest --> broken["□ ou un mauvais caractère"]
    local ~~~ send

Figure 8 : Le glyphe vit dans eudc.tte ; seul un numéro de la zone à usage privé reste dans les données, donc les gaiji ont l’air cassés dès qu’ils quittent le PC.

5.1. Une réponse réaliste pour un système qui a déjà reçu des gaiji

Le problème, c’est lorsque des données héritées d’un système existant ont déjà des gaiji mélangés. La procédure que nous recommandons dans les missions de migration est la suivante.

1. Enquêter : balayer les bases de données et les fichiers avec une expression régulière pour la zone à usage privé (U+E000–U+F8FF), et inventorier les codes gaiji en usage et leurs comptes. Collecter eudc.tte des PC de chaque site et confirmer les glyphes
2. Identifier : pour chaque gaiji, enquêter « peut-il être représenté comme un caractère Unicode ordinaire », « peut-il être représenté avec IVS », « y a-t-il un caractère correspondant dans la plateforme d’information sur les caractères (MJ) », et construire une table de correspondance de caractères de substitution. En pratique, la majorité des cas sont simplement qu’une ancienne forme avait été faite comme gaiji JIS
3. Remplacer : remplacer les données à partir de la table de correspondance. Seulement lorsqu’il n’y a vraiment aucun caractère correspondant, le conserver comme image ou attacher une note à cet enregistrement
4. Couper : dans le nouveau système, rejeter la saisie de la zone à usage privé à la validation, et ne pas créer de nouveaux gaiji

flowchart TB
    accTitle: La procédure pour migrer des données qui contiennent des gaiji
    accDescr: Inventorier les gaiji en usage en balayant la zone à usage privé et en collectant eudc.tte, construire une table de correspondance de caractères de substitution et remplacer, et dans le nouveau système rejeter la saisie de la zone à usage privé à la validation et ne pas créer de nouveaux gaiji
    st1["Enquêter : balayer la PUA"] --> st2["Identifier : table de subst."]
    st2 --> st3["Remplacer à partir de la table"]
    st3 --> st4["Couper : plus de nouveaux gaiji"]
    st1 -.-> tte["Collecter eudc.tte"]
    st2 -.-> nomap["Pas de correspondance : image ou note"]

Figure 9 : Migrez les gaiji en quatre étapes enquêter, identifier, remplacer et couper, et ne créez pas de nouveaux gaiji.

La direction est la même côté gouvernement : une politique a été énoncée d’identifier de façon unique les gaiji que les municipalités ont créés de leur côté (on dit environ deux millions de caractères à l’échelle nationale) contre les caractères standard pour les affaires administratives décrits plus loin, et d’arrêter leur usage.¹⁰ « Ne pas augmenter les gaiji ; les identifier contre un jeu de caractères standardisé » devient le motif de migration établi dans les secteurs public et privé.

6. La plateforme de caractères du gouvernement — Des caractères unifiés Koseki aux caractères standard pour les affaires administratives

Dans la conception d’un système qui traite des noms de personnes, connaître la plateforme de caractères côté gouvernement devient un matériau pour décider « jusqu’où accepter ».

Dans les systèmes métier cœur municipaux (systèmes conformes à la norme), une structure à deux niveaux est dans la spécification standard : utiliser les caractères standard pour les affaires administratives pour l’interopérabilité d’information des noms de personnes et similaires, et interopérer avec les systèmes externes qui n’ont pas de règles d’interopérabilité unifiées — smartphones et similaires — dans le périmètre de JIS X 0213:2012.¹⁰ La structure elle-même de « détenir un large jeu de caractères en interne, et échanger avec l’extérieur dans une plage qu’un environnement général peut afficher » est aussi une référence pour les systèmes du secteur privé.

flowchart TB
    accTitle: L'interopérabilité à deux niveaux d'un système conforme à la norme
    accDescr: Un système municipal conforme à la norme utilise les caractères standard pour les affaires administratives pour l'interopérabilité d'information des noms de personnes et similaires, et interopère avec les systèmes externes tels que les smartphones qui n'ont pas de règles d'interopérabilité unifiées dans le périmètre de JIS X 0213:2012
    sys["Système municipal standard"] --> renkei["Interop. des noms"]
    sys --> gaibu["Systèmes externes"]
    renkei --> mjp["Car. admin. standard"]
    mjp -.-> mjpN["Noms de personnes etc."]
    gaibu --> jis["Périmètre JIS X 0213:2012"]
    gaibu -.-> sumaho["Sans règles（smartphone）"]
    mjp -.-> naibu["Large jeu détenu à l'intérieur"]

Figure 10 : Une structure à deux niveaux : l’interopérabilité gouvernementale utilise les caractères standard pour les affaires administratives ; l’interopérabilité externe sans règles utilise JIS X 0213:2012.

Comme guidage pratique pour un système métier général, nous recommandons ce qui suit.

• Décidez du jeu de caractères accepté et déclarez-le à la fois dans la spécification et dans la validation de saisie. Par exemple « le périmètre de JIS X 0213:2012 », « la zone à usage privé et les caractères combinants ne sont pas autorisés », « IVS n’est pas accepté (ou est accepté, mais l’affichage n’est garanti que dans un environnement IPAmj Mincho) »
• N’acceptez pas sans limite. Une conception « c’est Unicode, donc tout passe » cassera quelque part dans l’affichage, l’impression ou l’interopérabilité
• Décidez à l’avance l’opération pour les caractères hors plage. La règle pour substituer une représentation alternative (une forme nouvelle, le katakana) et la formulation que vous expliquez à la personne sont elles-mêmes spécification système
• Lorsqu’un système aval tel que le gouvernement ou la finance a une règle de jeu de caractères, prenez-la comme autorité et alignez-vous dessus

flowchart TB
    accTitle: Concevoir et opérer un jeu de caractères accepté
    accDescr: Décidez du jeu de caractères accepté et déclarez-le à la fois dans la spécification et dans la validation de saisie ; acceptez les caractères dans la plage ; pour les caractères hors plage, décidez l'opération y compris la règle pour substituer une représentation alternative et la formulation que vous expliquez à la personne
    decide["Décider du jeu de caractères accepté"] --> spec["Le déclarer dans la spécification"]
    decide --> valid["Le déclarer dans la validation de saisie"]
    valid --> range{"Dans la plage ?"}
    range -->|Oui| ok["Accepter"]
    range -->|Non| alt["Substituer une représentation alternative"]
    alt -.-> word["La formulation que vous expliquez à la personne est aussi spécification"]

Figure 11 : Déclarez le jeu de caractères accepté à la fois dans la spécification et dans la validation de saisie, et décidez aussi l’opération hors plage.

7. Choisir et embarquer les polices — Aligner l’écran et le formulaire

7.1. Le caractère des polices habituelles

Ce qui importe dans le choix, c’est moins une préférence de police que si cette police existe dans chaque environnement impliqué dans l’affichage, l’impression et la génération de PDF. Les polices japonaises supplémentaires sur Windows 10/11 (BIZ UD et d’autres) sont parfois absentes selon la configuration, et dans une configuration qui génère des PDF côté serveur, la présence ou l’absence de la police sur le serveur a un effet direct.

flowchart TB
    accTitle: Les environnements à confirmer lors du choix d'une police
    accDescr: Dans le choix d'une police, ce qui importe est moins une préférence de police que si cette police existe dans chaque environnement impliqué dans l'affichage, l'impression et la génération de PDF ; la configuration des polices supplémentaires et la présence ou l'absence de la police sur le serveur ont un effet direct
    cand["Une police candidate"] --> exist["Sur chaque environnement ?"]
    exist --> scr["Environnement d'affichage"]
    exist --> more{"Impression ou serveur PDF ?"}
    more --> prn["Environnement d'impression"]
    more --> srv["Serveur de génération PDF"]
    scr -.-> hojo["Police supplémentaire ?"]
    hojo -.-> hojoN["Peut être absente"]
    srv -.-> eikyo["La police sur le serveur compte"]

Figure 12 : Choisissez une police moins par préférence de type que par sa présence dans chaque environnement d’affichage, d’impression et de génération de PDF.

7.2. Les bases de la conception de formulaires — Aligner, et embarquer

• Spécifiez la même police à l’écran et sur le formulaire. Si les polices diffèrent, les mêmes données peuvent ressembler à un glyphe différent, et vous obtenez la plainte de l’ouverture. Une configuration telle que « Meiryo à l’écran, MS Mincho sur le formulaire » devrait au moins être vérifiée pour savoir s’il y a une différence de glyphe sur les 168 caractères JIS2004
• Embarquez la police dans le PDF. Si vous n’embarquez pas, le côté consultation dessine par substitution avec une police qu’il a sous la main, et non seulement le glyphe mais la mise en page peut changer
• Le droit d’embarquement est déterminé par la licence. Une police OpenType déclare les permissions d’embarquement dans le champ fsType (Installable / Restricted / Preview & Print / Editable, no-subsetting, et d’autres), et vous ne devez pas embarquer une police dont l’embarquement n’est pas licencié.¹¹ Pour une police commerciale, confirmer le contrat est requis
• Faites de l’embarquement par sous-ensemble la base. Si vous n’embarquez que les glyphes des caractères utilisés, vous n’avez pas à prendre une police japonaise entière (plusieurs Mo à des dizaines de Mo)
• S’il y a une exigence de conservation à long terme, PDF/A. PDF/A (ISO 19005) est une norme qui complète à l’intérieur du fichier les ressources nécessaires à l’affichage, et l’embarquement de polices est requis.¹² C’est aussi le moyen le plus fiable d’empêcher « dix ans plus tard j’ai ouvert et les glyphes avaient changé »

flowchart TB
    accTitle: Le flux de décision pour l'embarquement de polices
    accDescr: Avant d'embarquer une police dans un PDF, confirmez la licence d'embarquement fsType ; si elle est licenciée, faites de l'embarquement par sous-ensemble la base ; s'il y a une exigence de conservation à long terme, envisagez PDF/A, qui exige l'embarquement
    emb["Embarquer la police dans le PDF"] --> lic{"L'embarquement est-il licencié par fsType ?"}
    lic -->|Licencié| sub["L'embarquement par sous-ensemble est la base"]
    lic -->|Non licencié| ng["Vous ne devez pas embarquer"]
    sub -.-> gly["Seulement les glyphes des caractères utilisés"]
    sub -->|Une exigence de conservation à long terme| pdfa["Envisager PDF/A"]
    pdfa -.-> must["L'embarquement de polices est requis"]

Figure 13 : L’embarquement suppose de confirmer la licence fsType ; l’embarquement par sous-ensemble et PDF/A sont la base.

Comment choisir un moyen d’implémentation pour l’impression et la sortie PDF est couvert en profondeur dans « Impression et sortie PDF dans les applications métier Windows — choisir entre System.Drawing.Printing, WPF et bibliothèques de rapports ».

8. Liaison de polices et repli — Le phénomène « une autre police se mélange »

Un caractère pour lequel la police spécifiée n’a pas de glyphe n’est pas affiché comme rien ; le dessin par substitution dans une autre police est le comportement par défaut des piles de dessin modernes. Dans GDI, la « liaison de polices » définie dans le registre (FontLink\SystemLink) le fait ; dans DirectWrite, WPF et les navigateurs, le « repli de police » le fait.¹⁵

flowchart TB
    accTitle: Le flux de la liaison de polices et du repli
    accDescr: Si la police spécifiée a un glyphe, il s'affiche tel quel ; sinon, il est dessiné par substitution dans une police de liaison ou de repli ; si aucun glyphe n'existe nulle part, cela devient □, mais les données sont souvent encore vivantes
    disp["Afficher un caractère"] --> has{"La police spécifiée a-t-elle un glyphe ?"}
    has -->|Oui| draw["Afficher dans la police spécifiée"]
    has -->|Non| fb{"Est-ce dans une cible de liaison ou de repli ?"}
    fb -->|Oui| alt["Dessiner par substitution dans une autre police"]
    alt -.-> mixed["La cause d'une sensation de police mélangée"]
    fb -->|Non| tofu["□ （tofu） s'affiche"]
    tofu -.-> alive["Les données sont souvent encore vivantes"]

Figure 14 : □ est la trace d’un échec de repli ; que le dessin par substitution réussisse est la fourche entre « mélangé » et « tofu ».

Connaître ce mécanisme vous permet d’expliquer les cas courants suivants.

• La sensation de police diffère entre latin et japonais : parce qu’une police latine a été spécifiée en premier, seule la portion japonaise est dessinée dans une police japonaise liée ou de repli
• Seuls les kanji d’une phrase japonaise deviennent un glyphe de style chinois : la cible de repli s’est résolue vers une police chinoise. Facile à arriver dans une page Web ou une application qui ne passe pas correctement l’information de langue (un attribut lang ou une locale)
• Le tofu (□) apparaît : ni la police spécifiée ni la cible de repli n’a de glyphe. Autrement dit, □ est la « trace d’un échec de repli », et les données sont souvent encore vivantes

Le repli est un mécanisme de secours ; ce n’est pas un substitut au choix de la bonne police dès le départ.¹⁵ Dans une application métier, la position saine est « sur les chemins principaux d’affichage et d’impression, terminer avec les polices conçues seules ; le repli est une assurance pour les caractères inattendus ». Pour la pensée du choix de police dans une interface multilingue, voir aussi « Internationalisation des applications WinForms/WPF : resx, assemblies satellites et changement de culture en pratique ».

9. Une liste de contrôle d’implémentation pour les applications métier

Enfin, les points à confirmer à chaque couche de la saisie à l’interopérabilité sont résumés dans un tableau.

La normalisation en particulier est un piège qui est le thème même de cet article : un traitement appliqué « avec de bonnes intentions » qui écrase la distinction des caractères variantes et de la pleine chasse versus la demi-chasse. L’original tel quel ; le traitement sur une copie est le principe. Les accidents d’encodage des caractères dans l’interopérabilité CSV sont couverts en profondeur dans « Le CSV n’est pas « juste du texte » ── La pratique du CSV dans les applications métier C# (encodage des caractères, compatibilité Excel, protection contre l’injection) ».

flowchart TB
    accTitle: L'original tel quel ; le traitement sur une copie
    accDescr: Stockez la chaîne saisie telle quelle comme original ; appliquez la normalisation à une copie limitée à un usage tel que générer une clé de recherche ; appliquer NFKC à l'original perd la distinction des caractères variantes et de la pleine chasse versus la demi-chasse
    input["La chaîne saisie"] --> orig["Original : stocker tel que saisi"]
    input --> copy["Copie : normaliser, limité à un usage"]
    copy -.-> use["Générer une clé de recherche, et d'autres"]
    orig -.-> ng["NFKC sur l'original écrase les distinctions"]

Figure 15 : Limitez la normalisation à un usage et appliquez-la à une copie ; stockez l’original tel que saisi.

10. Résumé

• Scindez d’abord les problèmes de caractères en « couche données (encodage des caractères) » et « couche apparence (polices) ». � est le signe d’un accident à la couche données, □ d’un accident à la couche apparence.
• JIS X 0213:2004 a changé les glyphes exemplaires de 168 caractères, et Windows a des glyphes JIS2004 comme défaut à partir de Vista. Que 葛, 辻 et 飴 aient un aspect différent selon l’environnement est l’histoire des polices, pas une corruption de données.
• Le moyen standard de figer un glyphe comme donnée est IVS, mais sans une police compatible et une application compatible, cela retombe sur le glyphe par défaut. N’oubliez pas l’impact d’implémentation qu’un caractère peut occuper jusqu’à quatre unités de code UTF-16.
• Les gaiji (EUDC) sont un actif spécifique à ce PC et ne peuvent pas voyager avec les données. La réponse réaliste est d’inventorier au moment de la migration, de remplacer à partir d’une table de correspondance vers des caractères ordinaires ou IVS, et d’arrêter d’en créer de nouveaux.
• Un système qui traite des noms de personnes décide du jeu de caractères accepté et le déclare. Le gouvernement standardise vers les caractères standard pour les affaires administratives sur le fondement des caractères unifiés Koseki et de la plateforme d’information sur les caractères, et un système qui interopère doit suivre ce mouvement.
• Pour les formulaires et les PDF, « aligner la police avec l’écran, confirmer la licence, et embarquer » est la base. Pour la conservation à long terme, envisagez PDF/A.
• La normalisation NFKC, le découpage par unité de code et la conversion CP932 sont les trois points qui cassent silencieusement les caractères variantes et les gaiji. Faites du stockage de l’original et du traitement en unités de graphème le principe.

La prochaine fois qu’on vous dit « le caractère est différent », reformulez d’abord la question ainsi. Les points de code sont-ils les mêmes, ou différents ? S’ils sont les mêmes, c’est un problème de police ; s’ils sont différents, c’est un problème de données. Ce seul geste vous empêche de prendre le mauvais point d’entrée pour l’investigation.

flowchart TB
    accTitle: La première question qui décide du point d'entrée de l'investigation
    accDescr: Quand on vous dit que le caractère est différent, comparez d'abord si les points de code sont les mêmes ou différents ; s'ils sont les mêmes, commencez l'investigation comme un problème de police, s'ils sont différents comme un problème de données
    said["On vous a dit que le caractère est différent"] --> cmp{"Les points de code sont-ils les mêmes ?"}
    cmp -->|Les mêmes| fontp["Un problème de police"]
    cmp -->|Différents| datap["Un problème de données"]

Figure 16 : Si les points de code sont les mêmes, commencez l’investigation comme un problème de police ; s’ils sont différents, comme un problème de données.

Articles connexes

• Introduction à l’encodage des caractères sous Windows - Le mojibake qui survient avec Linux
• Encodage des caractères et fins de ligne sous Windows - Les bases du mojibake et de CRLF/LF
• Impression et sortie PDF dans les applications métier Windows — choisir entre System.Drawing.Printing, WPF et bibliothèques de rapports
• Internationalisation des applications WinForms/WPF : resx, assemblies satellites et changement de culture en pratique
• Le CSV n’est pas « juste du texte » ── La pratique du CSV dans les applications métier C# (encodage des caractères, compatibilité Excel, protection contre l’injection)
• Introduction à l’accessibilité des applications Windows — se préparer à UI Automation et aux exigences d’aménagement raisonnable

Domaines de conseil associés

KomuraSoft LLC prend en charge la conception et l’investigation autour des caractères dans les systèmes métier. De l’isolement de la cause de symptômes tels que « le caractère diffère à l’écran et sur le formulaire » ou « après la migration un nom de personne est devenu □ », en passant par l’inventaire des gaiji et la construction d’une table de caractères de substitution à la migration depuis un système existant, la conception du jeu de caractères accepté d’un système qui traite des noms de personnes, et la revue de la configuration d’embarquement de polices des formulaires et PDF, nous couvrons à la fois la couche code et la couche police.

• Développement d’applications Windows
• Migration d’actifs hérités
• Conseil technique et revue de conception
• Nous contacter

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Pourquoi le même caractère 葛 a-t-il un aspect différent selon le PC ou le formulaire imprimé ?

Il s'agit plus probablement d'une différence de glyphes de police que de mojibake. JIS X 0213:2004 (JIS2004) a révisé les glyphes exemplaires de 168 kanji vers les formes d'impression standard, et Windows aussi a fait des glyphes JIS2004 le défaut dans MS Gothic / MS Mincho et d'autres à partir de Vista. 葛, 辻, 飴 et d'autres en sont des exemples représentatifs : le point de code Unicode (les données) reste le même, et seul le glyphe que la police détient (l'apparence) a changé. Comparez les données et elles correspondent ; un écart de forme entre l'image d'un formulaire de l'ère XP et l'écran d'un nouveau PC est le comportement spécifié. Si vous voulez aussi aligner les glyphes, utilisez la même police à l'écran et sur le formulaire, ou spécifiez le glyphe avec un sélecteur de variation idéographique.

Si nous utilisons des sélecteurs de variation idéographique (IVS), cela résout-il tous les problèmes de glyphe des noms de personnes ?

Non. IVS est un mécanisme qui place un sélecteur à partir de U+E0100 immédiatement après un caractère de base pour spécifier un glyphe comme donnée, et le glyphe spécifié s'affiche seulement lorsqu'une police compatible telle que IPAmj Mincho et une application compatible sont toutes deux présentes. Dans un environnement non compatible, le comportement spécifié est que le sélecteur est ignoré et que le glyphe par défaut du caractère de base s'affiche ; dans certains environnements, le sélecteur peut aussi apparaître comme □. De plus, un caractère porteur d'IVS peut occuper jusqu'à quatre unités de code en UTF-16, ce qui affecte le comptage de caractères, le découpage et la conception des longueurs de colonnes de base de données. Si vous l'introduisez, confirmez le périmètre de prise en charge à travers l'affichage, l'impression et les systèmes aval avant de l'utiliser.

Un caractère enregistré comme gaiji (EUDC) peut-il s'afficher sur un autre PC ou dans un PDF ?

En principe, non. Un gaiji est un mécanisme dans lequel un utilisateur enregistre un glyphe dans le fichier eudc.tte de ce PC à un point de code de la zone à usage privé Unicode (à partir de U+E000) ; le même point de code est indéfini ou un glyphe différent sur un autre PC. Le destin de le passer au courrier, à un PDF ou à un autre système est donc de devenir □ ou de ressembler à un caractère différent. Si vous avez déjà hérité de données qui contiennent des gaiji, le chemin réaliste au moment de la migration est d'inventorier les usages de la zone à usage privé, de construire une table de correspondance vers des caractères Unicode ordinaires ou des sélecteurs de variation idéographique, et de remplacer. Vous devriez éviter de créer de nouveaux gaiji dans un nouveau système.

Jusqu'où un système métier doit-il accepter les caractères dans les noms de personnes ?

La première chose est de « décider du jeu de caractères accepté et de le déclarer comme spécification ». Les registres d'état civil ont environ 56 000 caractères unifiés Koseki, et les systèmes conformes à la norme gouvernementale évoluent vers l'usage des caractères standard pour les affaires administratives, une extension de la plateforme d'information sur les caractères — mais un système métier général n'a aucune obligation d'accepter le même niveau sans limite. Une conception réaliste consiste à décider d'une plage telle que « jusqu'au périmètre de JIS X 0213 » ou « ne pas accepter les sélecteurs de variation idéographique ni la zone à usage privé », à valider à la saisie, et à traiter les cas hors plage par une alerte ou une représentation alternative. Seuls les systèmes qui interagissent avec des systèmes gouvernementaux ou des municipalités doivent suivre le mouvement des caractères standard pour les affaires administratives et les exigences d'interopérabilité fondées sur JIS X 0221.

Comment faire pour qu'un formulaire ou un PDF montre les mêmes caractères que l'écran ?

La base est de spécifier la même police à l'écran et sur le formulaire, et d'embarquer la police dans le PDF. Si les polices diffèrent, les mêmes données peuvent changer de glyphe ; si le PC de consultation n'a pas la police, une police de substitution est utilisée pour le dessin et l'apparence se casse. Le droit d'embarquement est déterminé par la licence de la police (OpenType fsType), donc confirmez-le plutôt que de le laisser à la bibliothèque de rapports. L'embarquement par sous-ensemble, qui n'embarque que les caractères utilisés, réduit aussi la taille du fichier. S'il y a une exigence de conservation à long terme, envisagez PDF/A, qui exige l'embarquement de polices.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.