ANNOUNCE: Text-CSV_XS 0.28

Note the IMPORTANT CHANGE!

file: $CPAN/authors/id/H/HM/HMBRAND/Text-CSV_XS-0.28.tar.gz
size: 33289 bytes
md5: 8c00161d04793deaf383b4331fe09db4

2007-06-03 0.28 - H.Merijn Brand

* IMPORTANT CHANGE: new () returns undef if it gets unsupported=

attributes. Until now, new ({ esc_char =3D> "\\" }) was just
silently ignored. Rejecting it and failing is better than
continuing with false assumptions.
* Added allow_loose_quotes (see doc)
* Added t/65_allow.t
* Added allow_loose_escapes (see doc) RT 15076
* More code cleanup in XS
* Added allow_whitespace (see doc)

2007-05-31 0.27 - H.Merijn Brand

* checked with perlcritic (still works under 5.00504)
so 3-arg open cannot be used (except in the docs)
* 3-arg open in docs too
* Added a lot to the TODO list
* Some more info on using escape character (jZed)
* Mention Text::CSV_PP in README
* Added t/45_eol.t, eol tests
* Added a section about embedded newlines in the pod
* Allow \r as eol ($/) for parsing
* More docs for eol
* More eol =3D \r fixes, tfrayner's test case added to t/45_eol=
..t


=3Ditem allow_whitespace

When this option is set to true, whitespace (TAB's and SPACE's)
surrounding the separation character is removed when parsing. So
lines like:

1 , "foo" , bar , 3 , zapp

are now correctly parsed, even though it violates the CSV specs.
Note that B whitespace is stripped from start and end of each
field. That would make is more a I than a way to be able
to parse bad CSV lines, as

1, 2.0, 3, ape , monkey

will now be parsed as

("1", "2.0", "3", "ape", "monkey")

even if the original line was perfectly sane CSV.

=3Ditem allow_loose_quotes

By default, parsing fields that have C characters inside
an unquoted field, like

1,foo "bar" baz,42

would result in a parse error. Though it is still bad practice to
allow this format, we cannot help there are some vendors that make
their applications spit out lines styled like this.