Re: JDBC encoding problem - Mailing list pgsql-sql

From Kurt Overberg
Subject Re: JDBC encoding problem
Date
Msg-id 3F310E4F.6080102@hotdogrecords.com
Whole thread Raw
In response to Re: JDBC encoding problem  ("LEON" <ldai@accunettech.com>)
List pgsql-sql
It seems like I was able to get it to work with UTF-8.  I found this
nifty little page: http://www.anassina.com/struts/i18n/i18n.html which
explained how to handle this within Jakarta Struts.  It SEEMS like when
reading the data from the database I don't need to explictly convert it
to UTF-8, it just happens.  When I converted my database, I dumped it
out, ran an ASCII to UNICODE converter, then loaded the data back in.  I
was able to enter japanese characters and read them back from the DB
okay.  My big question is completeness.  I really have no idea if I'm
handling every case since it "just seems to work".   Thanks for the reply!

/kurt



LEON wrote:
> I have met the same problem when  I deal with chinese.
> I guess tomcat and jdbc produced this bug.
> But you may solute the charset display problem.
> You change the database's charset is useless when you connected DB with JDBC. You should convert Input Text with
UTF-8before saved in database. When you fetch data from DATABASE ,you should convert output data with some charset
(F.E:GBK)before you display the data in page. 
>
>
> There is some java code I used.Hope they will help you.
> //Output:
> OutputStream fileOut = new FileOutputStream(outputFileName);
>
> fileOut.write(data.getBytes("GBK"));  //GBK、GB2312、BIG5、UTF8
>
> //Input:
> InputStream fileIn = new FileInputStream(inputFileName);
>
> int i = fileIn.read(buff);
>
> String data = new String(buff,"UTF8");
>
>
> Best regards.
>                                                   leon
>
> ----- Original Message -----
> From: "Kurt Overberg" <kurt@hotdogrecords.com>
> To: <pgsql-sql@postgresql.org>; <pgsql-jdbc@postgresql.org>
> Sent: Wednesday, August 06, 2003 1:11 AM
> Subject: [SQL] JDBC encoding problem
>
>
>
>>I'm having a rather strange problem that I'm hoping someone can help me
>>with.  I'm using Struts 1.0/jsp on Debian linux under Tomcat 4.1.x and
>>the blackdown JVM  .  I'm attempting to convert my current SQL_ASCII
>>database to UNICODE.  I'm new to this, so am most likely making a few
>>mistakes.  Here's what I've done so far:
>>
>>o  Converted database encoding to be UNICODE.  I'm pretty sure this part
>>worked okay.  (did a pg_dump, then iconv -f 8859_1 -t UTF-8, then
>>created new db with encoding UNICODE and reloaded- no errors upon reload)
>>
>>sparky:~$ psql -l
>>         List of databases
>>    Name    |  Owner   | Encoding
>>-----------+----------+-----------
>>  unitest   | kurt     | UNICODE
>>  template1 | postgres | SQL_ASCII
>>(2 rows)
>>
>>
>>o  set client_encoding to 'UTF8';
>>
>>o  In my JSP files, I set the following at the top of each:
>>
>><%@ page lanuage="java" pageEncoding="UTF-8" %>
>>
>>
>>Now, to test this, I go to a japanese page, copy some text, then paste
>>it into a form, that gets submitted to the server and saved into the DB.
>>Then I try to display what I got back from the database.  It comes out
>>garbled.  HOWEVER- if I leave the 'pageEncoding' out of my display .jsp
>>file it still comes out garbled, UNTIL I set UTF-8 manually in my
>>browsers Character Encoding settings (both mozilla and IE).  Then the
>>japanese characters render fine (just like I entered them).
>>
>>Very strange.  What's confusing is that when I set the pageEncoding to
>>'UTF-8', the characters don't render properly, and as far as I can tell,
>>thats the same as manually setting the browser manually.  I must be
>>doing something wrong because I get the same results in IE and mozilla
>>(recent build).
>>
>>What may be the problem- I don't do anything differently when getting
>>the data out of the database, just standard
>>resultset.getString("column");  Do I need to change that call, to handle
>>the potentially UTF-8 encoded strings?  I can't find anything on that at
>>all with google/usenet.
>>
>>Any and all help, suggestions or pointers would be greatly appreciated.
>>
>>Thanks!
>>
>>/kurt
>>
>>
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 4: Don't 'kill -9' the postmaster
>>
>
>
> ---------------------------(end of broadcast)---------------------------TIP 3: if posting/reading through Usenet,
pleasesend an appropriate      subscribe-nomail command to majordomo@postgresql.org so that your      message can get
throughto the mailing list cleanly 
>
>



pgsql-sql by date:

Previous
From: "Viorel Dragomir"
Date:
Subject: Re: looking for empty fields
Next
From: Jodi Kanter
Date:
Subject: Re: looking for empty fields