Re: storing Japanese characters

Hello John,

First of all, 3F3F is "??" marks. It seems you already failed to insert the data. A wrong NLS_LANG is set or none character set encoding information doesn't exist on the client side. It would cause the wrong character set conversions between client and server. This means the data may be broken.

The character set encoding you input must be the same as NLS_LANG setting on your client, regardless of the server character set encoding.

If you are using Windows (ja), you should set NLS_LANG to
".JA16SJIS". Probably, you want to see English error message or
return message, then you could set "NLS_LANG" to
"AMERICAN_AMERICA.JA16SJIS". NLS_LANG is stored in the registry
"HKEY_LOCAL_MACHINE"-"SOFTWARE"-"ORACLE".
If you are using Unix OS which has IM(Input Method) for Japanese, you should set NLS_LANG to ".JA16EUC", usually. Some Unix OS default encoding could be Shift-JIS. In that case, NLS_LANG would be ".JA16SJIS". NLS_LANG is an environment variable.

Based on the above facts, please check your NLS_LANG setting on your client. Did you set NLS_LANG on the client? If so, what is it? What is the OS? What language is supported on the OS? Did you install different language Oracle client from OS's? The resolution for your case depends on these answers.

BTW, I would not recommend you using NCHAR, NVARCHAR2, and NCLOB data types for UTF8 character set.
NCHAR types are the "second character set data type" when you need two kinds of character sets at the same time. Originally, I believe, NCHAR was invented for FIXED width Asian data, like JA16SJISFIXED. So the naming "national character set" may not represent NCHAR correctly.
In your case, if you just need UTF8, you don't need NCHARs.

Thanks,
--
Shige Takeda
smtakeda_at_earthlink.net Received on Wed Dec 08 1999 - 02:58:33 CST