Ein Gebietsschema ist ein Satz von Informationen, die sprachliche und kulturelle Anforderungen für eine bestimmte Sprache und ein bestimmtes Land enthalten. Normalerweise bieten die mit einem Gebietsschema verknüpften Daten Unterstützung für Formatierung und Analyse von Datums-, Uhrzeit-, Zahlen- und Währungsangaben usw. Die Bereitstellung aktueller und korrekter Gebietsschemadaten lag in der Vergangenheit in der Verantwortung der einzelnen Plattformbesitzer oder -verkäufer, was zu Inkonsistenzen und Fehlern bei Gebietsschemadaten führte.

Das Festlegen der NLS_LANG-Umgebungsparameter ist die einfachste Möglichkeit, das Gebietsschemaverhalten für Software von Oracle anzugeben. Hiermit werden Sprache und Gebiet festgelegt, die von der Clientanwendung und dem Datenbankserver verwendet werden. Außerdem ist auch der Clientzeichensatz angegeben, der dem Zeichensatz für Daten entspricht, die von einem Clientprogramm eingegeben oder angezeigt werden sollen.

NLS_LANG wird auf UNIX-Plattformen als lokale Umgebungsvariable festgelegt. NLS_LANG wird in der Registry auf Windows-Plattformen festgelegt.

Der Parameter NLS_LANG besteht aus drei Komponenten: Sprache, Gebiet und Zeichensatz. Geben Sie dies einschließlich der Interpunktion im folgenden Format an:
NLS_LANG = language_territory.charset

Jede Komponente des NLS_LANG-Parameters steuert den Betrieb einer Teilmenge der Funktionen zur Unterstützung der Globalisierung:

Language
Gibt Konventionen an, z. B. die Sprache für Oracle Nachrichten, Sortierung, Tages- und Monatsnamen. Jede unterstützte Sprache hat einen eindeutigen Namen, wie z. B.: AMERICAN, FRENCH oder GERMAN. Das Sprachargument gibt Standardwerte für die Gebiets- und Zeichensatzargumente an. Wenn die Sprache nicht angegeben ist, wird standardmäßig AMERICAN verwendet.

Territory
Gibt Konventionen wie das Standardformat für Datum, Geld und Zahlen an. Jedes unterstützte Gebiet hat einen eindeutigen Namen, wie z. B.: AMERICA, FRANCE oder CANADA. Wenn das Gebiet nicht angegeben ist, wird der Wert aus dem Sprachwert abgeleitet.

Charset
Gibt den von der Clientanwendung verwendeten Zeichensatz an (normalerweise der Oracle Zeichensatz, der dem Terminal- oder OS-Zeichensatz des Benutzers entspricht). Jeder unterstützte Zeichensatz hat ein eindeutiges Akronym, z. B. US7ASCII, WE8ISO8859P1, WE8DEC, WE8MSWIN1252 oder JA16EUC. Jeder Sprache ist ein Standardzeichensatz zugeordnet.

Hinweis:

Alle Komponenten der NLS_LANG -Definition sind optional. Jedes Element, das nicht angegeben wird, verwendet seinen Standardwert. Wenn Sie ein Gebiet oder einen Zeichensatz angeben, müssen Sie das vorangestellte Trennzeichen [Unterstrich (_) für das Gebiet, Punkt (.) für den Zeichensatz] einfügen. Andernfalls wird der Wert als Sprachenname analysiert.

Verwenden Sie beispielsweise das folgende Format, um nur den Gebietsabschnitt von NLS_LANG festzulegen: NLS_LANG=_JAPAN

Der Rest dieses Dokuments konzentriert sich auf die Zeichensatzkomponente der NLS_LANG-Einstellung, da dies das am wenigsten verstandene und wichtigste Element ist, das richtig eingestellt werden muss.

• Das Festlegen von NLS_LANG auf den Zeichensatz der Datenbank KANN richtig sein, häufig IST es jedoch falsch. Gehen Sie NICHT davon aus, dass NLS_LANG mit dem Datenbankzeichensatz identisch sein muss. DAS IST HÄUFIG NICHT WAHR.
• Der mit dem Parameter NLS_LANG definierte Zeichensatz ändert Ihren Clientzeichensatz NICHT. Dies wird verwendet, um Oracle mitzuteilen, welchen Zeichensatz Sie auf der Clientseite verwenden, damit Oracle die richtige Konvertierung durchführen kann. Sie können den Zeichensatz Ihres Clients nicht mit anderen NLS_LANG-Werten ändern!
• Wenn Sie NLS_LANG nicht auf dem Client festlegen, wird die NLS_LANG des Servers verwendet. Das ist auch NICHT wahr! Wenn das Oracle Installationsprogramm beispielsweise NLS_LANG nicht ausfüllt und es nicht anderweitig festgelegt ist, lautet der Wert standardmäßig AMERICAN_AMERICA.US7ASCII. Die Sprache ist AMERICAN, das Gebiet ist AMERICA und der Zeichensatz ist US7ASCII.
• Das Festlegen der Parameter LANGUAGE und TERRITORY von NLS_LANG hat nichts mit der Möglichkeit zu tun, Zeichen in einer Datenbank zu speichern. Wenn NLS_LANG auf JAPANESE_JAPAN.WE8MSWIN1252 gesetzt ist, können Sie Japanisch nicht speichern, da WE8MSWIN1252 keine japanischen Zeichen unterstützt. Mit NLS_LANG (AMERICAN_AMERICA.JA16SJIS) können Sie jedoch Japanisch speichern, vorausgesetzt, die Eingabedaten sind wirklich JA16SJIS und dass die Datenbank auch in einem Zeichensatz vorliegt, der Japanisch speichern kann, wie z. B. UTF8 oder JA16SJIS.

In vielen Fällen wurde NLS_LANG bereits während der Installation von Oracle oder danach manuell festgelegt. Um sicherzugehen, können Sie diese Methoden verwenden, um den Wert von NLS_LANG für SQL*Plus zurückzugewinnen:

Unter UNIX:

Dies gibt den Wert des Parameters zurück.

Unter Windows:
Unter Windows haben Sie zwei Möglichkeiten. Normalerweise wird NLS_LANG in der Registry festgelegt, es kann jedoch auch in der Umgebung festgelegt werden. Dies wird jedoch nicht häufig durchgeführt. Der Wert in der Umgebung hat Vorrang vor dem Wert in der Registry und wird für ALLE Oracle_Homes auf dem Server verwendet. Beachten Sie außerdem, dass jede USER-Umgebungsvariable beim Festlegen Vorrang vor jeder SYSTEM-Umgebungsvariablen hat (dies ist Windows-Verhalten und hat nichts mit Oracle zu tun)

So überprüfen Sie, ob dies in der Umgebung festgelegt ist:

Wenn dies nur %NLS_LANG% zurückgibt, ist die Variable nicht in der Umgebung festgelegt.

Andernfalls wird in etwa Folgendes zurückgegeben

ENGLISH_UNITED KINGDOM.WE8ISO8859P1
Wenn NLS_LANG in der Umgebung nicht festgelegt ist, überprüfen Sie den Wert in der Registry:

Beispiel:
Unable to open file.[ENGLISH_UNITED KINGDOM.WE8ISO8859P1].
Der "Dateiname" zwischen den geschweiften Klammern steht für den Wert des Registry-Parameters.

Wenn Sie
Unable to open file ".[%NLS_LANG%]." als Ergebnis erhalten, ist der Parameter NLS_LANG auch nicht in der Registry festgelegt.

Beachten Sie, dass die @.[%NLS_LANG%].-Technik meldet, dass die NLS_LANG, die der ausführbaren SQL*Plus-Datei bekannt ist, die Registry selbst nicht liest. Wenn Sie jedoch zuerst den HOST-Befehl ausführen und NLS_LANG nicht in der Umgebung festgelegt ist, können Sie sicher sein, dass die Variable in der Registry festgelegt ist, wenn @.[%NLS_LANG%]. einen gültigen Wert zurückgibt.

Alle anderen NLS-Parameter können wie folgt abgerufen werden:

Hinweis:

SELECT USERENV ( 'Sprache') FROM DUAL; gibt <Language>_<territory> der Sitzung zurück, der DATABASE-Zeichensatz legt jedoch den Client nicht fest, sodass der zurückgegebene Wert nicht die vollständige NLS_LANG-Einstellung des Clients ist!

In diesem Abschnitt wird die Reihenfolge erläutert, in der NLS-Parameter im Client/Server-Modell der Datenbank berücksichtigt werden. (Dies gilt NICHT für Thin JDBC-Verbindungen.)

Es gibt 3 Ebenen, auf denen Sie NLS-Parameter festlegen können: Datenbank, Instanz und Sitzung. Wenn ein Parameter auf mehr als einer Ebene definiert ist, sind die Regeln, auf denen er Vorrang hat, recht einfach:

1. 1. NLS-Datenbankeinstellungen werden durch NLS-Instanzeinstellungen ersetzt
2. 2. NLS-Datenbank- und NLS-Instanzeinstellungen werden durch NLS-Sitzungseinstellungen ersetzt

Dies sind die Einstellungen, die für die aktuelle SQL-Sitzung verwendet werden.

Diese geben (in dieser Reihenfolge) Folgendes wieder:

1. 1) Die Werte der NLS-Parameter, die festgelegt werden durch: "ALTER SESSION "
   ALTER SESSION set NLS_DATE_FORMAT = 'DD/MM/YYYY';
2. 2) Wenn keine explizite "ALTER SESSION"-Anweisung ausgeführt wird, wird die Einstellung des entsprechenden NLS-Parameters auf dem Client wiedergegeben, der aus der NLS_LANG-Variablen abgeleitet wurde.
3. 3) Wenn NLS_LANG nur mit diesem Teil angegeben wird, wird standardmäßig AMERICAN verwendet.

   Wenn Sie also NLS_LANG=_BELGIUM. WE8MSWIN1252 festlegen, erhalten Sie Folgendes:

   PARAMETERWERT

   NLS_LANGUAGE AMERICAN
   NLS_TERRITORY BELGIUM
   NLS_CURRENCY <Euro-Zeichen hier>
   NLS_ISO_CURRENCY BELGIUM

   Hinweis:

   Der Unterschied zwischen NLS_LANG=_BELGIUM.WE8MSWIN1252 (korrekt) und

   NLS_LANG=BELGIUM.WE8MSWIN1252 (falsch) liegt im fehlenden Trennzeichen „_“.

4. 4) Wenn NLS_LANG nur mit diesem Teil angegeben wird, wird standardmäßig eine Einstellung basierend auf Folgendem verwendet.

   Wenn Sie also NLS_LANG=ITALIAN_.WE8MSWIN1252 festlegen, erhalten Sie Folgendes:

   PARAMETERWERT

   NLS_LANGUAGE ITALIAN
   NLS_TERRITORY ITALY
   NLS_CURRENCY <Euro-Zeichen hier>
   NLS_ISO_CURRENCY ITALY

   Hinweis:

   Der Unterschied zwischen NLS_LANG=ITALIAN_.WE8MSWIN1252 (korrekt) und

   NLS_LANG=ITALIAN.WE8MSWIN1252 (falsch) liegt im fehlenden Trennzeichen „_“.

5. 5) Wenn NLS_LANG ohne den Teil _ angegeben wird, ist der Teil _ standardmäßig AMERICAN_AMERICA.

   Wenn Sie also NLS_LANG=.WE8MSWIN1252 festlegen, erhalten Sie Folgendes:

   PARAMETERWERT

   NLS_LANGUAGE AMERICAN
   NLS_TERRITORY AMERICA
   NLS_CURRENCY $
   NLS_ISO_CURRENCY AMERICA

   
   
   
   Note:
   
   The difference between NLS_LANG=.WE8MSWIN1252 (correct) and
   
   NLS_LANG=WE8MSWIN1252 (incorrect), you need to set the "." as separator.
   

6. 6) Wenn NLS_LANG festgelegt ist (entweder Punkt 3, 4 oder 5), sind Parameter wie

   NLS_SORT, NLS_DATE_FORMAT usw. als "eigenständige" Einstellung festgelegt und überschreiben die vom NLS_LANG _-Teil abgeleiteten Standardeinstellungen.

   Wenn Sie also NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252 und NLS_ISO_CURRENCY=FRANCE festlegen, erhalten Sie Folgendes:

   PARAMETERWERT

   NLS_LANGUAGE AMERICAN
   NLS_TERRITORY AMERICA
   NLS_CURRENCY $
   NLS_ISO_CURRENCY FRANCE

   Standartwerte:
   * Wenn NLS_DATE_LANGUAGE oder NLS_SORT nicht festgelegt sind, werden sie von
   NLS_LANGUAGE.
   abgeleitet. * Wenn NLS_CURRENCY, NLS_DUAL_CURRENCY, NLS_ISO_CURRENCY, NLS_DATE_FORMAT, NLS_TIMESTAMP_FORMAT, NLS_TIMESTAMP_TZ_FORMAT, NLS_NUMERIC_CHARACTERS nicht festgelegt sind, werden sie von NLS_TERRITORY abgeleitet.

7. 7) Wenn NLS_LANG überhaupt nicht gesetzt ist, lautet der Standardwert

   <Language>_<Territory>.US7ASCII und die Werte für den
   <Language>_<Territory>-Teil werden aus den

   NLS_INSTANCE_PARAMETERS entnommen. Parameter wie NLS_SORT, die clientseitig als "eigenständig" definiert sind, werden ignoriert.

   
   
   Note:
   
   * If set, client parameters (NLS_SESSION_PARAMETERS) always take precedence over NLS_INSTANCE_PARAMETERS and NLS_DATABASE_PARAMETERS.
   
   * This behavior cannot be disabled on/from the server, so a parameter set on the client always has precedence above an instance or database parameter.
   
   * NLS_LANG cannot be changed by ALTER SESSION, NLS_LANGUAGE and NLS_TERRITORY can. However NLS_LANGUAGE and /or NLS_TERRITORY cannot be set as "standalone" parameters in the environment or registry on the client.
   
   * NLS_SESSION_PARAMETERS is NOT visible for other sessions. If you need to trace this then you have to use a logon trigger to create your own logging table (based on session parameters)
   
   * The <clients characterset> part of NLS_LANG is NOT shown in any system table or view.
   
   * On Windows you have two possible options, normally the NLS_LANG is set in the registry, but it can also be set in the environment, however this is not often done and generally not recommended to do so. The value in the environment takes precedence over the value in the registry and is used for ALL Oracle_Homes on the server if defined as a system environment variable.
   
   * NLS_LANGUAGE in the session parameters also declares the language for the client error messages.
   
   * You cannot "set" a NLS parameter in an SQL script; you need to use ALTER SESSION.
   

Dies sind die Einstellungen in der init.ora der Datenbank zum Zeitpunkt des Starts oder der Einstellung der Datenbank über ALTER SYSTEM.

Wenn der Parameter nicht explizit in der init.ora festgelegt oder von ALTER SYSTEM definiert wurde, wird sein Wert NICHT von einem "höheren" Parameter abgeleitet. (Es handelt sich um Parameter wie NLS_SORT, die einen Standardwert von NLS_LANGUAGE in NLS_SESSION_PARAMETERS ableiten. Dies ist NICHT der Fall für NLS_INSTANCE_PARAMETERS.)

Note:

* NLS_LANG is not an init.ora parameter; NLS_LANGUAGE and NLS_TERRITORY are so you need to set NLS_LANGUAGE and NLS_TERRITORY separately.

* You cannot define the  or NLS_LANG in the init.ora

The client characterset is defined by the NLS_LANG on the client OS (see above).

* You cannot define the database characterset in the init.ora. The database characterset is defined by the "Create Database" command.

* These settings take precedence above the NLS_DATABASE_PARAMETERS.

* These values are used for the NLS_SESSION_PARAMETERS if the client the

NLS_LANG is NOT set.

* Oracle strongly recommends that you set the NLS_LANG on the client at least to

NLS_LANG=.<clients characterset>

* The NLS_LANGUAGE in the instance parameters also declares the language for the server error messages in alert.log and in trace files.

Der Standardwert ist AMERICAN_AMERICA, wenn während der Datenbankerstellung in init.ora keine expliziten Parameter festgelegt wurden. Wenn während der Datenbankerstellung in der init.ora Parameter festgelegt wurden, sehen Sie diese hier. Es gibt keine Möglichkeit, diese nach der Datenbankerstellung zu ändern. Versuchen Sie NICHT, Systemtabellen zu aktualisieren, um diese Einstellungen zu umgehen! Diese Einstellungen werden verwendet, um der Datenbank einen Standard zu geben, wenn die Parameter INSTANCE und SESSION nicht festgelegt sind.

Hinweis:

* NLS_LANG ist kein init.ora-Parameter, NLS_LANGUAGE und NLS_TERRITORY sind dies jedoch.

Daher müssen Sie NLS_LANGUAGE und NLS_TERRITORY separat festlegen.

* Diese Parameter werden von NLS_INSTANCE_PARAMETERS und NLS_SESSION_PARAMETERS überschrieben.

* Sie können <clients character set> oder NLS_LANG nicht in der init.ora definieren. Der Clientzeichensatz wird durch NLS_LANG auf dem Clientbetriebssystem definiert.

* Sie können den Datenbankzeichensatz nicht in der init.ora definieren.

Der (landeseigene) Datenbankzeichensatz NLS_(NCHAR)_CHARACTERSET) wird durch den Befehl "Create Database" definiert.

* Die Parameter NLS_CHARACTERSET und NLS_NCHAR_CHARACTERSET können nicht durch Instanz- oder Sitzungsparameter überschrieben werden.

Sie werden durch den im CREATE DATABASE-Befehl angegebenen Wert definiert und sollen danach nicht dynamisch geändert werden. Aktualisieren Sie die Systemtabellen NICHT, um den Zeichensatz zu ändern. Dies kann Ihre Datenbank beschädigen und möglicherweise das erneute Öffnen der Datenbank unmöglich machen.

* Das Festlegen von NLS_LANG während der Erstellung der Datenbank hat keinen Einfluss auf NLS_DATABASE_PARAMETERS.

* Die während der Datenbankerstellung festgelegte NLS_LANG hat KEINE Auswirkungen auf den Länderzeichensatz der Datenbank.

Weitere SELECT-Anweisungen:
A) SELECT name,value$ from sys.props$, wobei ein Name wie '%NLS%' angegeben wird.
Dies gibt die gleichen Informationen wie NLS_DATABASE_PARAMETERS aus.
Sie sollten NLS_DATABASE_PARAMETERS anstelle von props$ verwenden.
Beachten Sie die Großschreibung bei '%NLS%'

B) SELECT * from v$nls_parameters;
Diese Sicht zeigt die aktuellen Sitzungsparameter und den *DATABASE*-Zeichensatz in der Sicht NLS_DATABASE_PARAMETERS.

C) SELECT name,value from v$parameter, wobei ein Name wie '%NLS%' angegeben wird.
Diese Sicht gibt die gleichen Informationen wie NLS_INSTANCE_PARAMETERS aus.
Beachten Sie die Kleinschreibung bei '%NLS%'

D) SELECT userenv ('language') from dual;
und
SELECT sys_context('userenv','language') from dual;
Beide SELECT-Anweisungen geben den _ der Sitzung und den
DATABASE-Zeichensatz an. Der Datenbankzeichensatz stimmt nicht mit dem Zeichensatz des NLS_LANG überein, mit dem Sie diese Verbindung gestartet haben! Lassen Sie sich nicht täuschen, auch wenn die Ausgabe dieser Abfrage wie der Wert einer NLS_LANG-Variablen aussieht, ist dies NICHT der Fall.

E) SELECT userenv ('lang') from dual;
Diese SELECT-Anweisung gibt den Funktionscode an, den Oracle für die Sprache verwendet, die in der NLS_LANGUAGE-Einstellung für diese Sitzung definiert ist. Wenn NLS_LANGUAGE auf Französisch gesetzt ist, wird "F" zurückgegeben. Wenn NLS_LANGUAGE auf Englisch eingestellt ist, wird "GB" zurückgegeben.
Wenn NLS_LANGUAGE auf Amerikanisch eingestellt ist, wird "US" zurückgegeben usw...

F) SHOW parameter NLS%
Dies ergibt dasselbe wie NLS_INSTANCE_PARAMETERS

Auf einem UNIX-System wird eine Datenbank mit dem Zeichensatz US7ASCII erstellt. Ein Windows-Client, der eine Verbindung zur Datenbank herstellt, verwendet den Zeichensatz WE8MSWIN1252 (regionale Einstellungen –> Westeuropa/ACP 1252) und DBA sowie die UNIX-Shell (ROMAN8) zur Funktion mit der Datenbank. NLS_LANG ist auf den Clients und dem Server auf american_america.US7ASCII eingestellt.

Note:

This is an INCORRECT setup to explain character set conversion, don't use it in your environment!

Ein sehr wichtiger Punkt (wie bereits erwähnt):

Wenn für den NLS_LANG-Zeichensatz des Clients derselbe Wert wie für den Datenbankzeichensatz festgelegt ist, geht Oracle davon aus, dass die gesendeten oder empfangenen Daten dieselbe (korrekte) Codierung aufweisen, sodass aus Performance-Gründen keine Konvertierungen oder Überprüfungen auftreten können. Die Daten werden so gespeichert, wie sie vom Client geliefert wurden, Stück für Stück.

Unter Windows fügen Sie ein ‘é’ (Lateinischer Kleinbuchstabe E mit Akut) in eine Tabelle NLS_TEST ein, die eine Spalte ‘TEST’ vom Typ 'char' enthält.

Solange Sie unter Windows mit dem Zeichensatz WE8MSWIN1252 in die Spalte einfügen und aus dieser auswählen, funktioniert alles reibungslos. Es wird keine Konvertierung durchgeführt und 8 Bits werden eingefügt und zurückgelesen, selbst wenn der Zeichensatz der Datenbank als 7 Bits definiert ist. Dies geschieht, weil ein Byte 8 Bits umfasst und Oracle IMMER 8 Bits verwendet, auch wenn ein 7-Bit-Zeichensatz vorhanden ist. Bei einer korrekten Einstellung wird das höchstwertige Bit einfach nicht verwendet und nur 7 Bits werden berücksichtigt.

Wenn Sie vom UNIX-Server einfügen müssen. Wenn Sie mit SELECT aus Tabellen auswählen, in die Daten von Windows-Clients eingefügt wurden, erhalten Sie ein ‘Ò’ (Lateinischer Großbuchstabe O mit Tilde) anstelle von ‘é’.

Wenn Sie auf dem UNIX-Server ‘é’ einfügen und die Zeile per SELECT auf dem Windows-Client auswählen, erhalten Sie ein ‘Å’ (Lateinischer Großbuchstabe A mit Ring oben).

Dies alles sorgt jedoch für INKORREKTE Daten in der Datenbank. Sie speichern den numerischen Wert für 'é' des WE8MSWIN1252-Zeichensatzes in der Datenbank, aber Sie sagen Oracle, dass es sich um US7ASCII-Daten handelt. Somit konvertiert Oracle nichts und speichert nur den numerischen Wert (nochmals: Oracle denkt, dass der Client US7ASCII-Codes gibt da NLS_LANG auf US7ASCII eingestellt ist und der Datenbankzeichensatz ebenfalls US7ASCII ist -> es wird keine Konvertierung durchgeführt).

Wenn Sie dieselbe Spalte wieder auf dem UNIX-Server per SELECT auswählen, erwartet Oracle erneut, dass der Wert korrekt ist, und übergibt den Wert ohne Konvertierung an das UNIX-Terminal.

Jetzt besteht das Problem darin, dass ‘é’ im WE8MSWIN1252-Zeichensatz den hexadezimalen Wert 'E9' hat, und im Roman8-Zeichensatz hat ‘é’ den Hexadezimalwert 'C5'. Oracle übergibt nur den in der Datenbank gespeicherten Wert ('E9') an das UNIX-Terminal, und das UNIX-Terminal geht davon aus, dass dies das Zeichen ‘?’ ist, da im festgelegten Zeichensatz (Roman8) der Hexadezimalwert 'E9' für den Buchstaben ‘Ò’ steht. Statt des ‘é’ erhalten Sie demnach ein ‘Ò’ auf dem UNIX-Terminal-Bildschirm.

Mit der Umkehrung (die Einfügung unter UNIX und die Auswahl auf dem Windows-Client) verhält es sich genau, jedoch mit anderen Ergebnissen.

Die Lösung besteht darin, die Datenbank mit einem Zeichensatz zu erstellen, der ‘é’ enthält.

(WE8MSWIN1252, WE8ISO89859P1, UTF-8 usw.) und NLS_LANG auf dem Client auf WE8MSWIN1252 und auf dem Server auf WE8ROMAN8 festlegt. Wenn Sie dann auf beiden Seiten ein ‘é’ einfügen, erhalten Sie ein ‘é’, unabhängig davon, wo Sie SELECT ausführen. Oracle weiß dann, dass ein hexadezimaler Wert von 'C5 von UNIX und ein 'E9 von einem WE8MSWIN1252-Client beide ein ‘é’ sind und fügt ‘é’ in die Datenbank ein (der Code in der Datenbank hängt vom gewählten Zeichensatz ab).

Sie müssen nicht zwischen UNIX-, Windows- oder anderen Betriebssystemclients wechseln, um auf diese Art von Problem zu stoßen. Das gleiche Problem tritt auf, wenn Sie Windows-Clients hinzufügen, die einen anderen Zeichensatz verwenden und einen falschen NLS_LANG-Satz haben.

Um das Gebietsschemaverhalten Ihrer Clientsoftware von Oracle festzulegen, müssen Sie Ihren NLS_LANG-Parameter festlegen. Dieser legt die Sprache, das Gebiet und auch den Zeichensatz des Clients fest. Sie müssen die Ländereinstellungen überprüfen, um das dritte NLS_LANG-Feld (Zeichensatz) entsprechend einzustellen. Verwenden Sie dazu den Befehl "locale" wie folgt:

$ locale

Example of output:

LANG=fr_FR 
LC_CTYPE="fr_FR.iso885915@euro" 
LC_COLLATE="fr_FR.iso885915@euro" 
LC_MONETARY="fr_FR.iso885915@euro" 
LC_NUMERIC="fr_FR.iso885915@euro" 
LC_TIME="fr_FR.iso885915@euro" 
LC_MESSAGES="fr_FR.iso885915@euro" 
LC_ALL=fr_FR.iso885915@euro

Die Ausgabe dieses Befehls ist nicht in allen Unix-Umgebungen identisch. Auf einigen Plattformen kann es hilfreich sein, die folgende Syntax zu verwenden, um weitere Details zur tatsächlich verwendeten Codepage zu erhalten:

$ locale LC_CTYPE | head

         Example of output     
         in a HP-UX environment   
         :   

""
  

   


 
 
 
""
  

   


 
 
 
"iso885915"
  

   


 
 
 
""
  

   


 
 
 
          Example of output in a Linux environment:   
  

   


 
 
 
upper;lower;alpha;digit;xdigit;space;print;graph;blank;cntrl;
punct;alnum;
combining;combining_level3 
toupper;tolower;totitle 
16 
1 
ISO-8859-15 
70 
84 
1 
0 

In diesen Fällen sollte das dritte NLS_LANG-Feld auf WE8ISO8859P15 gesetzt werden. Unter Solaris, AIX und TRU64 liefert diese Syntax keine interessanten ergänzenden Informationen. Weitere Details zu diesen Einstellungen finden Sie hier:

Suchen Sie unter Solaris in /usr/lib/locale
Suchen Sie unter AIX in /usr/lib/nls/README
Suchen Sie auf TRU64 in /usr/lib/nls
Suchen Sie unter HP-UX in /usr/lib/nls/config
Suchen Sie unter Linux in /usr/share/locale/locale.alias

Zum Festlegen eines ausgewählten Werts für die "locale"-Einstellungen, müssen Sie wissen, welche Werte verfügbar sind. Verwenden Sie dazu die folgende Syntax:

Wenn Sie dann einen Wert ausgewählt haben, z. B. UTF-8 unter Linux, können Sie diesen folgendermaßen festlegen:

oder

 
Example of output after the setenv:

$ locale 

LANG=fr_FR 
LC_CTYPE="UTF-8" 
LC_NUMERIC="UTF-8" 
LC_TIME="UTF-8" 
LC_COLLATE="UTF-8" 
LC_MONETARY="UTF-8" 
LC_MESSAGES="UTF-8" 
LC_PAPER="UTF-8" 
LC_NAME="UTF-8" 
LC_ADDRESS="UTF-8" 
LC_TELEPHONE="UTF-8" 
LC_MEASUREMENT="UTF-8" 
LC_IDENTIFICATION="UTF-8" 
LC_ALL=UTF-8 

$ locale LC_CTYPE | head 
upper;lower;alpha;digit;xdigit;space;print;

graph;blank;cntrl;punct;alnum;combining;combining_level3 
toupper;tolower;totitle 
16 
6 
UTF-8 
70 
84 
1 
0 
1

In diesem Fall sollte das 3. Feld (Zeichensatz) von NLS_LANG auf UTF8 gesetzt werden.

% setenv NLS_LANG American_America.UTF8

Auf Windows-Systemen wird das Codierungsschema (Zeichensatz) durch eine Codepage angegeben. Codepages werden so definiert, dass sie bestimmte Sprachen oder Sprachgruppen unterstützen, die gemeinsame Schriftsysteme verwenden. Aus der Sicht von Oracle bedeuten die Begriffe Codepage und Zeichensatz dasselbe. Beachten Sie, dass in Umgebungen ohne Chinesisch, Japanisch, Koreanisch die Windows-GUI und die DOS-Eingabeaufforderung nicht dieselbe Codepage verwenden.

Infolgedessen verwendet Windows zwei verschiedene Zeichensätze für die Umgebungen ANSI (sqlplusw.exe) und OEM (dos box – sqlplus.exe).

In der Registry:
Unter Windows-Systemen sollten Sie sicherstellen, dass Sie für jedes Ihrer Oracle Homes einen NLS_LANG-Registry-Unterschlüssel festgelegt haben:
Mit dem Windows Registry-Edito können Sie diesen Unterschlüssel problemlos ändern:
Start -> Ausführen ...
Geben Sie „regedit“ ein und klicken Sie anschließend auf „OK“
Bearbeiten Sie den folgenden Registry-Eintrag:

Für Oracle Version 7:

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE

Für die Oracle Database-Versionen 8, 8i und 9i:

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEx\

wobei "x" für die eindeutige Nummer steht, die das Oracle Home identifiziert.

HOME0 ist die erste Installation

Für Oracle Database 10g:

HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_

Dort finden Sie einen Eintrag mit dem Namen NLS_LANG

Beim Starten eines Oracle Tools wie SQL*Plusw wird der Inhalt der Datei oracle.key gelesen, die sich im selben Verzeichnis befindet, um zu bestimmen, welcher Registry-Baum verwendet wird und somit auch welcher NLS_LANG-Unterschlüssel verwendet wird.

Hinweis:

Einige Benutzer sind verwirrt, wenn sie einen NLS_LANG vorfinden, der in HKEY_LOCAL_MACHINE\SOFTWARE\Oracle auf "NA" festgelegt ist, wenn keine Version 7 installiert war. Dies erfolgt aus Gründen der Abwärtskompatibilität und kann ignoriert werden.

Als System- oder Nutzer-Umgebungsvariable in den Systemeigenschaften:

Die Registry ist zwar das primäre Repository für Einstellungen unter Windows, aber nicht der einzige Ort, an dem Parameter festgelegt werden können. Auch wenn dies nicht empfohlen wird, können Sie NLS_LANG in den Systemeigenschaften als System- oder Nutzer-Umgebungsvariable festlegen.

Diese Einstellung wird für ALLE Oracle Homes verwendet.

So überprüfen und ändern Sie dies:

Klicken Sie mit der rechten Maustaste auf das Symbol 'Arbeitsplatz ->'Eigenschaften'

Wählen Sie die 'Registerkarte „Erweitert“ -> Klicken Sie auf 'Umgebungsvariablen'

Die Liste der 'Nutzer-Variablen enthält die Einstellungen für den aktuell angemeldeten Betriebssystembenutzer und die 'Systemvariablen enthalten systemweite Variablen für alle Benutzer.

Da diese Umgebungsvariablen Vorrang vor den in Ihrer Registry bereits festgelegten Parametern haben, sollten Sie an dieser Stelle keine Oracle Parameter festlegen, es sei denn, Sie haben einen sehr guten Grund.

Als Umgebungsvariable, die in der Eingabeaufforderung definiert ist:

Bevor Sie ein Oracle Befehlszeilentool verwenden können, müssen Sie den NLS_LANG-Parameter MANUELL festlegen. Verwenden Sie an einer MS-DOS-Eingabeaufforderung den Befehl set, zum Beispiel wie folgt:

C:\> set NLS_LANG=american_america.WE8PC850

Nachdem Sie wissen, auf was NLS_LANG momentan eingestellt ist, können Sie überprüfen, ob dies mit der aktuellen ANSI-Codepage übereinstimmt. Die ACP (ANSI-Codepage) wird durch das "Standardgebietsschema" von Windows definiert. Wenn Sie also einen britischen Windows 2000-Client nutzen und Kyrillisch (Russisch) eingeben möchten, müssen Sie die ACP ändern (indem Sie das "Standardgebietsschema" ändern), um Russisch eingeben zu können.

Sie finden den Wert in der Registry:

Start –> Ausführen...

Geben Sie "regedit" ein, und klicken Sie auf "ok"

Durchsuchen Sie den folgenden Registry-Eintrag:

Dort finden Sie (ganz unten) einen Eintrag mit dem Namen ACP. Der Wert von ACP stellt die aktuelle GUI-Codepage für die Zuordnung zum Namen Oracle dar. Da es viele Registry-Einträge mit sehr ähnlichen Namen gibt, vergewissern Sie sich, dass Sie sich an der richtigen Stelle in der Registry befinden.

Darüber hinaus enthält die folgende URL eine Liste der Standardcodepages für alle Windows-Versionen:

http://www.microsoft.com/globaldev/reference/(unter der Registerkarte REFERENZ links auf der Seite)

OEM = die Befehlszeilen-Codepage, ANSI = die GUI-Codepage

Beachten Sie, dass hier Hongkong HKSCS aufgelistet ist: http://www.microsoft.com/hk/hkscs/

Suchen Sie den entsprechenden Oracle Clientzeichensatz:

Suchen Sie den Oracle Clientzeichensatz in der folgenden Tabelle, basierend auf der oben gefundenen ACP. Beachten Sie, dass es für eine bestimmte ACP nur EINEN KORREKTEN Wert gibt.

Dies ist der Zeichensatz, der von der GUI SQL*Plus (sqlplusW.exe/plus80W.exe/plus33W.exe) verwendet wird, die Sie über das Windows-Startmenü starten. Bitte beachten Sie den Unterschied zwischen der GUI SQL*Plus und "DOS-Modus" SQL*Plus.

Sie können UTF8 unter Windows NT, 2000 und XP als Oracle Clientzeichensatz (=NLS_LANG) verwenden. Sie dürfen jedoch nur Clientprogramme verwenden, die diese Konfiguration ausdrücklich unterstützen. Dies liegt daran, dass die Benutzeroberfläche von Win32 nicht UTF8 ist. Daher muss das Clientprogramm explizite Konvertierungen zwischen UTF8 (auf der Seite von Oracle verwendet) und UTF16 (auf der Seite von Win32 verwendet) durchführen.

Legen Sie dies in der Registry fest:

Verwenden Sie den Windows-Registry-Editor, um NLS_LANG in Ihrem Oracle Home mit dem Wert einzurichten, den Sie soeben gefunden haben.

Der MS-DOS-Modus verwendet mit wenigen Ausnahmen wie CJK (Japanisch, Koreanisch, vereinfachtes Chinesisch und traditionelles Chinesisch) eine andere Codepage (als OEM-Codepage bezeichnet) als die Windows-GUI (ANSI-Codepage). Das heißt, bevor Sie ein Oracle Befehlszeilentool wie SQL*Plus (sqlplus.exe/plus80.exe/plus33.exe) und svrmgrl in einer Eingabeaufforderung verwenden, müssen Sie den Parameter NLS_LANG MANUELL als Umgebungsvariable mit dem festgelegten DOS-Wert festlegen, BEVOR Sie das Tool verwenden.

Für Japanisch, Koreanisch, vereinfachtes Chinesisch und traditionelles Chinesisch ist die MS-DOS-OEM-Codepage (CJK) mit der ANSI-Codepage identisch, sodass in diesem speziellen Fall der NLS_LANG-Parameter nicht im MS-DOS-Modus festgelegt werden muss.

In allen anderen Fällen müssen Sie dies festlegen, um den NLS_LANG-Registry-Schlüssel zu überschreiben, der bereits mit der ANSI-Codepage übereinstimmt. Die neue "dedizierte MS-DOS"-NLS_LANG muss mit der MS-DOS-OEM-Codepage übereinstimmen, die durch Eingabe von chcp in einer Eingabeaufforderung abgerufen werden kann:

C:\> chcp

Aktive Codepage: 437

C:\> set NLS_LANG=american_america.US8PC437

Wenn der NLS_LANG-Parameter für die Sitzung im MS-DOS-Modus nicht ordnungsgemäß festgelegt ist, können Fehlermeldungen und Daten aufgrund einer falschen Zeichensatzkonvertierung beschädigt werden.

Verwenden Sie die folgende Liste, um den Oracle Zeichensatz zu finden, der zu Ihrer auf Ihrem Gebietsschemasystem verwendeten MS-DOS-Codepage passt:

Hinweis: Dies ist die richtige Einstellung für die GUI SQL*Plus-Version (sqlplusW.exe/plus80W.exe/plus33W.exe).

Wenn Sie mit "Sonderzeichen" testen, verwenden Sie die GUI und nicht die "DOS-Box" sqlplus.exe!

Hinweis: Dies ist die richtige Einstellung für die DOS-BOX SQL*Plus-Version (sqlplus.exe/plus80.exe/plus33.exe).

Was steuert die LANGUAGE-Komponente des NLS_LANG-Parameters?

Die Sprachkomponente des NLS_LANG-Parameters steuert die Verfahren eines Teils der Funktionen zur Unterstützung der Globalisierung. Sie gibt Konventionen an, z. B. die Sprache für Oracle Nachrichten, Sortierung, Tages- und Monatsnamen. Jede unterstützte Sprache hat einen eindeutigen Namen, wie z. B.: AMERICAN, FRENCH oder GERMAN. Das Sprachargument gibt Standardwerte für die Gebiets- und Zeichensatzargumente an. Wenn die Sprache nicht angegeben ist, wird standardmäßig AMERICAN verwendet.

Was steuert die TERRITORY-Komponente des NLS_LANG-Parameters?

Die Gebietskomponente des NLS_LANG-Parameters steuert die Verfahren eines Teils der Funktionen zur Unterstützung der Globalisierung. Sie gibt Konventionen wie das Standardformat für Datum, Geld und Zahlen an. Jedes unterstützte Gebiet hat einen eindeutigen Namen, wie z. B.: AMERICA, FRANCE oder CANADA. Wenn das Gebiet nicht angegeben ist, wird der Wert aus dem Sprachwert abgeleitet.

Verwenden Sie den Befehl dump, um den realen numerischen Wert für ein in der Datenbank gespeichertes Zeichen zu ermitteln:

Die Syntax des Funktionsaufrufs lautet:

wobei:

value – ist der anzuzeigende Wert

format – ist eine Zahl, die das Format beschreibt, in dem Bytes des Werts angezeigt werden sollen: 8 – bedeutet oktal, 10 – bedeutet dezimal, 16 – bedeutet hexadezimal; andere Werte zwischen 0 und 16 bedeuten dezimal; Werte über 16 sind etwas verwirrend und bedeuten: Ausgabe als ASCII-Zeichen, wenn sie druckbaren ASCII-Codes entsprechen, Ausgabe als "^x", wenn sie ASCII-Steuercodes entsprechen, andernfalls Ausgabe als hexadezimal; durch das Hinzufügen von 1000 zur Formatnummer werden Zeichensatzinformationen für die Zeichendatentypwerte zum Rückgabewertoffset hinzugefügt. Dies ist der Offset des ersten Bytes des anzuzeigenden Werts. Negative Werte zeigen ausgehend von der Endlänge die Anzahl der anzuzeigenden Bytes an. Zum Beispiel:

Typ=1 Len=39 CharacterSet=UTF8: 227,131,143,227,131,170

Gibt den Wert einer Spalte mit 3 japanischen Zeichen in UTF8-Codierung zurück. Zum Beispiel ist das erste Zeichen 227(*255)+131. Sie müssen dies wahrscheinlich in UCS2 konvertieren, um den Codepunktwert mit der Unicode-Standardcodepage zu überprüfen.

Wo wird die Zeichenkonvertierung durchgeführt?

Normalerweise wird die Konvertierung aus Leistungsgründen auf Clientseite durchgeführt. Dies gilt ab Version 8.0.4. Wenn die Datenbank einen Zeichensatz verwendet, der dem Client nicht bekannt ist, erfolgt die Konvertierung serverseitig. Dies gilt ab Version 8.1.6.

Windows SQL*Plus zeigt nicht alle meine erweiterten Zeichen an?

Wenn Sie schwarze Quadrate anstelle der Zeichen sehen, ist wahrscheinlich nicht die richtige Schriftart für Ihre Codepage definiert. Eine Schriftart ist eine Sammlung von Glyphen (von "Hieroglyphen"), die ein gemeinsames Erscheinungsbild haben (Schriftart, Schriftgröße). Eine Schriftart wird vom Betriebssystem verwendet, um einen numerischen Wert in eine grafische Darstellung auf dem Bildschirm umzuwandeln. Eine Schriftart enthält nicht unbedingt eine grafische Darstellung für alle numerischen Werte, die in der verwendeten Codepage definiert sind. Dies ist der Grund, warum Sie manchmal schwarze Quadrate auf dem Bildschirm sehen, wenn Sie die Schriftarten ändern und die neue Schrift für ein bestimmtes Symbol nicht dargestellt wird.

Mit dem Windows-Dienstprogramm "Zeichentabelle" können Sie feststellen, welche Glyphen zu einer bestimmten Schriftart gehören.

Unter Windows 2000 und XP:

Start –> Ausführen...

Geben Sie "Zeichentabelle" ein, und klicken Sie auf "ok".

Ich erhalte ein Fragezeichen oder ein umgekehrtes Fragezeichen, wenn ich ein gerade eingefügtes Zeichen auswähle?

Wenn Zeichen zwischen dem Client- und dem Datenbankzeichensatz konvertiert werden oder umgekehrt, sollte das Zeichen in beiden vorhanden sein. Wenn es im zu konvertierenden Zeichensatz (dem Ziel) nicht vorhanden ist, wird ein Ersatzzeichen verwendet. Bei einigen Zeichensätzen sind bestimmte Ersetzungszeichen definiert, wenn aus anderen bestimmten Zeichensätzen übersetzt wird. Wenn dies jedoch nicht erfolgt, wird ein Standard-Ersetzungszeichen, wie z. B. ein „?“, verwendet. Die Umwandlung eines Ersatzzeichens in das Originalzeichen ist nicht möglich.

Ist iSQL*Plus der einzige UTF8-/Unicode-fähige Client, den wir unterstützen?

Unter Windows ja und unter Unix-Betriebssystemen nein. Alle Datenbankdienstprogramme, einschließlich Import, Export, SQL*Loader, SQL*Plus, können als UTF-8-Client fungieren, wenn das Gebietsschema des Betriebssystems UTF-8 lautet (z. B. en_US.UTF-8 unter Linux) und der Zeichensatz NLS_LANG auf UTF8 festgelegt ist oder AL32UTF8.

Wie überprüfe ich die von einem UNIX-Betriebssystem verwalteten Codepunkte?

Um zu wissen, welcher Codepunkt für ein Zeichen in einer Unix-Umgebung generiert wird, können Sie den "od"-Befehl verwenden:

Sie können das Zeichen, das einem Codepunkt entspricht, auch mit dem "Echo"-Befehl wie folgt überprüfen:

Für Solaris, AIX, HP-UX, TRU64:

Für Linux:

Sie können Locale Builder oder eine gedruckte Codepage (siehe Links unten) verwenden, um zu überprüfen, ob Ihre native Codepage und die NLS_LANG-Einstellung ordnungsgemäß übereinstimmen. Wenn es Unklarheiten gibt, verwenden Sie den obigen Befehl, um die Werte für mehr als ein Zeichen abzurufen. Für gedruckte Codepage:

http://www.unicode.org

http://www.iso.org

http://czyborra.com/charsets/iso8859.html

Normalerweise muss NLS_LANG mit der MS-DOS-OEM-Codepage übereinstimmen, die durch Eingabe von chcp in einer Eingabeaufforderung abgerufen werden kann:

C:\> chcp

Aktive Codepage: 437

C:\> set NLS_LANG=american_america.US8PC437

Für Tools wie SQL*Loader können Sie NLS_LANG vorübergehend in den Zeichensatz der zu ladenden DATEI ändern. Eine Alternative zum Ändern von NLS_LANG besteht darin, den Zeichensatz der Daten in der Datendatei mithilfe des Zeichensatz-Schlüsselworts in der CTL-Datei anzugeben. In diesem Fall interpretiert SQL*Loader die Daten in der Datendatei als diesen Zeichensatz, unabhängig von der Client-Zeichensatzeinstellung von NLS_LANG. Hier ist eine CTL-Beispieldatei für utf16. Dieses Beispiel wird im Demobereich ausgeliefert:

-- Copyright (c) 2001 by Oracle Corporation
--   NAME
--     ulcase11.ctl - Load Data in the Unicode Character Set UTF-16
--   DESCRIPTION
--     Loads data in the Unicode character set UTF-16. The data is in little
--     Endean byte order. This means that depending on whether SQL*Loader is
--     running on a little Endean or a big Endean system, it will have to
--     byte swap the UTF-16 character data as necessary. This load uses
--     character length semantics, the default for the character set UTF-16.
-- 
--     This case study is modeled after case study 3 (ulcase3), which loads
--     variable length delimited (terminated and enclosed) data.
-- 
--   RETURNS
-- 
--   NOTES
--     None
--   MODIFIED   (MM/DD/YY)
--    rpfau     02/06/01  - Merged rpfau_sqlldr_add_case_study_11
--    rpfau     01/30/01 -  Creation
--

LOAD DATA
CHARACTERSET utf16
BYTEORDER little
INFILE ulcase11.dat
REPLACE

INTO TABLE EMP
FIELDS TERMINATED BY X'002c' OPTIONALLY ENCLOSED BY X'0022'
(empno integer external (5), ename, job, mgr,
 hiredate DATE(20) "DD-Month-YYYY",
 sal, comm,
 deptno   CHAR(5) TERMINATED BY ":",
 projno,
 loadseq  SEQUENCE(MAX,1) )
 

In Oracle9i exportiert das Export-Dienstprogramm immer Benutzerdaten, einschließlich Unicode-Daten, in den Zeichensatz der Datenbank. Das Import-Dienstprogramm konvertiert die Daten automatisch in den Zeichensatz der Zieldatenbank.

In Oracle8i exportiert das Export-Dienstprogramm Benutzerdaten, um sie aus dem Datenbankzeichensatz in den Zeichensatz der NLS_LANG der Exportsitzung zu konvertieren. Das Import-Dienstprogramm konvertiert die Daten zuerst in den Zeichensatz der NLS_LANG der Importsitzung und konvertiert sie dann in den Zeichensatz der Zieldatenbank. Es muss darauf geachtet werden, dass der Zeichensatz der NLS_LANG für Export- und Importsitzungen alle zu migrierenden Zeichen enthält. Dieser Zeichensatz wird normalerweise als Quellendatenbank- oder Zieldatenbankzeichensatz ausgewählt und ist in der Regel für Export- und Importsitzungen identisch. Diese Auswahl wird insbesondere für Multibyte-Zeichensätze empfohlen, für die einige Einschränkungen für Exportdateien gelten. Die Oracle8i-Konvertierungen in und aus dem NLS_LANG-Zeichensatz erfolgen in Oracle9i für DDL-Anweisungen, die in der Exportdatei enthalten sind.

Die NLS_LANG auf dem Server (oder Client) hat keinen Einfluss auf die Zeichensatzkonvertierung über eine Datenbankverbindung. Oracle konvertiert den Zeichensatz der Quellendatenbank in den Zeichensatz der Zieldatenbank (oder umgekehrt).

Es gibt mit NLS_LANG und den Multiple Homes unter Windows keine Besonderheiten zu beachten. Der berücksichtigte Parameter ist der im Registry-Schlüssel ORACLE_HOME angegebene Parameter, der von der ausführbaren Datei verwendet wird. Wenn NLS_LANG in der Umgebung festgelegt ist, hat dies Vorrang vor dem Wert in der Registry und wird für ALLE Oracle_Homes auf dem Server/Client verwendet.

Die NLS_LANG kann in diesen Registry-Schlüsseln gefunden werden:

oder

Unter Windows gibt es zwei Arten von Tools/Anwendungen:

1. 1) Eine vollständig Unicode-fähige Anwendung, die Unicode-Codepunkte akzeptiert und diese rendern kann. Dies ist die Anwendung, die mit Unicode arbeiten muss. Windows stellt die Unicode-API bereit, aber das GUI-System selbst ist „von Natur aus“ NICHT Unicode.
   Eine vollständige Unicode-Anwendung kann nur eine Glyphe für einen bestimmten Unicode-Codepunkt anzeigen. Um Verwechslungen zu vermeiden, muss diese Anwendung eine vollständige Unicode-Schriftart verwenden. Wenn Sie eine vollständige Unicode-Anwendung haben, müssen Sie NLS_LANG auf UTF8 setzen.
   Beachten Sie, dass es derzeit nicht viele solcher Anwendungen gibt und wenn nicht ausdrücklich vom Anbieter angegeben, handelt es höchstwahrscheinlich um eine ANSI-Anwendung. Legen Sie NLS_LANG nicht auf UTF8 fest, wenn Sie sich nicht sicher sind!

   Der einzige Unicode-fähige Client, der in der Oracle Database enthalten ist, ist iSQL*Plus.

2. 2) Standard-ANSI-Anwendungen (wie sqlplusw.exe) können keine Unicode-Codepunkte verwenden. Daher muss der in der Datenbank gespeicherte Unicode-Codepunkt auf der Grundlage der korrekten Einstellung von NLS_LANG in einen ANSI-Codepunkt konvertiert werden. Auf diese Weise kann Oracle den Unicode-Codepunkt dem Zeichensatz des Clients zuordnen. Wenn der Unicode-Codepunkt keine Zuordnung zum Zeichensatz des Clients hat, wird ein Ersatzzeichen verwendet.

Ein Zeichensatz ist nur eine Vereinbarung darüber, welchen numerischen Wert ein Symbol hat. Ein Computer weiß nicht, ob es sich um ‘A’ oder ‘B ' handelt, sondern kennt nur den (binären) numerischen Wert für dieses Symbol, der im Zeichensatz des Betriebssystems (OS) oder in der Hardware (Firmware) für Terminals definiert ist. Ein Computer kann nur Zahlen manipulieren, weshalb Zeichensätze erforderlich sind. Beispiele dafür sind 'ASCII', ein alter 7-Bit-Zeichensatz, 'ROMAN8', ein 8-Bit-Zeichensatz unter UNIX, oder 'UTF8', ein Multibyte-Zeichensatz.

Eine Codepage ist der Name für das Windows-/DOS-Codierungsschema. Für Oracle NLS können Sie sie als Zeichensatz betrachten. Sie müssen auch zwischen einem FONT und einem Zeichensatz/einer Codepage unterscheiden. Das Betriebssystem verwendet eine Schriftart, um einen numerischen Wert in einen grafischen Wert umzuwandeln, der auf dem Bildschirm 'ausgedruckt' wird. Die Schriftart „Wingdings“ unter Windows ist das beste Beispiel für eine Schriftart, bei der ein ‘A’ NICHT als ‘A’ auf dem Bildschirm angezeigt wird, jedoch steht der numerische Wert für das Betriebssystem für ein ‘A’. Sie SEHEN es nicht als ‘A’, aber für Windows ist es ein ‘A’ und wird als ‘A’ gespeichert (oder verwendet).

Um die obige Erklärung besser zu verstehen, öffnen Sie einfach MS Word, wählen Sie die Schriftart „Wingdings“, geben Sie Ihren Namen ein (es werden Symbole angezeigt) und speichern Sie diese Datei als HTML. Wenn Sie die HTML-Datei mit Notepad öffnen, sehen Sie im Abschnitt <style>, dass die Schriftarten deklariert sind, und weiter unten im Abschnitt <body> finden Sie den Namen im Klartext, jedoch mit dem Attribut style='font-family: Wingdings’. Wenn Sie es in Internet Explorer oder Netscape öffnen, sehen Sie wieder die Wingdings-Symbole. Es ändert sich nur die Präsentation, nicht die Daten an sich.

Es ist auch möglich, dass die Symbole, die in der verwendeten Codepage definiert sind, nicht in einer bestimmten Schriftart angezeigt werden, da der Ersteller der Schriftart keine grafische Darstellung für alle Symbole in dieser Schriftart erstellt hat. Deshalb werden manchmal schwarze Quadrate auf dem Bildschirm angezeigt, wenn Sie die Schriftarten ändern. Unter Windows können Sie das Dienstprogramm 'Zeichentabelle' verwenden, um alle in einer Schriftart definierten Symbole anzuzeigen.

Zwei Hauptgründe:

Traditionell definierten Anbieter unterschiedliche 'Zeichensätze' für Hardware und Software, vor allem, weil es keine offiziellen Standards gab.

Neue Zeichensätze wurden definiert, um neue Sprachen zu unterstützen. Bei einem 8-Bit-Zeichensatz ist die Anzahl der unterstützten Symbole begrenzt, sodass für verschiedene geschriebene Sprachen unterschiedliche Zeichensätze verfügbar sind.

Ein 7-Bit-Zeichensatz kennt nur 128 Symbole (2^7)

Ein 8-Bit-Zeichensatz kennt 256 Symbole (2^8)

Unicode (UTF-8) ist ein Multibyte-Zeichensatz. Unicode kann über eine Million Zeichen definieren. Weitere Informationen zu Unicode finden Sie im Whitepaper Oracle Unicode Database Support (PDF)

Eine grundlegende Überlegung bei der Auswahl eines Zeichensatzes besteht darin, sicherzustellen, dass er mit jeder Sprache umgehen kann, die sofort und auf unbestimmte Zeit unterstützt werden muss. Eine weitere Überlegung, die übersehen wird, besteht darin, darüber nachzudenken, welche Anwendungen und Technologien Sie möglicherweise verwenden oder mit der Datenbank interagieren lassen möchten. Verwenden Sie den Locale Builder (ab Oracle Database 9i), um anzuzeigen, welche Zeichen für einen bestimmten Oracle Zeichensatz definiert sind.

Durch die Auswahl von Unicode als Datenbankzeichensatz wird eine solide Grundlage für alle in der Datenbank enthaltenen und darauf basierenden Elemente sichergestellt. Oracle empfiehlt die Verwendung von Unicode für alle neuen Systembereitstellungen. Es wird auch empfohlen, ältere Systeme nach Unicode zu migrieren. Die Bereitstellung Ihrer Systeme in Unicode bietet viele Vorteile in Bezug auf Benutzerfreundlichkeit, Kompatibilität und Erweiterbarkeit. Dank des umfassenden Supports von Oracle können Sie leistungsstarke Systeme schneller und einfacher bereitstellen und dabei die gesamte Leistungsfähigkeit von Unicode nutzen. Auch wenn Sie jetzt keine mehrsprachigen Daten unterstützen müssen oder Unicode benötigen. Auf lange Sicht ist dies wahrscheinlich die beste Wahl für ein neues System. Dies spart Ihnen letztendlich Zeit und Geld und verschafft Ihnen Wettbewerbsvorteile.