Чому ви не бачите двійковий код, коли ви відкриваєте двійковий файл з текстовим редактором?

Чому ви не бачите двійковий код, коли ви відкриваєте двійковий файл з текстовим редактором? Наприклад, коли я відкриваю зображення з текстовим редактором, я бачу деякі дивні символи, а також деякі люди, що читаються; але зображення має бути закодовано у двійковій формі.

Двійкові та текстові дані не розділені: вони просто дані . Це залежить від тлумачення, яке робить їх тим чи іншим. Якщо ви відкриєте двійкові дані (наприклад, файл зображення) в текстовому редакторі, велика частина цього не матиме сенсу, оскільки це не відповідає обраній інтерпретації (як текст).

Те, що ви називаєте текстом, - це підмножина можливого вмісту файлу: Дані, які в заданому наборі символів перекладаються на читаються символи.

Наприклад, в ASCII ви бачите, що з 128 "дозволених" значень лише половина - букви та цифри, 30 - пунктуаційні, а решта - контрольні символи . Остання група просто не використовується багато в текстових файлах, і вони не мають насправді хорошого текстового подання. Деякі з них - це символи Tab і Newline , де текстові редактори вже потребують творчості для їх відображення.

Деякі текстові редактори мають можливість чітко відображати пробіл. Тоді вони насправді малюватимуться як символи, крім звичайної поведінки форматування (що також є лише інтерпретацією цих символів).

Чистий ASCII інтерпретує лише 128 значень. У байтах, що використовуються для зберігання цієї інформації, є 256 можливих значень кожен, тому половина можливих значень заборонена в ASCII. Вони використовуються, наприклад, у наборах символів для регіону, таких як латинська 1, але в ASCII вони не визначені. Вони не мають корисного представлення в засобі перегляду тексту, який може обробляти лише ASCII.

Бінарні дані зазвичай не інтерпретуються як текст. Тож у цих файлах зазвичай знаходяться всі можливі значення байтів . Все інше було б марно (і це є причиною, що ви можете дуже добре стиснути текст). Формати файлів зображень складні, і ви зазвичай не розглядаєте їх як текст, тому їх не потрібно читати.

Оскільки немає загальної інтерпретації даних (набір символів), яка відображає всі можливі значення для читаються символів, і оскільки це все одно не мало б сенсу (оскільки це не читабельний текст), основні частини відображаються як безглузді.

Шістнадцятковий редактор вибирає для даних інше представлення: він відображає кожен байт у вигляді двох шестинадцяткових цифр. Це просто інше представлення, і таке з легко читабельним набором символів: Усі 256 можливих байтових значень можна представити двома шістнадцятковими цифрами.

Оскільки просте зіставлення двійкових даних у шістнадцяткове і навпаки (4 двійкові цифри до / з однієї шістнадцяткової цифри), а двійкові дані містять дуже мало інформації на одну цифру, то шістнадцятковий - це, як правило, кращий спосіб для читання бінарних даних, якщо немає конкретних причини віддати перевагу іншому представництву.

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

Деякі клієнти FTP просять вас вказати, які закінчення файлів використовуються для текстових даних . Потім ці програми змінять вміст файлу відповідно до ОС машини, до якої ви підключені, оскільки Windows використовує іншу послідовність символів, що закінчується ( CR/LF), ніж Linux та Unix (включаючи Mac OS X; LF).

Тому що ви відкрили його в текстовому редакторі, а не у бінарному редакторі .

Це все стосується контексту та інтерпретації. У вашому комп’ютері є моделі високої та низької напруги або намагнічені області диска, які набувають сенсу лише тоді, коли ми вирішуємо, як їх інтерпретувати.

За різних обставин шаблон низький-високий-низький-низький-низький-низький-високий може означати цифру 65, велику літеру "А", блакитно-блакитного кольору, що клієнт замовив каву, дату "березень 6-ий 'або що-небудь взагалі, насправді.

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

Коли ви відкриєте файл зображення у текстовому редакторі, він сприймається як текст. Це дуже простий формат, набагато ближчий до того, що насправді відбувається в комп'ютері, але все ще відбувається деяка інтерпретація. Зокрема, майже кожен малюнок інтерпретується як певний персонаж, якийсь звичайний, як AZ, але також якийсь дивний персонаж. Кілька візерунків не відображаються як символи, але натомість трактуються як базове форматування: новий рядок, вкладка.

(Ситуація трохи ускладнюється такими речами, як Unicode і текстове кодування, як UTF-8, але я не буду мати справу з тими, що тут, для простоти.)

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

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

Зображення являє собою простий шаховий візерунок, з квадратами 3 пікселі в ширину та сірою рамкою в 1 піксель між кожним квадратом. - три чорних пікселя, сірий піксельний рамка, три білі пікселі, сірий піксельний межі, повторити.

Перший рядок на цьому зображенні матиме таке значення чотири рази:

Black    Black    Black    Gray     White    White    White    Gray
0x000000 0x000000 0x000000 0x7F7F7F 0xFFFFFF 0xFFFFFF 0xFFFFFF 0c7F7F7F

(У шістнадцятковій, а не у двійковій - рядок у двійковій буде в чотири рази довше - 0x7F буде замінено на 0b01111111)

Якщо ви завантажите цей рядок даних у текстовий редактор, ви отримаєте такий текст:

[Nul] [Nul] [Nul] [Nul] [Nul] [Nul] [Nul] [Nul] [Nul] [Del] [Del] [Del] [Blank] [Blank] [Blank] [Blank] [Blank] ] [Пустий] [пустий] [пустий] [пустий] [del] [del] [del]

Це тому, що 0x00 - це ASCII-код для значення Null, і вам потрібно написати це 3 рази, щоб отримати значення для чорного пікселя (у будь-якому випадку, 24 біт BMP) і у вас є 3 чорних пікселя. Тоді 0x7F - код ASCII для видалення, і вам потрібно ТОТИ три рази, щоб отримати сірий піксель. 0xFF не є вашим кодом ASCII для чогось іншого - навіть у розширеному наборі ASCII - і вам потрібно написати його 9 разів, щоб отримати 3 білих пікселя. Закінчивши його, ви отримаєте ще три Видалити, щоб записати сірий піксель.

Інший спосіб його відображення, який може бути більш корисним поясненням, - це зворотний приклад - що ДУ вам потрібно написати у файл, щоб отримати нулі та нулі, коли їх відкрити в текстовому редакторі?

ASCII-коди для нуля та одиниці, звичайно! Нуль у текстовому редакторі не зберігається як єдиний біт зі значенням 0, він зберігається як 8 біт зі значенням 0b00110000 або в шістнадцятковій кількості 0x30

Код ASCII для '0' дорівнює 0x30, а код ASCII для '1' - 0x31, тому якщо ви хочете зберегти шаховий шаблон як нулі та одиниці, ваш файл буде виглядати так:

text editor:
10101010
01010101
10101010
01010101

Stored data (ASCII values for '1', '0' and 'new line'):
0x31 0x30 0x31 0x30 0x31 0x30 0x31 0x30 0x0D 0x30 0x31 0x30 0x31 0x30 0x31 0x30 0x31 0x0D 0x31 0x30 0x31 0x30 0x31 0x30 0x31 0x30 0x0D  0x30 0x31 0x30 0x31 0x30 0x31 0x30 0x31

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

Якщо перші 8 біт вашого файлу не є 0b00110000, ваш текстовий редактор не запише "0", оскільки це ASCII-код символу "0". Якщо перші 8 біт у вашому файлі не є 0b00110001, ваш текстовий редактор не запише "1", оскільки це ASCII-код символу "1".

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