Latest version fails to recognise line endings on Mac about jquery-csv HOT 10 CLOSED

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. 

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.

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.

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]

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.

Thanks for the reply.

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");

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.

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.  :)