3 ms·
That's too lazy, we need unicode symbols for escaped start-blob and escaped end-blob /s
by joosters 7y ago
That's too lazy, we need unicode symbols for escaped start-blob and escaped end-blob /s
- majewsky 7y agoNot sure why /s. Also, you only need escaped-end-blob. start-blob can safely be used inside a blob. So it's only 3 new codepoints, which is genuinely an interesting proposal.
- Dylan16807 7y agoBecause that doesn't round trip. You need to be able to distinguish whether the blob originally had "end-blob" or "escaped-end-blob". So now you need another character for double-escaping, and so on, and so on. To avoid that issue you're back to either adding a backslash, or doubling up the character inside the blob... but if you're doing that you could have just used " all along. No need for new characters! If you really don't want to change the contents of the blob, and can't length-prefix, then you could also use a new UUID as your delimiter each time you embed a blob.
- stiray 7y agoNo. It depends only on developers. If they would start embeding it into format, they would break the rules. If not, it would work.
- Dylan16807 7y agoIf you're telling developers not to embed that character anywhere then you only need one end of blob character. So not 'no', I'm still right in saying that having two end characters is a non-solution. And you still didn't explain why the existing ASCII control codes don't solve your problem. The suitable ones are also not supposed to appear inside text.