use Perl

• Standards (Score:2)

  by petdance (2468)

  First, there's not really a "standard" for CSV. It really means whatever someone wants to throw at you. I had a project last year where multiple business partners would send me "CSV" data, and no two were the same. Some quoted every field. Some only quoted fields that needed it. Some escaped double quotes by doubling them. Some used backslashes. It was a mess.

  Second, don't use Text::CSV. Use Text::CSV_XS [cpan.org]. It's got far more parameters for your tuning enjoyment.

  --
  

  --
  xoa
  • Re:Text::CSV_XS (Score:1)

    by htoug (771)

    But it still has the wierd notion of not allowing us to use our alphabet unless we enter binary mode, which disables any check on characters.
    Usefull, but I do have a hard time explaining why you have to use binary mode to write non-binary data!
    
    I would love for it to have an eight bit mode, where control characters are forbidden, ie. 0x00-0x17, 0x7f-0x97 and 0xff (if I got my ranges right). Of course this would annoy M$-users, that have some printable characters embedded in the high control range (0x80-0x9f
    • Re:Text::CSV_XS (Score:1)

      by barbie (2653) <reversethis-{ku. ... m} {ta} {eibrab}> on 2002.10.29 10:40 (#14332) Homepage Journal

      This was the issue I had with it. Why should I have to switch to binary just to use the extended character set? The fix I did, apart from clean up the bizarre nesting and blank lines helping to confuse the layout of blocks, was the following chuck added to the _bite() function, just before the last "} else {" line:

      } elsif ($in_quotes) {
          # an extended character in quotes...
          $$piece_ref .= substr($$line_ref, 0 ,1);
          substr($$line_ref, 0, 1) = '';

      Well it does the job for me.

      With regards to the control characters, I did think about that, but decided to just allow them. I may change it later though.

      Reply to This

      Parent