Support for iOS 10 about codablecsv HOT 13 CLOSED

Oh right, sorry I misread. Yes, I agree. I will bump the priority of the line delimiter inference in my todo list.

Thank you for your input and comments.

from codablecsv.

Yeah, that is only checking for hardcoded line delimiters: \r, n or the EOF, but it is not trying to figure out what the line delimiter is, which is the functionality I would love to include. In any case, thank you 👍

By the way, if you have some free time, do give another try to CodableCSV. Performance is better, now it supports files, and it can load huge files only partially as it is needed for decoding 😄

from codablecsv.

the problem is that many CSVs out there don't really follow the standard

I totally agree. And the same goes for using a consistent line delimiter throughout the file 😉

from codablecsv.

There isn't a reason for the iOS 12 limit. It was just what I needed to support at the time.

I went ahead and make a thorough check of the library's dependencies. CodableCSV minimally use Foundation; specifically it requires: CharacterSet, Data, Date, DateFormatter, Decimal, OutputStream, and URL. Technically I could set the limit at iOS 7, macOS 10.9, tvOS 9, and watchOS 2 😄

Anyways, I have made the changes on the SPM and Cocoapods files that you need and release a new fix version.

from codablecsv.

Great 😄 Thanks!

from codablecsv.

By the way @mhdhejazi, good work on the CoronaTracker app, I just downloaded it and I am digging it. I am sad CodableCSV couldn't be your CSV library of choice 😅

from codablecsv.

Thanks! Glad you like it 😄

It was actually my library of choice and mentioned that in the repo. But had to replace it to support iOS 10 as I said. And also because it doesn't detect the line delimiter automatically. There is an option for that (.unknown) but not implemented yet.

from codablecsv.

Yeah, that is in my todo 🗒 list. Does CSV.swift have the header inferral functionality? As far as I got, that library only provides the option to say whether the CSV has a header or not.

In any case, once I finish with the Encoder implementation, I will iron out all the missing behavior. I have some things in the pipeline that are pretty sweet 😊

from codablecsv.

I was talking about the line delimiter. Not sure about inferring the header. But I think inferring the line delimiter is more important as it's more likely to be messed up, and when that happens you find yourself dealing with things like "12\r" instead of numbers.

from codablecsv.

Hey @mhdhejazi I just finished a big upgrade to CodableCSV and I was thinking on tackling the line delimiter inference you mentioned previously next.

Last time I got the impression from your comments that CSV.swift did that, but I haven't been able to find it anywhere in their codebase. Do you have any pointers or do you know anybody that does something similar?

from codablecsv.

I guess this is how CSV.swift deals with line delimiters:
https://github.com/yaslab/CSV.swift/blob/81d2874c51db364d7e1d71b0d99018a294c87ac1/Sources/CSV/CSVReader.swift#L290-L298

from codablecsv.

Well, according to the standard, line breaks (\r, \n) should be considered line delimiters unless they are enclosed in double-quotes

   6.  Fields containing line breaks (CRLF), double quotes, and commas
       should be enclosed in double-quotes.  For example:

       "aaa","b CRLF
       bb","ccc" CRLF
       zzz,yyy,xxx

So, I think detecting the line delimiters for the whole file isn't that important (nor feasible for large files). Doing line by line processing is totally fine, and I don't think you have to worry about mistakenly dropping a \r or \n character from the data as long as you're following the standard.

from codablecsv.

Well, according to the standard, line breaks (\r, \n) should be considered line delimiters unless they are enclosed in double-quotes.

Definitely, the problem is that many CSVs out there don't really follow the standard. But for most cases is definitely the best.

from codablecsv.