I have a report which has Thai characters. If I run the report builder's report, the Thai characters display correctly, but if I run the report from the app, the Thai characters display as invalid characters.
NLS_CHARACTERSET - AL16UTF16
NLS_NCHAR_CHARACTERSET - AL16UTF16
in my DB.
Related
I am working with an Oracle 12.2 database. The database characterset is WE8MSWIN1252 (ie. an ASCII characterset).
The database contains a table with a CLOB column (according to Oracle SQL Developer). Some values in this column contain non-ASCII characters (I know this as when using ASCIISTR function on this column I can see the escaped non-ASCII character codes).
How is this possible? I thought ASCII characterset databases could only store unicode in NVARCHAR, NCLOB etc.
(I only discovered this when I was using a linked server to the Oracle db from SQL Server - when I ran an OPENQUERY on the table with the CLOB, it returned ? for the non-ASCII characters. I changed the OPENQUERY query string to use TO_NCLOB(clob_column) and it returned the non-ASCII characters.)
Any ideas?
Thanks
From wikipedia WE8MSWIN1252 description:
Windows-1252 or CP-1252 (code page 1252) is a single-byte character encoding of the Latin alphabet, used by default in the legacy components of Microsoft Windows for English and many European languages including Spanish, French, and German.
So, it a CLOB in a database with this charset can store strings like éàè. And ASCIISTR returns escaped codes because these chars are not defined in ASCII, for example:
SQL> select asciistr('é') eaccent, asciistr('e') e from dual;
EACCENT E
---------- -
\FFFD\FFFD e
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.
I have data which contains special characters like à ç è etc..
I am trying to insert the data into tables having these characters. Data gets inserted without any issues but these characters are replaced with with ?/?? when stored in tables
How should I resolve this issue?I want to store these characters in my tables.
Is it related to NLS parameters?
Currently the NLS characterset is having AL32UTF8 as seen from V$Nls_parameters table.
Is there any specific table/column to be checked ? Or is it something at the database settings ?
Kindly advise.
Thank in advance
From the comments: It is not required that column must be NVARCHAR (resp. NVARCHAR2), because your database character set is AL32UTF8 which supports any Unicode character.
Set your NLS_LANG variable to AMERICAN_AMERICA.AL32UTF8 before you launch your SQL*Plus. You may change the language and/or territory to your own preferences.
Ensure you select a font which is able to display the special characters.
Note, client character set AL32UTF8 is determined by your local LANG variable (i.e. en_US.UTF-8), not by the database character set.
Check also this answer for more information: OdbcConnection returning Chinese Characters as "?"
I'm loading a csv file using sqlldr.
the file contains the symbol "€" which is inserted into a VARCHAR2 column.
After the load, the database displays '¿' instead of the euro symbol.
I have specified the characterset in the control file during the load:
LOAD DATA
CHARACTERSET WE8MSWIN1252
I'm runing all of this on a Solaris machine, which by the way can't display the '€' symbol, I gives me a '.' instead when I hit the key to get the €.
We are using the data for BI purposes, so we have to keep the varchar2 column, even though changing its type to nvarchar2 inserts the € symbol correctly.
Can you suggest any other solution for the issue?
When I run locale command on the machin, I get :
LANG=
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
and my NLS DATABASE PARAMETERS Are:
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET WE8DEC
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
I have tried setting the NLS_LANG variable, but nothing seems to work.
Regards.
Your database is not configured to support the Euro character in a VARCHAR2 column. Your database's NLS_CHARACTERSET of WE8DEC means that it uses the old DEC MCS character set. That character set long predates the Euro character (it's even older than the ISO 8859-1 character set that also predates the Euro). So you can't validly store a Euro character in a VARCHAR2 column in your database.
You could change the database character set to something that supports the Euro character. There are many such character sets but I would guess that ISO-8859-15, Windows-1252, or UTF-8 would be the easiest migrations. Personally, I'd always prefer Unicode (UTF-8 which is the AL32UTF8 character set in Oracle) but you may have a reason to prefer a single-byte character set. Alternatively, you could declare this column (and any others that need to use the Euro character) to be NVARCHAR2 columns since your national character set supports Unicode. Supporting NVARCHAR2 columns may require changes to your front-end applications. If you can change the database character set, that would be my strong preference over adding NVARCHAR2 columns.
I understand that Oracle supports multiple character sets, but how can determine if the current 11g system where I work has that functionality enabled?
SELECT *
FROM v$nls_parameters
WHERE parameter LIKE '%CHARACTERSET';
will show you the database and national character set. The database character set controls the encoding of data in CHAR and VARCHAR2 columns. If the database supports Unicode in those columns, the database character set should be AL32UTF8 (or UTF8 in some rare cases). The national character set controls the encoding of data in NCHAR and NVARCHAR2 columns. If the database character set does not support Unicode, you may be able to store Unicode data in columns with these data types but that generally adds complexity to the system-- applications may have to change to support the national character set.
Unicode is a character encoding system that defines every character in most of the spoken languages in the world, Support for Unicode in Oracle Database:
Character Set Supported in RDBMS Release Unicode Encoding
AL24UTFFSS 7.2 - 8i UTF-8
UTF8 8.0 - 11g UTF-8
UTFE 8.0 - 11g UTF-EBCDIC
AL32UTF8 9i - 11g UTF-8
AL16UTF16 9i - 11g UTF-16
To Make sure your database is Unicode, please check the value of "NLS_CHARACTERSET" Parameter and it should be AL32UTF8 or AL16UTF16 from above list.
SQL>
SQL> SELECT * FROM v$nls_parameters WHERE parameter='NLS_CHARACTERSET';
PARAMETER VALUE CON_ID
--------------------------- ------------------- ----------
NLS_CHARACTERSET AL32UTF8 0
To Change the value of Parameter, Please Take the Fullback up because ALTER DATABASE statement cannot be rolled back and the Use following statements:
SHUTDOWN IMMEDIATE
STARTUP MOUNT;
ALTER SYSTEM ENABLE RESTRICTED SESSION;
ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
ALTER SYSTEM SET AQ_TM_PROCESSES=0;
ALTER DATABASE OPEN;
ALTER DATABASE CHARACTER SET AL32UTF8;
SHUTDOWN IMMEDIATE;
STARTUP;