Zeichenkonkordanzen

Auch wenn eine Zuordnung von Zeichensätzen zu Unicode vorliegt, ist es oft ziemlich mühsam, zwischen zwei gegebenen Zeichensätzen eine Umsetzungstabelle zu erzeugen. Dies liegt daran, daß diese Zeichensätze normalerweise nicht 1:1 ineinander abbildbar sind und daher unbedingt die Unicode-Information zu kanonischer und Kompatibilitäts- Dekomposition herangezogen werden sollte, um auch »verborgene« Übereinstimmungen zu entdecken. Aber auch dann bleiben noch genügend andere Faktoren, die die Deklaration von »offiziellen« Umsetzungstabellen fragwürdig machen:

• Die gegebenen Zeichensätze haben teilweise feinere Unterscheidungen als Unicode (z.B. Trema vs. Umlaut in MAB2, Akut-Apostroph ist nur Apostroph in MAB2).
• Die gegebenen Zeichensätze haben gröbere Unterscheidungen als Unicode (z.B. wird in den meisten bibliothekarischen Zeichensätzen zwar zwischen kleinem serbokroatischem dj ->đ<- und kleinem isländischen eth ->ð<- unterschieden, nicht aber zwischen den jeweiligen Großbuchstaben Dj ->Đ<- und Eth ->Ð<-).
• Anhand von vorhandenen Beispiel-Mappings der Zeichensätze auf andere ist ersichtlich, daß andere Ansichten über (De-)Komponierbarkeit vorliegen: So faßt z.B. Unicode die Zeichen ->Æ<- und ->æ<- nicht einmal als Ligaturen auf, aber auch die Ligaturen ->Œ<- und ->œ<- gelten als nicht »kompatibel« auflösbar. Desweiteren sind generell alle Zeichen mit Quer- und Schrägstrichen in Unicode nicht auf den Grundbuchstaben und ein separates Diakritikum reduzierbar. (Vermutlich war die Erkenntnis, daß man hierfür genau so viele - minimal abweichende - Einzelstriche wie komponierte Zeichen benötigen würde.)
• Umgekehrt gibt es stellenweise auch »Geisterzeichen« die sich von irgendwelchen Zeichensatzdefinitionen auf andere vererbt haben (man beachte die stellenweise abenteuerlich verfremdeten Darstellungen in den handschriftlichen Tabellen der MAB1-Dokumentation, oder den Hinweis zum Buchstaben YR ->Ʀ<- in den den Unicode-Tabellen, die ich so verstehe, daß DIN 31624 und ISO 5246-2 die einzigen Belege für die Existenz dieses Zeichens sind, das ich persönlich für identisch mit dem grönländischen Kra ->ĸ<- halte).
• Auch in den Fällen, in denen offizielle Mappings von Zeichensätzen zu Unicode vorliegen, ist es nicht gewährleistet, daß Daten entsprechend dieser Mappings erzeugt wurden (die Codepage CP437 hat offiziell auf Position 0xe7 das Zeichen "kleines tau" ->τ<-, die überwiegende Mehrzahl aller realen Anwender wird aber anhand des Aussehens geschlossen haben, daß es sich um das Zeichen "kleines gamma" ->͏<- handelt. Auf deutschen Tastaturen erzeugt Betätigen der mit dem Paragraphenzeichen gekennzeichneten Taste auf Rechnern mit Codepage 437 das Steuerzeichen 0x15 = U0015 und nicht etwa das Paragraphenzeichen U00A7 ->§<-. Das fällt nicht weiter auf, weil in dieser Codepage die Visualisierung dieses Steuerzeichens einem Paragraphenzeichen entspricht). Es sollte stets bedacht werden, daß die Unicode-Mappings dieser Zeichensätze stets retrospektiv erzeugt worden sind, zumindest ist mir keine Beispiel bekannt, wo sich nach dem Aufkommen von Unicode noch jemand die Mühe gemacht hat, einen neuen Zeichensatz zu definieren.
• Zu beachten ist auch, daß in bibliothekarischen Zeichensätzen oft mehrere äquivalente Codierungen für Zeichen existieren, analog den kanonischen Dekompositionen in Unicode: Gängige Zeichen wie die deutschen Umlaute und viele andere sind etwa in PICA und dem Allegro-Ostwest-Zeichensatz kombinierbar und außerdem als bereits kombinierte Einzelzeichen vorhanden. Im Falle der kombinierbaren Zeichen mit Grundbuchstabe "i" ist - anders als in Unicode - auch die Komposition mit dem türkischen, punktlosen i ->ı<- erlaubt.
• Bei Daten von realen Applikationen gibt es stets noch Zeichen mit Steuerbedeutung und jeweils zusätzlich Konventionen der Darstellung dieser Zeichen in der Dokumentation. Eine Unicode-basierende Umsetzung dieser Zeichen kann nur - meist erfolglos - diese Zeichen entsprechend ihrem Aussehen umsetzen, nicht aber die gewüschte Zuordnung auf der Ebene der Zeichenbedeutungen vornehmen.
• Anwender haben die Tendenz, auch solche Zeichen zu benutzen, die in ihrem gegebenen Zeichensatz nicht bzw. mit abweichender Bedeutung vorhanden sind, solange sie nur ähnlich genug aussehen. In bibliothekarischen Daten weit verbreitet sind (in PI etwa noch vorgeschriebene) Formatangaben als Folio, Quart und Oktav: 2°, 4° und 8°. Der »Kringel« ist vermutlich ein Gradzeichen ->x°< (im Gegensatz zu einer hochgestellten Null ->x⁰<- oder einem verballhornten maskulinen Ordinal ->xº<- oder anderen denkbaren Möglichkeiten. In der einschlägigen Norm DIN 31628-2 ist dieses Zeichen aber nicht als für bibliothekarische Anwendungen obligatorisch erwähnt, insofern fehlt es auch bei den verbreiteten Zeichensätzen MAB und PICA. Anwender tendieren in diesem Fall dazu, den in diesen Zeichensätzen vorhandenen, nur kompositionell zu benutzenden übergesetzten Ringel (Unicode U030A) als Gradzeichen (übrigens auch für geographische Gradangaben) einzusetzen (Das Gradzeichen ist hierbei besonders pikant, weil es ziemlich oft das letzte Zeichen eines Datenfeldes ist: Verarbeitende Software tut sich oft schwer mit dem Umstand, daß das letzte Zeichen eines Feldes oder Absatzes oder Datensatzes signalisiert, es sei ein überzusetzender Akzent auf das folgende Zeichen, das dann nicht kommt).
• Umgekehrt sind Anwender (nicht nur) in Anwendungen ohne »bibliothekarische« Zeichensätze versucht, Diakritika und typographische Besonderheiten der Vorlagen unter Zuhilfename der normalen ASCII-Zeichen Grad (->°<-), Tilde (->~<-), Unterstrich (->_<-), Apostroph (->'), Backtick (->`<-) und vielen anderen mehr zu erzeugen. Teilweise dieselben Zeichen werden von denselben Anwendern dann aber auch in ihrer »Standardbedeutung« benutzt, etwa wenn sie als Anführungszeichen oder in URLs vorkommen.
• In bibliothekarischen Anwendungen wird oft mit einer unvollständigen Zeichensatzunterstützung gearbeitet, indem nur Fonts umgeschaltet werden, die Tastaturcodes aber der für den Rechner globalen Ländereinstellung entspricht. (Vermeintliche) Tastatureingabe von Akzentbuchstaben führt dann dazu, daß der Rechner den Code für ein Einzelzeichen generiert, das im bibliothekarischen Zeichensatz möglicherweise legal ist, jedenfalls aber nicht die beabsichtigte Bedeutung hat. Hier handelt es sich strenggenommen um Anwendungsfehler, die aber in Einzelfällen die definierte Bedeutung der Zeichensätze überwiegen.
• In Zeiten der partiellen Unicode-Unterstützung ist es zudem oft nötig, einen Zeichensatz simultan in eine Reihe von (umzuschaltenden) Zeichensätzen abzubilden, etwa für Druckzwecke oder die Abbildung nach (WGL4)-RTF. Dies wird dann schnell unübersichtlich.

Die folgenden Links beziehen sich jeweils auf Tabellen für die Zuordnung eines Quell- in evtl. mehrere Zielzeichensätze, die wie folgt strukturiert sind:

1. 1:1-Abbildungen
   1. 1:1-Abbildungen von Zeichen an identischer Position
   2. 1:1-Abbildung von Zeichen auf Zeichen an anderer Position, identisch für alle Zielzeichensätze
   3. sonstige 1:1-Abbildungen von Zeichen
2. andere eindeutige Zuordnungen
   1. weitere Eindeutige Abbildung mittels kanonischer Dekomposition
   2. Eindeutige Abbildunge mittels Kompatibilitätszerlegung
3. Protypkombinationen im Quellzeichensatz (kein Mapping!)
4. Kompositionelle Abbildungen
   1. Protypabbildungen (kanonische Zerlegung mit Diakritischen Zeichen im Quellzeichensatz zu Einzelzeichen im Ziel)
   2. Komposition -> Einzelzeichen mit anderen als diakritischen Zeichen
5. kanonische Dekompositionen im Quellzeichensatz zu Kompatibilitätszerlegungen in den Zielzeichensätzen (kommt vor?)
6. Partielle Abbildungen von Einzelzeichen
   1. mit kanonischer Dekomposition
   2. mit Kompatibilitätszerlegung
   3. mit weiteren, nicht-Unicode Kompatibilitäten
7. Benutzte, aber nicht 1:x oder x:1 abgebildete Zeichen
   1. im Quellzeichensatz
   2. im Zielzeichensatz
8. Für die Konkordanz überhaupt nicht benutzte Zeichen
   1. im Quellzeichensatz (nicht abbildbar)
   2. im Zielzeichensatz (nicht erreichbar)
9. Unbenutzte Zeichenpositionen
   1. im Quellzeichensatz
   2. im Zielzeichensatz

Von der Vielzahl der bibliothekarischen Zeichensätze (MAB1, MAB2, MAB-Diskette, Pica, ANSEL, Allegro-Ostwest, ...) sind tendenziell alle Mappings untereinander, mit sich selbst (wg. Protyp-Expansionen), von und nach Unicode interessant sowie die Abbildungen von und in diverse gängige Codepages (DOS: CP437, CP850, CP852, mehrere von diesen, Windows: CP1252, CP1250, CP1254, mehrere von diesen) und ISO-Zeichensätze (8859-1, 8859-2, andere) interessant. Dies ergibt einige tausend mögliche Kombinationen, zuviel um sie hier alle vorzuhalten. Ich habe daher hier einige (vielleicht) besonders interessante Kombinationen aufgelegt, bei Bedarf generiere ich gerne noch weitere.

MAB

MAB1 -> MAB2,

MAB1 -> MAB-Diskette,

MAB2 -> MAB-Diskette,

MAB2 -> ANSEL,

ANSEL -> MAB2

nach allegro-Ostwest

von MAB2,

MAB-Diskette, CP852,

ANSEL,

PICA,

CP1252, CP1250,

Ostwest, allegro-Windows,

von Ostwest in einzelne

nach MAB2,

MAB-Diskette,

ANSEL,

ISO 8859-1, ISO 8859-2,

allegro-Windows,

Unicode.

von Ostwest in mehrere (Platzhalter müssen ausgefült werden)

CP850 + CP852 + CP857,

ISO Latin 1, 2, 5, 7,

Windows Latin 1, 2, 5, 7.