Построение образовательного портала «Юридическая Россия

В. Ю. Григорьев, Р. В. Павлов, А. В. Устинов
Построение
образовательного портала
«Юридическая Россия»
на основе технологии Joker
●
Аннотация
В докладе подробно рассмотрена архитектура постро
ения федерального образовательного портала по юриди
ческим наукам «Юридическая Россия» (http://law.edu.ru),
созданного и развиваемого СанктПетербургским государ
ственным университетом и являющегося составной частью
системы образовательных порталов, строящейся в рамках
Федеральной целевой программы «Развитие единой обра
зовательной информационной среды (2001—2005 годы)».
Показано развитие и преемственность технологиче
ских решений создания портала по отношению к системе
Joker, выступающей ядром информационнобиблиотечного
комплекса, удостоенного премии Президента Российской
Федерации в области образования.
Объясняются основные особенности Joker, вытека
ющие из круга решаемых системой задач.
Описывается модуль администрирования Joker, пред
назначенный как для управления плагинами, пользователя
ми, группами и их правами, так и для мониторинга функ
ционирования сервера Joker.
Отдельно рассмотрен вопрос создания и обработки
графических изображений полнотекстовых документов в
собственном формате fbt, базирующемся на технологии
сжатия изображений DjVU. Данный формат позволяет по
лучать высочайшую степень сжатия графических изобра
жений печатного текста при отличной читаемости, и
именно эти свойства обусловили выбор его для обработки
документов раритетных изданий правовой литературы
XVII—XIX веков.
393
Особое место в докладе уделено поисковой системе
Joker, включающей в себя как средства полнотекстового
поиска по документам различных типов, так и средства
поиска по метаданным, при этом для каждого типа мате
риала, описываемого метаданными, существует и настраи
вается индивидуальный набор поисковых атрибутов.
ВВЕДЕНИЕ
Как известно, формально работы по созданию феде
рального образовательного портала по юридическим нау
кам «Юридическая Россия» (далее — Портал) были начаты
в 2002 году. От большинства других образовательных пор
талов программно и технологически «Юридическая Рос
сия» отличается двумя факторами.
Вопервых, при построении и развитии Портала
используются только оригинальные (в смысле отличные
от других порталов) и собственные технологии. Для проек
тирования и программирования Портала не привлекаются
соисполнители и не применяются готовые решения сто
ронних организаций.
Вовторых, к началу работ над Порталом у команды
разработчиков был накоплен многолетний опыт разработ
ки, внедрения и эксплуатации информационных систем,
в основе которых лежали технологии Joker, — развиваемые
с 1996 года. Одна из таких систем — информационнобиб
лиотечный комплекс, ядром которого являлась система
Joker, была удостоена премии Президента Российской Фе
дерации в области образования за 2001 год.
Приведенные обстоятельства позволяют авторам наде
яться, что публикация полного текста доклада, выполнен
ного в рамках Всероссийской научнопрактической конфе
ренции «Образовательная среда сегодня и завтра», может
представлять определенный интерес не только для начина
ющих порталостроителей, но и для наших коллег по
СОИП.
1
С Т Р У К Т У РА С И С Т Е М Ы J O K E R
В докладе подробно рассматривается архитектура
построения системы Joker в соответствии с приведенной
структурной схемой (рис. 1).
394
Рис. 1. Структурная схема системы Joker
Практически вся система Joker реализована на Borland
Delphi 7.0, поэтому в дальнейшем под терминами «класс»
и «объект» следует понимать классы и объекты языка
Object Pascal.
2
О П И С А Н И Е Я Д РА J O K E R
Рассмотрение реализации начнем с ядра системы
Joker — сервера. При проектировании сервера предполага
лось, что он должен:
— функционировать как системная служба под операци
онными системами Windows NT 4.0 и старше;
— поддерживать обмен данными с клиентами по прото
колу TCP/IP;
395
— обладать возможностью безостановочного расширения
функциональности за счет подключения модулей рас
ширения (плагинов);
— иметь простой клиентский API;
— обладать необходимыми средствами удаленного адми
нистрирования;
— обеспечивать защиту аутентификационной информации.
Структура сервера Joker представлена на рисунке 2.
Сервер TCP осуществляет прием TCPсоединений по
порту, указанному в конфигурационном файле «Joker
EngineV7.ini». При переходе службы Joker в состояние пау
зы прием новых соединений приостанавливается, в то вре
мя как обслуживание уже установленных продолжается.
После того как новое соединение установлено (т. е. со сто
роны сервера создан новый сокет), создается объект «сес
сия», ассоциированный с данным соединением, а само
соединение переходит в состояние ожидания прихода за
просов от клиента.
В состоянии ожидания прихода запросов у менеджера
пула «слушающих» потоков запрашивается один из свобод
ных в настоящее время потоков, и ему передается дескрип
тор нового соединения. Каждый «слушающий» поток про
слушивает до 63 соединений. Сделано это для того, чтобы
Рис. 2. Структура сервера Joker
396
минимизировать количество одновременно активных
потоков при большом количестве открытых соединений
TCP. Дело в том, что большую часть времени соединение
находится в состоянии ожидания прихода запросов от
клиентов, поэтому модель «одно соединение — один поток»
неэффективна вследствие возрастания накладных расходов
операционной системы на частые переключения контекс
тов потоков.
Когда «слушающий» поток получает от какоголибо
из клиентов запрос, он перестает слушать соответствующий
сокет и передает обработку запроса менеджеру пула рабо
чих потоков. Менеджер пула рабочих потоков выбирает
один из свободных рабочих потоков (или создает новый
при необходимости) и переводит его в активное состояние.
Цикл рабочего потока состоит в обработке принятого за
проса и возврата результатов работы клиенту, после чего
рабочий поток возвращается в пул и «засыпает» (или завер
шается, если в пуле уже находится слишком много потоков).
Все обработчики клиентских запросов, собственно
и реализующие функциональность системы Joker, сосредо
точены в плагинах, сам Joker обрабатывает только незна
чительное количество команд административного характе
ра (получить список открытых сессий, принудительно за
крыть сессию и т. п.).
Плагин — это динамическая библиотека, экспортиру
ющая единственную функцию LoadPlugin. Плагины также
организованы в пул. При необходимости выполнения ко
манды или открытия набора данных у менеджера плагинов
запрашивается один из свободных экземпляров плагина
или создается новый при необходимости. Далее получен
ный экземпляр плагина блокируется от использования дру
гими сессиями, в нем находится нужная команда или на
бор данных, с ними выполняются необходимые операции,
плагин разблокируется и возвращается в пул.
Данный механизм гарантирует, что конкретный экзем
пляр плагина всегда используется только одним рабочим по
током и за все проблемы межпоточной синхронизации
отвечает менеджер — код плагина не требуется писать пото
кобезопасным.
Отдельного внимания заслуживает механизм замены
плагинов «на лету», без перерыва в обслуживании клиентов.
При получении от администратора запроса на замену пла
гина все ранее загруженные экземпляры плагина перево
дятся в особое состояние, в котором они продолжают об
работку уже активных запросов, а новые запросы ставятся
397
в очередь. Как только обработка всех активных запросов
завершается, динамическая библиотека выгружается менед
жером, содержимое файла DLL заменяется на новое, полу
ченное как параметр запроса, происходит загрузка новой
DLL, и работа продолжается.
Весь код, выполняемый в плагине, заключен в «оберт
ку» обработки программных исключений, поэтому ошибки
программирования плагина не фатальны для функциони
рования сервера в целом, однако ошибки типа бесконеч
ного цикла в настоящее время не отслеживаются — эта за
дача находится в стадии разработки.
Плагины содержат команды и наборы данных. Набор
данных (DataSet) — это просто запрос на языке Transact
SQL, функциональный аналог представления SQL View. Ко
манда является аналогом хранимой процедуры SQL. Для
разработки плагинов и придания им необходимой функ
циональности разработаны соответствующие визарды, так
что все необходимые «обертки» генерируются автомати
чески, разработчик пишет только непосредственно код
требуемой команды.
Формат пакетов, которыми обмениваются клиент
и сервер Joker, является открытым, поэтому реализация
клиента Joker на любой платформе не представляет значи
тельных трудностей. Клиентские приложения системы
Joker, ориентированные на работу в интрасети, работают
непосредственно через API Joker, в то же время для интег
рации Joker и webсервера требуется промежуточный ин
терфейс, представляющий собой достаточно тривиальный
comкласс, поддерживающий всего три метода — Login,
OpenDataSet, ExecCommand. При этом все наборы данных
и команды Joker едины как для локальных, так и для web
приложений.
3
С Т Р У К Т У РА Х РА Н И Л И Щ А Д А Н Н Ы Х
Наиболее общая структура хранилища данных Порта
ла показана на рисунке 3. Приведенная схема отражает
только базовые структуры данных, относящиеся к хране
нию документов и системе авторизации.
Документы в обязательном порядке должны быть снаб
жены метаописаниями, так как именно метаописания явля
ются предметом авторизации. Документ может быть струк
турирован, обладая произвольным уровнем иерархии
398
Рис. 3. Структура хранилища данных Портала
структуры, при этом метаописанием снабжается лишь кор
невой документ, остальные составные части с метаописа
нием явным образом не связываются, однако поисковая
система, находя некорневой документ, проверяет права
доступа к нему на основе связанного с корнем метаопи
сания.
Кроме того, как документы, так и метаописания могут
быть связаны друг с другом для отображения сопутству
ющих материалов.
Метаописания рубрицируются, при этом количество и
уровень иерархии рубрикаторов неограниченны.
Система авторизации Joker устроена следующим обра
зом: каждый пользователь принадлежит к одной или более
ролям. Роль определяет совокупность прав доступа входя
щих в нее пользователей как к метаописаниям, так и к объ
ектам ядра Joker (плагинам и входящим в них командам и
наборам данных). Собственно список возможных прав дос
тупа является настраиваемым, при этом список может со
держать до 32 элементов, что обусловлено форматом хра
нения списка прав в виде битовой маски длиной 4 байта.
Примерами прав доступа могут служить «ViewDoc» —
право просмотра документа, «ExecCmd» — право выполнения
399
команды Joker и т. п. Категории прав доступа определяют со
вокупность прав доступа (или маску доступа) для каждой ро
ли. Маска доступа может быть как разрешительной, так и
запретительной, что определяет способ вычисления резуль
тирующей маски в случае принадлежности пользователя
к нескольким ролям.
4
ПОИСКОВАЯ СИСТЕМА JOKER
Поисковая система осуществляет поиск документов,
метаописаний, а также произвольных текстовых данных,
хранящихся в базе данных MS SQL Server.
Метаописания в системе Joker хранятся в формате
MARC21, представляющем собой развитие формата
USMARC с поддержкой кодировки Unicode. Запись в фор
мате MARC21 состоит из набора полей (атрибутов). Функ
циональное назначение каждого поля определено в стан
дарте MARC21, за исключением пользовательских полей,
в которых может находиться произвольная информация.
Формат MARC21 включает в себя спецификации полей для
различных типов описываемых материалов: библиографи
ческие данные (книги, статьи), персоналии, организации,
события и конференции. Для каждого поля определены
правила заполнения, включая требуемые знаки пунктуации.
Часть полей содержит кодированные данные.
Поиск метаописаний осуществляется по настраива
емым поисковым индексам. В индекс может быть включе
но несколько полей MARC21, при этом для индексации тех
или иных полей возможно использование внешних функ
ций индексации, реализованных в виде скомпилирован
ных библиотек DLL. Каждый поисковый индекс имеет
один из трех типов данных: строковый, числовой, дата/
время.
В зависимости от типа данных индекса различается
набор применимых при поиске операторов. Для строково
го типа данных осуществляется поиск слов с учетом или
без учета морфологии русского и английского языков, при
этом существует четыре разновидности поиска: «любое
слово», «все слова», «фраза» (все слова в указанном поряд
ке с возможностью указания точной позиции искомой
фразы в значении поля) и «поиск вблизи» (вариант поис
ка «все слова» с ограничением максимального расстояния
между словами).
400
При выборе структуры поискового индекса приходит
ся идти на компромисс между ресурсоемкостью, скоростью
перестроения индекса и скоростью поиска. Метаописания
изменяются часто, и допустимое время переиндексации не
велико (в идеале переиндексация должна происходить сра
зу же после изменения метаописания), поэтому поисковый
индекс метаописаний имеет прямую структуру (порядко
вый номер слова — код слова — идентификатор записи),
что допускает мгновенную переиндексацию и обеспечи
вает приемлемое время поиска на массивах в несколько со
тен тысяч метаописаний, учитывая относительно малый
размер метаописания по сравнению с полнотекстовым до
кументом.
Поисковая система состоит из двух основных компо
нентов — индексатора и собственно поисковика. Индекса
тор реализован как системная служба, работающая в фоно
вом режиме и с определенной периодичностью проверяю
щая наличие обновлений в метаописаниях, документах или
настройках поисковых индексов. При наличии обновлений
выполняется перестроение требуемого индекса. При этом
индексация возможна в двух режимах — полное перестрое
ние поискового индекса и инкрементальное перестроение.
Полное перестроение требуется в том случае, если из
менилась структура индекса, во всех прочих случаях ис
пользуется инкрементальное. На время выполнения полно
го перестроения индекса использование данного индекса
в поиске невозможно. Инкрементальный алгоритм индек
сации более «гуманен» к пользователю: индексация осу
ществляется небольшими порциями, давая «продых» поис
ковой машине. В индексаторе реализован также механизм
немедленной переиндексации документа в рамках той же
транзакции, в которой он был изменен. Как правило, этот
механизм не используется, так как создает дополнительные
временные задержки при сохранении документа в катало
ге. Однако его можно использовать для повышения прио
ритета обработки конкретного документа по сравнению
с прочими, ожидающими переиндексации (к примеру, мо
жет оказаться необходимым быстрая индексация новостно
го документа, в то время как большой массив документов,
загруженных с другого сайта роботом, может подождать).
Кроме собственно построения поисковых индексов,
индексатор решает еще одну задачу — формирование неко
его сортировочного индекса для документа. Дело в том, что
в каталоге Портала хранятся документы, описывающие раз
ные объекты — книги, статьи, персоналии, события и т. д.
401
При отображении результатов поиска порядок сортировки
перечня документов различен для разных типов материа
лов: к примеру, список книг целесообразно сортировать
по фамилиям авторов и заглавиям, список событий —
по датам их проведения и т. п. Поэтому для каждого типа
документов индексатору можно указать выражение, по ко
торому будет вычисляться сортировочный индекс, причем
последний может быть как строкой, так и датой или чис
лом с соответствующими правилами сортировки значений.
Вышеупомянутое выражение может включать в себя конс
танты, арифметические операторы и имена полей MARC21
и вычисляется встроенным в индексатор языковым интер
претатором. Такой подход позволяет существенно ускорить
дальнейшее отображение списков документов, так как сор
тировочное значение сохраняется в каталоге в виде индек
са и может быть использовано крайне эффективно.
Поисковая машина реализована в виде плагина к ядру
Joker и состоит из нескольких команд, реализующих поиск,
постраничную выборку результатов поиска, а также сохра
нение поисковых запросов для их дальнейшего постоянно
го использования. Команда поиска («Search») принимает на
вход следующие параметры — поисковую строку (о ее фор
мате будет сказано ниже) и необязательные параметры —
список рубрик, в которых будет осуществляться поиск
(если не задан, то ищется по всем рубрикам), лимит коли
чества возвращаемых документов (по умолчанию 1000),
а также требуемое пользователю право доступа к найден
ным документам (по умолчанию требуется право поиска
документа «SearchDoc», однако может быть затребовано
любое право, например, если пользователь занимается ре
дактированием документов, ему целесообразно искать
только те документы, на которые у него имеется право ре
дактирования).
Поисковая строка представляет собой выражение,
состоящее из термов и логических операторов & (AND),
^ (OR), &! (AND NOT). Поисковый терм — это минималь
но необходимый элемент поискового запроса, он бывает
трех видов:
1) Терм типа SQL имеет вид [SQL ‘SQL SELECT expres
sion’], где SQL SELECT expression — SELECT выражение на
языке SQL Server transact SQL, возвращающее набор данных
из одного или более столбцов.
Никакого синтаксического анализа этого выражения
Joker не выполняет, полностью поручая эту работу серве
ру SQL. Первый столбец результирующего набора данных
402
Joker интерпретирует как идентификаторы найденных до
кументов, второй столбец (если есть) интерпретируется
как маска прав доступа к документу, остальные столбцы
игнорируются. Поскольку Joker никак не проверяет
действия, выполняемые при исполнении терма SQL, в це
лях обеспечения безопасности информации терм выпол
няется в контексте специально созданного логина SQL, об
ладающего только правами выборки данных из таблиц по
исковых индексов.
2) Терм типа FIND осуществляет поиск метаописаний
и имеет вид [FIND {оператор поиска} ‘значение’ IN {где ис
кать}].
Оператор поиска может иметь одно из следующих зна
чений: «ALL WORDS», «ВСЕ СЛОВА», «ANY WORD», «ЛЮБОЕ
СЛОВО», «PHRASE {POSITION StartPos}», «ФРАЗА {С ПОЗИ
ЦИИ StartPos}», «NEAR», «ВБЛИЗИ». Выражение «где искать»
может иметь либо значение «ANY INDEX», при этом поиск
осуществляется по всем полям метаописания, либо пере
численные через запятую идентификаторы поисковых ин
дексов, используемых в поиске, либо значение «IN LINKED
DOCUMENTS», что означает следующее: поиск осуществля
ется не в метаописаниях, а в каталоге полных текстов до
кументов, а затем возвращаются идентификаторы метаопи
саний, связанных с найденными полными текстами.
3) Терм типа FTFIND осуществляет поиск полнотексто
вых документов, и о нем будет рассказано далее, при опи
сании полнотекстового поиска.
Допускается произвольное смешение FIND и SQLтер
мов. Поисковая машина располагает развитыми средствами
оптимизации поисковых операций. Для каждого терма,
за исключением SQL, делается предварительная оценка сто
имости его исполнения на основе частотной статистики
входящих в поисковое значение слов. Далее выбирается
план выполнения поиска на основе анализа логических
операторов, связывающих термы. К примеру, если термы
связаны логическим «И» и в результате выполнения перво
го терма было найдено малое количество метаописаний
(малое по отношению к общему размеру поискового ин
декса), при выполнении обработки следующего терма Joker
выберет вариант «поиск в подмножестве найденного». Дру
гой пример — термы связаны логической операцией «ИЛИ»,
и в то же время установлен лимит на количество возвра
щаемых поисковиком записей. В этом случае уже при об
работке первого терма при достижении установленного
лимита поиск прекращается и возвращается требуемое
403
количество записей, найденных первыми. Для связывания
промежуточных результатов выполнения термов между со
бой используются эффективные алгоритмы хэширования
и представления наборов идентификаторов метаописаний
в виде битовых массивов.
Поскольку при отображении списка найденных доку
ментов через webинтерфейс Портала используется постра
ничное отображение длинных списков, после выполнения
поиска поисковая машина сортирует найденные метаописа
ния по вышеупомянутым сортировочным значениям и за
писывает полученный отсортированный массив в базу дан
ных вместе с поисковой строкой. Каждый поисковый за
прос, сохраненный в базе данных, получает уникальный
идентификатор и сохраняется на время существования
клиентской сессии, выполнившей данный поиск. При даль
нейшей постраничной выборке поиск повторно не выпол
няется и данные берутся из ранее сохраненного массива.
Существует возможность сохранения текста запроса для его
дальнейшего использования другими пользователями, одна
ко эта возможность предоставлена лишь администраторам
системы. При работе пользователя в режиме поиска доволь
но частой является ситуация, когда к ранее исполненному
поисковому запросу добавляются уточняющие критерии от
бора, при этом Joker распознает такую ситуацию и выпол
няет поиск в подмножестве ранее найденных документов,
сохраненных в базе данных, при этом режим поиска в ра
нее найденном работает только с запросами того же поль
зователя, так как при различных правах доступа к докумен
там и метаописаниям использование результатов поиска
других пользователей бессмысленно.
Кроме основной команды, осуществляющей собственно
поиск, поисковый плагин содержит еще ряд команд, осуще
ствляющих постраничную выборку результатов поиска,
а также считывание списка поисковых термов для каждого
типа материала. Дело в том, что в зависимости от того,
какой предмет описывает метаописание (книгу, персону, ор
ганизацию или чтолибо другое), состав поисковых термов
меняется. В системе Joker существует модуль настройки по
исковых термов под каждый тип материала. В принципе
собственно поисковик вполне допускает смешивание в од
ном поисковом выражении поисковых термов, относящих
ся к разным типам материала, однако webинтерфейс Пор
тала построен таким образом, что подобное смешение не
возможно, и в реальности поиск осуществляется в пределах
какоголибо одного типа данных. Это снимает ряд проблем
404
с отображением такого смешанного списка, для которого
неочевиден как порядок сортировки разнородных по типу
материалов, так и отображение на webстранице кнопок и
меню, контекстно зависимых опять же от типа материала.
Перейдем теперь к рассмотрению полнотекстового по
иска по документам Портала. Полнотекстовый поиск Joker
способен вести поиск как по файловому хранилищу, так и
по любым полям БД MS SQL, имеющих строковый или
BLOBтип. Как и в случае поиска метаописаний, в полно
текстовом поиске используются поисковые индексы, при
чем теоретически в один индекс могут быть включены раз
личные поля различных таблиц, хотя на практике такая
возможность в настоящее время не используется. В случае,
если индексируется поле типа BLOB, содержащее произ
вольные данные, индексатору необходимо указать, как
именно эти данные интерпретировать. Для этого при на
стройке структуры поискового индекса задается имя поля
таблицы, содержащего информацию о типе хранящегося в
таблице документа. В зависимости от типа документа ин
дексатор просматривает список зарегистрированных в нем
фильтров индексации, предназначенных для обработки до
кумента данного типа, при наличии такого фильтра осуще
ствляет анализ структуры документа (разбор на слова) и
записывает документ в поисковый индекс.
Фильтр представляет собой библиотеку DLL, экспорти
рующую ряд обязательных функций анализа структуры до
кумента, и может быть реализован на любом компилиру
ющем языке программирования. В настоящее время Joker
умеет индексировать текст ANSI и UNICODE, документы
HTML, MS Word, MS Excel, однако при необходимости этот
список легко может быть дополнен любым типом докумен
та с документированной структурой.
Для полнотекстового поиска используются два типа ин
дексов — «прямой» (как в метаописаниях) и «обратный»,
имеющий структуру «слово—массив документов, в которых
это слово встречается». Обратный индекс очень эффекти
вен при поиске вида «все слова» и «любое слово», однако
крайне неэффективен при перестроении. К примеру, если
изменился большой документ, содержащий 10 000 слов, воз
никает необходимость перестроения 10 000 массивов, соот
ветствующих каждому слову. Такая особенность обратного
индекса препятствует его моментальному обновлению
синхронно с изменением документа, поэтому переиндекса
ция полных текстов осуществляется следующим образом:
документ помечается как измененный и переиндексируется
405
только в прямом индексе, что происходит очень быстро.
Поисковая машина при поиске учитывает статус индекса
ции документа и использует оба поисковых индекса —
основной обратный и временный прямой. В фоновом ре
жиме работает процесс, отслеживающий количество доку
ментов во временном индексе, и, как только это количест
во станет велико, начинается процесс построения альтер
нативного обратного индекса параллельно с основным,
продолжающим использоваться для поиска. Как только аль
тернативный индекс перестраивается, поисковик переклю
чается на него, а предыдущий поисковый индекс удаляется.
Таким образом обеспечивается бесконфликтная работа ин
дексатора и поисковика.
Разумеется, наиболее эффективно все эти процессы
работают на многопроцессорных системах, при этом для
каждого из процессов возможно задать ограничение по ко
личеству используемых процессоров. В настоящее время
Joker функционирует на восьмипроцессорном сервере, при
этом один процессор занят индексатором, остальные де
лятся между ядром Joker и сервером SQL.
На сегодняшний момент в системе Joker реализованы
две разновидности поиска в полных текстах — «все слова»
и «любое слово». Поиск фраз и релевантный поиск «вбли
зи» находятся в стадии разработки и требуют проработ
ки решения об эффективном хранении структуры боль
ших документов. Дело в том, что в информационном хра
нилище Портала присутствует значительное количество
документов объемом 100 и более страниц, причем раз
биение этих документов на более мелкие не всегда ос
мысленно и целесообразно. Известные алгоритмы оценки
релевантности крайне неэффективны при работе с доку
ментами такого размера. Решение данной проблемы сто
ит в планах работы коллектива разработчиков Joker. Что
касается собственно алгоритма выполнения полнотексто
вого поиска, то при использовании обратного индекса он
весьма прост и заключается в выполнении логических
операций «И/ИЛИ» над массивами идентификаторов до
кументов, хранящимися в поисковом индексе. Аналогич
но с поиском по метаописаниям используется оптимиза
тор запросов, предварительно оценивающий частотность
входящих в запрос слов и прерывающий поиск при на
хождении требуемого количества документов. После за
вершения поиска массив документов сортируется и запи
сывается во временную таблицу для дальнейшего постра
ничного просмотра.
406
5
РА Б О Т А С П О Л Н Ы М И Т Е К С Т А М И
В ФОРМАТЕ DjVU
В информационном хранилище Портала в основном
находятся документы в текстовых форматах (TXT, HTML,
DOC). Такой формат хранения наиболее компактен и удо
бен для поиска и чтения. В то же время существуют доку
менты в печатной форме, которые по тем или иным при
чинам невозможно или нецелесообразно распознавать и
приводить к текстовому формату. В основном это относит
ся к старинным изданиям, напечатанным на пожелтевшей
бумаге шрифтами индивидуального изготовления. Такие
книги представляют очень большой интерес, так как полу
чить их в пользование практически невозможно вслед
ствие их редкостности, а переводить в текст крайне трудо
емко, да и сохранение необычного оформления этих изда
ний представляется весьма небезынтересным.
Поэтому перед разработчиками Joker встал вопрос
о выборе формата хранения графических изображений пе
чатного текста, оптимального с точки зрения минимиза
ции объема хранения при максимальном сохранении
внешнего вида оригинала. Были перепробованы различные
алгоритмы сжатия, однако все они либо неэффективно
осуществляли сжатие, либо не обеспечивали должную чи
таемость текста. Окончательный выбор был сделан в поль
зу формата DjVU, разработанного компанией ATT специ
ально для сжатия графических изображений текста.
Основная идея DjVU заключается в том, что печатная
страница содержит высококонтрастный текст на низко
контрастном фоне листа, при этом площадь, занимаемая
текстом, весьма невелика по сравнению с фоном, поэтому
разделение изображения на слои с последующим сжатием
слоев с различным качеством дает превосходные результа
ты: при аналогичном внешнем виде документа формат
DjVU дает на порядок лучшее сжатие, чем JPEG. Для про
смотра документов DjVU имеются бесплатно распростра
няемые плагины для браузеров IE и Netscape Navigator,
а также Open Source DjVU SDK под OS Linux. Под Win32
все DjVUпродукты коммерческие, поэтому разработчики
Joker переработали исходные тексты компрессора и деко
мпрессора Linuxверсии под Win32.
С использованием данной технологии средний размер
печатной страницы в формате A4 при отличной читаемости
407
текста и максимальном сохранении фактуры листа состав
ляет 30—50 Kb. Разумеется, формат DjVU — не панацея на все
случаи жизни, и при работе с документами, содержащими
множество многоцветных иллюстраций, степень сжатия по
лучается примерно такой же, как и в формате JPEG.
Формат DjVU существует в нескольких редакциях, по
следние версии которых поддерживают возможность сжатия
многостраничных документов с сохранением структуры до
кумента и гиперссылок между страницами, однако удобные
инструментальные средства создания составных документов
в настоящее время отсутствуют, поэтому разработчиками
Joker был принят свой собственный формат хранения мно
гостраничных документов. Этот формат (fbt — full book text)
включает в себя текстовое оглавление с гиперссылками
на страницы и собственно страницы DjVU.
Для создания документа в формате fbt сначала скани
руются и конвертируются в формат DjVU отдельные стра
ницы, затем вручную составляется оглавление с простав
ленными гиперссылками, и после этого все компилирует
ся в один документ с помощью программыкомпилятора,
входящей в состав системы Joker. Просмотр fbtдокумента
возможен двумя способами.
В составе системы Joker имеется приложение BookView,
предназначенное для просмотра fbt в системе Win32. На
рисунке 4 приведен внешний вид окна этой программы.
В правой части окна отображается структура оглавле
ния документа, в левой — собственно страницы документа.
Программа позволяет ставить в интересующих частях доку
мента именованные закладки, которые сохраняются в ре
естре и становятся доступны при последующем открытии
того же документа. Приложение BookView может открывать
документы формата fbt либо на файловом уровне, либо че
рез сервер Joker. В последнем случае приложение устанав
ливает соединение с серверов Joker и запрашивает у него
интересующие части документа, т. е. по умолчанию при отк
рытии документа клиент получает лишь его оглавление,
а сами страницы подгружаются по мере необходимости.
Такой режим удобен при работе через Интернет, миними
зируя время загрузки документа (если нам интересна пара
страниц большой книги, нет необходимости качать ее всю),
кроме того, он обеспечивает защиту авторских прав на до
кумент, так как BookView не имеет возможности сохране
ния документов непосредственно в fbtформате (можно, ра
зумеется, сохранять отдельные страницы, но по умолчанию
и эта возможность отключена).
408
Рис. 4. Внешний вид окна программы BookView
Второй способ просмотра fbtдокумента — через web
интерфейс Портала. В этом случае при открытии докумен
та в браузере отображается его оглавление со ссылками на
страницы, по которым загружаются отдельные страницы
в формате DjVU и отображаются браузером при наличии
установленного плагина от ATT. При таком варианте про
смотра защита авторских прав на документ фактически не
возможна, так как плагин не запрещает сохранение
страниц документа, поэтому в настоящий момент в связи
с непроработанностью ряда правовых вопросов доступ
к fbtдокументам через web закрыт. В настоящее время
в каталоге Портала размещены более 1000 документов
формата fbt общим объемом несколько сотен тысяч стра
ниц, в основном это раритетные издания юридической ли
тературы XVII—XIX веков.