Re: [Koha-devel] [Koha-patches] [PATCH] [SIGNED-OFF] Bug 6614: Remove newlines from order notes when exporting to CSV
Nicole C. Engard schreef op di 26-07-2011 om 14:22 [-0400]:
If an order contained a note with a newline in it, that line would come out as a blank entry in the exported CSV. This patch strips such characters, globally.
It should be OK to have \r and \n in CSVs, provided the fields are correctly wrapped in a quote characters, and any internal quote characters are correctly escaped (let me regale you with my tales of dealing with malformed CSV files coming from other ILS systems...another time perhaps.) I would expect Text::CSV to be able to understand such quoting and escaping properly. Also, keep in mind that some spreadsheet systems can't handle newlines in CSV files, while others can. IME, LibreOffice can, gnumeric can't. Robin.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27/07/11 01:38, Robin Sheat wrote:
Nicole C. Engard schreef op di 26-07-2011 om 14:22 [-0400]:
If an order contained a note with a newline in it, that line would come out as a blank entry in the exported CSV. This patch strips such characters, globally.
It should be OK to have \r and \n in CSVs, provided the fields are correctly wrapped in a quote characters>
I would expect Text::CSV to be able to understand such quoting and escaping properly.
Yes but the problem is that the Text::CSV object is not created as binary. So that the problem is not only with end of lines but with non-ascii characters. see Text::CSV's documentation Colin - -- Colin Campbell Chief Software Engineer, PTFS Europe Limited Content Management and Library Solutions +44 (0) 845 557 5634 (phone) +44 (0) 7759 633626 (mobile) colin.campbell@ptfs-europe.com skype: colin_campbell2 http://www.ptfs-europe.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4v53oACgkQiPfkNnpIKz+ghgCeJxUBGyffZ+iGQrGJPAOkjzn2 RwEAoKe+TASJZr2O1N1H5A8Ddn3vtjLr =mKT3 -----END PGP SIGNATURE-----
Op woensdag 27 juli 2011 22:25:22 schreef Colin Campbell:
Yes but the problem is that the Text::CSV object is not created as binary. So that the problem is not only with end of lines but with non-ascii characters. see Text::CSV's documentation
Perhaps then we should be outputting as binary? I do a lot with Text::CSV for reading, but not really for writing. For reading, it's generally the case that you work in binary mode unless you have a good reason not to. -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204
Any alternate implementation to allowing more characters into the Text::CSV exports is of course preferable. My patch was a quick fix for the issue, but I'll happily see it replaced with a more robust solution. Thanks to both Robin and Colin for exploring better options. -Ian 2011/7/27 Robin Sheat <robin@catalyst.net.nz>
Op woensdag 27 juli 2011 22:25:22 schreef Colin Campbell:
Yes but the problem is that the Text::CSV object is not created as binary. So that the problem is not only with end of lines but with non-ascii characters. see Text::CSV's documentation
Perhaps then we should be outputting as binary? I do a lot with Text::CSV for reading, but not really for writing. For reading, it's generally the case that you work in binary mode unless you have a good reason not to.
-- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
participants (3)
-
Colin Campbell -
Ian Walls -
Robin Sheat