我目前正在构建一个哈希键字符串（从地图中折叠），其中的值由特殊的 ASCII 单元分隔符 31 (1F) 分隔。
这很好地解决了试图猜测哪些 ASCII 字符不会在字符串值中使用的问题，我不需要担心转义或引用值等。
然而，阅读它的历史似乎是 1960 年代的遗物，我还没有看到很多使用这个特殊字符构建和标记字符串的例子，所以这一切似乎都太容易了。
在现代应用程序中使用此分隔符是否有任何问题？
我目前正在一个非 Unicode C++ 应用程序中执行此操作，但是我很想知道这通常如何应用于其他语言，例如 Java、C# 和 Unicode。
ASCII 的低 128 个字符映射完全固定在 Unicode 标准中，包括字符 0->31。您没有经常在字符串中看到特殊 ASCII 字符的唯一原因仅仅是因为人机接口的限制：当显示到屏幕或写入文件时，它们不能很好地可视化（如果有的话），而且您不能轻易也可以从键盘输入它们。它们也不允许在各种流行的“人类可读”文件格式中以未转义的形式出现，例如 XML。
但是，对于程序中不需要最终用户交互的逻辑处理任务，它们非常适合您可以找到的任何用途。您的特殊用途听起来新颖而有效，我认为您绝对应该使用它。
您的应用程序可以自由地接受它喜欢的任何二进制格式。但是，如果您需要在输入中嵌入任意二进制数据，则需要转义格式使用的任何分隔符或其他特殊代码。无论您选择哪个，这都是正确的。
我也不会忽略 Unicode。现在是 2012 年，现在使用过时的模型来处理文本是相当愚蠢的。如果您的输入数据是文本的，请照此处理。
想到的一个问题是为什么要发明另一种格式而不是使用 XML 或 JSON？或者，如果您需要紧凑的编码，这两者的“二进制”变体（Fast Infoset，msgpack，谁知道还有什么），或者 ASN.1？在推出自己的产品时，您可能会遇到很多其他问题，而这些格式的设计和工具已经解决了。