[rt-users] utf8 behavior and approach

[Peter Vereshagin]

Como esta, rt-users?

I believe many of you guys use both mysql and fastcgi or want to do that for
RT. There was a problem on the list and I'm looking forward to hear if it's
about that:
http://lists.bestpractical.com/pipermail/rt-users/2010-July/065600.html

The solution is:

Specifying the 'mysql_enable_utf8=1;' in the DSN line solves all troubles. This
means to patch the existing applications, e. g., Bugzilla and perhaps RT.

Beware that there should be no 'mysql_enable_utf8' attribute in the attributes
hash for the DBI->connect. I have no idea if RT can do this without a patch.

More about this should be seen from me on a DBD::mysql mailing list.

Thanks for attention.

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

[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