В частности, каков авторитетный источник этой информации?
Это может выглядеть как вопрос, не связанный с программированием, но мне нужно знать, содержит ли путь к реестру в мой код регулярное выражение или нет. Я решил, что лучший способ сделать это - предположить, что любое появление недопустимого символа (например, '*') означает поиск подстановочных знаков.
Для допустимых имен ключей и значений см. страницу MSDN в Структура реестра. В частности:
Каждый ключ имеет имя, состоящее из одного или нескольких печатных символов. Имена ключей не чувствительны к регистру. Имена ключей не могут включать символ обратной косой черты (\), но любой другой печатный символ может быть используемый. Имена значений и данные могут включать символ обратной косой черты.
Типы значений реестра объясняются в подробнее о MSDN здесь, если вам нужно знать допустимые значения.
Для всех вещей Windows, MSDN должен быть авторитетным источником - статья о Ограничения размера элемента реестра подразумевает, что Unicode хорош и Структура реестра говорит, что символы с обратной косой чертой и непечатаемые символы запрещены в именах ключей. Значения должны быть полностью печатаемыми символами.
Только что провел эксперимент с реестром Windows 7: программно создал имя ключа с символом 01 Hex (ASCII SOH) перед словом "TEST" (в Delphi это строка: # 1 "Test"). Это то, что REGEDIT не позволит вам сделать, даже набрав ALT-Keypad.
Он не только создал ключ, но и показал, что ключ в REGEDIT имеет "широкое" пространство, в котором находится символ # 1.
Копирование и вставка этого нового имени подраздела в TEXTPAD позволили мне убедиться, что это действительно символ # 1.
Я никогда не читал, чтобы № 1 считался "пригодным для печати", но в Windows в строку для печати можно вставить что угодно, кроме 00 Hex, и буквально все, что угодно, можно отправить на принтер, поэтому я предполагаю, что утверждение MSDN об этом ограничении оксюморон: потому что в Windows наличие символа подразумевает возможность печати, поэтому непечатный символ становится... ну, бессмысленным.
Хотя вы не можете ввести этот символ № 1 непосредственно в REGEDIT в качестве имени ключа (используя метод ввода номера клавиатуры ALT), вы тем не менее можете вставить его обратно из TEXTPAD в REGEDIT как часть операции переименования. REGEDIT даже будет жаловаться, если вы вставите его, чтобы переименовать другой одноранговый подраздел в исходный, потому что "указанный ключ уже существует".
Интересно, что я также экспериментировал с символом # 256 (который больше не является ASCII, но теоретически является Unicode Widechar, но не обязательно считается "пригодным для печати", если какие-либо части механизмов ввода, хранения или вывода отвергают его).
Несмотря на то, что я мог создать такой ключ программно и увидеть странную букву "А" в REGEDIT, он стал несколько менее надежным при вырезании и вставке. Я предполагаю, что операции с буфером обмена и взаимодействия с различными приложениями делают подобные вещи очень сомнительной практикой, поскольку, например, TEXTPAD может делать предположения о том, вставляете ли вы байтовые символы или широкие символы, которые не совсем соответствуют тому, что REGEDIT. положить в буфер обмена - и наоборот. Если код этих операций просто ожидает строки ANSI или широкие строки UTF-16, и ему присваивается нечто иное, включая различия в порядке следования байтов и UTF-8 или аналогичные различия, которых они не ожидали, тогда вещи с большой вероятностью пойти не так
Наконец, я экспериментировал с попыткой ввести широкий символ с гексом порядка 0FFFF. Это на самом деле не дает визуального присутствия персонажа в REGEDIT - насколько это "непечатно"? Но имя включало невидимого персонажа. Я подтвердил это, фактически пытаясь создать отдельный одноранговый подраздел в REGEDIT без оскорбительного символа и в результате получил то, что визуально выглядело как два идентичных ключа!
Итак, подведем итог: кажется, что вы можете поместить буквально любой символ в имя подраздела, если это не "\". Но это, вероятно, не очень хорошая идея, чтобы сделать это. И я думаю, что термин "непечатаемый" в Windows, как правило, относится только к шестнадцатеричному 00 - и это потому, что он обычно используется в качестве ограничителя строки и, следовательно, его немного трудно "отправить" через API реестра как символ!
Что вызывает беспокойство, так это способность хакеров запутывать и вводить в заблуждение. Вы можете буквально создать целую кучу подразделов реестра, которые, кажется, вообще не имеют имен и могут только осмысленно использоваться приложениями, а не людьми. Да, вы можете сделать это с пробелами, но некоторые символы Юникода (например, FFFFh) не имеют ширины, и вы можете использовать любое их количество вместе, чтобы создать уникальное и невидимое имя или части имени! Это делает их почти невозможными для обнаружения без использования трудоемкого вырезания и вставки или специального автоматизированного инструмента. В REGEDIT они все выглядят как ключи с одинаковыми именами или даже без имен.