2 Последовательные файлы

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

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

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

while (конец файла не достигнут) do

(получить следующую запись из файла и обработать ее)

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

Стандартная инфраструктура электронной почты (E-mail) в сети Интернет разработана для обработки традиционных ASCII-файлов и, таким образом, не совместима с другими форматами файлов, включая изображения, звуки и документы, обработанные текстовыми процессорами. Для передачи таких файлов по электронной почте их необходимо закодировать в формате текстового файла, передать и затем декодировать обратно в оригинальный формат. Для этой цели были созданы MIME (Multipurpose Internet Mail Extensions, многоцелевые расширения электронной почты в сети Интернет). Вкратце, MIME — это набор стандартов кодирования, при помощи которых определенные типы файлов (например, изображения в формате JPEG и GIF, видеофайлы MPEG, документы Microsoft Word) можно преобразовать в текстовые. Когда такой файл передается программе электронной почты с поддержкой MIME, он кодируется и помечается используемой системой кодирования, передается адресату и затем декодируется согласно метке документа. Сегодня возможности MIME встроены в большинство приложений для работы с электронной почтой.

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

Неотъемлемой частью процесса обработки последовательного файла является определение конца файла. В общем случае мы определяем конец последовательного файла как EOF (end-of-file, конец файла). Существует много способов распознавания ЕОF. Один из них — помещение специальной записи, называемой сигнальной меткой (sentinel), в конце файла. Конечно же, чтобы избежать недоразумений, поля сигнальной метки должны содержать значения, которые никогда не встречаются среди данных приложения. Используя эту технику, программа на языке программирования третьего поколения управляла бы обработкой последовательного файла при помощи подобных операторов:

Получить первую запись из файла;

while (полученная запись не является сигнальной меткой) do

(обработать запись и получить следующую запись из файла)

Рисунок 2 – Соблюдение порядка файла при помощи таблицы размещения файла

Консорциум производителей программного обеспечения для WWW (World Wide Web Consortium, W3C) был образован в 1994 году для продвижения WWW путем разработки стандартов протоколов. W3C был основателем XML. Проекты, которые в данный момент рассматриваются W3C, включают разработку стандартов для семантической сети, в которой (если говорить упрощенно) информация, хранящаяся в Интернете, связана по значению, а не по ключевым словам. Штаб-квартира W3C находится в CERN, лаборатории быстрых частиц в Женеве, Швейцария. В CERN был разработан первоначальный вариант языка разметки HTML, а также протокол HTTP для передачи HTML-документов через Интернет. Подробнее о W3C можно узнать на их веб-узле по адресу http://www.w3c.org.

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

while (не EOF) do

(получить запись из файла и обработать ее)

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

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

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

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

Листинг 1. Процедура слияния двух последовательных файлов

procedure MergeFiles (InputFileA. InputFileB, OutputFile)

if (достигнут EOF обоих файлов)

then (Stop, файл OutputFile пуст)

if (не EOF для InputFileA)

then (объявить его первую запись его текущей записью)

if (не EOF для InputFileB )

then (объявить его первую запись его текущей записью)

while (не достигнут EOF ни одного из файлов) do

(поместить текущую запись с «меньшим» значением ключевого

поля в OutputFile:

if (эта текущая запись является последней в соответствующем входном файле)

then (объявить, что этот входной файл достиг EOF)

else (объявить следующую запись в этой входном файле

текущей записью этого файла)

)

Начиная с текущей записи входного файла, не достигшего EOF, скопировать оставшиеся записи в OutputFile.

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

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

Такие соглашения существуют и в современных системах. В частности, в операционной системе UNIX предполагается, что конец строки обозначается только символом перевода строки, тогда как в системах, разработанных Apple Computer, Inc., используется только символ возврата каретки, а в операционных системах Microsoft необходимы оба символа — возврат каретки и перевод строки. В результате для передачи файлов из одной системы в другую необходимо выполнять преобразования. В этом состоит различие между текстовыми файлами и бинарными файлами при передаче их в Интернете по протоколу FTP (File Transfer Protocol, протокол передачи файлов). Во время использования FTP текстовый файл — это файл, для которого требуется такое преобразование, а бинарный файл передается без преобразования. В частности, файлы, которые созданы текстовыми процессорами, должны передаваться как бинарные, так как в этих файлах используются собственные средства кодирования текста.

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

Важно различать простые текстовые файлы, которыми манипулируют утилиты, называемые редакторами (editor), и более сложные файлы, которые создаются при помощи программ обработки текста или текстовых процессоров (word processors). Оба вида файлов содержат текстовый материал. Однако в текстовом файле содержится только посимвольно закодированный текст, а в файле, полученном при помощи текстового процессора, записаны различные внутренние коды, обозначающие разные шрифты, информацию о выравнивании текста и т. д. Более того, даже для представления текста в текстовых процессорах могут использоваться внутренние коды, а не стандартные, такие как ASCII или Unicode. Поэтому для просмотра и модификации файла, созданного программой обработки текста, требуется более сложное приложение, чем простой редактор, необходимый для работы с текстовым файлом.

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

Рисунок 4 – Структура простого файла сотрудников. Реализованного в виде текстового файла

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

Простота текстовых файлов привела к разработке способов кодирования нетекстового материала, например музыкальных произведений, в виде текстовых файлов. На первый взгляд система нотных станов, тактов и нот, при помощи которых обычно представляются музыкальные тексты, не соответствует посимвольному формату текстовых файлов. Но эту проблему можно решить, разработав альтернативную систему обозначений. Точнее, мы можем обозначать начало нотного стана как <staff clef = "treble">, конец стана как </staff>, знак размера при ключе в форме <time> 2/4 </time>, начало и конец такта как <measure> и </measure> соответственно, а ноты, например четвертную ноту С, как <notes> qtr С </notes> и т. д. Тогда текстом

<staff clef - "treble"> <key>C minor</key> <time> 2/4 </tirne>

<measure> <rest> qtr </rest> <notes> qtr G. qtr G. qtr G </notes></rneasure>

<measure> <notes> hif E </notes></measure>

</staff>

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

Рисунок 5 – Первые два такта пятой симфонии Бетховена

Обратите внимание, что наша система кодирования музыки выполнена в определенном стиле. Мы разделяем термины (называемые тегами), идентифицирующие компоненты, символами «<» и «>». Таким же образом мы обозначаем начало и конец структур (например, нотного стана, знаков при ключе, нот и тактов) — закрывающий тег отличается слэшем (то есть тег <measure> закрывается тегом </measure>). Внутри тегов мы тоже используем специальные атрибуты — выражения типа clef = "treble". Подобный стиль можно разработать и для представления других форматов, например математических выражений, медицинских диаграмм и целых веб-страниц.

Расширяемый язык разметки XML (extensible Markup Language) — это стандартизованный стиль (похожий на стиль в нашем музыкальном примере) для разработки систем обозначений и представления данных в виде текстовых файлов. (На самом деле XML — это упрощенный вариант более старого набора стандартов под названием Standard Generalized Markup Language, SGML.) Следуя стандартам XML, были разработаны системы обозначения, называемые языками разметки, для представления математических выражений (MathML), мультимедийных презентаций (SMIL), музыки (4ML) и веб-страниц (XHTML). (XHTML — это улучшенный вариант HTML, удовлетворяющий стандартам XML. Например, HTML предполагает, что начало нового параграфа, обозначаемое тегом <р>, завершает предыдущий параграф, но в XHTML перед началом нового параграфа необходимо явно завершать текущий параграф тегом <р>.)

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