[Catalyst] Catalyst Unicode woes ...

Tobias Kremer list at funkreich.de
Thu Aug 9 12:18:07 GMT 2007

Zitat von Tatsuhiko Miyagawa <miyagawa at gmail.com>:
> Similarly even if your templates are encoded in utf-8,
> Template-Toolkit doesn't know which encoding they are in, until you
> set BOM to your templates or use Template::Provider::Encoding to
> explicitly specify the encoding to decode the template.

So you're saying that there's no sane way using TT without
Template::Provider::Encoding (or something similar)? I admit I haven't really
grasped this whole Unicode issue fully yet (and I don't seem to be the only one
as it's causing trouble for lots of people) but this really should be more DWIM
out of the box if possible ... Especially since utf8 is becoming the de-facto
standard for encoding everything should "just" work. Yeah, I know, I'm naive :)

> Concatinating utf-8 flagged variables with utf-8 encoded byte string
> causes automatic SV upgrade, which causes double utf-8 encoded string.

Hmmm. So my templates are utf8 _ENCODED_ and the strings coming in from other
perl modules are just utf8 _FLAGGED_. When TT concats them together during
process() the result is wrecked because of the automatic upgrade. Correct?

> You might want to look at the manpages of encoding::warnings and perlunitut.

Just quickly tried out encoding::warnings which outputs nothing at all but I'll
give it a closer look.

> I have a couple of hacks to workaround that, like
> Template::Stash::ForceUTF8 that you mentioned, and
> Encode::DoubleEncodedUTF8 is probably the most evil one, that "fixes"
> the double-encoded utf-8 strings back to what you mean. Too evil to
> use on production but would be still useful to catch bugs like that in
> testing.

Hacks are not an option here :) And there must be a "right" way to do it.


More information about the Catalyst mailing list