Прочитайте (чтобы понять) шестнадцатеричный код в проекте, декомпилированном Reflector
Автор вопроса: CommunityОтветов: 3
Я использовал .NET Reflector 5.1.5.0 для декомпиляции файла с расширением: .exe. После экспорта в проект у меня есть несколько классов со многими "специальными" символами :(
Например:
Label_065C (почему исходное название ярлыка было преобразовано...)
Match matchBaseTag = new Regex(@"(?‹=base\s+href\=[\x27\x22])(?[^\x27\x22]* )(?=[\x27\x22])").Соответствие(Результат); (я думаю, что x27 - это шестнадцатеричный код)
вы можете установить десятичный формат числа в View-> options-> Disassembler-> Number Format
Ответ 2 · рейтинг 1 · Jon Skeet
Информация в двоичном файле - это просто содержимое строки после, когда компилятор интерпретировал все escape-последовательности и т. д. - это необработанные текстовые данные, а не источник. Точно так же значения для таких вещей, как SiteID сравнения, являются просто целыми числами.
Reflector предлагает некоторый источник, который будет компилироваться в тот же двоичный код - он не знает, использовали ли вы шестнадцатеричный литерал или десятичный и т. д. Вы можете изменить формат числа, который он использует, в View / Options / Disassembler, заставив его в шестнадцатеричном или десятичном виде или оставив его решать. Не похоже, что есть аналогичная опция для определения того, как декомпилировать символы, отличные от ASCII, - было бы неплохо, если бы он мог использовать форму \uXXXX вместо \x, IMO.
Я не знаю о бите "ярлык", поскольку вы не дали достаточно контекста о том, где вы его видите или что это было раньше.
Ответ 3 · Jason Haley
Обычно, когда есть разница между представлением Reflector и тем, что, по моему мнению, должно быть - я использую ILDasm. Я думаю, что целочисленные проблемы могут быть решены с помощью того, что сказали Джон и Наджмеддин. Строки немного сложнее (например, значение атрибута авторского права и строка вашего регулярного выражения).
Строковые константы (вещи, заключенные в кавычки в исходном коде) хранятся в виде последовательностей байтов Unicode в двоичном файле (либо в куче больших двоичных объектов, либо в куче пользовательских строк). Вы можете точно увидеть, что находится в вашем двоичном файле, используя ILDasm, если вы сделаете следующее: 0. Загрузите свою сборку в ILDasm 1. View->Meta Info проверьте Raw:Heaps 2. View->Meta Info нажмите Show!
Если вы выполняете поиск по "авторскому праву", он, скорее всего, будет в куче больших двоичных объектов (значения атрибутов используют другую сериализацию для байтов и находятся в куче больших двоичных объектов с другими двоичными значениями), а для вашей строки RegEx она должна быть в пользовательских строках. куча.
Как только вы посмотрите на значение в ILDasm, вы увидите, что на самом деле находится в сборке... если есть разница между этим и тем, что показывает Reflector... скорее всего, Reflector делает все возможное, чтобы декодировать двоичную строку, чтобы экранировать нечитаемые символы в более читаемый формат. Поскольку существует несколько возможных кодировок/декодирований, Reflecor иногда показывает правильную строку, но просто неправильно декодирует (например, декодирование \x27 и \x22 для ' и ").
Короче говоря, ваши значения не изменились в сборке (скорее всего), просто Reflector неправильно декодирует их в исходную строку.
