01-19-2016, 09:53 PM
Hi all, just catching up. It's very cool that MSP now supports CSV-based import of multiple songs from a single PDF. However I don't understand why there has been a lengthy discussion about which delimiter to use.
Sorry, but I disagree with your assumptions here. Whichever delimiter character you settle on, there will always be at least one case where someone needs to use that delimiter within a song title or other data field. So you can never guarantee avoiding all conflicts simply by carefully deciding the delimiter. But this problem was solved in CSV decades ago!! That's the whole point of quoting, which is very clearly explained in https://tools.ietf.org/html/rfc4180 and also demonstrated in the README for my own CSV index project: https://github.com/aspiers/book-indices
So I would strongly vote for keeping the default delimiter character as a comma (after all that's what the C in CSV stands for), and simply ensure that your parser understands quoting of fields which contain commas. Solved!
Having said that, of course it does not do any harm to also support multiple delimiters. But supporting field quoting is absolutely essential regardless of which delimiter you use.
(01-06-2016, 04:36 AM)Zuberman Wrote: The problem is that I have to choose something for delimiting values that doesn't clash with what can be potentially used for column delimiting. People here indicated that they would like to use semi-colon for column delimiting and it does seem to be a popular use for that. If I used semi-colon for value delimiting, then it certainly could not be used as a column delimiter.
Sorry, but I disagree with your assumptions here. Whichever delimiter character you settle on, there will always be at least one case where someone needs to use that delimiter within a song title or other data field. So you can never guarantee avoiding all conflicts simply by carefully deciding the delimiter. But this problem was solved in CSV decades ago!! That's the whole point of quoting, which is very clearly explained in https://tools.ietf.org/html/rfc4180 and also demonstrated in the README for my own CSV index project: https://github.com/aspiers/book-indices
So I would strongly vote for keeping the default delimiter character as a comma (after all that's what the C in CSV stands for), and simply ensure that your parser understands quoting of fields which contain commas. Solved!
Having said that, of course it does not do any harm to also support multiple delimiters. But supporting field quoting is absolutely essential regardless of which delimiter you use.