Вопрос по regex, windows – Каковы действительные символы для ключей реестра и значений?

24

В частности, каков авторитетный источник этой информации?

Это может выглядеть как вопрос, не связанный с программированием, но мне нужно знать, содержит ли путь реестра, поданный к моему коду, регулярное выражение или нет. Я решил, что наилучший способ сделать это - предположить, что любое появление недопустимого символа (например, *) означает поиск по шаблону.

Это зависит. Эта ссылка будет полезна для вас:en.wikipedia.org/wiki/Windows_Registry joe

Ваш Ответ

3   ответа
7

Ограничения размера элемента реестра подразумевает, что Юникод хорош иСтруктура реестра говорит, что обратная косая черта и непечатные символы запрещены в именах ключей. Значения просто должны быть полностью печатными символами.

-1 Пока я не могу понять, что это добавляет к другому ответу (я даже переключил бы его на +1, если он вызвал что-то, что другой ответ не упомянул)
@RubenBartelink - 5 минут спустя ?! Дайте парню отдохнуть, он, вероятно, все еще печатал его, когда был опубликован другой ответ.
@mjaggard Я не понимаю, почему ФП заявляет о своей анонимности - я объяснил почему в комментарии. Мой спор остается: этот ответ ничего не добавляет и, следовательно, не должен быть проголосовал, независимо от того, как быстро он опубликовал дублирующую информацию. Большинство людей удаляют, когда сталкиваются с точкой, либо потому, что они ее заметили, либо кто-то привередливый, такой как nme, замечает и тратит баллы за снижение
Почему (поздний) и анонимный downvote?
36

Структура реестра, Особенно:

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.

Типы значений реестра описаны вподробнее о MSDN здесьВ случае, если вам нужно знать допустимые значения.

Впервые я запутался, поскольку в реестре использовался термин «ключ». и "значение" отличается от других программ. При обычном использовании «ключ»; будет иметь единственное «значение». В реестре «ключ» содержит полный набор «имя / данные»; пары, каждая из которых называется «значением». Следовательно, «значение» имеет как & quot; имя & quot; и "данные". Данные могут быть заданы как двоичные или как строка с нулевым символом в конце. Любая форма данных может содержать непечатаемые символы
Нет проблем. В любое время, когда вам нужна авторитетная информация о Windows, MSDN - это место, где можно искать ... Тем не менее, я все еще использую google для своих поисков в msdn - просто ограничьте сайт MSDN.
Спасибо! Я должен выработать привычку искать именно на этом сайте, а не гуглить, как курица без головы. JCCyC
Это происходит потому, что поиск в MSDN выполняется поисковой системой Bing, которая является дерьмом. Они должны использовать Lucene!
1

программно создал имя ключа с помощью Hex 01(ASCII SOH) символ перед словом «ТЕСТ» (в Delphi это строка: # 1 «Test»). Это то, что REGEDIT не позволит вам сделать, даже набрав ALT-Keypad.

Он не только создал ключ, но и показал, что ключ в REGEDIT имеет «широкий» параметр. пространство, где находился символ # 1.

Копирование и вставка этого нового имени подраздела в TEXTPAD позволили мне убедиться, что это действительно символ # 1.

Я нигде не читал, что # 1 считается «пригодным для печати», но в Windows все, кроме 00 Hex, может быть помещено в строку для печати, и буквально все может быть отправлено на принтер, поэтому я предполагаю, что заявление MSDN об этом ограничении это оксюморон: потому что в Windowscharacter подразумевает, что для печати, эргоunprintable character становится ... ну, бессмысленным.

Пока тыcannot введите этот символ # 1 непосредственно в REGEDIT в качестве имени ключа (используя метод ввода номера клавиатуры ALT), выcan тем не менее, вставьте его обратно из TEXTPAD в REGEDIT как часть операции переименования. REGEDIT даже будет жаловаться, если вы вставите его, чтобы переименовать другой одноранговый подраздел в исходный, потому что указанный ключ уже существует.

Интересно, что я также экспериментировал с символом # 256 (который больше не является ASCII, но теоретически является Unicode Widechar, но не обязательно считается «пригодным для печати», если какие-либо части механизмов ввода, хранения или вывода отклоняют его).

Хотя я мог бы создать такой ключ программно и увидеть странно выглядящий «A»; в REGEDIT он стал несколько менее надежным при вырезании и вставке. Я предполагаю, что операции с буфером обмена и взаимодействия с различными приложениями делают подобные вещи очень сомнительной практикой, поскольку, например, TEXTPAD может делать предположения о том, вставляете ли вы байтовые символы или широкие символы, которые не совсем соответствуют тому, что REGEDIT. положить в буфер обмена - и наоборот. Если код этих операций просто ожидает строки ANSI или Wide-Strings UTF-16, и ему присваивается нечто иное, включая различия в порядке следования байтов и UTF-8 или аналогичные различия, которых они не ожидали, тогда вещи с большой вероятностью пойти не так

Наконец, я экспериментировал с попыткой ввести широкий символ с гексом порядка 0FFFF. Это фактически не дает визуального присутствия персонажа в РЕГЕДИТЕ -how "unprintable" is that, then?, Но имя включалоinvisible персонаж. Я подтвердил это, фактически пытаясь создать отдельный одноранговый подраздел в REGEDIT без оскорбительного символа и в результате получил то, что визуально выглядело как два идентичных ключа!

Итак, подведем итоги: кажется, что вы можете поместить буквально любой символ в имя подраздела, если он не является "\". Но это, вероятно, не очень хорошая идея, чтобы сделать это. И я думаю, что термин «непечатный» в Windows обычно применяется только к 00 hex - и это потому, что он обычно используется в качестве ограничителя строки и, следовательно, его немного трудно «отправить». через реестр API как персонаж!

Что вызывает беспокойство, так это способность хакеров запутывать и вводить в заблуждение. Вы можете буквально создать целую кучу подразделов реестра, которые, кажется, вообще не имеют имен и могут только осмысленно использоваться приложениями, а не людьми. Да, вы можете сделать это с пробелами, но некоторые символы Юникода (например, FFFFh) не имеют ширины, и вы можете использовать любое их количество вместе, чтобы создать уникальное и невидимое имя или части имени! Это делает их почти невозможными для обнаружения без использования трудоемкого вырезания и вставки или специального автоматизированного инструмента. В REGEDIT все они выглядят как ключи с одинаковыми именами или даже без имен.

Похожие вопросы