The current DB char set is as follows:
NLS_CHARACTERSET ZHS16GBK NLS_NCHAR_CHARACTERSET AL16UTF16
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:
ASCIISTR(EXPENSE_CODE_DESCRIPT 1 2 ???????-??
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.