The thing about encoding multiple fields within a cell using \x01 somewhat bugs me -- not because it's a hack but because it's yet another example of needless reinvention of wheels. Good old ASCII has characters specifically devoted to separating fields, keys, etc. that no-one uses for anything else. Why not use them instead of inventing a new character that does the same thing? (By the same token, there was never any need for CSV or tab-delimited text since those characters can't be typed into spreadsheet cells; parsing CSV can be a pain, and TABs can be typed.)
If you care, the characters are:
FS -- file separator 1C
GS -- group separator 1D
RS -- record separator 1E
US -- unit separator 1F
As you can see, they also have the benefit of being self-describing (unlike \x01, as the article points out).
(The sad thing is I only learned about these characters because I had to parse files in a 1960s format originally designed to be stored on tape drives -- and they used these delimiters and they worked great.)
I only found out about these recently because my company uses them in their custom RPC protocol, which was created about 15 years ago I think.
IMO, there are ups and downs to using unprintable characters in your protocol. On one hand, yeah, you don't need to worry about someone putting a tab in a TSV field and messing up the format. On the other hand, it can make debugging a lot harder because what you see isn't necessarily what you get, and obviously it becomes harder to hand-write requests.
Of course, OP ended up using unprintable characters anyway, so I think they might as well use the ASCII ones. But even if you know about and use those characters, I think there is still a place for [CT]SV.
I'm glad you brought them up though, because I think the nonprintable ASCII characters occupy a very interesting place in computer science -- (almost) universally supported, but (almost) never used.
You can make a case for CSV because it's text editor friendly, and tabs because it conceptually maps to typewriters, but we don't even have the option to use these characters. And arguing that typing escape sequences to represent common characters is better is pretty difficult to swallow.
as a younger programmer, the only place I have ever seen these characters is that the fish shell uses the Record Separator character when it exports an environment variable that is an array.
Comments
The thing about encoding multiple fields within a cell using \x01 somewhat bugs me -- not because it's a hack but because it's yet another example of needless reinvention of wheels. Good old ASCII has characters specifically devoted to separating fields, keys, etc. that no-one uses for anything else. Why not use them instead of inventing a new character that does the same thing? (By the same token, there was never any need for CSV or tab-delimited text since those characters can't be typed into spreadsheet cells; parsing CSV can be a pain, and TABs can be typed.)
If you care, the characters are:
FS -- file separator 1C
GS -- group separator 1D
RS -- record separator 1E
US -- unit separator 1F
As you can see, they also have the benefit of being self-describing (unlike \x01, as the article points out).
(The sad thing is I only learned about these characters because I had to parse files in a 1960s format originally designed to be stored on tape drives -- and they used these delimiters and they worked great.)
I only found out about these recently because my company uses them in their custom RPC protocol, which was created about 15 years ago I think.
IMO, there are ups and downs to using unprintable characters in your protocol. On one hand, yeah, you don't need to worry about someone putting a tab in a TSV field and messing up the format. On the other hand, it can make debugging a lot harder because what you see isn't necessarily what you get, and obviously it becomes harder to hand-write requests.
Of course, OP ended up using unprintable characters anyway, so I think they might as well use the ASCII ones. But even if you know about and use those characters, I think there is still a place for [CT]SV.
I'm glad you brought them up though, because I think the nonprintable ASCII characters occupy a very interesting place in computer science -- (almost) universally supported, but (almost) never used.
You can make a case for CSV because it's text editor friendly, and tabs because it conceptually maps to typewriters, but we don't even have the option to use these characters. And arguing that typing escape sequences to represent common characters is better is pretty difficult to swallow.
as a younger programmer, the only place I have ever seen these characters is that the fish shell uses the Record Separator character when it exports an environment variable that is an array.
Perhaps because the fields could also be using these same characters internally?
How much would you care to wager?