Таким образом, формат FictionBook обладает всеми качествами, чтобы стать единым стандартом для e-Book. И, фактически, уже стал им. Использование FB2 в русскоязычных онлайн-библиотеках, подтвердило его функциональность и жизнеспособность.
В нынешнем состоянии формат наиболее подходит для художественной литературы. Что совершенно не мешает использовать его для технических, методических, справочных изданий, а также для периодики.
После прочтения этого панегирика у читателя возникает справедливый вопрос:
Потому что развитие и, самое главное, продвижение формата целиком зависит от горстки энтузиастов.
Недосуг стало Михаилу Мацневу заниматься HaaliReader и FB Tools и все фактически замерло.
Впрочем, сейчас намечаются перемены к лучшему. Появляются новые программы для чтения, конверторы.
Второй причиной, пожалуй можно признать, необходимость ручного труда при подготовке книги. Автоматическая конвертация, позволяющей сделать качественную книгу просто невозможна. К тому же, до недавних пор, существующие программные средства для конвертации и редактирования особенным дружелюбием к пользователю не отличались.
В версию 2.1 формата было введено много новых и полезных элементов, как-то:
1. В заголовке появился новый необязательный раздел <src-title-info>, полностью идентичный по структуре <title-info>. Он используется в том случае, если книга переводная, и позволяет описать оригинал.
2. Четыре новых способа форматирования текста: <sub> (нижний индекс), <sup> (верхний индекс), <code>(преформатированный текст), <strikethrough> (зачеркнутый текст).
3. <text-author> теперь может содержать любое форматирование и ссылки, наравне с <p>.
4. Добавлена схема управления конвертацией платных документов.
5. Переработан список жанров.
6. Добавлен новый элемент — таблицы!
7. Добавлены атрибуты title и id для <image/>, предназначенный для подписей к картинкам и ссылок на картинки соответственно. Inline картинки и картинки в <coverpage>, по прежнему, никаких id и подписей не имеют.
К несчастью, эти полезные новшества не были оперативно поддержаны софтом для чтения и редактирования.
Поэтому все нововведения оказались «сбоку припеку». Они не используются, и кое-кто из пользователей уже поговаривает, что неплохо бы их вообще убрать. Что, надеюсь, сделано не будет.
Отсюда напрашивается категорический вывод, что выпуск давно анонсированной версии формата 3.0 должен сопровождаться выходом обновленных версий стандартной читалки, и не менее стандартного редактора. И читалка, и редактор, должны корректно поддерживать все особенности формата и, кроме того, они должны быть совместимы по формату закладок. Последняя «фича» крайне важна для вычитки текстов. Также, в обязательном порядке, должен быть, опять же, стандартный, пакет скриптов для сетевых библиотек. Иначе все улучшения и нововведения просто теряют всякий смысл.
Часть II
Подробное описание формата FictionBook
§ 2.1 Структура файла FictionBook.
Базовые понятия
Книга FictionBook представляет собой XML-файл.
Структурно этот файл можно разделить на три части.
1) Desсription — заголовок (описание) книги;
2) Body — непосредственно текст книги. В книге может быть несколько body.
3) Binary — необязательная часть. Содержит бинарные файлы, в кодировке BASE64. [2.1] Как правило, это картинки.
§ 2.2 Пример книги в формате FictionBook
Cпецификация (schema) FictionBook находится на сайте Дмитрия Грибова, а также входит в комплект FB Tools. Поэтому размещать ее в электронной версии книги смысла нет.
Но пример книги в формате FictionBook привести необходимо:
<?xml version="1.0" encoding="windows-1251"?>
<FictionBook xmlns="http://www.gribuser.ru/xml/fictionbook/2.0" xmlns:l="http://www.w3.org/1999/xlink">
<description>
<title-info>
<genre>reference</genre>
<author>
<first-name>Имя автора</first-name>
<last-name>Фамилия автора</last-name>
<nickname>Юзич</nickname>
</author>
<book-title>Пример книги в формате FictionBook 2.1</book-title>
<annotation>
<p>Это пример книги в формате FictiionBook</p>
</annotation>
<date value="2006-04-14">14 апреля 2006 г.</date>
<lang>ru</lang>
</title-info>
<document-info>
<author>
<nickname>Юзич</nickname>
</author>
<program-used>FB Tools</program-used>
<date value="2006-04-14">2006-04-14</date>
<id>1E693E16-8A80-4391-9800-C1A91A5E29A7</id>
<version>1.0</version>
<history>
<p>v 1.0 — создание книги (Юзич)</p>
</history>
</document-info>
</description>
<body>
<title>
<p>Юзич</p>
<p>ПРИМЕР КНИГИ В ФОРМАТЕ FictionBook 2.1</p>
</title>
<epigraph>
<p>Это эпиграф</p>
<text-author>Автор эпиграфа</text-author>
</epigraph>
<section>
<title>
<p>Первая секция</p>
</title>
<p>Секции обычно содержат текст.</p>
2.1
Base64
Этот алгоритм был разработан для представления произвольных последовательностей байтов в форму, читаемую для человека. Кодирующий и декодирующий алгоритмы очень просты, но закодированные данные примерно на 33% больше, чем некодированные. Этот метод идентичен тому, который используется в приложениях PEM (Privacy Enhanced Mail), описанной в RFC 1421 с одним отличием: base64 не приемлет встроенного «чистого» текста.
Base64 использует 65-символьный поднабор из US-ASCII, выделяя 6 бит на каждый печатный символ. (65-й символ «=» используется для обозначения функции спец. обработки).
Этот поднабор имеет важное свойство: он идентичен всем версиям языковой кодировки ISO 646, включая US ASCII, а также всем версиям EBCDIC. Другие популярные механизмы кодирования (uuencode, base85 — часть уровня 2 PostScript) не разделяют этих свойств и поэтому не удовлетворяют требованиям переносимости для двоичных данных электронной почты.
Процесс кодирования преобразует 4 входных символа в виде 24-битной группы, обрабатывая их слева направо. Эти группы затем рассматриваются как 4 соединенные 6-битные группы, каждая из которых транслируется в одиночную цифру алфавита base64. При кодировании base64, входной поток байтов должен быть упорядочен старшими битами вперед.
Каждая 6-битная группа используется как индекс для массива 64-х печатных символов. Символ, на который указывает значение индекса, помещается в выходную строку. Эти символы выбраны так, чтобы быть универсально представимыми и исключают символы, имеющие специальное значение для SMTP-транспорта («.», CR, LF) и для синтаксиса вложенных тел MIME («-»).
Таблица: Алфавит Base64