From: | Emi Lu <emilu(at)encs(dot)concordia(dot)ca> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: JDBC to load UTF8@psql to latin1@mysql |
Date: | 2012-12-14 20:10:47 |
Message-ID: | 50CB87C7.5070600@encs.concordia.ca |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 12/14/2012 01:37 PM, Emi Lu wrote:
> Hello All,
>>> Meh. That character renders as \310 in your mail, which is not an
>>> assigned code in ISO 8859-1. The numerically corresponding Unicode
>>> value would be U+0090, which is an unspecified control character.
>>
>> Oh, scratch that, apparently I can't do hex/octal arithmetic in my
>> head first thing in the morning. It's really U+00C8 which is perfectly
>> valid. I can't see a reason why that character and only that character
>> would be problematic --- have you done systematic testing to confirm
>> that that's the only should-be-LATIN1 character that fails?
>
> Finally, the problem is resolved:
>
> SHOW VARIABLES LIKE "character\_set\_%";
> +--------------------------+--------+
> | Variable_name | Value |
> +--------------------------+--------+
> | character_set_client | latin1 |
> | character_set_connection | latin1 |
> | character_set_database | latin1 |
> | character_set_filesystem | binary |
> | character_set_results | latin1 |
> | character_set_server | latin1 |
> | character_set_system | utf8 | -- here mysql uses utf8 for
> character_set_system.
Another try is that if I change my client tool encoding set, I do not
even need my java transition. All right, good to learn from this.
Emi
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Van Dyk | 2012-12-14 20:11:05 | Quickly making a column non-nullable (without a table scan) |
Previous Message | AI Rumman | 2012-12-14 19:58:49 | Re: pg_restore error with out of memory |