![]() |
|
Do you know where your variables are? | |
PerlMonks |
Unicode and Youby belg4mit (Prior) |
on Aug 18, 2002 at 09:40 UTC ( #190967=perlmeditation: print w/replies, xml ) | Need Help?? |
... One code to rule them all
Ladies and gentleman of the Monastery of Perl; perl 5.8. If I could offer you, only one tip for the future 5-8 would be it. I haven't run perl 5.8 through too many production rigors yet, but as some of you may be aware I have been doing quite a bit of Unicode development. And for this, 5.8 wins hands down. If you plan on working with Unicode (or probably any exotic encoding), upgrade. Upgrade upgrade upgrade. Feed your sysadmin horse tranquilizers if you have to, but upgrade, you'll thank yourself later. In my recent foray into Unicode I've stumbled across two subtle bugs in 5.6. that'd drive you batty if you didn't know they were there. Firstly, while not a bug and it doesn't agree with the documentation it seems sometimes the utf8 pragma is required for UTF-8 strings. With utf8 on in 5.6.0 and 5.6.1 the regexpen s/^\s{1,0}// and s/^\s{0,0}// (and potentially others, those just happen to be what I ran into, and yes of course they are silly regexps, but they were generated on the fly) will consume all leading whitespace. How's that for lovely? The other bug is a fair bit more subtle. When doing something like print join("", map(chr, 0x17d, 0x17e)) in 5.6.0 an extra pair of bytes are printed before the 4 bytes the code creates. The solution appears to be to not do that. Instead, start with a null, or apparently any other ASCII character, or even print join("", "", map(chr, 0x17d, 0x17e)), :-P This is not to say the trip will be easy, though it may help if you didn't bother to try it in 5.6, Unicode is not an easy thing to get your mind around. Good luck.
--
Back to
Meditations
|
|