Як відомі типи файлів, якщо не з суфікса файлу?

Мені хотілося б знати, як відомі типи файлів, якщо у назви файлів немає суфіксів.

Наприклад, файл з ім'ям myfileможе бути бінарним чи текстовим для початку, як система знає, чи файл є двійковим чи текстовим?

fileУтиліта визначає тип файлу по 3 способами:

Спочатку тести файлової системи : У межах цих тестів у файл викликається один із викликів сімейства stat . Це повертає різні типи файлів unix : звичайний файл, каталог, посилання, символьний пристрій, блоковий пристрій, названа труба або сокет. Залежно від цього складаються магічні тести.

У магії тести трохи складніше. Про типи файлів вгадується база даних шаблонів, що називається чарівним файлом . Деякі типи файлів можна визначити, прочитавши біт або число в певному місці файлу (наприклад, бінарні файли). Чарівний файл містить " магічні числа ", щоб перевірити файл, чи містить він чи ні, і яку текстову інформацію слід надрукувати. Ці " магічні числа " можуть мати значення 1-4Byte, рядки, дати або навіть регулярні вирази. З подальшими тестами можна знайти додаткову інформацію. У випадку виконуваного файлу додатковою інформацією буде те, чи буде вона динамічно пов'язана чи ні, позбавленачи ні, або архітектура. Іноді перед тим, як істинно ідентифікувати тип файлу, потрібно пройти кілька тестів. Але все одно, неважливо, скільки тестів виконано, це завжди лише гарна здогадка .

Ось перші 8 байт у файлі деяких поширених файлів, які можуть допомогти нам зрозуміти, як можуть виглядати ці магічні числа:

             Hexadecimal          ASCII
PNG   89 50 4E 47|0D 0A 1A 0A   ‰PNG|....
JPG   FF D8 FF E1|1D 16 45 78   ÿØÿá|..Ex
JPG   FF D8 FF E0|00 10 4A 46   ÿØÿà|..JF
ZIP   50 4B 03 04|0A 00 00 00   PK..|....
PDF   25 50 44 46|2D 31 2E 35   %PDF|-1.5

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

Розриви рядків також досліджуються, залежно від їх значень HEX:

• 0A( \n) класифікує файл, що закінчується Un * x / Linux / BSD / OSX
• 0D 0A( \r\n) - файли з операційних систем Microsoft
• 0D( \r) буде Mac OS до версії 9
• 15( \025) буде IBM AIX

Зараз починаються мовні тести . Якщо це здається текстовим файлом, у цьому файлі шукають конкретні рядки, щоб з’ясувати, яку мову він містить (C, Perl, Bash). Деякі мови скриптів можна також ідентифікувати за допомогою хешбангу ( #!/bin/interpreter) у першому рядку сценарію.

Якщо до файлу нічого не стосується, тип файлу неможливо визначити і fileпросто виводить "дані".

Отже, ви бачите, що суфікса немає потреби. Суфікс у будь-якому випадку може сплутати, якщо встановлено неправильно.

Часто це не хвилює. Ви просто передаєте її програмі, і вона інтерпретує її, або не робить. Можливо, це не буде корисно відкривати .jpg у текстовому редакторі, але вам це не завадить. Розширення, як і решта імен файлів, призначене для організаційної зручності людей.

Можливо також можлива побудова файлів, які можна правильно трактувати різними способами. Оскільки запускається формат ZIP-файлу, в кінці файлу є заголовок , ви можете додати інші речі спереду, і він все ще завантажиться як ZIP-файл. Це зазвичай використовується для створення саморозпаковуються поштових файлів.

Ця інформація зазвичай міститься у заголовку файлу. fileКоманда аналізує мету і повідомляє вам інформацію про файл. Багато інформації часто отримують із заголовків файлів, які часто бувають у перших кількох байтах файлу (див. Нижче). Система використовує заголовки, щоб визначити, як обробляти файли. #!/bin/bashна початку файлу вказує системі використовувати оболонку bash для інтерпретації наступного сценарію. ELFповідомляє системі, що це виконуваний файл ELF.

[~] root@www # file /bin/ls
/bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped

[~] root@www # file /etc/passwd
/etc/passwd: ASCII text

Приклади файлів:

[root@server4 ~]# xxd old_sm_logo.png | head -5
0000000: 8950 4e47 0d0a 1a0a 0000 000d 4948 4452  .PNG........IHDR
0000010: 0000 0134 0000 006f 0806 0000 0062 bf3c  ...4...o.....b.<

[root@server4 ~]# xxd /bin/ls | head -5
0000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
0000010: 0200 3e00 0100 0000 a024 4000 0000 0000  ..>......$@.....

[root@server4 proj]# xxd resizer.sh | head -5
0000000: 2321 2f62 696e 2f62 6173 680a 5b20 2d7a  #!/bin/bash.[ -z
0000010: 2022 2431 2220 5d20 2626 2065 6368 6f20   "$1" ] && echo

Перше, що потрібно перевірити, це жорстко закодований тип файлу, який розпізнається ядром. Це типи файлів, такі як каталог, спеціальний файл символів, спеціальний файл для блоку, спеціальний файл для труби, сокет та символічне посилання. Ця інформація надходить з inode файла. Якщо файл - це звичайний файл, наступний набір інформації надходить із перших 256 байт, шукаючи шаблони. Таким чином, текстові файли та вихідний код C розпізнаються шляхом вивчення цих байтів. Крім того, утиліти також шукають магічне число, яке використовується для тестування та перевірки типу файлу. Ви можете додати свої власні типи файлів для розпізнавання, додавши інформацію у файл /etc/magic. Перегляньте сторінку чоловіка, magic(5)щоб побачити формат чарівного файлу.

У старшій реалізації (наприклад, Solaris) у файлі /etc/magicперелічено більшість розпізнаних типів файлів.

fileКоманда застосовує деякі евристики від перевірки (частини) файл і зробити кваліфіковане припущення. Крім того, є деякі особливі випадки, коли можна отримати додаткову інформацію; як, наприклад, #!на початку текстового файлу, BoM (позначка порядку байтів) або конкретні байти заголовків файлів, що виконуються. Система використовує #!бінарні позначки у виконуваних файлах для їх розрізнення.

Система не знає, чи файл є двійковим чи текстовим. У всіх (AFAIK) операційних системах Unix типу, fopen(path, "rb")точно так само, як fopen(path "r")- це bне має ефекту. Це прийнято, оскільки стандартний C повинен бути переносним для деяких інших ОС, які роблять таке розрізнення.

Я заперечую, що "тип файлу" не є навіть змістовною концепцією в Unix;

У старі добрі часи мейнфрейм-комп’ютери підтримували їх декілька типів файлів, включаючи послідовний та індекс-послідовний. Сучасні операційні системи (Un * x і, можливо, Windows) зводять набір типів файлів до мінімуму (включаючи виконуваний, спільний об'єкт).

Можливо також можлива побудова файлів, які можна правильно трактувати різними способами

Можливо, існує складний формат файлу: фрагмент коду С, який можна інтерпретувати як опис зображення. Крім того, існують різні формати менш конкретні: текстовий файл, XML-файл, документ SOAP.