Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Quoting is also used to embed a comma (or other special character) in a field value. Without quotes, an embedded comma would be a delimiter. With quotes, the comma is NOT a delimiter. Your code doesn't handle this case.
http://en.wikipedia.org/wiki/Comma-separated_values#Toward_standardization

It's unclear whether the code even needs to handle quoted commas. If the data were really house, city, state, zip as posted in the 1st post, then it's conceivable a comma could appear in the "house" field. But since the data isn't that, it's unclear what the real constraints for the data are.

if you read what i wrote, or better yet just look at the code. you would see that it will always break at a comma wether it's in a quote or not. at this point the "csv" portion of all this is tossed out the window. we are dealing with a string object and have zero reference to any csv formatting. a string doesn't care about commas inside quotes. like i said before, if there is a comma it's gonna break, period paragraph.

if anyone needs something different, then figure it out. im tired of people nit picking perfectly functioning code with good documentation to boot. i don't see anyone else posting any worthwhile code. if you can do better, then do it.
 
if you read what i wrote, or better yet just look at the code. you would see that it will always break at a comma wether it's in a quote or not.
I know. I read both. That was precisely my point: your posted code doesn't handle quoting. Whether that's an acceptable limitation is unclear, but not through any fault of yours. The spec itself in the OP was unclear.


at this point the "csv" portion of all this is tossed out the window. we are dealing with a string object and have zero reference to any csv formatting.
I don't understand what your point here is. Simply saying "CSV" as a format can be ambiguous. It might imply quoting is supported, or it might not. There is no definitive rule one way or the other. With no further definition or specification, it's impossible to determine a complete answer.

a string doesn't care about commas inside quotes. like i said before, if there is a comma it's gonna break, period paragraph.
Understood. It supports only unquoted CSV.

if anyone needs something different, then figure it out. im tired of people nit picking perfectly functioning code with good documentation to boot. i don't see anyone else posting any worthwhile code. if you can do better, then do it.
I was simply pointing out that it was unclear what "CSV" meant in the originally posted context (house, city, state, zip), which might differ from that in the actual data (city, country, GPS-coords).

I also pointed out that quoting may not be necessary in the city,country,GPS case, simply because I'm not aware of any cities or countries whose names contain embedded commas or newlines. If there are any, then they would lead to misparsed data.

One of the problems with poorly defined data, or outright mistakes like calling it "cvs", is that a correct and comprehensive solution can be ambiguous. For example, does the data contain any quoted fields? Does it contain any fields with embedded commas? Answer: It's unspecified. What should one do about it? Work to spec? Require clarification? Over-engineer (e.g. add full support for quoting)?

Your code works correctly when commas are purely delimiters that will never appear embedded in a field. It won't work correctly if a comma is embedded in a quoted field. But we don't know if that's a problem or not.

Since the initial spec was unclear, and actually changed between the 1st post and the example data, it is entirely possible that your posted code meets all the OP's requirements. It certainly qualifies as simple and working, which is an excellent starting point.
 
Please, read CVS white papers

Knowing few things about this file format - you are not taking into account the escape characters and other important details.

Even when over-simplified - the objective C attempts to parse it look quite awful.

There are excellent libs in java and C on this subject.
 
Knowing few things about this file format - you are not taking into account the escape characters and other important details.

Even when over-simplified - the objective C attempts to parse it look quite awful.

There are excellent libs in java and C on this subject.

1. Everyone except you and the original poster is talking about CSV (comma separated values) and not CVS (Canvas image format).

2. The posted Objective-C code for reading an ASCII or UTF-8 file into a string, separating the string into newline-separated strings, and separating these strings into comma-separated units is just fine.

3. What's _not_ fine is the assumption that the data is in ASCII or UTF-8 format; since CSV is likely to be old it is quite possibly MacRoman or Windows-1252 or something more exotic. What's also not fine is the assumption that the lines are newline-separated, could easily be CR/LF pairs. What's also not fine is the assumption that the items don't contain quotes.

4. That said, good luck integrating an "excellent lib in Java" into a MacOS X or iOS application. And even including the more complicated details, the problem is really quite trivial and any experienced programmer will take less time writing the code than reading and understanding the documentation of some "excellent C lib", making it compile, integrating it into a project in a useful form, and checking whatever license the software comes with.
 
1. Everyone except you and the original poster is talking about CSV (comma separated values) and not CVS (Canvas image format).

2. The posted Objective-C code for reading an ASCII or UTF-8 file into a string, separating the string into newline-separated strings, and separating these strings into comma-separated units is just fine.

3. What's _not_ fine is the assumption that the data is in ASCII or UTF-8 format; since CSV is likely to be old it is quite possibly MacRoman or Windows-1252 or something more exotic. What's also not fine is the assumption that the lines are newline-separated, could easily be CR/LF pairs. What's also not fine is the assumption that the items don't contain quotes.

4. That said, good luck integrating an "excellent lib in Java" into a MacOS X or iOS application. And even including the more complicated details, the problem is really quite trivial and any experienced programmer will take less time writing the code than reading and understanding the documentation of some "excellent C lib", making it compile, integrating it into a project in a useful form, and checking whatever license the software comes with.
A little sensitive to typo perhaps. Sources are available, just google. Ah I forgot, you probably hate google. Do not worry, be the first one to claim Mac OSX and iOS makes it hard to work with C. I never suggested to use neither java or C, but you at least could look at the source code to realize it is not as simple as you might think it s. Anyway, good luck with CS job.

Indeed you got to hate google, as it only took one hit to find excellent primer on this subject including the source code:
http://www.cocoawithlove.com/2009/11/writing-parser-using-nsscanner-csv.html

Hard to believe, but the author supports my comments, figures...:
"Most common solutions for parsing CSV files involve quick parsers which don't consider the full format and instead just split strings into lines using -[NSString componentsSeparatedByString:mad:"\n"] and then split lines into columns with -[NSString componentsSeparatedByString:mad:","]. This will work for some cases but it does not handle all aspects of RFC4180 and is limited to simple CSV files."

As for novice, do not think that folks spent time making classes, libs or frameworks out of nothing. Over-simplification may get you in to trouble one day. Be respectful for what was done by others and be grateful they share it for free. Contribute when you can.
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.