Создание электронных книг в формате FictionBook 2.1: практическое руководство (pre-release)
Добавить в закладки К обложке
- Предуведомление - Страница 1
- Предисловие - Страница 2
- Введение - Страница 3
- Часть IФормат FictionBook и его место в мире электронной литературы - Страница 4
- § 1.2 Многообразие форматов электронных книг - Страница 5
- § 1.3 Несколько слов о XML - Страница 9
- § 1.4 Формат FictionBook — стандарт де-факто для электронных книг - Страница 10
- Часть IIПодробное описание формата FictionBook - Страница 13
- § 2.2 Пример книги в формате FictionBook - Страница 14
- § 2.3 Элементы описания книги.Базовые структурные элементы - Страница 16
- § 2.4 Элементы описания книги (description). Элементы первого уровня - Страница 18
- § 2.5 Элементы описания книги (description). Элементы второго уровня - Страница 20
- § 2.6 Элементы описания книги (description). Элементы третьего уровня (информация об авторе) - Страница 24
- § 2.7 Элементы тела книги (body). - Страница 25
- § 2.8 Элементы раздела книги (section).Элементы первого уровня. - Страница 26
- § 2.9 Элементы раздела книги (section).Элементы второго уровня. - Страница 28
- § 2.10 Элементы таблиц - Страница 29
- § 2.11 Элементы абзаца (стилевые, они же inline элементы) - Страница 30
- § 2.12 Элементы для платных книг - Страница 33
- § 2.13 Спецсимволы - Страница 34
- § 2.14 Список атрибутов элементов - Страница 35
- § 2.15 Алфавитный список всех элементов FictionBook 2.1 - Страница 37
- Часть IIIКонвертирование книг из других форматов - Страница 38
- § 3.1 Требования к исходному тексту - Страница 39
- § 3.2 Any to FB2 - Страница 40
- § 3.3 ExportXML - Страница 43
- § 3.4 doc2fb - Страница 44
- § 3.5 Перенос через буфер обмена - Страница 45
- § 3.6 Конвертор ExportToFB21 для Open Office - Страница 46
- § 3.7 Написание собственного конвертора - Страница 47
- Часть IVРедактирование книг. FB Editor - Страница 51
- § 4.1 Установка программы - Страница 52
- § 4.2 Описание функций и основные приемы работы - Страница 53
- § 4.3 Заполнение заголовка книги - Страница 55
- § 4.4 Структурирование документа - Страница 58
- § 4.5 Использование регулярных выражений - Страница 63
- § 4.6 Использование скриптов - Страница 64
- § 4.7 Баги с нами! - Страница 65
- § 4.8 Дальнейшее развитие редактора - Страница 66
- § 4.9 Альтернативные средства редактирования - Страница 67
- Часть VПрочие вопросы создания книг в формате FictionBook - Страница 69
- § 5.2 Подготовка картинок - Страница 71
- § 5.3 Обложки - Страница 73
- § 5.4 Сборник или по отдельности? - Страница 75
- § 5.5 Советы по вычитке книг - Страница 76
- § 5.6 Символы, которых нет на клавиатуре - Страница 78
- § 5.7 Высокое искусство аннотации - Страница 79
- § 5.8 Проблемы распространения - Страница 80
- Часть VIПросмотр и конвертирование книг в формате FictionBook - Страница 82
- § 6.1 Читалки - Страница 83
- § 6.2 Пакет FB2Any - Страница 85
- § 6.3 FB2GrWolf - Страница 87
- § 6.4 FB2PDF - Страница 88
- Часть VIIПрочее программное обеспечение для работы с FictionBook - Страница 90
- § 7.2 Утилита Booki - Страница 94
- § 7.3 Программа-библиотекарь JEFLibrarian - Страница 95
- § 7.4 Программа-библиотекарь MyHomeLib - Страница 96
- § 7.5 FB2Fix - Страница 97
- Заключение.Копирайт и доступность - Страница 101
- Благодарности - Страница 107
- Обратная связь - Страница 108
- Приложения - Страница 109
- Приложение БТехническое задание на написание читалки (ридера) - Страница 110
- Приложение ВСписок жанров FictionBook - Страница 111
- Приложение ГСписок возможных языков - Страница 113
- Приложение ДРегулярные выражения - Страница 114
- Приложение EОписание Base64 - Страница 117
- Приложение ЖОписание стандарта ISBN - Страница 118
- Приложение ЗПопытка анализа влияния «пиратов» на тиражи книг - Страница 120
- Приложение ИКопирайт и новая война луддитов - Страница 121
Приложение EОписание Base64
Этот алгоритм был разработан для представления произвольных последовательностей байтов в форму, читаемую для человека. Кодирующий и декодирующий алгоритмы очень просты, но закодированные данные примерно на 33% больше, чем некодированные. Этот метод идентичен тому, который используется в приложениях PEM (Privacy Enhanced Mail), описанной в RFC 1421 с одним отличием: base64 не приемлет встроенного «чистого» текста.
Base64 использует 65-символьный поднабор из US-ASCII, выделяя 6 бит на каждый печатный символ. (65-й символ «=» используется для обозначения функции спец. обработки).
Этот поднабор имеет важное свойство: он идентичен всем версиям языковой кодировки ISO 646, включая US ASCII, а также всем версиям EBCDIC. Другие популярные механизмы кодирования (uuencode, base85 — часть уровня 2 PostScript) не разделяют этих свойств и поэтому не удовлетворяют требованиям переносимости для двоичных данных электронной почты.
Процесс кодирования преобразует 3 входных символа в виде 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.»
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122