Re: How can I convert Characterset Properly on JDBC?

From: J.P.K <stmkjp_at_hotmail.com>
Date: 19 Apr 2002 00:39:18 -0700
Message-ID: <d6f86d9c.0204182339.33e9fd20@posting.google.com>

Thanks for your response. Here's my feedback.

afilonov_at_yahoo.com (Alex Filonov) wrote in message news:<336da121.0204181439.aa3c301_at_posting.google.com>...
> stmkjp_at_hotmail.com (J.P.K) wrote in message news:<d6f86d9c.0204172318.3e0f7a8b_at_posting.google.com>...
> > Hi,All.
> >
> > Current Situation:
> > DBMS : Oracle8i Using NLS_CHARACTERSET=AMERICAN_AMERICA.WE8DEC
>
> It's NLS_LANG, isn't it? NLS_CHARACTERSET should look like WE8DEC.

Yes, you're right. It's NLS_LANG.

> Looks like there is a different characterset for NLS_NCHAR_CHARACTERSET.
> Check if you can access table sys.props$. If so, run the statement:
> select name, value
> from sys.props$
> where name like 'NLS%'
>

results related with charset were as follows.

NLS_LANGUAGE              :     AMERICAN
NLS_TERRITORY             :     AMERICA
NLS_CHARACTERSET          :     WE8DEC
NLS_NCHAR_CHARACTERSET    :     WE8DEC



> > 

> >   I'm Korean and uses KO16KSC5601 characterset, but

> > in Pro*C or in SQL*Plus it's ok to use Korean characters
> > because I matched NLS_CHARACTERSET with server in environment file.
>
> Sounds a little bit strange. WE8DEC doesn't support Korean characters, as far as
> I know. Same goes for ISO 8859-1. I wonder how Korean characters are stored in
> the database. If NLS_NCHAR_CHARACTERSET is set to something which supports
> Korean characters (starting with KO, 16 or 32 bit charset) that's the
> characterset actually used in sqlplus and Pro*C.
> Could you please post NLS_LANG values in server and client environments?
>

Server & Client NLS_LANG value's are same : American_America.WE8DEC ===> OK only with same NLS_LANG value. when they're different,

    Korean Language not supported. ( broken korean chars in select & store)

> >
> > Problem :
> > When using JDBC, Korean Chars broken while English chars OK
> > in ResultSetObject. ( str = rset.getString(1); returns broken characters)
> >
> > What I tried :
> > String newResult = new String(rset.getBytes("8859_1"),"KSC5601");
> > --> some of Korean chars converted well, but still some other's not.
> >
> > Question :
> > 1) I think "8859_1" is not fully compatible with "WE8DEC".
>
> It is. But both only have english alphabet, western european extensions, like
> ummlauts and accents, numbers and punctuation characters. They don't support
> Korean characters.
>

Yes, You're right. Therefore, (Theoretically) i think

new String(rset.getBytes("8859_1"),"KSC5601") function should work like this.

english alphabet -> same code
korean char decoded with we8dec -> decode with ksc5601.

partly it works, but maybe some korean char & symbols code value is overlapped with we8dec character code value and not converted???

> > What characterset alias should I use for getBytes method?
> > I tried "WE8DEC", but jvm gave me an UnsupportedEncodingException error.
> >
> > 2) Is there any other way for obtaining proper results?
> > ( except for change DBMS server's NLS_CHARACTERSET, it's rejected by
> > Server Admin group...it's SAP ERP DB and they said they don't
> > recommend changing Server env. for Reliability...:-( )
>
> Try to test conversion on Oracle side:
> Use convert function. It has three parameters, 1st is a string to be converted,
> 2nd is a source characterset, 3rd is a target characterset. Example:
>
> select convert('abcdef', 'WE8DEC', 'WE8ISO8859P1') from dual
>
> prints abcdef converted from WE8DEC to WE8ISO8859P1.
>

I tried oracle convert function, but not work...  ===> result characterset is broken anyway, but it's somewhat different

      pattern.

Any help will be appreciated. Received on Fri Apr 19 2002 - 02:39:18 CDT