I have an Oracle DB's charset configured for Korean language and things in there are English and KOrean and they are working fine.
If i try to import a txt file with Chinese chararcters into the DB. It doesnt show correctly on query.
Is there any way I can solve this ? Since I find that there are many charset / NLS language options througout DB settings such asNLS_lang.
I read from others that they have the following response. Any alternative beside changing the whole DB charset ?
Recreate the database with the correct character set
Convert the database to AL32UTF8. Documentation link
Change the databases National Character Set to AL32UTF8 & change your application to use NVARCHAR2()/NCHAR() datatypes instead of VARCHAR2() (documented at the same link as above)
The current DB char set is as follows:
I Should say I m trying to import a Korean txt file into it and it shows quesion marks. Ofcos it display properly in excel as Korean.
The results of running SELECT ASCIISTR(expense_code_description_kor) FROM Kledger is like:
I'm a bit confused. Initially, you said that Korean and English were working and that Chinese was the problem. In your most recent post, you're saying that importing Korean is failing.
Your database character set is a Chinese character set. If things are being done correctly, you should be able to store Chinese data properly. You should not be able to store Korean or English data in a VARCHAR2 column, however. If you are saying that you are apparently doing that successfully, that implies that your NLS_LANG settings are incorrect which will lead to problems down the line.
Yes. that's the case. I said it wrong at the very first. The original DB is Chinese chars but now it needs to incorporate Korean chars in it as well.
So Chinese are fine on the DB but Korean becomes question marks.
But it seems to me that it's not possible. Actually I have read from other sites that the only way to do it is to recreate the whole DB. Just wonder if
there's any other way round it.
Unless you want to store the Korean and English data in NVARCHAR2 columns (which would not generally be recommended and may require application changes to support), you'd need to change the database character set to AL32UTF8. You can probably use the Database Migration Assistant for Unicode to convert the database without recreating the whole thing.
Thanks very much. I was looking at csscan and this MIgration assistant seems easier when i have applied the patch.
I just wonder how people find out whether the original and target encoding system are superset or subset of each other. As there seems not many clear places to find out. Appreciate your help.