in reply to Re^2: Can't write cyrillic to DBD::mysql
in thread Can't write cyrillic to DBD::mysql

Checking with Devel::Peek will only tell you whether Perl thinks that the string is encoded as utf8. I would print the output and then pipe it through hexdump or od -x to really see what octets are output.

But if the data really is utf8, then the culprit seems to be DBD::mysql and how it handles/accepts utf8. Are you using placeholders?

Replies are listed 'Best First'.
Re^4: Can't write cyrillic to DBD::mysql
by Wolfgang (Novice) on Jun 29, 2010 at 12:04 UTC

    Devel::Peek dumps the string too; before trusting Devel::Peek I wrote my own hexdump, but the data stays the same :-)

    I tried doing just a 'dbh->do(sql) and a dbh->do(sql, undef, @placeholder). The result is the same: The cyrillic characters are replaced by '?'.
    Same effect happens with greek Characters, Xilman was supecting that everything not in code block 01 of utf might fail.

    Wolfgang
[reply]

      My guess, which is totally not based on any facts, is that your table/column stores its data in Latin-1, even though you can send/receive the data in utf8. I don't know enough about MySQL to know whether that's a possibility though, so take this with a large grain of salt.

[reply]

        It is a long time since I last used MySQL but I recollect tables needed to be created with a CHARSET. We used to do something like:

        CREATE TABLE mytable
(

  columns
) TYPE = INNODB
DEFAULT CHARSET utf8;

        [download]
[reply]
[d/l]

        That was my guess, too. But I can store data with phpMyadmin and I can check it with the Mysql Query Browser which shows me the binary representation. And of course, that works with characters that do not have a representation in Latin-1

        So my best guess is, that some init is done wrong with perl but working with phpmyadmin

        Wolfgang
[reply]

In Section Seekers of Perl Wisdom