Какая самая маленькая единица, сохраняемая в файл?
1 бит (но не совсем. Это зависит от вашей файловой системы и оборудования, см. Ниже.)
Какова наименьшая делимая единица файла?
1 бит
Практически ни один файл не будет предназначен для доступа таким образом, но это тема форматов файлов и их реализация в различных программных и аппаратных средствах. Но если вы откроете какой-либо файл в шестнадцатеричном редакторе, вы можете технически изменить только один бит данных (например, измените 07 на 08). Некоторые шестнадцатеричные редакторы также дают вам двоичное представление, что делает еще проще переключать отдельные биты с 1 на 0 или обратно.
Везде, где я смотрю, кажется, что вам нужно прочитать файл по одному кусочку или слову за раз, а затем применить битовый фильтр, чтобы получить результат
Это зависит от того, какой именно язык программирования вы используете, но да, большинство из них работают на уровне байтов, а не бит, потому что это проще. Не говоря уже о том, что ОС и оборудование обычно не работают на битовом уровне ... поэтому язык программирования должен это учитывать. Однако заметным исключением являются логические значения, такие как true и false . Многие языки хранят логические значения в виде одного бита, двоичный 1 для true и двоичный 0 для false . Другое известное исключение - целые числа и значения с плавающей запятой, которые считаются двоичными в большинстве языков. Но для строк каждый персонаж будет использовать, по крайней мере, целый байт. До 4 байтов для 32-битных символов в кодировке Юникод.
Однако, как правило, способ написания кода приложения на несколько шагов исключается из "ON" и "OFF", из которых он в конечном итоге сделан и будет скомпилирован. Это потому, что вся цель компилятора - позволить вам написать абстрактный, читаемый человеком код, который затем превращается в настоящие машинные инструкции. Это особенность, а не ошибка.
Везде, где я смотрю, кажется, вам нужно прочитать файл по одному байту или слову за раз, а затем применить битовый фильтр, чтобы получить результат
Файлы - это совершенно другая банка червей. Здесь ваш носитель и файловая система, которую вы используете, определяют ваш минимальный размер файла. Это зависит от размера сектора, с которым была сконфигурирована файловая система, и минимального размера сектора, поддерживаемого носителем. это может быть 64, 128, 512, 1024, 2048, 4096, 8192 или даже 16384 байта. Если вы записываете файл, содержащий 1 бит данных, в файловую систему с использованием секторов размером 4096 байт, тогда этот файл будет занимать 4096 байт (или 4 КиБ), несмотря на то, что он содержит 1/32768 тыс. Таких данных.
Это сделано потому, что работа с небольшими размерами секторов создает дополнительную работу для устройства хранения и файловой системы ... но более крупные блоки менее эффективно используют пространство. Это компромисс между космической эффективностью и производительностью. Старые жесткие диски обычно имеют физический сектор размером 512 байт, что заставляет вас использовать сектора размером 512, 1024, 2048, 4069 байт (и т.д.). Оптические носители (CD и DVD) обычно используют 2048 байтовых секторов. А современные жесткие диски физически рассчитаны на сектора размером 4096 байт. Эффективность использования пространства не так велика, как это было, когда жесткие диски могли вместить только 1 гигабайт (о памяти).
Следует отметить, что использование 64-битной ОС не влияет ни на что из этого. Под 64-битным понимается, как операционная система и приложения, работающие на ней, обращаются к памяти (т.е. к ОЗУ). Не место для хранения. См. Документацию вашего языка программирования относительно переменных и типов данных, чтобы узнать больше о том, как он по-разному обрабатывает 32-битные и 64-битные среды.
Это создает вопрос, если у меня есть поврежденный файл, который сохранился только наполовину, сколько у меня буфера вокруг файла для доступа к данным?
Когда вы поймете это, обязательно опубликуйте статью о нем, создайте компанию по восстановлению данных и станьте грязными. Между тем, у каждого бизнеса по восстановлению данных есть мнение по этому вопросу, и ни одно из них не кажется более правильным, чем другое. "Короткий" ответ: зависит от файловой системы и носителя (плюс точное, но пока неизвестное состояние процесса чтения / записи в момент сбоя).
Как правило, магнитные запоминающие устройства, такие как жесткие диски, записывают целые сектора одновременно, поэтому теоретически каждый отдельный сектор записывается одновременно. Я не могу вспомнить, делает ли Flash Media то же самое в данный момент или нет. Должно быть, старею.
Может ли каждая часть фрагментированного файла делить только 8 бит или даже 64 бита на 64-битной ОС?
Фактически, фрагментация, по определению, - это когда секторы одного файла разбросаны по всему жесткому диску. Интересно, что эффект, который имеет место, когда файл имеет небольшие части, которые он изменил, состоит в том, что различные сектора, которые занимает файл, не будут полностью заполнены. Таким образом, вы можете получить файл размером 32 КБ, который занимает 42 КБ, поскольку многие его сектора используются только частично. Современные файловые системы, такие как NTFS и ext4fs, предпринимают шаги для предотвращения этого, но более старые, такие как FAT32, были печально известны этим (следовательно, дефрагментация раньше была такой большой проблемой). Кроме того, как я уже сказал, место для хранения больше не является редким и ценным ресурсом ... так что никому нет до этого дела.
Дефрагментация обычно означает захват всех секторов, которые занимает файл, и затем перезапись фактических данных файла в одно пустое пространство, в котором он может храниться, в процессе устранения всех, кроме одного частично используемого сектора.
И снова, сколько "битов" ОС не влияет на это.
Если я напишу программу для чтения двоичных файлов, будет ли какое-то неопределенное поведение, за которым я должен следить?
Читать бинарный файл откуда? Файл? Вы не сможете этого сделать, если не обойдете операционную систему, файловую систему и все драйверы оборудования, связанные с управлением устройствами хранения, и не получите прямой доступ к диску. Это плохой джиу. Не делайте этого. Не говоря уже о том, что современные ОС и оборудование предназначены для того, чтобы рассматривать попытки сделать это явной угрозой безопасности. Кроме того, помните, что многие устройства хотят записывать и считывать только определенную часть минимального размера для своего хранилища одновременно ... и это всегда больше, чем один бит.
Вместо этого вы можете вежливо запросить у вашей операционной системы наименьший кусок файла, который она готова предоставить вам через свои стандартные API, а затем разбить то, что она вам дает, на кусочки. Затем он спросит файловую систему и драйверы, которые будут взаимодействовать с оборудованием, и все это будет скоординировано и выполнено без необходимости выяснять, как сделать это самостоятельно для каждого контроллера хранилища, файловой системы и ОС, когда-либо созданных. ,
Обратитесь к документации по API языка программирования и библиотек, которые вы используете, чтобы узнать, для чего это нужно.
Например, выходить за пределы до EOF или чего-то еще.
Зависит от того, что именно вы имеете в виду за пределами. Существует терминология, соответствующая таковой в программировании, но обычно она относится к превышению размера буфера памяти и записи в части памяти, которые ваше приложение не выделило. Это тоже плохой джуджу ... но без смелых и заглавных букв. Главным образом потому, что это происходит так часто совершенно случайно, что большинство операционных систем предпринимают шаги, чтобы защитить себя и другие приложения от этого.
Однако, опять же, когда вы пишете или читаете с носителя, вы будете использовать свои языки программирования и API соответствующих библиотек, которые, в свою очередь, будут взаимодействовать с API-интерфейсами ОС, которые, в свою очередь, будут ... yadda yadda yadda , Как правило, файловая система отвечает за то, чтобы ничего не было записано там, где ее не должно быть, и, как правило, отправляет ошибку по цепочке в код вашего приложения, если вы пытаетесь это сделать.
