Insidie di font e caratteri giapponesi — Gestire JIS2004, IVS e gaiji nelle app aziendali

«Il carattere 葛 nell’elenco clienti ha un aspetto diverso a schermo e sul modulo stampato. Il cliente ha protestato che i dati devono essere corrotti.» — Nella manutenzione dei sistemi aziendali, questo tipo di consulenza non è raro. Un’altra comune è «un carattere nel nome di una persona non si visualizza su un documento che presentiamo all’ufficio. Si visualizzava sul vecchio PC; dopo la sostituzione è diventato □.»

Entrambe tendono a essere chiamate «mojibake» sul campo, ma sono un problema diverso dal mojibake che viene da una discordanza di encoding. Nella prima, non è cambiato un bit dei dati e solo l’aspetto è cambiato; nella seconda, un «gaiji» che esisteva solo su quel PC è andato perso.

flowchart TB
    accTitle: Cosa sono davvero le due consulenze comuni
    accDescr: La consulenza che 葛 ha un aspetto diverso a schermo e sul modulo è un caso in cui solo l'aspetto è cambiato mentre i dati restavano gli stessi; la consulenza che un carattere è diventato □ dopo una sostituzione del PC è un caso in cui un gaiji che esisteva solo su quel PC è andato perso; entrambe sono un problema diverso dal mojibake da discordanza di encoding
    c1["Consulenza 1: la forma differisce a schermo e sul modulo"] --> r1["I dati sono invariati; è cambiato solo l'aspetto"]
    c2["Consulenza 2: è diventato □ dopo una sostituzione"] --> r2["Un gaiji che esisteva solo su quel PC è andato perso"]
    r1 --> diff["Un problema diverso dal mojibake di encoding"]
    r2 --> diff

Figura 1: Le due consulenze che tendono a essere chiamate «mojibake» sono entrambe un problema diverso da una discordanza di encoding.

La promessa di questo articolo è semplice. Se separate lo strato del codice carattere (dati) da quello del font (aspetto), la maggior parte dei problemi di caratteri giapponesi diventa trattabile. Dal cambio di glifo JIS2004, dai selettori di variazione ideografica (IVS) e dai gaiji (EUDC), attraverso la piattaforma di caratteri del governo, fino a scegliere e incorporare i font, è organizzato in una forma che sviluppatori di sistemi aziendali e personale IT possono usare per decidere.

Il «mojibake» in sé che avviene nella conversione Shift_JIS ↔ UTF-8 è coperto in articoli esistenti, quindi questo articolo si concentra sul problema di «i codici fanno il round-trip correttamente, ma aspetto o visualizzabilità sono fuori».

1. Prima di tutto, la conclusione

• «Mojibake» e «il glifo è diverso» sono problemi diversi. Il mojibake è un incidente allo strato dati di interpretare male una sequenza di byte; una differenza di glifo è un incidente allo strato aspetto di una differenza nei glifi che un font detiene; i rimedi sono completamente diversi.
• Anche con lo stesso code point Unicode, il glifo che viene visualizzato dipende dal font. JIS X 0213:2004 ha rivisto i glifi esemplari di 168 caratteri come 葛, 辻 e 飴 verso le forme dello standard di stampa, e anche Windows ha reso i glifi JIS2004 il default in MS Gothic / MS Mincho da Vista in poi.¹²
• Il mezzo standard per fissare un glifo come dato è un selettore di variazione ideografica (IVS). Specificate un glifo con la sequenza di un carattere base più un selettore da U+E0100 in poi; collezioni come Adobe-Japan1, Hanyo-Denshi e Moji_Joho (la Piattaforma di informazioni sui caratteri) sono registrate nell’IVD di Unicode.³⁴
• In un ambiente che non lo supporta il comportamento specificato di IVS è che il selettore viene ignorato e viene visualizzato il glifo di default del carattere base. Un carattere con IVS, però, può arrivare a quattro unità di codice in UTF-16, quindi le implementazioni di conteggio e slicing dei caratteri richiedono attenzione.⁵
• I gaiji (EUDC) hanno il destino di «possono visualizzarsi solo su quel PC». Non c’è un significato concordato per un code point dell’Area di uso privato, e un glifo registrato in eudc.tte non viaggia verso un altro PC, verso la mail o verso un PDF.⁶⁷
• Un sistema che gestisce nomi di persona dovrebbe decidere il set di caratteri accettato e dichiararlo. Sul lato governo, partendo dai Caratteri unificati del koseki e dalla Piattaforma di informazioni sui caratteri, i sistemi conformi allo standard si stanno muovendo verso l’uso dei «Caratteri standard per gli affari amministrativi».⁸⁹¹⁰
• Per moduli e PDF, «allineare il font con lo schermo, e incorporarlo» è la baseline. Se l’incorporamento è consentito lo determina la licenza del font (fsType), e PDF/A per la conservazione a lungo termine richiede l’incorporamento del font.¹¹¹²
• Non applicate alla leggera la normalizzazione (NFKC) ai dati dei nomi di persona. Unificare fullwidth e halfwidth, e sostituire i caratteri di compatibilità, perde distinzioni che dovreste tenere.¹³

In una frase: «quale sequenza di byte memorizzate» è un problema di progetto dei dati; «come appare» è un problema di progetto del font. Se discutete i due mescolati, anche i problemi che potreste sistemare diventano insanabili.

2. Pensare dati e aspetto separatamente — Code point e glifi

In Unicode, un carattere è rappresentato da un numero chiamato code point. 葛 è U+845B, e questo numero è lo stesso su ogni PC. Come quel numero viene disegnato su uno schermo o su carta, invece, lo decide il glifo che il font detiene. È comportamento normale che lo stesso U+845B differisca nei dettagli della forma tra il font A e il font B.

Con questi due strati come premessa, i sintomi sul campo si possono spezzare come segue.

Come indizio per lo spezzamento, è utile ricordare la differenza tra «�» e «□». «�» di U+FFFD (REPLACEMENT CHARACTER) è una traccia di un fallimento di conversione allo strato dati, e il carattere originale è già perso. «□», invece, è in molti casi solo che i dati ci sono ancora ma il font non ha il glifo, e cambiare il font può renderlo visualizzabile.

flowchart TB
    accTitle: Spezzare il sintomo per � rispetto a □
    accDescr: Quando un carattere non si visualizza correttamente, � è una traccia di un fallimento di conversione allo strato dati in cui il carattere originale è stato perso; □ è solo che i dati ci sono ancora ma il font non ha il glifo, e cambiare il font può renderlo visualizzabile
    symptom["Un carattere non si visualizza correttamente"] --> which{"Cosa vedete?"}
    which -->|Vedete �| datalayer["Un incidente allo strato dati"]
    datalayer -.-> lost["Una traccia di fallimento di conversione （il carattere originale è perso）"]
    which -->|Vedete □| viewlayer["Un incidente allo strato aspetto"]
    viewlayer -.-> noglyph["Solo che il font non ha il glifo"]
    noglyph --> fixable["Cambiare il font può renderlo visualizzabile"]

Figura 2: � è un segno di un incidente allo strato dati, □ di un incidente allo strato aspetto, e il punto di ingresso dell’indagine cambia.

Le basi degli encoding in sé (CP932 e UTF-8, BOM, codici di newline) sono coperte in «Introduzione alle codifiche di testo Windows - Il mojibake che avviene integrando con Linux» e «Codifiche di testo Windows e fine riga - Le basi di mojibake e CRLF/LF». Da qui in poi è lo strato aspetto, e i problemi che avvengono al suo confine.

3. Da JIS90 a JIS2004 — Il glifo è cambiato mentre il codice restava lo stesso

L’identità dell’«apertura 葛 ha un aspetto diverso a schermo e sul modulo» è, in molti casi, qui.

Seguendo il rapporto 2000 del National Language Council «Hyogai Kanji Jitaihyo» (la tabella delle forme di carattere per i kanji fuori dalla lista joyo), la revisione 2004 JIS X 0213:2004 (comunemente JIS2004) ha rivisto i glifi esemplari di 168 kanji verso le forme dello standard di stampa, vicine alle cosiddette forme del Kangxi Dictionary. 葛, 辻, 飴, 芦, 溢, 餅 e simili sono esempi rappresentativi.¹

Windows si è allineato e ha reso i glifi JIS2004 il default in MS Gothic / MS Mincho (e nel Meiryo appena introdotto) da Windows Vista in poi. Anche l’attuale MS Gothic ha un glifo di default basato su JIS2004, con la struttura che i glifi dell’era JIS90 sono accessibili via la feature OpenType jp90.²¹

flowchart TB
    accTitle: La struttura di glifo dell'attuale MS Gothic
    accDescr: Da Vista in poi, MS Gothic ha i glifi JIS2004 come default, e accedere ai glifi dell'era JIS90 via la feature OpenType jp90 è la struttura
    msg["MS Gothic （da Vista in poi）"] --> def["Glifo di default: basato su JIS2004"]
    msg --> feat["Via la feature jp90"]
    feat --> old["Glifi dell'era JIS90"]

Figura 3: L’attuale MS Gothic ha i glifi JIS2004 come default, e può passare ai glifi JIS90 con la feature jp90.

Ciò che conta qui è che è cambiato solo il font; i dati non sono cambiati affatto.

• Il code point di 葛 è U+845B sia su XP sia su Windows 11
• Su XP (glifi JIS90) viene visualizzato nella forma che semplifica l’interno del radicale avvolgente a ヒ; da Vista in poi (glifi JIS2004) viene visualizzato nella forma che scrive anche 人 all’interno
• Quindi l’immagine scannerizzata di un modulo stampato sul vecchio sistema e la visualizzazione a schermo su un PC nuovo discordano nella forma del carattere. Un confronto dei dati coincide completamente

Se il radicale shinnyo di 辻 ha un punto o due, la forma del radicale «mangiare» di 飴 e simili sono lo stesso. Se non conoscete questa storia, l’indagine tende ad andare nella direzione sbagliata di «i dati sono stati corrotti nella migrazione». Quando vi dicono che l’aspetto di un carattere differisce prima e dopo una migrazione, prima confrontate i code point, e se coincidono, sospettate una differenza di glifo del font — quello è l’ordine corretto.

flowchart TB
    accTitle: Lo stesso code point, un glifo diverso a seconda del font
    accDescr: Il code point U+845B di 葛 resta lo stesso sia su XP sia su Windows 11; solo la forma visualizzata cambia tra un font a glifi JIS90 e un font a glifi JIS2004, e un confronto dei dati coincide completamente
    cp["Code point U+845B （葛）"] --> f90["Un font a glifi JIS90 （XP）"]
    cp --> f04["Un font a glifi JIS2004 （da Vista in poi）"]
    f90 --> g90["La forma che semplifica l'interno a ヒ"]
    f04 --> g04["La forma dello standard di stampa che scrive 人 all'interno"]
    g90 -.-> same["Un confronto dei dati coincide completamente"]
    g04 -.-> same

Figura 4: È cambiato solo il font; il code point U+845B resta lo stesso in ogni ambiente.

Notate che, poiché il carattere in sé non è cambiato, entrambi i glifi sono «lo stesso carattere». Nei nomi di persona, però, la persona o un ufficio a volte insiste su una forma particolare, e rispondere alla domanda di distinguere quello «come dato» è il prossimo argomento, IVS.

4. Selettori di variazione ideografica (IVS) — Specificare un glifo come dato

IVS (Ideographic Variation Sequence) è un meccanismo che piazza un code point invisibile chiamato «selettore di variazione ideografica» subito dopo un kanji, per specificare una variante di glifo come dato. I selettori usati sono U+E0100–U+E01EF (VS17–VS256).³

Quale sequenza «carattere base + selettore» si riferisce a quale glifo lo decide un registro chiamato IVD (Ideographic Variation Database), gestito dal Unicode Consortium. Le collezioni principali sono le seguenti.⁴

La documentazione Microsoft, per esempio, dà l’esempio di U+845B da solo (葛) usato nella grafia della stazione di Nishi-Kasai, e U+845B+U+E0100 (VS17) usato nella grafia della città di Katsuragi, Nara. Lo stesso 葛, ma quale glifo è si può distinguere come dato.³

flowchart TB
    accTitle: Un esempio di distinguere lo stesso 葛 come dato con IVS
    accDescr: 葛 come U+845B da solo è usato nella grafia della stazione di Nishi-Kasai; la sequenza di U+845B seguito da VS17 è usata nella grafia della città di Katsuragi; quale sequenza si riferisce a quale glifo lo decide il registro IVD
    seq1["U+845B da solo"] --> gl1["Il glifo usato nella grafia della stazione di Nishi-Kasai"]
    seq2["U+845B + VS17"] --> gl2["Il glifo usato nella grafia della città di Katsuragi"]
    ivd["IVD （il registro）"] -.-> gl1
    ivd -.-> gl2

Figura 5: Anche con lo stesso 葛, la presenza o l’assenza di un selettore vi consente di distinguere quale glifo è come dato.

4.1. Comportamento in un ambiente che non lo supporta

Sul lato font, la corrispondenza tra un IVS e un glifo è implementata nella tabella cmap OpenType (formato 14).⁵ Quando sono presenti sia un font che lo supporta (IPAmj Mincho e simili) sia un’app che lo supporta, compare il glifo specificato; quando non lo sono, va come segue.

• Il comportamento corretto specificato: il selettore viene ignorato e viene visualizzato il glifo di default del carattere base (il selettore stesso è invisibile)
• App più vecchie e alcuni stack di disegno: il selettore è trattato come un carattere sconosciuto indipendente, e viene visualizzato un □ extra

In altre parole IVS è progettato perché «anche se decade, il carattere base è leggibile», ma una garanzia che «si visualizzerà sempre nel glifo specificato» dipende dall’ambiente del ricevente. I sistemi governativi di anagrafe e registro di famiglia usano la combinazione di un font della Piattaforma di informazioni sui caratteri più IVS, ma se un sistema aziendale generale lo accetta alla leggera, il glifo cadrà da qualche parte in visualizzazione, stampa o un sistema a valle.

flowchart TB
    accTitle: Come vengono visualizzati i dati con IVS
    accDescr: Quando sono presenti sia un font che lo supporta sia un'app che lo supporta si visualizza nel glifo specificato; quando non lo sono, il selettore viene ignorato e viene mostrato il glifo di default del carattere base; in app più vecchie e alcuni stack di disegno il selettore è trattato come un carattere sconosciuto e viene visualizzato un □ extra
    ivs["Base + selettore IVS"] --> env{"Font + app che supportano?"}
    env -->|Sì| ok["Glifo specificato"]
    env -->|No| other{"Come viene disegnato?"}
    other -->|Ignorato| ignore["Glifo di default"]
    other -->|Più vecchio / alcuni stack| tofu["Un □ extra"]
    ignore -.-> spec["Corretto specificato"]

Figura 6: IVS resta leggibile come carattere base anche se decade, ma se compare il glifo specificato dipende dall’ambiente del ricevente.

4.2. Un’avvertenza di implementazione — «Un carattere» può arrivare a quattro unità di codice

I selettori IVS da U+E0100 in poi sono code point su un piano supplementare, quindi in UTF-16 sono sempre una coppia surrogata (due unità di codice). Se il carattere base è un kanji di piano supplementare (per esempio 𠮟 (U+20B9F), aggiunto in JIS2004), la base da sola è già due unità di codice, e la sequenza che un utente riconosce come «un carattere» è fino a quattro unità di codice in UTF-16, e fino a otto byte in UTF-8.

• Il "葛󠄀" di C# (葛+VS17) ha string.Length == 3. Substring e lo slicing a lunghezza fissa rischiano di spezzare il carattere base dal selettore
• La validazione del conteggio dei caratteri e lo slicing andrebbero fatti in unità di grafema (API come StringInfo), non in unità di codice
• Per la lunghezza di colonna DB (nvarchar(n) di SQL Server è in unità di codice UTF-16), se accettate IVS, provvedete da due a quattro volte il conteggio apparente dei caratteri
• In ricerca e confronto, la presenza o l’assenza di un selettore fa una stringa diversa. Se una ricerca di «葛» colpisce «葛+VS17» è qualcosa che dovete decidere come requisito e implementare

flowchart TB
    accTitle: Un carattere con IVS e le unità di codice UTF-16
    accDescr: La sequenza di un carattere base e un selettore di variazione ideografica che un utente riconosce come un carattere è sempre una coppia surrogata per il selettore, e se il carattere base è un kanji di piano supplementare altre due unità di codice, per un massimo di quattro unità di codice in UTF-16
    one["Un carattere visibile"] --> base["Carattere base"]
    one --> vs["Selettore di variazione"]
    base -.-> bnote["+2 se supplementare"]
    vs -.-> vnote["Sempre 2 unità di codice"]
    base --> total["Fino a 4 unità UTF-16"]
    vs --> total
    total -.-> risk["Spezzato nello slicing fisso"]

Figura 7: Un carattere con IVS può arrivare a quattro unità di codice in UTF-16; lo slicing per unità di codice è pericoloso.

5. Gaiji (EUDC) — Caratteri che si visualizzano solo su quel PC

Gaiji è un meccanismo in cui un utente assegna un glifo proprio a un code point nell’Area di uso privato Unicode (PUA: U+E000–U+F8FF e simili). Un code point dell’Area di uso privato non ha un significato concordato a livello mondiale; lo stesso U+E000 può essere assegnato a un carattere diverso per PC e per organizzazione.⁶

Su Windows create il glifo con l’Editor di caratteri privati (eudcedit.exe), e viene salvato in un file di font chiamato eudc.tte. Questo file è installato come font nascosto e associato a ciascun font nel registro HKEY_CURRENT_USER\EUDC.⁷ Nell’era Shift_JIS (CP932) l’intervallo gaiji era 0xF040–0xF9FC, e in conversione a Unicode viene mappato all’Area di uso privato.

La conseguenza di questo meccanismo è chiara.

• eudc.tte appartiene a quel PC (quel utente) e non viaggia verso l’altra parte con i dati
• Nel momento in cui viene passato a mail, a un PDF, al Web o a un altro sistema, diventa □ o assomiglia al gaiji diverso dell’altra parte
• Se dimenticate di migrare eudc.tte in una migrazione OS o in una sostituzione PC, avviene «un carattere che si visualizzava sul vecchio PC non si visualizza»

Questa è l’identità della seconda consulenza dell’apertura.

flowchart TB
    accTitle: Perché i gaiji si visualizzano solo su quel PC
    accDescr: Un glifo creato nell'Editor di caratteri privati viene salvato in eudc.tte e associato ai font nel registro di quel PC, quindi se solo il codice dell'Area di uso privato viene passato a mail, a un PDF o a un altro sistema diventa □ o assomiglia a un carattere diverso
    edit["Create un glifo PUA"] --> tte["Salvate in eudc.tte"]
    edit -.-> editN["Editor di caratteri privati"]
    tte --> reg["Mappatura font del registro"]
    reg --> local["Si visualizza su quel PC"]
    tte -.-> stay["eudc.tte resta indietro"]
    send["Solo il codice PUA va"] --> dest["Mail / PDF / altro sistema"]
    dest --> broken["□ o un carattere sbagliato"]
    local ~~~ send

Figura 8: Il glifo vive in eudc.tte; nei dati resta solo un numero dell’Area di uso privato, quindi i gaiji sembrano rotti una volta che lasciano il PC.

5.1. Una risposta realistica per un sistema che ha già ricevuto gaiji

Il problema è quando i dati ereditati da un sistema legacy hanno già gaiji mescolati. La procedura che raccomandiamo negli incarichi di migrazione è la seguente.

1. Indagare: scandite database e file con un’espressione regolare per l’Area di uso privato (U+E000–U+F8FF), e inventariate i codici gaiji in uso e i loro conteggi. Raccogliete eudc.tte dai PC di ciascun sito e confermate i glifi
2. Identificare: per ciascun gaiji, indagate «si può rappresentare come un carattere Unicode regolare», «si può rappresentare con IVS», «c’è un carattere corrispondente nella Piattaforma di informazioni sui caratteri (MJ)», e costruite una tabella di corrispondenza dei caratteri sostitutivi. In pratica la maggioranza dei casi è semplicemente che una forma vecchia era stata fatta come gaiji JIS
3. Sostituire: sostituite i dati dalla tabella di corrispondenza. Solo quando non c’è davvero un carattere corrispondente, tenetelo come immagine o allegate una nota a quel record
4. Tagliare: nel sistema nuovo, rifiutate l’input dell’Area di uso privato in validazione, e non create nuovi gaiji

flowchart TB
    accTitle: La procedura per migrare dati che contengono gaiji
    accDescr: Inventariate i gaiji in uso scandendo l'Area di uso privato e raccogliendo eudc.tte, costruite una tabella di corrispondenza dei caratteri sostitutivi e sostituite, e nel sistema nuovo rifiutate l'input dell'Area di uso privato in validazione e non create nuovi gaiji
    st1["Indagare: scandite la PUA"] --> st2["Identificare: tabella di sostituzione"]
    st2 --> st3["Sostituire dalla tabella"]
    st3 --> st4["Tagliare: niente nuovi gaiji"]
    st1 -.-> tte["Raccogliete eudc.tte"]
    st2 -.-> nomap["Niente mappa: immagine o nota"]

Figura 9: Migrate i gaiji in quattro stadi indagare, identificare, sostituire e tagliare, e non create nuovi gaiji.

La direzione è la stessa sul lato governo: è stata dichiarata una politica di identificare univocamente i gaiji che i comuni hanno creato per conto proprio (si dice circa due milioni di caratteri a livello nazionale) rispetto ai Caratteri standard per gli affari amministrativi descritti più avanti, e di smettere di usarli.¹⁰ «Non aumentare i gaiji; identificarli rispetto a un set di caratteri standardizzato» sta diventando il pattern di migrazione consolidato sia nel settore pubblico sia in quello privato.

6. La piattaforma di caratteri del governo — Dai Caratteri unificati del koseki ai Caratteri standard per gli affari amministrativi

Nel progetto di un sistema che gestisce nomi di persona, conoscere la piattaforma di caratteri lato governo diventa materiale per decidere «fino a dove accettare».

Nei sistemi core-business comunali (sistemi conformi allo standard), è nella specifica standard una struttura a due livelli: usare i Caratteri standard per gli affari amministrativi per l’interoperazione di informazioni di nomi di persona e simili, e interoperare con sistemi esterni che non hanno regole di interoperazione unificate — smartphone e simili — nell’ambito di JIS X 0213:2012.¹⁰ La struttura in sé di «tenere un set di caratteri ampio internamente, e scambiare con l’esterno in un ambito che un ambiente generale può visualizzare» è anche un riferimento per i sistemi del settore privato.

flowchart TB
    accTitle: L'interoperazione a due livelli di un sistema conforme allo standard
    accDescr: Un sistema comunale conforme allo standard usa i Caratteri standard per gli affari amministrativi per l'interoperazione di informazioni di nomi di persona e simili, e interopera con sistemi esterni come gli smartphone che non hanno regole di interoperazione unificate nell'ambito di JIS X 0213:2012
    sys["Sistema standard comunale"] --> renkei["Interoperazione nomi"]
    sys --> gaibu["Sistemi esterni"]
    renkei --> mjp["Caratteri standard amm."]
    mjp -.-> mjpN["Nomi di persona ecc."]
    gaibu --> jis["Ambito JIS X 0213:2012"]
    gaibu -.-> sumaho["Niente regole （smartphone）"]
    mjp -.-> naibu["Set ampio tenuto dentro"]

Figura 10: Una struttura a due livelli: l’interoperazione governativa usa i Caratteri standard per gli affari amministrativi; l’interoperazione esterna senza regole usa JIS X 0213:2012.

Come guida pratica per un sistema aziendale generale, raccomandiamo quanto segue.

• Decidete il set di caratteri accettato e dichiaratelo sia nella specifica sia nella validazione di input. Per esempio «l’ambito di JIS X 0213:2012», «l’Area di uso privato e i caratteri combinanti non sono ammessi», «IVS non è accettato (o è accettato, ma la visualizzazione è garantita solo in un ambiente IPAmj Mincho)»
• Non accettate senza limiti. Un progetto di «è Unicode, quindi va tutto» si romperà da qualche parte in visualizzazione, stampa o interoperazione
• Decidete in anticipo l’operazione per i caratteri fuori ambito. La regola per sostituire una rappresentazione alternativa (una forma nuova, katakana) e la formulazione che spiegate alla persona sono esse stesse specifica di sistema
• Quando un sistema a valle come governo o finanza ha una regola di set di caratteri, prendetela come autorevole e allineatevi

flowchart TB
    accTitle: Progettare e operare un set di caratteri accettato
    accDescr: Decidete il set di caratteri accettato e dichiaratelo sia nella specifica sia nella validazione di input; accettate i caratteri in ambito; per i caratteri fuori ambito, decidete l'operazione inclusa la regola per sostituire una rappresentazione alternativa e la formulazione che spiegate alla persona
    decide["Decidete il set di caratteri accettato"] --> spec["Dichiaratelo nella specifica"]
    decide --> valid["Dichiaratelo nella validazione di input"]
    valid --> range{"In ambito?"}
    range -->|Sì| ok["Accettate"]
    range -->|No| alt["Sostituite una rappresentazione alternativa"]
    alt -.-> word["La formulazione che spiegate alla persona è anche specifica"]

Figura 11: Dichiarate il set di caratteri accettato sia nella specifica sia nella validazione di input, e decidete anche l’operazione fuori ambito.

7. Scegliere e incorporare i font — Allineare schermo e modulo

7.1. Il carattere dei font usuali

Ciò che conta nella scelta è meno una preferenza di carattere che se quel font esiste in ogni ambiente coinvolto in visualizzazione, stampa e generazione PDF. I font supplementari giapponesi su Windows 10/11 (BIZ UD e simili) a volte non sono presenti a seconda della configurazione, e in una configurazione che genera PDF lato server, la presenza o l’assenza del font sul server ha un effetto diretto.

flowchart TB
    accTitle: Gli ambienti da confermare quando scegliete un font
    accDescr: Nel scegliere un font, ciò che conta è meno una preferenza di carattere che se quel font esiste in ogni ambiente coinvolto in visualizzazione, stampa e generazione PDF; la configurazione dei font supplementari e la presenza o l'assenza del font sul server hanno un effetto diretto
    cand["Un font candidato"] --> exist["Su ogni ambiente?"]
    exist --> scr["Ambiente di visualizzazione"]
    exist --> more{"Server di stampa o PDF?"}
    more --> prn["Ambiente di stampa"]
    more --> srv["Server di generazione PDF"]
    scr -.-> hojo["Font supplementare?"]
    hojo -.-> hojoN["Può essere assente"]
    srv -.-> eikyo["Il font sul server conta"]

Figura 12: Scegliete un font meno per preferenza di carattere che per se è presente in ogni ambiente di visualizzazione, stampa e generazione PDF.

7.2. Le basi del progetto di modulo — Allineare, e incorporare

• Specificare lo stesso font a schermo e sul modulo. Se i font differiscono, gli stessi dati possono sembrare un glifo diverso, e ottenete la protesta dell’apertura. Una configurazione come «Meiryo a schermo, MS Mincho sul modulo» andrebbe almeno controllata per se c’è una differenza di glifo sui 168 caratteri JIS2004
• Incorporare il font nel PDF. Se non incorporate, il lato visualizzazione disegna in sostituzione con un font che ha a disposizione, e non solo il glifo ma il layout può cambiare
• Se l’incorporamento è consentito lo determina la licenza. Un font OpenType dichiara i permessi di incorporamento nel campo fsType (Installable / Restricted / Preview & Print / Editable, no-subsetting, e simili), e non dovete incorporare un font il cui incorporamento non è concesso in licenza.¹¹ Per un font commerciale, confermare il contratto è richiesto
• Fate dell’incorporamento subset la baseline. Se incorporate solo i glifi dei caratteri usati, non dovete caricarvi un intero font giapponese (da diversi MB a decine di MB)
• Se c’è un requisito di conservazione a lungo termine, PDF/A. PDF/A (ISO 19005) è uno standard che completa le risorse necessarie per la visualizzazione dentro il file, e l’incorporamento del font è richiesto.¹² È anche il modo più affidabile per prevenire «dieci anni dopo l’ho aperto e i glifi erano cambiati»

flowchart TB
    accTitle: Il flusso di decisione per l'incorporamento del font
    accDescr: Prima di incorporare un font in un PDF, confermate la licenza di incorporamento fsType; se è concessa, fate dell'incorporamento subset la baseline; se c'è un requisito di conservazione a lungo termine, considerate PDF/A, che richiede l'incorporamento
    emb["Incorporate il font nel PDF"] --> lic{"L'incorporamento è concesso da fsType?"}
    lic -->|Concesso| sub["L'incorporamento subset è la baseline"]
    lic -->|Non concesso| ng["Non dovete incorporare"]
    sub -.-> gly["Solo i glifi dei caratteri usati"]
    sub -->|Un requisito di conservazione a lungo termine| pdfa["Considerate PDF/A"]
    pdfa -.-> must["L'incorporamento del font è richiesto"]

Figura 13: L’incorporamento assume di confermare la licenza fsType; l’incorporamento subset e PDF/A sono la baseline.

Come scegliere un mezzo di implementazione per stampa e output PDF è coperto in profondità in «Stampa e output PDF nelle applicazioni aziendali Windows».

8. Font linking e fallback — Il fenomeno di «si mescola un font diverso»

Un carattere per cui il font specificato non ha il glifo non viene visualizzato come niente; il disegno sostitutivo in un altro font è il comportamento di default degli stack di disegno moderni. In GDI, lo fa il «font linking» definito nel registro (FontLink\SystemLink); in DirectWrite, WPF e browser, lo fa il «font fallback».¹⁵

flowchart TB
    accTitle: Il flusso di font linking e fallback
    accDescr: Se il font specificato ha un glifo viene visualizzato così com'è; se no, viene disegnato in sostituzione in un font di link o fallback; se non esiste un glifo da nessuna parte diventa □, ma i dati sono spesso ancora vivi
    disp["Visualizzare un carattere"] --> has{"Il font specificato ha un glifo?"}
    has -->|Sì| draw["Visualizzate nel font specificato"]
    has -->|No| fb{"È in un obiettivo di link o fallback?"}
    fb -->|Sì| alt["Disegnate in sostituzione in un altro font"]
    alt -.-> mixed["La causa di una sensazione di carattere misto"]
    fb -->|No| tofu["Viene visualizzato □ （tofu）"]
    tofu -.-> alive["I dati sono spesso ancora vivi"]

Figura 14: □ è la traccia di un fallimento di fallback; se il disegno sostitutivo riesce è il bivio tra «misto» e «tofu».

Conoscere questo meccanismo vi consente di spiegare i seguenti casi comuni.

• La sensazione di carattere differisce tra latino e giapponese: perché è stato specificato prima un font latino, solo la porzione giapponese viene disegnata in un font giapponese collegato o di fallback
• Solo i kanji in una frase giapponese diventano un glifo in stile cinese: l’obiettivo di fallback si è risolto a un font cinese. Facile che avvenga in una pagina Web o un’app che non sta passando correttamente le informazioni di lingua (un attributo lang o un locale)
• Compare tofu (□): né il font specificato né l’obiettivo di fallback hanno un glifo. In altre parole □ è la «traccia di un fallimento di fallback», e i dati sono spesso ancora vivi

Il fallback è un meccanismo di soccorso; non è un sostituto dello scegliere il font corretto fin dall’inizio.¹⁵ In un’app aziendale la posizione sana è «sui percorsi principali di visualizzazione e stampa, completate con i soli font progettati; il fallback è assicurazione per caratteri inattesi». Per il ragionamento della selezione dei font in un’UI multilingue, vedete anche «Internazionalizzazione delle app WinForms/WPF».

9. Una checklist di implementazione per le app aziendali

Infine, i punti da confermare a ciascun strato dall’input attraverso l’interoperazione sono riassunti in una tabella.

La normalizzazione in particolare è una trappola che è il tema stesso di questo articolo: un processo applicato «con buone intenzioni» che schiaccia la distinzione dei caratteri varianti e di fullwidth rispetto a halfwidth. L’originale così com’è; l’elaborazione su una copia è il principio. Gli incidenti di encoding dei caratteri nell’interoperazione CSV sono coperti in profondità in «Il CSV non è “solo testo”».

flowchart TB
    accTitle: L'originale così com'è; l'elaborazione su una copia
    accDescr: Memorizzate la stringa inserita così com'è come originale; applicate la normalizzazione a una copia limitata a un uso come generare una chiave di ricerca; applicare NFKC all'originale perde la distinzione dei caratteri varianti e di fullwidth rispetto a halfwidth
    input["La stringa inserita"] --> orig["Originale: memorizzate come inserito"]
    input --> copy["Copia: normalizzate, limitata a un uso"]
    copy -.-> use["Generare una chiave di ricerca, e simili"]
    orig -.-> ng["NFKC sull'originale schiaccia le distinzioni"]

Figura 15: Limitate la normalizzazione a un uso e applicatela a una copia; memorizzate l’originale come inserito.

10. Riepilogo

• Spezzate prima i problemi di caratteri nello «strato dati (codifica dei caratteri)» e nello «strato aspetto (font)». � è un segno di un incidente allo strato dati, □ di un incidente allo strato aspetto.
• JIS X 0213:2004 ha cambiato i glifi esemplari di 168 caratteri, e Windows ha i glifi JIS2004 come default da Vista in poi. Che 葛, 辻 e 飴 abbiano un aspetto diverso per ambiente è la storia dei font, non corruzione dei dati.
• Il mezzo standard per fissare un glifo come dato è IVS, ma senza un font che lo supporta e un’app che lo supporta decade al glifo di default. Non dimenticate l’impatto di implementazione che un carattere può arrivare a quattro unità di codice UTF-16.
• I gaiji (EUDC) sono un asset specifico di quel PC e non possono viaggiare con i dati. La risposta realistica è inventariare al momento della migrazione, sostituire da una tabella di corrispondenza verso caratteri regolari o IVS, e smettere di crearne di nuovi.
• Un sistema che gestisce nomi di persona decide il set di caratteri accettato e lo dichiara. Il governo sta standardizzando verso i Caratteri standard per gli affari amministrativi sulla fondazione dei Caratteri unificati del koseki e della Piattaforma di informazioni sui caratteri, e un sistema che interopera deve seguire quel movimento.
• Per moduli e PDF, «allineare il font con lo schermo, confermare la licenza e incorporare» è la baseline. Per la conservazione a lungo termine, considerate PDF/A.
• La normalizzazione NFKC, lo slicing per unità di codice e la conversione CP932 sono i tre punti che rompono in silenzio i caratteri varianti e i gaiji. Fate della memorizzazione dell’originale e dell’elaborazione in unità di grafema il principio.

La prossima volta che vi dicono «il carattere è diverso», prima riformulate la domanda così. I code point sono gli stessi, o diversi? Se sono gli stessi è un problema di font; se sono diversi è un problema di dati. Quella sola mossa vi tiene dal prendere il punto di ingresso sbagliato per l’indagine.

flowchart TB
    accTitle: La prima domanda che decide il punto di ingresso dell'indagine
    accDescr: Quando vi dicono che il carattere è diverso, prima confrontate se i code point sono gli stessi o diversi; se sono gli stessi iniziate l'indagine come un problema di font, se sono diversi come un problema di dati
    said["Vi è stato detto che il carattere è diverso"] --> cmp{"I code point sono gli stessi?"}
    cmp -->|Gli stessi| fontp["Un problema di font"]
    cmp -->|Diversi| datap["Un problema di dati"]

Figura 16: Se i code point sono gli stessi, iniziate l’indagine come un problema di font; se sono diversi, come un problema di dati.

Articoli correlati

• Introduzione alle codifiche di testo Windows - Il mojibake che avviene integrando con Linux
• Codifiche di testo Windows e fine riga - Le basi di mojibake e CRLF/LF
• Stampa e output PDF nelle applicazioni aziendali Windows — come scegliere tra System.Drawing.Printing, WPF e librerie di report
• Internazionalizzazione delle app WinForms/WPF — la pratica di resx, satellite assembly e cambio cultura
• Il CSV non è “solo testo”: La gestione pratica dei file CSV nelle applicazioni aziendali C# (codifica dei caratteri, compatibilità con Excel, protezione dalle injection)
• Introduzione all’accessibilità delle app Windows — Prepararsi a UI Automation e agli obblighi di accomodamento ragionevole

Aree di consulenza correlate

KomuraSoft LLC si occupa di progetto e indagine intorno ai caratteri nei sistemi aziendali. Dall’isolare la causa di sintomi come «il carattere differisce a schermo e sul modulo» o «dopo la migrazione un nome di persona è diventato □», attraverso l’inventario dei gaiji e la costruzione di una tabella di caratteri sostitutivi alla migrazione da un sistema legacy, il progetto del set di caratteri accettato di un sistema che gestisce nomi di persona, e la revisione della configurazione di incorporamento dei font di moduli e PDF, copriamo sia lo strato del codice sia quello del font.

• Sviluppo di app Windows
• Riutilizzo di asset esistenti e supporto alla migrazione
• Consulenza tecnica e revisione della progettazione
• Contattaci

Riferimenti

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Perché lo stesso carattere 葛 ha un aspetto diverso a seconda del PC o del modulo stampato?

È più probabilmente una differenza di glifi del font che mojibake. JIS X 0213:2004 (JIS2004) ha rivisto i glifi esemplari di 168 kanji verso le forme dello standard di stampa, e anche Windows ha reso i glifi JIS2004 il default in MS Gothic / MS Mincho e altri da Vista in poi. 葛, 辻, 飴 e simili sono esempi rappresentativi: il code point Unicode (i dati) resta lo stesso, e solo il glifo che il font detiene (l'aspetto) è cambiato. Confrontate i dati e coincidono; una discordanza di forma tra l'immagine di un modulo dell'era XP e lo schermo di un PC nuovo è comportamento specificato. Se volete allineare anche i glifi, usate lo stesso font a schermo e sul modulo, oppure specificate il glifo con un selettore di variazione ideografica.

Se usiamo i selettori di variazione ideografica (IVS), risolviamo ogni problema di glifo nei nomi di persona?

No. IVS è un meccanismo che piazza un selettore da U+E0100 in poi subito dopo un carattere base per specificare un glifo come dato, e il glifo specificato viene visualizzato solo quando sono presenti sia un font che lo supporta, come IPAmj Mincho, sia un'app che lo supporta. In un ambiente che non lo supporta il comportamento specificato è che il selettore viene ignorato e viene mostrato il glifo di default del carattere base; in alcuni ambienti il selettore può anche comparire come □. Inoltre, un carattere con IVS può arrivare a quattro unità di codice in UTF-16, il che influisce sul conteggio dei caratteri, sul slicing e sul progetto delle lunghezze di colonna DB. Se lo introducete, confermate l'ambito di supporto attraverso visualizzazione, stampa e sistemi a valle prima di usarlo.

Un carattere registrato come gaiji (EUDC) può visualizzarsi su un altro PC o in un PDF?

In principio no. Gaiji è un meccanismo in cui un utente registra un glifo nel file eudc.tte di quel PC a un code point nell'Area di uso privato Unicode (da U+E000 in poi); lo stesso code point è indefinito o è un glifo diverso su un altro PC. Il destino di passarlo a mail, a un PDF o a un altro sistema è quindi che diventa □ o assomiglia a un carattere diverso. Se avete già ereditato dati che contengono gaiji, il percorso realistico al momento della migrazione è inventariare gli usi dell'Area di uso privato, costruire una tabella di corrispondenza verso caratteri Unicode regolari o selettori di variazione ideografica, e sostituire. Dovreste evitare di creare nuovi gaiji in un sistema nuovo.

Fino a che punto un sistema aziendale dovrebbe accettare caratteri nei nomi di persona?

La prima cosa è «decidere il set di caratteri accettato e dichiararlo come specifica». I registri di famiglia hanno circa 56.000 caratteri unificati del koseki, e i sistemi conformi allo standard governativo si stanno muovendo verso l'uso dei Caratteri standard per gli affari amministrativi, un'estensione della Piattaforma di informazioni sui caratteri — ma un sistema aziendale generale non ha alcun obbligo di accettare lo stesso livello senza limiti. Un progetto realistico è decidere un ambito come «fino all'ambito di JIS X 0213» o «non accettare selettori di variazione ideografica o l'Area di uso privato», validare in input, e operare i casi fuori ambito con un avviso o una rappresentazione alternativa. Solo i sistemi che interoperano con sistemi governativi o comuni devono seguire il movimento dei Caratteri standard per gli affari amministrativi e i requisiti di interoperazione basati su JIS X 0221.

Come facciamo a far sì che un modulo o un PDF mostri gli stessi caratteri dello schermo?

La baseline è specificare lo stesso font a schermo e sul modulo, e incorporare il font nel PDF. Se i font differiscono, gli stessi dati possono cambiare glifo; se il PC di visualizzazione non ha il font, viene usato un font sostitutivo per il disegno e l'aspetto si rompe. Se l'incorporamento è consentito lo determina la licenza del font (OpenType fsType), quindi confermatela invece di lasciarla alla libreria di report. L'incorporamento subset, che incorpora solo i caratteri usati, tiene anche giù la dimensione del file. Se la conservazione a lungo termine è un requisito, considerate PDF/A, che richiede l'incorporamento del font.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.