Hi,

Since I've moved from debian to buntu 8.04 I have strange encoding problems.
I used to latin1 encoding (but it should be latin2) and had no problem.
Ubuntu default encoding is utf8. When I login to the database and do sth
like:

select a,b from c_db;

I get wrong characters. After 'set names utf8' (the console is utf
either) it doesn't work properly.
When I change console settings to iso-8859-2 and latin2 in mysql - it is
wrong too...
The only properly working set is iso-8859-2 in console and latin1 in
database. May I know why?

I've got my database tables set to use utf-8, my connection to use
utf-8 and my terminal to us utf-8 and then inserting unicode data and
selecting it back out works fine. I would start from scratch with new
empty tables and see if that works for you too and then you can try
and diagnose piece by piece what's not working for you.

On Nov 20, 10:53am, Manhattan Project <ef...@poczta.fm> wrote:
> Hi,
>
> Since I've moved from debian to buntu 8.04 I have strange encoding problems.
> I used to latin1 encoding (but it should be latin2) and had no problem.
> Ubuntu default encoding is utf8. When I login to the database and do sth
> like:
>
> select a,b from c_db;
>
> I get wrong characters. After 'set names utf8' (the console is utf
> either) it doesn't work properly.
> When I change console settings to iso-8859-2 and latin2 in mysql - it is
> wrong too...
> The only properly working set is iso-8859-2 in console and latin1 in
> database. May I know why?

> Since I've moved from debian to buntu 8.04 I have strange encoding
> problems.
> I used to latin1 encoding (but it should be latin2) and had no problem.

Used latin encoding in what? It seems that you left all encoding
handling to the system and just hoped it did not clash. In short: it is
your responsibility as a programmer to determine what encoding to use,
stating what encoding to expect and to communicate that to the
subsystems (database, browser, or even OS).

> Ubuntu default encoding is utf8. When I login to the database and do sth
> like:
>
> select a,b from c_db;
>
> I get wrong characters.

Again, you get wrong characters in what? what are wrong characters? What
do they look like? If you see a lot of question marks or missing
characters, you are likely to see latin-1 rendered in utf-8. If you see
lots of the letter A with a tilde (~), this is the other way around.

So, what sub systems do you use? What encodings are they meant to use
and where have you configured that?

> After 'set names utf8' (the console is utf
> either) it doesn't work properly.

Please give a description of "it doesn't work properly". What did you
expect, what systems do you use and what did come out instead?

> When I change console settings to iso-8859-2 and latin2 in mysql - it is
> wrong too...
> The only properly working set is iso-8859-2 in console and latin1 in
> database. May I know why?

Sure. In fact, you should know. It is your system and you configured it.
But you fail to even say if you use the command-line client, a database
front-end program or a browser. Each have their own settings, so without
this knowledge you tell us really nothing. The front-end program Knoda,
for instance, is known to get the encoding wrong.

How did the data get into the tables? As far as I know, MySQL will
happily store invalid utf-8 in an utf-8 table if you have set all
settings to utf-8, because MySQL then sees not need for a conversion.
What is in the table is really just binary data. The ENCODING of that
data is set in the field, which is usually taken from the default in the
table or database.

There is a quick way to see what is really in the table. If you know a
field that contains a special character, show the HEX value of that
field. For a test: insert a string of just one special character into a
field, and select the HEX value for that field (HEX is a funtion). If
the hex value returns one byte (two characters in hex representation),
one byte is stored, and special characters are not stored in one byte in
utf-8.

Best regards,
--
Willem Bogaerts

Application smith
Kratz B.V.
http://www.kratz.nl/