DB2 Universal Database - Systemverwaltung


Unicode-/UCS-2- und UTF-8-Unterstützung in DB2 UDB

Diese beiden Standards sind hier dokumentiert.

Einführung

Der Unicode-Zeichencodierungsstandard ist ein Zeichencodierungsschema mit fester Länge, das Zeichen fast aller lebenden Sprachen der Welt umfaßt. Unicode-Zeichen werden normalerweise mit "U+xxxx" dargestellt, wobei xxxx der hexadezimale Code des Zeichens ist.

Jedes Zeichen ist unabhängig von der Sprache 16 Bit (2 Byte) groß. Obwohl die sich ergebenden 65000 Codeelemente zur Codierung der meisten Zeichen der wichtigsten Sprachen der Welt ausreichen, bietet der Unicode-Standard außerdem einen Erweiterungsmechanismus, mit dem bis zu einer Million weiterer Zeichen codiert werden können. Diese Erweiterung reserviert einen Bereich von Codewerten (U+D800 bis U+D8FF, als "Ersatzzeichen" bezeichnet) zum Codieren einiger 32-Bit-Zeichen als zwei aufeinanderfolgende Codeelemente.

Der Standard 10646 (ISO/IEC 10646) der International Standards Organization (ISO) und der International Electrotechnical Commission (IEC) definiert den Universalzeichensatz Universal Multiple-Octet Coded Character Set (UCS), von dem es eine 2-Byte- (UCS-2) und eine 4-Byte-Version (UCS-4) gibt. Die 2-Byte-Version dieses ISO-Standards entspricht Unicode ohne Ersatzzeichen. ISO 10646 definiert außerdem eine Erweiterungstechnik zum Codieren einiger UCS-4-Codes in einer mit UCS-2 codierten Zeichenfolge. Diese Erweiterung wird als UTF-16 bezeichnet und entspricht Unicode mit Ersatzzeichen.

DB2 UDB unterstützt UCS-2, d. h. Unicode ohne Ersatzzeichen.

Die Verbindung eines UTF-8-Clients (Codepage 1208) zu einer Nicht-Unicode-Datenbank wird nicht unterstützt.

UTF-8

Bei der UCS-2- oder Unicode-Codierung sind ASCII- und Steuerzeichen ebenfalls zwei Byte lang, und das führende Byte ist Null. Zum Beispiel ist NULL gleich U+0000 und das große A gleich U+0041. Dies könnte für ASCII-basierte Anwendungen und ASCII-Dateisysteme ein größeres Problem sein, weil in einer UCS-2-Zeichenfolge fremde Nullen an beliebigen Stellen in der Zeichenfolge auftreten können. Mit einem Umsetzungsalgorithmus, der als UTF-8 bezeichnet wird, kann dieses Problem für Programme umgangen werden, die sich darauf verlassen, daß ASCII-Code invariant ist.

UTF-8 (UCS Transformation Format 8) ist eine algorithmische Umsetzung, mit der UCS-4-Zeichen mit fester Länge in Bytefolgen variabler Länge umgesetzt werden. In UTF-8 werden ASCII-Zeichen durch ihren gewöhnlichen Einzelbytecode dargestellt. Andere Zeichen in UCS-2 sind jedoch zwei oder drei Byte lang. UTF-8 setzt UCS-2-Zeichen also in einen Mehrbyte-Zeichensatz um, für den ASCII unveränderlich ist. Die Anzahl von Byte für jedes UCS-2-Zeichen im UTF-8-Format ist der folgenden Tabelle zu entnehmen:

    UCS-2 (hex)     UTF-8 (binär)                  Beschreibung
    ------------    --------------------------     ----------------
    0000 - 007F     0xxxxxxx                       ASCII
    0080 - 07FF     110xxxxx 10xxxxxx              bis U+07FF
    0800 - FFFF     1110xxxx 10xxxxxx 10xxxxxx     weitere UCS-2
 
    HINWEIS: Der Bereich D800 bis DFFF ist von der Behandlung durch
             die dritte Zeile dieser Tabelle auszunehmen, die
             den UCS-4-Bereich 0000 0800 bis 0000 FFFF betrifft.

Im oben aufgeführten Angaben entspricht eine Reihe von x der UCS-Bitdarstellung des Zeichens. U0080 wird beispielsweise in 11000010 10000000 umgesetzt.

UCS-2-/UTF-8-Implementierung in DB2 UDB

Nummern von Codepages/IDs für codierten Zeichensatz

Bei IBM wurde die UCS-2-Codepage als Codepage 1200 registriert. Alle Codepages werden mit wachsenden Zeichensätzen definiert, d. h. beim Hinzufügen von neuen Zeichen zu einer Codepage ändert sich die Nummer der Codepage nicht. Codepage 1200 verweist immer auf die aktuelle Version von Unicode/UCS-2 und wird für UCS-2-Unterstützung in DB2 UDB verwendet.

Eine spezifische Version des UCS-Standards, wie durch Unicode 2.0 und ISO/IEC 10646-1 definiert, wurde auch bei IBM als ID für codierten Zeichensatz (CCSID) 13488 registriert. Diese ID für codierten Zeichensatz wird intern von DB2 UDB zum Speichern von Grafikzeichenfolgen in euc-Japan- und euc-Taiwan-Datenbanken verwendet. Die ID für codierten Zeichensatz 13488 und die Codepage 1200 verweisen beide auf UCS-2 und werden auf dieselbe Weise behandelt mit Ausnahme des Werts ihres "Doppelbyte"-Leerzeichens (DBCS):

     CP/CCSID        Einzelbyte-Leerzeichen        Doppelbyte-Leerzeichen
    ---------        ------------------------      ------------------------
      1200                   N/V                           U+0020
      13488                  N/V                           U+3000
 
    HINWEIS: In einer UCS-2-Datenbank hat U+3000 keine spezielle Bedeutung.

Bei Umsetzungstabellen werden die gleichen Tabellen (Implikation) für beide verwendet, da Codepage 1200 eine Implikation der ID für codierten Zeichensatz 13488 ist.

Bei IBM wurde UTF-8 als ID für codierten Zeichensatz 1208 mit wachsendem Zeichensatz registriert (manchmal auch als Codepage 1208 bezeichnet). Wenn neue Zeichen zum Standard hinzugefügt werden, ändert sich diese Nummer (1208) nicht. Diese Nummer 1208 wird als Nummer für die Mehrbyte-Codepage für die DB2-Unterstützung von UCS-2/UTF-8 verwendet.

DB2 UDB unterstützt UCS-2 als neue Mehrbyte-Codepage. Die MBCS-Codepage-Nummer ist 1208. Dies ist die Codepage-Nummer der Datenbank und die Codepage von Zeichenfolgedaten in der Datenbank. Die Doppelbyte-Codepage-Nummer für UCS-2 ist 1200. Dies ist die Codepage von Grafikzeichenfolgedaten in der Datenbank. Wenn eine Datenbank in UCS-2/UTF-8 erstellt wird, werden CHAR-, VARCHAR-, LONG VARCHAR- und CLOB-Daten in UTF-8 und GRAPHIC-, VARGRAPHIC-, LONG VARGRAPHIC- und DBCLOB-Daten in UCS-2 gespeichert. Dies wird hier einfach als UCS-2-Datenbank bezeichnet.

Erstellen einer UCS-2-Datenbank

Standardmäßig werden Datenbanken in der Codepage der Anwendung erstellt, die sie erstellt. Wenn Sie daher Ihre Datenbank von einem UTF-8-Client erstellen (z. B. länderspezifische Angaben UNIVERSAL von AIX) oder wenn die Registrierungsvariable DB2CODEPAGE auf dem Client auf 1208 gesetzt ist, wird Ihre Datenbank als UCS-2-Datenbank erstellt. Alternativ dazu können Sie explizit "UTF-8" als Namen für einen codierten Zeichensatz angeben und jeden gültigen aus zwei Buchstaben bestehenden Gebietscode verwenden, der von DB2 UDB unterstützt wird.

Setzen Sie z. B. den folgenden Befehl ab, um eine UCS-2-Datenbank mit dem Gebietscode für die Vereinigten Staaten zu erstellen:

   DB2 CREATE DATABASE dbname USING CODESET UTF-8 TERRITORY US

Zum Erstellen einer UCS-2-Datenbank mit der API sqlecrea sollten Sie die Werte in sqledbcountryinfo entsprechend setzen. Setzen Sie z. B. SQLDBCODESET auf den Wert UTF-8 und SQLDBLOCALE auf einen gültigen Gebietscode (z. B. US).

Die Standardsortierfolge für eine UCS-2-Datenbank ist IDENTITY, die die UCS-2-Codepunkt-Reihenfolge bereitstellt. Daher werden standardmäßig alle UCS-2-/UTF-8-Zeichen gemäß ihrer UCS-2-Codepunktfolge geordnet und verglichen.

Alle länderspezifischen Parameter wie Datums- oder Uhrzeitformat, Dezimaltrennzeichen u. a. basieren auf dem aktuellen Gebiet des Clients.

Eine UCS-2-Datenbank erlaubt Verbindungen von jeder Einzelbyte- und Mehrbyte-Codepage, die von DB2 UDB unterstützt wird. Codepage-Zeichenumsetzungen zwischen der Codepage des Clients und UTF-8 werden automatisch vom Datenbankmanager durchgeführt. Daten in Grafikzeichenfolgetypen sind immer in UCS-2 und erfahren keine Codepage-Umsetzungen. Die Umgebung des Befehlszeilenprozessors (CLP) ist eine Ausnahme. Wenn Sie mit einer SELECT-Anweisung Grafikzeichenfolgedaten (UCS-2) über den Befehlszeilenprozessor auswählen, werden die zurückgegebenen Grafikzeichenfolgedaten (vom Befehlszeilenprozessor) von UCS-2 in die Codepage Ihrer Client-Umgebung umgesetzt.

Jeder Client ist durch die Menge von Zeichen, die Eingabemethode und die von seiner Umgebung unterstützten Schriftarten beschränkt. Die UCS-2-Datenbank selbst jedoch akzeptiert und speichert alle UCS-2-Zeichen. Jeder Client arbeitet also mit einer Untergruppe von UCS-2-Zeichen, der Datenbankmanager läßt jedoch die Gesamtheit von UCS-2-Zeichen zu.

Wenn Zeichen von einer lokalen Codepage in UTF-8 umgesetzt werden, wird möglicherweise die Byteanzahl erweitert. Es gibt keine Erweiterung für ASCII-Zeichen, aber andere UCS-2-Zeichen werden um einen Faktor von zwei oder drei erweitert. Die Byteanzahl für jedes UCS-2-Zeichen im UTF-8-Format kann anhand der Tabelle in UTF-8 bestimmt werden.

Datentypen

Alle von DB2 UDB unterstützten Datentypen werden auch in einer UCS-2-Datenbank unterstützt. Insbesondere Grafikzeichenfolgedaten werden für eine UCS-2-Datenbank unterstützt und in UCS-2/Unicode gespeichert. Jeder Client, einschließlich Clients mit SBCS-Zeichensatz, kann mit Grafikzeichenfolgedatentypen in UCS-2/Unicode arbeiten, wenn er mit einer UCS-2-Datenbank verbunden ist.

Eine UCS-2-Datenbank ist wie jede beliebige MBCS-Datenbank, bei der die Zeichenfolgedaten in der Anzahl von Byte gemessen werden. Beim Arbeiten mit Zeichenfolgedaten in UTF-8 sollte nicht davon ausgegangen werden, daß jedes Zeichen ein Byte lang ist. Bei UTF-8-Mehrbytecodierung ist jedes ASCII-Zeichen ein Byte lang, andere Zeichen nehmen jedoch je zwei oder drei Byte ein. Dies sollte beim Definieren von CHAR-Feldern berücksichtigt werden. Je nach Verhältnis von ASCII-Zeichen zu anderen Zeichen kann ein CHAR-Feld der Größe von n Byte zwischen n/3 bis n Zeichen enthalten.

Die Verwendung von UTF-8-Zeichenfolgecodierung statt dem UCS-2-Grafikzeichenfolgedatentyp wirkt sich ebenfalls auf die Gesamtspeicheranforderungen aus. Wenn die Mehrheit der Zeichen ASCII-Zeichen sind und einige andere Zeichen dazwischenstehen, kann das Speichern von UTF-8-Daten die günstigere Alternative sein, da der Speicherbedarf eher einem Byte pro Zeichen entspricht. Wenn dagegen die Mehrheit der Zeichen keine ASCII-Zeichen sind, die auf 3 Byte lange UTF-8-Folgen erweitert werden (z. B. Ideogramme), ist das UCS-2-Grafikzeichenfolgeformat möglicherweise die bessere Alternative, da jedes UCS-2-Zeichen genau zwei Byte statt drei Byte für jedes entsprechende Zeichen im UTF-8-Format benötigt.

In MBCS-Umgebungen operieren SQL-Skalarfunktionen, die mit Zeichenfolgen arbeiten, z. B. LENGTH, SUBSTR, POSSTR, MAX, MIN u. ä., mit der Anzahl von "Byte" statt mit der Anzahl von "Zeichen". Das Verhalten ist in einer UCS-2-Datenbank gleich. Sie sollten jedoch besonders vorsichtig sein, wenn Sie relative Positionen und Längen für eine USC-2-Datenbank angeben, da diese Werte immer im Kontext der Datenbank-Codepage definiert werden. Im Fall einer UCS-2-Datenbank sollten diese relativen Positionen daher in UTF-8 definiert werden. Da einige Einzelbytezeichen in UTF-8 mehr als ein Byte benötigen, sind SUBSTR-Indizes, die für eine Einzelbyte-Datenbank gültig sind, möglicherweise für eine UCS-2-Datenbank nicht gültig. Wenn Sie falsche Indizes angeben, wird SQLCODE-Wert -191 (SQLSTATE 22504) zurückgegeben. Eine Beschreibung der Arbeitsweise dieser Funktionen finden Sie im Handbuch SQL Reference.

SQL-Datentypen CHAR werden in Benutzerprogrammen vom Datentyp char (in der Programmiersprache C) unterstützt. SQL-Datentypen GRAPHIC werden von sqldbchar in Benutzerprogrammen unterstützt. Bei einer UCS-2-Datenbank sind sqldbchar-Daten immer im Big-endian-Format (hohes Byte zuerst). Wenn ein Anwendungsprogramm mit einer UCS-2-Datenbank verbunden ist, werden Zeichenfolgedaten zwischen der Codepage der Anwendung und UTF-8 durch DB2 UDB umgesetzt, Grafikzeichenfolgedaten bleiben jedoch immer in UCS-2.

Bezeichner

In einer UCS-2-Datenbank sind alle Bezeichner im UTF-8-Mehrbyteformat. Es ist daher möglich, jedes UCS-2-Zeichen in Bezeichnern zu verwenden, bei denen die Verwendung eines Zeichens im erweiterten Zeichensatz (z. B. ein Zeichen mit Akzent oder ein Mehrbytezeichen) von DB2 UDB zugelassen wird. Informationen darüber, welche Bezeichner die Verwendung erweiterter Zeichen zulassen, finden Sie in Anhang A, Namenskonventionen.

Clients können alle Zeichen eingeben, die von ihrer SBCS- oder MBCS-Zeichensatzumgebung unterstützt werden. Alle Zeichen in den Bezeichnern werden vom Datenbankmanager in UTF-8 umgesetzt. Zwei Punkte müssen beim Angeben von Zeichen der Landessprache in Bezeichnern für eine UCS-2-Datenbank beachtet werden:

UCS-2-Literale

UCS-2-Literale können auf zwei Arten angegeben werden:

Bei Verwendung des Befehlszeilenprozessors (CLP) ist die erste Methode einfacher, wenn das UCS-2-Zeichen in der Codepage der lokalen Anwendung vorhanden ist (z. B. zur Eingabe von Zeichen der Codepage 850 von einem Terminal, das Codepage 850 verwendet). Die zweite Methode sollte für Zeichen verwendet werden, die außerhalb des Umfangs der Codepage der Anwendung liegen (z. B. zum Angeben von japanischen Zeichen von einem Terminal, das Codepage 850 verwendet).

Mustererkennung in einer UCS-2-Datenbank

Mustererkennung ist ein Bereich, in dem sich vorhandene MBCS-Datenbanken leicht von einer UCS-2-Datenbank unterscheiden.

MBCS-Datenbanken in DB2 UDB verhalten sich wie folgt: Wenn der Übereinstimmungsausdruck MBCS-Daten enthält, kann das Muster sowohl SBCS- als auch MBCS-Zeichen enthalten. Die Sonderzeichen im Muster werden folgendermaßen interpretiert:

Wenn der Übereinstimmungsausdruck DBCS-Grafikzeichenfolgedaten enthält, enthalten die Ausdrücke nur DBCS-Zeichen. Die Sonderzeichen im Muster werden folgendermaßen interpretiert:

In einer UCS-2-Datenbank gibt es keine echte Unterscheidung zwischen "Einzelbyte"- und "Doppelbyte"-Zeichen. Jedes UCS-2-Zeichen nimmt zwei Byte ein. Obwohl das UTF-8-Format eine "Mischbyte"-Codierung von UCS-2-Zeichen ist, gibt es in UTF-8 keine echte Unterscheidung zwischen SBCS- und MBCS-Zeichen. Jedes Zeichen ist ein UCS-2-Zeichen, unabhängig von der Anzahl seiner Byte im UTF-8-Format. Bei der Angabe eines Zeichenfolge- oder Grafikzeichenfolgeausdrucks verweist ein Unterstrich auf ein UCS-2-Zeichen und ein Prozentzeichen auf eine Zeichenfolge von null oder mehr UCS-2-Zeichen.

Auf der Client-Seite verwenden die Zeichenfolgeausdrücke die Codepage des Clients und werden vom Datenbankmanager in UTF-8 umgesetzt. SBCS-Codepages von Clients haben keine DBCS-Prozentzeichen oder -Unterstriche. Jede unterstützte Codepage enthält jedoch ein Einzelbyte-Prozentzeichen (entspricht U+0025) und einen Einzelbyte-Unterstrich (entspricht U+005F). Sonderzeichen werden in einer UCS-2-Datenbank folgendermaßen interpretiert:

DBCS-Codepages unterstützen außerdem ein DBCS-Prozentzeichen (entspricht U+FF05) und einen DBCS-Unterstrich (entspricht U+FF3F). Diese Zeichen haben für eine UCS-2-Datenbank keine besondere Bedeutung.

Für den wahlfreien "Escape-Ausdruck", der ein Zeichen angibt, das verwendet wird, um die spezielle Bedeutung des Unterstrichs und des Prozentzeichens aufzuheben, werden nur ASCII-Zeichen oder Zeichen unterstützt, die in eine UTF-8-Doppelbytefolge erweitert werden. Wenn Sie ein Escape-Zeichen angeben, das in einen 3 Byte langen UTF-8-Wert erweitert wird, wird eine Fehlermeldung (SQL0130N, SQLSTATE 22019) zurückgegeben.

Überlegungen zu IMPORT/EXPORT/LOAD

Die Dateiformate DEL, ASC und PC/IXF werden für eine UCS-2-Datenbank gemäß der Beschreibung in diesem Abschnitt unterstützt. Das Format WSF wird nicht unterstützt.

Beim Export von einer UCS-2-Datenbank in eine ASCII-DEL-Datei werden alle Zeichendaten in die Codepage der Anwendung umgesetzt. Sowohl Zeichenfolge- als auch Grafikzeichenfolgedaten werden in dieselbe SBCS- oder MBCS-Codepage des Clients umgesetzt. Dies ist die für den Export erwartete Funktionsweise von Datenbanken und kann nicht geändert werden, weil die gesamte ASCII-DEL-Datei nur eine Codepage haben kann. Wenn Sie also in eine ASCII-DEL-Datei exportieren, werden nur die UCS-2-Zeichen gespeichert, die in der Codepage Ihrer Anwendung vorhanden sind. Andere Zeichen werden durch die Standardsubstitutionszeichen für die Codepage der Anwendung ersetzt. Bei UTF-8-Clients (Codepage 1208) entsteht kein Datenverlust, weil alle UCS-2-Zeichen von UTF-8-Clients unterstützt werden.

Beim Importieren aus einer ASCII-Datei (DEL oder ASC) in eine UCS-2-Datenbank werden Zeichenfolgedaten aus der Codepage der Anwendung in UTF-8 und Grafikzeichenfolgedaten aus der Codepage der Anwendung in UCS-2 umgesetzt. Es entsteht kein Datenverlust. Wenn Sie ASCII-Daten importieren wollen, die unter einer anderen Codepage gespeichert wurden, sollten Sie die Codepage der Datendatei ändern, bevor Sie den Befehl IMPORT absetzen. Eine Möglichkeit hierzu besteht darin, DB2CODEPAGE auf die Codepage der ASCII-Datendatei zu setzen.

Der Bereich gültiger ASCII-Begrenzer für SBCS- und MBCS-Clients ist identisch mit dem derzeit von DB2 UDB für diese Clients unterstützten Bereich. Der Bereich gültiger Begrenzer für UTF-8-Clients ist 0x01 bis 0x7F mit den üblichen Einschränkungen. Eine vollständige Liste dieser Einschränkungen finden Sie im Anhang zu Dateiformaten für die Dienstprogramme IMPORT/EXPORT/LOAD im Handbuch Versetzen von Daten Dienstprogramme und Referenz.

Beim Export aus einer UCS-2-Datenbank in eine PC/IXF-Datei werden alle Zeichenfolgedaten in die SBCS-/MBCS-Codepage des Clients umgesetzt. Grafikzeichenfolgedaten werden nicht umgesetzt und in UCS-2 (Codepage 1200) gespeichert. Es entsteht kein Datenverlust.

Beim Importieren aus einer PC/IXF-Datei in eine UCS-2-Datenbank wird bei Zeichenfolgedaten davon ausgegangen, daß sie in der in den PC/IXF-Kopfdaten gespeicherten SBCS-/MBCS-Codepage vorliegen, und bei Grafikzeichenfolgedaten, daß sie in der in den PC/IXF-Kopfdaten gespeicherten DBCS-Codepage vorliegen. Zeichenfolgedaten werden vom Importdienstprogramm von der in den PC/IXF-Kopfdaten angegebenen Codepage in die Codepage des Clients und dann (von der Anweisung INSERT) von der Codepage des Clients in UTF-8 umgesetzt. Grafikzeichenfolgedaten werden vom Importdienstprogramm von der in den PC/IXF-Kopfanweisung angegebenen DBCS-Codepage direkt in UCS-2 (Codepage 1200) umgesetzt.

Das Dienstprogramm LOAD setzt die Daten direkt in die Datenbank und geht standardmäßig davon aus, daß Daten in ASC- oder DEL-Dateien in der Codepage der Datenbank vorliegen. Es findet daher standardmäßig keine Codepage-Umsetzung für ASCII-Dateien statt. Wenn die Codepage für die Datendatei explizit (mit dem codepage-Wert) angegeben wurde, verwendet das Dienstprogramm LOAD diese Information zum Umsetzen der Daten aus der angegebenen Codepage in die Codepage der Datenbank, bevor es die Daten lädt. Bei PC/IXF-Dateien konvertiert das Dienstprogramm LOAD immer von den in den IXF-Kopfdaten angegebenen Codepages in die Codepage der Datenbank (1208 für CHAR und 1200 für GRAPHIC).

Die Codepage für DBCLOB-Dateien ist immer 1200 für UCS-2. Die Codepage von CLOB-Dateien entspricht der Codepage der importierten, geladenen oder exportierten Datendateien. Beim Laden oder Importieren von Daten mit dem Format PC/IXF wird beispielsweise angenommen, daß die CLOB-Datei in der in den PC/IXF-Kopfdaten angegebenen Codepage vorliegt. Wenn die DBCLOB-Datei das Format ASC oder DEL hat, nimmt das Dienstprogramm LOAD an, daß CLOB-Daten in der Codepage der Datenbank vorliegen (sofern dies nicht explizit mit dem codepage-Wert anders angegeben wird), während das Importdienstprogramm annimmt, daß die Daten in der Codepage der Client-Anwendung vorliegen.

Der nochecklengths-Wert wird für eine UCS-2-Datenbank aus folgenden Gründen immer angegeben:

Weitere Informationen über die Dienstprogramme LOAD, IMPORT und EXPORT finden Sie im Handbuch Versetzen von Daten Dienstprogramme und Referenz.

Inkompatibilitäten

Für Anwendungen, die mit einer UCS-2-Datenbank verbunden sind, sind die Grafikzeichenfolgedaten immer in UCS-2 (Codepage 1200). Für Anwendungen, die mit Nicht-UCS-2-Datenbanken verbunden sind, haben die Grafikzeichenfolgedaten die DBCS-Codepage der Anwendung oder sind unzulässig, wenn die Codepage der Anwendung SBCS ist. Wenn z. B. ein 932-Client mit einer japanischen Nicht-UCS-2-Datenbank verbunden ist, haben die Grafikzeichenfolgedaten die Codepage 301. Für die 932-Client-Anwendungen, die mit einer UCS-2-Datenbank verbunden sind, sind die Grafikzeichenfolgedaten in UCS-2.


[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]