(ok 2.11.6) SET NAMES for importing with command-line client

dumped by mysqldump

dumped by phpmyadmin

Logged In: YES
user_id=126268
Originator: YES

File Added: firestats_sites-phpmyadmin.sql

Logged In: YES
user_id=126268
Originator: YES

using PHPMyAdmin 2.11.2.1deb1
MySQL version 5.0.45-Debian_1
PHP version PHP 4.4.4-9+lenny1

Logged In: YES
user_id=210714
Originator: NO

When exporting with phpMyAdmin, do you see a "character set of the file" just on top on the compression modes dialog? If yes, which character set did you choose?

Logged In: YES
user_id=1383652
Originator: NO

>When exporting with phpMyAdmin, do you see a "character set of the file"
you only get this option on "export" if you set "AllowAnywhereRecoding" = true;
Otherwise the dump is always utf8 by default (at least on my box and on Michal's demo).

Logged In: YES
user_id=126268
Originator: YES

Nope, no character set option in my export screen.
On the other hand, I keep seeing warnings like:
Notice: ob_flush() [ref.outcontrol]: failed to flush buffer. No buffer to flush. in /usr/share/phpmyadmin/libraries/ob.lib.php on line 101
from xdebug.

See attached screen shot.
File Added: pma.png

Logged In: YES
user_id=210714
Originator: NO

As windkiel said, try setting in your config.inc.php the AllowAnywhereRecoding parameter to true (you'll need the iconv or recode PHP extensions).

Anyway you should be running the latest stable version 2.11.4 before reporting a bug. Tomorrow I'll try to export/import your mysqldump file.

Logged In: YES
user_id=210714
Originator: NO

Please attach a screenshot of phpMyAdmin browsing the table produced by importing firestats_sites-mysqldump.sql with the mysql command-line utility on your server. I tried on mine and the characters for id 4 do not look like Hebrew at all.

Maybe it's because the default charset for your table in your mysqldump file is latin1.

Also, what is the MySQL connection collation on your home page of phpMyAdmin?

good dump with mysqldump

Logged In: YES
user_id=126268
Originator: YES

Few things:
1. PMA never shows Hebrew correctly, even if my application does.
2. When I import the firestats_sites-mysqldump.sql I attached before, it doesn't work in my application, must have made some mistake with it.
3. I created a new dump file (attached, firestats_sites-mysqldump2.sql) which works correctly in my application (when I import it, the Hebrew text appears correctly).

I am attaching three pairs of screen shots:
The first pair is when everything is good before I imported anything.
The second pair is after I imported the pma export.
The third pair is after I imported firestats_sites-mysqldump2.sql.

each pair consists of
a. screen shot of the table browse in PMA.
b. screen shot of how FireStats displays the data.

File Added: firestats_sites-mysqldump2.sql

screen shots of how data looks in PMA and in FireStats at various states.

Logged In: YES
user_id=126268
Originator: YES

File Added: pma-vs-firestats.zip

Logged In: YES
user_id=210714
Originator: NO

Thanks for your screenshots. Don't you find weird that your Hebrew data does not look correct in PMA (see before_import_PMA) but if you choose in PMA the Hebrew language, you see correctly the Hebrew characters of the PMA messages?

I think this is because there is a mismatch between the charset of your table (latin1) and the real data in it.

Logged In: YES
user_id=126268
Originator: YES

I just made a small test:
created a simple table with collation encoding, and entered a single Hebrew string.
it appeared correctly in PMA.

when I exported and imported it back (through PMA) the data got mangled, and not only that, I also got TWO rows, one of which was empty.
the export looks like:
INSERT INTO `test` (`s`) VALUES
(''),
('×~Q×~S×~Yק×~T');

so again, something was wrong with the export.

I don't think the problem this ticket is about is related to the table collation.
(There is another problem with how Hebrew is displayed, which is probably because of the latin collation).

Logged In: YES
user_id=126268
Originator: YES

BTW:
That junk in the export is unicode copy pasted from my terminal (which does not support unicode). the real problem is that there were two exported row for some reason.

I tried again and was not able to reproduce it.

a bit more info:
if I import the input through PMA and specify that the file encoding is utf8 the Hebrew imports correctly.
all my previous imports were using the command line:
cat test.sql | mysql -u user --password=pass db

this lets me think this bug is not as serious as I thought.
regardless, it would be good if the PMA were agnostic to the file encoding when importing and exporting.
all the information for importing should be in the file already. what happens if the user exports two tables of different encodings into the same file? he will never be able to import them back like that.

Logged In: YES
user_id=210714
Originator: NO

"if I import the input" -> do you mean your new small test?

"should be agnostic" -> well, with thousands of users using many charsets, such a problem should have been reported already; if it was not, it must not be serious (as you say); probably people just export/import using the default UTF-8 and it works.

Logged In: YES
user_id=1383652
Originator: NO

>probably people just export/import using the default UTF-8 and it works.
That's also what mysqldump is using (AFAIK).