Pièges des polices et des caractères japonais — Traiter JIS2004, les sélecteurs de variation idéographique et les gaiji (caractères personnalisés EUDC) dans les applications métier

« Le nom est le même, mais la forme du caractère diffère entre l’écran et le formulaire imprimé. » « Après le remplacement du PC, un caractère qui s’affichait est devenu □. » Les systèmes métier qui traitent le japonais attirent ce type de consultations.

La première chose à vérifier est si les données du caractère ont changé, ou si seule l’apparence des mêmes données a changé. Si vous tentez de corriger cela comme un « mojibake » sans séparer les deux, vous entrez dans l’investigation par la mauvaise porte.

Cet article part de deux consultations : un 葛 d’une liste clients qui n’a pas le même aspect à l’écran et sur le formulaire imprimé, et un nom sur un document soumis à une administration qui n’a plus pu s’afficher après un remplacement de PC.

Aucune de ces deux consultations n’est le mojibake qu’un décalage d’encodage provoque. Dans la première, pas un bit des données n’a changé et seule l’apparence a changé ; dans la seconde, un « gaiji (caractères personnalisés EUDC) » 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 imprimé 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["Données inchangées ; seule l'apparence a changé"]
    c2["Consultation 2 : il est devenu □ après le remplacement du PC"] --> 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.

Séparez le code de caractère (la couche données) de la police (la couche apparence), et la plupart des problèmes de caractères japonais se clarifient. Cet article s’adresse aux développeurs de systèmes métier et au personnel informatique. Il parcourt dans l’ordre l’isolement du symptôme, le fonctionnement de JIS2004, des IVS et des gaiji, le périmètre de caractères à accepter et la conception des formulaires et des PDF.

Le brouillage qui survient dans la conversion entre Shift_JIS et UTF-8 est couvert dans des articles existants, donc cet article se concentre sur le problème où les codes font l’aller-retour correctement mais l’apparence, ou la possibilité même d’afficher le caractère, est fausse.

1. D’abord l’essentiel

« Quelle séquence d’octets stocker » est une question de conception des données ; « à quoi ça ressemble » est une question de conception des polices. Quand vous décidez comment répondre, séparez les trois points suivants.

D’abord, confirmer que les données sont les mêmes

Le « mojibake » est un problème de couche données : une séquence d’octets mal interprétée. En revanche, le même point de code Unicode peut avoir un glyphe différent dans une police différente. JIS2004 a changé les glyphes exemplaires de 168 caractères, dont 葛, 辻 et 飴, et à partir de Vista les glyphes JIS2004 sont le défaut dans MS Gothic et MS Mincho de Windows.¹²

Ne pas confondre la spécification d’un glyphe et le transport des gaiji

IVS est le moyen standard de spécifier un glyphe comme donnée. Il faut toutefois une police compatible et une application compatible, et dans un environnement qui n’en a pas, le comportement correct est d’ignorer le sélecteur et d’afficher le glyphe par défaut du caractère de base. Parce que ce qui ressemble à un caractère peut occuper jusqu’à quatre unités de code UTF-16, cela affecte non seulement l’affichage mais aussi les comptages de caractères et le découpage.³⁴

Les gaiji (EUDC, caractères définis par l’utilisateur) sont une autre affaire : un numéro de zone à usage privé n’a pas de signification partagée dans le monde. Le glyphe dans eudc.tte ne voyage pas vers l’autre partie avec les données, donc une migration a besoin d’un inventaire et d’une correspondance vers des caractères de substitution.⁵⁶

Inscrire dans la spécification les caractères acceptés et l’environnement de sortie

Un système qui traite des noms de personnes décide du jeu de caractères qu’il accepte et le déclare explicitement. Là où le système échange des données avec l’administration, suivez aussi les caractères standard pour les affaires administratives, qui s’appuient sur les caractères unifiés Koseki et la plateforme d’information sur les caractères.⁷⁸⁹ Pour les formulaires et les PDF, la base est d’utiliser la même police que l’écran, de confirmer la licence et d’embarquer la police. Pour la conservation à long terme, envisagez PDF/A.¹⁰¹¹

De plus, n’appliquez pas à la légère une normalisation NFKC à l’original d’un nom de personne. Remplacer les formes pleine chasse et demi-chasse et les caractères de compatibilité fait perdre des distinctions qu’il faut conserver.¹²

Choisir où lire selon le symptôme ou l’objectif

Pour comprendre l’ensemble, lisez à partir du chapitre 2 dans l’ordre ; pour investiguer le symptôme devant vous, partez de la section correspondante du tableau. Quand vous implémentez une contre-mesure, vérifiez aussi à la fin, au chapitre 9, son effet sur les autres couches.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (14 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

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

Le numéro et la forme dessinée sont des choses différentes

En Unicode, un caractère est représenté par un numéro appelé point de code. 葛 est U+845B, et ce numéro est le même sur chaque PC.

Comment ce numéro 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.

Séparer la couche à investiguer selon le symptôme

Avec ces deux couches comme prémisse, les symptômes rencontrés sur le terrain se répartissent comme suit.

Comme indice pour la séparation, il est utile de retenir la différence entre « � » et « □ ».

« � » est la trace d’une conversion échouée. Une fois qu’il a été remplacé par U+FFFD (REPLACEMENT CHARACTER), le caractère d’origine est déjà perdu. Investiguez la couche données.

« □ » est, dans la plupart des cas, un affichage « glyphe introuvable ». Si les données sont encore là et que la police n’a simplement pas de glyphe, changer de police peut rendre l’affichage possible. Investiguez la couche apparence.

flowchart TB
    accTitle: Répartir le symptôme selon � versus □
    accDescr: Quand un caractère ne s'affiche pas correctement, � est la trace d'un échec de conversion à la couche données où le caractère d'origine a été perdu, tandis que □ signifie seulement que les données sont encore là mais que la police n'a pas de glyphe, et changer de police peut rendre l'affichage possible
    symptom["Un caractère ne s'affiche pas correctement"] --> which{"Que voyez-vous ?"}
    which -->|� est visible| datalayer["Accident de la couche données"]
    datalayer -.-> lost["Trace d'une conversion échouée (le caractère d'origine est perdu)"]
    which -->|□ est visible| viewlayer["Accident de la couche apparence"]
    viewlayer -.-> noglyph["La police n'a simplement pas de glyphe"]
    noglyph --> fixable["Changer de police peut rendre l'affichage possible"]

Figure 2 : � signale un accident de la couche données et □ un accident de la couche apparence, et le point d’entrée de l’investigation change en conséquence.

Les bases des encodages eux-mêmes (CP932 et UTF-8, BOM, fins 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, le sujet est la couche apparence et les problèmes qui surviennent à sa frontière.

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

La véritable cause derrière le « 葛 n’a pas le même aspect à l’écran et sur le formulaire » de l’ouverture se trouve, dans la plupart des cas, ici.

Ce qui a changé : les glyphes par défaut de la police

À la suite de la Hyogai Kanji Jitaihyo (la table des formes de caractères pour les kanji hors de la liste Jōyō) rapportée par le Conseil de la langue nationale en 2000, la révision 2004 JIS X 0213:2004 (couramment appelée JIS2004) a changé les glyphes exemplaires de 168 kanji vers les formes d’impression standard, proches des formes dites du dictionnaire Kangxi. 葛, 辻, 飴, 芦, 溢 et 餅 en sont des exemples représentatifs.¹

Windows a suivi et a fait des glyphes JIS2004 le défaut dans MS Gothic et MS Mincho (et la Meiryo nouvellement introduite) à partir de Windows Vista. La MS Gothic actuelle aussi a des glyphes par défaut fondés sur JIS2004, les glyphes de l’époque JIS90 étant accessibles via la fonctionnalité OpenType jp90.²¹

flowchart TB
    accTitle: Comment les glyphes de la MS Gothic actuelle sont organisés
    accDescr: MS Gothic à partir de Vista a les glyphes JIS2004 comme défaut, et les glyphes de l'époque JIS90 sont accessibles via la fonctionnalité OpenType jp90
    msg["MS Gothic (à partir de Vista)"] --> def["Glyphes par défaut : fondés sur JIS2004"]
    msg --> feat["Via la fonctionnalité jp90"]
    feat --> old["Glyphes de l'époque JIS90"]

Figure 3 : La MS Gothic actuelle a les glyphes JIS2004 par défaut et peut basculer vers les glyphes JIS90 avec la fonctionnalité jp90.

Ce qui n’a pas changé : le point de code du caractère

Ce qui compte 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 sur XP comme sur Windows 11
• XP (glyphes JIS90) affiche la forme où l’intérieur du 勹 est simplifié en ヒ ; à partir de Vista (glyphes JIS2004) s’affiche la forme qui écrit aussi 人 à l’intérieur
• Par conséquent, une image numérisée d’un formulaire imprimé par l’ancien système et l’écran du nouveau PC divergent dans la forme du caractère. Une comparaison des données correspond entièrement

Que le radical shinnyō de 辻 ait un point ou deux, et la forme du radical de la nourriture dans 飴, sont du même ordre. Sans connaître cette histoire, une investigation tend à partir dans la mauvaise direction : « la migration a corrompu les données ».

L’ordre d’investigation est : comparer les points de code avant et après la migration → s’ils correspondent, suspecter une différence de glyphe entre polices. Ne concluez pas que les données sont corrompues simplement parce que cela a un aspect différent.

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 diffère entre une police aux glyphes JIS90 et une police aux glyphes JIS2004, et une comparaison des données correspond entièrement
    cp["Point de code U+845B pour 葛"] --> f90["Police aux glyphes JIS90 (XP)"]
    cp --> f04["Police aux glyphes JIS2004 (à partir de Vista)"]
    f90 --> g90["Forme avec l'intérieur de 勹 simplifié en ヒ"]
    f04 --> g04["Forme d'impression standard qui écrit 人 à l'intérieur"]
    g90 -.-> same["La comparaison des données correspond entièrement"]
    g04 -.-> same

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

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

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

Ce chapitre examine séparément le mécanisme qui spécifie un glyphe, les conditions sous lesquelles il peut s’afficher, et l’impact sur l’implémentation.

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

La correspondance des glyphes est décidée par l’enregistrement IVD

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.¹³

Par exemple, la documentation de Microsoft donne U+845B seul (葛) comme la forme utilisée dans le nom de la gare de Nishi-Kasai, et U+845B suivi de U+E0100 (VS17) comme la forme utilisée dans le nom de la ville de Katsuragi, préfecture de Nara. Le même 葛, et pourtant les données peuvent dire quel glyphe est visé.³

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

Figure 5 : Même pour le même 葛, la présence ou l’absence d’un sélecteur permet aux données de dire quel glyphe est visé.

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

Côté police, la correspondance entre une IVS et un glyphe est implémentée dans la table cmap OpenType (format 14).⁴ Quand une police compatible (telle que IPAmj Mincho) et une application compatible sont toutes deux présentes, le glyphe spécifié apparaît.

Quand elles ne le sont pas, le glyphe spécifié n’est pas garanti de survivre. Séparez les deux cas suivants.

• Le comportement correct selon la spécification : 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)
• Les anciennes applications et certains empilements de rendu : 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 en se dégradant, le caractère de base reste lisible », mais le fait que « cela s’affiche toujours dans le glyphe spécifié » dépend de l’environnement récepteur.

Les systèmes administratifs d’état civil et d’enregistrement des résidents 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 tombe quelque part sur le chemin de l’affichage, de l’impression ou d’un système aval.

flowchart TB
    accTitle: Comment les données porteuses d'IVS s'affichent
    accDescr: Quand une police compatible et une application compatible sont toutes deux présentes, l'affichage se fait dans le glyphe spécifié ; sinon le sélecteur est ignoré et le glyphe par défaut du caractère de base est montré ; dans les anciennes applications et certains empilements de rendu, le sélecteur est traité comme un caractère inconnu et un □ supplémentaire s'affiche
    ivs["Caractère de base + sélecteur de variation idéographique"] --> env{"Police et application compatibles toutes deux présentes ?"}
    env -->|Oui| ok["Affiché dans le glyphe spécifié"]
    env -->|Non| ignore["Sélecteur ignoré ; glyphe par défaut affiché"]
    env -->|Anciennes applications ou certains empilements de rendu| tofu["Un □ supplémentaire s'affiche"]
    ignore -.-> spec["C'est le comportement correct selon la spécification"]

Figure 6 : IVS reste lisible comme caractère de base même en se dégradant, mais l’apparition du glyphe spécifié dépend de l’environnement récepteur.

4.2. Précautions 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 du 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 lui-même un kanji du plan supplémentaire (par exemple 𠮟 (U+20B9F), ajouté dans JIS2004), la base seule fait deux unités de code, et la séquence qu’un utilisateur perçoit comme « un caractère » occupe jusqu’à quatre unités de code en UTF-16 et jusqu’à huit octets en UTF-8.

Comptages de caractères et sous-chaînes : ne pas couper le caractère apparent

En C#, "葛󠄀" (葛 + VS17) a string.Length == 3. Substring et le découpage à longueur fixe risquent de séparer le caractère de base de son sélecteur.

Validez les comptages de caractères et extrayez les sous-chaînes en unités de graphème, avec des API telles que StringInfo, et non en unités de code.

Stockage : vérifier l’unité de la longueur de colonne

Le nvarchar(n) de SQL Server se mesure en unités de code UTF-16. Si vous acceptez IVS, prévoyez des longueurs de colonnes de base de données de deux à quatre fois le nombre apparent de caractères.

Recherche et comparaison : décider si les sélecteurs sont distingués

La présence ou l’absence d’un sélecteur fait une chaîne différente. Savoir si une recherche de « 葛 » doit aussi trouver « 葛 + 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 perçoit comme un caractère a un sélecteur qui est toujours une paire de substituts, plus deux unités de code si le caractère de base est un kanji du plan supplémentaire, soit jusqu'à quatre unités de code en UTF-16
    one["Un caractère tel que l'utilisateur le perçoit"] --> base["Caractère de base"]
    one --> vs["Sélecteur de variation idéographique"]
    base -.-> bnote["Deux unités de code s'il s'agit d'un kanji du plan supplémentaire"]
    vs -.-> vnote["Toujours une paire de substituts (deux unités de code)"]
    base --> total["Jusqu'à quatre unités de code en UTF-16"]
    vs --> total
    total -.-> risk["Le découpage à longueur fixe risque de les séparer"]

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

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

Les gaiji sont un mécanisme par 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 plages). Un point de code de la zone à usage privé n’a pas de signification partagée dans le monde ; le même U+E000 peut se voir assigner un caractère différent sur chaque PC et dans chaque organisation.⁵

Le glyphe vit dans la police gaiji ; seul le numéro reste dans les données

Sous Windows, vous créez le glyphe dans 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 via la clé de registre HKEY_CURRENT_USER\EUDC.⁶ À l’époque Shift_JIS (CP932), la plage gaiji allait de 0xF040 à 0xF9FC, et la conversion vers Unicode la fait correspondre à la zone à usage privé.

Un numéro dans les données ne signifie pas que l’autre partie a le même glyphe. Ce mécanisme donne lieu aux problèmes suivants.

• eudc.tte appartient à ce PC (cet utilisateur) et ne voyage pas vers l’autre partie avec les données
• Dès que les données atteignent le courrier, un PDF, le Web ou un autre système, le caractère devient □ ou ressemble à un autre gaiji de l’autre côté
• Si vous oubliez de déplacer eudc.tte lors d’une migration d’OS ou d’un remplacement de PC, « un caractère qui s’affichait sur l’ancien PC ne s’affiche plus » se produit

C’est la véritable cause derrière la seconde 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 via le registre de ce PC, donc lorsque seul le code de la zone à usage privé voyage vers le courrier, un PDF ou un autre système, il devient □ ou ressemble à un caractère différent
    edit["Créer le glyphe dans l'Éditeur de caractères privés"] --> tte["Enregistré dans eudc.tte"]
    tte --> reg["Associé aux polices via le registre"]
    reg --> local["S'affiche sur ce PC"]
    tte -.-> stay["eudc.tte ne voyage pas avec les données"]
    send["Seul le code de la zone à usage privé atteint l'autre partie"] --> dest["Courrier, PDF, autres systèmes"]
    dest --> broken["Devient □ ou ressemble à un caractère différent"]

Figure 8 : Le glyphe vit dans eudc.tte et seul un numéro de 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à accueilli des gaiji

Le problème survient lorsque des données héritées d’un système héritage contiennent déjà des gaiji. Ce que nous recommandons dans les missions de migration est une procédure en quatre étapes : inventorier → identifier → remplacer → bloquer.

1. Inventorier : rassembler les numéros en usage et les glyphes d’origine

Parcourez les bases de données et les fichiers avec une expression régulière pour la zone à usage privé (U+E000 à U+F8FF) et dressez l’inventaire des codes gaiji en usage et de leurs effectifs. Récupérez eudc.tte auprès des PC de chaque site et vérifiez les glyphes.

2. Identifier : construire une table de correspondance vers des caractères de substitution

Pour chaque gaiji, vérifiez s’il peut être représenté par un caractère Unicode ordinaire, s’il peut l’être avec IVS, et si la plateforme d’information sur les caractères (MJ) a un caractère correspondant, et construisez une table de correspondance vers des caractères de substitution. En pratique, la majorité des cas se révèlent n’être rien de plus qu’une ancienne forme de caractère qui avait été créée comme gaiji JIS.

3. Remplacer : remplacer les données selon la table

Remplacez les données selon la table de correspondance. Seulement lorsqu’aucun caractère correspondant n’existe du tout, conservez le caractère comme image ou attachez une note à l’enregistrement concerné.

4. Bloquer : ne pas ajouter de nouveaux gaiji

Dans le nouveau système, rejetez en validation les saisies de la zone à usage privé et ne créez pas de nouveaux gaiji.

flowchart TB
    accTitle: Procédure de migration des données qui contiennent des gaiji
    accDescr: Inventoriez les gaiji en usage en parcourant la zone à usage privé et en récupérant eudc.tte, construisez une table de correspondance vers des caractères de substitution et remplacez, et dans le nouveau système rejetez en validation les saisies de la zone à usage privé et ne créez pas de nouveaux gaiji
    st1["Inventorier : parcourir la zone à usage privé"] --> st2["Identifier : construire la table de correspondance vers des caractères de substitution"]
    st2 --> st3["Remplacer : remplacer selon la table"]
    st3 --> st4["Bloquer : ne créer aucun nouveau gaiji"]
    st1 -.-> tte["Récupérer eudc.tte auprès de chaque site"]
    st2 -.-> nomap["Image ou note seulement là où aucune correspondance n'existe"]

Figure 9 : Migrez les gaiji en quatre étapes — inventorier, identifier, remplacer et bloquer — et ne créez pas de nouveaux gaiji.

La direction est la même côté administration : la politique déclarée est d’identifier de façon unique les gaiji que les municipalités ont créés elles-mêmes (on parle d’environ deux millions de caractères à l’échelle nationale) contre les caractères standard pour les affaires administratives décrits plus bas, et de cesser de les utiliser.⁹ « Ne pas ajouter de gaiji ; les identifier contre un jeu de caractères standardisé » devient le schéma de migration établi dans les secteurs public et privé.

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

Lors de la conception d’un système qui traite des noms de personnes, connaître la plateforme de caractères de l’administration fournit des éléments pour décider « jusqu’où accepter ».

D’abord, séparer les noms et les rôles des plateformes de caractères

Séparer l’échange au sein de l’administration de l’échange avec le monde extérieur général

Pour les systèmes métier cœurs des municipalités (systèmes conformes à la norme), la spécification standard est un arrangement à deux niveaux : utiliser les caractères standard pour les affaires administratives pour l’échange d’information des noms et analogues, et échanger dans le périmètre de JIS X 0213:2012 avec les systèmes externes qui n’ont pas de règles d’échange unifiées, tels que les smartphones.⁹

Cet arrangement, « détenir un large jeu de caractères en interne et échanger avec l’extérieur dans le périmètre qu’un environnement général peut afficher », est lui-même une référence utile pour les systèmes du secteur privé.

flowchart TB
    accTitle: L'échange à 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'échange d'information des noms et analogues, et échange dans le périmètre de JIS X 0213:2012 avec les systèmes externes tels que les smartphones qui n'ont pas de règles d'échange unifiées
    sys["Système municipal conforme à la norme"] --> renkei["Échange d'information des noms et analogues"]
    sys --> gaibu["Échange avec les systèmes externes"]
    renkei --> mjp["Caractères standard pour les affaires administratives"]
    gaibu --> jis["Périmètre de JIS X 0213:2012"]
    gaibu -.-> sumaho["Contreparties sans règles, tels que les smartphones"]
    mjp -.-> naibu["Un large jeu de caractères est détenu en interne"]

Figure 10 : Un arrangement à deux niveaux : l’échange administratif utilise les caractères standard pour les affaires administratives, et l’échange externe sans règles utilise JIS X 0213:2012.

Décider de la plage que votre propre système accepte

Comme orientation 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 », « pas de zone à usage privé ni de caractères combinants », ou « IVS non accepté (ou accepté, avec affichage garanti seulement dans un environnement IPAmj Mincho) »
• N’acceptez pas sans limite. Une conception « c’est Unicode, donc tout passe » cassera quelque part sur le chemin de l’affichage, de l’impression ou de l’interconnexion
• Décidez à l’avance comment les caractères hors plage sont traités. La règle de substitution d’une représentation alternative (une forme de style nouveau ou du katakana) et le libellé utilisé pour l’expliquer à la personne font partie de la spécification du système
• Lorsqu’une partie aval telle qu’une administration ou une institution financière a des règles de jeu de caractères, traitez-les comme faisant autorité et alignez-vous dessus

flowchart TB
    accTitle: Concevoir et exploiter le 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, et pour les caractères hors plage décidez l'exploitation à l'avance, y compris la règle de substitution d'une représentation alternative et le libellé utilisé pour l'expliquer à 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["Le libellé expliqué à la personne fait aussi partie de la 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 du traitement des caractères hors plage.

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

Ici l’ordre de pensée est : confirmer que la police existe dans les environnements que vous utilisez → utiliser la même police à l’écran et sur le formulaire → confirmer la licence et l’embarquer dans le PDF.

7.1. Le caractère des polices courantes

Vérifier les environnements utilisés, pas seulement le nom de la police

Ce qui compte dans le choix n’est pas la préférence de style, mais si la police existe dans chaque environnement impliqué dans l’affichage, l’impression et la génération de PDF.

Les polices japonaises supplémentaires de Windows 10/11 (BIZ UD et autres) peuvent ne pas être installées selon la configuration, et dans une configuration qui génère les PDF côté serveur, la présence de la police sur le serveur a un effet direct.

flowchart TB
    accTitle: Les environnements à vérifier lors du choix d'une police
    accDescr: Lors du choix d'une police, ce qui compte n'est pas la préférence de style mais si la police existe dans chaque environnement impliqué dans l'affichage, l'impression et la génération de PDF, et la configuration des polices supplémentaires ainsi que la présence de la police sur le serveur ont un effet direct
    cand["Police candidate"] --> exist["Présente dans chaque environnement ?"]
    exist --> scr["Environnement d'affichage"]
    exist --> prn["Environnement d'impression"]
    exist --> srv["Serveur de génération de PDF"]
    scr -.-> hojo["Les polices supplémentaires peuvent être absentes selon la configuration"]
    srv -.-> eikyo["La présence de la police sur le serveur a un effet direct"]

Figure 12 : Choisissez une police non par préférence de style mais selon qu’elle est présente dans chaque environnement d’affichage, d’impression et de génération de PDF.

7.2. Les bases de la conception des formulaires — aligner, puis embarquer

Utiliser la même police à l’écran et sur le formulaire

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 réclamation de l’ouverture. Une configuration du type « Meiryo à l’écran, MS Mincho sur le formulaire » devrait au moins être vérifiée pour des différences de glyphe parmi les 168 caractères JIS2004.

Embarquer dans le PDF, après confirmation de la licence

Embarquez la police dans le PDF. Si vous ne le faites pas, le côté consultation dessine avec la police qu’il a sous la main, et non seulement les glyphes mais aussi la mise en page peuvent changer.

Le droit d’embarquement est décidé par la licence. Une police OpenType déclare ses permissions d’embarquement dans le champ fsType (Installable, Restricted, Preview & Print, Editable, pas de sous-ensemble, etc.), et vous ne devez pas embarquer une police dont l’embarquement n’est pas autorisé.¹⁰ Pour les polices commerciales, la vérification du contrat est obligatoire.

Faites de l’embarquement par sous-ensemble le défaut. Si vous n’embarquez que les glyphes des caractères utilisés, vous n’avez pas à transporter une police japonaise entière (plusieurs Mo à quelques dizaines de Mo).

Envisager PDF/A pour la conservation à long terme

Si la conservation à long terme est une exigence, utilisez PDF/A. PDF/A (ISO 19005) est une norme qui rend autonomes dans le fichier les ressources nécessaires à l’affichage, et l’embarquement de polices est obligatoire.¹¹ C’est aussi le moyen le plus fiable d’empêcher « nous l’avons ouvert dix ans plus tard 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, vérifiez la licence d'embarquement dans fsType, faites de l'embarquement par sous-ensemble le défaut s'il est autorisé, et envisagez PDF/A, où l'embarquement est obligatoire, si la conservation à long terme est une exigence
    emb["Embarquer la police dans le PDF"] --> lic{"Embarquement autorisé par fsType ?"}
    lic -->|Autorisé| sub["L'embarquement par sous-ensemble est le défaut"]
    lic -->|Non autorisé| ng["Ne doit pas être embarqué"]
    sub -.-> gly["Seuls les glyphes des caractères utilisés"]
    sub -->|Exigence de conservation à long terme| pdfa["Envisager PDF/A"]
    pdfa -.-> must["L'embarquement de polices est obligatoire"]

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

Comment choisir une approche d’implémentation pour l’impression et la sortie PDF est couvert en détail dans « Impression et sortie PDF dans les applications métier Windows ».

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 laissé vide ; le comportement par défaut des empilements de rendu modernes est de le dessiner à la place avec une autre police.

Sous GDI, c’est la « liaison de polices » définie dans le registre (FontLink\SystemLink) qui s’en charge ; sous DirectWrite, WPF et les navigateurs, c’est le « repli de police ».¹⁵

flowchart TB
    accTitle: Le flux de la liaison de polices et du repli
    accDescr: Si la police spécifiée a le glyphe il s'affiche tel quel, sinon il est dessiné avec une police liée ou de repli, et si aucun glyphe n'existe nulle part il devient □, mais les données sont en général encore intactes
    disp["Afficher un caractère"] --> has{"La police spécifiée a-t-elle le glyphe ?"}
    has -->|Oui| draw["Affiché dans la police spécifiée"]
    has -->|Non| fb{"Une police liée ou de repli l'a-t-elle ?"}
    fb -->|Oui| alt["Dessiné à la place avec une autre police"]
    alt -.-> mixed["La cause d'un sentiment de style mélangé"]
    fb -->|Non| tofu["□ (tofu) s'affiche"]
    tofu -.-> alive["Les données sont en général encore intactes"]

Figure 14 : □ est la trace d’un repli échoué ; le succès du dessin de substitution est la fourche entre « mélangé » et « tofu ».

Lire le résultat du dessin de substitution à partir du symptôme

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

• Le sentiment de style diffère entre les alphanumériques et le japonais : une police latine a été spécifiée en premier, donc seule la partie japonaise est dessinée dans la police japonaise liée ou de repli
• Seuls les kanji d’une phrase japonaise prennent des glyphes d’allure chinoise : le repli s’est résolu vers une police chinoise. Cela arrive facilement dans les pages Web et les applications qui ne transmettent pas correctement l’information de langue (un attribut lang ou une locale)
• Le tofu (□) apparaît : ni la police spécifiée ni la police de repli n’a le glyphe. Autrement dit, □ est la « trace d’un repli échoué », et les données sont en général encore intactes

Le repli n’est pas un substitut de la conception

Le repli est un filet de sécurité ; 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 « les chemins principaux d’affichage et d’impression sont complets avec les seules polices conçues, et le repli est une assurance contre les caractères inattendus ». Pour la façon de penser le choix de police dans une interface utilisateur multilingue, voir aussi « Internationalisation des applications WinForms/WPF ».

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

Enfin, le tableau ci-dessous résume les points à vérifier à chaque couche, de la saisie à l’interconnexion. Ne vous arrêtez pas à « cela s’affiche à l’écran » ; vérifiez aussi le stockage, l’impression et l’interconnexion.

Séparer le stockage de l’original du traitement pour la recherche

La normalisation en particulier est le piège qui est le thème même de cet article : un traitement appliqué « avec de bonnes intentions » qui aplatit les distinctions entre caractères variantes et entre pleine chasse et demi-chasse. Garder l’original tel quel ; traiter une copie est le principe.

Les accidents d’encodage dans l’interconnexion CSV sont couverts en détail dans « Le CSV n’est pas « juste du texte » ».

flowchart TB
    accTitle: Garder l'original tel quel et traiter une copie
    accDescr: Stockez la chaîne saisie comme original exactement telle que saisie, appliquez la normalisation à une copie limitée à des usages tels que la génération de clés de recherche, et notez qu'appliquer NFKC à l'original aplatit les distinctions entre caractères variantes et entre pleine chasse et demi-chasse
    input["Chaîne saisie"] --> orig["Original : stocké tel que saisi"]
    input --> copy["Copie : normalisée pour un usage limité"]
    copy -.-> use["Génération de clés de recherche et analogues"]
    orig -.-> ng["NFKC sur l'original aplatit les distinctions"]

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

10. Synthèse

Investigation : séparer les données de l’apparence

• Répartissez d’abord les problèmes de caractères en « couche données (encodage des caractères) » et « couche apparence (polices) ». � signale un accident de la couche données, □ un accident de la couche apparence.
• JIS X 0213:2004 a changé les glyphes exemplaires de 168 caractères, et Windows a les glyphes JIS2004 par défaut à partir de Vista. Que 葛, 辻 et 飴 aient un aspect différent selon l’environnement est de l’histoire des polices, pas une corruption de données.

Conception : décider comment les glyphes sont spécifiés et ce qui est accepté

• Le moyen standard de figer un glyphe dans les données est IVS, mais sans police compatible et application compatible il 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 des actifs propres à ce PC et ne peuvent pas voyager avec les données. La réponse réaliste est de les inventorier au moment de la migration, de les remplacer via une table de correspondance vers des caractères ordinaires ou IVS, et de cesser 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. L’administration 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 les systèmes qui échangent des données avec elle doivent suivre ce mouvement.

Implémentation et sortie : protéger l’original et aligner les chemins d’affichage

• Pour les formulaires et les PDF, la base est « utiliser la même police que l’écran, confirmer la licence, et embarquer ». Envisagez PDF/A pour la conservation à long terme.
• La normalisation NFKC, le découpage par unité de code et la conversion CP932 sont les trois grands 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 la règle.

La prochaine fois que l’on vous dit « le caractère est différent », commencez par cette question : 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 diffèrent, c’est un problème de données. Ce seul geste vous empêche d’entrer dans l’investigation par la mauvaise porte.

flowchart TB
    accTitle: La première question qui décide du point d'entrée de l'investigation
    accDescr: Quand on vous dit qu'un caractère est différent, comparez d'abord si les points de code sont les mêmes ou différents, et commencez l'investigation comme un problème de police s'ils sont les mêmes et comme un problème de données s'ils diffèrent
    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["Problème de police"]
    cmp -->|Différents| datap["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 diffèrent, 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 du traitement des caractères dans les systèmes métier. Nous travaillons depuis la couche code et depuis la couche police : isoler la cause de symptômes tels que « le caractère diffère à l’écran et sur le formulaire » ou « un nom est devenu □ après la migration », inventorier les gaiji et construire des tables de caractères de substitution lors de la migration depuis des systèmes héritage, concevoir le jeu de caractères accepté pour les systèmes qui traitent des noms de personnes, et revoir la configuration d’embarquement des polices des formulaires et des PDF.

• Développement d’applications Windows
• Valorisation et migration d’actifs existants
• 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 le plus souvent d'une différence de glyphes de police, et non 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 飴 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 ; qu'une image de formulaire de l'ère XP et l'écran d'un nouveau PC divergent en forme 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 le caractère de base pour spécifier le glyphe comme donnée, et le glyphe spécifié ne s'affiche que lorsqu'une police compatible telle que IPAmj Mincho et une application compatible sont toutes deux présentes. Dans un environnement non compatible, le comportement correct 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 chaque système 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 l'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. C'est donc le destin des gaiji de devenir □ ou de ressembler à un caractère différent dès qu'ils atteignent le courrier, un PDF ou un autre système. Si vous détenez déjà des données qui contiennent des gaiji, le chemin réaliste à la migration est de trouver chaque usage 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. Il faut é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 des noms de personnes ?

La première étape est de décider du jeu de caractères accepté et de le déclarer explicitement comme spécification. Les registres d'état civil détiennent environ 56 000 caractères unifiés Koseki, et les systèmes gouvernementaux conformes à la norme évoluent vers les 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 décide d'une plage telle que « jusqu'au périmètre de JIS X 0213 » ou « pas de sélecteurs de variation idéographique ni de zone à usage privé », valide à la saisie, et traite les caractères hors plage par une alerte ou une représentation alternative. Seuls les systèmes qui échangent des données avec des systèmes gouvernementaux ou des municipalités doivent suivre l'évolution des caractères standard pour les affaires administratives et des exigences d'échange fondées sur JIS X 0221.

Comment faire pour qu'un formulaire imprimé 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 produire des glyphes différents, et 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écidé par la licence de la police (OpenType fsType) ; vérifiez-le vous-même 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, où l'embarquement de polices est obligatoire.

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.