I have an Oracle Database with character set AL32UTF8, but I am not able to read some information (ex. Chinese characters). How can I configure my PLSQL Developer to read these characters?
By the way, when I read this information it appears such as ???
I'm using Windows XP.
I found the answer by myself.
It's necessary to change the NLS_LANG registry in the following route HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_ODACHome2
And set it with the properly language. In my case it was : AMERICAN_AMERICA.AL32UTF8
Anyway...Thanks.
Set NLS_LANG Environment Variable also works for me.
Variable: NLS_LANG
Value: AMERICAN_AMERICA.AL32UTF8
Your NLS_CHARACTERSET should be set to AL32UTF8 and also make sure that parameter NLS_NCHAR_CHARACTERSET is set to UTF8.
SQL> ALTER SESSION SET NLS_NCHAR_CHARACTERSET = 'UTF8';
Related
I am using 19c client and my database's NLS parameters like these:
Also my clients specs are:
While (Windows 10 x64) I am using sqplus, I get this(you can see my NLS_LANG environment variable on the top of command line):
My 19c client home regedit NLS_LANG variable also is set to AMERICAN_AMERICA.W8ISO8859P9.
Yet, when I using TOAD for Oracle:
and using SQL Developer:
I got confused. On the internet they say NLS_LANG environment variable should be enough for setting client character set, but clearly it isn' t.
Due to this configuration difference, I am seeing "fıtıkçışahap"(on sqlplus) as "fıtıkçışahap"(on SQL Developer and TOAD for Oracle)
How can I overcome this situation?
Thanks in advance!
Edit:
V$NLS_PARAMETERS
Forget about SELECT CLIENT_CHARSET FROM V$SESSION_CONNECT_INFO, it does not mean anything.
SQL Developer is Java/JDBC based. Starting from Oracle Database 10g, the NLS_LANG variable is no longer part of the JDBC globalization mechanism. The JDBC driver does not check NLS environment. So, setting it has no effect.
Your NLS_LANG variable is set to AMERICAN_AMERICA.W8ISO8859P9 - what does it mean in terms of character set?
You tell the Oracle database: "my client uses character set W8ISO8859P9" (i.e. ISO-8859-9) - no more, no less!
When you run SQL*Plus then it inherits the character set from the command line codepage. You can interrogate and modify the codepage with command chcp. I assume it is either CP857 (if you run a Turkish Windows) or CP850 or CP437 (see National Language Support (NLS) API Reference). Non of these three codepages matches ISO-8859-9, so your output is gibberish.
Before you run SQL*Plus set the codepage accordingly, i.e. chcp 28599 (see Code Page Identifiers)
Alternatively set the NLS_LANG according to your codepage, e.g. AMERICAN_AMERICA.TR8PC857 (check with SELECT VALUE AS ORACLE_CHARSET, UTL_I18N.MAP_CHARSET(VALUE) AS IANA_NAME FROM V$NLS_VALID_VALUES WHERE PARAMETER = 'CHARACTERSET')
Usually TOAD handles the character set very smart, so I fear the gibberish you see in TOAD is the real data in your database, i.e. it is junk because you had the wrong NLS_LANG value when the data was inserted.
See also OdbcConnection returning Chinese Characters as "?"
My PostgreSQL database' s encoding was tr_TR.UTF8, so still UTF8. It should have been LATIN that support Turkish character set. Changing it to tr_TR.iso8859 solved my problem.
I would like to know the difference between
NLS_NCHAR_CHARACTERSET and NLS_CHARACTERSET settings in Oracle?
From my understanding, NLS_NCHAR_CHARACTERSET is for NVARCHAR data types
and for NLS_CHARACTERSET would be for VARCHAR2 data types.
I tried to test this on my development server which my current settings for CHARACTERSET are as the following :
PARAMETER VALUE
------------------------------ ----------------------------------------
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET US7ASCII
Then I inserted some Chinese character values into the database. I inserted the characters into a table called data_<seqno> and updated the column for ADDRESS and ADDRESS_2 which are VARCHAR2 columns. Right from my understanding with the current setting for NLS_CHARACTERSET US7ASCII, Chinese characters should not be supported but it is still showing in the database. Does NLS_NCHAR_CHARACTERSET take precedence over this?
Thank You.
In general all your points are correct. NLS_NCHAR_CHARACTERSET defines the character set for NVARCHAR2, et. al. columns whereas NLS_CHARACTERSET is used for VARCHAR2.
Why is it possible that you see Chinese characters with US7ASCII?
The reason is, your database character set and your client character set (i.e. see NLS_LANG value) are both US7ASCII. Your database uses US7ASCII and it "thinks" also the client sends data using US7ASCII. Thus it does not make any conversion of the strings, the data are transferred bit-by-bit from client to server and vice versa.
Due to that fact you can use characters which are actually not supported by US7ASCII. Be aware, in case your client uses a different character set (e.g. when you use ODP.NET Managed Driver in an Windows application) the data will be rubbish! Also if you would consider a database character set migration you have the same issue.
Another note: I don't think you would get the same behavior with other character sets, e.g. if your database and your client both would use WE8ISO8859P1 for example. Also be aware that you actually have wrong configuration. Your database uses character set US7ASCII, your NLS_LANG value is also US7ASCII (most likely it is not set at all and Oracle defaults it to US7ASCII) but the real character set of SQL*Plus, resp. your cmd.exe terminal is most likely CP950 or CP936.
If you like to set everything properly you can either set your environment variable NLS_LANG=.ZHT16MSWIN950 (CP936 seems to be not supported by Oracle) or change your codepage before running sqlplus.exe with command chcp 437. With this proper settings you will not see any Chinese characters as you probably would have expected.
Some time ago my PL/SQL stopped showing characters åäö.
I've tried reinstalling oracle_home_11g, PL/SQL cleaned the registry but the problem remains.
Anyone know why?
Most probably it is due to the mismatch between the locale-specific NLS characterset and the database characterset. Or else, the NLS_LANG value is not correctly set in the OS environmental variable.
Have a look at Why are junk values/special characters/question marks displayed on my client?
Your client charaterset doesn't match with database characterset.
You can compare between :
-- locale-specific characterset
select value
from v$nls_parameters
where parameter = 'NLS_CHARACTERSET';
-- database characterset
select value
from nls_database_parameters
where parameter = 'NLS_CHARACTERSET';
If you see a mismatch between the two, then set the locale-specific NLS characterset to that of database characterset.
If the above charactersets match, then you need to set the NLS_LANG value in the OS environmental variable.
For Windows OS, the format is:
[NLS_LANGUAGE]_[NLS_TERRITORY].[NLS_CHARACTERSET]
Follow the instruction in the documentation regarding setting up the NLS_LANG : Setting the NLS_LANG Environment Variable for Oracle Databases
I'm facing a character discrepancy issue while extracting data from db tables.
I've written a PL/SQL code to spool some data to .txt file from my db tables and running this sql using unix shell but when I'm getting the spooled file, the result set is a changed one from the one at back end.
For example:
At back end: SADETTÝN
In Spooled txt file : SADETTŸN
If you look at the Y character, it is a changed one. I want to preserve all the characters the way they are at back end.
My db's character set:
SELECT * FROM v$nls_parameters WHERE parameter LIKE 'NLS%CHARACTERSET'
PARAMETER VALUE
NLS_CHARACTERSET WE8ISO8859P1
NLS_NCHAR_CHARACTERSET WE8ISO8859P1
And Unix NLS_LANG parameter :
$ echo $NLS_LANG
AMERICAN_AMERICA.WE8ISO8859P1
I tried changing NLS_LANG parameter to WE8ISO8859P9(Trukish characterset) but no help!
Could anyone let me know the solution to this problem?
I presume that you are trying to visualize your file with "vi" or something similar.NLS_LANG parameter is used only by your database to export to your file.For your editor(vi), you need to set the LANG parameter to the corresponding value to your NLS_LANG.
Exemple : For ISO8859P1 american english you have to do
export LANG=en_US.ISO8859-1
In other words your file is just fine it's your editor who doesn't know what to do with your Turkish characters.
You should use NCHAR data types. More information is available at Oracle Documentation - SQL and PL/SQL Programming with Unicode
For spooling from SQL*Plus, you need to set the NLS_LANG environment variable correctly. Here is a similar question in stackoverflow.
I have an oracle database which nls character set is set to ALS32UTF8 and nls nchar character set is set to UTF8.
But however if i insert any data to a nvarchar column in a table.
Subsequent when i do a select the data i got is ???.
Why is this so?
The funny thing is that using TOAD i can read view the correct nvarchar data using the schema brower - > data
But if i use sql to do a select i get ???.
Any idea anyone and how to resolve this?
What is the NLS_LANG setting on your client? For a good reference on NLS parameters, read this FAQ by Oracle. For additional reading on Unicode, see this essay by Joel Spolsky.
You need to set the clients NLS_LANG to utf.
sqlplus uses these environent variables (registry parameters on windows):
(You may need to use sqlplusw.exe to use utf-8 on windows.)
NLS_LANG=AMERICAN_AMERICA.AL32UTF8
LC_CTYPE="en_US.UTF-8"
ORA_NCHAR_LITERAL_REPLACE=true
See also : Inserting national characters into an oracle NCHAR or NVARCHAR column does not work