Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Жесткое кодирование (также жесткое кодирование или жесткое кодирования ) является практикой разработки программного обеспечения встраивания данных непосредственно в исходном код в виде программы или другого исполняемого объекта, в отличии от получения данных из внешних источников или его генерации на время выполнения . Жестко закодированные данные обычно можно изменить только путем редактирования исходного кода и перекомпиляции исполняемого файла, хотя их можно изменить в памяти или на диске с помощью отладчика или шестнадцатеричного редактора . Жестко запрограммированные данные обычно представляют собой неизменные части информации, такие как физические константы , номера версий.и статические текстовые элементы. С другой стороны, данные с программным кодированием кодируют произвольную информацию через вводимые пользователем , текстовые файлы , файлы INI , ответы HTTP-сервера, файлы конфигурации, макросы препроцессора, внешние константы, базы данных, аргументы командной строки и определяются во время выполнения.

Обзор [ править ]

Жесткое кодирование требует, чтобы исходный код программы изменялся каждый раз при изменении входных данных или желаемого формата, когда конечному пользователю может быть удобнее изменить детали каким-либо образом вне программы. [1]

Часто требуется жесткое кодирование, но его также можно рассматривать как антипаттерн . [2] Программисты могут не иметь разработанного решения для динамического пользовательского интерфейса для конечного пользователя, но все же должны предоставить эту функцию или выпустить программу. Обычно это временно, но в краткосрочном плане снимает необходимость предоставить код. Позже выполняется мягкое кодирование, позволяющее пользователю передавать параметры, которые дают конечному пользователю способ изменить результаты или результат.

Термин «жестко запрограммированный» изначально использовался в качестве аналогии с аппаратными схемами - и предназначался для передачи негибкости, возникающей в результате его использования при разработке и реализации программного обеспечения. В контексте расширяемых сред совместной разработки во время выполнения, таких как MUD , жесткое кодирование также относится к разработке основного механизма системы, отвечающего за низкоуровневые задачи и выполнение сценариев , в отличие от мягкого кодирования, которое разрабатывает высокоуровневые сценарии, которые получают интерпретируется системой во время выполнения со значениями из внешних источников, таких как текстовые файлы , файлы INI , макросы препроцессора, внешние константы, базы данных , аргументы командной строки , ответы HTTP- сервера , файлы конфигурации и пользовательский ввод . В этом случае этот термин не уничижительный и относится к общему развитию, а не к конкретному внедрению выходных данных.

Жесткое кодирование и бэкдоры [ править ]

Учетные данные с жестким кодированием - популярный способ создания бэкдора . Жестко закодированные учетные данные обычно не видны в файлах конфигурации или в выводе команд перечисления учетных записей и не могут быть легко изменены или обойдены пользователями. Если обнаружено, пользователь может иметь возможность отключить такой бэкдор путем изменения и перестроек программы из исходного кода ( если источник находится в открытом доступе ), декомпиляции или обратное проектирование программного обеспечения , непосредственно редактирование программы двоичного кода , или возбуждение в целостности проверка (например, цифровые подписи, защита от взлома и защита от мошенничества), чтобы предотвратить неожиданный доступ, но такие действия часто запрещены лицензионным соглашением .

Жесткое кодирование и DRM [ править ]

В качестве меры управления цифровыми правами разработчики программного обеспечения могут жестко закодировать уникальный серийный номер непосредственно в программе. Или же общепринято жестко закодировать открытый ключ , создав DRM, для которого невозможно создать генерацию ключей.

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

Фиксированный путь установки [ править ]

Если программа Windows запрограммирована так, что она всегда устанавливается в C: \ Program Files \ Appname и кто-то пытается установить ее на другой диск из-за недостатка места или по организационным причинам, она может не установиться или запуститься после установки. Эта проблема может быть не выявлена ​​в процессе тестирования, поскольку средний пользователь устанавливает на диск и в каталог по умолчанию, а тестирование может не включать возможность изменения каталога установки. Однако программистам и разработчикам рекомендуется не исправлять путь установки программы, поскольку путь установки по умолчанию зависит от операционной системы, версии ОС и решений системного администратора . Например, многие установки Microsoft Windows используют диск C: в качестве основного жесткого диска., но это не гарантируется.

Аналогичная проблема была с микропроцессорами на ранних компьютерах, которые начинали выполнение с фиксированного адреса в памяти.

Загрузочный диск [ править ]

Некоторые « защищенные от копирования » программы при запуске ищут определенный файл на гибком диске или флеш-накопителе, чтобы убедиться, что они не являются неавторизованными копиями. Если компьютер заменен на более новую машину, у которой нет дисковода для гибких дисков, программа, которая требует его сейчас, не может быть запущена, так как дискета не может быть вставлена.

Этот последний пример показывает, почему жесткое кодирование может оказаться непрактичным, даже если в то время казалось, что оно будет работать полностью. В 1980-х и 1990-х подавляющее большинство ПК было оснащено по крайней мере одним дисководом для гибких дисков, но позже дисководы для гибких дисков вышли из употребления. Программа, жестко запрограммированная таким образом 15 лет назад, может столкнуться с проблемами, если не будет обновлена.

Специальные папки [ править ]

В некоторых операционных системах Windows есть так называемые специальные папки, которые логически организуют файлы на жестком диске. При жестком кодировании могут возникнуть проблемы:

Путь к профилю [ править ]

Некоторые программы Windows жестко кодируют путь профиля к определенным разработчиком расположениям, таким как . Это путь для подавляющего большинства Windows 2000 или более поздних версий, но это может вызвать ошибку, если профиль хранится в сети или перемещается иным образом. Правильный способ получить это - вызвать функцию или разрешить переменную среды. Еще одно предположение, которое часто делают разработчики, - это предположение, что профиль расположен на локальном жестком диске.C:\Documents and Settings\UsernameGetUserProfileDirectory%userprofile%

Путь к папке "Мои документы" [ править ]

Некоторые программы Windows жестко задают путь к файлу My Documentsas ProfilePath\My Documents. Эти программы будут работать на машинах с английской версией, но в локализованных версиях Windows эта папка обычно имеет другое имя. Например, в итальянской версии My Documentsпапка называется Documenti . My Documentsтакже могли быть перемещены с помощью перенаправления папок в групповой политике в Windows 2000 или более поздней версии. Правильный способ получить это - вызвать SHGetFolderPathфункцию.

Решение [ править ]

Косвенная ссылка, такая как переменная внутри программы под названием «FileName», может быть расширена путем доступа к диалоговому окну «обзор файла», и программный код не нужно будет изменять, если файл перемещается.

Жесткое кодирование особенно проблематично при подготовке программного обеспечения к переводу на другие языки.

Во многих случаях одно жестко запрограммированное значение, например размер массива, может встречаться несколько раз в исходном коде программы. Это было бы волшебное число . Обычно это может вызывать программную ошибку, если изменяются некоторые представления значения, но не все. Такую ошибку сложно найти и она может оставаться в программе долгое время. Аналогичная проблема может возникнуть, если одно и то же жестко запрограммированное значение используется для более чем одного значения параметра, например, для массива из 6 элементов и минимальной длины входной строки 6. Программист может по ошибке изменить все экземпляры значения (часто используя средство поиска и замены редактора), не проверяя код, чтобы увидеть, как используется каждый экземпляр. Обе ситуации можно избежать, задав константы, которые связывают имена со значениями и используют имена констант для каждого появления в коде.

Один из важных случаев жесткого кодирования - это когда строки помещаются непосредственно в файл, что вынуждает переводчиков редактировать исходный код для перевода программы. (Существует инструмент, gettextкоторый позволяет оставлять строки в файлах, но позволяет переводчикам переводить их без изменения исходного кода; он эффективно де-жестко кодирует строки.)

Жесткое кодирование в соревнованиях [ править ]

На компьютерных соревнованиях, таких как Международная олимпиада по информатике , участники должны написать программу с определенным шаблоном ввода-вывода в соответствии с требованиями вопросов.

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

См. Также [ править ]

  • Проводка
  • Прошивка
  • Программное обеспечение с закрытым исходным кодом
  • Самомодифицирующийся код

Ссылки [ править ]

  1. ^ Эльфриде Дастин (2002). Эффективное тестирование программного обеспечения: 50 конкретных способов улучшить ваше тестирование . Эддисон-Уэсли Профессионал. С. 188–. ISBN 978-0-201-79429-8.
  2. ^ Таня Jan (14 октября 2020). Алиса и Боб изучают безопасность приложений . Вайли. С. 15–. ISBN 978-1-119-68740-5.