Сохранение внешнего оформления (форматирования) текста.

Выделяют два основных способа форматирования текста: физическую и логическую разметку. Физическая разметка предполагает встраивание в текст кодов разметки (как правило, в двоичном формате, не совпадающем с 8-битовыми кодами ASCII, хотя возможно и символьное представление разметки). Коды разметки задают конкретные параметры шрифтов, величину отступов и междустрочных интервалов, дополнительные пробелы при выравнивании строк и т. п. Логическая разметка означает, что указываются не конкретные виды и размеры шрифтов, выделений, отступов и т. п., а логическое значение каждого фрагмента: «заголовок документа», «заголовок раздела», «абзац», «примечание» и т. д. Каждый такой фрагмент предваряется или обрамляется специальными маркерами – операторами разметки в символьной форме. Многие форматы сочетают возможности физической и логической разметки.

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

§ хранение данных в символьном формате;

§ хранение данных в графическом формате;

§ хранение данных в выходном формате.

В случае, когда решающим фактором является справочная ценность ЭД, т. е. предполагается активно работать с ним – вести поиск внутри текста, вставлять фрагменты из него в новые документы и т. п., - оптимальным является хранение в символьном формате с сохранением физической разметки. Наиболее предпочтительным в сегодняшних условиях представляется формат RTF (Rich Text Format), разработанный фирмой Microsoft и предназначенный для обмена данными между приложениями операционной системы Windows.

Для воспроизведения текста, сохраненного в формате RTF, потребуется текстовый редактор, способный конвертировать его в собственный внутренний формат, т. е. данный формат является в определенной степени программно-зависимым. Тем ни менее он может эффективно применяться при временном (порядка нескольких лет) хранении текста. Немаловажно, что конвертор формата RTF встроен в редактор Microsoft Word, являющийся на сегодня самым распространенным текстовым редактором в мире. Учитывая повсеместность операционной системы Windows, в которой Word является основным способом работы с текстом, можно не опасаться его отмирания в ближайшие годы. К тому же более поздние версии этого редактора позволяют открыть документ, созданный ранними версиями (но не наоборот). При дальнейшем развитии программного обеспечения фирмы Microsoft эта преемственность наверняка будет сохраняться. Преимуществами формата RTF перед собственным форматом Word является то, что его использование существенно уменьшает размеры файла и он более устойчив к разрушению,так как исключает возможность встраивания в документ макровирусов.

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

Данный способ хранения предполагает наличие в организации определенных аппаратно-программных средств, осуществляющих преобразование текста в изображение (сканера, графического редактора). При отсутствии таких средств может быть рекомендован промежуточный вариант - хранение в выходном формате. В настоящее время сформировались общие принципы управления устройствами вывода, что дает возможность хранения данных в формате, независимом от типа компьютера, операционной системы или марки принтера. Текст, подготовленный к выводу на печать, может быть сохранен в таком виде на машинном носителе. Этот способ сохранения стал возможным после появления в 1984 г. языка программирования PostScript, разработанного фирмой Adobe Systems. Поскольку на печать выводится уже полностью отформатированный документ, он приобретает жестко заданную физическую разметку и подлежит только воспроизведению, но не редактированию. Таким образом, полностью сохраняется внешний облик документа, а возможности его использования (кроме просмотра) сильно ограничиваются. Правда, при обеспечении доказательной ценности ЭД следует учитывать, что текст в формате PostScript представляет собой набор символьных кодов и в принципе может быть изменен. Поэтому использование данного формата не отменяет необходимость мероприятий по защите информации.

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

В 1992 г. фирма Adobe Systems разработана на базе формата PostScript новый формат, претендующий на роль универсального средства обмена – PDF (Portable Document Format). Документ, преобразованный в данный формат, предназначен не для печати, а для отображения практически в неизменном виде разными программами просмотра, включая распространенные Интернет-браузеры. Это придает ему платформенную независимость (документ, созданный в операционной системе Windows, может быть воспроизведен на компьютере в среде UNIX или другой, и наоборот). Важным преимуществом является также совместимость с Интернет-технологиями, широкая распространенность которых в известной мере гарантирует, что в нужный момент удастся найти средство для просмотра.

Недостатком формата PDF представляется программная зависимость (для конвертации в него требуется программное обеспечение, собственником которого является фирма Adobe Systems). К тому же этот формат, несмотря на широкое распространение в Интернете, не стал пока общепризнанным стандартом. Жизнеспособность его и перспективность для архивного хранения, очевидно, можно будет оценить только по прошествии нескольких лет.

 

 

Сохранение гипертекста.

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

Наиболее развитым средством подготовки гипертекстовых электронных документов является язык описания документов Hyper-Text Markup Language (HTML) - относительно новый стандарт, основанный на языке логической разметки SGML (Standard Generic Markup Language), в 1986 г. получившем статус международного стандарта ISO. Язык HTML рассчитан на использование программами просмотра (браузерами) службы World-Wide Web (WWW) в сети Интернет, благодаря чему он получил очень широкое распространение по всему миру. Файлы в формате HTML читаются распространенными текстовыми редакторами, включая Word. Кроме того, операционная система Windows 98 основана на полной интеграции браузера Internet Explorer в свою среду. Поэтому доступность и воспроизводимость документов HTML в ближайшей перспективе не вызывает опасений. Но следует учитывать, что логическая разметка HTML не позволяет строго задавать внешний вид ЭД. Создатель документа лишь предлагает свой вариант оформления, а различные программы просмотра могут интерпретировать его по-своему.

Стандарт HTML постоянно развивается, поэтому не все возможности его различных версий взаимосовместимы. При создании гипертекстовых ЭД, предназначенных для архивного хранения, рекомендуется использовать только базовые возможности языка, которые едины во всех версиях и одинаково воспринимаются основными браузерами (HTML 2.0). При подготовке документа HTML к архивному хранению все внешние ссылки (IP-адреса) должны быть преобразованы в локальные ссылки.

 

Электронные таблицы

Электронные таблицы (spreadsheets) создаются специальными программами, наиболее распространенными среди них являются Lotus и Excel. В отличие от текстовых редакторов, эти программы позволяют задавать отношения между ячейками таблицы. При изменении значений ячеек-атрибутов значение ячеек-функций автоматически изменяется. Современные текстовые редакторы (в частности, Word) позволяют либо импортировать содержимое электронной таблицы через буфер обмена, конвертируя его при этом в собственный формат, либо хранить таблицу в отдельном файле и в исходном формате, устанавливая в соответствующем месте текста ссылку на нее. При отображении документа на экране или выводе на печать автоматически загружается соответствующая программа, открывающая нужный файл.

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

 

 

Базы данных

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

§ хранение базы данных вместе с исходным программным обеспечением;

§ хранение содержания базы в фиксированном текстовом формате;

§ периодическая конвертация базы для новых поколений СУБД с воссозданием поисковых средств на базе исходного алгоритма.

 

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

Второй вариант является менее програмно-зависимым. Например, файлы DBF-формата, создаваемые с помощью СУБД класса dBASE, могут быть преобразованы в текстовые файлы с помощью параметра SDF (System Data Format) команд СУБД, изначально предназначенного для организации обмена данными с другими СУБД, программами LOTUS 1-2-3, Word и т.д.. В результате создается файл в фиксированном формате, который является разновидностью формата ASCII и содержит логические записи фиксированной длины, состоящие из полей фиксированной длины.

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

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

 

Графика