True, but in my mind picking ", " indicate to me that they don't care or don't know what they're doing. I often run into something similar with XML. I've had more than one partner call or write me saying that the elements in a file are not in the right order. Every single time they've admitted to not actually using an XML parser.
Don't do things that screw up the standard tools other developers depend on.
Stuff not being in the correct order is a perfectly fine technical reason to reject an XML file if you have a DTD based workflow. It is actually quite difficult to specify that the order of elements is irrelevant (it goes with n!, so allowing six elements exactly once, but in arbitrary order in the contents of
So in that case, you might have been the developer that screwed up the standard tools other developers dependan element makes that part of the DTD 720 times longer than specifying a fixed order).
So they could have easily played the ball back into your field if they had know what they did...
That is much more complex than the issues we've seen. My issue is with say a <person> with the subelements <name> and <email>, it should never make any difference if email or name is first or second.
You can replace all commas with a placeholder (e.g. "#COMMA#"), replace the delimiter with a comma, parse the document and then replace all placeholders in the data with ",".
That does not work, unless that first replacement magically ignores the commas that are part of field separators. If you know how to write the code that does that, your problem is solved.
I was referencing to "What if the character separating fields is not a comma?".
And there it clearly works. I used this technique a few times with success. If you find a CSV file that has mixed field separator types, then you probably found a broken CSV file.
You just choose a placeholder that does not appear in the data. You could even implement it in a way that a placeholder is automatically selected upfront that does not appear in the data.
When it comes to parsing, the thing is that you usually have to make some assumptions about the document structure.
Don't do things that screw up the standard tools other developers depend on.