Fallstricke bei japanischen Schriften und Zeichen — Umgang mit JIS2004, IVS und Gaiji in Geschäftsanwendungen

„Das Zeichen 葛 in der Kundenliste sieht auf dem Bildschirm und auf dem gedruckten Formular anders aus. Der Kunde hat sich beschwert, die Daten müssten beschädigt sein.“ — In der Wartung von Geschäftssystemen ist diese Art von Anfrage nicht selten. Eine weitere häufige ist: „Ein Zeichen in einem Personennamen wird auf einem Dokument, das wir bei der Behörde einreichen, nicht angezeigt. Auf dem alten PC wurde es angezeigt; nach dem Austausch wurde es zu □.“

Beide werden vor Ort gern „Mojibake“ genannt, aber sie sind ein anderes Problem als das Mojibake, das von einer Kodierungsabweichung kommt. Im ersten Fall hat sich kein Bit der Daten geändert und nur das Erscheinungsbild hat sich geändert; im zweiten ist ein „Gaiji“, das nur auf diesem PC existierte, verloren gegangen.

flowchart TB
    accTitle: Was die zwei häufigen Anfragen wirklich sind
    accDescr: Die Anfrage, dass 葛 auf dem Bildschirm und auf dem Formular anders aussieht, ist ein Fall, in dem nur das Erscheinungsbild geändert hat, während die Daten gleich geblieben sind; die Anfrage, dass ein Zeichen nach einem PC-Austausch zu □ wurde, ist ein Fall, in dem ein Gaiji, das nur auf diesem PC existierte, verloren ging; beide sind ein anderes Problem als Kodierungs-Mojibake
    c1["Anfrage 1: die Form unterscheidet sich auf Bildschirm und Formular"] --> r1["Die Daten sind unverändert; nur das Erscheinungsbild hat sich geändert"]
    c2["Anfrage 2: es wurde nach einem Austausch zu □"] --> r2["Ein Gaiji, das nur auf diesem PC existierte, ging verloren"]
    r1 --> diff["Ein anderes Problem als Kodierungs-Mojibake"]
    r2 --> diff

Abbildung 1: Die zwei Anfragen, die gern „Mojibake“ genannt werden, sind beide ein anderes Problem als eine Kodierungsabweichung.

Das Versprechen dieses Artikels ist einfach. Wenn Sie die Zeichencode-Schicht (Daten) von der Schrift-Schicht (Erscheinungsbild) trennen, werden die meisten japanischen Zeichenprobleme handhabbar. Von der JIS2004-Glyphenänderung, ideografischen Variationsselektoren (IVS) und Gaiji (EUDC) über die Zeichenplattform der Regierung bis zur Auswahl und Einbettung von Schriften ist es so organisiert, dass Entwickler von Geschäftssystemen und IT-Personal es für Entscheidungen nutzen können.

Das „Mojibake“ selbst, das bei der Konvertierung Shift_JIS ↔ UTF-8 entsteht, wird in bestehenden Artikeln behandelt, daher konzentriert sich dieser Artikel auf das Problem „die Codes machen den Roundtrip korrekt, aber Erscheinungsbild oder Anzeigbarkeit stimmen nicht“.

1. Zuerst die Kernaussage

• „Mojibake“ und „die Glyphe ist anders“ sind unterschiedliche Probleme. Mojibake ist ein Unfall auf der Datenschicht durch Fehlinterpretation einer Bytefolge; ein Glyphenunterschied ist ein Unfall auf der Erscheinungsschicht durch einen Unterschied der Glyphen, die eine Schrift hält; die Abhilfen sind völlig verschieden.
• Selbst bei demselben Unicode-Codepunkt hängt die angezeigte Glyphe von der Schrift ab. JIS X 0213:2004 hat die Beispielglyphen von 168 Zeichen wie 葛, 辻 und 飴 auf die drucküblichen Formen überarbeitet, und auch Windows hat ab Vista die JIS2004-Glyphen in MS Gothic / MS Mincho zum Standard gemacht.¹²
• Das Standardmittel, eine Glyphe als Daten festzulegen, ist ein ideografischer Variationsselektor (IVS). Sie spezifizieren eine Glyphe mit der Folge aus einem Basiszeichen plus einem Selektor ab U+E0100; Sammlungen wie Adobe-Japan1, Hanyo-Denshi und Moji_Joho (die Zeicheninformationsplattform) sind in Unicodes IVD registriert.³⁴
• In einer nicht unterstützenden Umgebung lautet das spezifizierte Verhalten von IVS, dass der Selektor ignoriert und die Standardglyphe des Basiszeichens angezeigt wird. Ein IVS-tragendes Zeichen kann jedoch in UTF-16 bis zu vier Codeeinheiten umfassen, daher brauchen Implementierungen von Zeichenzählung und Zerteilung Sorgfalt.⁵
• Gaiji (EUDC) hat das Schicksal „es kann nur auf diesem PC angezeigt werden“. Es gibt keine vereinbarte Bedeutung für einen Codepunkt der Private Use Area, und eine in eudc.tte registrierte Glyphe reist nicht zu einem anderen PC, zu Mail oder zu einem PDF.⁶⁷
• Ein System, das Personennamen verarbeitet, sollte den akzeptierten Zeichensatz festlegen und erklären. Auf der Regierungsseite bewegen sich konforme Systeme auf der Grundlage der Koseki-Vereinheitlichungszeichen und der Zeicheninformationsplattform hin zur Nutzung der „Standardzeichen für Verwaltungsangelegenheiten“.⁸⁹¹⁰
• Für Formulare und PDFs ist „die Schrift mit dem Bildschirm angleichen und einbetten“ die Grundlage. Ob Einbettung erlaubt ist, bestimmt die Lizenz der Schrift (fsType), und PDF/A für langfristige Aufbewahrung verlangt Schrifteinbettung.¹¹¹²
• Wenden Sie Normalisierung (NFKC) nicht leichthin auf Personennamendaten an. Voll- und Halbbreite zu vereinheitlichen und Kompatibilitätszeichen zu ersetzen, verliert Unterscheidungen, die Sie behalten sollten.¹³

In einem Satz: „welche Bytefolge Sie speichern“ ist ein Datendesignproblem; „wie es aussieht“ ist ein Schriftdesignproblem. Wenn Sie die beiden vermischt diskutieren, werden selbst Probleme, die Sie beheben könnten, unbehebbar.

2. Daten und Erscheinungsbild getrennt denken — Codepunkte und Glyphen

In Unicode wird ein Zeichen durch eine Zahl dargestellt, die Codepunkt heißt. 葛 ist U+845B, und diese Zahl ist auf jedem PC dieselbe. Wie diese Zahl auf einem Bildschirm oder auf Papier gezeichnet wird, entscheidet dagegen die Glyphe, die die Schrift hält. Es ist normales Verhalten, dass dasselbe U+845B in den Formdetails zwischen Schrift A und Schrift B abweicht.

Mit diesen zwei Schichten als Voraussetzung lassen sich Feldsymptome wie folgt aufteilen.

Als Hinweis für die Aufteilung ist es nützlich, den Unterschied zwischen „�“ und „□“ zu merken. Das „�“ von U+FFFD (REPLACEMENT CHARACTER) ist eine Spur eines Konvertierungsfehlers auf der Datenschicht, und das Originalzeichen ist bereits verloren. „□“ dagegen ist in vielen Fällen nur, dass die Daten noch da sind, die Schrift aber keine Glyphe hat, und ein Schriftwechsel kann es anzeigbar machen.

flowchart TB
    accTitle: Das Symptom nach � versus □ aufteilen
    accDescr: Wenn ein Zeichen nicht korrekt angezeigt wird, ist � eine Spur eines Konvertierungsfehlers auf der Datenschicht, bei dem das Originalzeichen verloren ist; □ bedeutet nur, dass die Daten noch da sind, die Schrift aber keine Glyphe hat, und ein Schriftwechsel kann es anzeigbar machen
    symptom["Ein Zeichen wird nicht korrekt angezeigt"] --> which{"Was sehen Sie?"}
    which -->|Sie sehen �| datalayer["Ein Unfall auf der Datenschicht"]
    datalayer -.-> lost["Eine Spur eines Konvertierungsfehlers （das Originalzeichen ist verloren）"]
    which -->|Sie sehen □| viewlayer["Ein Unfall auf der Erscheinungsschicht"]
    viewlayer -.-> noglyph["Nur dass die Schrift keine Glyphe hat"]
    noglyph --> fixable["Ein Schriftwechsel kann es anzeigbar machen"]

Abbildung 2: � ist ein Zeichen eines Unfalls auf der Datenschicht, □ eines auf der Erscheinungsschicht, und der Einstieg der Untersuchung ändert sich.

Die Grundlagen der Kodierungen selbst (CP932 und UTF-8, BOM, Zeilenumbruchcodes) werden in „Einführung in Windows-Zeichenkodierungen - Mojibake im Zusammenspiel mit Linux“ und „Windows-Zeichenkodierung und Zeilenumbrüche - Die Grundlagen von Mojibake und CRLF/LF“ behandelt. Ab hier ist es die Erscheinungsschicht und die Probleme, die an ihrer Grenze auftreten.

3. Von JIS90 zu JIS2004 — Die Glyphe hat sich geändert, der Code ist gleich geblieben

Die Identität des einleitenden „葛 sieht auf dem Bildschirm und auf dem Formular anders aus“ liegt in vielen Fällen hier.

Im Anschluss an den Bericht 2000 des National Language Council „Hyogai Kanji Jitaihyo“ (die Tabelle der Zeichenformen für Kanji außerhalb der Joyo-Liste) hat die Revision 2004 JIS X 0213:2004 (üblicherweise JIS2004) die Beispielglyphen von 168 Kanji auf die drucküblichen Formen überarbeitet, nahe den sogenannten Kangxi-Wörterbuchformen. 葛, 辻, 飴, 芦, 溢, 餅 und ähnliche sind typische Beispiele.¹

Windows hat sich daran ausgerichtet und ab Windows Vista die JIS2004-Glyphen in MS Gothic / MS Mincho (und dem neu eingeführten Meiryo) zum Standard gemacht. Auch das heutige MS Gothic hat eine JIS2004-basierte Standardglyphe, mit der Struktur, dass Glyphen der JIS90-Ära über das OpenType-Merkmal jp90 erreichbar sind.²¹

flowchart TB
    accTitle: Die Glyphenstruktur des heutigen MS Gothic
    accDescr: Ab Vista hat MS Gothic JIS2004-Glyphen als Standard, und der Zugriff auf Glyphen der JIS90-Ära über das OpenType-Merkmal jp90 ist die Struktur
    msg["MS Gothic （ab Vista）"] --> def["Standardglyphe: JIS2004-basiert"]
    msg --> feat["Über das Merkmal jp90"]
    feat --> old["Glyphen der JIS90-Ära"]

Abbildung 3: Das heutige MS Gothic hat JIS2004-Glyphen als Standard und kann mit dem Merkmal jp90 auf JIS90-Glyphen umschalten.

Was hier zählt, ist, dass nur die Schrift sich geändert hat; die Daten haben sich überhaupt nicht geändert.

• Der Codepunkt von 葛 ist auf XP und auf Windows 11 U+845B
• Auf XP (JIS90-Glyphen) wird es in der Form angezeigt, die das Innere des umschließenden Radikals zu ヒ vereinfacht; ab Vista (JIS2004-Glyphen) wird es in der Form angezeigt, die innen auch 人 schreibt
• Daher stimmen das gescannte Bild eines auf dem alten System gedruckten Formulars und die Bildschirmanzeige auf einem neuen PC in der Zeichenform nicht überein. Ein Datenvergleich stimmt vollständig

Ob das Shinnyo-Radikal von 辻 einen Punkt oder zwei hat, die Form des „Essen“-Radikals von 飴 und Ähnliches sind dasselbe. Wenn Sie diese Geschichte nicht kennen, geht die Untersuchung gern in die falsche Richtung „die Daten wurden bei der Migration beschädigt“. Wenn man Ihnen sagt, das Erscheinungsbild eines Zeichens unterscheide sich vor und nach einer Migration, vergleichen Sie zuerst die Codepunkte, und wenn sie übereinstimmen, verdächtigen Sie einen Schriftglyphenunterschied — das ist die richtige Reihenfolge.

flowchart TB
    accTitle: Derselbe Codepunkt, eine andere Glyphe je nach Schrift
    accDescr: Der Codepunkt U+845B von 葛 bleibt auf XP und auf Windows 11 derselbe; nur die angezeigte Form ändert sich zwischen einer JIS90-Glyphen-Schrift und einer JIS2004-Glyphen-Schrift, und ein Datenvergleich stimmt vollständig
    cp["Codepunkt U+845B （葛）"] --> f90["Eine JIS90-Glyphen-Schrift （XP）"]
    cp --> f04["Eine JIS2004-Glyphen-Schrift （ab Vista）"]
    f90 --> g90["Die Form, die das Innere zu ヒ vereinfacht"]
    f04 --> g04["Die druckübliche Form, die innen 人 schreibt"]
    g90 -.-> same["Ein Datenvergleich stimmt vollständig"]
    g04 -.-> same

Abbildung 4: Nur die Schrift hat sich geändert; der Codepunkt U+845B bleibt in jeder Umgebung derselbe.

Beachten Sie, dass beide Glyphen „dasselbe Zeichen“ sind, weil sich das Zeichen selbst nicht geändert hat. Bei Personennamen besteht die Person oder eine Behörde jedoch manchmal auf einer bestimmten Form, und der Forderung nachzukommen, das „als Daten“ zu unterscheiden, ist das nächste Thema, IVS.

4. Ideografische Variationsselektoren (IVS) — Eine Glyphe als Daten festlegen

IVS (Ideographic Variation Sequence) ist ein Mechanismus, der unmittelbar nach einem Kanji einen unsichtbaren Codepunkt namens „ideografischer Variationsselektor“ setzt, um eine Glyphenvariante als Daten festzulegen. Die verwendeten Selektoren sind U+E0100–U+E01EF (VS17–VS256).³

Welche Folge „Basiszeichen + Selektor“ auf welche Glyphe verweist, entscheidet ein Register namens IVD (Ideographic Variation Database), das das Unicode Consortium verwaltet. Die wichtigsten Sammlungen sind die folgenden.⁴

Die Dokumentation von Microsoft gibt zum Beispiel an, dass U+845B allein (葛) in der Schreibweise des Bahnhofs Nishi-Kasai verwendet wird und U+845B+U+E0100 (VS17) in der Schreibweise der Stadt Katsuragi, Nara. Dasselbe 葛, aber welche Glyphe es ist, lässt sich als Daten unterscheiden.³

flowchart TB
    accTitle: Ein Beispiel, dasselbe 葛 mit IVS als Daten zu unterscheiden
    accDescr: 葛 als U+845B allein wird in der Schreibweise des Bahnhofs Nishi-Kasai verwendet; die Folge von U+845B gefolgt von VS17 wird in der Schreibweise der Stadt Katsuragi verwendet; welche Folge auf welche Glyphe verweist, entscheidet das IVD-Register
    seq1["U+845B allein"] --> gl1["Die Glyphe in der Schreibweise des Bahnhofs Nishi-Kasai"]
    seq2["U+845B + VS17"] --> gl2["Die Glyphe in der Schreibweise der Stadt Katsuragi"]
    ivd["IVD （das Register）"] -.-> gl1
    ivd -.-> gl2

Abbildung 5: Selbst bei demselben 葛 lässt An- oder Abwesenheit eines Selektors als Daten unterscheiden, welche Glyphe es ist.

4.1. Verhalten in einer Umgebung, die es nicht unterstützt

Auf der Schriftseite ist die Zuordnung zwischen einem IVS und einer Glyphe in der OpenType-cmap-Tabelle (Format 14) implementiert.⁵ Wenn eine unterstützende Schrift (IPAmj Mincho und ähnliche) und eine unterstützende App beide vorhanden sind, erscheint die angegebene Glyphe; wenn nicht, verläuft es wie folgt.

• Das spezifizierte korrekte Verhalten: der Selektor wird ignoriert und die Standardglyphe des Basiszeichens angezeigt (der Selektor selbst ist unsichtbar)
• Ältere Apps und manche Zeichenstapel: der Selektor wird als unabhängiges unbekanntes Zeichen behandelt, und ein zusätzliches □ wird angezeigt

Mit anderen Worten ist IVS so entworfen, dass „selbst wenn es degradiert, das Basiszeichen lesbar bleibt“, aber eine Garantie, dass „es immer in der angegebenen Glyphe angezeigt wird“, hängt von der Empfängerumgebung ab. Regierungsseitige Einwohner- und Personenstandsregister nutzen die Kombination aus einer Schrift der Zeicheninformationsplattform plus IVS, aber wenn ein allgemeines Geschäftssystem es leichthin akzeptiert, fällt die Glyphe irgendwo in Anzeige, Druck oder einem nachgelagerten System aus.

flowchart TB
    accTitle: Wie IVS-tragende Daten angezeigt werden
    accDescr: Wenn eine unterstützende Schrift und eine unterstützende App beide vorhanden sind, wird es in der angegebenen Glyphe angezeigt; wenn nicht, wird der Selektor ignoriert und die Standardglyphe des Basiszeichens gezeigt; in älteren Apps und manchen Zeichenstapeln wird der Selektor als unbekanntes Zeichen behandelt und ein zusätzliches □ angezeigt
    ivs["Basis + IVS-Selektor"] --> env{"Unterstützende Schrift + App?"}
    env -->|Ja| ok["Angegebene Glyphe"]
    env -->|Nein| other{"Wie wird es gezeichnet?"}
    other -->|Ignoriert| ignore["Standardglyphe"]
    other -->|Älter / manche Stapel| tofu["Ein zusätzliches □"]
    ignore -.-> spec["Spezifiziert korrekt"]

Abbildung 6: IVS bleibt auch bei Degradierung als Basiszeichen lesbar, aber ob die angegebene Glyphe erscheint, hängt von der Empfängerumgebung ab.

4.2. Eine Implementierungswarnung — „Ein Zeichen“ kann bis zu vier Codeeinheiten umfassen

IVS-Selektoren ab U+E0100 sind Codepunkte auf einer Ergänzungsebene, daher sind sie in UTF-16 immer ein Surrogatpaar (zwei Codeeinheiten). Wenn das Basiszeichen ein Kanji der Ergänzungsebene ist (zum Beispiel 𠮟 (U+20B9F), in JIS2004 hinzugefügt), umfasst die Basis allein bereits zwei Codeeinheiten, und die Folge, die ein Benutzer als „ein Zeichen“ erkennt, umfasst in UTF-16 bis zu vier Codeeinheiten und in UTF-8 bis zu acht Bytes.

• C#s "葛󠄀" (葛+VS17) hat string.Length == 3. Substring und festlängenbasierte Zerteilung riskieren, das Basiszeichen vom Selektor zu trennen
• Validierung der Zeichenzahl und Zerteilung sollten in Graphem-Einheiten geschehen (APIs wie StringInfo), nicht in Codeeinheiten
• Für die Datenbankspaltenlänge (nvarchar(n) von SQL Server ist in UTF-16-Codeeinheiten) sollten Sie, wenn Sie IVS akzeptieren, das Zwei- bis Vierfache der scheinbaren Zeichenzahl vorsehen
• Bei Suche und Vergleich macht An- oder Abwesenheit eines Selektors eine andere Zeichenkette. Ob eine Suche nach „葛“ „葛+VS17“ trifft, müssen Sie als Anforderung entscheiden und implementieren

flowchart TB
    accTitle: Ein IVS-tragendes Zeichen und UTF-16-Codeeinheiten
    accDescr: Die Folge aus einem Basiszeichen und einem ideografischen Variationsselektor, die ein Benutzer als ein Zeichen erkennt, ist für den Selektor immer ein Surrogatpaar, und wenn das Basiszeichen ein Kanji der Ergänzungsebene ist, kommen zwei weitere Codeeinheiten hinzu, höchstens vier Codeeinheiten in UTF-16
    one["Ein sichtbares Zeichen"] --> base["Basiszeichen"]
    one --> vs["Variationsselektor"]
    base -.-> bnote["+2 wenn Ergänzungsebene"]
    vs -.-> vnote["Immer 2 Codeeinheiten"]
    base --> total["Bis zu 4 UTF-16-Einheiten"]
    vs --> total
    total -.-> risk["Getrennt bei fester Zerteilung"]

Abbildung 7: Ein IVS-tragendes Zeichen kann in UTF-16 bis zu vier Codeeinheiten umfassen; Zerteilung nach Codeeinheit ist gefährlich.

5. Gaiji (EUDC) — Zeichen, die nur auf diesem PC angezeigt werden

Gaiji ist ein Mechanismus, bei dem ein Benutzer eine eigene Glyphe einem Codepunkt der Unicode Private Use Area (PUA: U+E000–U+F8FF und ähnliche) zuweist. Ein Codepunkt der Private Use Area hat keine weltweit vereinbarte Bedeutung; dasselbe U+E000 kann pro PC und pro Organisation ein anderes Zeichen zugewiesen bekommen.⁶

Unter Windows erstellen Sie die Glyphe mit dem Private Character Editor (eudcedit.exe), und sie wird in einer Schriftdatei namens eudc.tte gespeichert. Diese Datei wird als versteckte Schrift installiert und in der Registrierung HKEY_CURRENT_USER\EUDC jeder Schrift zugeordnet.⁷ In der Shift_JIS-Ära (CP932) war der Gaiji-Bereich 0xF040–0xF9FC, und bei der Konvertierung nach Unicode wird er auf die Private Use Area abgebildet.

Die Folge dieses Mechanismus ist klar.

• eudc.tte gehört zu diesem PC (diesem Benutzer) und reist nicht mit den Daten zur Gegenseite
• Sobald es an Mail, ein PDF, das Web oder ein anderes System weitergegeben wird, wird es zu □ oder sieht aus wie das andere Gaiji der Gegenseite
• Wenn Sie bei einer OS-Migration oder einem PC-Austausch vergessen, eudc.tte zu migrieren, tritt „ein Zeichen, das auf dem alten PC angezeigt wurde, wird nicht angezeigt“ auf

Das ist die Identität der zweiten Anfrage der Einleitung.

flowchart TB
    accTitle: Warum Gaiji nur auf diesem PC angezeigt werden
    accDescr: Eine im Private Character Editor erstellte Glyphe wird in eudc.tte gespeichert und in der Registrierung dieses PCs Schriften zugeordnet, sodass nur der PUA-Code an Mail, ein PDF oder ein anderes System weitergegeben wird und zu □ wird oder wie ein anderes Zeichen aussieht
    edit["Eine PUA-Glyphe erstellen"] --> tte["In eudc.tte speichern"]
    edit -.-> editN["Private Char. Editor"]
    tte --> reg["Schriftzuordnung der Registrierung"]
    reg --> local["Wird auf diesem PC angezeigt"]
    tte -.-> stay["eudc.tte bleibt zurück"]
    send["Nur der PUA-Code geht"] --> dest["Mail / PDF / anderes Sys"]
    dest --> broken["□ oder ein falsches Zeichen"]
    local ~~~ send

Abbildung 8: Die Glyphe lebt in eudc.tte; in den Daten bleibt nur eine Nummer der Private Use Area, daher wirken Gaiji gebrochen, sobald sie den PC verlassen.

5.1. Eine realistische Antwort für ein System, das bereits Gaiji empfangen hat

Das Problem ist, wenn aus einem Altsystem geerbte Daten bereits Gaiji gemischt haben. Das Verfahren, das wir bei Migrationsaufträgen empfehlen, ist das folgende.

1. Untersuchen: Datenbanken und Dateien mit einem regulären Ausdruck nach der Private Use Area (U+E000–U+F8FF) scannen und die genutzten Gaiji-Codes und ihre Anzahlen inventarisieren. eudc.tte von PCs an jedem Standort sammeln und die Glyphen bestätigen
2. Identifizieren: für jedes Gaiji prüfen „kann es als reguläres Unicode-Zeichen dargestellt werden“, „kann es mit IVS dargestellt werden“, „gibt es ein entsprechendes Zeichen in der Zeicheninformationsplattform (MJ)“, und eine Ersatzzeichen-Zuordnungstabelle aufbauen. In der Praxis sind die meisten Fälle einfach, dass eine alte Form als JIS-Gaiji angelegt worden war
3. Ersetzen: die Daten aus der Zuordnungstabelle ersetzen. Nur wenn wirklich kein entsprechendes Zeichen existiert, als Bild behalten oder dem Datensatz eine Notiz anhängen
4. Abschneiden: im neuen System Private-Use-Area-Eingabe in der Validierung ablehnen und keine neuen Gaiji anlegen

flowchart TB
    accTitle: Das Verfahren zur Migration von Daten, die Gaiji enthalten
    accDescr: Genutzte Gaiji inventarisieren, indem die Private Use Area gescannt und eudc.tte gesammelt wird, eine Ersatzzeichen-Zuordnungstabelle aufbauen und ersetzen, und im neuen System Private-Use-Area-Eingabe in der Validierung ablehnen und keine neuen Gaiji anlegen
    st1["Untersuchen: PUA scannen"] --> st2["Identifizieren: Ersatz-Tabelle"]
    st2 --> st3["Aus der Tabelle ersetzen"]
    st3 --> st4["Abschneiden: keine neuen Gaiji"]
    st1 -.-> tte["eudc.tte sammeln"]
    st2 -.-> nomap["Keine Zuordnung: Bild oder Notiz"]

Abbildung 9: Migrieren Sie Gaiji in den vier Stufen Untersuchen, Identifizieren, Ersetzen und Abschneiden, und legen Sie keine neuen Gaiji an.

Die Richtung ist auf der Regierungsseite dieselbe: Es wurde eine Politik erklärt, die Gaiji, die Kommunen selbst angelegt haben (bundesweit etwa zwei Millionen Zeichen), eindeutig gegen die später beschriebenen Standardzeichen für Verwaltungsangelegenheiten zu identifizieren und ihre Nutzung einzustellen.¹⁰ „Gaiji nicht vermehren; sie gegen einen standardisierten Zeichensatz identifizieren“ wird im öffentlichen und im privaten Sektor zum etablierten Migrationsmuster.

6. Die Zeichenplattform der Regierung — Von Koseki-Vereinheitlichungszeichen zu Standardzeichen für Verwaltungsangelegenheiten

Beim Entwurf eines Systems, das Personennamen verarbeitet, wird die Kenntnis der regierungsseitigen Zeichenplattform Material, um zu entscheiden „wie weit akzeptieren“.

In kommunalen Kern-Geschäftssystemen (konforme Systeme) steht in der Standardspezifikation eine zweistufige Struktur: Standardzeichen für Verwaltungsangelegenheiten für den Informationsaustausch von Personennamen und Ähnlichem nutzen und mit externen Systemen ohne einheitliche Interoperabilitätsregeln — Smartphones und Ähnliches — im Umfang von JIS X 0213:2012 zusammenarbeiten.¹⁰ Die Struktur selbst, „intern einen breiten Zeichensatz zu halten und mit außen in einem Bereich auszutauschen, den eine allgemeine Umgebung anzeigen kann“, ist auch eine Referenz für Systeme der Privatwirtschaft.

flowchart TB
    accTitle: Die zweistufige Interoperabilität eines konformen Systems
    accDescr: Ein kommunales konformes System nutzt Standardzeichen für Verwaltungsangelegenheiten für den Informationsaustausch von Personennamen und Ähnlichem und arbeitet mit externen Systemen wie Smartphones ohne einheitliche Interoperabilitätsregeln im Umfang von JIS X 0213:2012 zusammen
    sys["Kommunales Standardsystem"] --> renkei["Namensaustausch"]
    sys --> gaibu["Externe Systeme"]
    renkei --> mjp["Verw.-Standardzeichen"]
    mjp -.-> mjpN["Personennamen usw."]
    gaibu --> jis["Umfang JIS X 0213:2012"]
    gaibu -.-> sumaho["Keine Regeln（Smartphone）"]
    mjp -.-> naibu["Breiter Satz intern gehalten"]

Abbildung 10: Eine zweistufige Struktur: Regierungsinteroperabilität nutzt Standardzeichen für Verwaltungsangelegenheiten; externe Interoperabilität ohne Regeln nutzt JIS X 0213:2012.

Als praktische Leitlinie für ein allgemeines Geschäftssystem empfehlen wir das Folgende.

• Legen Sie den akzeptierten Zeichensatz fest und erklären Sie ihn sowohl in der Spezifikation als auch in der Eingabevalidierung. Zum Beispiel „der Umfang von JIS X 0213:2012“, „die Private Use Area und kombinierende Zeichen sind nicht erlaubt“, „IVS wird nicht akzeptiert (oder wird akzeptiert, aber die Anzeige ist nur in einer IPAmj-Mincho-Umgebung garantiert)“
• Akzeptieren Sie nicht unbegrenzt. Ein Entwurf „es ist Unicode, also geht alles“ bricht irgendwo in Anzeige, Druck oder Interoperabilität
• Entscheiden Sie den Betrieb für Zeichen außerhalb des Bereichs im Voraus. Die Regel, eine Alternativdarstellung (eine neue Form, Katakana) zu ersetzen, und die Formulierung, die Sie der Person erklären, sind selbst Systemspezifikation
• Wenn ein nachgelagertes System wie Regierung oder Finanzen eine Zeichensatzregel hat, nehmen Sie die als maßgeblich und richten Sie sich danach

flowchart TB
    accTitle: Einen akzeptierten Zeichensatz entwerfen und betreiben
    accDescr: Legen Sie den akzeptierten Zeichensatz fest und erklären Sie ihn sowohl in der Spezifikation als auch in der Eingabevalidierung; akzeptieren Sie Zeichen im Bereich; für Zeichen außerhalb des Bereichs entscheiden Sie den Betrieb einschließlich der Regel für eine Alternativdarstellung und der Formulierung, die Sie der Person erklären
    decide["Den akzeptierten Zeichensatz festlegen"] --> spec["In der Spezifikation erklären"]
    decide --> valid["In der Eingabevalidierung erklären"]
    valid --> range{"Im Bereich?"}
    range -->|Ja| ok["Akzeptieren"]
    range -->|Nein| alt["Eine Alternativdarstellung ersetzen"]
    alt -.-> word["Die Formulierung, die Sie der Person erklären, ist auch Spezifikation"]

Abbildung 11: Erklären Sie den akzeptierten Zeichensatz sowohl in der Spezifikation als auch in der Eingabevalidierung, und entscheiden Sie auch den Betrieb außerhalb des Bereichs.

7. Schriften wählen und einbetten — Bildschirm und Formular angleichen

7.1. Der Charakter der üblichen Schriften

Was bei der Wahl zählt, ist weniger eine Schriftpräferenz als ob diese Schrift in jeder Umgebung existiert, die an Anzeige, Druck und PDF-Erzeugung beteiligt ist. Japanische Ergänzungsschriften auf Windows 10/11 (BIZ UD und ähnliche) fehlen je nach Konfiguration manchmal, und in einer Konfiguration, die PDFs serverseitig erzeugt, hat Vorhandensein oder Fehlen der Schrift auf dem Server eine direkte Wirkung.

flowchart TB
    accTitle: Die Umgebungen, die Sie bei der Schriftwahl prüfen
    accDescr: Bei der Schriftwahl zählt weniger eine Schriftpräferenz als ob diese Schrift in jeder Umgebung existiert, die an Anzeige, Druck und PDF-Erzeugung beteiligt ist; die Konfiguration von Ergänzungsschriften und Vorhandensein oder Fehlen der Schrift auf dem Server haben eine direkte Wirkung
    cand["Eine Kandidatenschrift"] --> exist["Auf jeder Umgebung?"]
    exist --> scr["Anzeigeumgebung"]
    exist --> more{"Druck oder PDF-Server?"}
    more --> prn["Druckumgebung"]
    more --> srv["PDF-Erzeugungsserver"]
    scr -.-> hojo["Ergänzungsschrift?"]
    hojo -.-> hojoN["Kann fehlen"]
    srv -.-> eikyo["Schrift auf dem Server zählt"]

Abbildung 12: Wählen Sie eine Schrift weniger nach Schriftpräferenz als danach, ob sie in jeder Umgebung von Anzeige, Druck und PDF-Erzeugung vorhanden ist.

7.2. Die Grundlagen des Formularentwurfs — Angleichen und einbetten

• Geben Sie dieselbe Schrift auf dem Bildschirm und auf dem Formular an. Wenn die Schriften unterschiedlich sind, können dieselben Daten wie eine andere Glyphe aussehen, und Sie erhalten die Beschwerde der Einleitung. Eine Konfiguration wie „Meiryo auf dem Bildschirm, MS Mincho auf dem Formular“ sollte zumindest darauf geprüft werden, ob es auf den 168 JIS2004-Zeichen einen Glyphenunterschied gibt
• Betten Sie die Schrift in das PDF ein. Wenn Sie nicht einbetten, zeichnet die Betrachtungsseite mit einer Schrift, die sie zur Hand hat, ersatzweise, und nicht nur die Glyphe, sondern auch das Layout kann sich ändern
• Ob Einbettung erlaubt ist, bestimmt die Lizenz. Eine OpenType-Schrift erklärt Einbettungsrechte im Feld fsType (Installable / Restricted / Preview & Print / Editable, no-subsetting und ähnliche), und Sie dürfen eine Schrift, deren Einbettung nicht lizenziert ist, nicht einbetten.¹¹ Bei einer kommerziellen Schrift ist die Vertragsprüfung erforderlich
• Machen Sie Teilmengeneinbettung zur Grundlage. Wenn Sie nur die Glyphen der verwendeten Zeichen einbetten, müssen Sie nicht eine ganze japanische Schrift (mehrere MB bis zehn MB) übernehmen
• Wenn es eine Anforderung langfristiger Aufbewahrung gibt, PDF/A. PDF/A (ISO 19005) ist ein Standard, der die zur Anzeige nötigen Ressourcen im Inneren der Datei vervollständigt, und Schrifteinbettung ist erforderlich.¹² Es ist auch der zuverlässigste Weg, „zehn Jahre später habe ich es geöffnet und die Glyphen hatten sich geändert“ zu verhindern

flowchart TB
    accTitle: Der Entscheidungsfluss für Schrifteinbettung
    accDescr: Bevor Sie eine Schrift in ein PDF einbetten, prüfen Sie die fsType-Einbettungslizenz; wenn sie lizenziert ist, machen Sie Teilmengeneinbettung zur Grundlage; wenn es eine Anforderung langfristiger Aufbewahrung gibt, erwägen Sie PDF/A, das Einbettung verlangt
    emb["Die Schrift in das PDF einbetten"] --> lic{"Ist Einbettung durch fsType lizenziert?"}
    lic -->|Lizenziert| sub["Teilmengeneinbettung ist die Grundlage"]
    lic -->|Nicht lizenziert| ng["Sie dürfen nicht einbetten"]
    sub -.-> gly["Nur die Glyphen der verwendeten Zeichen"]
    sub -->|Eine Anforderung langfristiger Aufbewahrung| pdfa["PDF/A erwägen"]
    pdfa -.-> must["Schrifteinbettung ist erforderlich"]

Abbildung 13: Einbettung setzt die Prüfung der fsType-Lizenz voraus; Teilmengeneinbettung und PDF/A sind die Grundlage.

Wie Sie ein Implementierungsmittel für Druck und PDF-Ausgabe wählen, wird ausführlich in „Drucken und PDF-Ausgabe in Windows-Geschäftsanwendungen — System.Drawing.Printing, WPF und Berichtsbibliotheken richtig einsetzen“ behandelt.

8. Schriftverknüpfung und Fallback — Das Phänomen „eine andere Schrift mischt sich ein“

Ein Zeichen, für das die angegebene Schrift keine Glyphe hat, wird nicht als nichts angezeigt; Ersatzzeichnen in einer anderen Schrift ist das Standardverhalten moderner Zeichenstapel. In GDI erledigt das die in der Registrierung definierte „Schriftverknüpfung“ (FontLink\SystemLink); in DirectWrite, WPF und Browsern tut das „Schrift-Fallback“.¹⁵

flowchart TB
    accTitle: Der Fluss von Schriftverknüpfung und Fallback
    accDescr: Wenn die angegebene Schrift eine Glyphe hat, wird sie so angezeigt; wenn nicht, wird sie in einer Verknüpfungs- oder Fallback-Schrift ersatzgezeichnet; wenn nirgendwo eine Glyphe existiert, wird es zu □, aber die Daten sind oft noch lebendig
    disp["Ein Zeichen anzeigen"] --> has{"Hat die angegebene Schrift eine Glyphe?"}
    has -->|Ja| draw["In der angegebenen Schrift anzeigen"]
    has -->|Nein| fb{"Ist es in einem Verknüpfungs- oder Fallback-Ziel?"}
    fb -->|Ja| alt["In einer anderen Schrift ersatzzeichnen"]
    alt -.-> mixed["Die Ursache eines gemischten Schriftgefühls"]
    fb -->|Nein| tofu["□ （Tofu） wird angezeigt"]
    tofu -.-> alive["Die Daten sind oft noch lebendig"]

Abbildung 14: □ ist die Spur eines Fallback-Fehlers; ob Ersatzzeichnen gelingt, ist die Gabelung zwischen „gemischt“ und „Tofu“.

Diesen Mechanismus zu kennen, lässt Sie die folgenden häufigen Fälle erklären.

• Das Schriftgefühl unterscheidet sich zwischen Latein und Japanisch: weil zuerst eine lateinische Schrift angegeben wurde, wird nur der japanische Anteil in einer verknüpften oder Fallback-japanischen Schrift gezeichnet
• Nur die Kanji in einem japanischen Satz werden zu einer chinesisch wirkenden Glyphe: das Fallback-Ziel hat sich zu einer chinesischen Schrift aufgelöst. Leicht auf einer Webseite oder in einer App, die Sprachinformation (ein lang-Attribut oder eine Locale) nicht korrekt übergibt
• Tofu (□) erscheint: weder die angegebene Schrift noch das Fallback-Ziel hat eine Glyphe. Mit anderen Worten ist □ die „Spur eines Fallback-Fehlers“, und die Daten sind oft noch lebendig

Fallback ist ein Entlastungsmechanismus; es ist kein Ersatz dafür, von Anfang an die richtige Schrift zu wählen.¹⁵ In einer Geschäftsanwendung ist die gesunde Haltung „auf den Hauptanzeige- und Druckpfaden mit den entworfenen Schriften allein fertig werden; Fallback ist Versicherung für unerwartete Zeichen“. Zum Denken der Schriftwahl in einer mehrsprachigen UI siehe auch „Mehrsprachigkeit für WinForms/WPF-Anwendungen ── resx, Satelliten-Assemblies und Kulturumschaltung in der Praxis“.

9. Eine Implementierungs-Checkliste für Geschäftsanwendungen

Schließlich sind die Punkte, die Sie auf jeder Schicht von der Eingabe bis zur Interoperabilität prüfen, in einer Tabelle zusammengefasst.

Normalisierung insbesondere ist eine Falle, die das Thema dieses Artikels selbst ist: eine Verarbeitung, die „in guter Absicht“ angewendet wird und die Unterscheidung von Variantenzeichen und von Voll- versus Halbbreite zerdrückt. Das Original unverändert; Verarbeitung auf einer Kopie ist das Prinzip. Zeichenkodierungsunfälle in der CSV-Interoperabilität werden ausführlich in „CSV ist nicht „nur Text“ ── CSV in der Praxis für C#-Business-Anwendungen (Zeichenkodierung, Excel-Kompatibilität, Schutz vor Injection)“ behandelt.

flowchart TB
    accTitle: Das Original unverändert; Verarbeitung auf einer Kopie
    accDescr: Speichern Sie die eingegebene Zeichenkette unverändert als Original; wenden Sie Normalisierung auf eine auf einen Zweck begrenzte Kopie an, etwa einen Suchschlüssel zu erzeugen; NFKC auf das Original anzuwenden, verliert die Unterscheidung von Variantenzeichen und von Voll- versus Halbbreite
    input["Die eingegebene Zeichenkette"] --> orig["Original: wie eingegeben speichern"]
    input --> copy["Kopie: normalisieren, auf einen Zweck begrenzt"]
    copy -.-> use["Einen Suchschlüssel erzeugen und Ähnliches"]
    orig -.-> ng["NFKC auf das Original zerdrückt Unterscheidungen"]

Abbildung 15: Begrenzen Sie Normalisierung auf einen Zweck und wenden Sie sie auf eine Kopie an; speichern Sie das Original wie eingegeben.

10. Zusammenfassung

• Teilen Sie Zeichenprobleme zuerst in die „Datenschicht (Zeichenkodierung)“ und die „Erscheinungsschicht (Schriften)“. � ist ein Zeichen eines Unfalls auf der Datenschicht, □ eines auf der Erscheinungsschicht.
• JIS X 0213:2004 hat die Beispielglyphen von 168 Zeichen geändert, und Windows hat ab Vista JIS2004-Glyphen als Standard. Dass 葛, 辻 und 飴 je nach Umgebung anders aussehen, ist die Geschichte der Schriften, keine Datenbeschädigung.
• Das Standardmittel, eine Glyphe als Daten festzulegen, ist IVS, aber ohne eine unterstützende Schrift und eine unterstützende App fällt es auf die Standardglyphe zurück. Vergessen Sie nicht die Implementierungsauswirkung, dass ein Zeichen bis zu vier UTF-16-Codeeinheiten umfassen kann.
• Gaiji (EUDC) ist ein Bestand, der diesem PC eigen ist, und kann nicht mit den Daten reisen. Die realistische Antwort ist, zum Migrationszeitpunkt zu inventarisieren, aus einer Zuordnungstabelle zu regulären Zeichen oder IVS zu ersetzen und keine neuen anzulegen.
• Ein System, das Personennamen verarbeitet, legt den akzeptierten Zeichensatz fest und erklärt ihn. Die Regierung standardisiert auf der Grundlage der Koseki-Vereinheitlichungszeichen und der Zeicheninformationsplattform hin zu Standardzeichen für Verwaltungsangelegenheiten, und ein System, das interoperiert, muss dieser Bewegung folgen.
• Für Formulare und PDFs ist „die Schrift mit dem Bildschirm angleichen, die Lizenz prüfen und einbetten“ die Grundlage. Für langfristige Aufbewahrung erwägen Sie PDF/A.
• NFKC-Normalisierung, Zerteilung nach Codeeinheit und CP932-Konvertierung sind die drei Punkte, die Variantenzeichen und Gaiji still zerbrechen. Machen Sie das Speichern des Originals und die Verarbeitung in Graphem-Einheiten zum Prinzip.

Wenn man Ihnen das nächste Mal sagt „das Zeichen ist anders“, formulieren Sie die Frage zuerst so um. Sind die Codepunkte dieselben oder unterschiedlich? Wenn sie dieselben sind, ist es ein Schriftproblem; wenn sie unterschiedlich sind, ist es ein Datenproblem. Dieser eine Schritt hält Sie davon ab, den falschen Einstieg für die Untersuchung zu nehmen.

flowchart TB
    accTitle: Die erste Frage, die den Einstieg der Untersuchung entscheidet
    accDescr: Wenn man Ihnen sagt, das Zeichen sei anders, vergleichen Sie zuerst, ob die Codepunkte dieselben oder unterschiedlich sind; wenn sie dieselben sind, beginnen Sie die Untersuchung als Schriftproblem, wenn unterschiedlich als Datenproblem
    said["Man hat Ihnen gesagt, das Zeichen sei anders"] --> cmp{"Sind die Codepunkte dieselben?"}
    cmp -->|Dieselben| fontp["Ein Schriftproblem"]
    cmp -->|Unterschiedlich| datap["Ein Datenproblem"]

Abbildung 16: Wenn die Codepunkte dieselben sind, beginnen Sie die Untersuchung als Schriftproblem; wenn sie unterschiedlich sind, als Datenproblem.

Weiterführende Artikel

• Einführung in Windows-Zeichenkodierungen - Mojibake im Zusammenspiel mit Linux
• Windows-Zeichenkodierung und Zeilenumbrüche - Die Grundlagen von Mojibake und CRLF/LF
• Drucken und PDF-Ausgabe in Windows-Geschäftsanwendungen — System.Drawing.Printing, WPF und Berichtsbibliotheken richtig einsetzen
• Mehrsprachigkeit für WinForms/WPF-Anwendungen ── resx, Satelliten-Assemblies und Kulturumschaltung in der Praxis
• CSV ist nicht „nur Text“ ── CSV in der Praxis für C#-Business-Anwendungen (Zeichenkodierung, Excel-Kompatibilität, Schutz vor Injection)
• Einführung in die Barrierefreiheit von Windows-Apps — Vorbereitung auf UI Automation und Anforderungen an angemessene Vorkehrungen

Zugehörige Beratungsfelder

KomuraSoft LLC übernimmt Entwurf und Untersuchung rund um Zeichen in Geschäftssystemen. Von der Ursachenisolation von Symptomen wie „das Zeichen unterscheidet sich auf Bildschirm und Formular“ oder „nach der Migration wurde ein Personenname zu □“ über die Inventarisierung von Gaiji und den Aufbau einer Ersatzzeichentabelle bei der Migration aus einem Altsystem, den Entwurf des akzeptierten Zeichensatzes eines Systems, das Personennamen verarbeitet, und die Prüfung der Schrifteinbettungskonfiguration von Formularen und PDFs decken wir sowohl die Code-Schicht als auch die Schrift-Schicht ab.

• Windows-Anwendungsentwicklung
• Migration bestehender Assets
• Technische Beratung und Design-Review
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Warum sieht dasselbe Zeichen 葛 je nach PC oder gedrucktem Formular anders aus?

Es ist eher ein Unterschied der Schriftglyphen als Mojibake. JIS X 0213:2004 (JIS2004) hat die Beispielglyphen von 168 Kanji auf die drucküblichen Formen überarbeitet, und auch Windows hat ab Vista die JIS2004-Glyphen in MS Gothic / MS Mincho und anderen zum Standard gemacht. 葛, 辻, 飴 und ähnliche sind typische Beispiele: Der Unicode-Codepunkt (die Daten) bleibt derselbe, und nur die Glyphe, die die Schrift hält (das Erscheinungsbild), hat sich geändert. Vergleichen Sie die Daten, und sie stimmen überein; eine Formabweichung zwischen einem Formularbild aus der XP-Zeit und dem Bildschirm eines neuen PCs ist das spezifizierte Verhalten. Wenn Sie auch die Glyphen angleichen wollen, verwenden Sie dieselbe Schrift auf dem Bildschirm und auf dem Formular, oder spezifizieren Sie die Glyphe mit einem ideografischen Variationsselektor.

Wenn wir ideografische Variationsselektoren (IVS) nutzen, löst das jedes Glyphenproblem bei Personennamen?

Nein. IVS ist ein Mechanismus, der unmittelbar nach einem Basiszeichen einen Selektor ab U+E0100 setzt, um eine Glyphe als Daten festzulegen, und die angegebene Glyphe wird nur angezeigt, wenn eine unterstützende Schrift wie IPAmj Mincho und eine unterstützende App beide vorhanden sind. In einer nicht unterstützenden Umgebung lautet das spezifizierte Verhalten, dass der Selektor ignoriert und die Standardglyphe des Basiszeichens angezeigt wird; in manchen Umgebungen kann der Selektor auch als □ erscheinen. Außerdem kann ein IVS-tragendes Zeichen in UTF-16 bis zu vier Codeeinheiten umfassen, was Zeichenzählung, Zerteilung und die Auslegung von Datenbankspaltenlängen betrifft. Wenn Sie es einführen, prüfen Sie den Unterstützungsbereich über Anzeige, Druck und nachgelagerte Systeme, bevor Sie es nutzen.

Kann ein als Gaiji (EUDC) registriertes Zeichen auf einem anderen PC oder in einem PDF angezeigt werden?

Grundsätzlich nicht. Gaiji ist ein Mechanismus, bei dem ein Benutzer eine Glyphe in der Datei eudc.tte dieses PCs an einem Codepunkt der Unicode Private Use Area (ab U+E000) registriert; derselbe Codepunkt ist auf einem anderen PC undefiniert oder eine andere Glyphe. Das Schicksal, ihn an Mail, ein PDF oder ein anderes System weiterzugeben, ist daher, dass er zu □ wird oder wie ein anderes Zeichen aussieht. Wenn Sie bereits Daten geerbt haben, die Gaiji enthalten, ist der realistische Weg zum Migrationszeitpunkt, die Nutzungen der Private Use Area zu inventarisieren, eine Zuordnungstabelle zu regulären Unicode-Zeichen oder ideografischen Variationsselektoren aufzubauen und zu ersetzen. In einem neuen System sollten Sie keine neuen Gaiji anlegen.

Wie weit sollte ein Geschäftssystem Zeichen in Personennamen akzeptieren?

Das Erste ist, „den akzeptierten Zeichensatz festzulegen und ihn als Spezifikation zu erklären“. Personenstandsregister haben etwa 56.000 Koseki-Vereinheitlichungszeichen, und Systeme, die dem Regierungsstandard entsprechen, bewegen sich hin zur Nutzung der Standardzeichen für Verwaltungsangelegenheiten, einer Erweiterung der Zeicheninformationsplattform — aber ein allgemeines Geschäftssystem ist nicht verpflichtet, dasselbe Niveau unbegrenzt zu akzeptieren. Ein realistischer Entwurf ist, einen Bereich wie „bis zum Umfang von JIS X 0213“ oder „ideografische Variationsselektoren und die Private Use Area nicht akzeptieren“ festzulegen, bei der Eingabe zu validieren und Fälle außerhalb des Bereichs mit einer Warnung oder einer Alternativdarstellung zu betreiben. Nur Systeme, die mit Regierungssystemen oder Kommunen zusammenarbeiten, müssen der Bewegung der Standardzeichen für Verwaltungsangelegenheiten und den Interoperabilitätsanforderungen auf Basis von JIS X 0221 folgen.

Wie sorgen wir dafür, dass ein Formular oder PDF dieselben Zeichen wie der Bildschirm zeigt?

Die Grundlage ist, dieselbe Schrift auf dem Bildschirm und auf dem Formular anzugeben und die Schrift in das PDF einzubetten. Wenn die Schriften unterschiedlich sind, können dieselben Daten die Glyphe wechseln; wenn der betrachtende PC die Schrift nicht hat, wird eine Ersatzschrift zum Zeichnen verwendet und das Erscheinungsbild bricht. Ob Einbettung erlaubt ist, bestimmt die Lizenz der Schrift (OpenType fsType), daher prüfen Sie das, statt es der Berichtsbibliothek zu überlassen. Teilmengeneinbettung, die nur die verwendeten Zeichen einbettet, hält auch die Dateigröße klein. Wenn langfristige Aufbewahrung eine Anforderung ist, erwägen Sie PDF/A, das Schrifteinbettung verlangt.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.