Unicode-/Codepage-Umgebung konfigurieren und verwalten

#### Search Results

Search

# Unicode-/Codepage-Umgebung konfigurieren und verwalten

Folgende Themen werden behandelt:

- ICU Data Library kundenspezifisch einrichten

- Natural-Profilparameter und Parameter-Makros

- Information zur Zeichencodierung

#### Notation vr:

In diesem Dokument stellt die Notation vr die aus zwei Zeichen bestehende ICU-Versionsnummer dar.

## ICU Data Library kundenspezifisch einrichten

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:

- Neue Datenelemente beschaffen

- Konvertierungstabellen und Locales kompilieren

- Neues Data Library-Paket erstellen

- Assembler Source auf die Großrechner-Plattform übertragen

- Neue Data Library auf der Ziel-Großrechner-Plattform benutzen

### Neue Datenelemente beschaffen

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 Deselect All wählt.

Die Menge der angezeigten Elemente kann reduziert werden, wenn man bei den Advanced-Optionen die Schaltfläche Filter Items 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 Filter Items wählen. Danach können mehrere Elemente ausgewählt oder abgewählt werden. Alle ausgewä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.

### Konvertierungstabellen und Locales kompilieren

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.

### Neues Data Library-Paket erstellen

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.

### Assembler Source auf die Großrechner-Plattform übertragen

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.

### Neue Data Library auf der Ziel-Großrechner-Plattform benutzen

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)`.

## Natural-Profilparameter und Parameter-Makros

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 `CFICU`-Parameter und `CFICU` and `CP`: Session-Modi
`CMPO` oder Schlüsselwort-Subparameter `CPAGE` des Makros `NTCMPO` | Generiert codepage-sensitive Natural-Programme. Siehe auch `CPAGE`-Compiler-Option.
`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 `CFICU` and `CP`: Session-Modi.
`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 `NATCONFG` definierte Platzhalterzeichen ersetzt.
`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 `NTCPAGE`. `NTCPAGE` und `NATCONFG` werden ausführlich in der Operations-Dokumentation behandelt.
`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 Quellcode-Objekte 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:

- Profilparameter CFICU

- CFICU und CP: Session-Modi

- Compiler-Option CPAGE

- Parameter-Makro NTCPAGE

- Natural Development Server (NDV)

### Profilparameter CFICU

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 Einfluss 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.

### CFICU und CP: Session-Modi

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 `SAGICU` (oder ein alternatives ICS-Modul) nicht mit dem Natural-Nukleus verlinkt zu sein.
`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. `MOVE A TO U` zu benutzen, weil dafür die Standard-Codepage-Information erforderlich ist. Der Fehler NAT3411 wird ausgegeben, um anzuzeigen, dass keine Standard-Codepage verfügbar ist.
`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`.

### Compiler-Option CPAGE

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                                                         ÄÖÜ

### Parameter-Makro NTCPAGE

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/OS wird eine Codepage durch ihre Coded Character Set ID (CCSID) qualifiziert. 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 normalerweise 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.

### Natural Development Server (NDV)

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.

## Information zur Zeichencodierung

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.

### Ebene 1 - Standard-Codepage

Die Standard-Codepage kann mit dem Natural-Profilparameter `CP` (Name der Standard-Codepage) angegeben werden.

### Ebene 2 - Codepage für ein einzelnes Objekt

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.

### On this page

- ICU Data Library kundenspezifisch einrichten
- Natural-Profilparameter und Parameter-Makros
- Information zur Zeichencodierung