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