ZURÜCK

Zuerst erschienen in der public Ausgabe 03-2021

von Tim Braatz

 

Verpflichtend für den behördlichen Datenaustausch

EU-Bürgerinnen und -Bürger haben bei der Kommunikation mit Behörden das Recht auf die korrekte Schreibung ihres Namens in ihrer Landessprache. Dieses im Gesetz zu dem Übereinkommen vom 13. September 1973 über die Angabe von Familiennamen und Vornamen in den Personenstandsbüchern¹ festgelegte Recht motiviert die neue Norm DIN SPEC 91379². Die Norm – auch bekannt als String.Latin 1.2 – wurde 2019 vom IT-Planungsrat festgesetzt und gilt spätestens ab November 2024 verbindlich für alle IT-Verfahren, die „dem Bund-Länder-übergreifenden Datenaustausch oder dem Datenaustausch mit Bürgern und Wirtschaft dienen“. Sie legt fest, welche Zeichenmenge solche Verfahren unterstützen müssen, um alle Namen von Bürgerinnen, Bürgern und Handelsunternehmen in der EU korrekt erfassen und darstellen zu können und ersetzt damit den alten Standard String Latin 1.1, wobei die Anzahl der Zeichen von 490 auf 924 erweitert und zusätzlich einige technische Kategorisierungen eingeführt werden.

 

Zeichensatz, Schriftart, Kodierung – Gerne verwechselt

Um die Bedeutung des neuen Standards besser kennenzulernen, ist es sinnvoll, sich zunächst die Funktionsweise von Schrift auf Computersystemen genauer anzusehen und Begrifflichkeiten zu unterscheiden, denn gerade im deutschsprachigen Raum werden viele dieser Begriffe gerne verwechselt oder fälschlicherweise synonym gebraucht. Bei einem Zeichensatz handelt es sich zunächst einmal nur um eine Menge von Zeichen. Der Unicode als De-facto-Standard des Internets hat den Anspruch, sämtliche bekannten Zeichen zu enthalten – das sind in der aktuellen Version 13.0 von März 2020 genau 143.859. Darunter sind nicht nur Buchstaben und Zahlen, sondern zum Beispiel auch Steuerungszeichen, diakritische Zeichen (wie Apostrophe) oder sogar Emojis. Zusätzlich ordnet der Unicode jedem dieser Zeichen eine Zahl – genannt Code Point – zu. Damit handelt es sich genau genommen bereits nicht mehr nur um einen Zeichensatz, sondern auch um eine Kodierung. Das ist in diesem Kontext allerdings eher ungebräuchlich und führt daher zu Verwechslungen. Zwei Beispiele für Unicode-Zuordnungen für die Nummern 41 und 128.578 wären also

LATIN CAPITAL A – U+0041
SLIGHTLY SMILING FACE EMOJI – U+1F642

Zudem kann ein Zeichen durchaus aus mehreren Code Points bestehen, meist, wenn es sich um Buchstaben mit beispielsweise Apostrophen handelt:

LATIN SMALL LETTER S WITH COMBINING HORN AND
COMBINING MACRON – U+0073,U+031B,U+0304

Von der abstrakten Ebene des Zeichensatzes gibt es zwei Richtungen, in die Zeichen konkreter werden: die Darstellung für den Menschen und die Speicherungen für den Rechner.

Für die Darstellung, also die konkrete Gestalt eines Zeichens, kommt die Schriftart ins Spiel. Sie ordnet einer Teilmenge des Zeichensatzes Glyphen zu, welche die Benennung und die Zahl eines Zeichens auf ein konkretes Bild abbildet – zum Beispiel die Glyphe A oder das Emoji ?, wie Sie sie hier in der bekannten Schriftart Arial lesen und sehen können. Sollte eine Schriftart ein Zeichen im Text nicht enthalten, wird es häufig durch das Ersetzungszeichen ersetzt. Moderne Betriebssysteme versuchen dies allerdings zu vermeiden, indem sie in anderen im System installierten und möglichst ähnlichen Schriftarten nach einer passenden Glyphe suchen. Für dieses Verhalten gibt es jedoch keinerlei Garantien.

Für die Speicherung, also die maschinennähere Konkretisierung des Zeichensatzes, werden Kodierungen eingesetzt. Zwar könnte man genau genommen einfach die vom Unicode definierten Zahlenabbildungen verwenden, jedoch müsste man sich hierfür auf eine feste Anzahl von Bytes pro Zeichen festlegen. In der Anfangszeit des Unicodes wären – um den gesamten Zeichenumfang abdecken zu können – hierzu zwei Bytes nötig gewesen, seit der Überschreitung von 65.536 Zeichen im Jahre 2001 jedoch drei Bytes. Dieser Wechsel wäre mit einer festen Byteanzahl sehr schwierig gewesen. Zudem ist es aus Speichereffizienzgründen auch wünschenswert, häufig genutzten Zeichen weniger Bytes zuzuordnen. Aus diesem Grund gibt es für den Unicode eine Menge von Transformationsformaten, wovon UTF-8 (besonders effizient für westliche Zeichen und De-facto-Standard des Internets) und UTF-16 die bekanntesten sind. Versuchen Systeme mit falsch eingestellten Encodings zu kommunizieren, so ist das Ergebnis häufig eine Zuordnung auf falsche Zeichen, welche dann zu Zeichensalat führen (z. B. wird „Größere Veränderungen“ zu „Größere Veränderungen“) - oder eine Zuordnung auf nicht definierte Zeichen, die durch das Ersetzungszeichen ersetzt werden („Gr ere Ver nderungen“).

 

Was ändert sich mit der DIN SPEC 91379?

Das Erfreuliche: Seitens der Kodierung ändert sich normalerweise nicht viel. Zwar müssen miteinander kommunizierende Systeme an dieser Stelle aufeinander abgestimmt sein. Dies ist jedoch nicht neu; auch bei fast jedem anderen Zeichenumfang hätten falsch eingestellte Encodings bereits vorher zu größeren Problemen geführt. Interessanter wird es beim Zeichensatz – die DIN SPEC gibt hier einen Mindestvorrat an Zeichen an, der zu unterstützen ist. Oft wird bereits zumindest an der Schnittstelle Unicode³ unterstützt – ein guter Anfang – doch die DIN SPEC „[…] umfasst insbesondere die Erfassung, Speicherung, Übermittlung, Anzeige und den Ausdruck aller Schriftzeichen“. Es muss also sichergestellt sein, dass etwaige Systeme und Verfahren die entsprechenden Zeichen vollumfänglich unterstützen. Hierbei den ganzen Unicode abzudecken, mag bei Systemen, die lediglich Eingabedaten speichern und/oder weiterleiten, noch möglich sein, birgt jedoch bei den meisten weiter gehenden Verfahren einige Schwierigkeiten:

• Um eine Vorgabe wie die DIN SPEC sicher zu erfüllen, ist es ratsam, die korrekte Verarbeitung des Zeichenvorrats mit technischen Mitteln zu prüfen. Eine Prüfung des gesamten Unicodes wäre jedoch äußerst aufwendig, auch unter der Hinsicht, dass dem Unicode als lebendem Standard regelmäßig neue Zeichen hinzugefügt werden. So würde man vielerorts auf nur wenig Überraschung treffen, wenn sich herausstellt, dass das eigene System, das vermeintlich Unicode unterstützt, an irgendeiner Stelle doch Probleme mit neueren Zeichen hat, die zwar an der Systemschnittstelle akzeptiert, aber von einer älteren Systemkomponente nicht gekannt werden.
• Nicht jedes Zeichen ist im Kontext deutscher Behörden sinnvoll. Zwar können grobe Fehler – wie Emojis in Namen – oft durch eine menschliche Kontrolle erkannt werden, doch spätestens bei extrem ähnlichen bis identischen Zeichen, wie etwa dem jeweils lateinischen, griechischen und kyrillischen P ist auf eine solche Kontrolle kein Verlass mehr. Die DIN SPEC unterteilt deshalb ihren Zeichensatz noch einmal in fünf verschiedene Datentypen für verschiedene Anwendungsfelder wie Namen natürlicher Personen oder sonstige Namen wie Straßennamen. Durch Anwendung dieser Datentypen können unplausible Daten – wie Zahlen in natürlichen Namen – direkt an der Systemgrenze abgefangen werden. Ein Vorteil, der bei grundsätzlicher Annahme des gesamten Unicodes entfallen würde.
• Häufig ist in Fachverfahren gewünscht, Daten auf andere Formen zu transformieren – zum Beispiel eine Form ohne Sonderzeichen oder eine Suchform, um eine „Müllêrstraße“ auch bei einer Suche nach „Muellerstrasse“ zu finden. Für jedes DIN-SPEC-Zeichen ist eine Abbildung auf ausschließlich große, lateinische Buchstaben definiert, die zu diesem Zweck verwendet werden kann. Eine solche Abbildung für den ganzen Unicode zu finden, ist dagegen fast unmöglich.

 

 

Zuletzt zu bedenken ist die Schriftart: In vielen Systemen werden Namensdaten nicht nur erhoben und gespeichert, sondern zu irgendeinem Zeitpunkt dargestellt – sei es in einer Webanwendung oder auf einem Druckstück. Die Auswahl einer Schriftart ist daher unumgänglich. Zwar gibt es einige ambitionierte Projekte, die Schriftarten entwickeln, welche den vollständigen Unicode abdecken, doch für die meisten gängigen Schriftarten gilt das nicht. Einfacher wird es bei Schriftarten, die wenigstens den DIN-SPEC-Zeichenvorrat abdecken – jedoch auch hier fehlen je nach Version bei vielen bekannten Schriftarten wie Arial noch Zeichen. Auch die im Styleguide der Bundesregierung empfohlene Schriftart BundesSans deckt gerade einmal 59 Prozent der Zeichen ab (Stand 09/21). Eine beliebte Wahl aus dem Open-Source-Bereich ist daher die Schriftartgruppe „Liberation“⁴, die mittlerweile eine vollständige Abdeckung bietet und dabei in ihrer Schriftweite je nach Variante Arial, Times New Roman oder Courier New nachbildet. Bekannte Alternativen mit (fast) allen Zeichen der DIN SPEC sind „DejaVu“⁵ und „Noto“⁶.

In der öffentlichen Verwaltung spielen offizielle Dokumente mit einem exakt vorgegebenen Design (Ausweis, Führerschein, amtliche Bestätigungen oder Bescheide etc.) aus nachvollziehbaren Gründen eine große Rolle. Diese geben häufig für bestimmte Angaben wie „Vorname“, „Nachname“, „Adresse“ einen bestimmten – häufig auch knapp bemessenen – Platz vor. Auch die zu verwendende Schriftart ist bei solchen Dokumenten häufig festgelegt. Insbesondere bei älteren offiziellen Dokumenten, welche die beliebten Schriftarten Arial, Times New Roman oder Courier New benutzen, können mit einer Umstellung auf die DIN SPEC plötzlich einige Glyphen fehlen. Einfach eine beliebige andere Schriftart zu wählen ist nicht ratsam, weil sich mit dem Wechsel der Schriftart häufig die Schriftweite ändert. Damit können sich dann Textumbrüche verschieben oder lange (Straßen-)Namen, die zuvor noch exakt in den vorgegebenen Platz hineinpassten, passen nun nicht mehr. Auch hierfür ist die Wahl der Open Source-Schriftartgruppe „Liberation“ eine gute Wahl. Neben der schon oben erwähnten vollständigen Abdeckung der DIN SPEC Zeichen bildet sie je nach Variante Arial, Times New Roman oder Courier New eine verschiedene Schriftweite.

 

Probleme in der Praxis

Ist nun einmal klar, welche Schritte nötig sind, um ein System DIN-SPEC-konform zu machen, ergibt sich rasch ein sehr praktisches Problem: Oft kommunizieren IT-Systeme untereinander und sind dabei darauf angewiesen, den gleichen Zeichenvorrat zu verstehen. Eine gleichzeitige Umstellung aller kommunizierenden Systeme ist jedoch häufig organisatorisch schwierig machbar – es muss von einer schrittweisen Umstellung ausgegangen werden. Dabei fällt zunächst auf: Schickt ein System Daten eines kleineren Zeichenvorrats, etwa des alten String.Latin-1.1-Standards, an ein System, das bereits den vergrößerten Zeichenvorrat der DIN SPEC 91379 unterstützt, entsteht kein Problem. Der Empfänger unterstützt ja auch alle Zeichen des kleineren Zeichenvorrats. Problematisch wird es immer dann, wenn Daten mit Zeichen verschickt werden, die vom empfangenden System nicht verarbeitet werden können. Daraus ergibt sich eine natürliche Reihenfolge: Werden immer zunächst diejenigen Systeme umgestellt, die ausschließlich Daten empfangen oder nur an bereits DIN-SPEC-konforme Systeme schicken, gibt es theoretisch keine Probleme (siehe Abbildung 2).

 

 

Leider ist es auch nicht immer möglich, eine Umstellungsreihenfolge beliebig festzulegen – spätestens, wenn die Systeme unterschiedlichen Behörden zugeordnet sind. Für solche Fälle kann eine Transformation in kleinere Zeichensätze zu Hilfe genommen werden, um Systeme mit unterschiedlichen Zeichensätzen kommunizieren zu lassen. Eine direkte Transformation auf den alten Standard String.Latin 1.1 gibt die DIN SPEC zwar nicht vor⁷, dafür aber Abbildungen auf verschiedene internationale Standards wie die ISO8859⁸ oder Windows CP1252⁹, welche hierbei eine größere Hilfestellung bieten. Spätestens ab November 2024 sollten solche Behelfe jedoch durch eine vollumfängliche Unterstützung des DIN-SPEC-Zeichensatzes ersetzt worden sein. Aus alledem ergibt sich ein Bedarf, der an vielen Stellen zu beobachten ist: der Bedarf nach Standardisierung. Denn eine größere Menge von Systemen auf den neuen Standard umzustellen und dabei technisch die Zeichenmenge, Suchform, Datentypen und etwaige Transformationen jeweils neu zu implementieren, multipliziert das Risiko von Fehlern und damit Kommunikationsschwierigkeiten von Systemen – ein Problem, dem jedoch mit einheitlichen Softwarekomponenten leicht und effektiv begegnet werden kann, sodass der Umstieg bis November 2024 möglichst reibungslos gelingen kann.

 

Mehr zum Thema IT lesen Sie hier

Mehr lesen

 

Quellen

¹ https://www.personenstandsrecht.de/Webs/PERS/DE/uebereinkommen/_documents/ciec/ue14.html (abgerufen am 20.12.2021).

² https://www.beuth.de/de/technische-regel/din-spec-91379/301228458 (abgerufen am 20.12.2021).

³ https://de.wikipedia.org/wiki/Unicode (abgerufen am 20.12.2021).

⁴ https://de.wikipedia.org/wiki/Liberation_(Schriftart) (abgerufen am 20.12.2022).

⁵ https://de.wikipedia.org/wiki/DejaVu (abgerufen am 20.12.2021).

⁶ https://de.wikipedia.org/wiki/Noto_Fonts (abgerufen am 20.12.2021).

⁷ Dieses „Versäumnis“ wird mit der DIN 91379, welche der DIN SPEC 91379 nachfolgen wird, behoben. Die DIN unterscheidet sich inhaltlich kaum von der DIN SPEC (Stand 11/2021: NORM-Entwurf bei beuth.de verfügbar) und beinhaltet die fehlenden Regeln für eine direkte Transformation auf den alten Standard String.Latin 1.1.

⁸ https://de.wikipedia.org/wiki/ISO_8859 (abgerufen am 20.12.2021).

⁹ https://de.wikipedia.org/wiki/Windows-1252 (abgerufen am 20.12.2021).