Folgende Themen werden behandelt:
In diesem Dokument stellt die Notation vr die aus zwei Zeichen bestehende ICU-Versionsnummer dar.
In ICU werden verschiedenste Datentabellen verwendet, um vielfältige Dienste zur Verfügung zu stellen, beispielsweise Converter-Abbildungstabellen, Collationsregeln, Transliterationsregelen, Regeln für Umbruch-Iteratoren und Diktionäre und sonstige Locale-Daten. Die ICU Data Library für Natural wird als Paket (Package) zur Verfügung gestellt, das die gewünschten Datenelemente enthält. Die Verwendung von Paketen anstelle von einzelnen Datenelementdateien steigert die Performance, weil während der Initialisierung nur ein Dateizugriff zum Laden des Pakets erfolgt. Es ist jedoch nicht so flexibel, denn es erfordert einen Rebuild des Pakets, wenn Datenelemente hinzugefügt werden müssen.
Die ICU Data Library kann kundenspezifisch angepasst werden, um existierende oder neue Converter-Abbildungstabellen oder um andere Datenelemente, z.B. Collationsregeln, Regeln für Umbruch-Iteratoren und sonstige Locale-Daten hinzuzufügen.
Das Tool für die kundenspezifische Anpassung der ICU Data Library kann aus dem Download Components-Bereich in Empower (https://empower.softwareag.com/) heruntergeladen werden. Benutzen Sie die mitgelieferte icudtvr.zip-Datei (vr = Version), um die Data Libraries für die ICU-Version anzupassen, die in Ihrer Natural-Umgebung erforderlich ist: Für ICS Version 2.2 ist icudt58.zip erforderlich. Die in diesem Abschnitt beschriebenen Dateien sind in der icudtvr.zip-Datei enthalten.
Um ein neues ICU Data Library Package zu erstellen, sind mehrere Schritte erforderlich. Einige davon werden auf einem PC durchgeführt, andere auf der zugehörigen Großrechner-Plattform.
Folgende Themen werden behandelt:
Für neue Datenelemente gibt es verschiedene Quellen:
Der ICU Data Library Customizer auf http://apps.icu-project.org/datacustom/.
Das ICU Converter Data Archive auf http://source.icu-project.org/repos/icu/data/trunk/charset/data/ucm/.
Benutzerdefinierte Converter-Abbildungstabellen.
Der ICU Data Library Customizer ist ein web-basiertes Tool, das
von IBM zur Verfügung gestellt wird. Für jede unterstützte Version ist ein ICU
Data Library Customizer verfügbar. Die ICU-Version kann mit Hilfe der
SYSCP-Utility
festgestellt werden (siehe Funktion
ICU
Information).
Der Data Library Customizer zeigt die Datenelemente in einer Baumstrukturansicht an. Zunächst sind alle Datenelemente als ausgewählt markiert. Man kann alle Elemente zusammen abwählen, indem man die Advanced-Option erweitert und die Schaltfläche wählt.
Die Menge der angezeigten Elemente kann reduziert werden, wenn man
bei den Advanced-Optionen die Schaltfläche
wählt. Um zum Beispiel die
Baumstrukturansicht so einzuschränken, dass nur Elemente für Japanisch
angezeigt werden, muss man die Zeichenkette japanese in das
Texteingabefeld eingeben und die Schaltfläche wählen. Danach können mehrere Elemente ausgwählt oder
abgewählt werden. Alle ausgwählten Elemente werden später zur ausgelieferten
ICU Data Library hinzugefügt und stehen dann für Natural zur Verfügung.
Die zweite Möglichkeit besteht darin, für den gewünschten Converter eine (Source) Mapping-Datendatei .ucm zu übernehmen oder zu erstellen. Das ICU-Team unterhält ein umfangreiches Archiv mit Converter-Daten. Dieses Archiv ist versionsunabhängig. Falls die gewünschte Konvertierungstabelle nicht im Archiv vorhanden ist, kann man sich eine neu erstellen. Das Layout von Converter Mapping-Tabellen (.ucm-Dateien) ist im Kapitel Conversion Data im ICU User Guide dokumentiert, siehe http://userguide.icu-project.org/conversion/data. Es wird empfohlen, aus dem Archiv eine ähnliche Mapping-Tabelle zu kopieren und sie an die neuen Erfordernisse anzupassen.
Anmerkung:
Es ist untersagt, die Zeichenabbildung eines existierenden
Converters zu ändern. Tatsächlich handelt es sich dabei um das Erstellen eines
neuen Converters, was die Vergabe eines neuen Namens erfordert, um
Verwechslungen zu vermeiden.
Ausführliche Informationen zur kundenspezifischen Anpassung der ICU Data Library finden Sie in der Datei readme.txt, die Teil der heruntergeladenen zip-Datei ist.
Converter-Quelldateien werden mit dem Tool makeconv.exe in binäre Converterdateien (.cnv-Dateien) kompiliert. Es ist möglich, mehr als einen Converter anzugeben:
Beispiel:
| Kommando | Beschreibung |
|---|---|
makeconv ibm-1142_P100-1997.ucm |
Kompiliert die dänische Zeichenabbildungstabelle der Codepage IBM-1142 in das binäre Format. In einem anschließenden Schritt kann die Ausgabedatei ibm-1142_P100-1997.cnv zu dem neuen Data Library-Paket hinzugefügt werden. |
Converters, die vom ICU übernommen werden, sind bereits in der
Tabelle der Aliasnamen registriert. Falls die Converter-Source-Datei eine
benutzerdefinierte Datei ist, existiert noch kein zugehöriger Name in der
Tabelle der Aliasnamen. In diesem Fall müssen Sie die neue Codepage in der
Tabelle der Aliasnamen registrieren. Öffnen Sie die Textdatei
convrtrs.txt und fügen Sie einen entsprechenden Eintrag am
Ende der Datei im Abschnitt "User defined code
pages" (benutzerdefinierte Codepages) hinzu. Der Name der
Codepage muss angegeben werden, die Angabe des IANA-Namens ist optional. Die
Zeichenkette { IANA* } deklariert
iana-name als IANA-Namen. Für jede
benutzerdefinierte Codepage muss ein Eintrag in der Tabelle der Aliasnamen
vorgenommen werden.
Der Eintrag hat folgendes Format:
name-of-code-page iana-name { IANA* }
Wenn die Codepage "my_cp-100" mit dem IANA-Namen "MYCP" hinzugefügt werden soll, ist in convrts.txt die folgende Zeile erforderlich:
my_cp-100 MYCP { IANA*}
Weitere Informationen finden Sie im Kopfdatenbereich der Datei convrtrs.txt oder im ICU User Guide.
Die geänderte Tabelle muss mit gencnval.exe in eine binäre Datei (cnvalias.icu) kompiliert werden, um sie dann mit dem neuen Data Library-Paket zu verlinken.
Ein neues Data Library-Paket wird mit dem Tool makpkg.bat erstellt. Es benutzt das gelieferte Paket icudtvr.dat (vr = Version) und sortiert neue, benutzerdefinierte Elemente ein. Ein benutzerdefiniertes Element kann ein zusätzliches Paket sein, das neue Datenelemente enthält, ein einzelnes Datenelement, z.B. ein neuer Converter (.cnv-Datei), oder eine Textdatei, die eine Liste neuer Elemente enthält.
Beispiele:
| Kommando | Beschreibung |
|---|---|
makepkg icudtvrl.dat |
Fügt die Datenelemente, die in icudtvrl.dat enthalten sind, zum Basispaket icudtvrb.dat hinzu. |
makepkg ibm-1142_P100-1997.cnv |
Fügt die dänsiche Codepage IBM-1142 zum Basis-Data-Library-Paket icudtvrb.dat hinzu. |
makepkg newitems.txt |
Fügt alle Datenelemente (Converters), die in der Textdatei newitems.txt aufgeführt sind, zum Basis-Data-Library-Paket icudtvrb.dat hinzu. |
makepkg.bat erzeugt zwei Dateien: eine
Big-Endian EBCDIC-basierte binäre Datei und eine HL Assembler Source. Die
Assembler Source enthält das binäre Abbild der ersten Datei, gepackt in
DC X'...'-Statements. Der Name der binären Datei
icudtvre.dat und der Name der Assembler Source ist
icudtvre_dat.s. Die Datei icudtvre
ist eine Kopie von icudtvre_dat.s. Die Dateien dürfen
niemals umbenannt werden, weil der Paketname
"icudtvre" als
Bestandteil interner Referenzen bei Datenelementen verwendet wird. Sie wird von
der ICU Runtime für den Zugriff auf Datenelemente, z.B. Converters, und zum
Validieren der Datendatei benutzt. "icudt"
identifiziert die Datei als Big-Endian EBCDIC-kodiert.
Wenn mehr als ein Element hinzugefügt werden soll oder wenn die Tabelle der Aliasnamen geändert worden ist, müssen die Elemente als Liste in der Datei newitems.txt deklariert werden.
Beispiele:
Hinzufügen der Codepages ibm-939_P120-1999 und
ibm-942_P12A-1999
Einträge in newitems.txt:
ibm-939_P120-1999.cnv
ibm-942_P12A-1999.cnv
Hinzufügen der benutzerdefinierten Codepage
my_cp-100
Einträge in newitems.txt:
cnvalias.icu
my_cp-100.cnv
Weitere Informationen siehe ICU User Guide.
Das Ergebnis der vorangegangen Schritts ist ein Assembler-Modul. Das Assembler-Modul mit dem neuen Data Library-Paket icudtvre muss auf die Zielplattform übertragen werden. Das File Transfer Protocol (FTP) ist auf jedem PC vorhanden und kann für diesen Zweck benutzt werden. Wenden Sie sich an den Systemadministrator wegen der Informationen (z.B. Host-Name, Port-Nummer, Benutzername und Passwort), die Sie benötigen, um Zugang zur Zielmaschine über FTP zu erhalten. Da es sich bei icudtvre um eine Textdatei handelt, muss der Transfermodus auf ASCII gesetzt werden, um die korrekte Umsetzung der Datei auf der Zielplattform sicherzustellen. Der Name der Datei auf der Zielplattform kann frei gewählt werden. Es wird jedoch empfohlen, den Namen icudtvre zu verwenden. Falls eine Umbenennung der Datei icudtvre gewünscht wird, muss das Tool renamepkg.bat benutzt werden.
Das Assembler-Source-Modul muss auf der Zielplattform assembliert
und gelinkt werden. Es kann entweder mit dem Nukleus verlinkt oder dynamisch
geladen werden mit RCA=name und
CFICU=(DATFILE=name).
In diesem Abschnitt sind die Natural-Profilparameter und Parameter-Makros aufgeführt, die im Zusammenhang mit der Unicode- und Codepage-Unterstützung benutzt werden.
Falls nicht anderes angegeben ist, werden die in diesem Abschnitt erwähnten Profilparameter und Makros in der Parameter-Referenz-Dokumentation ausführlich beschrieben.
| Parameter oder Makro | Beschreibung |
|---|---|
CFICU oder Makro
NTCFICU
|
Aktiviert die Unicode-Unterstützung für
verschiedene Unicode-Einstellungen.
Siehe auch |
CMPO oder
Schlüsselwort-Subparameter CPAGE des Makros
NTCMPO |
Generiert codepage-sensitive
Natural-Programme.
Siehe auch |
CP |
Definiert die Standard-Codepage für
Natural.
Diese Codepage wird für die Laufzeit- und die Entwicklungsumgebung benutzt, falls die Angabe nicht mit einer Codepage überschrieben wird, die für ein einzelnes Objekt (z.B. ein Natural-Quellcode-Objekt) definiert ist. Es können nur Codepages benutzt werden, die zur Plattform passen. Das bedeutet, dass für eine Großrechner-Plattform keine ASCII-Codepage definiert werden kann. Falls eine falsche Codepage benutzt wird, erscheint bei der Initialisierung eine Fehlermeldung. Siehe auch |
CPCVERR |
Gibt an, ob eine Fehlermeldung angezeigt
wird, wenn ein Umsetzungsfehler bei folgenden Umsetzungen auftritt: von Unicode
nach Codepage oder von Codepage nach Unicode oder von einer Codepage in eine
andere Codepage.
Dieser Parameter wird nicht bei der Umsetzung von Natural-Sourcen berücksichtigt, wenn diese in den Editierbereich geladen oder katalogisiert werden. Es wird nicht berücksichtigt, ob ein Unicode-Feld vor
einer Eingabe/Ausgabe über eine Terminalemulation in die Codepage umgesetzt
wird. In diesem Fall wird das durch ICU definierte Ersatzzeichen durch das in
|
CPOBJIN |
Dient zur Angabe der Codepage, in der die
Batch-Eingabedatei codiert ist. Diese Datei ist im Dataset CMOBJIN
definiert.
|
CPPRINT |
Dient zur Angabe der Codepage, in der die
Batch-Ausgabedatei codiert ist. Diese Datei ist im Dataset CMPRINT
definiert.
|
CPSYNIN |
Dient zur Angabe der Codepage, in der die
Batch-Eingabedatei für Kommandos codiert ist. Diese Datei ist im Dataset
CMSYNIN definiert.
|
NTCPAGE-Makro
|
Dieses Makro definiert im Modul
NATCONFG
eine Codepage und alle zugehörigen Informationen, z.B. Platzhalterzeichen,
Locale ID und Collation Tables.
Siehe auch Makro
|
OPRB oder
NTOPRB-Makro
|
Dient zum Setzen der Optionen
ACODE und/oder WCODE zur Definition der
Benutzer-Zeichencodierung, wenn die benutzte Adabas-Datenbank für Universal
Encoding Support (UES) freigegeben ist.
|
PRINT oder
CP-Schlüsselwort-Parameter im Makro
NTPRINT |
Definiert die Codepage für einen Report. |
SRETAIN |
Dient zur Angabe, dass alle existierenden Quellcodee in ihrem Original-Zeichencodierungsformat gespeichert werden müssen. Siehe auch Kundenspezifische Anpassung Ihrer Umgebung. |
Siehe auch:
Natural in Batch Mode in der Operations-Dokumentation.
Informationen zu gültigen Codepages siehe http://www.iana.org/assignments/character-sets.
Folgende Themen werden behandelt:
Eine ausführliche Beschreibung des Profilparameters
CFICU und seiner
Schlüsselwort-Subparameter befindet sich in der
Parameter-Referenz-Dokumentation. Einige der
Schlüsselwort-Subparameter haben Einfluß auf die Performance.
Wenn Collation Services zum Vergleichen von Unicode-Zeichenketten
benutzt werden, werden beide Zeichenketten untersucht, ob sie normalisiert sind
oder nicht. Die Prüfung selbst verbraucht viel CPU-Zeit. Wenn Sie sicher sind,
dass die Zeichenketten bereits normalisiert sind, können Sie die Prüfung
ausschalten (COLNORM=OFF).
In Unicode ist es möglich, dasselbe Zeichen als einen Codepoint
oder als eine Kombination von zwei oder mehr Codepoints darzustellen.
Beispielsweise kann das deutsche Zeichen "ä" durch
"U+00E4" oder durch die Kombination der Codepoints
"U+0061" und "U+0308"
dargestellt werden. Bei der Umwandlung von Unicode nach beispielsweise IBM01140
werden Zeichen als einzelne Codepoints behandelt, d.h. es wird ein
"a" gefolgt von einem Ersatzzeichen erzeugt, weil
der Codepoint "U+0308" in der Ziel-Codepage nicht
repräsentiert ist. Die Einstellung
CNVNORM=ON
bewirkt, dass vor der eigentlichen Umwandlung eine Normalisierung durchgeführt
wird. Die Umwandlung verbraucht zusätzliche CPU-Zeit und Zwischenspeicherplatz.
Wenn Sie sicher sind, dass bei MOVE-Statements (außer
MOVE
NORMALIZED) keine zusammengesetzten Zeichen beteiligt sind,
sollten Sie CNVNORM auf OFF setzen, um die
Performance zu verbessern. Beachten Sie, dass alle möglichen Kombinationen
durch einen einzeln kodierten Unicode-Codepoint repräsentiert werden.
Die Umwandlung von Unicode in Codepage und umgekehrt erfordert
keine hohe Leistung. Dies liegt daran, dass die ICU-Implementierung in C++
geschrieben ist, das nahezu alle Unicode-, Codepage- und Sprachenaspekte in der
Welt abdeckt. Manche Codepages können jedoch über Umsetzungstabellen
(Translation Tables) in Unicode (und umgekehrt) abgebildet werden, um die
Umwandlung zu beschleunigen. Mit dem Schlüsselwort-Subparameter
CPOPT
des Profilparameters CFICU werden zur Beschleunigung
Accelerator Tables aktiviert. Ist der Subparameter auf ON gesetzt,
erstellt Natural unter Benutzung von ICU-Konvertierungsfunktionen bei der
Session-Initialisierung zwei Accelerator Tables. Die erste Tabelle (mit einer
Größe von 512 Bytes) wird für die Umwandlung von Codepage in Unicode und die
andere Tabelle (mit einer Größe von 65535 Bytes) für die Umwandlung von Unicode
in Codepage benutzt. Während der Natural-Session werden dann alle Umwandlungen
über Accelerator Tables statt mit ICU-Aufrufen ausgeführt. Accelerator Tables
werden nur für die Standard-Codepage (*CODEPAGE)
verfügbar gemacht. Temporäre Codepages (z.B. in
MOVE
ENCODED-Statements) benutzen keine Accelerator Tables, wenn
das Modul NATCPTAB nicht verlinkt ist. Wenn es verlinkt ist,
werden bis zu 30 auf der ICU-Datenbank basierende Accelerator Tables benutzt,
um die Performance zu beschleunigen.
Die Profilparameter CFICU und
CP können Sie
benutzen, um Natural für bestimmte Zwecke anzupassen:
| Einstellungen | Beschreibung |
|---|---|
CFICU=OFF,
CP=OFF |
Kompatibilitätsmodus, um existierende
Anwendungen ohne Unicode- und ohne Codepage-Unterstützung auszuführen.
Für die Umsetzung der Ein- und Ausgaben werden
herkömmliche Umsetzungstabellen verwendet. Im Vergleich zu früheren Versionen
tritt kein signifikanter Ressourcenverbrauch (CPU-Zeit und Puffernutzung) auf.
In diesem Modus braucht das ICS-Modul |
CFICU=ON,
CP=OFF |
Für neue Anwendungen, bei denen
Unicode- und Codepage-Umwandlung (MOVE ENCODED), aber
keine Standard-Codepage-Unterstützung verwendet wird. Deshalb ist die
Systemvariable *CODEPAGE
leer.
Es ist möglich, Variablen im Format U zu benutzen, aber
es ist nicht möglich, z.B. |
CFICU=ON,
CP=value * |
Für neue Anwendungen, bei denen vollständige Unicode- sowie Codepage-Unterstützung verwendet wird. |
CFICU=OFF,
CP=value * |
Diese Kombination ist nicht sinnvoll,
weil zur Codepage-Unterstüzung ICU Services für die Umwandlung benötigt werden.
Deshalb wird in diesem Fall die Einstellung CFICU=ON erzwungen und
bei der Session-Initialisierung eine Meldung ausgegeben.
|
* dabei ist value ein
beliebiger Wert ungleich OFF.
Die Compiler-Option CPAGE erstellt
Objekte, die mit einer anderen Codepage als die zur Erstellungszeit verwendete
Codepage ausgeführt werden können. Das bedeutet, dass alle alphanumerischen
Konstanten des Objekts, die in der zur Erstellungszeit verwendete Codepage
kodiert sind, in die Codepage umgesetzt werden müssen, die zur Ausführungszeit
aktiv ist. Um es dem Natural Object Loader zu ermöglichen, alphanumerische
Konstanten zu finden und umzusetzen, wird vom Compiler eine zusätzliche Tabelle
erstellt. Dadurch nimmt die Größe des generierten Objekts in Abhängigkeit von
der Anzahl der verwendeten alphanumerischen Konstanten zu. Die Umwandlung zur
Laufzeit verbraucht zusätzliche CPU-Zeit. Wenn die Standard-Codepage (Wert der
Systemvariablen *CODEPAGE)
dieselbe ist wie die zur Erstellungszeit verwendete Codepage oder wenn die
Session keine Standard-Codepage hat (CP=OFF), wird keine
Umwandlung durchgeführt. Unabhängig von der Einstellung des Profilparameters
CPCVERR
werden Umsetzungsfehler ignoriert. Wenn die Compiler-Option CPAGE
auf OFF gesetzt ist, wird zur Laufzeit keine Umwandlung
durchgeführt und die alphanumerischen Konstanten werden so behandelt, wie sie
sind.
Das folgende Beispiel-Programm ist mit der Codepage IBM01141 (German) katalogisiert und wird mit der Standard-Codepage IBM01140 (us) ausgeführt. Die Zeichen "Ä", "Ö" und "Ü" sind in beiden Codepages definiert, jedoch an verschiedenen Codepoints.
Beispiel 1 - CPAGE=OFF:
OPTIONS CPAGE=OFF WRITE *CODEPAGE 'ÄÖÜ' END
Ausgabe mit Codepage IBM01140 (us):
Page 1
IBM01140 ¢\!
Beispiel 2 - CPAGE=ON:
OPTIONS CPAGE=ON WRITE *CODEPAGE 'ÄÖÜ' END
Ausgabe mit Codepage IBM01140 (us):
Page 1 IBM01140 ÄÖÜ
Am gebräuchlichsten für Codepage-Namen ist der IANA-Name. Deshalb
enthält die Systemvariable *CODEPAGE
den IANA-Namen der Standard-Codepage. Bei z/VSE and z/OS wird eine Codepage
durch ihre Coded Character Set ID (CCSID) qualifiziert. Bei BS2000 ist der
Coded Character Set Name (CCSN) am weitesten verbreitet. Adabas verwendet
zurzeit die Entire Conversion Service Definition (ADAECS).
Das Parameter-Makro
NTCPAGE
kann benutzt werden, um diese verschiedenen Namen zu dem eindeutigen IANA-Namen
zuzuweisen. NTCPAGE ist Teil des Natural-Konfigurationsmoduls
(NATCONFG).
Es spielt keine Rolle, ob der IANA-Name, die CCSID/CCSN oder der Aliasname beim
Profilparameter CP angeben wird. Der Aliasname kann ein
benutzerdefinierter Name sein, der verwendet wird, um der Codepage einen
aussagefähigeren Namen zuzuweisen. In jedem Fall enthält die Systemvariable
*CODEPAGE den IANA-Namen der gewählten
Codepage.
Zusätzlich kann für eine Codepage ein Platzhalterzeichen definiert
werden. Es überschreibt das Standard-Ersatzzeichen der betreffenden Codepage,
das nomalerweise ein nicht anzeigbarers Zeichen ist (z.B. H’3F’ in
einer EBCDIC-Codepage). Das Platzhalterzeichen kann benutzt werden, um zu
vermeiden, dass nicht anzeigbarer Zeichen an Terminals gesendet werden.
Beispiel:
NTCPAGE IANA=IBM01140,CCSID=1140,ECS=1140,ALIAS=’US’,PHC=003F
Die Werte IBM01140, 1140 oder
US können mit dem Profilparameter CP
eingegeben werden, um die Codepage zu aktivieren. Die Systemvariable
*CODEPAGE
enthält den Namen IBM01140. Das Ersatzzeichen der Codepage wird durch
"U+003F" ersetzt, was ein Fragezeichen (?) ist
Die Anzahl der verfügbaren Codepages ist abhängig von der verwendeten ICU Data Library.
Alle im zurzeit verwendeten Datenpaket definierten Codepages
können von Natural benutzt werden. Ein Eintrag in NTCPAGE ist nur
nötig, wenn ein alternativer Aliasname oder ein alternatives Platzhalterzeichen
gewünscht wird.
Beim Natural Development Server (NDV) steht der folgende Konfigurationsparameter zur Verfügung:
| Einstellung | Beschreibung |
|---|---|
TERMINAL_EMULATION=WEBIO
|
Gibt an, welcher Natural Web I/O Interface Client (der Unicode unterstützt) für die Ein- und Ausgabe benutzt wird. |
Die Codepage-Information des Objekts ist Teil des
Objektverzeichnisses, das mit dem Systemkommando
LIST
angezeigt werden kann. Weitere Informationen siehe
Directory-Informationen
anzeigen in der
Systemkommandos-Dokumentation.
Die Zeichenkodierung von Codepage-Daten kann auf verschiedenen Ebenen angegeben werden:
Die Standard-Codepage kann mit dem Natural-Profilparameter
CP (Name der
Standard-Codepage) angegeben werden.
Eine Codepage kann angegeben werden für:
Natural-Quellcode-Objekte, Batch-Eingabedateien (CPOBJIN - Codepage
der Batch-Eingabedatei, CPSYNIN - Codepage
der Batch-Eingabedatei für Kommandos) und Ausgabedateien (CPPRINT - Codepage
der Batch-Ausgabedatei).
Die Definition einer Codepage auf der Objektebene ist maßgeblich für das betreffende Objekt und hat dort Vorrang vor der Standard-Codepage.