Почему вы не видите двоичный код при открытии двоичного файла в текстовом редакторе?

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

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

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

Некоторые текстовые редакторы имеют опции для явного отображения пробелов. Затем они будут фактически нарисованы как символы, в дополнение к их обычному поведению форматирования (которое также является просто интерпретацией этих символов).

Чистый ASCII интерпретирует только 128 значений. Байты, используемые для хранения этой информации, имеют по 256 возможных значений каждый, поэтому половина возможных значений не допускается в ASCII. Например, они используются в специфических для региона наборах символов, таких как Latin 1, но в ASCII они не определены. Они не имеют полезного представления в средстве просмотра текста, которое может обрабатывать только ASCII.

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

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

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

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

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

Некоторые FTP-клиенты просят указать, какие окончания файлов используются для текстовых данных . Эти программы затем изменят содержимое файла в соответствии с ОС компьютера, к которому вы подключены, поскольку Windows использует другую последовательность символов окончания строки ( CR/LF), чем Linux и Unix (включая Mac OS X; LF).

Потому что вы открыли его в текстовом редакторе, а не в бинарном редакторе .

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

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

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

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

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

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

As a simplified example, consider an image file opened with a text editor.

The image is a simple chess pattern, with the squares 3 pixels wide and a 1-pixel gray border between each square. - three black pixels, a grey border pixel, three white pixels, a grey border pixel, repeat.

The first line in that image would have the following value four times:

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

(In Hex, rather than Binary - the string in Binary would be four times as long - 0x7F being replaced with 0b01111111)

If you load that string of data in a text editor, you would get the following text:

[Nul][Nul][Nul][Nul][Nul][Nul][Nul][Nul][Nul][Del][Del][Del][Blank][Blank][Blank][Blank][Blank][Blank][Blank][Blank][Blank][Del][Del][Del]

This is because 0x00 is the ASCII code for the Null value and you need to write that 3 times to get the value for a black pixel (In 24bit BMP anyway) and you have 3 black pixels. Then 0x7F is the ASCII code for Delete, and you need THAT three times to get a gray pixel. 0xFF isn't valud ASCII code for anything in particular - even in the extended ASCII set - and you need to write it 9 times to get 3 white pixels. Finishing it off, you get three more Deletes to write a gray pixel.

A different way to show it, which might be more usefully explanatory, is the reverse example - what DO you have to write to a file in order to get zeroes and ones when opened in a text editor?

The ASCII codes for zero and one, of course! A zero in a text editor isn't stored as a single bit with value 0, it is stored as 8 bits with value 0b00110000, or in hex 0x30

The ASCII code for '0' is 0x30, and the ASCII code for '1' is 0x31, so if you want to store a chess pattern as zeroes and ones, your file will look like this:

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 

There is a lot more to it than this - files have starts and stops and metadata and all other kinds of things, but the takehome lesson and answer to your question is:

Unless the first 8 bits of your file are 0b00110000, your text editor will not write '0' because that's the ASCII-code for the character '0'. Unless the first 8 bits ouf your file are 0b00110001, your text editor will not write '1' because that's the ASCII-code for the character '1'.

Редактор недостаточно умен, чтобы понять, имеет ли смысл какой-либо текст, поэтому он отображает любой файл в виде текста, если не указано иное, если он имеет такую ​​функцию. Как отмечали другие, некоторые редакторы имеют функцию отображения шестнадцатеричных.