Программирование: "Магиялық сан" - файл форматтарын анықтайтын кодтағы тұрақты мән. Оның мағынасын түсіндіру қиын, қателерге себеп болуы мүмкін. SEO үшін жақсартылған.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы 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)
Аталмаған сандық тұрақтылар
Сиқырлы сан немесе сиқырлы тұрақты терминдері бастапқы кодта тікелей сандарды пайдаланудың анти-үлгісін білдіреді. Бұл бағдарламалаудың ең көне ережелерінің бірін бұзу болып саналады, бұл ереже 1960 жылдардағы COBOL, FORTRAN және PL/1 нұсқаулықтарында көрсетілген. Кодта аталмаған сиқырлы сандарды қолдану дамытушылардың осы санды таңдау ниетін жасырады, көзге көрінбейтін қателерге мүмкіндік жасайды (мысалы, 3.14159265358979323846 санының әр цифры дұрыс па және бұл 3.14159 санына тең бе?) және бағдарламаны болашақта өзгерту мен кеңейтуді қиындатады. Барлық маңызды сиқырлы сандарды атаулы тұрақтылармен (түсіндірмелі айнымалылар деп те аталады) алмастыру бағдарламаны оқуды, түсінуді және күтіп ұстауды жеңілдетеді. Бағдарлама контексінде мағыналы болып таңдалған атаулар, бастапқы автор емес (немесе тіпті бастапқы автор кейінірек) бағдарламаны күтіп ұстаушыға оңай түсінілетін кодты қамтамасыз етеді. Unix-тің алтыншы нұсқасына дейінгі нұсқалары орындалатын файлды жадқа оқып, бағдарламаның бірінші төмен жад адресіне, яғни нөлге қатысты адреске секіріп өтетін. Unix-тің беттік жадты пайдаланатын нұсқаларының дамуымен орындалатын кескіннің компоненттерін сипаттау үшін басқыш құрылды. Сонымен қатар, бөлімше нұсқаулық ретінде енгізілген бірінші сөз ретінде басқышты өткіріп, бағдарламаны іске қосу үшін нұсқау берілді. Осылайша бағдарлама ескі, жылжымалы жад мекенжайларын пайдаланатын (стандартты) режимде немесе беттік жад режимінде орындалуы мүмкін. Орындалатын форматтардың саны артқан сайын, жаңа тұрақтылар тармаққа қатысты ауысуды ұлғайту арқылы қосылды. Unix бағдарламалық жүктеушісінің алтыншы нұсқасының бастапқы кодында exec функциясы файлдық жүйеден орындалатын (бинарлық) кескінді оқиды. Файлдың алғашқы 8 байты бағдарламаның (мәтін) және инициализацияланған (жалпы) деректер аймақтарының өлшемдерін қамтитын басқыш болды. Сонымен қатар, басқыштың алғашқы 16 биттік сөзі екі тұрақтымен салыстырылып, орындалатын кескінде жылжымалы жад мекенжайлары (нормалды), жаңадан енгізілген беттік жадты тек оқуға арналған орындалатын кескін немесе бөлек нұсқаулар мен деректерді беттік жадта сақтау бар-жоғын анықтау үшін салыстырылды. Басқыш тұрақтысының екі қызметі туралы ештеңе айтылмады, бірақ тұрақтының жоғары ретті байты PDP 11 тармақ нұсқаулығының операциялық коды болды (сегіздік 000407 немесе он алтылық 0107). Бағдарлама санағышына жеті қосылса, егер бұл тұрақты орындалса, Unix exec қызметі сегіз байттық орындалатын кескін басқышынан өтіп, бағдарламаны іске қосатынын көрсетті. Unix-тің алтыншы және жетінші нұсқалары беттік жадты пайдаланғандықтан, басқыш тұрақтысының екі қызметі жасырылды. Яғни, exec қызметі орындалатын файлдың бас (мета) деректерін ядролық кеңістіктегі буферге оқиды, бірақ орындалатын кескінді пайдаланушы кеңістігіне оқиды, осылайша тұрақтының тармақталу мүмкіндігін пайдаланбайды. Сиқырлы сандарды құру Unix сілтемелеушісі мен жүктеушісінде іске асырылды және сиқырлы сандарды тармақтау, мүмкін, әлі де алтыншы және жетінші нұсқаларымен бірге келген дербес диагностикалық бағдарламалар жиынтығында қолданылған. Осылайша, басқыш тұрақтысы иллюзияны қамтамасыз етті және сиқырлы сандардың критерийлеріне сай келді. Version Seven 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-пен басталады. GPT бөлу схемасының GUID Partition Table-інде BIOS Boot бөлімдері {21686148 6449 6E6F 744E 656564454649} арнайы GUID-ін қолданады, ол GUID анықтамасына сәйкес келмейді; керісінше, ол "Hah!IdontNeedEFI" жолының ASCII кодтарын шағын ендік тәртібімен ішінара пайдалану арқылы құрылады.
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.