comment on

How do you know what encoding the mysql shell uses? How do you know what your console uses as encoding? How do you know what the web browser did with the encoded data before putting it into the clipboard?

You need to eliminate as many conversion steps as possible and check the consistency of the remaining. I wouldn't rely on MySQL to upgrade or change the encoding. Use ~~Scalar::Util~~Devel::Peek to dump the scalars before sending them to the DB to see whether Perl encodes them as UTF8 or Latin1. Then retrieve them via DBI and check the encoding again. It should be the same as you put in, but maybe it isn't. Also, the strings should ideally be bytewise identical.

If Encode::decode() works, then likely your data is in UTF8 when you retrieve it from MySQL. If it already is in UTF8 when you put it in, it could be an idea to keep all data in UTF8 throughout your application and just convert at the output stage to Latin1.

Update: moritz pointed out that I want Devel::Peek, not Scalar::Util

In reply to Re^3: OT? Character set issues with MySQL/CGI::Application by Corion
in thread OT? Character set issues with MySQL/CGI::Application by cLive ;-)

Are you posting in the right place? Check out Where do I post X? to know for sure.
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
Want more info? How to link or How to display code and escape characters are good places to start.


Do you know where your variables are?
	PerlMonks