Keine Ergebnisse gefunden

Ihre Suche ergab keine Treffer.

Beachten Sie die folgenden Tipps, um das Gesuchte zu finden:

  • Prüfen Sie die Schreibweise des Suchbegriffs.
  • Verwenden Sie Synonyme für das eingegebene Stichwort, z. B. “Anwendung” statt “Software.”
  • Testen Sie eine der unten gezeigten beliebten Suchen.
  • Beginnen Sie eine neue Suche.
Aktuelle Fragen

Häufig gestellte Fragen

Alle öffnen Alle schließen
  • NLS_LANG-Parametergrundlagen

    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 Registrierung auf Windows-Plattformen festgelegt.

    Der Parameter NLS_LANG besteht aus drei Komponenten: Sprache, Gebiet und Zeichensatz. Geben Sie dies im folgenden Format einschließlich der Interpunktion 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.

  • Häufige NLS_LANG-Missverständnisse
    • 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.
  • Überprüfen der aktuellen NLS_LANG-Einstellung

    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:

    SQL> HOST ECHO $NLS_LANG

    Dies gibt den Wert des Parameters zurück.

    Unter Windows:
    Unter Windows haben Sie zwei Möglichkeiten: normalerweise wird NLS_LANG in der Registrierung 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 Registrierung 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:

    SQL> HOST ECHO %NLS_LANG%

    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 Registrierung:

    SQL>@.[%NLS_LANG%].

    Wenn Sie eine der folgenden ähnliche Meldung erhalten:
    Datei kann nicht geöffnet werden.[ENGLISH_UNITED KINGDOM.WE8ISO8859P1].
    Der "Dateiname" zwischen den geschweiften Klammern steht für den Wert des Registrierungsparameters.

    Wenn Sie dies als Ergebnis erhalten:
    Datei kann nicht geöffnet werden ".[%NLS_LANG%]." ist der Parameter NLS_LANG auch nicht in der Registrierung festgelegt.

    Beachten Sie, dass die @.[%NLS_LANG%].-Technik meldet, dass die NLS_LANG, die der ausführbaren SQL*Plus-Datei bekannt ist, die Registrierung 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 Registrierung festgelegt ist, wenn @.[%NLS_LANG%]. einen gültigen Wert zurückgibt.

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

    SELECT * FROM NLS_SESSION_PARAMETERS;

    Hinweis:

    SELECT USERENV ('Sprache') FROM DUAL; gibt der <Sprache>_<Gebiet> 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!

  • Die Priorität der NLS-Parameter in Bezug auf NLS_LANG

    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 einstellen 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
  • Sitzungsparameter
    SELECT * from NLS_SESSION_PARAMETERS;

    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:

      PARAMETER VALUE

      NLS_LANGUAGE AMERICAN
      NLS_TERRITORY BELGIUM
      NLS_CURRENCY <Eurosymbol>
      NLS_ISO_CURRENCY BELGIUM

      Hinweis:

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

      NLS_LANG=BELGIUM.WE8MSWIN1252 (falsch), Sie müssen "_" als Trennzeichen festlegen.

    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:

      PARAMETER VALUE

      NLS_LANGUAGE ITALIAN
      NLS_TERRITORY ITALY
      NLS_CURRENCY <Eurosymbol>
      NLS_ISO_CURRENCY ITALY

      Hinweis:

      Beachten Sie den Unterschied zwischen NLS_LANG=ITALIAN_.WE8MSWIN1252 (korrekt) und

      NLS_LANG=ITALIAN_.WE8MSWIN1252 (falsch), Sie müssen "_" als Trennzeichen festlegen.

    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:

      PARAMETER VALUE

      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:

      PARAMETER VALUE

      NLS_LANGUAGE AMERICAN
      NLS_TERRITORY AMERICA
      NLS_CURRENCY $
      NLS_ISO_CURRENCY FRANCE

      Standardwerte:
      * Wenn NLS_DATE_LANGUAGE oder NLS_SORT nicht festgelegt sind, werden sie abgeleitet von
      NLS_LANGUAGE.
      * 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 entnommen aus den

      NLS_INSTANCE_PARAMETERS. 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.
       
  • Instanzparameter
    SELECT * from NLS_INSTANCE_PARAMETERS;

    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.
     
  • Datenbankparameter
    SELECT * from NLS_DATABASE_PARAMETERS;

    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 den <Clientzeichensatz> 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.

    Zusätzliche 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" usw...

    F) SHOW parameter NLS%
    Dies ergibt dasselbe wie NLS_INSTANCE_PARAMETERS

  • Ein Beispiel für ein falsches NLS_LANG-Setup

    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 ‘é’ (LATIN SMALL LETTER E WITH ACUTE) 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 ‘Ò’ (LATIN CAPITAL LETTER O WITH 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 ‘Å’ (LATIN CAPITAL LETTER A WITH RING ABOVE).

    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 teilen Oracle mit, dass dies US7ASCII-Daten sind, sodass Oracle NICHT konvertiert und nur den numerischen Wert speichert. (Auch hier gilt: Oracle geht davon aus, dass der Client US7ASCII-Codes angibt, da NLS_LANG auf US7ASCII festgelegt ist und der Datenbankzeichensatz auch US7ASCII lautet. –> 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 erstellt die Datenbank mit einem Zeichensatz, 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.

  • So richten Sie NLS_LANG ordnungsgemäß für UNIX ein

    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:

    $ locale -a

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

    $ export LC_ALL=UTF-8

    oder

    % setenv LC_ALL UTF-8
    
     
     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

  • So richten Sie NLS_LANG ordnungsgemäß für Windows- und DOS-Codepages ein

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

  • So stellen Sie NLS_LANG unter Windows ein

    In der Registry:
    Auf Windows-Systemen sollten Sie sicherstellen, dass Sie für jedes Ihrer Oracle Homes einen NLS_LANG-Registrierungsunterschlüssel festgelegt haben:
    Sie können diesen Unterschlüssel einfach mit dem Windows-Registrierungseditor ändern:
    Start –> Ausführen...
    Geben Sie "regedit" ein, und klicken Sie auf "ok"
    Bearbeiten Sie den folgenden Registrierungseintrag:

    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 Registrierungsbaum 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 Registrierung 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

  • Bestimmen Sie Ihre Windows ANSI-Codepage

    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 Registrierung:

    Start –> Ausführen...

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

    Durchsuchen Sie den folgenden Registrierungseintrag:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NLS\CodePage\

    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 Registrierungseinträge mit sehr ähnlichen Namen gibt, vergewissern Sie sich, dass Sie sich an der richtigen Stelle in der Registrierung 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.

    ANSI CodePage (ACP) Oracle Clientzeichensatz (3. Teil von NLS_LANG)

    1250

    EE8MSWIN1250

    1251

    CL8MSWIN1251

    1252

    WE8MSWIN1252

    1253

    EL8MSWIN1253

    1254

    TR8MSWIN1254

    1255

    IW8MSWIN1255

    1256

    AR8MSWIN1256

    1257

    BLT8MSWIN1257

    1258

    VN8MSWIN1258

    874

    TH8TISASCII

    932

    JA16SJIS

    936

    ZHS16GBK

    949

    KO16MSWIN949

    950

    ZHT16MSWIN950 - außer für Hongkong (siehe unten)

    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 Registrierung fest:

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

  • Die richtige NLS_LANG für Windows-Befehlszeilenvorgänge

    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-Registrierungsschlü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:

    MS-DOS-Codepage Oracle Clientzeichensatz (3. Teil von NLS_LANG)

    437

    US8PC437

    737

    EL8PC737

    850

    WE8PC850

    852

    EE8PC852

    857

    TR8PC857

    858

    WE8PC858

    861

    IS8PC861

    862

    IW8PC1507

    865

    N8PC865

    866

    RU8PC866

  • Liste häufig verwendeter NLS_LANG-Einstellung in der Windows-Registrierung:

    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!

    Betriebssystem-Gebietsschema NLS_LANG-Wert

    Arabisch (VAE)

    ARABIC_UNITED ARAB EMIRATES.AR8MSWIN1256

    Bulgarisch

    BULGARIAN_BULGARIA.CL8MSWIN1251

    Katalanisch

    CATALAN_CATALONIA.WE8MSWIN1252

    Chinesisch (VR China)

    SIMPLIFIED CHINESE_CHINA.ZHS16GBK

    Chinesisch (Taiwan)

    TRADITIONAL CHINESE_TAIWAN.ZHT16MSWIN950

    Chinesisch (Hongkong, HKCS)

    TRADITIONAL CHINESE_HONG KONG.ZHT16HKSCS

    Chinesisch (Hongkong, HKCS2001)

    TRADITIONAL CHINESE_HONG KONG.ZHT16HKSCS2001 (neu in 10gR1)

    Kroatisch

    CROATIAN_CROATIA.EE8MSWIN1250

    Tschechisch

    CZECH_CZECH REPUBLIC.EE8MSWIN1250

    Dänisch

    DANISH_DENMARK.WE8MSWIN1252

    Niederländisch (Niederlande)

    DUTCH_THE NETHERLANDS.WE8MSWIN1252

    Niederländisch (Belgien)

    DUTCH_BELGIUM.WE8MSWIN1252

    Englisch (Vereinigtes Königreich)

    ENGLISH_UNITED KINGDOM.WE8MSWIN1252

    Englisch (USA)

    AMERICAN_AMERICA.WE8MSWIN1252

    Estnisch

    ESTONIAN_ESTONIA.BLT8MSWIN1257

    Finnisch

    FINNISH_FINLAND.WE8MSWIN1252

    Französisch (Kanada)

    CANADIAN FRENCH_CANADA.WE8MSWIN1252

    Französisch (Frankreich)

    FRENCH_FRANCE.WE8MSWIN1252

    Deutsch (Deutschland)

    GERMAN_GERMANY.WE8MSWIN1252

    Griechisch

    GREEK_GREECE.EL8MSWIN1253

    Hebräisch

    HEBREW_ISRAEL.IW8MSWIN1255

    Ungarisch

    HUNGARIAN_HUNGARY.EE8MSWIN1250

    Isländisch

    ICELANDIC_ICELAND.WE8MSWIN1252

    Indonesisch

    INDONESIAN_INDONESIA.WE8MSWIN1252

    Italienisch (Italien)

    ITALIAN_ITALY.WE8MSWIN1252

    Japanisch

    JAPANESE_JAPAN.JA16SJIS

    Koreanisch

    KOREAN_KOREA.KO16MSWIN949

    Lettisch

    LATVIAN_LATVIA.BLT8MSWIN1257

    Litauisch

    LITHUANIAN_LITHUANIA.BLT8MSWIN1257

    Norwegisch

    NORWEGIAN_NORWAY.WE8MSWIN1252

    Polnisch

    POLISH_POLAND.EE8MSWIN1250

    Portugiesisch (Brasilien)

    BRAZILIAN PORTUGUESE_BRAZIL.WE8MSWIN1252

    Portugiesisch (Portugal)

    PORTUGUESE_PORTUGAL.WE8MSWIN1252

    Rumänisch

    ROMANIAN_ROMANIA.EE8MSWIN1250

    Russisch

    RUSSIAN_CIS.CL8MSWIN1251

    Slowakisch

    SLOVAK_SLOVAKIA.EE8MSWIN1250

    Spanisch (Spanien)

    SPANISH_SPAIN.WE8MSWIN1252

    Schwedisch

    SWEDISH_SWEDEN.WE8MSWIN1252

    Thailändisch

    THAI_THAILAND.TH8TISASCII

    Spanisch (Mexiko)

    MEXICAN SPANISH_MEXICO.WE8MSWIN1252

    Spanisch (Venezuela)

    LATIN AMERICAN SPANISH_VENEZUELA.WE8MSWIN1252

    Türkisch

    TURKISH_TURKEY.TR8MSWIN1254

    Ukrainisch

    UKRAINIAN_UKRAINE.CL8MSWIN1251

    Vietnamesisch

    VIETNAMESE_VIETNAM.VN8MSWIN1258

  • Liste der allgemeinen NLS_LANG-Einstellungen, die in der Eingabeaufforderung (DOS-Box) verwendet werden

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

    Betriebssystem-Gebietsschema Oracle Clientzeichensatz (3. Teil von NLS_LANG)

    Arabisch

    AR8ASMO8X

    Katalanisch

    WE8PC850

    Chinesisch (VR China)

    ZHS16GBK

    Chinesisch (Taiwan)

    ZHT16MSWIN950

    Tschechisch

    EE8PC852

    Dänisch

    WE8PC850

    Niederländisch

    WE8PC850

    Englisch (Vereinigtes Königreich)

    WE8PC850

    Englisch (USA)

    US8PC437

    Finnisch

    WE8PC850

    Französisch

    WE8PC850

    Deutsch

    WE8PC850

    Griechisch

    EL8PC737

    Hebräisch

    IW8PC1507

    Ungarisch

    EE8PC852

    Italienisch

    WE8PC850

    Japanisch

    JA16SJIS

    Koreanisch

    KO16MSWIN949

    Norwegisch

    WE8PC850

    Polnisch

    EE8PC852

    Portugiesisch

    WE8PC850

    Rumänisch

    EE8PC852

    Russisch

    RU8PC866

    Slowakisch

    EE8PC852

    Slowenisch

    EE8PC852

    Spanisch

    WE8PC850

    Schwedisch

    WE8PC850

    Türkisch

    TR8PC857

  • Weitere häufig gestellte Fragen zu NLS_LANG

    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.

  • Wie erkenne ich, was tatsächlich in der Datenbank gespeichert ist?

    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:

    DUMP( <value> [, <format> [, <offset> [, <length> ] ] ] )

    Erläuterung:

    Wert - 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:

    SQL> SELECT DUMP(col,1016)FROM table;

    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:

    $ echo "" | od -xc

    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:

    $echo '\0351'

    Für Linux:

    $echo -e '\0351'

    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

  • Was ist mit Befehlszeilentools wie SQL*Loader, Import, Export und Dienstprogrammen?

    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.

  • Was ist mit Datenbanklinks?

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

  • Was ist mit Multiple Homes unter Windows?

    Es gibt mit NLS_LANG und den Multiple Homes unter Windows keine Besonderheiten zu beachten. Der berücksichtigte Parameter ist der im Registrierungsschlü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 Registrierung und wird für ALLE Oracle_Homes auf dem Server/Client verwendet.

    Die NLS_LANG kann in diesen Registrierungsschlüsseln gefunden werden:

    HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE

    oder

    HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEx
  • Gibt es einen Unicode-Client von Oracle unter Windows?

    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, das GUI-System selbst ist jedoch NICHT "ursprünglich" 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.
  • Was ist ein Zeichensatz oder eine Codepage?

    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 Wingdings-Schriftart 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 Wingdings-Schriftart, geben Sie Ihren Namen ein (es werden Symbole angezeigt) und speichern Sie diese 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.

  • Warum gibt es unterschiedliche Zeichensätze?

    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.

  • Was ist der Unterschied zwischen 7-Bit-, 8-Bit- und Unicode-Zeichensätzen?

    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)

  • Wie wähle ich den richtigen Datenbankzeichensatz aus?

    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.