Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Последовательность байтов, используемая для идентификации или указания формата файла.
Sequence of bytes used to identify or indicate the format of a file
В компьютерном программировании "магическое число" может означать следующее:
In computer programming, a magic number is any of the following:
Уникальное значение с неясным смыслом или множественными повторениями, которое (желательно) следует заменить на именованную константу.
Постоянное числовое или текстовое значение, используемое для идентификации формата файла или протокола; для файлов смотрите Список сигнатур файлов.
Отличительное уникальное значение, которое маловероятно будет ошибочно интерпретировано как что-либо другое (например, глобально уникальные идентификаторы).
A unique value with unexplained meaning or multiple occurrences which could (preferably) be replaced with a named constant
A constant numerical or text value used to identify a file format or protocol; for files, see List of file signatures
A distinctive unique value that is unlikely to be mistaken for other meanings (e. g., Globally Unique Identifiers)
Неназванные числовые константы
Термин «волшебное число» или «волшебная константа» относится к антипаттерну использования чисел непосредственно в исходном коде. Это считается нарушением одного из старейших правил программирования, уходящего корнями в руководства по COBOL, FORTRAN и PL/1 1960-х годов. Использование безымянных волшебных чисел в коде скрывает намерения разработчика при выборе этого числа, увеличивает вероятность возникновения тонких ошибок (например, верна ли каждая цифра в числе 3.14159265358979323846 и равно ли оно 3.14159?) и затрудняет адаптацию и расширение программы в будущем. Замена всех значимых волшебных чисел именованными константами (также называемыми поясняющими переменными) упрощает чтение, понимание и сопровождение программ. Имена, выбранные для отражения смысла в контексте программы, позволяют легче понять код сопровождающему, который не является автором (или даже автору спустя некоторое время). В версиях Unix до Шестого издания исполняемый файл загружался в память, и выполнение начиналось с первого адреса в нижней части памяти программы, относительно адреса ноль. С развитием страничной организации Unix был создан заголовок для описания компонентов исполняемого образа. Также в качестве первого слова заголовка была вставлена инструкция перехода, чтобы пропустить заголовок и начать выполнение программы. Таким образом, программа могла быть запущена в старом режиме с перемещаемыми адресами памяти (обычном) или в страничном режиме. По мере разработки новых исполняемых форматов добавлялись новые константы путем увеличения смещения перехода. В исходном коде загрузчика программ Unix Шестого издания функция `exec` считывала исполняемый (бинарный) образ из файловой системы. Первые 8 байтов файла представляли собой заголовок, содержащий размеры программы (текста) и инициализированных (глобальных) областей данных. Кроме того, первое 16-битное слово заголовка сравнивалось с двумя константами, чтобы определить, содержит ли исполняемый образ перемещаемые ссылки на память (обычный), недавно реализованный странично организованный исполняемый образ только для чтения или разделенный образ инструкций и данных, организованный по страницам. О двойственной роли константы заголовка не упоминалось, но старший байт константы фактически являлся кодом операции инструкции перехода PDP-11 (восьмеричный 000407 или шестнадцатеричный 0107). Добавление семи к счетчику команд показывало, что при выполнении этой константы произойдет переход в службу Unix `exec` поверх восьмибайтового заголовка исполняемого образа и начнется выполнение программы. Поскольку в Шестом и Седьмом изданиях Unix использовался код страничной организации, двойственная роль константы заголовка была скрыта. То есть, служба `exec` считывала данные заголовка (метаданные) исполняемого файла в буфер пространства ядра, но сам исполняемый образ загружала в пользовательское пространство, тем самым не используя функцию перехода константы. Создание волшебных чисел было реализовано в связующем загрузчике и загрузчике Unix, а переход по волшебным числам, вероятно, все еще использовался в наборе автономных диагностических программ, поставлявшихся с Шестым и Седьмым изданиями. Таким образом, константа заголовка действительно создавала иллюзию и соответствовала критериям волшебства. В Седьмом издании Unix константа заголовка не проверялась напрямую, а присваивалась переменной с именем `ux mag` и впоследствии называлась волшебным числом. Вероятно, из-за своей уникальности термин «волшебное число» стал означать тип исполняемого формата, затем расширился до типа файловой системы и, наконец, до любого типа файла.
The term magic number or magic constant refers to the anti pattern of using numbers directly in source code. This has been referred to as breaking one of the oldest rules of programming, dating back to the COBOL, FORTRAN and PL/1 manuals of the 1960s. The use of unnamed magic numbers in code obscures the developers' intent in choosing that number, increases opportunities for subtle errors (e. g. is every digit correct in 3.14159265358979323846 and is this equal to 3.14159?) and makes it more difficult for the program to be adapted and extended in the future. Replacing all significant magic numbers with named constants (also called explanatory variables) makes programs easier to read, understand and maintain. Names chosen to be meaningful in the context of the program can result in code that is more easily understood by a maintainer who is not the original author (or even by the original author after a period of time). Pre Sixth Edition Unix versions read an executable file into memory and jumped to the first low memory address of the program, relative address zero. With the development of paged versions of Unix, a header was created to describe the executable image components. Also, a branch instruction was inserted as the first word of the header to skip the header and start the program. In this way a program could be run in the older relocatable memory reference (regular) mode or in paged mode. As more executable formats were developed, new constants were added by incrementing the branch offset. In the Sixth Edition source code of the Unix program loader, the exec function read the executable (binary) image from the file system. The first 8 bytes of the file was a header containing the sizes of the program (text) and initialized (global) data areas. Also, the first 16 bit word of the header was compared to two constants to determine if the executable image contained relocatable memory references (normal), the newly implemented paged read only executable image, or the separated instruction and data paged image. There was no mention of the dual role of the header constant, but the high order byte of the constant was, in fact, the operation code for the PDP 11 branch instruction (octal 000407 or hex 0107). Adding seven to the program counter showed that if this constant was executed, it would branch the Unix exec service over the executable image eight byte header and start the program. Since the Sixth and Seventh Editions of Unix employed paging code, the dual role of the header constant was hidden. That is, the exec service read the executable file header (meta) data into a kernel space buffer, but read the executable image into user space, thereby not using the constant's branching feature. Magic number creation was implemented in the Unix linker and loader and magic number branching was probably still used in the suite of stand alone diagnostic programs that came with the Sixth and Seventh Editions. Thus, the header constant did provide an illusion and met the criteria for magic. In Version Seven Unix, the header constant was not tested directly, but assigned to a variable labeled ux mag and subsequently referred to as the magic number. Probably because of its uniqueness, the term magic number came to mean executable format type, then expanded to mean file system type, and expanded again to mean any type of file.
GUID
Можно создавать или изменять глобально уникальные идентификаторы (GUID), чтобы сделать их запоминающимися, но это настоятельно не рекомендуется, так как это снижает их надежность как практически уникальных идентификаторов. Спецификации для генерации GUID и UUID достаточно сложны, что и обеспечивает их виртуальную уникальность при правильной реализации. Идентификаторы продуктов Microsoft Windows для продуктов Microsoft Office иногда заканчиваются на 0000 0000 0000000FF1CE ("OFFICE"), например, {90160000 008C 0000 0000 0000000FF1CE}, – идентификатор продукта компонента "Office 16 Click to Run Extensibility Component". Java использует несколько GUID, начинающихся с CAFEEFAC. В таблице разделов GUID схемы разделов GPT, разделы BIOS Boot используют специальный GUID {21686148 6449 6E6F 744E 656564454649}, который не соответствует определению GUID; вместо этого он формируется путем использования ASCII-кодов строки "Hah!IdontNeedEFI", частично в порядке little-endian.
It is possible to create or alter globally unique identifiers (GUIDs) so that they are memorable, but this is highly discouraged as it compromises their strength as near unique identifiers. The specifications for generating GUIDs and UUIDs are quite complex, which is what leads to them being virtually unique, if properly implemented. Microsoft Windows product ID numbers for Microsoft Office products sometimes end with 0000 0000 0000000FF1CE ("OFFICE"), such as {90160000 008C 0000 0000 0000000FF1CE}, the product ID for the "Office 16 Click to Run Extensibility Component". Java uses several GUIDs starting with CAFEEFAC. In the GUID Partition Table of the GPT partitioning scheme, BIOS Boot partitions use the special GUID {21686148 6449 6E6F 744E 656564454649} which does not follow the GUID definition; instead, it is formed by using the ASCII codes for the string "Hah!IdontNeedEFI" partially in little endian order.