对字符串中的复杂分隔符序列使用随机 Unicode 是否安全？答案

【问题标题】：Is it safe to use random Unicode for complex delimiter sequences in strings?对字符串中的复杂分隔符序列使用随机 Unicode 是否安全？
【发布时间】：2011-02-09 18:31:22
【问题描述】：

问题：就程序稳定性和确保系统实际运行而言，使用¦、§ 或‡ 等字符在字符串？我是否可以相信我不会在错误读取这些内容的程序中遇到任何问题？

我在一个系统中工作，使用 C# 代码，我必须在一个字符串中存储一组相当复杂的信息。该字符串的可读性仅在计算机端是必需的，最终用户只能在通过适当的方法解析后才能看到信息。因为这些字符串中的一些数据将是可变大小的集合，所以我使用不同的分隔符来标识字符串的哪些部分对应于某个组织层。有足够多的情况表明，标准集;、| 和类似的东西已经用尽了。我考虑过两个字符的分隔符，例如;# 或;|，但我觉得这样效率很低。一个字符存储与两个字符存储的性能差异可能那么大，但是当我可以选择较小的选项时，选择较大的选项感觉不对。

所以最后，我考虑使用像双匕首和节这样的字符集。它们只占用一个字符，而且它们绝对不会出现在我将要存储的实际文本中，因此它们不会被任何东西混淆。

但是字符编码很挑剔。虽然对最终用户的可见性毫无意义（因为他们实际上不会看到它），但我最近开始担心系统中的程序将如何读取它。字符串存储在一个数据库中，而一个单独的程序负责将字符串编码和解码为不同的对象类型，以供应用程序的其余部分使用。如果某些东西预计会以一种方式编写，可能会以另一种方式编写，那么可能整个系统都会失败，我真的不能让这种情况发生。那么将这些字符用作背景分隔符是否安全？

【问题讨论】：

标签： c# string unicode delimiter

【解决方案1】：

因为您必须将数据编码为字符串，我假设这是因为您正在与其他系统交互。为什么不使用 XML 或 JSON 之类的东西，而不是发明自己的数据格式？

使用 XML，您可以指定使用的编码，例如：

<?xml version="1.0" encoding="UTF-8"?>

【讨论】：

老实说，我不知道 JSON 是什么。我会冒险，XML 会导致明显更大的字符串。如果我想放弃并使用超过 1 个字符，我可以只使用 2-char 系统，作为额外的奖励，我不必添加任何新类型的解析器（因为你不能这样做带有 XML 的正则表达式）。
JSON 的大小明显小于 XML，但大于单字符分隔符。物有所值，这是一个很好的折衷方案json.org/example.html
XQuery 和 XPath 都支持正则表达式。您提到了层，因此听起来您的数据是分层的；与使用分隔符技术相比，JSON 或 XML 处理得更好。
对于分层数据，确实，JSON 或 XML 更擅长处理它。也许我的观点是错误的……但是对于这个特定的系统，我觉得在标签中花费 4 倍以上的字符来存储使用 JSON 或 XML 的信息并不是一个好的权衡。应用程序其余部分使用的类结构也很好地处理了解码数据的组织，因此似乎没有必要。再说一次，也许我从一个不好的角度来看它。

【解决方案2】：

您可以采用与 URL 或 HTML 编码相同的方法，并将关键字符替换为 sequences 字符。 IE。 &amp; 变为 &amp;。

虽然这会产生更多字符，但由于这些序列的重复，它可以非常有效地压缩。

【讨论】：

那不是和只用;#和;|类似吗？

【解决方案3】：

嗯，UNICODE 是一个标准，所以只要涉及的每个人（代码、数据库等）都在使用 UNICODE，你就不会有任何问题。

【讨论】：

【解决方案4】：

Unicode 集中有更稀有的字符。据我所知，只有 0x32（空格）以下的字符具有特殊含义，任何应保留在 NVARCHAR 数据列中的字符。

除非您有一个很好的规范，否则它永远不会完全安全，哪些字符可以成为数据的一部分，哪些不能成为数据的一部分。

【讨论】：

【解决方案5】：

记住一些墨菲定律：

“任何可能出错的事情都会发生。”

“任何不会出错的，都会无论如何。”

那些绝对不会被使用的字符，最终可能会被使用。如果是，应用程序肯定会失败。

您可以使用任何您喜欢的字符作为分隔符，如果您只对值进行转义以保证该字符不会出现在其中。不久前我写了一个例子，表明你甚至可以使用像“a”这样的常用字符作为分隔符。

转义值当然意味着某些字符将被表示为两个字符，但通常这仍然比使用多字符分隔符的开销要小。更重要的是，它是完全安全的。

【讨论】：

【解决方案6】：

存储和检索 Unicode 文本的任何系统都不会改变这些特定字符。

在文本传输过程中可以更改的主要字符是行尾标记。例如，以文本模式将文件从 Unix 系统 FTP 传输到 Windows 系统可能会替换 LINE FEED 字符以用于 CARRIAGE RETURN + LINE FEED 对。

之后，某些系统可能会对文本执行规范化规范化。除非考虑到规范规范化（组合或分解），否则不应使用组合字符和带有变音符号的字符。 Unicode 字符数据库包含有关在这些规范化方案下需要哪些转换的信息。

总结了需要注意的最重要的事情，对于您列出的角色来说，这些都不是问题。

可能进行但不太可能进行的其他转换是大小写更改和兼容性规范化。为了避免这些，请远离字母或任何看起来像字母的东西。一些符号也在兼容性规范化中进行了转换，因此您应该检查 Unicode 字符数据库中的属性以确保确定。但是，任何系统都不太可能在没有明确表示会这样做的情况下进行兼容性规范化。

在Unicode Code Charts 中，规范规范化用“≡”表示，兼容性规范化用“≈”表示。

【讨论】：