Latest version fails to recognise line endings on Mac

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Test with the attached csv file.
2.
3.

What is the expected output? What do you see instead?
There should be 19 lines but I see only 1 line. All the fields are flattened 
into one line.

What version of the product are you using? On what operating system?
version 0.64, Mac OS

Please provide any additional information below.
We also tried the latest version 0.70 which seem to work on Mac OS but does not 
work in firefox browser.

Original issue reported on code.google.com by ra...@manusis.com on 7 Nov 2012 at 6:24

Attachments:

• [test csv.csv](https://storage.googleapis.com/google-code-attachments/jquery-csv/issue-17/comment-0/test csv.csv)

[GoogleCodeExporter]

The current version  used is 0.70 which fails on Mac OS. The version 0.64 works 
on Chrome on Mac OS but does not work in firefox browser. 

Original comment by ra...@manusis.com on 7 Nov 2012 at 6:26

[GoogleCodeExporter]

The null-last-value is a known issue in 0.64 but should be resolved in 0.7. A 
new parser core was released with 0.65 that eliminated any and all 
cross-browser inconsistencies.

First, try downloading the latest from the repository. 

Go to:
http://code.google.com/p/jquery-csv/source/browse/src/jquery.csv.js.

Right-click 'Save As' on the link that says 'View raw file' to get the very 
latest source. 

If that doesn't resolve your issue I'll need you to post what the parser is 
outputting. Let me know if you need help figuring out how.

Original comment by evanpla...@gmail.com on 7 Nov 2012 at 12:10

• Changed state: Accepted
• Added labels: Priority-High
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Did you manage to get it working?

If not, let me know. Otherwise, I'm going to close this issue is resolved and 
close it out.

Original comment by evanpla...@gmail.com on 14 Nov 2012 at 1:34

[GoogleCodeExporter]

Original comment by evanpla...@gmail.com on 19 Nov 2012 at 7:29

• Changed state: Invalid

[GoogleCodeExporter]

This is what the parser is giving back

[Array[64]]
 0: Array[64]
  0: "Test Name"
  1: "Last Run Time"
  2: "creation Date"
  3: "Other uselsess information"
  4: ""
  5: ""
  6: "A"
  7: "1/1/86"
  8: ""
  9: "B"
  10: "1/1/87"
  11: ""
  12: "C"
  13: "4:15pm 1/1/99"
  14: ""
  15: "D"
  16: "4/4/12"
  17: ""
  18: "E"
  19: "8/8/12"
  20: ""
  21: "F"
  22: "9/9/12"
  23: ""
  24: "G"
  25: "10/1/12"
  26: ""
  27: "H"
  28: "1/1/12"
  29: ""
  30: "j"
  31: "2/2/12"
  32: ""
  33: "k"
  34: "3/3/12"
  35: ""
  36: "l"
  37: "4/4/12"
  38: ""
  39: "m"
  40: ""
  41: ""
  42: "m"
  43: ""
  44: ""
  45: "';lkas;l"
  46: ""
  47: ""
  48: "23m'"
  49: ""
  50: ""
  51: "56o"
  52: ""
  53: ""
  54: "m'21"
  55: ""
  56: ""
  57: "This is a verrrrrrrrry lonnngggggggg testttttttttttttt nnnnnnnnnameeeeeeeeeeea  that runs and runs and runs and runs"
  58: ""
  59: ""
  60: "mwsyes"
  61: "5/4/67"
  62: ""
  63: ""
 length: 64
 __proto__: Array[0]
 length: 1
__proto__: Array[0]

Original comment by vipul.sh...@manusis.com on 13 Dec 2012 at 5:26

[GoogleCodeExporter]

Why does your data use carriage returns as the newline char? How was this data 
created?

Technically, OSX is a unix-derived platform so it should use LF (line-feed) as 
the default line-ending. CR (carriage-return) chars were only used in pre-OSX 
Mac operating systems. The library supports CRLF (ie windows-style 
line-endings) but the CR is ignored.

CR (carriage-return) line endings are considered obsolete so the library 
doesn't support them.

Solution: Find a text editor that can convert carriage-returns to line-endings, 
then run it through the parser.

On a side-note, download the latest release too. 0.64 had a significant bug 
that was fixed in the release of 0.7.

Original comment by evanpla...@gmail.com on 13 Dec 2012 at 5:46

[GoogleCodeExporter]

Thanks for the reply.

Original comment by vipul.sh...@manusis.com on 13 Dec 2012 at 7:06

[GoogleCodeExporter]

For the record, I just discovered that Excel 2011 for Mac saves csv files by 
default with the CR-only line ending.  I agree that it's silly and obsolete, 
but I imagine that as a result many people will bump into this issue.

It would be great if the parser could support this line ending even though it's 
nonstandard.  In the meantime, I've worked around it by replacing any 
standalone CRs with LFs before calling toArrays:

csv = csv.replace(/\r(?!\n)/g, "\n");

Original comment by pub...@gmail.com on 20 Jan 2013 at 5:33

[GoogleCodeExporter]

There might be a way to configure the default settings in Excel for Mac to use 
the correct (ie UNIX) line endings.

Isn't there an option to save as 'Windows CSV', 'MS-DOS CSV', 'Windows Comma 
Separated' or something along those lines? I don't use a mac or else I'd test 
it myself.

Technically, Excel CSV export is the ONLY know application that still uses CR 
line endings by default. Don't let Microsoft fool you, this is not a feature, 
it's a bug.

Original comment by evanpla...@gmail.com on 25 Jan 2013 at 4:47

[GoogleCodeExporter]

Yes, there is the option to save as a Windows csv in Excel for Mac, and there 
are other workarounds as well, like "flip"; 
https://ccrma.stanford.edu/~craig/utility/flip/

Sometimes, though, we receive one of these csv files from a colleague or 
whatnot, and it would be nice to have it "just work" in jquery-csv, or at least 
for it to throw a more explicit error message about the source of the problem 
so it's more easily remedied.  I am totally in agreement that the source of the 
problem likes with Microsoft, it would just be a kindness to users if 
jquery-csv handled Microsoft's bug gracefully.  :)

Original comment by pub...@gmail.com on 28 Jan 2013 at 4:54