Какой формат сохранения файлов является основным

Обновлено: 06.01.2025

«Рекомендации по комплектованию, учету и организации хранения электронных архивных документов в архивах организаций», разработанные Росархивом/ВНИИДАД2, рекомендуют при подготовке электронных документов к передаче на хранение в архив организации производить их конвертацию в формат PDF/A-1, который далее называют форматом архивного хранения. Согласно рекомендациям контейнер электронного документа должен представлять собой сжатую zip-папку. Туда необходимо включить сам электронный документ в формате архивного хранения (PDF/A-1), а также метаданные документа (в формате XML), включая электронные подписи. При этом проверка наличия и состояния основных и рабочих экземпляров электронных документов проводится при приеме электронных документов в архив организации, потом через год после приема электронных документов на хранение в архив и далее с периодичностью один раз в три года.

Приказом Минкомсвязи РФ от 02.09.2011 № 221 были утверждены «Требованиями к информационным системам электронного документооборота федеральных органов исполнительной власти»3, в которых отмечалась необходимость обработки посредством данных систем не только общей служебной информации, но и информации ограниченного распространения. Согласно Требованиям, система электронного документооборота федерального органа исполнительной власти должна обеспечивать отображение следующих форматов файлов: PDF, RTF, DOC, TIFF.

Приказом Минкомсвязи России N 186 и ФСО России N 258 от 27.05.2015 были утверждены «Требования к организационно-техническому взаимодействию государственных органов и государственных организаций посредством обмена документами в электронном виде»4. Согласно этим требованиям, файл электронного документа, а также файл электронного образа документа с графическими элементами регистрационных данных и отметок об ЭП, внедренными в него, должен иметь формат PDF/A-1, соответствующий международному стандарту ISO 19005-1:2005.

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

Помимо нормативных документов министерств и ведомств, рекомендации по форматам хранения электронных документов содержатся и в национальных стандартах.

ГОСТ Р 54471-2011 «Системы электронного документооборота. Управление документацией. Информация, сохраняемая в электронном виде. Рекомендации по обеспечению достоверности и надежности»7 содержит описание рекомендуемой практики электронного хранения деловой и иной информации в электронной форме и описывает порядок внедрения и эксплуатации систем управления информацией и документами, которые могут рассматриваться как надежно (заслуживающим доверия образом) хранящие электронную информацию. В стандарте описаны средства, с помощью которых в любое время можно доказать, что содержание конкретного электронного объекта, созданного или существующего в компьютерной системе, не изменился с момента его создания внутри системы или с момента импорта. Стандарт рекомендует создавать отдельный документ, регламентирующий хранение информации в электронном виде, в том числе содержащий сведения о допустимых форматах файла, методах сжатия информации и сроках ее хранения. Стандарт определяет «доверенную систему» как систему, «которая позволяет рассматривать всю сохраняемую в ней в электронном виде информацию как достоверные и точные копии изначальной информации независимо от ее первоначального формата»8. Согласно стандарту электронная информация может храниться в двух формах: в виде графических образов либо в виде объектов данных. Чаще всего графические образы получаются в результате обработки бумажных документов (например, сканирование). Объекты данных используются для хранения информации в «первоначальном» формате, при этом для извлечения содержащейся в них информации может потребоваться оригинальное программное обеспечение. Однако стандарт дает весьма общие рекомендации по выбору формата хранения электронных документов, не называя их.

ГОСТ Р 54989-2012/ ISO / TR 18492:2005 «Обеспечение долговременной сохранности электронных документов»9 сосредотачивается на обеспечении сохранности ЭД. Согласно стандарту, долговременная сохранность это «период времени, в течение которого электронные документы поддерживаются в качестве доступного и аутентичного свидетельства (доказательства)»10. Нечитаемость документа может наступить вследствие порчи носителя или его морального устаревания. Чтобы документ не стал нечитаемым, нужно осуществлять периодический перенос информации с одних носителей на другие, более новые, а также правильно выбирать форматы хранения. Стратегия долговременной сохранности должна поддерживать те же характеристики документов, что и в стандарте ГОСТ Р ИСО 15489-1-2007, а кроме того, документ должен быть правильно интерпретируемым и идентифицируемым, причем обеспечение аутентичности считается ключевой задачей. Организации, стремящиеся обеспечить долговременный доступ к аутентичным документам, должны обратить внимание на следующие три ключевые аспекта своей стратегии: передача/прием на хранение и ответственное хранение; среда хранения; управление доступом и защита информации. Пока электронные документы находятся в среде их создания, их трудно защитить от изменений, поэтому нужно предусмотреть механизмы ограничения доступа к электронным документам и защиты их от порчи, случайного или умышленного искажения. При передаче на хранение может потребоваться переформатирование — миграция. При переформатировании стандарт рекомендует использовать механизм циклического избыточного кода CRC 11 (контрольных сумм CRC ) — распространенного метода обеспечения надежности электронной передачи данных или хэш-дайджестов12.

Стратегия долговременной сохранности должна решать проблему зависимости от конкретного программного обеспечения. Если конкретные электронные документы могут быть использованы только при помощи определенного программного приложения, то обеспечение долговременного доступа к этим документам может оказаться проблематичным. В стандарте обращено внимание на то, что после передачи электронных документов на хранение, следует думать об их миграции из широкого набора форматов, используемых создателями и получателями документов, в меньшее число «стандартизованных» форматов. Стандарт не рекомендует выбирать коммерческие (проприетарные) форматы. К числу заслуживающих внимания технологически нейтральных форматов, рекомендованных стандартом, относятся PDF / A -1, XML , TIFF и JPEG .

Выбор оптимального формата хранения определяется видом информации, характеристиками технических средств хранения, особенностями доступа к данным и используемым программным средствам. Вышеназванные форматы делятся на текстовые и графические форматы и могут использоваться для хранения электронных документов. Особняком стоит формат PDF / A , который был создан специально для долгосрочного хранения электронных документов. В соответствии с международным стандартом ISO 19005-1:2005/Cor.1:2007 «Управление документацией. Формат файлов электронных документов для долгосрочного хранения»13 различают специальную разновидность формата PDF — PDF-А (archives). Именно ему мы и уделим особое внимание.

В действительности PDF/A является подмножеством формата PDF, из которого исключены некоторые особенности, не подходящие для долговременного хранения электронных документов. Ключевой элемент воспроизводимости этого формата состоит в требовании, чтобы документы в формате PDF/A были на 100 % самодостаточными. Вся информация, которая необходима для того, чтобы документ каждый раз отображался в неизменном виде, должна быть внедрена в файл. Сюда входит (не ограничиваясь только этим) всё содержимое документа (текст, растровые изображения и векторная графика), шрифты и информация о цвете. Важно отметить, что документы форматов семейства PDF/A не могут использовать информацию из внешних источников (как то шрифтовые программы или гиперссылки), в них запрещено внедрение кода на java S cript14 и команд на запуск исполняемых файлов, также не разрешено шифрование15. Так как документ формата PDF/A должен включать все шрифты, которые он использует, файл PDF/A часто будет большего размера, чем его PDF-эквивалент, не содержащий внедрённых шрифтов. Это может быть нежелательно при хранении большого числа небольших документов, содержащих одни и те же шрифты, так как один и тот же шрифт будет внедрен в каждый из файлов. Однако при хранении большого числа небольших документов в одном архиве, из-за свойств алгоритмов сжатия, разница между использованием PDF с внедренными шрифтами и без них — незначительна.

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

Следует отметить, что в широком профессиональном сообществе часто не делают различий между форматами PDF / A -1, PDF / A -2 и PDF / A -3. Как правило, в различных методических рекомендациях указывается только PDF / A как рекомендуемый формат для осуществления долговременного хранения, но если обратить внимание на ссылки на стандарты, то можно отметить, что разработчики методических документов ссылаются на первый стандарт формата PDF / A -1. Рассмотрим все три формата подробнее.

Первая версия формата PDF / A -1 стандартизирована ISO 19005-1:2005, « Document management — Electronic document file format for long - term preservation — Part 1: Use of PDF 1.4 ( PDF / A -1)»17 и актуализирована в 2015 году.

Стандарт PDF/A — 1 определяет два уровня соответствия для PDF-файлов:

• PDF/A-1a — соответствие Уровню A,

• PDF/A-1b — соответствие Уровню B.

РPDF/A-1b ставит целью обеспечение надёжного воспроизведения внешнего вида документа. PDF/A-1a включает все требования стандарта PDF/A-1b, а также дополнительно требует, чтобы структура документа была включена в файл, ставя при этом целью обеспечение возможности поиска и преобразования содержимого документа.

Таким образом, стандарт PDF/A-1 определяет два уровня соответствия: уровень соответствия «а» удовлетворяет всем требованиям спецификации; уровень « b » является более низким уровнем соответствия, «охватывающим требования этой части ISO 19005 относительно визуального появления электронных документов, но не их структурных или семантических свойств»18.

Формат PDF/A-2 был стандартизирован ISO 19005-2:2011 «Document management ― Electronic document file format for long-term preservation — Part 2: Use of ISO 32000-1 (PDF/A-2)» 19 и актуализирован в 2016 году . Особенностью формата является его ориентация на PDF 1.7, используемого для длительного хранения информации, представленной визуально в виде страниц.

Стандарт PDF/A-2 определяет три уровня соответствия: уровень соответствия « a » удовлетворяет всем требованиям спецификации; уровень «b» является более низким уровнем соответствия, «охватывающим требования этой части ISO 19005 относительно визуального появления электронных документов, но не их структурных или семантических свойств»20. Для PDF/A-2 был введен промежуточный уровень соответствия — уровень « u », который представляет соответствие уровня « b » с дополнительным требованием, заключающимся в том, чтобы весь текст в документе имел эквиваленты Unicode21.

Основное различие между PDF/A-1 и PDF/A-2 заключалось в использовании более поздней версии PDF. Добавленные возможности соответствуют требованиям ISO 32000-122 и включают:

- улучшения базового формата PDF (повышение его доступности),

- сжатый объект и потоки XRef23, (для меньших размеров файлов),

- поддержку встраивания вложенных файлов в формате PDF/A, переносимых коллекций и пакетов PDF,

- поддержку прозрачности изображений,

- поддержку сжатия JPEG 2000 для изображений24.

Формат PDF/A-3 стандартизирован ISO 19005-3:2012 «Document management — Electronic document file format for long-term preservation — Part 3: Use of ISO 32000-1 with support for embedded files» 25 и актуализирован в 2018 году .

PDF/A-3 добавляет единственную и очень важную функцию к предшественнику PDF/A-2. Если PDF/A-2 допускал вложение других файлов, пока вложенные файлы были действительными файлами PDF/A, то PDF/A-3 позволяет встраивать файлы любого формата (включая XML, CSV, CAD, изображения, бинарные исполняемые файлы и т. д.) в единый файл PDF/A. Эта новая функция предназначена для расширения функциональности PDF/A от формата зафиксированного «бумажного документа» (пусть и подходящего для использования в долгосрочной перспективе) до полноценного архивного формата, ориентированного на хранение электронного документа в неизменном виде, который может иметь и поддерживать связанные с ним файлы и электронную подпись.

Как и в PDF/A-2, стандарт PDF/A-3 определяет три уровня соответствия: уровень соответствия «a» удовлетворяет всем требованиям стандарта; уровень «b» является более низким уровнем соответствия, удовлетворяющим требованиям, которые должны быть минимально необходимы для обеспечения того, чтобы визуальный внешний вид соответствующего файла сохранялся в течение длительного времени. При этом в стандарте отмечается, что файлы, соответствующие стандартам уровня «b», могут не иметь «достаточно богатой внутренней информации, чтобы обеспечить сохранение логической структуры документа и текстового контента в естественном порядке чтения»26, что обеспечивается соответствием более высокому уровню «a». Промежуточный уровень соответствия, уровень «u» способен соответствовать всем дополнительным требованиям.

PDF/A-3 позволяет встраивать файлы любого типа, но накладывает требования, отличные от обычных, определенных в ISO 32000-127 для PDF 1.7. Согласно положениям стандарта файлы, соответствующие этим требованиям, называются «связанными» файлами. Для их создания и поддержания должна быть сделана явная связь между каждым встроенным файлом, содержащим PDF-документ, объектом или его структурой (например, изображение, страница или логический раздел) в PDF-файле. Для связанных файлов должны быть предусмотрены типы MIME28. Однако PDF/A-3 требует использования специальных приложений, если тип MIME неизвестен.

Существует мнение специалистов, что версия формата PDF/A-3 не направлена на расширение формата PDF/A-2 с целью поддержки встраивания файлов любого типа. В этом контексте интересны материалы вебинара от вендора Luratech, который занимается созданием программных продуктов и решений для преобразования документов с оптическим распознаванием символов, а также программного обеспечения для поставщиков услуг сканирования и долгосрочного архивирования в формате PDF/A-329. По мнению ведущего вебинара, в файле PDF/A-3 встроенные файлы не должны считаться «архивируемыми». Другими словами, источник или дополнительный материал рассматриваются только как краткосрочные или временные. То, что в долгосрочной перспективе должно рассматриваться как «архивированное», является только основным контентом PDF с его видимым отображением страницы. Отсюда вытекает утверждение, что PDF/A-3 обеспечивает «гибридное архивирование», т. е. каждая ревизия документа сопровождается хранением файла PDF/A-3 с встроенным исходным файлом обработки текста, а сам документ должен быть готов к архивированию при каждом прекращении редактирования, т. е. архивироваться перманентно.

Члены рабочей группы NDSA ( National Digital Stewardship Alliance ) в статье «New NDSA Report: The Benefits and Risks of the PDF/A-3 File Format for Archival Institutions» пришли к выводу, что формат PDF/A-3 служит «важным бизнес-потребностям, не связанным с сохранением документов в долгосрочной перспективе»30. Согласно статье юридическое лицо, такое как корпорация, обязано «архивировать определенные категории документов на определенный период для исполнения правительственных распоряжений»31. Эти документы начинают жизнь в редактируемой форме и на определенном этапе считаются окончательными, если промежуточные черновики сохраняются как PDF/A-3 с внедренной встраиваемой формой. При этом документ архивируется на любом этапе, упрощая управление документами. Эти бизнес-потребности стимулируют разработку инструментов для создания файлов PDF/A-3. Некоторые из них, безусловно, будут использованы в архивах. Согласно мнению авторов статьи: «сложность формата PDF свидетельствует о том, что PDF/A-3 может быть наиболее подходящим для использования в контролируемых рабочих процессах, но не может быть подходящим выбором в качестве формата долгосрочного хранения общего назначения»32. Тем не менее, предлагаемое PDF Association33 создание бесплатного инструмента для проверки PDF с открытым исходным кодом может снизить риски долгосрочного сохранения, связанные со сложностью формата PDF/A в качестве формата связывания.

На наш взгляд, отсутствие таких надежных инструментов проверки, конвертация PDF-файлов в PDF/A-3 в рабочих процессах оперативного документооборота оправдано, но является довольно ненадежным методом долгосрочного хранения документов. Для того чтобы детально разобраться в этом вопросе, необходимо провести специальное исследование, не менее значимое, чем проведенное экспертами РГГУ в 2013 году. Научный доклад РГГУ «Сравнительный анализ форматов файлов электронных документов постоянного (долговременного) хранения» установил, что PDF/A-1 (ISO 19005-1) и PDF/A-2 (ISO19005-2:2011) обладают высокой степенью надежности и обеспечивают долгосрочность хранения информации34.

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

В нижерасположенной таблице приведено сравнение форматов семейства PDF/A.

Сравнительная таблица форматов семейства PDF / A

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

Формат файла

Документ Word (DOCX).

Используемый по умолчанию XML-формат документов Word 2008 для Mac, Word для Mac 2011, Word 2016 для Windows, Word 2007 для Windows, Word 2010 для Windows, Word 2013 для Windows и Word 2016 для Windows.

Документ Word 97–2004 (DOC)

Формат документов, совместимый с версиями от Word 98 до Word 2004 для Mac и от Word 97 до Word 2003 для Windows.

Шаблон Word (DOTX).

Сохранение документа в виде XML-шаблона, на базе которого можно создавать новые документы. Сохранение содержимого документа и его параметров, в том числе стилей, разметки страниц, элементов автотекста, пользовательских сочетаний клавиш и меню.

Шаблон Word 97–2004 (DOT)

Сохранение документа в виде шаблона, на основе которого можно создавать новые документы. Сохранение содержимого документа и его параметров, в том числе стилей, разметки страниц, элементов автотекста, пользовательских сочетаний клавиш и меню. Совместим с версиями Word 97–2003 для Windows и Word 98–2004 для Mac.

Экспорт содержимого и форматирования документа в формате, распознаваемом и читаемом другими приложениями, включая совместимые программы Майкрософт.

Обычный текст (TXT)

Экспорт содержимого документа в текстовый файл и сохранение текста без форматирования. Этот формат следует выбирать лишь в том случае, если целевая программа не способна читать файлы других доступных форматов. В этом формате используется расширенный набор символов ASCII для Mac.

Сохранение документа в формате, предназначенном для просмотра в Интернете. HTML — это стандартный веб-формат, который отображается в браузерах Macintosh и Windows.

Экспорт документа в PDF-файл, который выглядит одинаково на компьютерах Macintosh и Windows.

Документ Word с поддержкой макросов (DOCM)

Формат документов на основе XML, в котором сохраняется код макросов VBA. Макросы VBA выполняются в Word 2016 для Mac и Word для Mac 2011, но не в Word 2008.

Шаблон Word с поддержкой макросов (DOTM)

Сохранение документа в виде XML-шаблона с кодом макросов VBA. Макросы VBA выполняются в Word 2016 для Mac и Word для Mac 2011, но не в Word 2008.

XML-документ Word (XML)

Экспорт содержимого документа в XML-файл. Преобразование всех инструкций форматирования и текста в формат XML. Совместим с Word 2007 для Windows.

XML-документ Word 2003 (XML)

Экспорт содержимого документа в XML-файл. Преобразование всех инструкций форматирования и текста в формат XML. Совместим с Word 2003 для Windows.

Веб-страница в одном файле (MHT)

Сохранение документа в формате, предназначенном для просмотра в Интернете, с созданием единого файла со всеми элементами страницы, такими как графические объекты. Используется интернет-стандарт MIME HTML.

Шаблон документа Word (DOC)

Сохранение документа с пометкой "Шаблон" для системы поиска. При открытии такого файла будет открываться новый документ без названия.

Настраиваемый словарь (DIC)

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

Словарь исключений (DIC)

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

Совместимый с Word 4.0–6.0/95 (RTF)

Этот формат RTF совместим с версиями от Word 4.0 до Word 6.0 для Mac, а также с Word 6.0 и Word 95 для Windows.

Тема Office (THMX)

Сохранение шрифта, цветовой схемы и фона файла для использования в качестве новой темы.

Чтобы применить к документу тему из другого документа, на вкладке Главная в разделе Темы выберите команду Обзор тем. Чтобы сохранить измененную тему как новую, на вкладке Главная в разделе Темы выберите команду Сохранить тему.

Таких программ на самом деле немало. Это AutoCAD, Photoshop, Microsoft Office (будем честными: даже пытаясь протащить его через ISO, «мелкомягкие» рассчитывали, что он будет совместим в первую очередь с самим собой).

И для простоты добавим ещё одно требование, которое отбросит все три этих программы, но довольно реалистичное (ему отвечают Windows 10 и куча программ помельче).

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

Я долго искал программу, которая отвечает всем этим требованиям, и наконец нашёл: Inkscape. Несмотря на то, что её файлы основаны на стандарте SVG, половина всей информации лежит в расширениях SVG — пространствах имён «sodipodi» и «inkscape».

В первой части постараюсь обойтись без программирования, зато объясню парочку важных концепций.

Собственно, у нас есть такие возможные форматы для хранения информации.

Формат первый. XML

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

[+] Много стандартного инструментария.
[+] Оптимальный выбор, если мы храним размеченный текст.
[±] Можно (хотя и тяжело) редактировать файл вручную.
[−] Разбор может занимать много времени — от 20 до 95% всего времени загрузки. Эту неоптимальность даже обозвали «налогом на угловые скобки». По опыту загрузки (не полной) XLSX собственными силами: раззиповка — 0,3 с, разбор XML — 1,1 с, остальное — 0,6 с.
[−] Программировать своими силами очень опасно, возможны незаметные ошибки.
[−] Зачастую избыточен.
[−] Если в программе есть огромные массивы из малюсеньких объектов (звуковые волны, картинки, матрицы чисел), их приходится сохранять не-XML’ными мерами. Посмотрите, например, как хранятся кривые в SVG:

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

Каким образом? Я знаю четыре подхода к чтению XML: на callback’ах (SAX), на потоках (StAX), на сопрограммах и DOM. А также два подхода к записи XML: прямая запись тэг за тэгом и DOM.

Чтение на callback’ах даёт сложный и путаный код, напоминающий конечный автомат. DOM расходует памяти в разы больше, чем структура предметной области. Сопрограммы — сложное дело и есть не везде. Так что наш выбор — чтение на потоках, запись тэг за тэгом. В обоих случаях расходуется пренебрежимо мало памяти, так что автоматически выполняется моё обещание не грузить громадину.

На языках, где мы управляем памятью вручную (Си), у потокового парсера есть ещё одна полезная черта. Управление памятью действует как унитазный бачок — потихоньку заполняется, мгновенно сливается — потому в самых быстрых из них действует собственное управление памятью. К сожалению, не получается добиться столь впечатляющей скорости, как в DOM (прежде чем выйти из функции getThing, надо «подобрать концы»). Так что у меня лично получилось (на Си++) сделать потоковый парсер в 2,5 раза медленнее, чем у рекордсмена PugiXML. Но это уже замечательный результат: научился грузить огромный XLSX втрое быстрее, чем Excel.

Формат второй. XML-лайты

«XML-лайтами» я называю языки наподобие XML, в которых единицы смысла — это строки текстового файла (иногда также агрегаты из нескольких строк). Наиболее известный — YAML.

Много лет назад, не накопав хорошего XML-инструментария для Delphi, за полдня я придумал XML-лайт с тупым названием Multilevel. Правда, тогда по неопытности работал только с DOM-разбором.

[+] Достаточно быстры.
[+] Редактируются вручную.
[±] Думаю, можно подобрать подходящий формат для огромных массивов из малюсеньких объектов.
[±] Легко запрограммировать своими силами.
[−] Даже если формат известный, вроде YAML, велика вероятность, что найдутся только DOM-подобные механизмы.
[−] Малопригодны для размеченного текста (и то придётся специально продумывать подходящий формат).

Формат третий. Двоичные XML-подобные коды

XML — формат текстовый. Но ничего не стоит перевести его в двоичный вид. Вот наобум придуманный XML-подобный двоичный формат (порядок байтов для наглядности взят Motorola):

На XML бы это выглядело так.

Я не открываю Америку, формат BIFF из Microsoft Office существует лет тридцать. Компания облажалась в двух местах: 1) Формат не иерархический, что сильно мешает дробить блоки; 2) блок ограничен 64 килобайтами, что решается вторым, третьим и т.д. блоком CONTINUE.

Недавно для целей медиаконтейнера Matroška сделали язык EBML — тот же XML, но двоичный. Конкретно с ним не знаком.

[+] Крайне быстры.
[+] Тэги, скорее всего, будут достаточно коротки, чтобы размеченный текст отнял даже меньше места в файле, чем в памяти.
[±] Легко запрограммировать своими силами.
[±] Огромные массивы из малюсеньких объектов можно сохранять как есть, в двоичном виде.
[−] Ручному редактированию не подлежат, для отладки потребуется программа-дампер.

Прочие форматы (и их недостатки)

Эти форматы лучше даже не рассматривать.

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

UPD. Чем плоха рефлексия? Костылями при серьёзных изменениях структуры файла.

SQLite продвигает свой формат БД как формат документа. По-моему, из-за сложностей программирования с ним имеет смысл работать именно как с СУБД.

JSON несколько проще в программировании, чем XML, но всё равно сложен. Плюс затруднено потоковое считывание: JSON различает объекты и массивы, и синтаксис JS говорит, что от перестановки атрибутов результат не меняется.

Хотя JSON подсказывает нам одну важную идею. А именно…

Идея 1. Или последовательность, или коллекция

Нашу жизнь очень сильно упростят два важных требования.

Любой тэг должен быть или последовательностью тэгов/блоков, или коллекцией тэгов/блоков. Объясню, что это такое.

Последовательность — это когда каждый сын повторяется не более одного раза и знает своё место. При этом возможны необязательные или взаимоисключающие.
- В терминах регулярных выражений — что угодно без дублей и операции «повторить». Например, AB [C] (D | [E]F) G .
- Неизвестные тэги, замеченные в последовательности, пропускаются.
- Пример: тэг <html>будет последовательностью из <head> и <body> .
- Неизвестные тэги, замеченные в коллекции, пропускаются или вызывают ошибку по желанию программиста.
- Пример: тэг <body>будет коллекцией из (почти) всех возможных тэгов HTML. Тэг <tr> содержит только <td> и <th> .
Примечание. Я понимаю, что в HTML оба этих тэга, td и th, можно использовать как непарные, браузер разберётся. Но давайте будем считать, что имеем дело с XHTML и эти тэги парные.

А вот совершенно не подходит под нашу модель тэг table . В официальной документации он описан как [caption], [title], [summary], ( col* | colgroup* ), (( [thead], [tfoot], tbody+ ) | ( tr+ )) — не похоже ни на коллекцию, ни на последовательность. Я понимаю разработчиков: HTML-то пишется в первую очередь руками. Но в машиночитаемом формате лучше так не делать.

Делая коллекцию дочкой коллекции, надо чётко осознавать риски. Тэг table в одном из вариантов будет коллекцией тэгов tr . А он, в свою очередь, коллекция из td и th . Если вдруг, случись что, в tr появится какой-нибудь тэг tx , с большой вероятностью оборвётся совместимость.

Как бы мы переписали нашу несчастную таблицу под машинное сохранение?

Но при этом мы чётко понимаем, что внутри коллекции tbody находится коллекция tr. Но таблица — она двухмерная, и крайне мала вероятность, что внутри tr вставят что-то не являющееся клеткой таблицы — так что закрываем на это глаза.

А вот в нашем простом иерархически-двоичном формате так нельзя. Причина в том, что у тэга XML есть атрибуты, куда, если что, можно закинуть немножко информации. А у каталога двоичного формата нет ничего — потому в этот самый tr не впишешь никаких новых данных: ни стиля, ни соответствия электронного документа и бумажного источника… Потому приходится полностью исключать коллекции в коллекциях.

Выносите отдельные сущности, особенно необязательные, в тэг-контейнер. Заголовок к таблице можно описать двумя способами:

Второй лучше — больше места для расширения. Может, вы когда-нибудь станете оформлять части заголовка жирным и курсивом. А может, будут два заголовка (например, в начале таблицы и в продолжении, если её разорвало на две страницы). Кто знает?

Впрочем, <table /> вполне себе катит: ссылка на стиль — свойство, заголовок, висящий где-то на мониторе — сущность.

Идея 2. Extend, upgrade, break. Или расширить, модернизировать, порвать

Какую бы мы ни придумали конструкцию — когда-нибудь мы из неё вырастем. Пусть у нас редактор простейших уровней, например, для Super Mario. Изначально там был один «мир» (скажем, лес). Делаем так, чтобы были два, три и больше миров. Как это будет выглядеть в XML?

Новую программу можно научить открывать старый формат. Но старая программа не откроет нового. И тогда я предлагаю трёхстадийный «мягкий переход». Сколько длится каждая из стадий — зависит от того, насколько сложен формат, как вы заставляете пользователей обновлять программу и как вы готовы тестировать её на проектах старых версий.

(название намеренно сделано похожим на Microsoft’овское Embrace/Extend/Extinguish, да и суть та же).

Расширить: программа пишет старый формат, если в игре один мир, и в новый, если много.

Примерно через полгода-год происходит фаза Модернизировать: программа начинает писать только новый формат, всё ещё читая оба.

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

Идея 3. Работая с текстовыми файлами, используйте нейтральную локаль

«Странно», — подумал я, но девочка из ПФР оставила ман в сто страниц А4. Решив начать по-хорошему, я сел и стал его вдумчиво курить. Где-то на 40-й странице я наткнулся на указание сменить стандартный разделитель целой и дробной частей в винде на запятую, иначе программа не будет работать. Открыл, смотрю — ага, всё верно. Сменил на точку — программа ФОМС заработала, но перестала работать программа ПФР, выдавая всю ту же ошибку сохранения данных. Теперь пожилая женщина-кадровик обучена переключать разделитель, а я проникся небывалой нежностью к отечественным программистам.

Идея 4. Как синхронизировать версии программы у сотрудников, работающих над одним документом

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

Цифру partlyCompatibleWith поднимаем до текущей, когда делаем extend или break в чём-то важном. Можно её устанавливать умно в зависимости от того, сохраняли мы в старом формате или нет. Цифру fullyCompatibleWith поднимаем, когда добавляем любой тэг.

Если файл загружен программой версии меньше 25, вывести: «Настоятельно рекомендуем обновить программу. Есть вероятность, что важные данные потеряны».

Если файл загружен программой версии меньше 40, вывести: «Рекомендуем обновить программу. Есть вероятность, что какие-то данные потеряны.»

Если файл загружен какой-то очень новой программой, чей partlyCompatibleWith больше 42, тоже можно что-то вывести.

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

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

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

Сохранение документов

В большинстве компьютерных программ файлы можно сохранять с помощью горячих клавиш Ctrl+S, или Command+S для Apple. А также, нажав на кнопку со значком дискеты, которая выглядит примерно, как на изображении ниже.

В программах Microsoft Office, таких как Word, Excel и других, документы сохраняются сочетанием клавиш Shift+F12.

Также в большинстве программ, сохранить документ можно с помощью меню «Файл/Сохранить» или «Сохранить как».

Как выбрать формат для сохранения файла

Чтобы сохранить файл в определенном формате, нужно в меню программы выбрать «Файл/Сохранить как». А затем в блоке «Тип файла» выбрать нужный формат. Ниже показан пример из MS Word.

Как работает сохранение документов и файлов

Когда вы создаете новый документ, поработав с ним сохраните его обычным способом, или с помощью меню «Файл/Сохранить как». Затем выбираете место хранения и имя файла.

При дальнейшей работе с документом, будет достаточно просто сохранять его по окончанию работы. Файл будет перезаписываться. А если нажать «Сохранить как», то можно создать новую копию документа с другим названием, и сохранить его в другое место.

Недопустимые имена файлов

В операционной системе Windows есть некоторые символы, которые нельзя использовать в названиях файлов и папок, а именно:

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

Читайте также: