Konzept isy-sonderzeichen
Diese Seite ist ein Teil der IsyFact-Standards.
Alle Inhalte der Seite, insbesondere Texte und Grafiken, sind urheberrechtlich geschützt.
Alle urheberrechtlichen Nutzungs- und Verwertungsrechte liegen beim Bundesverwaltungsamt.
Die Nutzung ist unter den Lizenzbedingungen der Creative Commons Namensnennung 4.0 International gestattet.
1. Einleitung
In Anwendungen nach den IsyFact-Standards werden Daten in internationaler Schreibweise erfasst und gespeichert. Dies sind z.B. die Namen von Personen und Orten. Während die Eingabe von internationalen Sonderzeichen über eine deutsche Tastatur nur einen beschränkten Umfang an Sonderzeichen erlaubt, werden möglicherweise auch Daten abgelegt, die international landesspezifisch erfasst wurden. Hierin können alle landestypischen Sonderzeichen enthalten sein. Insbesondere also auch solche, die nicht über eine deutsche Tastatur eingegeben werden können.
Eine auf den IsyFact-Standards aufsetzende Architektur umfasst mehrere technische Systeme in einer Umgebung. Für jedes dieser Systeme muss sichergestellt werden, dass die benötigten Sonderzeichen durchgängig verarbeitet werden können und beim Datenaustausch zwischen diesen Systemen einheitlich durchgereicht und korrekt interpretiert werden.
2. Aufbau und Zweck des Dokuments
In diesem Dokument werden zunächst die Anforderungen aufgeführt, die an die Verarbeitung von Sonderzeichen innerhalb von auf IsyFact-Standards basierenden Anwendungen gestellt werden.
Internationalisierung bedeutet, ein Programm so zu entwerfen und umzusetzen, dass die Anpassung an andere Sprachen möglich ist, ohne den Quellcode zu ändern. Jedoch ist Internationalisierung nicht Bestandteil dieses Dokuments.
3. Anforderungen und Randbedingungen
An die Verarbeitung von Sonderzeichen nach den IsyFact-Standards bestehen die folgenden Anforderungen:
-
Prinzipiell (technisch) muss jedes Sonderzeichen nutzbar sein.
-
Jedes System nach IsyFact-Standards muss die Sonderzeichen in gleicher Weise verarbeiten können.
-
Nach Erlass des BMI ist für das Personenstands-, Melde- und Ausländerwesen die Verarbeitung sämtlicher Zeichen gem. OWASP Top 10 Project vorgegeben. Weder mehr noch weniger Zeichen darf/muss das System verarbeiten können.
4. Festlegung des Zeichensatzes und der Codierung
Laut der Architekturrichtlinie für die IT des Bundes - Technische Spezifikation zur Architekturrichtlinie (Version 2020) soll der Zeichensatz DIN SPEC 91379 (auch String.Latin 1.2) in der UTF-8-Codierung verwendet werden. Das BMI hat als Rahmenbedingung für seinen Verantwortungsbereich festgelegt, für die Zeichencodierung in neuen Systemen ausschließlich UTF-8 zu nutzen. Dieser Zeichensatz stellt ausreichend viele der weltweit existierenden Buchstaben, Ziffern und Symbole zur Verfügung, um Daten in internationalen Schreibweisen abbilden zu können.
Gemäß den Anforderungen des String.Latin Zeichensatzes des BMI OWASP Top 10 Project soll die IsyFact genau diesen Zeichensatz unterstützen. Nach Veröffentlichung der DIN Norm 91379 soll diese die DIN SPEC 91379 ersetzen. Daher wird festgelegt, dass für IsyFact-Standard-basierte Anwendungen der Zeichensatz DIN Norm 91379 in der UTF-8-Codierung zu verwenden ist.
| Die Webseiten der KoSIT bieten weitere Informationen zu String.Latin 1.2 sowie einen Download der entsprechenden Spezifikation. |
5. Transformation von Sonderzeichen
In den Fällen, wo kein Unicode-Zeichensatz verwendet werden kann, müssen Sonderzeichen eventuell in andere Darstellungen oder Codierungen umgewandelt werden. Hierzu gibt es prinzipiell drei Möglichkeiten: die Transkription, die Umcodierung und das Filtern von Zeichen. In diesem Kapitel werden diese drei Möglichkeiten in je einem Unterkapitel beschrieben.
5.1. Transkription
Transkription (Umschreibung) ist eine aussprachebasierte Darstellung eines fremden Alphabetes mit dem eigenen Alphabet, also z.B. die Darstellung russischer Namen in kyrillischer Schreibweise mit dem deutschen Alphabet. Transkription wird eingesetzt, um ohne Kenntnisse einer fremden Sprache und des zugehörigen Alphabets eine halbwegs richtige Aussprache von Wörtern zu ermöglichen. Eine eindeutige Rückübertragung ist in der Regel nicht möglich. Im Folgenden werden die Festlegungen zur Transkription im Rahmen der IsyFact-Standards beschrieben.
5.1.1. Zeichensätze und Sprachen
Wie in Kapitel Festlegung des Zeichensatzes und der Codierung festgelegt, wird für die IsyFact der Zeichensatz Unicode v4.x in der UTF-8-Codierung verwendet. Die Transkription überführt die internationalen Sonderzeichen aus dem Unicode v4.x Zeichensatz in den ASCII-Zeichensatz.
Im Rahmen der IsyFact werden zur Zeit von der Transkription nur kyrillische, griechische und lateinische Zeichen unterstützt, da hiermit die im europäischen Raum gebräuchlichen Zeichen abgedeckt sind.
5.1.2. Anwendungsbereiche in einer IsyFact-Systemlandschaft
Transkription ist an den folgenden Stellen von Bedeutung:
- Datenaustausch mit anderen Systemen
-
Für nach IsyFact Standards entwickelte Anwendungen ist der zu verwendende Zeichensatz festgelegt. Andere Systeme, mit denen diese kommunizieren, können aber einen anderen Zeichensatz verwenden. Hier müssen die Daten zunächst in den Zeichensatz des Zielsystems umgewandelt werden. Die Umwandlung kann durch Transkription geschehen.
Beispiel: Ein Nachbarsystem arbeitet ausschließlich mit dem ASCII-Zeichensatz. Daten einer Anwendung nach IsyFact-Standards werden zunächst umgeschrieben und dann dem Nachbarsystem übergeben. - Einheitliche Repräsentation von Daten
-
Für Namen können verschiedene ländertypische Schreibweisen genutzt werden. Trotzdem sollen Daten aber vergleichbar sein. Hier kann die Transkription zu einer einheitlichen (normierten) Schreibweise führen. Werden dann Suchen auf den umgeschriebenen Daten durchgeführt, erhöht sich die Wahrscheinlichkeit, dass der Gesuchte in der Trefferliste ist. Dadurch verbessert sich aber nicht unbedingt die Trefferqualität.
Beispiel: „Müller“ wird im Originalschreibweise gespeichert und für die Suche zu „Mueller“ umgeschrieben. Eine Suchanfrage nach „Müller“ wird zunächst zu „Mueller“ umgeschrieben, dann gesucht und auch gefunden. Eine Suchanfrage nach „Mueller“ braucht nicht umgeschrieben werden und wird gefunden.
Transkription wird in der Regel nur für Namen verwendet, also für Vornamen, Nachnamen und Ortsbezeichnungen.
5.1.3. Transkriptionsregeln
Die Transkription basiert auf dem ICAO-Standard (ICAO-MRTD). Der ICAO-Standard wurde ursprünglich für das automatische Lesen von Dokumenten in der Luftfahrt entwickelt. Er umfasst 142 Abbildungsvorschriften (Regeln) für lateinische und kyrillische Buchstaben. Für die Abbildung von griechischen Zeichen wird der Standard ISO-843 verwendet.
Während der ISO-Standard (ISO-9) für die Transkription von kyrillischen Zeichen noch diakritische lateinische Zeichen verwendet, ist bei ICAO-MRTD das Ziel, diakritische Zeichen vollständig zu vermeiden, um eine Abbildung auf den ASCII-Zeichensatz zu ermöglichen. Eine bereits umgeschriebene Zeichenfolge wird durch eine erneute Transkription nicht mehr verändert.
In der Tabelle Transkription sind die Transkriptionsregeln für die verschiedenen Zeichen dargestellt.
5.1.4. Umsetzung im System
Daten werden immer im Originalformat gespeichert. Umgeschriebene Daten können bei Bedarf zusätzlich abgelegt werden. Dabei sind die der Transkription zugrunde liegenden Parameter ebenfalls mit abzulegen. Dies führt zu folgendem Datentyp für umgeschriebene Zeichenfolgen:
Die Attribute für den Datentyp „TransText“ haben die folgende Bedeutung:
| Attribut | optional | Beschreibung |
|---|---|---|
|
nein |
Originaltext im Unicode-Zeichenformat |
|
ja |
Sprachcode gemäß ISO 639 für die Sprache des Originaltextes |
|
nein |
umgeschriebener Text |
|
nein |
Kennzeichen für den bei der Transkription verwendeten Satz von Transkriptionsregeln, also der Methode nach der die Transkription durchgeführt wurde. Verschiedene Versionen der gleichen Transkriptionsregeln können durch eigene Kennzeichen abgebildet werden. |
Die Transkription soll nicht als zentraler Service, sondern als Komponente umgesetzt werden, die bei Bedarf in die Anwendungen eingebunden wird. Dabei sind die Transkriptionsregeln in einer oder mehreren Konfigurationsdateien hinterlegt, die von der Komponente eingelesen werden. Darüber wird auch eine einfache Erweiterbarkeit der Transkriptionsregeln gewährleistet. Es ist möglich, mehrere Sätze von Transkriptionsregeln zu hinterlegen, um so auch andere Standards für die Transkription verwenden zu können.
Die Komponente Transkription bietet nach außen nur die Methode
TransText umschreiben(String text, String sprache, String methode)an.
Hier ist der Parameter text der umzuschreibende Text, sprache der Sprachcode gemäß ISO 639 und methode das Kennzeichen des zu verwendenden Satzes von Transkriptionsregeln.
Ergebnis ist die umgeschriebene Darstellung des Textes gemäß dem Datentyp TransText.
Im Fehlerfall werden entsprechende Exceptions geworfen.
Die Angabe der Sprache ist optional.
Ist die Sprache unbekannt, d.h. es wird kein Sprachcode übergeben, dann wird die Sprache bei der Transkription nicht berücksichtigt.
5.2. Umcodierung
Textdaten, die von der Anwendung aus einer Datei eingelesen werden oder über eine Programm-Schnittstelle übergeben werden, können eventuell nicht in UTF-8 codiert sein.
Textdateien werden in der Standard-Zeichencodierung der JVM eingelesen und gespeichert. Die Standard-Zeichencodierung kann als Aufrufparameter in der JVM gesetzt werden (siehe auch Kapitel Java im Dokument Sonderzeichen - Nutzungsvorgaben. Sollte eine andere Zeichencodierung verwendet werden, so muss dies explizit im Code umgesetzt werden.
Das kann z.B. erfolgen, indem die Dateien mit einem InputStreamReader gelesen werden bzw. mit einem OutputStreamWriter geschrieben werden.
In beiden Klassen kann im Konstruktor der Zeichensatz angegeben werden.
Beim Lesen werden die Daten dann automatisch decodiert bzw. beim Schreiben codiert.
Dieses Verfahren kann für beliebige Byte-Arrays verwendet werden, sodass auch Daten, die über eine Programm-Schnittstelle übergeben werden, so umcodiert werden können.
5.3. Filtern von Zeichen
Neben den druckbaren Zeichen enthält der Unicode-Zeichensatz auch nicht druckbare Steuerzeichen (Ugs. „Schmierzeichen“). Diese Zeichen können an der Oberfläche bei der Übernahme aus anderen Programmen über die Zwischenablage oder beim Import von Daten in eine IsyFact-konforme Anwendung gelangen. Diese Zeichen sind prinzipiell bei der Validierung der Daten auszufiltern. Ob der Benutzer von diesem Vorgang informiert wird oder ob Log-Einträge geschrieben werden, hängt von der Fachlichkeit der jeweiligen Anwendung ab. Je nach Anwendung kann es auch sinnvoll sein, einige Steuerzeichen, wie z.B. einen Zeilenumbruch, zuzulassen. Diese von der Anwendung abhängigen Festlegungen müssen in der Spezifikation bzw. im Systementwurf der jeweiligen Anwendung beschrieben werden.
5.4. Spezifikation von fachlichen Datentypen
Bereits in der Spezifikation ist darauf zu achten, dass für einen fachlichen Datentyp die zulässigen Zeichen genau angegeben werden. Nur so können die entsprechenden Validierungen konzipiert und umgesetzt werden. Hier ist der Datentyp String bzw. Alpha in der Regel zu grob. Hier müssen abgestufte Typen für Textinhalte definiert werden, z.B. Alpha-Latein-Basis (alle großen und kleinen lateinischen Buchstaben ohne diakritische Zeichen), Alpha-Latein-Diakrit (alle großen und kleinen lateinischen Buchstaben inklusiv diakritische Zeichen), Alpha-Europa (alle großen und kleinen lateinischen, griechischen und kyrillischen Zeichen, inklusiv diakritischer Zeichen).