Die Variable NLS_LANG wird bei Windows-Systemen üblicherweise in der Registry gesetzt und bei Linux/Unix-Systemen über entsprechende Login-Skripte.
Die Variable NLS_LANG hat drei Teile: <Sprache>_<Territorium>.<Zeichensatz>
Beispiel:
echo $NLS_LANG
AMERICAN_AMERICA.AL32UTF8
Über die Sprache wird zum Beispiel die Sprache der Fehlermeldungen sowie der Tages- und Monatsnamen gesteuert. Über das Territorium werden beispielsweise die Währung und die numerischen Trennzeichen gesteuert. Und der Zeichensatz gibt an, in welchem Zeichensatz der Client die Daten an die Datenbank schickt, beziehungsweise in welchem (Client-)Zeichensatz Abfrageergebnisse dargestellt werden sollen. Und da fangen die Missverständnisse und Fehlkonfigurationen an.
Da der Zeichensatz in NLS_LANG angibt, in welchem Satz der Client die Zeichen an die Datenbank schickt, sollte die Zeichensatzkomponente dem Betriebssystem-Zeichensatz des Clients entsprechen und nicht dem Datenbank-Zeichensatz.
Auf Windows-Systemen ist das üblicherweise etwas wie GERMAN_GERMANY.WE8MSWIN1252 (8-bit Windows-Zeichensatz, Code-Page 1252). Oftmals sieht man aber Einstellungen wie GERMAN_GERMANY.AL32UTF8, weil die Datenbank mit dem Unicode-Zeichensatz AL32UTF8 arbeitet. Und das ist ein Fehler, der oftmals nicht sofort auffällt: Denn wenn alle Clients so (falsch) eingestellt sind, dann werden die Werte beim Eintrag in die Datenbank falsch übersetzt und beim Auslesen aus der Datenbank falsch zurückübersetzt. Und auf den Clients sieht alles gut aus.
Erst wenn man mit einem korrekt konfigurierten Client auf die Datenbank zugreift, sieht man, dass die Werte in der Datenbank falsch sind.
Ein Beispiel:
Auf einem Linux-Rechner ist als Zeichensatz UTF8 eingestellt:
locale
LANG=en_US.UTF8
[…]
Wir setzen jetzt bei NLS_LANG die Zeichensatzkomponente bewusst falsch auf den 8-Bit-Zeichensatz WE8ISO8859P15:
export NLS_LANG=GERMAN_GERMANY.WE8ISO8859P15
Dann fügen wir in eine Test-Tabelle eine Zeile mit Umlauten ein:
SQL> insert into t values ('äö');
1 Zeile wurde erstellt.
Wenn man die Daten kontrolliert, sieht auf dem Linux-Client mit falscher Zeichensatzeinstellung alles gut aus:
SQL> select * from t;
C1
----------
Äö
Das Problem fällt also nicht sofort auf. Wenn man die Daten aber mit einem Client mit korrekter Zeichensatzeinstellung abfragt, dann zeigt sich ein anderes Bild:
select * from t;
C1
----------
Àö
Für solche Tests bietet sich übrigens der SQL-Developer an, denn dort wird die Zeichensatzeinstellung korrekt gesteuert. Darüber können Sie dann auch derartige Fehler in der Datenbank entdecken.
Lange Rede, kurzer Sinn: Setzen Sie bei Ihren Datenbank-Clients NLS_LANG so, dass der Zeichensatz dem korrekten Client-Zeichensatz entspricht. Nur so können Sie sicher sein, dass die Daten korrekt in der Datenbank abgelegt werden.
Markus Flechtner
Themenverantwortlicher Open Source
