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
