On 2/9/06, JupiterHost.Net <[EMAIL PROTECTED]> wrote: > > > Baskaran Sankaran wrote: > > > Thanks for that but still I do face problem. I did that and it raises a > > warning: > > > > > > > > utf8 "\xFF" does not map to Unicode at second.pl line 8, > > <$lang_sample_fh> line 1. > > Excellent, so now we have soem info to start with :) > > > > I have 10 sentences each in different line in the input file (input file > > doesn't contain any blank lines between sentences). The output file gets > > generated, but only alternate lines are displayed properly. Lines 2, 4, > > 6, ... are displayed as junk boxes in Unicode. > > ok: > > send the "new" code so we can see what line 8 is and please send a > representation of the data in the file, the results and what you excpect. > (IE imagine we can't pull what you expect to happen and what is > happening from thin air, all I have is an abscure warning, something > about every other line being goofed, and something about Unicode *'s) > > Thanks ;) >
Also, let us know what platform you're on (the EBCDIC unicide implementation, for instance, has it's own set of issues), how you've come to the conclusion that that the issues you're seeing are with Perl and not your terminal--nine time out of ten, Perl is doing the right thing and it's the on-scren n display that's the problem--and why you're setting :utf8 on both input and output. Perl should handle the conversion implicitly for each individual string. In theory, you should only need :utf8 to force utf8 output, and then only in situations where unicode isn't the native character set. Setting the flag when is doesn't need to be can cause considerable confusion; try not using the utf8 layer on the input. HTH, -- jay -------------------------------------------------- This email and attachment(s): [ ] blogable; [ x ] ask first; [ ] private and confidential daggerquill [at] gmail [dot] com http://www.tuaw.com http://www.dpguru.com http://www.engatiki.org values of β will give rise to dom!
