Создание электронных книг в формате FictionBook 2.1: практическое руководство (beta 4)
Шрифт:
В отличие от всех не-XML форматов, которые ориентированы на хранение или оформление текстовых данных, в FictionBook упор сделан на структурирование документа. То есть с помощью тэгов выделяются области текста: это — глава, это — заголовок, это — эпиграф, а вот это — цитата. А как все «это» будет выглядеть на экране, зависит от программы-ридера. Впрочем, на случай, если потребуется оформить книгу строго определенным образом, предусмотрена возможность присоединения таблицы стилей.
Используя формат FictionBook можно создать четко структурированную книгу (именно книгу, а не просто электронный документ), которую удобно читать в специализированной программе-читалке, а в случае надобности можно легко сконвертировать в любой популярный формат. Как правило, без потери разметки.
Возможности FictionBook позволяют
Все компоненты книги (описание, непосредственно текст, иллюстрации) хранятся в одном файле, который можно упаковать архиватором. Большинство программ-читалок для FB2 умеют напрямую работать с архивами.
За прошедшие несколько лет стандарт уже успел устояться. Несмотря на то, что он включает сравнительно немного элементов, в него трудно добавить что-то действительно новое и полезное.
Еще одно достоинство FictionBook — книги в этом формате отлично поддаются каталогизации. Опираясь на встроенную систему описания книги, можно с легкостью создать как домашнюю, так и сетевую электронную библиотеку любого масштаба.
Учитывая объем электронных книг, накопленный до появления FictionBook, первый вопрос, который возникает при знакомстве с новым форматом — это возможность конвертирования книг из других форматов.
Никаких проблем. Разработанные авторами формата и энтузиастами программные средства позволяют эффективно конвертировать книги из форматов txt, HTML, RTF (doc).
Если же, наоборот, возникнет необходимость преобразовать книгу в формате FictionBook в другой формат, то «штатный» конвертор FB2Any неплохо справляется с преобразованием FB2 не только в классические txt и RTF, но и в специализированные форматы Roсket Book, iSilo, Micro$oft Reader. Еще не успел устояться новомодный формат для аппаратных читалок Wolf, как появились сразу несколько программ для конвертации книг fb2 в этот формат.
Таким образом, формат FictionBook обладает всеми качествами, чтобы стать единым стандартом для e-Book. И, фактически, уже стал им. Использование FB2 в русскоязычных онлайн-библиотеках, подтвердило его функциональность и жизнеспособность.
В нынешнем состоянии формат наиболее подходит для художественной литературы. Что совершенно не мешает использовать его для технических, методических, справочных изданий, а также для периодики.
После прочтения этого панегирика у читателя возникает справедливый вопрос:
Потому что развитие и, самое главное, продвижение формата целиком зависит от горстки энтузиастов.
Недосуг стало Михаилу Мацневу заниматься HaaliReader и FB Tools и все фактически замерло.
Впрочем, сейчас намечаются перемены к лучшему. Появляются новые программы для чтения, конверторы.
Второй причиной, пожалуй можно признать, необходимость ручного труда при подготовке книги. Автоматическая конвертация, позволяющей сделать качественную книгу просто невозможна. К тому же, до недавних пор, существующие программные средства для конвертации и редактирования особенным дружелюбием к пользователю не отличались.
В версию 2.1 формата было введено много новых и полезных элементов, как-то:
1. В заголовке появился новый необязательный раздел <src-title-info>, полностью идентичный по структуре <title-info>. Он используется в том случае, если книга переводная, и позволяет описать оригинал.
2. Четыре новых способа форматирования текста: <sub> (нижний индекс), <sup> (верхний индекс), <code>(преформатированный текст), <strikethrough> (зачеркнутый текст).
3. <text-author> теперь может содержать любое форматирование и ссылки, наравне с .
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.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
Выходной поток (закодированные байты) должен иметь длину строк не более 76 символов. Все признаки перевода строки и другие символы, отсутствующие в таблице 1, должны быть проигнорированы декодером base64. Среди данных в Base64 символы, не перечисленные в табл. 1, переводы строки и т.п. должны говорить об ошибке передачи данных, и, соответственно, почтовая программа должна оповестить пользователя о ней.
Если в хвосте потока кодируемых данных осталось меньше, чем 24 бита, справа добавляются нулевые биты до образования целого числа 6-битных групп. А до конца 24-битной группы остается от 0 до 3-х недостающих 6-битных групп, вместо каждой из которых ставится символ-заполнитель «=». Поскольку весь входной поток представляет собой целое число 8-битных групп (т.е., просто байтных значений), то возможны лишь следующие случаи:
(1) входной поток как раз оканчивается 24-битной группой. В таком случае, выходной поток будет оканчиваться четырьмя символами Base64 без символа «=»;
(2) хвост входного потока имеет длину 8 бит. Тогда в конце выходного кода быдут два символа Base64, с добавлением двух символов «=»;
(3) хвост входного потока имеет длину 16 бит. Тогда в конце выходного будут стоять три символа Base64 и один символ «=».
Т.к. символ «=» является хвостовым заполнителем, его появление в теле письма может означать только то, что конец данных достигнут. Но такой гарантии нет, если число переданных битов кратно 24.
Любые бессмысленные последовательности в коде Base64 вроде «=====» должны быть игнорированы.
Основано на:
Спецификация RFC 1521 «MIME — Multipurpose Internet Mail Extensions. Part one.»