Doc ID: Note:179133.1 Type: BULLETIN
Last Revision Date: 28-DEC-2005 Status: PUBLISHED
Content:
--------
1. Key concepts/terminology.
2. How to set up my NLS_LANG
3. The correct NLS_LANG for my Windows ANSI Code Page
4. The correct NLS_LANG for my DOS / Command Prompt OEM Code Page
5. How to check the NLS_LANG
6. List of common NLS_LANG to be set in Windows registry
7. List of common character sets to be used in a command prompt
8. How Windows uses Fonts to display the different charactersets
1. Key Concepts/terminology:
----------------------------
NLS_LANG consist of: NLS_LANG=
This note covers the
windows specific information in addition of
Note 158577.1 NLS_LANG Explained (How does Client-Server Character Conversion Work?).
Please read that note first to have an idea how NLS_LANG works..
1.1 Windows and Dos Code Pages:
-------------------------------
On Windows systems, the encoding scheme (=Characterset) is specified by a Code Page.
Code Pages are defined to support specific languages or groups of languages
which share common writing systems.
From Oracle point of view the terms Code Page and Characterset mean the same.
Note that in non Chinese-Japanese-Korean environments, the Windows GUI and DOS
command prompt do not use the same code page (!).
As a result windows uses 2 different charactersets for the ANSI (sqlplusw.exe)
and to OEM (dos box - sqlplus.exe) environments
To illustrate the issue:
open notepad, type some "üéèç�" , save that file as c:\test.txt
(make sure that the encoding save as setting of notepad is set ot ANSI)
open a dos box
Start - Run - cmd - ok
and type
C:\Documents and Settings\user>edit c:\test.txt
you see "³ÚÞþÓ" in edit
Here you see a file in "ansi" encoding (notepad) displayed by the OEM
(dos box) environment of edit. You see clearly that windows do not use
the same characterset for the ANSI and CMD / DOS box environments.
For more questions about this, please contact Microsoft.
1.2 Fonts:
----------
A font is a collection of glyphs (from "hieroglyphs") that share common
appearances (typeface, character size). A font is used by the operating system
to convert a numeric value into a graphical representation on screen.
A font does not necessarly contain a graphical representation for all numeric
values defined in the code page you are using.
That's why you get sometimes black squares on the screen if you change fonts and the new
that font has no representation for a certain symbol.
The Windows "Character Set Map" utility can be used to see which glyphs are part
of a certain font.
On Windows 2000:
Start -> Programs -> Accessories -> System Tools -> Character Map
or
Start -> Run...
Type "charmap", and click "ok"
A font also implements a particular code page or set of code pages.
For example, the Arial font implements the code pages 1252, 1250, 1251, 1253,
1254, 1257.
For more in-depth info on fonts see point 8 in this note.
2. How to setup my NLS_LANG:
----------------------------
To specify the locale behaviour of your client Oracle software, you have to set
your NLS_LANG parameter.
It sets the language, territory and also the character set of your client.
For a short overview, it uses the following format:
NLS_LANG = LANGUAGE_TERRITORY.CHARACTERSET
where:
LANGUAGE specifies:
- language used for Oracle messages,
- day names and month names
TERRITORY specifies:
- monetary and numeric formats,
- territory and conventions for calculating week and day numbers
CHARACTERSET:
- controls the character set used by the client application
* or it matches your Windows code page
* or it set to UTF8 for an unicode application
The list of supported character sets,languages and territory
can also be found in the Oracle9i Globalization Support Guide,
Appendix A, Locale Data
Available online at the following URL:
http://otn.oracle.com/pls/db92/db92.docindex?remark=homepage
4 important remarks:
* Setting the NLS_LANG to the characterset of the database MAY be correct
but IS NOT ALWAYS correct. Please DO NOT assume that NLS_LANG needs to be
ALWAYS the same as the database characterset. THIS IS NOT TRUE.
* The characterset defined with the NLS_LANG parameter does NOT CHANGE
your client's characterset, it is used to let Oracle know what characterset
you are USING on the client side, so Oracle can do the proper conversion.
You cannot just set NLS_LANG to the characterset you WANT.
If you need Hebrew support (for example) on an Cyrillic windows
then that windows need to be changed to have an 1255 ACP (see point 3),
just setting the nls_lang to hebrew will NOT allow you to retrieve/store hebrew.
* Another myth is that if you don't set the NLS_LANG on the client
it uses the NLS_LANG of the server. This is also NOT true!
The characterset part of the NLS_LANG parameter is never inherited from the server.
Please also see: Note 241047.1 The Priority of NLS Parameters Explained.
* Note that LANGUAGE and TERRITORY have nothing to do with the abillity to
*store* characters in a database.
A NLS_LANG set to JAPANESE_JAPAN.WE8MSWIN1252 will not allow you to store Japanese
as WE8MSWIN1252 dousn't know Japanese characters.
For
at the end of this note and Note 158577.1.
2.1 In the Registry:
--------------------
On Windows systems, you should make sure that you have set an NLS_LANG registry
subkey for each of your Oracle Homes:
You can easily modify this subkey with the Windows Registry Editor:
Start -> Run...
Type "regedit", and click "ok"
Edit the following registry entry:
for version 7:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE
For version 8 , 8i and 9i:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEx\
where "x" is the unique number identifying the Oracle home.
HOME0 is the first installation
For version 10g:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_
There you have an entry with as name NLS_LANG
When starting an Oracle tools, like sqlplusw, it will read the content of
the oracle.key file located in the same directory to determine which registry
tree will be used, therefore which NLS_LANG subkey will be used.
Note:
-----
Some people are confused by finding a NLS_LANG set to "NA"
in HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE when no version 7 was installed.
This is used for backwards compatibility, ignore this.
for 8.0, 8i and 9i you need to set the NLS_LANG in
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEx\
2.2 As a System or User Environment Variable, in System properties:
-------------------------------------------------------------------
Although the Registry is the primary repository for settings on Windows, it is
not the only place where parameters can be set.
Even if not at all recommended, you can set the NLS_LANG as a System or User
Environment Variable in the System properties.
This setting will be used for ALL Oracle homes.
To check and modify them:
Right-click the 'My Computer' icon -> 'Properties'
Select the 'Advanced' Tab -> Click on 'Environment Variables'
The 'User Variables' list contains the settings for the specific OS user
currently logged on and the 'System variables' system-wide variables for all users.
Since these environment variables take precedence of the parameters already set
in your Registry, you should not set Oracle parameters at this location unless you
have a very good reason.
Particularly note the "ORACLE_HOME" parameter that is set on unix but NOT on windows.
2.3 As an Environment variable defined in the command prompt:
-------------------------------------------------------------
If you set the NLS_LANG as an environment variable in a Command prompt,
be aware that it will overrite the current NLS_LANG setting in the Registry
and also the System Properties.
In an MS-DOS command prompt, use the set command, for example:
C:\> set NLS_LANG=american_america.WE8PC850
3. The correct NLS_LANG for my Windows ANSI Code Page:
------------------------------------------------------
3.1 Determine your Windows ANSI code page:
------------------------------------------
The ACP (Ansi Code Page) is defined by the "default locale" setting of windows,
so if you have a UK Windows 2000 client and you want to input cyrillic (russian)
you need to change the ACP (by changing the "default locale") in order to be
able to input russian.
see Note 199926.1 How to change the ANSI Code Page (ACP) on Windows.
You'll find its value in the registry:
Start -> Run...
Type "regedit", and click "ok"
Browse the following registry entry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\
There you have (all the way below) an entry with as name ACP
The value of ACP is your current GUI Codepage, see the table in point 3.2
for the mapping to the oracle name.
Since there are many registry entries with very similar names, please
make sure that you are looking at the right place in the registry.
Again, if you need to change the "ACP" please see:
Note 199926.1 How to change the ANSI Code Page (ACP) on Windows
Do NOT simply change it in the registry.
Not all languages have a ANSI encoding, sqlplus only supports
ANSI and OEM charactersets.
The following URL provides a list of the default code pages
for a language for Windows 2000 / xp versions:
http://www.microsoft.com/globaldev/nlsweb/default.asp
OEM = the command line codepage (dos box), ANSI = the gui codepage
a ANSI codepage of 0 in this list means that the language is supported
by microsoft windows trough a unicode layer
and that there is no ANSI code page for that language
a OEM codepage of 1 in this list means that the language is supported
by microsoft windows trough a unicode layer
and that there is no OEM code page for that language
if you want to see / insert languages with a 0 or 1 on a windows client then
you need to use a Unicode client.
Sqlplusw.exe and sqlplus.exe are NOT unicode clients
You can use iSqlplus.
Note 231231.1 Quick setup of iSQL*Plus 9.2 as unicode (UTF8) client on windows.
Note 281847.1 How do I configure or test iSQL*Plus 10i?
note that the Honk Kong HKSCS is listed here:
http://www.microsoft.com/hk/hkscs/
3.2 Find the correspondent Oracle client character set:
-------------------------------------------------------
Find the Oracle client character set in the table below based
on the ACP you found in point 3.1.
Note that there is only ONE CORRECT value for a given ACP
Not all scripts / languages have ANSI support.
The following languages have NO ANSI support in windows:
Armenian, Divehi, Georgian, Gujarati, Hindi, Kannada, Oriya,
Konkani, Marathi, Punjabi, Sanskrit, Syriac, Tamil and Telugu.
(there are more... this list is just a example, see point 3.1 in this note )
ANSI CodePage (ACP) Oracle Client character set (3rd part of 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 - except for Hong kong (see below)
This is the characterset used by the GUI sqlplus
(sqlplusW.exe/ plus80W.exe / plus33W.exe ) that you start trough
the windows start menu.
Please *DO* make the difference between the GUI sqlplus
and the "DOS mode" sqlplus (see point 4 in this note)
You can use UTF8 as Oracle client character set (=NLS_LANG) on Windows NT, 2000 and XP but
you will be limited to use only client programs that explicitly support this
configuration.
This is because the user interface of Win32 is not UTF8, therefore the client
*program* have to perform explicit conversions between UTF8 (used on Oracle
side) and UTF16 (used on Win32 side).
An example of such a program is Oracle Forms in version 5 and later on NT 4.0.
Note 105809.1 Character Set Support for Developer Tools
or iSqlPlus (from 817 onwards).
Note 231231.1 Quick setup of iSQL*Plus as unicode (UTF8) client on windows.
Note 281847.1 How do I configure or test iSQL*Plus 10i?
Contact Microsoft if you have questions about writing a unicode application.
a little (non-official, so nothing is endorsed by Oracle or Microsoft) intro:
http://www.jorendorff.com/articles/unicode/windows.html
From the other side, programs relying on ANSI Win32 API, like SQL*Plus,
older Oracle Forms , etc. cannot work with an NLS_LANG set to UTF8.
For euro support see:
Note 68790.1 RDBMS Support for the Euro Currency Symbol
For tools like sqlloader you need to set the NLS_LANG
to the characterset of the FILE you loading.
Note 227330.1 Character Sets & Conversion - Frequently Asked Questions
18. What is the best way to load non-US7ASCII characters using SQL*Loader?
For Export / Import please see:
Note 227332.1 NLS considerations in Import/Export
3.3 Set it in your Registry:
----------------------------
Use the Windows Registry Editor to set up the NLS_LANG in your Oracle Home
with the value you have just find above.
Section 2.1 gives you more details on how to use the Registry Editor for that
purpose.
4. The correct NLS_LANG for my DOS / Command Prompt OEM Code Page:
------------------------------------------------------------------
MS-DOS mode uses, with a few exceptions like CJK, a different code page
(called OEM code page) than Windows GUI (ANSI code page).
Meaning that before using an Oracle command line tool such as SQL*Plus
(sqlplus.exe/ plus80.exe / plus33.exe ) en svrmgrl in a command prompt
then you need to MANUALLY SET the NLS_LANG parameter as an environment
variable with the set DOS command BEFORE using the tool.
For Japanese, Korean, Simplified Chinese, and Traditional Chinese,
the MS-DOS OEM code page (CJK) is identical to the ANSI code page meaning that,
in this particular case, there is no need to set the NLS_LANG parameter in
MS-DOS mode.
Not all scripts / languages have OEM support.
The following languages have NO OEM support in windows:
Armenian, Divehi, Georgian, Gujarati, Hindi, Kannada, Oriya,
Konkani, Marathi, Punjabi, Sanskrit, Syriac, Tamil and Telugu.
(there are more... this list is just a example, see point 3.1 in this note )
In all other cases, you need to set it in order to overwrite the NLS_LANG
registry key already matching the ANSI code page. The new "MS-DOS dedicated"
NLS_LANG needs to match the MS-DOS OEM code page that could be retrieved by
typing chcp in a Command Prompt:
C:\> chcp
Active code page: 437
C:\> set NLS_LANG=american_america.US8PC437
If the NLS_LANG parameter for the MS-DOS mode session is not set appropriately,
error messages and data can be corrupted due to incorrect character set
conversion.
Use the following list to find the Oracle character set that fits to your MS-DOS
code page in use on your locale system:
MS-DOS code page Oracle Client character set (3rd part of NLS_LANG)
437 US8PC437
737 EL8PC737
850 WE8PC850
852 EE8PC852
857 TR8PC857
858 WE8PC858
861 IS8PC861
862 IW8PC1507
865 N8PC865
866 RU8PC866
There is no euro support in the Command Prompt OEM Code Pages, see:
Note 68790.1 RDBMS Support for the Euro Currency Symbol
For tools like sqlloader you need to set the NLS_LANG
to the characterset of the FILE you loading.
Note 227330.1 Character Sets & Conversion - Frequently Asked Questions
18. What is the best way to load non-US7ASCII characters using SQL*Loader?
For Export / Import please see:
Note 227332.1 NLS considerations in Import/Export
5. How to check the NLS_LANG:
-----------------------------
To check the NLS_LANG, you need to open a command prompt and to run sqlplus
in command line mode.
First, check if it's set in the environment:
SQL> host echo %NLS_LANG%
If this reports just %NLS_LANG% back, the variable is not set in the
environment. If it's set it reports something like
ENGLISH_UNITED KINGDOM.WE8PC850
If NLS_LANG is not set in the enviroment, you should check the value
in the registry:
SQL> @.[%NLS_LANG%].
If you get something like:
unable to open file ".[ENGLISH_UNITED KINGDOM.WE8ISO8859P1]."
the "file name" between the '[]' is the value of the registry parameter.
(This is NOT an error but just a "trick" to get the NLS_LANG value)
If you get this as result:
unable to open file ".[%NLS_LANG%]."
then the parameter NLS_LANG is also not set in the registry.
Note: the @.[%NLS_LANG%]. "trick" reports the NLS_LANG known by the sqlplus
executable, it will not read the registry itself.
But then you are not sure if the variable is set in the enviroment or in the
registry. That's the reason of checking with the host commando first.
6. List of common NLS_LANG's used in the Windows Registry:
----------------------------------------------------------
note: this is the correct setting for the GUI sqlplus version,
(sqlplusW.exe/ plus80W.exe / plus33W.exe )
If you are testing with "special" characters please DO use the gui
and not the "dos box" sqlplus.exe !
Not all scripts / languages have ANSI support.
The following languages have NO ANSI support in windows:
Armenian, Divehi, Georgian, Gujarati, Hindi, Kannada, Oriya,
Konkani, Marathi, Punjabi, Sanskrit, Syriac, Tamil and Telugu.
(there are more... this list is just a example, see point 3.1 in this note )
Operating System Locale NLS_LANG Value
Arabic (U.A.E.) ARABIC_UNITED ARAB EMIRATES.AR8MSWIN1256
Bulgarian BULGARIAN_BULGARIA.CL8MSWIN1251
Catalan CATALAN_CATALONIA.WE8MSWIN1252
Chinese (PRC) SIMPLIFIED CHINESE_CHINA.ZHS16GBK
Chinese (Taiwan) TRADITIONAL CHINESE_TAIWAN.ZHT16MSWIN950
Chinese (Hong Kong HKCS) TRADITIONAL CHINESE_HONG KONG.ZHT16HKSCS
Chinese (Hong Kong HKCS2001) TRADITIONAL CHINESE_HONG KONG.ZHT16HKSCS31 (new in 10gR2)
(see http://www.microsoft.com/hk/hkscs/ how Microsoft supports HKCS and
http://www.info.gov.hk/digital21/eng/structure/cli_main.html )
Croatian CROATIAN_CROATIA.EE8MSWIN1250
Czech CZECH_CZECH REPUBLIC.EE8MSWIN1250
Danish DANISH_DENMARK.WE8MSWIN1252
Dutch (Netherlands) DUTCH_THE NETHERLANDS.WE8MSWIN1252
Dutch (belgium) DUTCH_BELGIUM.WE8MSWIN1252
English (United Kingdom) ENGLISH_UNITED KINGDOM.WE8MSWIN1252
English (United States) AMERICAN_AMERICA.WE8MSWIN1252
Estonian ESTONIAN_ESTONIA.BLT8MSWIN1257
Finnish FINNISH_FINLAND.WE8MSWIN1252
French (Canada) CANADIAN FRENCH_CANADA.WE8MSWIN1252
French (France) FRENCH_FRANCE.WE8MSWIN1252
German (Germany) GERMAN_GERMANY.WE8MSWIN1252
Greek GREEK_GREECE.EL8MSWIN1253
Hebrew HEBREW_ISRAEL.IW8MSWIN1255
Hungarian HUNGARIAN_HUNGARY.EE8MSWIN1250
Icelandic ICELANDIC_ICELAND.WE8MSWIN1252
Indonesian INDONESIAN_INDONESIA.WE8MSWIN1252
Italian (Italy) ITALIAN_ITALY.WE8MSWIN1252
Japanese JAPANESE_JAPAN.JA16SJIS
Korean KOREAN_KOREA.KO16MSWIN949
Latvian LATVIAN_LATVIA.BLT8MSWIN1257
Lithuanian LITHUANIAN_LITHUANIA.BLT8MSWIN1257
Norwegian NORWEGIAN_NORWAY.WE8MSWIN1252
Polish POLISH_POLAND.EE8MSWIN1250
Portuguese (Brazil) BRAZILIAN PORTUGUESE_BRAZIL.WE8MSWIN1252
Portuguese (Portugal) PORTUGUESE_PORTUGAL.WE8MSWIN1252
Romanian ROMANIAN_ROMANIA.EE8MSWIN1250
Russian RUSSIAN_CIS.CL8MSWIN1251
Slovak SLOVAK_SLOVAKIA.EE8MSWIN1250
Spanish (Spain) SPANISH_SPAIN.WE8MSWIN1252
Swedish SWEDISH_SWEDEN.WE8MSWIN1252
Thai THAI_THAILAND.TH8TISASCII
Spanish (Mexico) MEXICAN SPANISH_MEXICO.WE8MSWIN1252
Spanish (Venezuela) LATIN AMERICAN SPANISH_VENEZUELA.WE8MSWIN1252
Turkish TURKISH_TURKEY.TR8MSWIN1254
Ukrainian UKRAINIAN_UKRAINE.CL8MSWIN1251
Vietnamese VIETNAMESE_VIETNAM.VN8MSWIN1258
7. List of common NLS_LANG's used in the Command Prompt (DOS box):
------------------------------------------------------------------
note: this is the correct setting for the DOS BOX sqlplus version,
(sqlplus.exe/ plus80.exe / plus33.exe )
Not all scripts / languages have OEM support.
The following languages have NO OEM support in windows:
Armenian, Divehi, Georgian, Gujarati, Hindi, Kannada, Oriya,
Konkani, Marathi, Punjabi, Sanskrit, Syriac, Tamil and Telugu.
(there are more... this list is just a example, see point 3.1 in this note )
Operating System Locale Oracle Client character set (3rd part of NLS_LANG)
Arabic AR8ASMO8X
Catalan WE8PC850
Chinese (PRC) ZHS16GBK
Chinese (Taiwan) ZHT16MSWIN950
Czech EE8PC852
Danish WE8PC850
Dutch WE8PC850
English (United Kingdom) WE8PC850
English (United States) US8PC437
Finnish WE8PC850
French WE8PC850
German WE8PC850
Greek EL8PC737
Hebrew IW8PC1507
Hungarian EE8PC852
Italian WE8PC850
Japanese JA16SJIS
Korean KO16MSWIN949
Norwegian WE8PC850
Polish EE8PC852
Portuguese WE8PC850
Romanian EE8PC852
Russian RU8PC866
Slovak EE8PC852
Slovenian EE8PC852
Spanish WE8PC850
Swedish WE8PC850
Turkish TR8PC857
8. How Windows uses Fonts to display the different charactersets:
-----------------------------------------------------------------
We assume you have an UTF8 database with correctly stored UTF8 codepoints.
On Windows there are two kinds of tools / applications:
1)A fully Unicode enabled applications which accepts Unicode codepoints and
which can render them. It's the application that needs to deal with the Unicode,
Windows provides the unicode API but the GUI system itself is NOT Unicode
"by nature".
A fully Unicode application can only show one glyph for a given Unicode
code point. So there is NO confusion possible here, this application will need
to use a full unicode font. If you have a full unicode application, then you
need to set the NLS_LANG to UTF8.
Note that there are currently NOT many applications like this and if it's not
explicitly mentioned by the vendor it's most likely an ANSI application (see
below). So DON'T set the NLS_LANG to UTF8 if you are not sure!
Tcode capable client that is included in the database is iSQLPLus.
See Note 231231.1 Quick setup of iSQL*Plus as unicode client on windowisandard ANSI application (like sqlplusw.exe) cannot use Unicode
code points. So the Unicode code point stored in the database needs to be
CONVERTED to a ANSI code point. This is done by setting NLS_LANG (as described
in further on in this note and in Note 158577.1.
This allows oracle to map the unicode point to the characterset of the client,
(and here comes the tricky part)but this is NOT the same as a font.
If you want to display Arabic for example then you need to set the Windoabic. That way Windows knows what are valid codepoints and
can use the FONT engine to DISPLAY the codepoints (this results in glyphs).
Windows passes the codepoint and the "page" to the rendering engine.
This "page" defines the glyphs for the codepoints for a certain
characterset/codepage.
Because there are osible positions for a ANSI application, and one
font contains normally glyphs for different languages this "page" is used to
select from a FONT that has (for example) all the glyphs for Cyrillic, Arabic
and West-European the "page" for arabian.
So lets say you have a Arabic setup that works, you change manually the "Page"
of a FONT and ask to display the glyph for ANSI codepoint XX. Now 1 of 2 things
can happen:
1) There is a character defined on that position for the CHARACTERSET of that
"Page", so the creator of the font has forseen a glyph and this is displayed
(but this is NOT the character expected or wanted as its stored as a different
character in the database!).
2) There is NO character defined on that position for the CHARACTERSET of that
"Page" so the creator of the font has NOT forseen a glyph and you get "garbage"
or black squares (normally you should see a black square but a ? or ? are also
possible, this depends on the error handling defined in the FONT).
The above is also possible if you have an non-Unicode characterset for the
database.
For more information see also:
Note 137127.1 Character Sets, Code Pages, Fonts and the NLS_LANG Value
Related Documents:
==================
Note 241047.1 The Priority of NLS Parameters Explained.
Note 158577.1 NLS_LANG Explained (How does Client-Server Character Conversion Work?)
Note 137127.1 Character Sets, Code Pages, Fonts and the NLS_LANG Value
Note 199926.1 How to change the ANSI Code Page (ACP)nd Windows 2000
Note 226558.1 An example insillic data into a database on23706.1> Using Locale Builder to view the definition of character sets
Note 132453.1 How to Change the Displayed Font in SQL*Plus (GUI) on WinNT
Note 231231.1 Quick setup of iSQL*Plus as unicode (UTF8) client on windows.
Note 165259.1 How to set NLS Variables for different Applications using the same ORACLE_HOME
Oracle8i Installation Guide for Windows NT, Part Number A85302-01
Appendix D - National Language Support
http://otn.oracle.com/documentation/oracle8i.html
- Oracle9i Database Installation Guide for Windows, Part Number A90162-01
Appendix E - Globalization Support
http://otn.oracle.com/documentation/oracle9i.html
- This Microsoft web site:
http://www.microsoft.com/globaldev/reference/oslocversion.mspx
provides a list of the default code pages for all Windows versions.
- updating/changing the NLS_LANG in the registry to the correct value:
this can easely be done by importing a .reg file who will then delete the old and add the new registry value.
like shown in http://www.winguides.com/article.php/8/
like:
REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\]
"NLS_LANG"=-
[HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME0]
"NLS_LANG"=-
"NLS_LANG"="DUTCH_BELGIUM.WE8MSWIN1252"
For further NLS / Globalization information you may start here:
Note 267942.1 Globalization Technology (NLS) Knowledge Browser
No comments:
Post a Comment