Re: [SQL] JDBC encoding problem

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-8 before 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(at)hotdogrecords(dot)com>
> To: <pgsql-sql(at)postgresql(dot)org>; <pgsql-jdbc(at)postgresql(dot)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, please send an appropriate subscribe-nomail command to majordomo(at)postgresql(dot)org so that your message can get through to the mailing list cleanly
>
>