Fallstricke bei japanischen Schriften und Zeichen — JIS2004, ideografische Variationsselektoren und Gaiji in Geschäftsanwendungen

„Der Name ist derselbe, aber die Form des Zeichens unterscheidet sich zwischen Bildschirm und gedrucktem Formular.“ „Nach dem Austausch des PCs wurde ein Zeichen, das früher angezeigt wurde, zu □.“ Geschäftssysteme, die Japanisch verarbeiten, ziehen solche Anfragen an.

Als Erstes ist zu prüfen, ob sich die Zeichendaten geändert haben oder ob sich nur das Erscheinungsbild derselben Daten geändert hat. Wenn Sie es ohne diese Trennung als „Mojibake“ beheben wollen, betreten Sie die Untersuchung durch die falsche Tür.

Dieser Artikel geht von zwei Anfragen aus: einem 葛 in einer Kundenliste, das auf dem Bildschirm und auf dem gedruckten Formular anders aussieht, und einem Namen auf einem bei einer Behörde eingereichten Dokument, der nach einem PC-Austausch nicht mehr angezeigt werden konnte.

Keine dieser beiden Anfragen ist das Mojibake, das eine Kodierungsabweichung verursacht. Im ersten Fall hat sich kein Bit der Daten geändert und nur das Erscheinungsbild hat sich geändert; im zweiten ist ein „Gaiji“ (ein vom Endbenutzer definiertes Zeichen) verloren gegangen, das nur auf diesem PC existierte.

flowchart TB
    accTitle: Was die zwei häufigen Anfragen wirklich sind
    accDescr: Die Anfrage, dass 葛 auf dem Bildschirm und auf dem gedruckten Formular anders aussieht, ist ein Fall, in dem nur das Erscheinungsbild sich 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["Daten unverändert; nur das Erscheinungsbild hat sich geändert"]
    c2["Anfrage 2: Nach dem Austausch des PCs wurde es 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.

Trennen Sie den Zeichencode (die Datenschicht) von der Schrift (der Erscheinungsschicht), und die meisten japanischen Zeichenprobleme werden handhabbar. Dieser Artikel richtet sich an Entwickler von Geschäftssystemen und IT-Personal und geht der Reihe nach von der Isolation des Symptoms über die Funktionsweise von JIS2004, IVS und Gaiji bis zum akzeptierten Zeichenbereich und zum Entwurf von Formularen und PDFs.

Das Verwürfeln, das bei der Konvertierung zwischen Shift_JIS und UTF-8 entsteht, behandeln bestehende Artikel; dieser Artikel konzentriert sich auf das Problem, dass die Codes den Roundtrip korrekt machen, das Erscheinungsbild oder die Anzeigbarkeit aber abweichen.

1. Zuerst die Kernaussage

„Welche Bytefolge gespeichert wird“ ist eine Frage des Datendesigns; „wie es aussieht“ ist eine Frage des Schriftdesigns. Wenn Sie die Reaktion festlegen, trennen Sie die folgenden drei Dinge.

Zuerst prüfen, ob die Daten dieselben sind

„Mojibake“ ist ein Problem der Datenschicht: Eine Bytefolge wird falsch interpretiert. Dagegen kann derselbe Unicode-Codepunkt in einer anderen Schrift eine andere Glyphe haben. JIS2004 hat die Beispielglyphen von 168 Zeichen geändert, darunter 葛, 辻 und 飴, und ab Vista sind die JIS2004-Glyphen in MS Gothic und MS Mincho von Windows der Standard.¹²

Die Festlegung einer Glyphe nicht mit dem Mitführen von Gaiji verwechseln

IVS ist das Standardmittel, eine Glyphe als Daten festzulegen. Es braucht jedoch eine unterstützende Schrift und eine unterstützende App; in einer Umgebung ohne beides ist das korrekte Verhalten, den Selektor zu ignorieren und die Standardglyphe des Basiszeichens anzuzeigen. Weil das, was wie ein Zeichen aussieht, bis zu vier UTF-16-Codeeinheiten umfassen kann, betrifft es nicht nur die Anzeige, sondern auch Zeichenzahlen und Zerteilung.³⁴

Gaiji (EUDC, vom Endbenutzer definierte Zeichen) sind eine andere Sache: Eine Nummer der Private Use Area hat keine weltweit gemeinsame Bedeutung. Die Glyphe in eudc.tte reist nicht mit den Daten zum Gegenüber, daher braucht eine Migration eine Bestandsaufnahme und eine Zuordnung zu Ersatzzeichen.⁵⁶

Die akzeptierten Zeichen und die Ausgabeumgebung in die Spezifikation schreiben

Ein System, das Personennamen verarbeitet, legt den akzeptierten Zeichensatz fest und hält ihn ausdrücklich fest. Wo das System Daten mit der Verwaltung austauscht, beobachten Sie außerdem die Standardzeichen für Verwaltungsangelegenheiten, die auf den Koseki-Vereinheitlichungszeichen und der Zeicheninformationsplattform aufbauen.⁷⁸⁹ Für Formulare und PDFs ist die Grundlage, dieselbe Schrift wie auf dem Bildschirm zu verwenden, die Lizenz zu prüfen und die Schrift einzubetten. Für langfristige Aufbewahrung erwägen Sie PDF/A.¹⁰¹¹

Außerdem: Wenden Sie NFKC-Normalisierung nicht leichthin auf das Original eines Personennamens an. Das Ersetzen von Voll- und Halbbreiteformen und von Kompatibilitätszeichen verliert Unterscheidungen, die erhalten bleiben sollen.¹²

Den Leseeinstieg nach Symptom oder Ziel wählen

Um das Gesamtbild zu verstehen, lesen Sie ab Kapitel 2 der Reihe nach; um das Symptom vor Ihnen zu untersuchen, beginnen Sie beim einschlägigen Abschnitt der Tabelle. Wenn Sie eine Gegenmaßnahme umsetzen, prüfen Sie am Ende in Kapitel 9 auch die Wirkung auf die anderen Schichten.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (14 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Daten und Erscheinungsbild getrennt denken — Codepunkte und Glyphen

Die Nummer und die gezeichnete Form sind verschiedene Dinge

In Unicode wird ein Zeichen durch eine Nummer dargestellt, den Codepunkt. 葛 ist U+845B, und diese Nummer ist auf jedem PC dieselbe.

Wie diese Nummer auf einem Bildschirm oder auf Papier gezeichnet wird, entscheidet dagegen die Glyphe, die die Schrift hält. Es ist normal, dass derselbe U+845B in den Details der Form zwischen Schrift A und Schrift B abweicht.

Die zu untersuchende Schicht nach dem Symptom trennen

Mit diesen zwei Schichten als Voraussetzung lassen sich die Symptome vor Ort wie folgt aufteilen.

Als Hinweis für die Trennung hilft es, den Unterschied zwischen „�“ und „□“ im Kopf zu behalten.

„�“ ist die Spur einer fehlgeschlagenen Konvertierung. Sobald es durch U+FFFD (REPLACEMENT CHARACTER) ersetzt wurde, ist das ursprüngliche Zeichen bereits verloren. Untersuchen Sie die Datenschicht.

„□“ ist in den meisten Fällen die Anzeige „Glyphe nicht gefunden“. Wenn die Daten noch da sind und der Schrift lediglich eine Glyphe fehlt, kann ein Schriftwechsel die Anzeige möglich machen. Untersuchen Sie die Erscheinungsschicht.

flowchart TB
    accTitle: Das Symptom nach � gegenüber □ aufteilen
    accDescr: Wenn ein Zeichen nicht korrekt angezeigt wird, ist � die Spur eines Konvertierungsfehlers auf der Datenschicht, bei dem das ursprüngliche Zeichen verloren ist, während □ nur bedeutet, dass die Daten noch da sind, der Schrift aber die Glyphe fehlt, und ein Schriftwechsel die Anzeige möglich machen kann
    symptom["Ein Zeichen wird nicht korrekt angezeigt"] --> which{"Was sehen Sie?"}
    which -->|� ist sichtbar| datalayer["Unfall der Datenschicht"]
    datalayer -.-> lost["Spur einer fehlgeschlagenen Konvertierung (das Originalzeichen ist verloren)"]
    which -->|□ ist sichtbar| viewlayer["Unfall der Erscheinungsschicht"]
    viewlayer -.-> noglyph["Der Schrift fehlt lediglich eine Glyphe"]
    noglyph --> fixable["Ein Schriftwechsel kann die Anzeige möglich machen"]

Abbildung 2: � signalisiert einen Unfall der Datenschicht und □ einen der Erscheinungsschicht; der Einstieg der Untersuchung ändert sich entsprechend.

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

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

Die eigentliche Ursache hinter dem einleitenden „葛 sieht auf Bildschirm und Formular anders aus“ liegt in den meisten Fällen hier.

Was sich geändert hat: die Standardglyphen der Schrift

Im Anschluss an die Hyogai Kanji Jitaihyo (die Tabelle der Zeichenformen für Kanji außerhalb der Jōyō-Liste), die der Rat für die Landessprache im Jahr 2000 vorgelegt hat, hat die Revision 2004 JIS X 0213:2004 (üblicherweise JIS2004 genannt) die Beispielglyphen von 168 Kanji auf die Druckstandardformen überarbeitet, die den sogenannten Kangxi-Wörterbuchformen nahestehen. 葛, 辻, 飴, 芦, 溢 und 餅 sind typische Beispiele.¹

Windows ist gefolgt und hat ab Windows Vista die JIS2004-Glyphen in MS Gothic und MS Mincho (und der neu eingeführten Meiryo) zum Standard gemacht. Auch die heutige MS Gothic hat JIS2004-basierte Standardglyphen; die Glyphen der JIS90-Zeit sind über das OpenType-Merkmal jp90 erreichbar.²¹

flowchart TB
    accTitle: Wie die Glyphen der heutigen MS Gothic organisiert sind
    accDescr: MS Gothic ab Vista hat die JIS2004-Glyphen als Standard, und die Glyphen der JIS90-Zeit sind über das OpenType-Merkmal jp90 erreichbar
    msg["MS Gothic (ab Vista)"] --> def["Standardglyphen: JIS2004-basiert"]
    msg --> feat["Über das Merkmal jp90"]
    feat --> old["Glyphen der JIS90-Zeit"]

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

Was sich nicht geändert hat: der Codepunkt des Zeichens

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

• Der Codepunkt von 葛 ist auf XP und auf Windows 11 U+845B
• XP (JIS90-Glyphen) zeigt die Form, in der das Innere des 勹 zu ヒ vereinfacht ist; ab Vista (JIS2004-Glyphen) die Form, die innen auch 人 schreibt
• Deshalb weichen ein Scan eines vom Altsystem gedruckten Formulars und der Bildschirm des neuen PCs in der Form des Zeichens ab. Ein Datenvergleich stimmt vollständig überein

Ob der Shinnyō-Radikal von 辻 einen Punkt oder zwei hat und die Form des Speiseradikals in 飴 sind dieselbe Art von Sache. Ohne diese Geschichte neigt eine Untersuchung dazu, in die falsche Richtung zu gehen: „Die Migration hat die Daten beschädigt“.

Die Untersuchungsreihenfolge lautet: die Codepunkte vor und nach der Migration vergleichen → stimmen sie überein, einen Glyphenunterschied zwischen Schriften vermuten. Schließen Sie nicht allein deshalb auf beschädigte Daten, weil es anders aussieht.

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 unterscheidet sich zwischen einer Schrift mit JIS90-Glyphen und einer Schrift mit JIS2004-Glyphen, und ein Datenvergleich stimmt vollständig überein
    cp["Codepunkt U+845B für 葛"] --> f90["Schrift mit JIS90-Glyphen (XP)"]
    cp --> f04["Schrift mit JIS2004-Glyphen (ab Vista)"]
    f90 --> g90["Form mit dem Inneren von 勹 zu ヒ vereinfacht"]
    f04 --> g04["Druckstandardform, die innen 人 schreibt"]
    g90 -.-> same["Datenvergleich stimmt vollständig überein"]
    g04 -.-> same

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

Weil sich das Zeichen selbst nicht geändert hat, sind beide Glyphen „dasselbe Zeichen“. Bei Personennamen bestehen die Person oder die Behörde jedoch manchmal auf einer bestimmten Form; diese Anforderung, das „als Daten“ zu unterscheiden, beantwortet das nächste Thema, IVS.

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

Dieses Kapitel betrachtet getrennt den Mechanismus, der eine Glyphe festlegt, die Bedingungen, unter denen sie angezeigt werden kann, und die Auswirkungen auf die Implementierung.

Eine 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 bis U+E01EF (VS17 bis VS256).³

Die Glyphenzuordnung entscheidet die IVD-Registrierung

Welche Folge „Basiszeichen + Selektor“ welche Glyphe meint, entscheidet ein Register namens IVD (Ideographic Variation Database), das das Unicode Consortium führt.

Die wichtigsten Sammlungen sind die folgenden.¹³

Microsofts Dokumentation gibt zum Beispiel U+845B allein (葛) als die Form im Namen des Bahnhofs Nishi-Kasai und U+845B gefolgt von U+E0100 (VS17) als die Form im Namen der Stadt Katsuragi in der Präfektur Nara. Dasselbe 葛, und doch können die Daten sagen, welche Glyphe gemeint ist.³

flowchart TB
    accTitle: Ein Beispiel, dasselbe 葛 mit IVS als Daten zu unterscheiden
    accDescr: 葛 als U+845B allein wird im Namen des Bahnhofs Nishi-Kasai verwendet, die Folge U+845B gefolgt von VS17 im Namen der Stadt Katsuragi, und welche Folge welche Glyphe meint, entscheidet das IVD-Register
    seq1["U+845B allein"] --> gl1["Glyphe im Namen des Bahnhofs Nishi-Kasai"]
    seq2["U+845B + VS17"] --> gl2["Glyphe im Namen der Stadt Katsuragi"]
    ivd["IVD (Register)"] -.-> gl1
    ivd -.-> gl2

Abbildung 5: Selbst beim selben 葛 lässt das Vorhandensein oder Fehlen eines Selektors die Daten sagen, welche Glyphe gemeint ist.

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

Auf der Schriftseite wird die Zuordnung zwischen einer IVS und einer Glyphe in der OpenType-cmap-Tabelle (Format 14) implementiert.⁴ Wenn eine unterstützende Schrift (etwa IPAmj Mincho) und eine unterstützende App beide vorhanden sind, erscheint die angegebene Glyphe.

Wenn sie nicht vorhanden sind, ist die angegebene Glyphe nicht garantiert haltbar. Trennen Sie die folgenden zwei Fälle.

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

Mit anderen Worten: IVS ist so entworfen, dass „selbst bei Degradation das Basiszeichen lesbar bleibt“, aber ob „es immer in der angegebenen Glyphe angezeigt wird“, hängt von der empfangenden Umgebung ab.

Verwaltungsseitige Einwohner- und Personenstandsregister nutzen die Kombination aus einer Schrift der Zeicheninformationsplattform plus IVS; akzeptiert ein allgemeines Geschäftssystem das leichthin, fällt die Glyphe irgendwo auf dem Weg über Anzeige, Druck oder ein nachgelagertes 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 in der angegebenen Glyphe angezeigt; wenn nicht, wird der Selektor ignoriert und die Standardglyphe des Basiszeichens gezeigt; in älteren Apps und manchen Zeichnungsstapeln wird der Selektor als unbekanntes Zeichen behandelt und ein zusätzliches □ angezeigt
    ivs["Basiszeichen + ideografischer Variationsselektor"] --> env{"Unterstützende Schrift und App beide vorhanden?"}
    env -->|Ja| ok["In der angegebenen Glyphe angezeigt"]
    env -->|Nein| ignore["Selektor ignoriert; Standardglyphe angezeigt"]
    env -->|Ältere Apps oder manche Zeichnungsstapel| tofu["Ein zusätzliches □ wird angezeigt"]
    ignore -.-> spec["Das ist das korrekte Verhalten laut Spezifikation"]

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

4.2. Hinweise zur Implementierung — „Ein Zeichen“ kann bis zu vier Codeeinheiten umfassen

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

Zeichenzahlen und Teilzeichenketten: Das scheinbare Zeichen nicht zerteilen

In C# hat "葛󠄀" (葛 + VS17) string.Length == 3. Substring und festlängenbasierte Zerteilung riskieren, das Basiszeichen von seinem Selektor zu trennen.

Prüfen Sie Zeichenzahlen und extrahieren Sie Teilzeichenketten in Graphemeinheiten, mit APIs wie StringInfo, nicht in Codeeinheiten.

Speicherung: Die Einheit der Spaltenlänge prüfen

SQL Servers nvarchar(n) wird in UTF-16-Codeeinheiten gemessen. Wenn Sie IVS akzeptieren, planen Sie Datenbankspaltenlängen mit dem Zwei- bis Vierfachen der scheinbaren Zeichenzahl.

Suche und Vergleich: Entscheiden, ob Selektoren unterschieden werden

Das Vorhandensein oder Fehlen eines Selektors macht eine andere Zeichenkette. Ob eine Suche nach „葛“ auch „葛 + VS17“ treffen soll, müssen Sie als Anforderung festlegen und umsetzen.

flowchart TB
    accTitle: Ein IVS-tragendes Zeichen und UTF-16-Codeeinheiten
    accDescr: Die Folge aus Basiszeichen und ideografischem Variationsselektor, die ein Benutzer als ein Zeichen wahrnimmt, hat einen Selektor, der immer ein Surrogatpaar ist, plus zwei weitere Codeeinheiten, wenn das Basiszeichen ein Kanji der Ergänzungsebene ist, also bis zu vier Codeeinheiten in UTF-16
    one["Ein Zeichen, wie der Benutzer es wahrnimmt"] --> base["Basiszeichen"]
    one --> vs["Ideografischer Variationsselektor"]
    base -.-> bnote["Zwei Codeeinheiten, wenn es ein Kanji der Ergänzungsebene ist"]
    vs -.-> vnote["Immer ein Surrogatpaar (zwei Codeeinheiten)"]
    base --> total["Bis zu vier Codeeinheiten in UTF-16"]
    vs --> total
    total -.-> risk["Festlängenbasierte Zerteilung riskiert, sie zu trennen"]

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

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

Gaiji sind ein Mechanismus, mit dem ein Benutzer einer eigenen Glyphe einen Codepunkt der Unicode Private Use Area (PUA: U+E000 bis U+F8FF und andere Bereiche) zuweist. Ein Codepunkt der Private Use Area hat keine weltweit gemeinsame Bedeutung; demselben U+E000 kann auf jedem PC und in jeder Organisation ein anderes Zeichen zugewiesen sein.⁵

Die Glyphe lebt in der Gaiji-Schrift; in den Daten bleibt nur die Nummer

Unter Windows erstellen Sie die Glyphe im Editor für private Zeichen (eudcedit.exe), und sie wird in einer Schriftdatei namens eudc.tte gespeichert.

Diese Datei wird als versteckte Schrift installiert und über den Registrierungsschlüssel HKEY_CURRENT_USER\EUDC jeder Schrift zugeordnet.⁶ In der Shift_JIS-Zeit (CP932) lag der Gaiji-Bereich bei 0xF040 bis 0xF9FC; die Konvertierung nach Unicode ordnet ihn der Private Use Area zu.

Eine Nummer in den Daten bedeutet nicht, dass das Gegenüber dieselbe Glyphe hat. Dieser Mechanismus führt zu den folgenden Problemen.

• eudc.tte gehört zu diesem PC (diesem Benutzer) und reist nicht mit den Daten zum Gegenüber
• In dem Moment, in dem die Daten Mail, ein PDF, das Web oder ein anderes System erreichen, wird das Zeichen zu □ oder sieht auf der anderen Seite wie ein anderes Gaiji aus
• Wenn Sie bei einer OS-Migration oder einem PC-Austausch vergessen, eudc.tte mitzunehmen, entsteht „ein Zeichen, das auf dem alten PC angezeigt wurde, wird nicht mehr angezeigt“

Das ist die eigentliche Ursache hinter der zweiten Anfrage der Einleitung.

flowchart TB
    accTitle: Warum Gaiji nur auf diesem PC angezeigt werden
    accDescr: Eine im Editor für private Zeichen erstellte Glyphe wird in eudc.tte gespeichert und über die Registrierung dieses PCs Schriften zugeordnet, sodass nur der Code der Private Use Area zu Mail, einem PDF oder einem anderen System reist und zu □ wird oder wie ein anderes Zeichen aussieht
    edit["Die Glyphe im Editor für private Zeichen erstellen"] --> tte["In eudc.tte gespeichert"]
    tte --> reg["Über die Registrierung Schriften zugeordnet"]
    reg --> local["Wird auf diesem PC angezeigt"]
    tte -.-> stay["eudc.tte reist nicht mit den Daten"]
    send["Nur der Code der Private Use Area erreicht das Gegenüber"] --> dest["Mail, PDF, andere Systeme"]
    dest --> broken["Wird zu □ oder sieht wie ein anderes Zeichen aus"]

Abbildung 8: Die Glyphe lebt in eudc.tte und in den Daten bleibt nur eine Nummer der Private Use Area, daher sehen Gaiji kaputt aus, sobald sie den PC verlassen.

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

Das Problem entsteht, wenn aus einem Altsystem geerbte Daten bereits Gaiji enthalten. Was wir in Migrationsprojekten empfehlen, ist ein vierstufiges Verfahren: erheben → identifizieren → ersetzen → sperren.

1. Erheben: Die genutzten Nummern und die ursprünglichen Glyphen sammeln

Durchsuchen Sie Datenbanken und Dateien mit einem regulären Ausdruck für die Private Use Area (U+E000 bis U+F8FF) und inventarisieren Sie die genutzten Gaiji-Codes und ihre Häufigkeiten. Holen Sie eudc.tte von den PCs jedes Standorts und prüfen Sie die Glyphen.

2. Identifizieren: Eine Zuordnungstabelle zu Ersatzzeichen aufbauen

Prüfen Sie für jedes Gaiji, ob es durch ein reguläres Unicode-Zeichen darstellbar ist, ob es mit IVS darstellbar ist und ob die Zeicheninformationsplattform (MJ) ein entsprechendes Zeichen hat, und bauen Sie eine Zuordnungstabelle zu Ersatzzeichen. In der Praxis stellt sich die Mehrheit der Fälle als nichts weiter heraus als eine alte Zeichenform, die als JIS-Gaiji angelegt worden war.

3. Ersetzen: Die Daten gemäß der Tabelle ersetzen

Ersetzen Sie die Daten gemäß der Zuordnungstabelle. Nur wenn überhaupt kein entsprechendes Zeichen existiert, behalten Sie das Zeichen als Bild oder hängen Sie eine Anmerkung an den betreffenden Datensatz.

4. Sperren: Keine neuen Gaiji hinzufügen

Im neuen System weisen Sie Eingaben aus der Private Use Area in der Validierung zurück und legen Sie keine neuen Gaiji an.

flowchart TB
    accTitle: Verfahren zur Migration von Daten, die Gaiji enthalten
    accDescr: Inventarisieren Sie die genutzten Gaiji durch Scannen der Private Use Area und Einsammeln von eudc.tte, bauen Sie eine Zuordnungstabelle zu Ersatzzeichen und ersetzen Sie, und im neuen System weisen Sie Eingaben aus der Private Use Area in der Validierung zurück und legen keine neuen Gaiji an
    st1["Erheben: die Private Use Area scannen"] --> st2["Identifizieren: die Zuordnungstabelle zu Ersatzzeichen aufbauen"]
    st2 --> st3["Ersetzen: gemäß der Tabelle ersetzen"]
    st3 --> st4["Sperren: keine neuen Gaiji anlegen"]
    st1 -.-> tte["eudc.tte von jedem Standort einsammeln"]
    st2 -.-> nomap["Bild oder Anmerkung nur, wo keine Zuordnung existiert"]

Abbildung 9: Migrieren Sie Gaiji in vier Stufen — erheben, identifizieren, ersetzen und sperren — und legen Sie keine neuen Gaiji an.

Die Richtung ist auf Verwaltungsseite dieselbe: Die erklärte Politik ist, die Gaiji, die Kommunen selbst angelegt haben (bundesweit sollen es etwa zwei Millionen Zeichen sein), eindeutig gegen die weiter unten beschriebenen Standardzeichen für Verwaltungsangelegenheiten zu identifizieren und sie nicht mehr zu nutzen.⁹ „Keine Gaiji hinzufügen; sie gegen einen standardisierten Zeichensatz identifizieren“ wird im öffentlichen wie im privaten Sektor zum etablierten Migrationsmuster.

6. Die Zeichensplattform der Verwaltung — Von den Koseki-Vereinheitlichungszeichen zu den Standardzeichen für Verwaltungsangelegenheiten

Beim Entwurf eines Systems, das Personennamen verarbeitet, gibt die Kenntnis der Zeichensplattform der Verwaltung Material für die Entscheidung „wie weit akzeptieren“.

Zuerst die Namen und Rollen der Zeichensplattformen trennen

Den Austausch innerhalb der Verwaltung vom Austausch mit der allgemeinen Außenwelt trennen

Für kommunale Kernfachsysteme (standardkonforme Systeme) ist die Standardspezifikation eine zweistufige Anordnung: die Standardzeichen für Verwaltungsangelegenheiten für den Informationsaustausch von Namen und Ähnlichem nutzen und mit externen Systemen ohne einheitliche Austauschregeln, etwa Smartphones, im Bereich von JIS X 0213:2012 austauschen.⁹

Diese Anordnung — „intern einen weiten Zeichensatz halten und nach außen im Bereich austauschen, den eine allgemeine Umgebung anzeigen kann“ — ist selbst ein nützlicher Bezug für Systeme der Privatwirtschaft.

flowchart TB
    accTitle: Der zweistufige Austausch eines standardkonformen Systems
    accDescr: Ein kommunales standardkonformes System nutzt die Standardzeichen für Verwaltungsangelegenheiten für den Informationsaustausch von Namen und Ähnlichem und tauscht im Bereich von JIS X 0213:2012 mit externen Systemen wie Smartphones aus, die keine einheitlichen Austauschregeln haben
    sys["Kommunales standardkonformes System"] --> renkei["Informationsaustausch von Namen und Ähnlichem"]
    sys --> gaibu["Austausch mit externen Systemen"]
    renkei --> mjp["Standardzeichen für Verwaltungsangelegenheiten"]
    gaibu --> jis["Bereich von JIS X 0213:2012"]
    gaibu -.-> sumaho["Gegenstellen ohne Regeln, etwa Smartphones"]
    mjp -.-> naibu["Intern wird ein weiter Zeichensatz gehalten"]

Abbildung 10: Eine zweistufige Anordnung: Der Verwaltungsaustausch nutzt die Standardzeichen für Verwaltungsangelegenheiten, der externe Austausch ohne Regeln JIS X 0213:2012.

Den Bereich festlegen, den das eigene System akzeptiert

Als praktische Orientierung für ein allgemeines Geschäftssystem empfehlen wir Folgendes.

• Legen Sie den akzeptierten Zeichensatz fest und halten Sie ihn sowohl in der Spezifikation als auch in der Eingabeprüfung fest. Zum Beispiel „der Bereich von JIS X 0213:2012“, „keine Private Use Area und keine kombinierenden Zeichen“ oder „IVS nicht akzeptiert (oder akzeptiert, mit Anzeigegarantie nur in einer IPAmj-Mincho-Umgebung)“
• Akzeptieren Sie nicht unbegrenzt. Ein Entwurf „es ist Unicode, also geht alles“ bricht irgendwo auf dem Weg über Anzeige, Druck oder Anbindung
• Legen Sie im Voraus fest, wie Zeichen außerhalb des Bereichs behandelt werden. Die Regel für die Ersetzung durch eine Alternativdarstellung (eine neuere Form oder Katakana) und der Wortlaut, mit dem Sie das der Person erklären, gehören zur Systemspezifikation
• Wo eine nachgelagerte Partei wie eine Behörde oder ein Finanzinstitut Zeichensatzregeln hat, behandeln Sie diese als maßgeblich und richten Sie sich danach

flowchart TB
    accTitle: Entwurf und Betrieb des akzeptierten Zeichensatzes
    accDescr: Legen Sie den akzeptierten Zeichensatz fest und halten Sie ihn sowohl in der Spezifikation als auch in der Eingabeprüfung fest, akzeptieren Sie Zeichen im Bereich, und für Zeichen außerhalb des Bereichs legen Sie den Betrieb im Voraus fest, einschließlich der Regel für die Ersetzung durch eine Alternativdarstellung und des Wortlauts, mit dem Sie das der Person erklären
    decide["Den akzeptierten Zeichensatz festlegen"] --> spec["In der Spezifikation festhalten"]
    decide --> valid["In der Eingabeprüfung festhalten"]
    valid --> range{"Im Bereich?"}
    range -->|Ja| ok["Akzeptieren"]
    range -->|Nein| alt["Durch eine Alternativdarstellung ersetzen"]
    alt -.-> word["Der der Person erklärte Wortlaut gehört ebenfalls zur Spezifikation"]

Abbildung 11: Halten Sie den akzeptierten Zeichensatz sowohl in der Spezifikation als auch in der Eingabeprüfung fest und legen Sie auch den Umgang mit Zeichen außerhalb des Bereichs fest.

7. Schriften auswählen und einbetten — Bildschirm und gedrucktes Formular angleichen

Hier ist die Denkreihenfolge: prüfen, dass die Schrift in den genutzten Umgebungen existiert → dieselbe Schrift auf Bildschirm und Formular verwenden → die Lizenz prüfen und sie in das PDF einbetten.

7.1. Der Charakter der gängigen Schriften

Die genutzten Umgebungen prüfen, nicht nur den Schriftnamen

Was bei der Auswahl zählt, ist nicht die Vorliebe für eine Type, sondern ob die Schrift in jeder Umgebung existiert, die an Anzeige, Druck und PDF-Erzeugung beteiligt ist.

Die japanischen Ergänzungsschriften unter Windows 10/11 (BIZ UD und andere) können je nach Konfiguration fehlen, und in einer Konfiguration, die PDFs serverseitig erzeugt, hat das Vorhandensein der Schrift auf dem Server unmittelbare Wirkung.

flowchart TB
    accTitle: Die bei der Schriftwahl zu prüfenden Umgebungen
    accDescr: Bei der Schriftwahl zählt nicht die Vorliebe für eine Type, sondern ob die Schrift in jeder Umgebung existiert, die an Anzeige, Druck und PDF-Erzeugung beteiligt ist, und die Konfiguration der Ergänzungsschriften sowie das Vorhandensein der Schrift auf dem Server haben unmittelbare Wirkung
    cand["Kandidatenschrift"] --> exist["In jeder Umgebung vorhanden?"]
    exist --> scr["Anzeigeumgebung"]
    exist --> prn["Druckumgebung"]
    exist --> srv["PDF-Erzeugungsserver"]
    scr -.-> hojo["Ergänzungsschriften können je nach Konfiguration fehlen"]
    srv -.-> eikyo["Das Vorhandensein der Schrift auf dem Server hat unmittelbare Wirkung"]

Abbildung 12: Wählen Sie eine Schrift nicht nach Type-Vorliebe, sondern danach, ob sie in jeder Umgebung für Anzeige, Druck und PDF-Erzeugung vorhanden ist.

7.2. Die Grundlagen des Formularentwurfs — angleichen, dann einbetten

Dieselbe Schrift auf Bildschirm und Formular verwenden

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 aus der Einleitung. Eine Konfiguration wie „Meiryo auf dem Bildschirm, MS Mincho auf dem Formular“ sollte zumindest auf Glyphenunterschiede bei den 168 JIS2004-Zeichen geprüft werden.

In das PDF einbetten, nach Prüfung der Lizenz

Betten Sie die Schrift in das PDF ein. Wenn Sie das nicht tun, zeichnet die betrachtende Seite mit der Schrift, die sie zur Hand hat, und nicht nur die Glyphen, sondern auch das Layout können sich ändern.

Ob Einbettung erlaubt ist, entscheidet die Lizenz. Eine OpenType-Schrift erklärt ihre Einbettungsrechte im Feld fsType (Installable, Restricted, Preview & Print, Editable, kein Subsetting und so weiter), und Sie dürfen eine Schrift, deren Einbettung nicht erlaubt ist, nicht einbetten.¹⁰ Bei kommerziellen Schriften ist die Prüfung des Vertrags Pflicht.

Machen Sie Teilmengeneinbettung zum Standard. Wenn Sie nur die Glyphen der verwendeten Zeichen einbetten, müssen Sie nicht eine ganze japanische Schrift (mehrere MB bis einige zehn MB) mitschleppen.

Für langfristige Aufbewahrung PDF/A erwägen

Wenn langfristige Aufbewahrung eine Anforderung ist, nutzen Sie PDF/A. PDF/A (ISO 19005) ist ein Standard, der die zur Anzeige nötigen Ressourcen in der Datei selbstständig macht, und Schrifteinbettung ist Pflicht.¹¹ Es ist auch der zuverlässigste Weg, „wir haben es zehn Jahre später geöffnet und die Glyphen hatten sich geändert“ zu verhindern.

flowchart TB
    accTitle: Der Entscheidungsfluss für die Schrifteinbettung
    accDescr: Bevor Sie eine Schrift in ein PDF einbetten, prüfen Sie die Einbettungslizenz in fsType, machen Sie Teilmengeneinbettung zum Standard, wenn sie erlaubt ist, und erwägen Sie PDF/A, bei dem Einbettung Pflicht ist, wenn langfristige Aufbewahrung eine Anforderung ist
    emb["Die Schrift in das PDF einbetten"] --> lic{"Einbettung durch fsType erlaubt?"}
    lic -->|Erlaubt| sub["Teilmengeneinbettung ist der Standard"]
    lic -->|Nicht erlaubt| ng["Darf nicht eingebettet werden"]
    sub -.-> gly["Nur die Glyphen der verwendeten Zeichen"]
    sub -->|Anforderung langfristiger Aufbewahrung| pdfa["PDF/A erwägen"]
    pdfa -.-> must["Schrifteinbettung ist Pflicht"]

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

Wie Sie einen Implementierungsweg für Druck und PDF-Ausgabe wählen, behandelt ausführlich „Drucken und PDF-Ausgabe in Windows-Geschäftsanwendungen“.

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

Ein Zeichen, für das die angegebene Schrift keine Glyphe hat, bleibt nicht leer; das Standardverhalten moderner Zeichnungsstapel ist, es stattdessen mit einer anderen Schrift zu zeichnen.

Unter GDI übernimmt das die in der Registrierung (FontLink\SystemLink) definierte „Schriftverknüpfung“; unter DirectWrite, WPF und Browsern der „Schrift-Fallback“.¹⁵

flowchart TB
    accTitle: Der Ablauf von Schriftverknüpfung und Fallback
    accDescr: Wenn die angegebene Schrift die Glyphe hat, wird sie unverändert angezeigt; wenn nicht, wird mit einer verknüpften oder Fallback-Schrift gezeichnet, und wenn nirgendwo eine Glyphe existiert, wird es zu □, aber die Daten sind in der Regel noch intakt
    disp["Ein Zeichen anzeigen"] --> has{"Hat die angegebene Schrift die Glyphe?"}
    has -->|Ja| draw["In der angegebenen Schrift angezeigt"]
    has -->|Nein| fb{"Hat eine verknüpfte oder Fallback-Schrift sie?"}
    fb -->|Ja| alt["Stattdessen mit einer anderen Schrift gezeichnet"]
    alt -.-> mixed["Die Ursache für ein gemischtes Schriftgefühl"]
    fb -->|Nein| tofu["□ (Tofu) wird angezeigt"]
    tofu -.-> alive["Die Daten sind in der Regel noch intakt"]

Abbildung 14: □ ist die Spur eines fehlgeschlagenen Fallbacks; ob das Ersatzzeichnen gelingt, ist die Gabelung zwischen „gemischt“ und „Tofu“.

Das Ergebnis des Ersatzzeichnens am Symptom ablesen

Wer diesen Mechanismus kennt, kann die folgenden vertrauten Fälle erklären.

• Das Schriftgefühl unterscheidet sich zwischen alphanumerischen Zeichen und Japanisch: Eine lateinische Schrift wurde zuerst angegeben, daher wird nur der japanische Anteil in der verknüpften oder Fallback-Japanischschrift gezeichnet
• Nur die Kanji in einem japanischen Satz nehmen chinesisch wirkende Glyphen an: Der Fallback hat sich zu einer chinesischen Schrift aufgelöst. Das geschieht leicht in Webseiten und Apps, die Sprachinformation (ein lang-Attribut oder ein Gebietsschema) nicht korrekt übergeben
• Tofu (□) erscheint: Weder die angegebene Schrift noch die Fallback-Schrift hat die Glyphe. Mit anderen Worten: □ ist die „Spur eines fehlgeschlagenen Fallbacks“, und die Daten sind in der Regel noch intakt

Fallback ist kein Ersatz für Entwurf

Fallback ist ein Sicherheitsnetz; es ist kein Ersatz dafür, von Anfang an die richtige Schrift zu wählen.¹⁵

In einer Geschäftsanwendung ist die gesunde Haltung: „Die wesentlichen Anzeige- und Druckwege sind mit den entworfenen Schriften allein vollständig, und Fallback ist Versicherung gegen unerwartete Zeichen“. Zur Schriftwahl in einer mehrsprachigen Benutzeroberfläche siehe auch „Mehrsprachigkeit für WinForms/WPF-Anwendungen“.

9. Eine Implementierungscheckliste für Geschäftsanwendungen

Zum Schluss fasst die folgende Tabelle die Punkte zusammen, die Sie auf jeder Schicht von der Eingabe bis zur Anbindung prüfen sollten. Hören Sie nicht bei „es wird auf dem Bildschirm angezeigt“ auf; prüfen Sie auch Speicherung, Druck und Anbindung.

Das Speichern des Originals vom Verarbeiten für die Suche trennen

Gerade Normalisierung ist die Falle, die das eigentliche Thema dieses Artikels ist: eine „in guter Absicht“ angewendete Verarbeitung, die die Unterscheidungen zwischen Variantenzeichen und zwischen Voll- und Halbbreite einebnet. Das Original unverändert lassen; eine Kopie verarbeiten ist der Grundsatz.

Kodierungsunfälle bei der CSV-Anbindung behandelt ausführlich „CSV ist nicht „nur Text““.

flowchart TB
    accTitle: Das Original unverändert lassen und eine Kopie verarbeiten
    accDescr: Speichern Sie die eingegebene Zeichenkette als Original genau wie eingegeben, wenden Sie Normalisierung auf eine Kopie begrenzt auf Zwecke wie das Erzeugen von Suchschlüsseln an, und beachten Sie, dass NFKC auf das Original die Unterscheidungen zwischen Variantenzeichen und zwischen Voll- und Halbbreite einebnet
    input["Eingegebene Zeichenkette"] --> orig["Original: gespeichert wie eingegeben"]
    input --> copy["Kopie: für einen begrenzten Zweck normalisiert"]
    copy -.-> use["Erzeugen von Suchschlüsseln und Ähnliches"]
    orig -.-> ng["NFKC auf das Original ebnet die Unterscheidungen ein"]

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

10. Zusammenfassung

Untersuchung: Daten vom Erscheinungsbild trennen

• Teilen Sie Zeichenprobleme zuerst in die „Datenschicht (Zeichenkodierung)“ und die „Erscheinungsschicht (Schriften)“. � signalisiert einen Unfall der Datenschicht, □ einen der Erscheinungsschicht.
• JIS X 0213:2004 hat die Beispielglyphen von 168 Zeichen geändert, und Windows hat ab Vista die JIS2004-Glyphen als Standard. Dass 葛, 辻 und 飴 je nach Umgebung anders aussehen, ist Schriftgeschichte, keine Datenbeschädigung.

Entwurf: Festlegen, wie Glyphen angegeben werden und was akzeptiert wird

• Das Standardmittel, eine Glyphe in den Daten festzulegen, ist IVS, aber ohne unterstützende Schrift und 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) sind Bestände, die diesem PC eigen sind, und können nicht mit den Daten reisen. Die realistische Antwort ist, sie bei der Migration zu inventarisieren, über eine Zuordnungstabelle zu regulären Zeichen oder IVS zu ersetzen und keine neuen anzulegen.
• Ein System, das Personennamen verarbeitet, legt den akzeptierten Zeichensatz fest und hält ihn fest. Die Verwaltung standardisiert auf der Grundlage der Koseki-Vereinheitlichungszeichen und der Zeicheninformationsplattform hin zu den Standardzeichen für Verwaltungsangelegenheiten, und Systeme, die damit Daten austauschen, müssen dieser Bewegung folgen.

Implementierung und Ausgabe: Das Original schützen und die Anzeigewege angleichen

• Für Formulare und PDFs ist die Grundlage „dieselbe Schrift wie auf dem Bildschirm verwenden, die Lizenz prüfen und einbetten“. Erwägen Sie PDF/A für langfristige Aufbewahrung.
• NFKC-Normalisierung, Zerteilung nach Codeeinheit und CP932-Konvertierung sind die drei großen Punkte, die Variantenzeichen und Gaiji still zerbrechen. Machen Sie das Speichern des Originals und die Verarbeitung in Graphemeinheiten zur Regel.

Wenn Ihnen das nächste Mal gesagt wird „das Zeichen ist anders“, beginnen Sie mit dieser Frage: Sind die Codepunkte dieselben oder unterschiedlich? Wenn sie dieselben sind, ist es ein Schriftproblem; wenn sie unterschiedlich sind, ein Datenproblem. Dieser eine Schritt hält Sie davon ab, die Untersuchung durch die falsche Tür zu betreten.

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

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

Verwandte 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

Verwandte Beratungsfelder

KomuraSoft LLC übernimmt Entwurf und Untersuchung der Zeichenverarbeitung in Geschäftssystemen. Wir arbeiten von der Code-Schicht und der Schrift-Schicht: Isolation der Ursache von Symptomen wie „das Zeichen unterscheidet sich auf Bildschirm und Formular“ oder „nach der Migration wurde ein Name zu □“, Inventarisierung von Gaiji und Aufbau von Ersatzzeichentabellen bei der Migration aus Altsystemen, Entwurf des akzeptierten Zeichensatzes für Systeme, die Personennamen verarbeiten, und Prüfung der Schrifteinbettungskonfiguration von Formularen und PDFs.

• Windows-App-Entwicklung
• Nutzung und 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 handelt sich höchstwahrscheinlich um einen Unterschied der Schriftglyphen, nicht um Mojibake. JIS X 0213:2004 (JIS2004) hat die Beispielglyphen von 168 Kanji auf die Druckstandardformen überarbeitet, und auch Windows hat ab Vista die JIS2004-Glyphen in MS Gothic, MS Mincho und anderen zum Standard gemacht. 葛, 辻 und 飴 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; dass ein Formularbild aus der XP-Zeit und der Bildschirm eines neuen PCs in der Form abweichen, ist das spezifizierte Verhalten. Wenn Sie auch die Glyphen angleichen wollen, verwenden Sie dieselbe Schrift auf dem Bildschirm und auf dem Formular, oder legen Sie die Glyphe mit einem ideografischen Variationsselektor fest.

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

Nein. IVS ist ein Mechanismus, der unmittelbar nach dem Basiszeichen einen Selektor ab U+E0100 setzt, um die Glyphe als Daten festzulegen; 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 ist das korrekte 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 jedes nachgelagerte System, 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 der 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. Deshalb ist es das Schicksal von Gaiji, zu □ zu werden oder wie ein anderes Zeichen auszusehen, sobald sie Mail, ein PDF oder ein anderes System erreichen. Wenn Sie bereits Daten halten, die Gaiji enthalten, ist der realistische Weg bei der Migration, jede Nutzung der Private Use Area zu finden, 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 die Zeichen von Personennamen akzeptieren?

Der erste Schritt ist, den akzeptierten Zeichensatz festzulegen und ihn ausdrücklich als Spezifikation festzuhalten. Personenstandsregister halten etwa 56.000 Koseki-Vereinheitlichungszeichen, und die standardkonformen Systeme der Verwaltung bewegen sich hin zu den Standardzeichen für Verwaltungsangelegenheiten, einer Erweiterung der Zeicheninformationsplattform — aber ein allgemeines Geschäftssystem ist nicht verpflichtet, dasselbe Niveau unbegrenzt zu akzeptieren. Ein realistischer Entwurf legt einen Bereich wie „bis zum Umfang von JIS X 0213“ oder „keine ideografischen Variationsselektoren und keine Private Use Area“ fest, prüft bei der Eingabe und behandelt Zeichen außerhalb des Bereichs mit einer Warnung oder einer Alternativdarstellung. Nur Systeme, die mit Verwaltungssystemen oder Kommunen Daten austauschen, müssen der Entwicklung der Standardzeichen für Verwaltungsangelegenheiten und den Austauschvorgaben auf Basis von JIS X 0221 folgen.

Wie sorgen wir dafür, dass ein gedrucktes 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 unterschiedliche Glyphen erzeugen, und wenn dem betrachtenden PC die Schrift fehlt, wird eine Ersatzschrift zum Zeichnen verwendet und das Erscheinungsbild bricht. Ob Einbettung erlaubt ist, entscheidet die Lizenz der Schrift (OpenType fsType); prüfen Sie das selbst, 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, bei dem Schrifteinbettung Pflicht ist.

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.