[rt-users] mysql/mariadb returns wrong utf8 for TT: 'Wide character in FCGI::Stream::PRINT'

[Peter Vereshagin]

Como esta, dev-apps-bugzilla?

I rose a question at http://groups.google.com/group/comp.lang.perl.misc/browse_thread/thread/93a3f08cd9a0c574
but seem no qualified help. As a remind, the question is: there are three sides to seem responsible, whom should I ask best?

I put this here because the inpact is a somewhat deeper and here is the scoop:

- when I connect to mariadb with 'set names utf8', I prefer 'set character set utf8' because I don't use l10n table/column names, I get some different kind of utf8 scalar variable, than when I connect having the mysql_enable_utf8=1 inside the dsn string for DBI's connect method.
- This impacts the how FCGI.pm behaves: it takes its FCGI::Stream::PRINT to substitute the placeholders in Template.pm of the Template::Toolkit. This is because since some of the version of FCGI.pm package, as explained on http://www.google.ru/search?hl=ru&inlang=ru&newwindow=1&ie=windows-1251&q=Wide+character+in+FCGI%3A%3AStream%3A%3APRINT it does not accept 'wrong' utf8 scalars any more.

As a result, if you just don't care what you send to DBD::mysql as a sql, or to T::T as a variable to put in-place, the 'correct' utf8::encode'd utf-8 stringor the octets , it's typically the 'wrong' utf-8 string. Sad to say, the DBD::mysql supplies values this way from database, too.

If, again, you use the 'typical' kind of solution, which the 'set names' on the code is.
As a fact the my one, the 'worksforme' solution aforementioned is 'correct' for such a case. E. g., I use to patch my bugzilla to replace 'set names utf8' in favour of dsn line change on every upgrade required by security. I believe RT users suffer from the same.

Thanks for attention.
 
73! Peter pgp: A0E26627 (4A42 6841 2871 5EA7 52AB  12F8 0CE1 4AAC A0E2 6627)
--
http://vereshagin.org