Во-первых, обе формы являются «данными» в некотором смысле, и, если перейти к основам, они обе хранятся абсолютно одинаково на базовом уровне в двоичном формате. Будь то текстовый, числовой, исполняемый, что угодно, все это хранится в двоичном виде, в комбинации 0 и 1, на используемом вами носителе.
Итак, почему то, что вы называете текстом, отображает то, что оно делает?
Весь текст сохраняется снова, как комбинация 0 или 1. Но это само по себе довольно бесполезно для конечного пользователя, который хочет видеть значение, хранящееся на диске. Это где кодирование символов вступает в игру.
Возможно, вы слышали о некоторых других типах кодировки символов, таких как ASCII и UTF. Они используются для сопоставления сохраненного двоичного файла с распознаваемым символом (который затем будет отображаться с использованием определенного шрифта, но это немного выходит за рамки этой области).
Используя ASCII в качестве примера, символы хранятся в 7 битах (где байт состоит из 8 битов), от 0000000 до 1111111. Вы можете увидеть, как каждый персонаж отображается здесь:
С http://www.asciitable.com/
Каждый символ, то есть прописные, строчные, символы и "специальные символы", интерпретируется определенным значением. Используя Hello в качестве примера:
`H` -> Decimal 72 -> Binary 01001000
`e` -> Decimal 101 -> Binary 01100101
`l` -> Decimal 108 -> Binary 01101100
`l` -> Decimal 108 -> Binary 01101100
`o` -> Decimal 111 -> Binary 01101111
Другие карты символов будут использовать все 8 битов или даже более 1 байта для хранения символа, что позволяет хранить большие буквы или несколько алфавитов и больше символов в одном и том же файле с использованием той же кодировки.
Таким образом, мы можем видеть, как двоичный файл теперь может быть преобразован в то, что мы считаем "текстом".
Но что происходит, когда вы открываете файл другого типа, а не текст?
Каждый файл на вашем компьютере, сохраненный в двоичном виде, может быть открыт текстовым редактором, который попытается прочитать файл в виде кодировки. Конечно, то, что отображается, будет абсолютно бессмысленным, поскольку файл не был закодирован для чтения картой символов, а вместо этого выполнен другим способом. Многие байты будут совпадать с символом на карте, которую он использует, что иногда будет означать, что вы видите странный символ, который вы узнаете. Остальные либо не будут отображаться и возвращать нечетный или отсутствующий символ, либо будут соответствовать различным частям карты, которые не имеют смысла декодировать. Там ничто не мешает этому пробовать все же.
Я отредактировал данные для файла PNG, но он все еще открылся и не повредил. Зачем?
Глядя здесь, вы можете увидеть структуру файла PNG. В частности:
Чанки могут появляться в любом порядке, с учетом ограничений, накладываемых на каждый тип чанков. (Одно заметное ограничение заключается в том, что IHDR должен появляться первым, а IEND должен появляться последним; таким образом, блок IEND служит маркером конца файла.) Может появиться несколько фрагментов одного типа, но только если специально разрешено для этого типа.
Этот конкретный тип файла предоставляет маркер конца файла, который сообщит читателю, что данные за пределами этой точки не являются частью самого файла. Таким образом, вы можете добавить данные сверх этого, и это может не вызвать проблем, если читатель правильно обрабатывает файл. Тем не менее, если вы добавите еще один маркер EoF, это может вызвать путаницу.
Следует также отметить, что тип файла состоит из кусков, каждый из которых имеет проверку CRC. Проверка CRC сообщает читателю, допустим ли фрагмент и не был ли он изменен и должен всегда присутствовать. Читатель может быть обучен игнорировать данные, не включающие в себя допустимую комбинацию порций данных и CRC, хотя я подозреваю, что это приведет к ошибке какой-либо формы.
Дальнейшее чтение:
ASCII
Двоичный файл
Кодировка символов
