Dem Unicode-Zeichensatz kommt im Zuge der zunehmenden Internationalisierung auch in BS2000 und seinen Anwendungen eine entscheidende Bedeutung zu. Nähere Informationen dazu finden Sie im Handbuch „ Unicode in BS2000“.
Die Unicode-Unterstützung in BS2000 ist eingebettet in das bereits vorhandene Konzept der codierten Zeichensätze (Coded Character Set, CCS), siehe Handbuch „ XHCS (BS2000)“.
Voraussetzung für die Verwendung von Unicode ist eine dementsprechende BS2000-Systemumgebung. Derzeit sind für SESAM/SQL die Produkte ESQL-COBOL, COBOL, CRTE und XHCS relevant, siehe die Freigabemitteilung zu SESAM/SQL-Server.
Das Konzept der Unicode-Unterstützung in SESAM/SQL erlaubt die Verwendung von Unicode-Zeichen in den Spalten von Tabellen und berücksichtigt codierte Zeichensätze in Datenbanken, in Ein-/Ausgabedateien und für Anwenderprogramme. Dieses Konzept wirkt sich auf die SQL-Sprachbeschreibung, die Utility-Funktionen und die SESAM/SQL-Anwenderprogramme aus.
EBCDIC-Zeichensätze
Der Standardzeichensatz im BS2000 ist EBCDIC.DF.03IRV (CCS-Name EDF03IRV), ein 7-Bit-Zeichensatz, dessen Zeichenvorrat dem ASCII-7-Bit-Zeichensatz entspricht, erweitert um den zweiten Steuerzeichenblock von ISO8859-1.
EDF03IRV umfasst nur 191 Zeichen, davon 95 abdruckbare Zeichen.
Die 8-Bit-Zeichensätze EDF04x (x=1, 2, 3, 4, 5, 7, 8, 9, F) entsprechen in ihrem Zeichenvorrat den entsprechenden Zeichensätzen ISO8859-x.
Alle EBCDIC-Zeichensätze enthalten denselben EBCDIC-Kern (79 Zeichen). Die 8-Bit-Zeichensätze enthalten außerdem sprachspezifische Zeichen, z.B. griechische Zeichen in EDF047. Für die Anwendung der EBCDIC-Zeichensätze mussten in SESAM/SQL bis V4.0 keine Besonderheiten beachtet werden. Der codierte Zeichensatz der Datenbank (CODE_TABLE) hatte Kommentarcharakter.
Zur binären Darstellung (Codierung) eines EBCDIC-Zeichens genügt ein Byte. Die Länge eines EBCDIC-Zeichens ist demzufolge ein Byte.
Aus Kompatibilitätsgründen zum Unicode-Zeichensatz wird auch für EBCDIC-Zeichenketten die Angabe der Länge in Code Units (1 Code Unit = 1 Zeichen = 1 Byte) definiert.
Vergleich und Sortierung von Werten bzw. Spalten mit alphanumerischen (EBCDIC-) Datentypen erfolgen binär:
lateinische Kleinbuchstaben (a-z) < lateinische Großbuchstaben (A-Z) < Ziffern (0-9)
Das Wort „alphanumerisch“ drückt in der Handbuchreihe SESAM/SQL die Zugehörigkeit zu einem EBCDIC-Zeichensatz aus, z.B. alphanumerischer Datentyp, alphanumerischer Wert, alphanumerisches Literal.
Unicode-Zeichensatz
Unicode fasst alle weltweit bekannten Textzeichen in einem einzigen Zeichensatz zusammen. Zudem ist Unicode unabhängig von unterschiedlichen Herstellern, Systemen und Ländern.
In Unicode wird jedem Zeichen eine Nummer, der sogenannte Code Point, zugeordnet. Ein Unicode Code Point wird im Allgemeinen in der Form U+n angegeben, wobei n aus 4 bis 6 sedezimalen Ziffern besteht. Beispiel: das Euro-Zeichen €: U+0020AC.Der Unicode-Zeichensatz umfasst über eine Million Code Points.
Für die Darstellung von Unicode-Werten oberhalb FFFF (sedezimal) werden sogenannte Surrogate Pairs verwendet:
Code Point-Bereich | UTF-16-Codierung (2 Byte) | Bemerkungen |
| Leading Surrogate | |
| Trailing Surrogate | |
| Surrogate Pair | Leading Surrogate gefolgt von |
Tabelle 2: Surrogate-Darstellung
„Noncharacters“ sind Code Points, die in Unicode für interne Zwecke reserviert sind. Sie dürfen in SESAM/SQL nicht in Unicode-Zeichenketten verwendet werden.
Die folgende Tabelle zeigt die Code Point-Bereiche der Noncharacters und wie diese Zeichen in UTF-16 codiert sind.
Code Point-Bereich | UTF-16-Codierung (2 Byte) | Bemerkungen |
| nicht zulässig | 32 Code Points |
| nicht zulässig | 32 Code Points |
| nicht zulässig | 2 Code Points |
Tabelle 3: Unicode-Noncharacters (x ist eine Sedezimalziffer)
Code Points werden für den Einsatz in der Datenverarbeitung auf verschiedene Arten in Bytes dargestellt (codiert). Das Unicode-Konsortium definiert dafür drei verschiedene Codierungsformen („encoding forms“): UTF-8, UTF-16 und UTF-32.
Die Länge von Unicode-Zeichenketten in der jeweiligen Codierungsform wird dabei in Code Units angegeben. Beschränkt man sich bei der Codierungsform UTF-16 auf das sogenannte „Basic Multilingual Plane“ (BMP, entspricht UCS-2) so ist 1 Code Unit = 2 Byte.
SESAM/SQL verwendet in den Datenbanken zur Darstellung von Unicode-Zeichen die Codierungsform UTF-16.
Zur binären Darstellung (Codierung) eines UTF-16-Zeichens in SESAM/SQL werden also genau zwei Byte benötigt, d.h. eine Code Unit in UTF-16. Vergleich und Sortierung von Werten bzw. Spalten mit Unicode-Datentypen erfolgen (bezogen auf UTF-16) binär:Ziffern (0-9) < lateinische Großbuchstaben (A-Z) < lateinische Kleinbuchstaben (a-z).
Das Wort „National“ drückt in der Handbuchreihe SESAM/SQL die Zugehörigkeit zum Unicode-Zeichensatz aus, z.B. National-Datentyp, National-Wert, National-Literal.
Der technische Report des Unicode-Standards beschreibt in Anlehnung an die Codierungsform UTF-8 für ASCII-Server eine UTF-EBCDIC-Codierung für EBCDIC-Server. Die Zeichen von UTF-8, die in einem Byte dargestellt werden, entsprechen den Zeichen des ASCII-7-Bit-Zeichensatzes. Analog entsprechen die Zeichen von UTF-EBCDIC, die in einem Byte dargestellt werden, dem Standardzeichensatz EDF03IRV von BS2000. Der Vorteil von UTF-EBCDIC (BS2000, CCS-Name UTFE) liegt darin, daß alle Systemprogramme von BS2000, die sich traditionell auf den Zeichenvorrat EDF03IRV beschränken (z.B. der BS2000-Kommandoprozessor), ohne Anpassungen auch Zeichenketten in der Codierungsform UTF-EBCDIC bearbeiten können.
Unterstützung von Unicode in SESAM/SQL
Zur Unterstützung von Unicode gibt es in SESAM/SQL die Datentypen NATIONAL CHA-RACTER (NCHAR) und NATIONAL CHARACTER VARYING (NVARCHAR). In Spalten mit diesen Datentypen können Unicode-Daten gespeichert werden.
Die Daten werden in SESAM/SQL in der Codierungsform UTF-16 (im Umfang der BMP) gespeichert. Da in der internen Darstellung von SESAM/SQL für ein UTF-16-Zeichen zwei Byte Speicherplatz (eine Code Unit) benötigt werden, ergeben sich für die Unicode-Datentypen folgende maximale Längen:
NCHAR: 128 Zeichen (256 Byte)
NVARCHAR: 16000 Zeichen (32000 Byte)
Die Unicode-Datentypen können in Operationen wie Vergleich, Konkatenation und Zuweisung verwendet werden.
Alle bisher in SESAM/SQL vorhandenen Funktionen für CHARACTER (VARYING) gibt es auch für die neuen Datentypen NATIONAL CHARACTER (VARYING). Hierbei müssen die jeweiligen Randbedingungen berücksichtigt werden.
Die neuen Datentypen werden auch in den betreffenden DDL- und Utility-Anweisungen unterstützt, siehe die Anweisungen CREATE TABLE und ALTER TABLE in der „ SQL-Sprachbeschreibung Teil 1: SQL-Anweisungen“ bzw. CREATE CATALOG, ALTER CATALOG, LOAD, UNLOAD, EXPORT, IMPORT in der „ SQL-Sprachbeschreibung Teil 2: Utilities“.
Codierter Zeichensatz der Datenbank
Zur korrekten Interpretation von (alphanumerischen) Zeichenketten in Spalten mit den Datentypen CHARACTER und CHARACTER VARYING muss SESAM/SQL den codierten (EBCDIC-)Zeichensatz kennen, in dem die Daten codiert sind.
Beim Erzeugen einer neuen Datenbank (mit CREATE CATALOG) bzw. beim Ändern einer bestehenden Datenbank (mit ALTER CATALOG) können Sie deshalb mit dem Parameter CODE_TABLE den CCS-Namen für die Datenbank bestimmen bzw. ändern. Der CCS-Name der Datenbank wird in SESAM/SQL bei Konvertierungen zwischen Daten des Typs (VAR)CHAR und N(VAR)CHAR und umgekehrt benutzt. Dies ist z.B. notwendig bei einer entsprechenden Änderung des Datentyps einer Spalte und in einigen Varianten der Utility-Anweisungen LOAD und UNLOAD.
Codierter Zeichensatz der Anwendung
Zur korrekten Interpretation von Zeichenketten muss SESAM/SQL den codierten (EBCDIC-)Zeichensatz kennen, mit dem die Anwendung die Zeichenketten interpretiert.
Mit dem neuen Konnektionsmodul-Parameter CCSN (CCS-Name) geben Sie dem independent-DBH bekannt, mit welchem Zeichensatz die Anwendung Zeichenketten interpretiert. Dem linked-in DBH geben Sie dies über die DBH-Option LINKED-IN-ATTRIBUTES bekannt.
SQL-Anweisungen können im DBH nur verarbeitet werden, wenn der CCS-Name der Anwendung mit dem CCS-Namen der Datenbank übereinstimmt oder wenn für die Datenbank kein codierter Zeichensatz verwendet wird (CODE_TABLE hat den Wert _NONE_).
Aktivierung von Unicode in einer bestehenden Datenbank
In SESAM/SQL-Datenbanken bis einschließlich V4.0 hatte der Parameter CODE_TABLE bei CREATE CATALOG Kommentarcharakter und wurde wie angegeben in den Metadaten gespeichert. Da der Parameter nun eine Bedeutung hat, erhält er beim ersten Zugriff auf eine bestehende Datenbank durch SESAM/SQL seit V5.0 den Wert _NONE_, d.h. die Datenbank verwendet keinen codierten Zeichensatz.
Zur Nutzung von Unicode muss der Datenbank-Administrator mit der Utility-Anweisung AL-TER CATALOG den aktuell verwendeten codierten (EBCDIC-)Zeichensatz für die Datenbank eintragen, z.B. EDF03IRV oder EDF041 für eine deutsche BS2000-Umgebung. Auch für die Anwendungen sollte der codierte Zeichensatz festgelegt werden, siehe oben.
Wenn der Wert _NONE_ für die Datenbank beibehalten wird, dann sind keine impliziten Konvertierungen von (VAR)CHAR nach N(VAR)CHAR und umgekehrt möglich. Alle Aufträge an die Datenbank, die eine solche Konvertierung benötigen, werden abgewiesen.
Beispiel 1
Eine Tabelle PERSONAL hat die Spalte NACHNAME mit dem Datentyp CHARACTER(40). Der CCS-Name der Datenbank ist EDF041, die Daten sind also mit dem CCS-Namen EDF041 gespeichert. Zur Nutzung von Unicode gibt es zwei Möglichkeiten:
Mit der folgenden DDL-Anweisung wird der Datentyp der Spalte
NACHNAMEin NATIONAL CHARACTER geändert und die in dieser Spalte gespeicherten Daten werden implizit von EDF041 nach UTF16 konvertiert:ALTER TABLE PERSONAL ALTER COLUMN NACHNAME SET NCHAR(40)Mit der folgenden Anweisung wird eine zusätzliche Spalte definiert:
ALTER TABLE PERSONAL ADD COLUMN ALIAS_NACHNAME NCHAR(40)Anschließend werden die Daten explizit von der ursprünglichen Spalte vom Datentyp CHARACTER in die Zielspalte vom Datentyp UTF16 konvertiert. Dabei wird der codierte Zeichensatz EDF041 der Datenbank verwendet:
UPDATE PERSONALSET ALIAS_NACHNAME=TRANSLATE(NACHNAME USING CATALOG_DEFAULT)
Beispiel 2
Eine Tabelle PERSONAL hat die Spalte NACHNAME mit dem Datentyp CHARACTER(40). Der CCS-Name der Datenbank hat den Wert _NONE_. Mit folgender Anweisung wird eine zusätzliche Spalte definiert:
ALTER TABLE PERSONAL ADD COLUMN ALIAS_NACHNAME NCHAR(40)
Anschließend werden die Daten explizit von der ursprünglichen Spalte vom Datentyp CHARACTER in die Zielspalte vom Datentyp UTF16 konvertiert. Dabei wird der codierte Zeichensatz EDF041 explizit angegeben:
UPDATE PERSONAL SET ALIAS_NACHNAME = TRANSLATE(NACHNAME USING EDF041)
Folgende Anweisung wird abgewiesen, da der CCS-Name der Datenbank _NONE_ ist und somit die Konvertierung nicht ausgeführt werden kann.
UPDATE PERSONAL SET ALIAS_NACHNAME=TRANSLATE(NACHNAME USING CATALOG_DEFAULT)
Transliteration, Transcoding
Zum Umwandeln von alphanumerischen Zeichenketten (Datentyp (VAR)CHAR) in Unicode-Zeichenketten (Datentyp N(VAR)CHAR, Zeichensatz UTF-16) und umgekehrt (Transliteration) gibt es in SESAM/SQL die SQL-Funktion TRANSLATE().
TRANSLATE() wandelt auch alphanumerische Zeichenfolgen, die im Unicode-Zeichensatz UTF-EBCDIC (BS2000, CCS-Name UTFE) vorliegen, in den Unicode-Zeichensatz UTF-16 um und umgekehrt (Transcoding).
Siehe die „ SQL-Sprachbeschreibung Teil 1: SQL-Anweisungen“.
Normalisierung
Die Codierung eines Zeichens in Unicode ist nicht eindeutig, d.h. es kann für ein Zeichen mehr als eine Codierung geben.
Ein typisches Beispiel sind die deutschen Umlaute. Beispielsweise hat das Zeichen Ä sowohl den Code Point U+00C4 (composed form) als auch die Code Point-Kombination U+0041 und U+0308 (decomposed form). In normalisierten Darstellungsformen treten diese Unterschiede nicht auf. Wenn zwei normalisierte Zeichenketten unterschiedlich sind, dann sind es auch ihre unterschiedlichen Code Point-Darstellungen.
Nicht-normalisierte Zeichenketten können zu Folgefehlern nach einer Sortierung führen.
In SESAM/SQL bringt die SQL-Funktion NORMALIZE() eine Zeichenkette mit National-Zeichen (Datentyp N(VAR)CHAR) in eine normalisierte Form. Dabei werden nur Zeichen berücksichtigt, die Code Points im Bereich U+0000 bis U+2FFF besitzen. Andere Zeichen, z.B. Surrogates, bleiben unverändert. Siehe die „ SQL-Sprachbeschreibung Teil 1: SQL-Anweisungen“.
Der Vorgang der Normalisierung benötigt CPU-Leistung. Deshalb sollten die Daten einer SESAM/SQL-Datenbank in normalisierter und komprimierter Form vorliegen.
Wenn nicht sichergestellt ist, ob (Eingabe-)Daten in normalisierter Form vorliegen, sollte eine Normalisierung mit der SQL-Funktion NORMALIZE() in die Normalization Form C durchgeführt werden.
Beispiel
Der Code Point U+1ED6 entspricht dem lateinischen Großbuchstaben „O“ mit Zirkumflex und Tilde. Dieses Zeichen kann mit Hilfe dreier Code Points U+00D4 für „Ô“ und U+0303 für Tilde bzw. U+004F für „O“ und U+0302 für Zirkumflex und U+0303 für Tilde erzeugt werden. Auch die Code Point-Sequenz U+00D5 für das „Õ“ mit Tilde und U+0302 für Zirkumflex ergibt dieses Zeichen. Es gibt nur die Regel, dass das Grundzeichen vor den damit verknüpften diakritischen Zeichen steht.
D.h. das Ergebnis der Normalisierungsform C (compose) von NORMALIZE() des lateinischen Großbuchstaben „O“ mit Zirkumflex und Tilde ist U+1ED6, das Ergebnis der Normalisierungsform D (decompose) ist die Code Point-Kombination U+004F, U+0302, U+0303.
Sortierreihenfolge
In den meisten Programmen werden Zeichenketten binär verglichen. Die binäre Sortierreihenfolge der Zeichen ist abhängig von ihrer Codierung:
Für alle ISO8859- und Unicode-Codierungen gilt:
Ziffern (1-9) < lateinische Großbuchstaben (A-Z) < lateinische Kleinbuchstaben (a-z)Für EBCDIC und UTFE gilt:
lateinische Kleinbuchstaben (a-z) < lateinische Großbuchstaben (A-Z) < Ziffern (1-9).
Umlaute und diakritische Zeichen sind nicht eindeutig in diese Sortierreihenfolgen eingeordnet. Damit können sich unschöne Sortierreihenfolgen ergeben, z.B. kann in der Sortierung einer Namensliste der Name „Zuse“ vor dem Namen „Öhler“ erscheinen.
Die Unicode-Norm beschreibt einen linguistischen Sortieralgorithmus. Jedem Unicode-Zeichen wird ein Sortierelement (Collation-Element) zugeteilt. Die Reihenfolge nach der die Unicode-Zeichen sortiert werden, wird mit Hilfe dieser Collation-Elemente festgelegt. Die Collation-Elemente werden mittels einer von XHCS gelieferten Tabelle (Default Unicode Collation Table, DUCET) festgelegt. Diese Tabelle enthält eine Wertigkeit des Zeichens auf verschiedenen Ebenen (Leveln). SESAM/SQL unterscheidet drei Ebenen, die in der nachfolgenden Tabelle dargestellt sind. Der Vergleich der einzelnen Zeichen findet jeweils von links nach rechts statt. Der erste Unterschied bestimmt das Vergleichsergebnis.
Vergleichsebene | Beschreibung | Beispiel |
Ebene 1 | Grundzeichen (base character) | a < b |
Ebene 2 | Akzente (diakritische Zeichen) | A < Å |
Ebene 3 | Groß-/Kleinschreibung | a < A |
Ebene 1 : | Jedem Grundzeichen (a,b,c...) ist eine feste Wertigkeit in der Default Unicode |
Ebene 2 : | Zum Grundzeichen gehört ein diakritisches Zeichen. Ein diakritisches Zeichen |
| Ebene 3: | Die Sortierreihenfolge wird durch die Unterscheidung zwischen Groß- und |
In BS2000 können Sie sich das Collation-Element über XHCS besorgen, siehe auch Handbuch „ XHCS (BS2000)“.
Die SQL-Funktion COLLATE() liefert für National-Zeichenketten das entsprechende Collation-Element der Default Unicode Collation Table.
Siehe die „ SQL-Sprachbeschreibung Teil 1: SQL-Anweisungen“.