BlockWrite — Процедура Delphi


Содержание

Pascal-Паскаль

Процедура BlockWrite Pascal-Паскаль

  • Скачено бесплатно: 6843
  • Куплено: 414
  • Pascal-Паскаль->B->Процедура BlockWrite Pascal-Паскаль

Процедура BlockWrite Pascal-Паскаль

Описание

BlockWrite — Записывает одну или большее количество записей из переменной в файл.

Объявление: Procedure BlockRead(Var F : File; Var Buf; Count : Word [; Var Result : Word]);
Режим: Windows, Real, Protected

Где:
F — нетипизированная файловая переменная
Buf — любая переменная
Count — выражение типа Word
Result — переменная типа Word

Замечания:

Процедура BlockWrite записывает Count или меньшее количество записей в файл F из блока памяти, начинающегося с первого байта, занятого переменной Buf. Реальное количество записанных записей (меньшее или равное Count) возвращается в необязательном параметре Result. Если параметр Result не определен, то в случае, когда количество прочитанных записей не равно параметру Count, происходит ошибка ввода/вывода.

Весь записанный блок занимает максимум Count * RecSize байт, где RecSize — размер записи, определяемый при открытии файла (или 128 байт, если размер записи не был определен). Если Count * RecSize больше, чем 64Кб, то происходит ошибка.

Параметр Result является необязательным. Если весь запрошенный блок был записан, то Result будет равно Count. Иначе, в случае, если Result меньше, чем Count, то диск заполнился до завершения записи блока. В таком случае, если параметр RecSize был больше 1, то Result вернет количество целиком записанных записей.

Указатель текущей позиции файла перемещается на количество записей, равное значению параметра Result.

В режиме <$I->функция IOResult вернет нуль, если операция была успешной, иначе она вернет отличный от нуля код ошибки.

Ограничения:

Файл должен быть открыт.

Пример программы для процедур BlockRead и BlockWrite

Программирование

Исходники Pascal (127)

Справочник

Справочник по паскалю: директивы, функции, процедуры, операторы и модули по алфавиту

BlockWrite — Процедура Delphi

Описание
Процедура записывает одну или несколько записей из переменной Buf во внешний файл, связанный с файловой переменной Vf. Параметр Count определяет количество записей, которое необходимо записать в файл. В параметре AmtTransferred возвращается фактическое количество скопированных записей, которое может быть меньше Count (например, когда место на диске закончилось до окончания записи в файл). Максимальный размер записываемого блока равен Count*RecSize байт, где RecSize — размер записи, определенный, во время открытия файла или 128 байт, если размер записи не был определен. Параметр AmtTransferred является необязательным. Но если данный параметр опущен, и количество прочитанных записей будет меньше Count, то возникнет ошибка ввода/вывода (исключение EinOutError).

BlockWrite — Процедура Delphi

Writes one or more records from a variable to an open file.

F is an untyped file variable, Buf is any variable, Count is an expression of type Integer, and AmtTransferred is an optional variable of type Integer.

BlockWrite writes Count or fewer records to the file F from memory, starting at the first byte occupied by Buf. The actual number of complete records written (less than or equal to Count) is returned in AmtTransferred.

The entire block transferred occupies at most Count * RecSize bytes. RecSize is the record size specified when the file was opened (or 128 if the record size was unspecified).

If the entire block is transferred, AmtTransferred is equal to Count on return.

If AmtTransferred is less than Count, the disk became full before the transfer was complete. In this case, if the file’s record size is greater than 1, AmtTransferred returns the number of complete records written.

BlockWrite advances the current file position by AmtTransferred records.

If AmtTransferred isn’t specified, an I/O error occurs if the number written isn’t equal to Count. If the $I+ compiler directive is in effect, errors raise an EInOutError exception.

Delphi — неправильная запись данных и чтение с использованием BlockWrite / BlockRead

Delphi Tokyo — я и создаю файл конфигурации. Я пишу файл конфигурации с помощью BlockWrite, а затем читаю его с помощью BlockRead. Что-то не так, когда я читаю строку. Я получаю то, что кажется азиатскими персонажами .

Я думаю, что проблема заключается в том, как я определяю свою процедуру ReadString.

Вот моя рутина WriteString

Моя процедура ReadString должна вернуть мне те же данные, но это не так. Вот код ReadString.

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

Вот FULL WriteConfig и ReadConfig Routine, а также SetConfigValues, который просто создает некоторые тестовые данные.

ShortString — это 8-битный строковый тип, который использует длину в 1 байт. Вы записываете ShortString в файл правильно (при условии, что размер «записи» файла был предварительно установлен в 1), но вы не читаете его правильно. Вы читаете 4-байтовое integer вместо 1-байтового AnsiChar / Byte для длины строки, а затем вы читаете 8-битные символы в 16-битную UnicodeString вместо ShortString .

Используйте это вместо:

Я бы не рекомендовал использовать ShortString вообще. Вы используете версию Delphi для Unicode, поэтому, если вы можете свободно изменять макет файла, я бы предложил, чтобы WriteString() принимала (Unicode)String качестве входных данных и преобразовывала ее в UTF-8 для хранения, а затем ReadString() сделать наоборот, например:

BlockRead и BlockWrite динамического массива

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

Ошибка появляется в этом MCVE:

Этот код приводит к ошибке ввода-вывода 998. Я пытался объявить тип TDoubleArray = array of Double; и передать ari в качестве параметра в BlockRead. Я также пытался установить SetLength(ari, Count) прежде чем вызывать BlockRead, но безуспешно.

Ответ на этот вопрос мне не помог. Код правильно читает Count но выдает исключение при загрузке массива. Что я делаю неправильно?

1 ответ

Вы должны установить размер блока в командах перезаписи / сброса:

RecSize — это необязательное выражение, которое можно указывать, только если F является нетипизированным файлом. Если F — нетипизированный файл, RecSize указывает размер записи, который будет использоваться при передаче данных. Если RecSize опущен, предполагается размер записи по умолчанию 128 байтов.

Это означает, что чтение данных приведет к переполнению выделенного буфера, что приведет к ошибке ввода-вывода из системы.

Предупреждение . Это более старый метод, который особенно опасен для использования из-за нетипизированного параметра Buf, что может привести к повреждению памяти. Размер записи, используемый BlockRead и BlockWrite, определяется необязательным вторым параметром для вызова сброса или перезаписи, который использовался для открытия записываемого файла. Желательно использовать потоки в ваших приложениях. Например, пользовательская процедура, включающая поток, может использовать как TMemoryStreams, так и TFileStreams , вместо того, чтобы ограничиваться использованием файлов, как в этих более старых подпрограммах.

В целом разница в скорости между BlockRead/Write и потоками незначительна. Для больших файлов предпочтительнее буферизованный обработчик.

Существует отличный пример обработчика потока буферизованных файлов от David: Буферизованные файлы (для более быстрого доступа к диску)

Как заметил @ kami / @ ТомБрунберг и то, что вы пробовали, вы также должны выделить длину динамического массива ari перед чтением данных.

Delphi — Wrong data writing then reading using BlockWrite/BlockRead

Delphi Tokyo — I and creating a configuration file. I am writing the config file using BlockWrite, then reading it using BlockRead. Something is wrong when I am reading a String. I am getting what appears to be asian characters.

I think the issue is with the way I am defining my ReadString routine.

Here is my WriteString routine

My ReadString Routine should give me back the same data, but it is not. Here is the ReadString Code.

The first value read from the config file is a Boolean, and it appears to be read the file properly. The next value is a string, and is messed up. Any help appreciated.

Here is the FULL WriteConfig and ReadConfig Routine, as well as a SetConfigValues which just creates some test data.

2 Answers 2

A ShortString is an 8-bit string type that uses a 1-byte length. You are writing the ShortString to file correctly (assuming the file’s «record» size has been set to 1 beforehand), but you are not reading it back correctly. You are reading a 4-byte integer instead of a 1-byte AnsiChar / Byte for the string length, and then you are reading 8-bit characters into a 16-bit UnicodeString instead of into a ShortString .

Use this instead:

I would not recommend using a ShortString at all, though. You are using a Unicode version of Delphi, so if you are free to change the file layout, I would suggest making WriteString() take a (Unicode)String as input and convert it to UTF-8 for storage, then make ReadString() do the reverse, eg:

For shortstrings the length is ord(s[0]) and only one byte is written. But you read four bytes into l. So you cannot expect this to work. As a fix, you can blockwrite the length as integer or blockread a byte variable l.

Not the answer you’re looking for? Browse other questions tagged delphi or ask your own question.

Hot Network Questions

Subscribe to RSS

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

site design / logo © 2020 Stack Exchange Inc; user contributions licensed under cc by-sa 4.0 with attribution required. rev 2020.11.11.35399

BlockRead и BlockWrite динамического массива

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

Ошибка появляется в этом MCVE:

Этот код приводит к ошибке I / O 998. Я пытался объявить тип TDoubleArray = array of Double; и передать в ari качестве параметра в BlockRead. Я также пытался , SetLength(ari, Count) прежде чем я называю BlockRead без какого — либо успеха.

Ответ на этот вопрос не помог мне. Код читает Count правильно , но поднимается исключение при загрузке массива. Что я делаю не так?

Вы должны установить размер блока в / Сброс команд Перепишите:

RecSize является необязательным выражение, которое может быть определено только, если F является нетипизированная файл. Если F является нетипизированной файл, RecSize определяет размер записи, которые будут использоваться в передаче данных. Если RecSize опущен, размер записи по умолчанию 128 байт предполагается.

Это означает, что чтение данных будет переполнение выделенного буфера, следовательно, ошибки ввода / вывода из системы.

Предупреждение : Это старый метод , который особенно опасен для использования из — за бестиповой параметр Buf, что приводит к потенциальной коррупции памяти. Размер записи используется BlockRead и BlockWrite регулируется с помощью дополнительного 2 — го параметра для сброса или Перепишите вызов , который был использован для открытия файла записываемого. Предпочтительно использовать потоки в своих приложениях. Например, процедура пользователя с участием потока может использовать как TMemoryStreams и TFileStreams , вместо того , чтобы быть ограничены использованием файлов , как с этими старыми рутин.

В общем случае разница в скорости между BlockRead/Write и потоков незначительна. Для больших файлов, предпочтительным является буферный обработчик.

Существует отличный пример буферном файл обработчик потока от Давида: буферизация файлов (для более быстрого доступа к диску)

Как @ Ки / @ TomBrunberg отметила и то , что вы пробовали, вы должны также выделить длину ari динамического массива перед чтением данных.

Delphi — неправильная запись данных, а затем чтение с использованием BlockWrite/BlockRead

Delphi Tokyo — я и создаем файл конфигурации. Я пишу конфигурационный файл с помощью BlockWrite, а затем читаю его с помощью BlockRead. Что-то не так, когда я читаю строку. Я получаю то, что кажется азиатскими персонажами.

Я думаю, проблема связана с тем, как я определяю мою процедуру ReadString.

Вот моя ручная программа WriteString

Моя ReadString Routine должна вернуть мне те же данные, но это не так. Вот код ReadString.

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

Вот FULL WriteConfig и ReadConfig Routine, а также SetConfigValues, который просто создает некоторые тестовые данные.

ShortString — это 8-битный строковый тип, который использует длину в 1 байт. Вы пишете ShortString в файл правильно (при условии, что размер файла «запись» был установлен на 1 заранее), но вы не вернете его правильно. Вы читаете 4-байтовое integer вместо 1-байтового AnsiChar / Byte для длины строки, а затем вы читаете 8-битные символы в 16-разрядную UnicodeString а не в ShortString .

Используйте это вместо этого:

Однако я бы не рекомендовал использовать ShortString . Вы используете Unicode-версию Delphi, поэтому, если вы можете изменить макет файла, я бы предложил сделать WriteString() взять (Unicode)String качестве входных данных и преобразовать ее в UTF-8 для хранения, а затем сделать ReadString() сделайте обратное, например:

Для коротких замыканий длина ord (s [0]) и записывается только один байт. Но вы читаете четыре байта в l. Поэтому вы не можете ожидать, что это сработает. В качестве исправления вы можете блокировать длину как целое или blockread переменной байта l.

Блог GunSmoker-а

. when altering one’s mind becomes as easy as programming a computer, what does it mean to be human.

17 октября 2011 г.

Сериализация — файлы в стиле Pascal

Оглавление

Общие сведения

В языке Pascal (и, следовательно, Delphi) есть встроенные средства по работе с файлами, не зависящие от нижележащей операционной системы.

В отличие от файловых API уровня операционной системы, файлы Pascal ориентированы на работу с типами данных языка (а не нетипизированным байтовым потоком, как это имеет место для API операционной системы, которая понятия не имеет про типы данных языка Pascal) и включают в себя высокоуровневую оболочку для работы со строками и наборами однородных данных. Поэтому работа с файлами Pascal удобнее, чем обращение к API операционной системы.

В отличие от других, более современных методов, использующих мета-информацию, файлы Pascal отличаются простотой использования. Поэтому, хотя другие методы работы с файлами могут упростить повседневную работу, но кривая их изучения существенно круче.

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

Сразу же замечу, что я не буду рассказывать для совсем уж начинающих — тут будет подробное изложение. Предполагается, что вы уже прочитали какую-то «книжку по Delphi».

Всего в языке есть три файловых типа:

  • текстовые файлы ( var F: TextFile; )
  • типизированные файлы ( var F: file of Тип-Данных; )
  • нетипизированные файлы ( var F: file; )

Нетипизированные файлы являются самым общим типом, а текстовые и типизированные файлы — обёрткой над нетипизированными файлами, частным случаем. Они предоставляют более удобные способы работы, путём наложения ограничений на содержимое файла.

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

Под текстовым файлом понимают файлы, содержащие читабельный для человека текст в кодировках ANSI, UTF-8 или Unicode. Текст представлен в явном виде, при этом некоторые специальные символы (с кодами от 0 до 31) являются специальными — они всегда имеют один и тот же смысл и обычно отвечают за форматирование текста: перенос строк, табуляцию и т.п. Обычно текстовыми файлами не называют документы — файлы, содержащие текст, но оформленные в формате определённой программы (вроде Word), потому что кроме самих данных (текста) такие файлы содержат служебную мета-информацию (заголовки, данные форматирования, атрибуты и т.п.).

В Pascal и Delphi в настоящий момент поддерживаются только текстовые файлы в кодировке ANSI. Файловые типы Pascal считаются устаревшим средством — появившись в языке давно, они уже не развиваются. В те далёкие дни люди мало волновались о кодировках, а о Unicode и UTF-8 и слыхом не слыхивали. Поэтому вы не сможете работать с текстовыми файлами, отличными от канонического ANSI-формата (кодовая страница ANSI, без BOM).

Примечание: начиная с Delphi XE2 (год выхода 2011), файлы Pascal впервые за пару десятков лет получили обновление API: теперь становится возможным указывать кодировку файла, которая может быть отличной от системной кодовой страницы, но вы всё ещё не можете использовать BOM.

Как я уже сказал, «текстовый файл» — это просто удобный ярлык, навешиваемый на файл, чтобы как-то охарактеризовать его содержимое. Это не однозначная и неизменная характеристика. Вы можете открыть текстовый файл в двоичном режиме и вы можете открыть произвольный бинарный файл как текстовый (весь вопрос в осмысленности результатов от таких действий; если первое ещё имеет смысл, то открытие двоичного файла как текстового — весьма сомнительная операция).

Типизированные файлы содержат записи одного типа и фиксированной длины. Чаще всего компонентами файла выступают именно записи ( record ), но это может быть и любой другой тип фиксированного размера. К примеру, текстовый файл можно открыть как типизированный — file of AnsiChar .

Наконец, под нетипизированными файлами понимают файлы произвольной, нерегулярной структуры. Это означает открытие файла в двоичном режиме — как набор байт, без какой-либо предопределённой структуры. Именно в этом режиме работают файловые API операционной системы. В подобном режиме можно открыть любой файл и это всегда будет иметь смысл.

Илон Маск рекомендует:  Бесплатный курс по SVG

Следует заметить, что понятие «типизированный файл» может трактоваться в двух смыслах. Во-первых, про файл можно говорить, что он типизированный в смысле строгого определения типизированного файла Pascal. Т.е. это файл, определяемый как » file of что-то «, состоящий из набора блоков одинаковой длины. Иными словами, это файл-массив однотипных элементов. Но на практике «типизированный файл» может употребляться и в более широком смысле — как файл с однородными данными. При этом файл не обязан состоять исключительно из последовательности записей, и сами записи файла не обязаны иметь одинаковый размер. К примеру, в начале файла может быть записан заголовок (сигнатура, контрольная сумма, число записей, версия файла и т.п.), а за ним идти набор записей одинакового вида (скажем, три числа и строка), но записи будут иметь переменную длину (строка разной длины). Такой файл могут называть типизированным (в смысле однородности его данных), но надо понимать, что он не будет типизированным в смысле языка Pascal — и работать с ним нужно будет как с нетипизированным, двоичным файлом. Применение термина «типизированный файл» к файлам нерегулярной структуры не корректно. Примером такого файла является .exe файл: в нём содержится первичный заголовок, который ссылается на дополнительные заголовки, в нём есть секции кода и данных (произвольных размеров), оглавление ресурсов (и сами ресурсы) и т.п. Все части файла имеют разную длину и разную структуру.

Общие принципы работы с файлами Pascal

Работа с любыми типами файлов имеет общие элементы, которые мы сейчас и рассмотрим.

Во-первых, работа с файлами в стиле Pascal почти всегда следует одному шаблону (кратко):

  1. AssignFile
  2. Reset/Rewrite/Append
  3. работа с файлом
  4. CloseFile

Подробно:

  1. Вы начинаете с объявления файловой переменной нужного типа. В зависимости от выбранного вами вида файла, вам нужно использовать var F: TextFile; var F: file of Тип-Данных; или var F: file; (текстовый, типизированный и двоичный файл соответственно), где «Тип-Данных» является типом данных фиксированного размера.

    Вы ассоциируете переменную с именем файла. Делается это вызовом AssignFile . Которая имеет прототип: Примеры вызова: Как видите — вы можете указывать любое допустимое имя файла с путём или без, но по соображениям надёжности кода я рекомендую вам всегда указывать полностью квалифицированное имя файла.

    Параметр CodePage является необязательным и он появился только начиная с Delphi XE 2. Он применим только для текстовых файлов. Если он не указан, то используется DefaultSystemCodePage , что для «русской Windows» равно Windows-1251.

    Он указывает кодовую страницу для выполнения перекодировки текста перед записью и после чтения данных из файла. Например: Текстовый файл должен быть в указанной вами кодовой странице. Кодовая страница — любая из принимаемых функцией WideCharToMultiByte (или её аналога на не Windows платформах). Файл не может иметь BOM. Так что на практике эта возможность полезна только для открытия ANSI файлов в кодировке, отличной от системной, но не текстовых файлов в UTF-8 и UTF-16, которые почти всегда имеют BOM.

    Данная операция НЕ открывает файл. Она просто записывает имя файла в файловую переменную. Так что когда вы откроете файл в будущем (как правило — сразу же после этой операции), то будет открыт именно файл с указанным тут именем.

    Данная операция всегда выполняется успешно, но вам нужно быть внимательным и никогда не вызывать её для уже открытых файлов — это приведёт к утечке открытых описателей файла (фактически, AssignFile просто тупо затирает нулями переменную перед выполнением своей работы; так что, чтобы там у вас ни было — оно будет потеряно). Собственно, эта операция нужна не столько для ассоциации с файловым путём, сколько для инициализации переменной. Как правило, за всё время жизни файловой переменной, эта операция применяется к ней единственный раз — первым действием.

    В Pascal вместо AssignFile используется Assign . Это ровно эта же процедура, просто в Delphi Assign переименовали в AssignFile , чтобы избежать конфликтов имён с другим кодом, который тоже использует имя Assign (к примеру — форма, компоненты, да и любой TPersistent ). Assign всё ещё существует в Delphi, так что любой старый код может быть перекомпилирован в Delphi и он будет работать. Но для нового кода вам лучше использовать AssignFile .

    Далее файл открывается. Открывать файл можно в трёх режимах: чтение, запись и чтение-запись. Как несложно сообразить, при открытии файла в режиме чтения из него можно только читать, но не писать — и так далее. Таким образом, всего у файловой переменной может быть 4 режима: закрыт, открыт на чтение, открыт на запись и открыт на чтение-запись (любые другие значения указывают на отсутствие инициализации файловой переменной — т.е. закрытый файл): Открытие файла выполняется с помощью функций Reset , Rewrite и Append .

    Что касается общих моментов: Rewrite создаёт новый файл; Reset открывает существующий файл, а Append является модификацией Reset и открывает файл для дополнения: т.е. после открытия файла переходит в его конец для дозаписи данных. Append применима только к текстовым файлам.

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

    1. Rewrite создаёт новый файл. Если файл с таким именем уже существует, то он удаляется и вместо него создаётся новый файл. Если файловая переменная уже открыта к моменту вызова Rewrite , то файл закрывается и пересоздаётся. После открытия файл позиционируется на начало файла, а функция EOF возвращает True — указывая на конец файла.
    2. Reset открывает существующий файл в режиме, указываемом в глобальной переменной FileMode (по умолчанию — чтение-запись; возможные значения — только чтение, только запись и чтение-запись). Если файл не существует или не может быть открыть в нужном режиме (заблокирован, отказ доступа) — то возникнет ошибка. Если файловая переменная уже открыта к моменту вызова Reset , то файл закрывается и открывается заново. После открытия файл позиционируется на начало файла, а функция EOF возвращает True , если файл существует и имеет размер 0 байт или (обычно) False — если файл существует и имеет ненулевой размер.
    3. Append применимо только к текстовым файлам и будет рассмотрена ниже.

    Глобальная переменная FileMode является именно глобальной переменной, а потому установка доступа не является потоко-безопасным действием. В любом случае, переменная может содержать комбинацию (через «or») следующих флагов: Вы можете указать один флаг вида fmOpenXYZ и один флаг из второй группы. Первый флаг определяет режим открытия: только чтение ( fmOpenRead ), только запись ( fmOpenWrite ) или чтение-запись ( fmOpenReadWrite ), вторые флаги определяют режим разделения файла: без разделения ( fmShareExclusive ), запретить другим читать ( fmShareDenyRead ), запретить другим писать ( fmShareDenyWrite ) и без ограничений ( fmShareDenyNone ). И два флага являются специальными. Флаги разделения используют устаревшую deny-семантику MS-DOS, в отличие от современного API. См. также: взаимодействие флагов режима открытия и разделения.

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

    Затем идёт работа с файлом — чтение и/или запись данных. Эти операции специфичны для разных типов файловых переменных. Их мы отдельно рассмотрим ниже.

    В итоге после работы файл нужно закрыть. Делается это вызовом CloseFile : После этого файл будет полностью закрыт, все изменения полностью сброшены на диск, а файловую переменную можно использовать заново — связать её с другим файлом (через AssignFile ), открыть и т.д., но, как правило, с файловой переменной работают лишь один раз.

    Примечание: аналогично AssignFile (см. выше), CloseFile является переименованной Close , которая тоже всё ещё доступна, но чаще всего замещается другим кодом (к примеру — Close у формы). Всегда используйте CloseFile в новом коде.

Итак, на этом мы закончили разбор общих принципов работы с файлами Pascal. Но прежде чем перейти к обсуждению способов работы с каждым конкретным типом файловых переменных, нужно обсудить ещё один важный общий момент: обработку ошибок.

Обработка ошибок

Тут надо сказать, что обработка ошибок работы с файлами Pascal весьма запутывающа. Дело в том, что обработку ошибок подпрограммы ввода-вывода файлов Pascal производят в двух режимах — которые переключаются весьма нестандартно: опцией компилятора. Она называется I/O Checking и расположена на вкладке Compiling (Compiler в старых версиях Delphi) в опциях проекта в Delphi (Project/Options). Что ещё хуже — эта настройка может быть изменена прямо в коде, используя директиву компилятора. В коде можно использовать <$I+>для включения этой опции и <$I->для выключения.

Итак, если эта опция выключена (либо в коде стоит <$I->), то обработку ошибок любых функций по работе с файлами в стиле Pascal (кроме AssignFile , которая всегда успешна) нужно проводить так: вам доступна функция IOResult , которая возвращает статус последней завершившейся операции. Если она вернула 0 — то операция была успешно выполнена (файл открыт, данные записаны и т.п.). Если же она возвращает что-то иное — произошла ошибка. Какая именно ошибка — зависит от значения, которое она вернула, которое (значение) представляет собой код ошибки. Возможные коды ошибок можно посмотреть здесь (только не закладывайтесь на неизменность этих кодов и неизменность таблицы). Помимо ошибок ввода-вывода, вы можете получать и системные коды ошибок. Их список можно увидеть в модуле Windows. Откройте его и запустите поиск по «ERROR_SUCCESS» (без кавычек). А ниже вы увидите список системных кодов ошибок. Наиболее частые ошибки при работе с файлами — ERROR_FILE_NOT_FOUND, ERROR_PATH_NOT_FOUND, ERROR_ACCESS_DENIED, ERROR_INVALID_DRIVE, ERROR_SHARING_VIOLATION. Но вообще код может быть почти любым. В любом случае, вам доступен только код ошибки, но не её текстовое описание. Если произошла ошибка, то все последующие вызовы функций ввода-вывода будут игнорироваться, пока вы не вызовете IOResult .

Итак, это старый режим обработки ошибок, который пришёл в Delphi из языка Pascal. С ним код выглядит примерно так: Вызов функции очищает код ошибки, так что если вы хотите обработать ошибку, нужно поступать так: Поскольку ошибка блокирует вызовы функций ввода-вывода, то обработку ошибок удобно делать один раз — в конце работы. Например: Этот код основан на том факте, что если при работе с файлом возникнет ошибка (к примеру — при открытии файла в момент вызова Rewrite из-за того, что в Edit1 указано недопустимое имя файла), то все нижеследующие функции не будут ничего делать, а код ошибки будет сохранён до вызова IOResult .

Обратите внимание, что правило «ничего не делать при ошибке» не распространяется на CloseFile . Вот почему мы вставили обработку ошибок в самый конец, а не до CloseFile .

Окей, с этим способом всё. Теперь, если вы включаете опцию I/O Checking или используете <$I+>, то функция IOResult вам не доступна, а всю обработку ошибок берут на себя сами функции ввода-вывода: если при вызове любой из них возникнет ошибка — функция сама обработает её путём возбуждения исключения (если модуль SysUtils не подключен — то возбуждением run-time ошибки; подробнее — тут). Исключение имеет класс EInOutError : Собственно, код в этом режиме всегда будет выглядеть так: А при возникновении проблем — у вас будет исключение, которое в стандартной VCL Forms программе в конечном итоге обрабатывается показом сообщения:

Я допускаю, что вы можете не очень быть знакомы с работой с исключениями (и в таком случае вам можно начать с этой статьи), но я бы всё же рекомендовал использовать режим <$I+>по одной очень простой причине: с исключениями поведение по умолчанию — показ ошибки; в режиме <$I->— скрытие и игнорирование. Иными словами, если в <$I->по незнанию или из-за лени вы опустите обработку ошибок, а при выполнении программы ошибка всё же возникнет — вы останетесь ни с чем: код просто не работает и вы понятия не имеете почему. С исключениями же такое невозможно: вам нужно специально прикладывать усилия, чтобы скрыть ошибку, так что это не может произойти случайно, по недосмотру.

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

Персональное примечание: напомню, что именно запутанность обработки ошибок в файлах Pascal привела к обнаружению вируса Virus.Win32.Induc.a.

В любом случае, это всё. И нам наконец-то можно приступить к обсуждению непосредственно работы с файлами.

Текстовые файлы

Итак, текстовый файл — это обычный файл, открываемый через переменную типа TextFile , для которого делается предположение о чисто текстовом содержимом. Тип TextFile в Delphi имеет псевдоним Text — это текстовый тип в Pascal. И снова: тип был переименован, старый Text всё ещё существует по соображениям совместимости, но в новых программах нужно использовать тип TextFile .

Когда вы открываете текстовый файл, его содержимое интерпретируется специальным образом: предполагается, что файл содержит последовательности читабельных символов, организованных в строки, при этом каждая строка заканчивается маркером end-of-line («конец строки»). Иными словами, текстовый файл трактуется не как просто file of Char , а с дополнительной смысловой нагрузкой. Для текстовых файлов есть специальные формы Read и Write , на которые мы посмотрим чуть позже.

В Delphi есть три стандартные глобальные переменные типа текстовых файлов: Input для чтения или Output для вывода — это специальные имена для стандартных каналов ввода-вывода; ещё есть ErrOutput — стандартный канал вывода ошибок, по умолчанию он направляется в канал вывода, но вызывающая программа может отделить его. Соответственно, Input открывается только для чтения и обычно представляет собой клавиатуру в консольных приложениях (если ввод не был перенаправлен), а остальные два — только для записи (и обычно представляют собой экран). Эти файловые переменные открываются автоматически. В Windows они открываются только для консольных программ, но на других платформах это может быть и не так.

В любом случае, для открытия текстовых файлов можно использовать Rewrite (создание), Reset (открытие) и Append (дозапись в существующий файл). Все три используются одинаково — им передаётся переменная файлового типа. Больше аргументов у них нет. Особенность текстовых файлов: Rewrite открывает файл (вернее — создаёт) в режиме только запись, Reset всегда открывает файл в режиме только чтение, а Append открывает файл в режиме только запись. Текстовые файлы нельзя открыть в режиме чтение-запись.
Append аналогична Reset , только устанавливает текущую позицию файла в конец и открывает в режиме записи, а не чтения.

После открытия вам доступны процедуры Write , WriteLn , Read и ReadLn для записи и чтения строк (варианты функций с *Ln допустимы только для текстовых файлов). Эти подпрограммы не являются настоящими функциями и процедурами, а представляют собой магию компилятора. Первым параметром у них идёт файловая переменная — она указывает файл, с которым будет производится работа (чтение строк или запись), а далее идёт произвольное число параметров — что пишем или читаем.

Если опустить файловую переменную — будет подразумеваться консоль ( Input и Output ). Это используется для ввода-вывода в консольных программах. Вам необязательно работать со стандартными каналами ввода-вывода именно через файлы Pascal, вы можете использовать и API.

Иными словами, вызовы этих функций имеют форму: Где «что-то» — это одна или более строковых или числовых переменных, указанных через запятую — как обычные аргументы. Мы рассмотрим это чуть позже.

При этом, краткая форма: эквивалентна: В Windows Input , Output и ErrOutput доступны только для консольных программ. Попытка использовать их в GUI приложении приведёт к ошибке (операция над закрытой файловой переменной). Это — частая ошибка новичков. Они забывают указать первым параметром файловую переменную. Эта ошибка не страшна в Windows, поскольку вы тут же увидите проблему при запуске программы, но достаточно коварна на других платформах, где стандартные каналы ввода-вывода могут быть открыты для всех программ. Таким образом, если вы забудете указать файловую переменную, то ваша программа будет работать, не выдавая ошибки — но будет работать неправильно.

Функции с постфиксом Ln отличаются от своих собратьев тем, что используют разделитель строк. Иными словами, Write записывает данные в файл, а WriteLn дополнительно после этого вписывает в файл перенос строки. Т.е. несколько вызовов Write подряд будут писать данные в одну строку. Аналогично, Read читает данные из файла, а ReadLn после этого ищет конец строки и делает переход к следующей строке в файле. В качестве разделителя строк используется умолчание для платформы, если вы пишете в файл, или Enter, если вы работаете с консолью. К примеру, для Windows разделителем строк является последовательности из двух символов #13#10 — известные как CR (carriage return) и LF (line feed), они имеют коды 13 и 10, соответственно. По историческим причинам выбор разделителя строк зависит от платформы. Вы можете изменить умолчание вызовом SetLineBreakStyle , но замечу, что работа с файлами другой платформы — это достаточная головная боль. Я не буду это подробно рассматривать. Часто наилучшее решение — предварительная нормализация данных и файлов. В частности, в Delphi есть функция AdjustLineBreaks.

Read читает все символы из файла вплоть до конца строки или конца файла, но она не читает сами маркеры. Чтобы перейти на следующую строчку — используйте ReadLn . Если вы не вызовите ReadLn , то все вызовы Read после встречи маркера конца строки будут возвращать пустые строки (для чисел — нули). Опознать конец строки или конец файла можно с помощью функций EoLn и EoF (или функций SeekEoLn и SeekEoF — и эти функции не следует путать с функцией Seek ). Если же читаемая строка длиннее, чем аргумент у Read / ReadLn , то результат обрезается без возбуждения ошибки. Но если вы читаете числа, то Read пропускает все пробелы, табуляторы и переносы строк, пока не встретит число. Иными словами, при чтении чисел они должны отделяться друг от друга пробелами, табуляторами или размещаться на отдельных строках. При чтении строк вы должны переходить на следующую строку сами.

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

В общем случае параметр выглядит так:

Где в квадратных скобках указываются опциональные (необязательные) части. OutExpr — это само выражение для записи. Оно может быть переменной, константой или непосредственным значением. MinWidth и DecPlaces являются спецификаторами форматирования и должны быть числами. MinWidth указывает общую длину вывода и должно быть числом большим нуля. По необходимости слева добавляется нужное количество пробелов. А DecPlaces указывает число знаков после десятичной точки и применимо только при записи чисел. Если эти данные не указаны, то используется научный формат представления чисел. Форматирование значений при выводе — наследие Pascal, где не было функций форматирования строк. В современных программах предпочтительнее использовать функцию Format и её варианты. Этот современный вариант форматирования данных является стандартным решением в Delphi и предоставляет больше возможностей.

Write пишет значения друг за другом, без разделителей. Поэтому, когда вы записываете числа, вам нужно вставлять пробелы, табуляторы или использовать WriteLn .

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

Далее необходимо заметить, что переменные текстового файлового типа имеют буфер. Все данные, записываемые в файл, на самом деле записываются в этот буфер. И лишь при закрытии файла или переполнения буфера данные сбрасываются на диск. Аналогичные действия производятся и при чтении файла. Это делается для оптимизации посимвольного ввода-вывода. Буфер можно сбросить и вручную в любой момент — с использованием подпрограммы Flush . По умолчанию размер буфера равен 128 байтам, но его можно изменить на произвольное значение вызовом SetTextBuf .

Текстовые файлы не поддерживают позиционирование.

Типизированные файлы

Типизированный файл — это очень простая БД в виде «array of что-то». Как уже было сказано, «что-то» должно иметь фиксированный размер в байтах, поэтому строки и динамические массивы хранить нельзя (но можно — короткие строки или статические массивы символов). Для открытия файлов доступны Rewrite и Reset . Здесь нет никаких особенностей по сравнению с вышеуказанными общими принципами. Запись и чтение из файла осуществляется с помощью Write и Read .

В отличие от текстовых файлов, типизированные и нетипизированные файлы поддерживают позиционирование. Вы можете установить текущую позицию в файле с помощью Seek . Процедура принимает два параметра — файл и номер позиции, на которую нужно переместиться. Положение отсчитывается не в байтах, а в размере записи файла. Иными словами, если вы работаете с, к примеру, file of Integer , то Seek(F, 0) переместит вас в начало файла, Seek(F, 1) — ко второму элементу (т.е. через 4 байта от начала файла), Seek(F, 2) — к третьему (через 8 байт), а Seek(F, FileSize(F)) — в конец файла. Т.е. функция FileSize тоже возвращает размер файла не в байтах, а в записях. Этот размер совпадает с размером в байтах только для file of byte и аналогичных типов — с однобайтовыми записями. Текущую файловую позицию (снова в записях) всегда можно узнать вызовом FilePos .

Ещё одной особенностью типизированных (и нетипизированных) файлов является функция Truncate . Она удаляет содержимое файла за текущей позицией. После её вызова функция EoF возвращает True .

Нетипизированные файлы

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

Для нетипизированных файлов нам доступны Rewrite и Reset — равно как и для типизированных файлов. Но тут есть одно важное отличие: для нетипизированных файлов эти процедуры принимают два параметра. Первый параметр, как обычно, файловая переменная. А второй параметр — размер блока. Размер блока измеряется в байтах и является аналогом размера записи у типизированных файлов. Размер блока влияет на все подпрограммы работы с нетипизированными файлами, которые принимают размеры или позицию. Все они подразумевают указание размеров/позиции в блоках, а не байтах. Вы можете указать 1, чтобы производить измерения в байтах. Плохая новость — второй параметр является опциональным, его можно не указывать. Проблема тут в том, что если вы его не укажете, то размер блока по умолчанию будет 128 байт — не самое очевидное поведение.

Далее, для чтения и записи в нетипизированный файл вместо Read и Write используются функции BlockRead и BlockWrite . Обе они используются одинаково: первый параметр — файловая переменная, второй параметр — что пишем/читаем, третий параметр — сколько пишем/читаем (в блоках). Функция возвращает сколько реально было прочитано/записано. Если блок прочитан/записан целиком, то результат равен третьему параметру. У обеих функций есть перегруженные варианты, у которых результат функции возвращается четвёртым параметром.

Замечу, что второй параметр — нетипизированный. Это значит, что компилятор не выполняет проверок типа. И вам лучше бы не напутать, что туда передавать. Я в первую очередь сейчас говорю про указатели и динамические типы. К примеру: Фух, достаточно сложно. Но только если вы не понимаете как работают указатели.

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

Прочие подпрограммы и особенности

Хотя типы файловых переменных являются «чёрным ящиком», но внутренне они представлены записями TTextRec (для текстовых файлов) или TFileRec (для всех прочих файлов). Обе записи объявлены в модуле System : Вам не нужны эти записи для обычной работы, но иногда могут быть ситуации, когда вам нужно получать доступ к полям записи. Сделать это можно простым приведением типа: Примечание: структура записей зависит от версии вашей Delphi. Прежде чем использовать код, который работает с этими записями или объявляет аналогичные хак-записи — убедитесь, что код написан для вашей версии Delphi или адаптируйте объявления и код.

Практика

Все примеры ниже приводятся с полной обработкой ошибок для режима <$I+>. Примеры используют файл в папке с программой. Это удобно для тестирования и экспериментов, но, как указано ранее, этого нужно избегать в реальных программах. После тестирования и перед использованием кода в релизе вы должны заменить папку программы на подпапку в Application Data.

Практика: текстовые файлы

  1. Одно значение: Double Обратите внимание, что запись чисел всегда использует фиксированный формат числа — вне зависимости от региональных установок. Иными словами, конвертация чисел в строки и обратно выполняется процедурами Str и Val . Это имеет как плюсы, так и минусы.

С одной стороны, файл, созданный на одной машине, без проблем прочитается на другой.

С другой стороны, текстовый файл, очевидно, предназначен для редактирования человеком. Иначе зачем делать его текстовым? А человек вправе ожидать, что числа будут использовать «правильный формат». К примеру, для России это — использование запятой в качестве разделителя целой и дробной частей, а не точки. Простого решения этой проблемы для текстовых файлов в стиле Pascal нет.

Одно значение переменного размера: String Ключевой момент при записи данных с динамическим размером — размещать каждое такое значение на отдельной строке. Тогда размер данных = размеру строки.

Набор однородных значений: array of Double Обратите внимание, что записываем мы все значения в одну строчку — поэтому нам нужно вставить разделитель (пробел). Кроме того, мы могли бы также писать каждое число на отдельной строке — используя WriteLn . Тогда пробел был бы уже не нужен.

Что касается чтения, то мы могли бы читать ровно как и писать — циклом. Но это подразумевает, что у вас жёсткая структура файла. Т.е. записали все числа в одну строчку — значит, и человек после редактирования файла должен оставить все числа в одной строке. И так далее.

Поэтому вместо этого я показал, как вы можете считать файл произвольной структуры — лишь бы в нём были бы числа. Для этого мы делаем цикл чтения, пока не будет встречен конец файла ( while not SeekEof(F) do ), а в самом цикле считываем и добавляем в массив каждое число. При этом мы пользуемся тем фактом, что Read при чтении числа будет пропускать все пробельные символы, включая переносы строк. Вот почему нам не нужно явно вызывать ReadLn .

Ещё один момент — использование SeekEoF вместо просто EoF . Если бы мы использовали EoF , то тогда в массив добавлялся бы ноль в конец, если в конце файла стоит несколько пробелов или пустых строк.

Набор однородных значений переменного размера: array of String Здесь всё оказывается ещё проще — динамические данные должны размещаться на отдельной строке, так что мы просто используем WriteLn / ReadLn . Обратите внимание, что в этом случае, поскольку мы записываем строки, то нет никакой возможности отличить пустую строку в конце файла — часть ли это данных или просто человек случайно добавил её. Если в ваших данных пустые строки недопустимы, то вы можете заменить EoF на SeekEoF , как это сделано в предыдущем примере.

Запись — набор неоднородных данных: Тут всё достаточно прозрачно — каждое поле на новой строке.

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

Массив из записей внутри записи — составные данные: С вложением самих записей проблем не возникает — я даже не буду писать пример, т.к. он эквивалентен предыдущему. Просто выпишите в ряд WriteLn полей TCompose . Для полей-записи вместо одного WriteLn вам нужно будет написать несколько — по одному на каждое поле вложенной записи. Ну а ReadLn будут зеркальным отражением WriteLn .

Но вот вложение массива записей уже является непреодолимым препятствием для общего случая. Дело в том, что в текстовом файле нет возможности как-то указать размер вложенных данных, ведь обычная техника записи динамических данных в текстовый файл — использование разделителей (чаще всего — переноса строк). В частных случаях вы можете найти решение. Скажем, отделять поле Related пустой строкой от следующего элемента/поля. Но в общем случае приемлемого решения нет — вам нужно использовать нетипизированный файл. В некоторых случаях вы можете предложить введение формата в текстовый файл. Вроде INI, XML, JSON и т.п. Но на это мы посмотрим в следующий раз.

Практика: типизированные файлы

  1. Одно значение: Double В данном случае число записывается в двоичном формате, а не текстовом, так что все проблемы с региональными настройками обходят нас стороной.

Тут надо сделать примечание, почему вообще для этого примера выбран именно тип Double , а не Extended , который в Delphi является де-факто стандартом для чисел с плавающей запятой. Дело в том, что Extended зависит от платформы. Его размер может меняться. Так что если вы компилируете, скажем 32-битную и 64-битную программы — у них размер Extended будет разным. Что означает, что из одной программы вы не сможете прочитать данные, созданные в другой. Это не проблема, если вы планируете работу только в одной платформе — можете спокойно использовать Extended . В противном случае вам нужно использовать Double . Ну а если вам нужно прочитать Extended , созданный на другой платформе, то вы можете использовать тип TExtended80Rec (появился, начиная с Delphi XE2, где, собственно, и появилась поддержка нескольких платформ) вместо Extended .

Аналогично, по этой же причине вам следует избегать Integer и Cardinal при работе с типизированными файлами — потому что это generic-типы, размер которых может меняться. Используйте вместо них LongInt и LongWord соответственно.

Одно значение переменного размера: String . Сделать это для типизированных файлов невозможно. В типизированный файл (в смысле файловых типов языка Pascal) нельзя записывать данные переменного (динамического) размера. Для динамических данных нужно использовать либо текстовые, либо нетипизированные файлы. Что вы можете сделать — так это использовать какое-то ограничение.

К примеру, если брать строки, то вы можете использовать ShortString — это ограничит ваши данные ANSI и 255 символами. Ещё вариант — статический массив символов. Скажем array[0..4095] of Char ( AnsiChar / WideChar ). Обратите внимание, что запись в файл ShortString или массива из символов — это не аналог текстовых файлов, потому что кроме значимого текста в файле появляется т.н. padding — мусорные данные, не несущие смысловой нагрузки, а служащие для дополнения данных до нужного размера. Вы можете вызывать FillChar или ZeroMemory для предварительной очистки данных перед записью — чтобы визуально подчеркнуть неиспользуемость дополнения.

Надо понимать, что чем больше (по байтовому размеру) вы возьмёте тип, тем больше места у вас будет тратиться зря (на padding), если в основной массе у вас короткие строки. С другой стороны, если вы возьмёте недостаточно большой тип, то ваши данные будут обрезаться. Так что подобный вариант далеко не всегда возможен — а только, если вы можете предложить подходящее ограничения размера.

Здесь и далее я не буду приводить пример — он всегда эквивалентен предыдущему примеру с данными фиксированного размера. Только замените типы.

Набор однородных значений: array of Double Обратите внимание, что нам не нужен разделитель, поскольку элементы имеют фиксированный размер. Кроме того, нет проблемы с пробелами в конце, ранее решаемой SeekEoF . Кроме того, фиксированность элементов позволяет узнать длину массива заранее — по размеру файла, что в итоге позволяет написать более эффективный код.

Запись — набор неоднородных данных: Аналогично второму примеру, записать неоднородные данные в типизированный файл невозможно. Если вы объявите file of LongWord , то вы не сможете записать в него строку и наоборот. В общем, нужно использовать текстовые или нетипизированные файлы.

Вы можете подумать, что вы могли бы объявить file of TData — ну, с заменой динамических строк на фиксированные аналоги, конечно же. А затем использовать первый пример. Да, это будет работать для конкретного объявления TData , но только этот пример — не на запись в файл record -а, а на запись неоднородных данных.

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

Практика: нетипизированные файлы

  1. Одно значение: Double
    Обратите внимание на 1 у Rewrite / Reset . Конечно, мы могли бы использовать вместо неё SizeOf(Double) . Но это фактически означало бы, что мы используем нетипизированный файл как типизированный. А в чём тогда смысл примера?

Одно значение переменного размера: String Данный случай прост — размер данных определяется по размеру файла. Для примера я выбрал AnsiString , а не String по друм причинам — во-первых, String — это псевдоним либо на AnsiString , либо на UnicodeString , в зависимости от версии Delphi. Иными словами, тут получается ситуация, аналогичная ситуации с Extended в разделе примеров для типизированных файлов. Так что вам нужно использовать явные типы — AnsiString , WideString (или UnicodeString ), а не String , иначе файл, созданный в одном варианте программы, нельзя будет прочитать в другом варианте программы.

Во-вторых, используя AnsiString , я показал, как вы можете загрузить в строку весь файл целиком, «как есть». Хотя, если подобный подход использовать в реальных программах, то уж лучше использовать array of Byte или хотя бы RawByteString — чтобы подчеркнуть двоичность данных.

Набор однородных значений: array of Double Данный пример эквивалентен примеру с типизированными файлами. Только теперь мы используем двоичный доступ, без учёта типа — так что нам приходится указывать явно все размеры. Вообще говоря, это общий принцип — работа с нетипизированными файлами и фиксированными размерами эквивалента типизированным файлам с учётом коэффициента размера.

И снова, благодаря фиксированности размеров элементов, мы можем установить размер массива ещё до чтения из файла.

Обратите внимание, что не имеет значения, какой индекс используется внутри выражения у SizeOf . Более того, не требуется даже наличие (существование) этого элемента. Это потому, что мы не обращаемся к нему — мы только просим у компилятора его размер. Это, по сути, константа. Так что всё выражение вообще не вычисляется — оно просто заменяется числом. Это удобный трюк для написания подобного кода, потому что это удобнее, чем писать тип явно: SizeOf(Double) . Почему? А что, если мы изменим объявление типа с Double на Single ? И забудем обновить SizeOf ? Тогда это приведёт к порче памяти — т.к. писаться или читаться будет больше, чем реально есть байт в элементе. Это выглядит не очень страшно для массива из Double , но рассмотрите вариант, скажем, строки — изменение размера Char гораздо более вероятно. А вот если мы используем форму SizeOf как в примере, то такой проблемы не будет — размер изменится автоматически.

Набор однородных значений переменного размера: array of String С записью набора динамических данных возникает проблема — как отличить один элемент от другого? Мы не можем более использовать переход на другую строку, как это было с текстовыми файлами. Тут есть несколько вариантов.

Самый простой и очевидный — ввести разделитель данных. Т.е. элементы отделяются друг от друга специальным символом. В качестве такого чаще всего выступает нулевой символ (#0) — это аналог разделителя строк в текстовых файлах. Тогда чтение-запись сведётся к примеру два. Но я не стал показывать этот путь, т.к. он очевидно вводит ограничение на возможные данные: теперь данные не могут содержать в себе разделитель (каким бы вы его ни выбрали). Конечно, вы можете его экранировать, но гораздо проще будет выбор другого подхода.

И я его показал — это явная запись размера данных до записи самих данных. Т.е. мы пишем два значения для каждого элемента: длину и сами данные.

Кроме того, в этом же примере показано, как можно сделать так, чтобы внутри программы работать с хорошо знакомым String , а в файле хранить фиксированный тип ( AnsiString / RawByteString или WideString / UnicodeString ). Вообще говоря, даже если вы работаете на Delphi 7 или любой другой версии Delphi до 2007 включительно — я бы рекомендовал всегда писать Unicode-данные в формате WideString во внешние хранилища.

Обратите внимание, что в качестве счётчика длины используется LongInt , а не Integer — по причинам, указанным выше для типизированных файлов: String , Extended , Integer и Cardinal могут менять свои размеры в зависимости от окружения — поэтому мы используем другие типы, которые гарантировано всегда имеют один и тот же размер.

Запись — набор неоднородных данных: В отличие от типизированных файлов, для нетипизированных файлов нет никаких проблем с записью неоднородных данных — вы просто пишете одно за другим. Данные фиксированного размера самодокументируются, а для динамических данных вы пишете сначала их размер, а затем сами данные. При чтении повторяете всё это в обратном порядке.

Кстати, я бы вынес запись динамических данных в отдельные служебные подпрограммы: Тогда чтение-запись свелись бы к: Выглядит существенно проще и красивее, не так ли? Иллюстрация силы выделения кода в подпрограммы.

Набор (массив) из записей — иерархический набор данных: Для начала хочу сразу же заметить, что странное выражение для поля Salary сделано для обхода бага Delphi. Вообще, там должно стоять просто BlockWrite(F, Values[Index].Salary, SizeOf(Values[Index].Salary)) , но в настоящий момент это выражение даёт ошибку «Variable required», поэтому используется обходной путь: мы берём указатель и разыменовываем его. Вообще говоря, это NOP-операция. А смысл её заключается в потере информации о типе. Это достаточно частый трюк, когда мы хотим запустить свои шаловливые руки под капот языка, минуя информацию типа, но в данном случае он используется для более благих целей: обхода бага компилятора. Вы можете использовать BlockWrite(F, Values[Index].Salary, SizeOf(Values[Index].Salary)) , если ваша версия компилятора это позволяет, или просто выбрать другой тип данных (не Currency ).

В любом случае, надо заметить, что достаточно часто при записи/чтении массива записей новички пытаются сделать такую вещь, как запись элемента целиком ( BlockWrite(F, Values[Index], SizeOf(Values[Index])) ). Это будет работать для записей фиксированного размера, не содержащих динамические данные (указатели). Ровно как это работает для типизированных файлов. Но если в записях у вас встречаются строки, динамические массивы и другие данные-указатели, то этот подход не будет работать. Собственно, если вы используете типизированные файлы, то компилятор даже не даст вам объявить такой тип данных ( file of String , например, или file of Запись , где Запись содержит String ). Но суть нетипизированных файлов — в прямом доступе, минуя информацию типа. Так что по рукам за это вам никто не даст. Вместо этого код будет просто вылетать или давать неверные результаты. А проблема тут в том, что для динамических данных, поле — это просто указатель. Записывая элемент «как есть» вы запишете в файл значение указателя, но не данные, на которые он указывает. Запись в файл произойдёт нормально, но в файле вы не найдёте своих строк. Чтение из файла тоже пройдёт отлично. Но как только вы попробуете обратиться к прочитанной строке — код вылетит с access violation, потому что указатель строки указывает в космос, на мусор.

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

Вместо этого в примере я показал уже известную технику: запись длины строки вместе с её данными. Это избавляет вас от всех недостатков ShortString /массива символов, но даёт новый недостаток: теперь вы не можете сохранить данные одной строчкой, вам нужно писать их поле-за-полем.

Массив из записей внутри записи — составные данные: Как видите — здесь нет никаких проблем, вы просто соединяете воедино техники из предыдущих примеров. Мы используем технику с записью счётчика длины для динамических данных в двух местах: при записи строк и при записи массивов (поле Related ).

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

Заметьте, что вы всё ещё должны писать записи по отдельным полям. И если вы меняете объявление записи — вам лучше бы не забыть поменять код, сериализующий и десериализующий запись.

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

Преимущества и недостатки файлов в стиле Pascal

Плюсы:

  • Отлично подходят для начального изучения языка
  • Вы наверняка знаете, как с ними работать, ибо это первый способ работы с файлами, который все изучают
  • Удобство работы с (текстовыми) данными: форматирование и переменное число аргументов
  • Гибкий подход, позволяющий работать с текстовыми, типизированными и произвольными данными
  • Встроенная буферизация даёт прирост производительности при записи небольших кусочков из-за экономии на вызовах в режим ядра
  • Могут быть расширены на поддержку любых файловых устройств, а не только дисковых файлов (т.е. IPC, pipes, сетевых каналов и т.п.) — путём написания своих адаптеров ввода-вывода, называемых «Text File Device Drivers». Подробнее см. Text File Device Drivers в справке Delphi

Минусы:

  • Необходимость ручной сериализации данных
  • Неудобная (и неоднозначная) обработка ошибок
  • Поведение кода зависит от директив компилятора
  • Нет поддержки Unicode и кодировок (улучшено начиная с Delphi XE2)
  • Проблемы с обработкой больших файлов (более 2 Гб)
  • Проблемы с глобальными переменными
  • Проблемы с многопоточностью
  • В некоторых случаях требуется ручной сброс буфера
  • Недостаточная гибкость для некоторых задач
  • Нестандартный код

Пояснение по последнему пункту: файлы Pascal пришли в Delphi из её предшественника. В них есть странная обработка ошибок, волшебные функции с переменным числом параметров, нестандартное для языка форматирование строк — всё это выбивается из обычного кода Delphi, оно выглядит иначе. Разнородный код — обычно это не хорошо.

Вывод: это отличный выбор для изучения языка и работы с файлами, но лично я для практических задач предпочитаю держаться подальше от файлов в стиле Pascal, но кто-то может считать это удобным способом. Если текстовые файлы ещё как-то оправдывают своё существование (если вы закроете глаза на их минусы), то типизированные и нетипизированные файлы практически зеркалируют потоки данных, но не имеют над ними никаких преимуществ.

BlockWrite — Процедура Delphi

Delphi 4 для начинающих. Часть 3
Разгребаясь с письмами читателей, я решил начать следующую статью с работы с файлами и строковыми переменными. На такой ход меня натолкнуло следующее письмо: «Я только начал программировать на Delphi. У меня к вам большая просьба: при создании различных программ часто приходится работать с файлами (создавать, удалять, копировать, переписывать файлы), не могли бы вы в ближайшем номере «Компьютерной газеты» мне рассказать о методах работы с файлами». Что ж, желание просящих выполняю.

Подавляющее большинство приложений, с которыми работает пользователь, должно как-то сохранять результаты своей работы, сохранять изменения в настройках. Для сохранения настроек приложения зачастую используют системный реестр, а вот для сохранения конечных данных приходится использовать файлы или базы данных. О базах данных мы поговорим в будущих статьях, а о работе с файлами я поведаю Вам уже сейчас.

Для использования файлов в приложении разработчику приходится решать множество задач. Основные из них – это поиск необходимого файла и выполнение с ним операций ввода/вывода.

Основные принципы и структура файловой системы мало изменились еще со времен MS-DOS. Если не принимать во внимание способы защиты файлов и организацию их хранения на уровне кластеров, то все остается без изменений вот уже скоро двадцать лет. Новые варианты файловых систем (FAT32, NTFS) не изменяют главного – понятия файла и способов обращения к нему. Поэтому современный программный код Delphi, например, для чтения данных из файла, удивительно похож на аналогичный, написанный, к примеру, на Turbo Pascal 4.0.

При организации операций файлового ввода/вывода в приложении большое значение имеет тип используемых данных. В основном это строки, но встречаются числовые данные или структурированная информация, например, записи или массивы данных. О типе хранимых в файле данных необходимо знать заранее. Для работы с файлами необходимо для начала описать тип файла. Для этого используются специальные файловые переменные. Они делятся на нетипизированные и типизированные. В Delphi имеется одна нетипизированная переменная. Для ее обозначения используется ключевое слово file :

Такие файловые переменные используются для организации быстрого и эффективного ввода/вывода безотносительно к типу данных. При этом подразумевается, что данные читаются или записываются в виде двоичного массива. Для этого используются специальные процедуры блочного чтения и записи.

Типизированные файловые переменные обеспечивают ввод/вывод с учетом конкретного типа данных. Для их объявления используется ключевое слово file of, к которому добавляется конкретный тип данных. Например, для работы с двоичным файлом файловая переменная будет иметь вид:

v ar ByteFile: file of byte;

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


type Country = record

var CountryFile: file of Country;

Для работы с текстовыми файлами используется специальная файловая переменная TextFile или Text :

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

Итак, для выполнения операции чтения и/или записи необходимо выполнить следующие действия:

  1. Объявить файловую переменную;
  2. При помощи функции AssignFile связать эту переменную с требуемым файлом;
  3. Открыть файл при помощи функций Append, Reset или Rewrite;
  4. Выполнить операции чтения и/или записи. При этом, в зависимости от сложности задачи и структуры данных, может использоваться целый ряд вспомогательных функций.
  5. Закрыть файл при помощи функции CloseFile .

В качестве примера рассмотрим небольшой фрагмент исходного кода программы:

If OpenDlg1.Execute then AssignFile(F, OpenDlg1.fileName) else exit;

While Not EOF(F) do

Если в диалоге OpenDlg1 был выбран файл, то его имя связывается с файловой переменной F при помощи процедуры AssignFile . В качестве имени файла всегда рекомендуется передавать полное имя файла (включая путь к нему). Как раз в таком виде возвращают результат выбора файла диалоги работы с файлами, описанные в материале прошлого номера. Затем при помощи процедуры Reset этот файл открывается для чтения и записи. В цикле осуществляется чтение из файла текстовых строк и запись их в компонент TMemo . Процедура Readln осуществляет чтение текущей строки файла и переходит на следующую строку. Цикл выполняется до тех пор, пока функция EOF не сообщит о достижении конца. По завершении цикла файл закрывается.

Теперь остановимся поподробнее на назначении функций, используемых для файлового ввода/вывода. Открытие файла может осуществляться тремя процедурами:


procedure Reset(var F [: File; RecSize: Word ] );
— открывает существующий файл для чтений и записи, текущая позиция устанавливается на первой строке файла;


procedure Append(var F: Text);
— открывает файл для записи информации после его последней строки, текущая позиция устанавливается на конец файла;

procedure Rewrite(var F: File [; Recsize: Word ] ); — создает новый файл и открывает его, текущая позиция устанавливается в начало файла. Если файл с таким именем уже существует, то он перезаписывается.

Чтение данных из файла выполняют процедуры Read и Readln.


procedure Read( [ var F: Text; ] V1 [, V2. Vn ] ); —
для текстовых файлов;


Procedure Read(F, V1 [, V2,…,Vn ] );
— для типизированных файлов.

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

procedure Readln([ var F: Text; ] V1 [, V2, . Vn ]); — считывает одну строку текстового файла и устанавливает текущую позицию на следующую строку. Если использовать процедуру без переменных, то она просто передвигает текущую позицию на следующую строку.

Процедуры для записи данных в файл Write и Writeln работают аналогично.

Для контроля за текущей позицией в файле применяются две основные функции. Функция EOF возвращает значение True, если достигнут конец файла. Функция EOLN сигнализирует о достижении конца строки. В качестве параметра в функции необходимо передавать файловую переменную.


procedure Seek(var F; N: Longint); —
обеспечивает смещение текущей позиции на N элементов. Размер одного элемента в байтах зависит от типа данных файла (от типизированной переменной).

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

Для реализации этого режима необходимо использовать только нетипизированные файловые переменные. Размер блока определяется в процедуре открытия файла ( Reset, Rewrite, Append ). Непосредственно для выполнения операций используются процедуры BlockRead и BlockWrite . Процедура


procedure BlockRead(var F: File; var Buf; Count: Integer [; var AmtTransferred: Integer]);

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

В блочном режиме чтения/записи размер блока необходимо выбирать таким образом, чтобы он был кратен размеру одному значению типа, который хранится в файле. Например, если в файле хранятся значения типа Double (8 байт), то размер блока может быть равен 8, 16, 24, 32 и т.д. Фрагмент исходного кода блочного чтения из такого файла выглядит так:

DoubleArray: array [0..255] of Double;

If OpenDlg.Execute then AssignFile(F, OpenDlg.FileName) else Exit;

BlockRead(F, DoubleArray, 32, Transfered);

ShowMessage(‘Считано ‘+IntToStr(Transfered)+’ блок(-а,-ов)’);

Как видно из примера, размер блока установлен в процедуре Reset и кратен размеру элемента массива DoubleArray, в который считываются данные. В переменную Transfered возвращается число считанных блоков. Если размер файла меньше заданного в процедуре BlockRead числа блоков, ошибка не возникает, а в переменную Transfered передается число реально считанных блоков.

Обратите внимание, что для процедуры BlockRead организовывать цикл для чтения нескольких блоков нет необходимости.


procedure BlockWrite(var f: File; var Buf; Count: Integer [; var AmtTransferred: Integer]);

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

Эта запись обеспечивает хранение характеристик файла при удачном поиске. Дата и время создания файла хранятся в формате MS-DOS, поэтому для получения этих параметров в формате TDateTime необходимо использовать функцию


function FileDateToDateTime(FileDate: Integer): TDateTime;

Обратное преобразование выполняет функция


function DateTimeToFileDate(DateTime: TDateTime): Integer;

Свойство Attr может содержать комбинацию следующих значений:

faReadOnly – только для чтения;

Для определения параметров файла используется оператор AND :


If SearchRec.Attr AND faReadOnly) > 0 then ShowMessage(‘
файл только для чтения’);

Непосредственно для поиска файлов используются функции FindFirst и FindNext .

function FindFirst(const Path: string; Attr: Integer; var F: TSearchRec): Integer;

находит первый файл, заданный полным маршрутом Path и параметрами Attr . Если заданный файл найден, функция возвращает 0, иначе – код ошибки. Параметры найденного файла возвращаются в записи F типа TSearchRec .

function FindNext(var F: TSearchRec): Integer;

используется для поиска файла. При этом используются параметры поиска, заданные последним вызовом функции FindFirst . В случае удачного поиска возвращается 0.

Для освобождения ресурсов, выделенных для выполнения поиска, применяется функция

procedure FindClose(var F: TSearchRec);

В качестве примера организации поиска файлов рассмотрим фрагмент исходного кода, в котором маршрут поиска файлов задается в однострочном текстовом редакторе DirEdit, а список найденных файлов передается в компонент TListBox.

FindFirst(DirEdit.Text, faArchive + faHidden, SearchRec);

While FindNext(SearchRec) = 0 do

Напоследок, как и обещал в прошлом номере, немного о создании дополнительных форм. Итак, для создания дополнительной формы необходимо воспользоваться пунктом меню New Form ( File/New Form ) или кнопкой New Form на панели инструментов. Перед Вами появится новая форма проекта с названием Form2 . При запуске программы эта форма не будет активизирована. Для ее запуска необходимо воспользоваться процедурой Show из кода исходной программы. Список существующих форм и возможность активизация форм проекта доступны при нажатии на кнопку ViewForm на панели инструментов или при нажатии на пункт Forms… ( View/Forms… ). Таким образом, необязательно загромождать экран бесконечными формами проекта, когда на данный момент из них необходима только одна. Достаточно закрыть ненужные формы, а при необходимости активизировать их при помощи диалога ViewForm .

Илон Маск рекомендует:  Лекции по конструированию компиляторов глава 9 системы автоматизации построения трансляторов
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL