If that is really true (a perl string value representing e-acute, when printed, really is just one byte), I would expect that there is something else on the new server (not directly involved with DBI or DBD, and maybe only tangentially related to Perl) that is converting data from utf8 to some non-Unicode encoding (typically cp1252 or iso-8859-1) - I don't know what it could be (maybe a locale setting or other detail affecting your shell environment?), but some other tests of unicode/utf8-related actions on old vs. new systems (assuming the old system is still accessible/usable) could help diagnose where the difference(s) may be.
As for "combing a multitude of code" to handle the encoding difference properly (assuming that the fix can only be the one you've discovered so far, using Encode::encode_utf8 where necessary), how many times (in how many places) do you have: use DBI;?
One approach would be to change that to something like: use MyDBI;, and compose your module to inherit most of the functionality of DBI, but only replace the functions you use that actually return strings from the database. Your module would start with:
package MyDBI; @ISA = qw(DBI::db); use DBI;
Ideally, there would be some other, config-level change, like the mysql_enable_utf8 setting that you've already tried, that would make this approach unnecessary. But writing your own 'wrapper' module for DBI is a sensible and workable fallback.
BTW, if you can manage it, it may help to show us relevant bits of your code, so we see how you've done the DBI connect and a given query, plus snippets of actual data (preferably as Data::Dumper style output).
One other issue you didn't mention: are your old and new systems both talking to the same Mysql server, or was there an upgrade of that as well?
In reply to Re: UTF8 between versions
by graff
in thread UTF8 between versions
by edgreenberg
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |