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

What are the valid characters for Registry keys and valuenames?

提问by JCCyC

More specifically, what is the authoritative source for that information?

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

This may look like a non-programming question, but I need to know whether a registry path fed to my code contains a regular expression or not. I decided the best way to do that is assume that any occurrence of an invalid character (like '*') means a wildcard search.

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

回答by Reed Copsey

For allowable key and value names, see the MSDN page on Structure of the Registry. In particular:

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

Each key has a name consisting of one or more printable characters. Key names are not case sensitive. Key names cannot include the backslash character (\), but any other printable character can be used. Value names and data can include the backslash character.

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

Registry value types are explained in detail on MSDN here, in case you need to know the allowable values.

MSDN 此处详细解释了注册表值类型，以防您需要了解允许的值。

回答by Rowland Shaw

For all things Windows, MSDN has to be the authoritative source -- the article on Registry Element Size Limitsimplies Unicode is good and Structure of the Registrysays that backslash and non-printable characters are disallowed in key names. Values merely have to be entirely printable characters.

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

回答by Alex T

Just did an experiment with the Windows 7 registry: programmatically creating a key name with the 01 Hex (ASCII SOH)character in front of the word 'TEST' (in Delphi that is the string: #1'Test'). This is something that REGEDIT will not allow you to do by typing - even with ALT-Keypad operations.

刚刚用 Windows 7 注册表做了一个实验：以编程方式创建一个带有 01 Hex (ASCII SOH)字符的键名，位于单词 'TEST' 前面（在 Delphi 中是字符串：#1'Test'）。这是 REGEDIT 不允许您通过键入来执行的操作 - 即使使用 ALT-Keypad 操作。

Not only did it create the key, it showed the key in REGEDIT as having a 'wide' space where the #1 character resided.

它不仅创建了密钥，而且在 REGEDIT 中显示密钥具有一个“宽”空间，其中 #1 字符所在的位置。

Copying and pasting this new subkey name into TEXTPAD allowed me to verify that it was indeed still a #1 character.

将这个新的子项名称复制并粘贴到 TEXTPAD 中，我可以验证它确实仍然是 #1 字符。

I've never read anywhere that #1 is deemed 'printable', but in Windows anything other than 00 Hex can be put into a print string and literally anything can be sent to a printer, so I guess the MSDN statement about this limitation is an oxymoron: because in Windows being a characterimplies being printable, ergo unprintable characterbecomes ...well, meaningless.

我从来没有读过#1 被认为是“可打印”的任何地方，但是在 Windows 中，除了 00 Hex 之外的任何东西都可以放入打印字符串中，并且实际上任何东西都可以发送到打印机，所以我猜关于这个限制的 MSDN 声明是矛盾的说法：因为在 Windows 中，字符意味着可打印，因此无法打印的字符变得......好吧，毫无意义。

Whilst you cannottype that #1 character directly into REGEDIT as a keyname (using the ALT-keypad-number entry method), you cannontheless paste it back from TEXTPAD to REGEDIT as part of a rename-operation. REGEDIT will even complain if you paste it to rename another peer subkey to your original one because the 'specified key already exists'.

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

Interestingly, I also experimented with the character #256 (which is no-longer ASCII, but is theoretically a Unicode Widechar, but not necessarily one deemed as "printable" if any parts of the input, storage or output mechanisms reject it).

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

Whilst I could create such a key programmatically, and see a strange looking 'A' in REGEDIT, it became somewhat less reliable in cut-and-paste. I'm guessing that the clipboard operations and interactions with different applications make this sort of thing a very dubious practice since TEXTPAD, for instance, might be making assumptions about whether you were pasting byte characters or wide characters that don't quite match what REGEDIT put into the clipboard - and vice-versa. If the code behind these operations are just expecting ANSI strings or UTF-16 Wide-Strings, and are being given something different, including byte-order differences and UTF-8 or similar differences that they were not expecting, then things are very likely to go wrong.

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

Finally, I experimented with an attempt to inject a widechar with order 0FFFF hex. That did not actually give any visual presence of the character in REGEDIT - how "unprintable" is that, then?. But the name did include the invisiblecharacter. I confirmed this by actually trying to create a separate peer subkey in REGEDIT without the offending character and as a result obtained what visually looked like two identical keys!

最后，我尝试尝试注入一个具有 0FFFF 十六进制顺序的宽字符。这实际上并没有给 REGEDIT 中的角色提供任何视觉存在 -那么，这有多“不可打印”？. 但是这个名字确实包含了隐形字符。我通过实际尝试在 REGEDIT 中创建一个单独的对等子项来确认这一点，而没有冒犯性的字符，结果获得了视觉上看起来像两个相同的键！

So in summary: It seems that you can put literally any character into a subkey name as long as it isn't a '\'. But it probably is not a very good idea to do so. And I think the term 'unprintable' in Windows generally only applies to 00 hex - and that is because it is usually used as a string terminator and therefore is a little bit difficult to 'send' through the registry API as a character!

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

What is quite worrying is the ability that this gives hackers to confuse and mislead. You could quite literally create a whole raft of registry subkeys that appear to have no names at all and can only be meaningfully used by applications, not humans. Yes, you could do that with space-characters, but some unicode characters (like FFFFh) have no width, and you can use any number of them together to create a unique and invisible name, or parts in a name! This makes them almost impossible to detect without using a laborious cut-and-paste, or a dedicated automated tool. In REGEDIT they all just look like identically named, or indeed unnamed, keys.

相当令人担忧的是，这会给黑客带来混淆和误导的能力。您可以从字面上创建大量注册表子项，这些子项似乎根本没有名称，只能由应用程序有意义地使用，而不能由人类使用。是的，您可以使用空格字符来做到这一点，但一些 unicode 字符（如 FFFFh）没有宽度，您可以将任意数量的它们一起使用来创建一个唯一且不可见的名称，或名称中的一部分！这使得它们几乎不可能在不使用费力的剪切和粘贴或专用自动化工具的情况下被检测到。在 REGEDIT 中，它们看起来都像是同名的，或者实际上是未命名的键。