E R skribis 2007-10-19 17:14 (-0500): > The problem I need to understand now is the following: > # using mod_perl 1.28 > # note: binmode(STDOUT, ":utf8") has no effect > $r->print($x); # emits 1 octet > $r->print($y); # emits 2 octets > I get similar behavior when storing $y into an Oracle DB - a string of length > 2 > is stored. Storing $x, however, results in a length 1 string.
These don't use a filehandle, so :utf8 or :encoding layers don't work. That leaves two options: either use the encoding functionality by the module (if any), or encode manually. AFAIK, mod_perl does not provide transparent encoding for output. DBD::Oracle does, but you need to enable it. (Don't ask me how; I bailed out when I saw the complexity of Oracle's charset/encoding support.) When doing the encoding manually, I strongly suggest that you subclass the module in question, to prevent that the logic is spread all over the place. (And please release your subclass to CPAN :)) > So it seems that in light of this one should always use Encode::encode with > these modules to ensure the data is represented the way you want it. Encode::encode, Encode::encode_utf8, or utf8::encode. > Stated another way: if you use a module which converts a Perl string to an > octet > sequence, and there is no provision for specifying an encoding, that should > be a > red flag that you need to encode the string before you send it to the module. Well stated. I have collected a summary at http://juerd.nl/perluniadvice that is neither complete nor accurate, but it provides more information than most documentation does. Unfortunately I lack tuits to send bug reports and make patches. -- Met vriendelijke groet, Kind regards, Korajn salutojn, Juerd Waalboer: Perl hacker <[EMAIL PROTECTED]> <http://juerd.nl/sig> Convolution: ICT solutions and consultancy <[EMAIL PROTECTED]>
