问题：在程序稳定性和确保系统实际运行方面，使用¦，§或{{1}等字符的安全性如何？对于字符串中复杂的分隔符序列？我是否可靠地相信我不会在阅读这些错误的程序中遇到任何问题？
我在一个使用C＃代码的系统中工作，我必须在一个字符串中存储一组相当复杂的信息。该字符串的可读性仅在计算机端是必需的，最终用户只有在通过适当的方法解析后才能看到该信息。因为这些字符串中的某些数据将是可变大小的集合，所以我使用不同的分隔符来标识字符串的哪些部分对应于某个组织层。有足够的情况，标准集;，|和类似的同类已经用尽。我考虑过两个字符分隔符，比如;＃或; |，但我觉得它效率很低。使用一个字符与两个字符存储时，可能没有存在大的性能差异，但是当我可以选择较小的选项时，选择较大的选项会感觉不对。 / p>
所以最后，我考虑使用像双匕首和部分这样的字符集。他们只占用一个字符，而且它们绝对不会出现在我将要存储的实际文本中，因此它们不会被混淆。
但字符编码很挑剔。虽然对最终用户的可见性毫无意义（因为他们实际上看不到它），但我最近担心系统中的程序将如何读取它。该字符串存储在一个数据库中，而另一个程序负责将字符串编码和解码为不同的对象类型，以供其他应用程序使用。如果预期某种方式会写一些东西，可能会写另一种方式，那么也许整个系统都会失败，我不能真的让它发生。那么将这些字符用于背景分隔符是否安全？
答案 0 :(得分：5)
因为你必须用字符串对数据进行编码，所以我认为这是因为你正在与其他系统连接。为什么不使用XML或JSON这样的内容而不是发明自己的数据格式？
使用XML，您可以指定正在使用的编码，例如：
<?xml version="1.0" encoding="UTF-8"?>
答案 1 :(得分：4)
存储和检索Unicode文本的任何系统都会改变这些特定字符的危险性很小。
可以在文本传输过程中更改的主要字符是行标记的结尾。例如，在文本模式下将文件从Unix系统FTP到Windows系统可能会替换CARRIAGE RETURN + LINE FEED对的LINE FEED字符。
之后，某些系统可能会执行文本的规范规范化。除非考虑规范的标准化（组成或分解），否则不应使用字符和字符与变音符号组合。 Unicode字符数据库包含有关这些规范化方案下所需转换的信息。
总结了要注意的最重要的事情，而且对于你列出的角色来说，这些都不是问题。
可能进行的其他转换（但不太可能）是大小写更改和兼容性规范化。要避免这些，请远离字母或任何看起来像字母的字母。某些符号也会在兼容性规范化中进行转换，因此您应该检查Unicode字符数据库中的属性以确定。但是，如果没有明确指出它会这样做，任何系统都不太可能进行兼容性规范化。
在Unicode Code Charts中，“≡”表示规范标准化，“≈”表示相容性标准化。
答案 2 :(得分：3)
您可以采用与URL或HTML编码相同的方法，并使用字符的序列替换关键字符。即&变为&。
虽然这会产生更多的字符，但由于这些序列的重复，它可以非常有效地压缩。
答案 3 :(得分：2)
嗯，UNICODE是一个标准，所以只要涉及的每个人（代码，数据库等）都使用UNICODE，你就不应该有任何问题。
答案 4 :(得分：2)
Unicode集中有更罕见的字符。据我所知，只有0x32（空格）以下的字符具有特殊含义，任何应该保留在NVARCHAR数据列中的字符。
除非你有一个很好的规范，哪些字符可以成为你的数据的一部分，否则永远不会是完全安全的。
答案 5 :(得分：1)
记住墨菲的一些法律：
“任何可能出错的地方都会。”
“任何不会出错的事情都会 无论如何“。
最终可能会使用那些绝对不会使用的字符。如果是，应用程序肯定会失败。
如果您只是转义值，则可以使用您喜欢的任何字符作为分隔符，以确保字符不会出现在其中。我前一段时间写了一个例子，表明你甚至可以使用像“a”这样的常用字符作为分隔符。
转义值当然意味着某些字符将表示为两个字符，但通常仍然比使用多字符分隔符的开销少。更重要的是，它是完全安全的。