注册表项和值名称的有效字符是什么？

Question

更具体地说，该信息的权威来源是什么？

这可能看起来像一个非编程问题，但我需要知道提供给我的代码的注册表路径是否包含正则表达式。 我决定最好的方法是假设任何无效字符的出现（如'*'）表示通配符搜索。

Answer 1

有关允许的键和值名称，请参阅注册表结构上的 MSDN页面。 尤其是：

每个键的名称由一个或多个可打印字符组成。 键名不区分大小写。 键名不能包含反斜杠字符（\\），但可以使用任何其他可打印字符。 值名称和数据可以包含反斜杠字符。

如果您需要知道允许的值，请在MSDN上详细说明注册表值类型。

Answer 2

对于Windows的所有内容，MSDN必须是权威来源 - 关于注册表元素大小限制的文章暗示Unicode是好的，并且注册表的结构表明在密钥名称中不允许使用反斜杠和不可打印的字符。 值只需要是完全可打印的字符。

Answer 3

刚刚对Windows 7注册表进行了一项实验：以“TEST”（在Delphi中为字符串：＃1'Test'）的前面以编程方式创建一个带有01 Hex （ASCII SOH）字符的密钥名称。 这是REGEDIT不允许您通过键入来实现的 - 即使使用ALT-Keypad操作也是如此。

它不仅创造了密钥，它还将REGEDIT中的密钥显示为具有＃1字符所在的“宽”空间。

将这个新的子项名称复制并粘贴到TEXTPAD允许我验证它确实仍然是＃1字符。

我从来没有读过＃1被视为'可打印'的任何地方，但是在Windows中，除了00 Hex之外的任何东西都可以放入打印字符串中，任何东西都可以发送到打印机，所以我想MSDN声明这个限制是矛盾：因为在Windows中，一个角色意味着可打印，所以ergo 不可打印的角色变得......好吧，毫无意义。

虽然您不能将＃1字符直接键入REGEDIT作为键名（使用ALT-keypad-number输入法），但您仍然可以将其作为重命名操作的一部分从TEXTPAD粘贴回REGEDIT。 REGEDIT甚至会抱怨，如果你粘贴它以将另一个对等子密钥重命名为原始的子密钥，因为'指定密钥已经存在'。

有趣的是，我还尝试了字符＃256（不再是ASCII，但理论上是Unicode Widechar，但如果输入，存储或输出机制的任何部分拒绝它，则不一定被认为是“可打印的”）。

虽然我可以通过编程方式创建这样的密钥，并且在REGEDIT中看到一个看起来很奇怪的“A”，但它在剪切和粘贴方面变得不那么可靠了。 我猜测剪贴板操作和与不同应用程序的交互使得这种事情变得非常可疑，因为例如TEXTPAD可能会假设你是粘贴字节字符还是广泛字符与REGEDIT不完全匹配放入剪贴板 - 反之亦然。 如果这些操作背后的代码只是期望ANSI字符串或UTF-16宽字符串，并且给出了不同的东西，包括字节顺序差异和UTF-8或者他们没有预料到的类似差异，那么很可能出错。

最后，我尝试尝试注入具有0FFFF十六进制数的widechar。 这实际上并没有给出REGEDIT中任何角色的视觉存在 - 那么“不可打印”是什么呢？ 。 但这个名字确实包含了隐形人物。 我通过实际尝试在没有违规字符的情况下在REGEDIT中创建单独的对等子项来确认这一点，结果获得了视觉上看起来像两个相同的键！

总而言之：只要它不是'\\'，似乎你可以将字面上的任何字符放入子项名称中。 但这样做可能不是一个好主意。 我认为Windows中的“不可打印”一词通常只适用于00十六进制 - 这是因为它通常用作字符串终止符，因此通过注册表API作为一个字符“发送”有点困难！

令人担忧的是，这会让黑客感到困惑和误导。 您可以完全创建一大堆注册表子项，这些子项看起来根本没有名称，只能由应用程序而不是人类有意义地使用。 是的，您可以使用空格字符执行此操作，但是某些unicode字符（如FFFFh）没有宽度，您可以将它们中的任意数量一起使用来创建唯一且不可见的名称，或名称中的部分！ 这使得它们几乎不可能在不使用费力的剪切和粘贴或专用自动化工具的情况下进行检测。 在REGEDIT中，它们看起来都是同名的，或者实际上未命名的密钥。