Re: How can I convert Characterset Properly on JDBC?

stmkjp_at_hotmail.com (J.P.K) wrote in message news:<d6f86d9c.0204182339.33e9fd20_at_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.

Again, WE8DEC doesn't represent Korean characters. If you can store some Korean characters in WE8DEC, it's strange to say the least.

>
> 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.

I'm afraid you're out of luck here. The basic problem is that you need 16-bit (at least) characterset representing Korean characters, when on the database side you have 8-bit characterset which doesn't represent Korean characters. Received on Fri Apr 19 2002 - 12:56:53 CDT