在现代编程中使用ASCII分隔符（29-31）

Question

我正在构建一个哈希键字符串（从地图中折叠），其中的值由特殊的ASCII单位分隔符31（1F）分隔。

这很好地解决了试图猜测字符串值中不会使用哪些ASCII字符的问题，我不需要担心转义或引用值等。

然而，阅读有关它的历史，它似乎是20世纪60年代的遗物，我没有看到许多使用这个特殊字符构建和标记字符串的例子，所以这一切看起来都太容易了。

在现代应用程序中使用此分隔符是否有任何问题？

我目前正在非Unicode C ++应用程序中执行此操作，但是我很想知道这通常适用于其他语言，例如Java，C＃和Unicode。

Answer 1

ASCII的低128字符映射完全按照Unicode标准设置，包括字符0-> 31。你不经常在字符串中看到特殊的ASCII字符的唯一原因就是人为接口的限制：它们在显示到屏幕或写入文件时不能很好地显示（如果有的话），你不能轻易地从键盘输入它们。它们也不允许以各种流行的“人类可读”文件格式（例如XML）进行未转义的形式。

对于不需要最终用户交互的程序中的逻辑处理任务，它们非常适合您可以找到的任何用途。你的特殊用途听起来既新颖又高效，我认为你绝对应该使用它。

Answer 2

您的应用程序可以自由接受任何二进制格式。但是，如果需要在输入中嵌入任意二进制数据，则需要转义格式使用的分隔符或其他特殊代码。无论你选择哪一个，都是如此。

我也不会忽略Unicode。到2012年，到目前为止处理过时的模型处理文本是相当愚蠢的。如果您的输入数据是文本的，请按原样处理。

我想到的一个问题是为什么要发明另一种格式而不是使用XML或JSON;或者如果你需要一个紧凑的编码，那两个的“二进制”变体（Fast Infoset，msgpack，谁知道还有什么），还是ASN.1？可能还有很多其他问题在您自己推出时会遇到，这些格式的设计和工具已经解决了。