On Sun, Jul 27, 2008 at 11:53:22PM +0900, Tomita wrote:
> On Sun, Jul 27, 2008 at 07:57, Éric Cholet <[EMAIL PROTECTED]> wrote:
> >
> >
> > That's not quite correct, UNICODE will cause a template with no BOM to
> > be decoded as well as long as you provide ENCODING.
>
> Thanks. that's point.
>
> Using Unicode with TT ...
>
> (UNICODE = 1 and BOM code)
> or
> (UNICODE = 1 and ENCODING = "some encoding name")a
Again UNICODE is automatically set based on your Perl version. I
assume this is to determine if your Perl has the Encode module.
(Seems checking for Encode.pm might be a better approach.) Thus,
UNICODE is not something users need to normally set.
If you force UNICODE to zero, then no decoding will take place. I
cannot think of a reason to ever do this. Therefore, I'm not sure
there is a need to document it as a user configuration setting.
So, with a modern Perl version all you have to do is make sure your
templates have a BOM and Template::Provider will decode it w/o any
configuration requirements.[1]
IF your templates do not have a BOM, then you can set
"ENCODING" to *force* your templates to be decoded.
Decoding is also skipped (either with BOM or ENCODING) if the template
content has the utf8 flag set (e.g. if read from a handle with a
decoding layer set).
IIRC, all generated (Perl) templates begin with "use utf8". So the
constants in the generated templates can include utf8 (regardless of
what encoding your initial templates are correctly decoded as).
[1] providing that your BOM matches one of the hard-coded values. I'm
not familiar with BOMs enough to know if this is a complete list.
my $boms = [
'UTF-8' => "\x{ef}\x{bb}\x{bf}",
'UTF-32BE' => "\x{0}\x{0}\x{fe}\x{ff}",
'UTF-32LE' => "\x{ff}\x{fe}\x{0}\x{0}",
'UTF-16BE' => "\x{fe}\x{ff}",
'UTF-16LE' => "\x{ff}\x{fe}",
];
--
Bill Moseley
[EMAIL PROTECTED]
Sent from my iMutt
_______________________________________________
templates mailing list
[email protected]
http://mail.template-toolkit.org/mailman/listinfo/templates
