Директива Options

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

Режим получения URL документаFindLinks

Получать URL документов с помощью распознавания гипертекстовых ссылок в тексте уже проиндексированных документов. Этот аргумент используется только в секции IndexedArea.

FindDir

Получать URL документов считыванием оглавлений файловых директорий локальной сети. Этот аргумент используется только в секции IndexedArea.

NoUrlCaseFold

Считать URL документов регистро-зависимыми, в соответствии со стандартом.

UrlCaseFold

Получать URL документов регистро-независимыми, например, при индексировании документов с веб-серверов под Windows.

IndexFollow

Индексировать документы и распознавать гипертекстовые ссылки для получения URL-ов новых документов.

IndexNofollow

Индексировать документы, но не распознавать гипертекстовые ссылки для получения URL-ов новых документов.

NoindexFollow

Не индексировать документы, но просматривать их и распознавать находящиеся в них гипертекстовые ссылки для получения URL-ов новых документов.

Режим получения содержимого документаGetFile

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

GetHttp

получать содержимое документов с помощью HTTP-протокола, посылая заголовки по умолчанию. Этот аргумент используется только в секции IndexedArea.

GetHttp:configid

получать содержимое документов с помощью HTTP-протокола, посылая заголовки, сконфигурированные в конфигурации, имеющей идентификатор configid. Идентификатор configid либо задает локальный путь к файлу с конфигурацией HTTP-запросов, абсолютный или относительно WorkDir, либо определяет значение атрибута name секции HttpOptions в текущем конфигурационном файле.
Этот аргумент используется только в секции IndexedArea.

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

Тип документаИндексироватьНе индексировать, оставитьНе индексировать, удалить

Новый	indnew	skipnew
Изменившийся	indmod	skipmod	remmod
Неизменившийся	indold	skipold	remold
Недоступный		skipmiss	remmiss

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

UpdateУбирать из индекса данные о недоступных документах и индексировать заново новые и изменившиеся документы, не индексировать неизменившиеся документы. Эквивалентен заданию indnew, indmod, skipold, remmiss.

ReindexУбирать из индекса недоступные документы и индексировать заново все существующие, независимо от того, изменились ли они со времени предыдущего индексирования. Эквивалентен заданию indnew, indmod, indold, remmiss.

NoremoveИндексировать документы в данной области индексирования, но не убирать из индекса недоступные документы. Этот флаг полезен при индексировании временно недоступных документов. Эквивалентен заданию indnew, indmod, skipold, skipmiss.

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

Эквивалентен заданию indnew, skipmod, skipold, remmiss.

Noindex Не индексировать документы из данной области индексирования, убирать из индекса все ранее проиндексированные документы из этой области. Эквивалентен заданию skipnew, remmod, remold, remmiss.

SkipНе индексировать документы из данной области индексирования, но сохранить в индексе ранее проиндексированные документы из этой области. Эквивалентен заданию skipnew, skipmod, skipold, skipmiss.

Значение по умолчанию: Update

При получении содержимого документов через HTTP-соединение можно использовать следующие аргументы.

SkipDisconnectedНе удалять из индекса документы, принадлежащие Веб-серверу, с которым не удалось установить HTTP-соединение. Это более слабый вариант noremove, действующий только для недоступных Веб-серверов.

RemoveDisconnectedУдалять из индекса документы, принадлежащие Веб-серверу, с которым не удалось установить HTTP-соединение.

ReconnectВ случае обрыва HTTP-соединения с Веб-сервером пытаться установить его для каждого последующего документа.

ReconnectOnceВ случае обрыва HTTP-соединения с Веб-сервером считать все оставшиеся документы Веб-сервера недоступными.

Значение по умолчанию: RemoveDisconnected, Reconnect

Кодировка символов, используемая в документахrecognizeВсегда распознавать кодировку символов автоматически.

use_content_typeВ случае документов, получаемых по протоколу HTTP, считать кодировкой документа значение, указанное в заголовке Content-Type. Если заголовок отсутствует или в нем не указана кодировка, распознавать кодировку с помощью анализа текста документа.

КодировкаОбозначение

WinCyrillic	windows-1251, cp1251
MacCyrillic	MacCyrillic, MacRussian
DOSCyrillic	IBM855 или cp855
DOSCyrillicRussian	IBM866, cp866
ISOLatinCyrillic	ISO-8859-5, iso-ir-144
WinLatin1	windows-1252, cp1252
WinLatin2	windows-1250, cp1250
KOI8R	KOI8-R, csKOI8R
ISO8859_2	iso-2, iso_8859-2
UTF8	utf8, utf-8

Значение по умолчанию: recognize

Обнаружение границ предложений и абзацев на основе пунктуации

AllowPunctBreaksРазрешить распознавание границ предложений и абзацев по знакам пунктуации - точкам, пробелам, переводам строк и т.п.

IgnorePunctBreaksГраницами предложений и абзацев считать только теги, разбивающие абзац в языке разметки или заданные в конфигурации парсера. Никакие естественные границы (например, точка+пробел+Большая_буква или два перевода строки и абзацный отступ внутри тега <pre> в HTML) не разбивают предложений и абзацев. Однако следует учитывать, что максимальная длина предложения ограничена, поэтому слишком длинные предложения все равно будут разбиты на несколько частей.

Значение по умолчанию: AllowPunctBreaks

Набор атрибутов документаSet имя=значениевключить область индексирования в раздел

Unset имя=значениеисключить область индексирования из раздела

Указанные аргументы позволяют задать поисковые документные атрибуты типа LITERAL, дополнительно к атрибутам, назначаемым парсером документного формата во время индексирования документа. Использование данных аргументов позволяет включить документы в определенные тематические разделы на основании структуры веб-директорий, в которых находятся документы. Альтернативно, во время индексирования документы могут получить поисковые документные атрибуты в соответствии с их содержанием. См. обсуждение в разделе Форматы документов, зоны и атрибуты.

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

Пример: Options Set subtree=ourcompany, Unset subtree=news

Директивы конфигурационного файла

Конфигурация поискового сервера состоит из директивы QueryCharset и секций QueryCache и SearchPageTemplate. Ни одна из директив или секций не является обязательной.

QueryCharset

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

Возможные значения приведены в следующей таблице:

КодировкаОбозначение

WinCyrillic	windows-1251, cp1251
MacCyrillic	MacCyrillic, MacRussian
DOSCyrillic	IBM855 или cp855
DOSCyrillicRussian	IBM866, cp866
ISOLatinCyrillic	ISO-8859-5, iso-ir-144
WinLatin1	windows-1252, cp1252
WinLatin2	windows-1250, cp1250
KOI8R	KOI8-R, csKOI8R
ISO8859_2	iso-2, iso_8859-2
UTF8	utf8, utf-8

Значение по умолчанию: windows-1251.

Секция SearchPageTemplate предназначена для задания шаблона, в соответствии с которым сервер будет показывать страницу с результатами поиска. В случае отсутствия данной секции будет использован встроенный шаблон. В секцию входят следующие директивы:

Директивы секции SearchPageTemplate

Method

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

perl

Шаблон страницы написан на языке Perl. Для использования этого аргумента на компьютере должен быть установлен Perl 5.8, который используется для интерпретации шаблона. Пример такого шаблона приведен в файле report.phtml, включенного в поставку.

xsl

Шаблон страницы написан на XSLT. Шаблон интерпретируется встроенным в поисковый сервер процессором, основанным на библиотеке XALAN. Схема XML, поступающего на вход XSLT-шаблона, приведена в файлах request.xs и yandex.xs, включенных в комплект поставки. Пример XSLT-шаблона содержится в файле report.xsl, включенного в поставку.

binary

Шаблон страницы представляет собой предварительно скомпилированную бинарную динамическую библиотеку, обычно написанную на C++. Пример исходных кодов библиотеки содержится в директории sources_sample/report из комплекта поставки.

ModuleОбязательная директива, указывает путь к файлу, содержащему шаблон страницы. Если указанный файл шаблона отсутствует или имеет неправильный формат, будет использован встроенный шаблон.

OptionsВ настоящее время используется только для шаблонов на Perl. Позволяет задать дополнительные параметры командной строки для интерпретатора Perl, например, подключить какие-либо специфические библиотеки.

Значение по умолчанию: не задан

Секция QueryCache предназначена для описания политики кеширования результатов выполнения поисковых запросов. По умолчанию, если данная секция отсутствует, поисковые запросы не кешируются, то есть каждое обращение к поисковому серверу сопровождается выполнением поиска по индексным файлам. Если секция QueryCache имеется, результаты выполненных запросов временно сохраняются в специальной директории, и время на повторную обработку недавно выполненного запроса не тратится. Необходимость кеширования определяется размером индексных файлов и интенсивностью запросов. При малой нагрузке в кешировании нет необходимости, что упрощает администрирование поискового сервера.

В секцию входят следующие директивы:

Директивы секции QueryCache

PolicyОпределяет, будет ли кеширование полным или частичным. Если аргументом директивы является значение PagesOnly, запросы будут кешироваться только для выполнения переходов на следующие страницы, а повторные запросы с тем же текстом запроса, параметрами сортировки и группировки будут выполняться снова. Если аргументом директивы является значение RepeatedQueries, повторные запросы с такими же параметрами обрабатываться не будут, а их результат будет извлекаться из кеша. В этом случае кеш запросов должен быть очищен после переиндексирования.

Значение по умолчанию: RepeatedQueries

DirДиректория для размещения кешированных поисковых запросов.

Значение по умолчанию: системная директория для временных файлов

LifeTimeВремя в минутах, в течение которого выполненный поисковый запрос хранится в кеше.

Значение по умолчанию: 60

Copyright © 1997 ? 2004 «Яндекс»

Назад	Содержание	Вперед
Группировочные атрибуты		Метапоиск и его настройка

Что вы ищете:

на сайтев интернете

Службы Яндекса:

Маркет - Деньги - Почта - Народ - Новости - Каталог - Директ - Открытки - Отпуск
Энциклопедии - Словарь Лингво - Закладки - Мой Яндекс - Бар - Игрушки - Гостиная

Обратная связь

Директивы, определяющие формат документов Секция DocFormat

Конфигурационный файл может включать несколько секций DocFormat, каждая из которых описывает один из форматов подлежащих индексированию документов и используемый для его интерпретации парсер (анализатор содержимого документа). Более подробную информацию о документных форматах можно найти в разделе Форматы документов, зоны и атрибуты.

Каждая секция DocFormat должна включать обязательную директиву MimeType. Также могут присутствовать необязательные директивы Extensions, Module, Symbol и Config. Если в директиве MimeType указано значение, не перечисленное в списке медиа-типов таблицы Значения директив секции DocFormat по умолчанию, директивы Module и Symbol являются обязательными.

MimeType

Задает произвольное имя документного формата, уникально идентифицирующее этот формат. Обычно в качестве идентификатора формата используется т.н. медиа-тип, значения которого специфицированы для большого количества форматов. Медиа-типы, поддерживаемые по умолчанию, для которых не обязательно задавать директивы Module и Symbol, перечислены в таблице Значения директив секции DocFormat по умолчанию.

Extensions

Задает суффиксы (расширения) файлов данного формата. Если для получения содержимого документа используется файловая система, документы в файлах с заданными расширениями будут считаться имеющими медиа-тип, указанный в директиве MimeType. Тем не менее, если для получения содержимого документа используется веб-сервер, возвращающий заголовок Content-type, в качестве медиа-типа используется значение этого заголовка. Если директива задана с пустым значением, все файлы считаются принадлежащими данному медиа-типу, а все предыдущие секции DocFormat игнорируются. Если директива отсутствует, для медиа-типов, перечисленных в таблице Значения директив секции DocFormat по умолчанию, используются указанные там расширения, а для всех других медиа-типов по умолчанию используется пустое значение.

Module

Задает либо имя файла с библиотекой парсера, либо полный путь к этой библиотеке. Если задано имя файла, полный путь к библиотеке парсера будет определен операционной системой.
Для некоторых медиа- типов имеются значения по умолчанию, перечисленные в таблице Значения директив секции DocFormat по умолчанию, для остальных значений директивы MimeType данная директива должна быть задана.

Symbol Задает имя символа, который должен быть загружен из библиотеки парсера. Значения по умолчанию перечислены в таблице Значения директив секции DocFormat по умолчанию.

Config Задает локальный путь к конфигурационному файлу парсера для данного формата, абсолютный или относительно WorkDir. Форматы конфигурационных файлов описаны в документации к соответствующим парсерам. Например, настройка анализатора формата HTML описана в разделе Конфигурация HTML-парсера, а анализатор формата text/plain не является настраиваемым и для него значение данной директивы игнорируется. Если директива Config отсутствует, будет использована стандартная конфигурация парсера, описанная в документации к соответствующему парсеру.

Пример: <DocFormat> MimeType text/html Extensions .htm, .html, .asp Config attr.cfg </DocFormat>

Документы и индексные файлыВ данной

Существует три способа получения содержимого документа при индексировании и подсветке найденного:

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

Обращение к веб-серверам по протоколу HTTP.

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

Модуль связи с источником данных является посредником между индексатором и внешним источником данных, например, базой данных. В комплект поставки входят модули связи для баз данных, доступных через OLEDB или ODBC (для Windows), и базы данных MySQL. Описание протокола для модуля связи с источником данных входит в состав данной документации, поэтому такие модули могут быть разработаны независимыми поставщиками для произвольных источников данных.

Форматы документов, зоны и атрибуты Понятие парсера

Индексатор, используемый в Яndex.Server 3.1, разработан так, чтобы индексировать документы произвольного формата. С этой целью чтение документа и интерпретация его формата осуществляется с помощью отдельных модулей, по одному модулю на каждый формат документа. Эти интерпретирующие формат модули в дальнейшем называются парсерами.

В состав стандартной поставки Яndex.Server 3.1 входят парсеры форматов text/html и text/plain, в настоящее время доступны также парсеры форматов XML, RTF, PDF и DOC. Кроме того, доступна спецификация интерфейса, которая позволяет независимым производителям разработать нужные парсеры.

Функции, вызываемые разработчиком страницы результатов

h2>7.3.6. Примеры использования Perl

В данном разделе приведены простейшие примеры использования описанных выше функций на языке Perl. Реальные работающие примеры можно найти в файле report.phtml, включенном в комплект поставки программы.

sub UserInit

sub UserInit { Yx::SetSearchParam("ReportCoding", "KOI8-R"); # Каталог, содержащий картинки $::PICTURE_DIR = Yx::ImagesUrl(); # количество документов в списке найденного $::DEF_NUM_DOC = 10; # количество отображаемых для каждого документа контекстов $::DEF_NUM_PASSAGES = 3; # Включить в форму поиск похожих документов $::USE_SIMILAR_DOCS_SEARCH = 1; }

sub UserHttpHeaders

sub UserHttpHeaders { Yx::ContentType ("text/html; charset=".Yx::Charset()); Yx::HeaderOut("Cache-Control", "max-age=3600"); Yx::SetLastModified(); }

sub UserRequest

sub UserRequest { my $text = Yx::FormField("text"); return "" if $text eq ""; my $req = $text; # поиск документов, измененных за последние N дней, # где N определяется cgi-параметором within my $within = Yx::FormField("within"); if ($within != 0) { my $beg_time = time() - ($within * 3600 * 24); my ($sec,$min,$hour,$mday,$mon,$year) = localtime($beg_time); $req .= "&&#date>=".sprintf("\"%04d%02d%02d\"", $year+1900, $mon+1, $mday); } return $req; }

sub UserReport

Перловый модуль, используемый для настройки поисковой выдачи, представляет собой HTML-файл с участками кода на Perl 5, заключенными между разделителями <% и %>: <% sub UserReport { %> <html><head><title>Список найденных документов</title></head> <body><p> <% my $stat = Yx::WordStat(); if ($stat ne "") { print "Результат поиска: $stat<br>\n"; print "Найдено документов: <b>".Yx::TotalDocCount()."</b>\n"; } %> </body></html> <%}%>

Назад	Содержание	Вперед
Метапоиск и его настройка	Уровень выше	Язык запросов Яndex.Server 3.1

Что вы ищете:

на сайтев интернете

Службы Яндекса:

Обратная связь

с результатами поиска требует использования

h2>4.8. Использование статических картинокЕсли дизайн страниц с результатами поиска требует использования картинок, эти картинки можно разместить на каком-либо внешнем HTTP-сервере и указать их веб-адреса в скрипте, создающем страницу результатов (см. главу Формирование страниц с результатами поиска). Тем не менее, чтобы сделать Яндекс-сервер самодостаточным, предусмотрена возможность выдачи статических картинок, пути веб-адресов которых начинаются с /images/. С этими адресами будут выдаваться все картинки с расширениями gif, jpg и png, расположенные в поддиректории ./images директории, в которой находится выполняемый модуль Яндекс-сервера для Windows, либо директории, из которой запущена программа, для Unix.

Copyright © 1997 ? 2004 «Яндекс»

Назад	Содержание	Вперед
Структура и формат конфигурационных файлов		Настройка и использование индексатора

Что вы ищете:

на сайтев интернете

Службы Яндекса:

Обратная связь

Быстрое знакомство

h2>2.3. Пример поисковой формы

Ниже приведен пример простой HTML-формы, которую вы можете разместить на страницах вашего Веб-сервера для ввода данных для поиска:  <form name="search" method="get" action="http://www.firma.ru:17000/"> <b>Поиск:</b><br> <input size="15" name="text" value="" maxlength="200"> <input type="submit" value=" Найти "> </form> Задайте вместо www.firma.ru имя машины, на которой у вас установлен Яndex.Server 3.1. Также задайте свой номер порта, на котором работает Яndex.Server 3.1, если он отличается от принятого по умолчалчанию значения 17000.

Назад	Содержание	Вперед
Назначение и возможности Яndex.Server 3.1		Структура и формат конфигурационных файлов

Что вы ищете:

на сайтев интернете

Службы Яндекса:

Обратная связь

Документация для разработчиков

Содержание8.1. Модули расширения для внешних источников данных8.2. Программа attributer

Группировочные атрибуты

h2>6.5. База группировочных атрибутов

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

indexaof, indexatr

Основные файлы базы группировочных атрибутов. Во время индексирования могут быть созданы из поисковых атрибутов, имена которых перечислены в директиве Groups конфигурации индексатора. Данные поисковые атрибуты должны представлять из себя целые числа или последовательность целых чисел, разделенных запятыми или пробелами. Чтобы использовать в качестве группировочного атрибут типа DATE, он должен быть распознан с помощью parse_data_integer. После этого в группировках и сортировках будет использовано целое число, имеющее смысл числа секунд, прошедших после 1 января 1970 года.

Пример 1. Будем считать, что иерархия из примера Построение иерархического атрибута соответствует группировочному атрибуту с именем cat, и все индексируемые документы имеют формат HTML и содержат тег <META NAME="category" CONTENT="значение"> где "значение" - одно из целых чисел, указанных в примере. В конфигурации HTML-парсера укажем <Attributes> ... cat = TEXT,doc,,ignore/meta.category </Attributes> Это означает, что значение meta-тега с именем category будет распознано парсером как документный атрибут с именем cat. Значение этого атрибута станет известно в результате индексирования документа, но не будет сохранено в основном индексном файле (из-за наличия аргумента ignore). Аргумент ignore позволяет уменьшить размер индексного файла за счет атрибутов, которые не нужны в языке запросов. В конфигурации индексатора укажем директиву Groups: cat Это означает, что документный атрибут cat, определенный парсером при индексировании документа, будет преобразован в одноименный группировочный атрибут, который будет сохранен в базе группировочных атрибутов.

Пример 2. Пусть индексируемые документы являются законодательными актами в формате HTML. Каждому документу соответствует дата его принятия законодателем, по которой требуется искать и сортировать документы. По умолчанию поддерживается поиск и сортировка по дате последнего изменения файла на диске, которая не совпадает с нужной датой. Поэтому сохраняем дату принятия законодателем в следующих meta-тегах: <META NAME="pub_date_search" CONTENT="значение"> <META NAME="pub_date_group" CONTENT="значение"> где "значение" - дата в одном из следующих форматов:
19970127T142435 или
Mon, 27 Jan 1997 14:24:35 или
Mon Jan 27 14:24:35 1997 или
Monday, 27-Jan-97 14:24:35
Используется два разных тега для одинаковой даты, так как даты необходимо по-разному преобразовать для поисковых и группировочных атрибутов. В конфигурации HTML-парсера укажем <Attributes> ... pdat=DATE,doc,parse_http_expires/meta.pub_date_search pd=DATE,doc,parse_data_integer,ignore/meta.pub_date_group </Attributes> В конфигурации индексатора укажем Groups: pd Поисковый атрибут pdat будет сохранен в индексе в формате, позволяющем задавать поисковые запросы вида #pdat>="19990614". Группировочный атрибут pd будет сохранен в базе группировочных атрибутов, что позволит сортировать документы по дате принятия.
имя_атрибута.c2nВ некоторых случаях значения группировочных атрибутов, представленные целыми числами, бессмысленны с точки зрения пользователя поискового сервиса. В этом случае в результатах поиска требуется показать в качестве значений атрибутов некоторые строки-идентификаторы. Соответствие между значением атрибута и строковым идентификатором этого значения задается в файле с расширением c2n, имя которого совпадает с именем атрибута. Для каждого атрибута создаЈтся отдельный файл. Каждая строка указанного файла задает одно соответствие. Эта строка имеет формат (целое число, значение атрибута)(символ табуляции)(текстовая_строка)(символ перевода строки)

Если для значений атрибута не предусмотрено соответствия текстовым строкам, то c2n-файл для этого атрибута отсутствует.
Заданные в c2n-файле имена значений могут быть получены при формировании страниц с результатами поиска на C++ и Perl с помощью функции CategName. В XML-представлении результатов поиска они указываются в атрибуте attr элемента categ.
Пример. Для иерархии из примера Построение иерархического атрибута c2n-файл имеет вид 1 Развлечения и отдых 2 Компьютеры 3 Спорт 4 Знакомства 5 Путешествия 6 Hardware 7 Software 8 Горные лыжи 9 Плавание 10 Туры 11 Отели 12 Билеты 13 Авиа 14 Ж/д
имя_атрибута.c2pФайлы c2p используются только для иерархических атрибутов и состоят из строк формата: (целое число, значение "ребенок")(символ табуляции)(целое число, значение "родитель")(символ перевода строки) Каждая строка задает одно иерархическое соответствие ребЈнок → родитель. Для каждого атрибута создаЈтся отдельный файл.
Если атрибут не является иерархическим, то c2p-файл для него отсутствует.
Заданные в c2p-файле значения могут быть получены при формировании страниц с результатами поиска на C++ и Perl с помощью функции CategParent. В XML-представлении результатов поиска иерархия атрибутов для данного документа представлена в виде вложенных элементов categ.
Пример. Для иерархии из примера Построение иерархического атрибута c2p-файл имеет вид 1 0 2 0 3 1 4 1 5 1 6 2 7 2 8 3 9 3 10 5 11 5 12 5 13 12 14 12
Все описанные файлы должны находиться в той же директории, что и основные индексные файлы.
Техническое замечание. С точки зрения эффективности реализации желательно, чтобы диапазон значений группировочных атрибутов был как можно более "компактен" и его нижняя граница была недалека от нулевого значения.
Максимальное число группировочных атрибутов равно 20. Максимальное число уровней в иерархии данного атрибута равно 10. Максимальное число значений данного атрибута, которое может иметь документ, равно 20 (без учета верхних уровней возможной иерархии).

Настройка и использование индексатора

Содержание5.1. Алгоритм работы индексатора5.2. Директивы конфигурационного файла5.3. Правила индексирования, не описываемые в конфигурационном файле5.4. Конфигурация HTTP-запросов5.5. Парсеры документных форматов5.6. Внешние источники данных

Настройка и использование поискового сервера

Содержание7.1. Директивы конфигурационного файла7.2. Метапоиск и его настройка7.3. Формирование страниц с результатами поиска7.4. Язык запросов Яndex.Server 3.1

Server StandardНе содержит лицензионных ограничений

h2>1.6. Различные редакции Яndex.Server 3.1Яndex.Server 3.1 выпускается в следующих редакциях: Яndex. Server StandardНе содержит лицензионных ограничений на число индексируемых документов, их размер или суммарный размер индекса. Позволяет индексировать документы как через HTTP-соединение, так и чтением локальной файловой системы. Позволяет независимо настраивать параметры индексирования для разных групп документов. Поддерживает все возможности языка запросов, ранжирования результатов поиска и подсветки найденных слов. Представляет результаты поиска во встроенном дизайне, созданном Студией Артемия Лебедева.

Яndex.Server ProfessionalВ дополнение к возможностям стандартной редакции Яndex.Server Standard, позволяет полностью настроить дизайн страницы с результатами поиска с использованием скриптов, написанных на Perl, C++ или XSLT, или представить эти результаты в виде XML-документа с определенной схемой. Имеет возможность реализовать "расширенный поиск" для пользователей, не знакомых с языком запросов, организовать поиск по тематическим разделам, сгруппировать найденные документы по различным признакам. Позволяет сделать тонкую настройку индексируемых зон и атрибутов в HTML-документе.

Яndex.Server EnterpriseВ дополнение к возможностям редакции Яndex.Server Professional, поддерживает форматы XML, RTF, PDF, MSDOC, MP3 и другие. Позволяет получать индексируемые документы из произвольных баз данных, в частности, MySQL и MS SQL. Позволяет искать в нескольких независимых коллекциях документов, имеет возможность распределенного поиска, со сливанием результатов, полученных из разных поисковых источников.

Данная документация описывает все возможности редакции Яndex.Server Enterprise. Для редакции Яndex.Server Professional имеются следующие ограничения. Раздел Конфигурирование коллекции документов. Возможна только одна секция Collection.

Раздел URL и содержимое документа. Внешние источники данных не поддерживаются. Конфигурация индексатора не может включать секцию DataSource.
Модули расширения, описанные в разделе Внешние источники данных, не поставляются.
Раздел Секция DocFormat. Секция не может содержать директив Symbol и Module, а директива MimeType может принимать только значения text/plain и text/html. Парсеры других форматов не поставляются.
Для редакции Яndex.Server Standard дополнительно к указанным имеются следующие ограничения Раздел Форматы документов, зоны и атрибуты. Поддерживается только конфигурация HTML-парсера по умолчанию. Секция DocFormat в конфигурации индексатора не может содержать директиву Config.
Раздел Группировочные атрибуты. В дизайне по умолчанию поддерживается только несгруппированный список документов. Конфигурация индексатора не может содержать директив DocProperty и Groups.
Раздел Использование функций формирования страниц (C++ и Perl). Скрипты формирования страниц не поддерживаются. Конфигурация поискового сервера не может включать секцию SearchPageTemplate.
Кеширование поисковых запросов не поддерживаются. Конфигурация поискового сервера не может включать секцию QueryCache.

Copyright © 1997 ? 2004 «Яндекс»

Назад	Содержание	Вперед
Яndex.Server 3.1		Быстрое знакомство

Что вы ищете:

на сайтев интернете

Службы Яндекса:

Обратная связь

Структура и формат конфигурационных файлов

Яndex.Server 3.1 настраивается с помощью размещения директив в одном или нескольких текстовых конфигурационных файлах. Основной конфигурационный файл обычно называется yandex.cfg и располагается в той же директории, в которой находится выполняемый модуль Яндекс-сервера для Windows, либо директории, из которой запущена программа, для Unix. Однако это поведение может быть переписано с помощью параметра командной строки. В некоторых директивах основного конфигурационного файла могут задаваться дополнительные конфигурационные файлы.

Изменения в конфигурационных файлах распознаются в следующее время.

Параметры, относящиеся к сервису в целом - только при старте сервиса.

Параметры индексирования - при каждом запуске индексирования.

Параметры поиска - при запуске поисковой сессии.

Каждая директива конфигурационного файла соответствует одному из параметров настройки. Директивы состоят из одного или нескольких слов, разделенных пробельными символами. Первое слово директивы является ключом, соответствующим настраиваемому параметру, остальные - аргументами, задающими значение параметра. Помимо пробельных символов, ключ директивы может отделяться от аргументов необязательными символами : (двоеточие) и = (равно), но не более, чем одним. Аргументы директивы могут отделяться друг от друга, помимо пробельных символов, символом , (запятая). Конфигурационные файлы включают одну директиву на строку. Для переноса аргументов директивы на следующую строку может быть использован обратный слеш (\), расположенный на конце строки. (То есть, если между символом обратного слеша и символом конца строки находятся только пробельные символы, то директива переносится на следующую строку, а символ \ игнорируется.) Ключи директив конфигурационного файла являются регистро-независимыми, но аргументы директив зависят от регистра символов.

Директивы конфигурационного файла могут быть сгруппированы в секции. Каждая секция начинается со строки <Имя_Секции> и кончается строкой </Имя_Секции>, где Имя_Секции соответствует параметру, который настраивается с помощью одной или нескольких директив, расположенных внутри секции.
Секции могут быть вложенными. Директивы конфигурационного файла, которые не лежат в какой-либо секции, считаются принадлежащими подразумеваемой главной секции, включающей весь конфигурационный файл.
Строки конфигурационного файла, расположенные внутри секции и начинающиеся с символов #, ! или ;, рассматриваются как комментарии и игнорируются. Однако, если указанные символы встречаются в середине или конце строки, они считаются значимыми. Пустые строки и пробельные символы в начале строки игнорируются, поэтому могут использоваться, чтобы сделать запись более ясной. Помимо этого, в любом месте конфигурационного файла могут быть расположены комментарии в XML/HTML-стиле, начинающиеся с символов .
Пример 3-1. Формат конфигурационного файла
Ниже приведен отрывок некоторого конфигурационного файла правильного формата !Следующая строка содержит директиву главной секции с ключом Debug !и аргуметами config, base и error Debug : config, base, error  <IndexedArea> HttpPrefix / Options reindex # FilePrefix = ./mydir </IndexedArea>
Copyright © 1997 ? 2004 «Яндекс»

Назад	Содержание	Вперед
Быстрое знакомство		Архитектура, настройка и администрирование Яndex.Server 3.1

Что вы ищете:

на сайтев интернете

Службы Яндекса:

Обратная связь

Индексирование баз данных MySQL (Unix) Конфигурационный файл индексатора

Индексирование MySQL баз данных реализовано в Яndex.Server 3.1 посредством специального модуля связи с источником данных, который находится в файле ypmysql.dll для Windows и libypmysql.so для Unix. Поэтому для индексирования MySQL-данных в конфигурационном файле индексатора надо задать хотя бы одну секцию следующего вида (см. раздел Секция DataSource).

<DataSource> Name mysqldata Module ypmysql.dll Config mysql_datasrc.cfg <DataSource>

Здесь mysqldata - произвольный идентификатор, отличающий один источник данных от другого, а mysql_datasrc.cfg - произвольное имя конфигурационного файла для источника данных. Ниже в этом разделе мы рассмотрим директивы этого конфигурационного файла.

Индексирование данных через интерфейс

Индексирование баз данных через интерфейс OLEDB реализовано в Яndex.Server 3.1 посредством специального модуля связи с источником данных, который находится в файле oledb.dll. Поэтому для индексирования OLEDB-данных в конфигурационном файле индексатора надо задать хотя бы одну секцию следующего вида (см. раздел Секция DataSource).

<DataSource> Name: mydata Module: oledb.dll Config: sqldb.cfg <DataSource>

Здесь mydata - произвольный идентификатор, отличающий один источник данных от другого, а sqldb.cfg - произвольное имя конфигурационного файла для источника данных. Ниже в этом разделе мы рассмотрим директивы этого конфигурационного файла.

Индексирование книжного магазина

Пример 5-6. Конфигурация OLEDB-источника данных

Ниже приведена настройка индексирования, которую можно было бы использовать для индексирования книжного магазина. Предположим, что база данных магазина поддерживается MSSQL-сервером на компьютере BOOKDB в каталоге bookshop, который состоит из трех таблиц. Первая таблица books описывает книги и содержит следующие поля. bookid ;идентификатор книги authorid ;идентификатор автора catid ;идентификатор темы title ;название книги description ;краткое содержание Вторая таблица authors описывает авторов и содержит следующие поля. authorid ;идентификатор автора author ;имя автора biograph ;биография автора Третья таблица categories описывает многоуровневый тематический каталог и содержит следующие поля. catid ;идентификатор темы owner ;идентификатор темы верхнего уровня из этой же таблицы category ;название темы Идентификаторы в таблицах являются числами, остальные поля содержат обычный текст без форматирования.

Конфигурационный файл индексатора включает в себя следущую секцию. <DataSource> Name: books Module: oledb.dll Config: sqldb.cfg Options: IndexNofollow UrlCaseFold </DataSource> При поиске мы хотим сгруппировать результаты по темам книжного каталога, поэтому добавим в конфигурацию следующую директиву: Groups: cat Эта директива позволит автоматически создать файлы группировочных атрибутов в процессе индексирования документов, однако для этого надо определить документный атрибут cat, то есть настроить парсер: <DocFormat> MimeType: text/html Config: html.cfg </DocFormat>

Конфигурационный файл источника данных sqldb.cfg имеет следующий вид. provider = SQLOLEDB.1 datasource = BOOKDB catalog = bookshop userid = ***** password = *****  <Dump> cat.c2n = SELECT catid, category FROM categories/catid/category cat.c2p = SELECT catid, owner FROM categories/catid/owner </Dump>  <book> urlquery = SELECT bookid FROM books ORDER BY 1 keyfields = bookid docquery = SELECT b.catid, b.title, b.description, a.author, c.category \ FROM books b, authors a, categories c \ WHERE b.catid = c.catid AND b.authorid = a.authorid AND b.bookid = $1 indexfields = catid, title, description, author, category template = c:\yandexsite\book.htm </book>

Файл c:\yandexsite\book.htm шаблона документа, представляющего одну книгу, имеет следующий вид. <HTML> <HEAD> <META NAME="catid" CONTENT="$1"> </HEAD> <BODY> <H1>$2</H1> <H2>$4</H2> <H3>$5</H3> <P>$3</P> </BODY> </HTML>

Конфигурационный файл парсера html.cfg имеет следующий вид (см. раздел Конфигурация HTML-парсера). <Zones> title H1 author H2 category H3 description P </Zones> <Attributes> cat INTEGER/meta.catid </Attributes> Так как документ разбит на несколько поисковых зон, книги можно искать как по полному описанию, так и независимо по названиям, авторам, описаниям, категориям каталога. Например, найдем произведения Пушкина, в описании которых встречается слово сказка: description[сказка] && author[Пушкин]

Copyright © 1997 ? 2004 «Яндекс»

Назад	Содержание	Вперед
Парсеры документных форматов	Уровень выше	Группировочные атрибуты

Что вы ищете:

на сайтев интернете

Службы Яндекса:

Обратная связь

Индексирование WAP-ресурсов

Ниже приведен пример секции <DOCTYPE>, которая может быть использована при индексировании WML-документов (см. http://www.wapforum.org/DTD/wml12.dtd).

<DOCTYPE public="DTD WML 1.2"> LocalDTD = wml12.dtd <Zones> anchor = anchor, a, go, card, option / link </Zones> <Attributes> link = URL,anchor/_.href,card.ontimer,card.onenterforward,card.onenterbackward,option.onpick title = TEXT,doc/card.title </Attributes> <TextFlags> BREAK_PARAGRAPH = br, table, tr, td </TextFlags> </DOCTYPE>

Назад	Содержание	Вперед
Конфигурация HTTP-запросов	Уровень выше	Внешние источники данных

Что вы ищете:

на сайтев интернете

Службы Яндекса:

Обратная связь

В заключение сведем все вышесказанное

h2>7.4.9. Краткое описание языка запросов В заключение сведем все вышесказанное в таблицу. Данным сжатым описанием языка запросов Яndex.Server 3.1 удобно пользоваться при составлении сложных поисковых выражений и всегда полезно иметь под рукой.

Таблица 7-1. Краткое описание языка запросов

СинтаксисЧто означает операторПример запроса

Пробел или &	Логическое И (в пределах предложения)	Лечебная физкультура
&&	Логическое И (в пределах документа)	рецепты && (плавленый сыр)
\|	логическое ИЛИ	фото \| фотография \| снимок \| фотоизображение
( )	группирование слов	(технология \| изготовление) (сыра \| творога)
~	бинарный оператор И НЕ (в пределах предложения)	банки ~ закон
~~	бинарный оператор И НЕ (в пределах документа)	путеводитель по парижу ~~ (агентство \| тур)
/(n m)	расстояние в словах (-назад +вперед)	поставщики /2 кофе музыкальное /(-2 4) образование вакансии ~ /+1 студентов
" "	поиск фразы	"красная шапочка" (эквивалентно красная /+1 шапочка)
&&/(n m)	расстояние в предложениях (-назад +вперед)	банк && /1 налоги

Таблица 7-2. Поиск в зонах и элементах

СинтаксисЧто означает операторПример запроса

$title (выражение)	поиск в заголовке	$title (CompTek)
title [выражение]	поиск в заголовке	title [CompTek]
$anchor (выражение)	поиск в тексте ссылок	$anchor (CompTek \| Dialogic)
anchor [выражение]	поиск в тексте ссылок	anchor [CompTek \| Dialogic]
$address (выражение)	поиск в тексте адреса	$address (Иванов)
address [выражение]	поиск в тексте адреса	address [Иванов]
#keywords=(выражение)	поиск в ключевых словах	#keywords=(поисковая система)
#abstract=(выражение)	поиск в описании	#abstract=(искалка \| поиск)
#hint=(выражение)	поиск в подписях к изображениям	#hint=(lenin \| ленин)
#image="имя файла"	поиск файла изображения	#image="tort*"
#applet="имя файла"	поиск файла java-апплета	#applet="pref.class"
#style="имя файла"	поиск документа в данном стиле	#style="mitsu.css"
#url="значение"	поиск на заданном сайте (странице)	#url="www.comptek.ru*"
#link="значение"	поиск ссылок на заданный URL	#link="www.yandex.ru*"
#anchor.link="значение"	поиск ссылок на заданный URL из обычной ссылки	#anchor.link="www.yandex.ru*"
#date="значение"	дата создания документа 14.05.1997	#date="19970514"
#date<"значение"	дата создания документа до 14.05.1997	#date<"19970514"
#date>"значение"	дата создания документа после 14.05.1997	#date>"19970514"
#date<="значение"	дата создания документа до 14.05.1997 включительно	#date<="19970514"
#date>="значение"	дата создания документа после 14.05.1997 включительно	#date>>="19970514"
#<имя_раздела>="значение"	поиск в разделах, заданных при индексировании	#contents="gogol"

Назад	Содержание	Вперед
Формирование страниц с результатами поиска	Уровень выше	Документация для разработчиков

Что вы ищете:

на сайтев интернете

Службы Яндекса:

Обратная связь

Как получить URL документа?

h2>5.1.3. Области индексирования

Область индексирования - это множество документов, индексируемых с единым набором параметров. Каждый внешний источник данных целиком соответствует одной области индексирования. Области индексирования для остальных документов задаются префиксом URL, то есть все документы, URL которых начинается с заданного префикса, принадлежат одной области индексирования. Области индексирования могут быть вложенными. В этом случае область индексирования, заданная более длинным префиксом, наследует все свойства "родительской" области, если они явно не переопределены. Все свойства областей индексирования, то есть параметры индексирования соответствующих документов, задаются в конфигурационном файле.

Свойства областей индексирования. Для каждой области индексирования могут быть заданы режим получения URL документа, режим получения содержимого документа, включая конфигурацию HTTP-заголовков и прокси-серверов для документов, получаемых по HTTP-протоколу, режим обновления индекса, кодировка символов, используемая в документах, набор атрибутов, значения которых можно использовать, например, в качестве критериев поиска. Если в области индексирования URL-ы документов определяются чтением оглавленния локальных директорий, или содержимое документов получается чтением файлов в локальной сети, то для этой области индексирования должен быть задан соответствующий ей локальный путь (локальная директория). При этом локальный путь для документов из этой области индексирования определяется заменой префикса URL документа, совпадающего с URL области индексирования, на локальный путь указанной директории. Свойства областей индексирования, включая локальные пути, задаются в секциях IndexedArea конфигурационного файла. Как специальный случай областей индексирования рассматриваются внешние источники данных, свойства которых задаются в секциях DataSource.

Назад	Содержание	Вперед
Архитектура, настройка и администрирование Яndex.Server 3.1		Директивы конфигурационного файла

Что вы ищете:

на сайтев интернете

Службы Яндекса:

Конфигурация HTML-парсера Проектирование конфигурации HTML-парсера

Конфигурация HTML-парсера проектируется в соответствии с типичными поисковыми задачами, которые могут возникнуть для данной коллекции документов. В процессе разработки конфигурации рекомендуется придерживаться следующих основных шагов.

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

Пример: Для поиска по подзаголовкам документов введем поисковую зону header. Для поиска по тексту ссылок на другие документы введем поисковую зону anchor. Для поиска по адресам ссылок на другие документы введем поисковый атрибут link.

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

Пример: Определим, что поисковой зоне header принадлежит текст документа, находящийся внутри любого из тегов <h1>...</h1>, <h2>...</h2> или <h3>...</h3>.

Определить, будут ли некоторые поисковые зоны условными. Условными будем называть поисковые зоны, образуемые только при наличии заданного поискового атрибута. Для списка HTML-тегов, определяющего поисковую зону, может быть дополнительно указано имя некоторого поискового (не HTML!) атрибута. Если имя указано, и при попытке создать поисковую зону из содержимого данного HTML-тега эта зона не получает поискового атрибута с указанным именем (и любым значением), то поисковая зона не создается.

Пример: Пусть поисковой зоне anchor должен принадлежать текст документа, находящийся внутри тега <a>...</a>, но только при условии, что данный текст ссылается на другой документ. Для этого данный тег должен иметь HTML-атрибут href. Поэтому определим поисковую зону anchor как условную, возникающую только при наличии поискового атрибута link, описанного в следующем примере.

Для каждого поискового атрибута выбрать его тип (из числа описанных в разделе Типы атрибутов) и список пар (имя HTML-тега, имя HTML-атрибута этого тега). Если у HTML-тега, имя которого совпадает с первым именем в паре имеется HTML-атрибут, имя которого совпадает со вторым именем в паре, то значение этого HTML-тега распознается как значение определяемого поискового атрибута по правилам, специфичным для указанного типа поискового атрибута.

Пример: Определим, что поисковый атрибут link имеет тип URL и значениями этого атрибута будут значения HTML-атрибута href HTML-тега <a> и значения HTML-атрибута src HTML-тега <frame>.

Конфигурация парсера, спроектированная в примерах данного раздела, имеет следующий вид. <HtmlParser> <Zones> header = h1,h2,h3 anchor = a/link </Zones> <Attributes> link = URL,any/a.href,frame.src </Attributes> </HtmlParser> Формальные правила описания конфигурации приведены в следующем разделе.

Конфигурация HTTP-запросов

h2>5.4.4. Пример конфигурации HTTP-запросов

Пример 5-3. Конфигурация HTTP-запросов

Ниже приведен отрывок из конфигурационного файла индексатора, задающий конфигурацию HTTP-запросов при индексировании хоста www.host.ru.

<IndexedArea> HttpPrefix www.host.ru Options GetHttp:myhttp </IndexedArea> <HttpOptions name="myhttp"> Timeout: 150 Delay: 0 ProxyUrl: http://proxy.host.ru:8080 <Authorization> UserName: yandex UserPassword: asdf12345 </Authorization> <Headers> User-Agent: Yandex.Server.MyHost/3.0 From: admin@host.ru Accept-Language: ru, *;q=0.1 MyHeader: TestStroka </Headers> </HttpOptions>

В приведенном фрагменте все директивы находятся в одном файле. Такую же конфигурацию можно получить, задав в основном конфигурационном файле индексатора директивы <IndexedArea> HttpPrefix www.host.ru Options http:myhttp.cfg </IndexedArea> и создав дополнительный конфигурационный файл myhttp.cfg следующего содержания Timeout: 150 Delay: 0 ProxyUrl: http://proxy.host.ru:8080 <Authorization> UserName: yandex UserPassword: asdf12345 </Authorization> <Headers> User-Agent: Yandex.Server.MyHost/3.0 From: admin@host.ru Accept-Language: ru, *;q=0.1 MyHeader: TestStroka </Headers>

Назад	Содержание	Вперед
Правила индексирования, не описываемые в конфигурационном файле	Уровень выше	Парсеры документных форматов

Что вы ищете:

на сайтев интернете

Службы Яндекса:

Обратная связь

Конфигурация по умолчанию

Ниже приведен пример конфигурационного файла для HTML-парсера. Данная настройка соответствует поведению парсера по умолчанию, то есть будет использоваться в случае, если дополнительная конфигурация парсера не указана.

<HtmlParser> <Zones> title = title address = address anchor = a/link </Zones> <Attributes> _ = LITERAL/meta._ link = URL,anchor/a.href link = URL,any/frame.src,iframe.src,area.href link = URL/link._ robots = LITERAL,doc,parse_meta_robots,ignore/meta.robots refresh = URL,doc,parse_http_refresh,ignore/meta.refresh style = URL/link.stylesheet profile = URL/head.profile script = URL,any/script.src image = URL,any/img.src applet = URL,any/applet.code,applet.object object = URL,any/object.data,object.classid abstract = TEXT/meta.description keywords = TEXT/meta.keywords hint = TEXT,any/img.alt,area.alt tooltip = TEXT,any/_.title </Attributes> </HtmlParser>

Ниже приведен пример конфигурационного файла для XML-парсера. Данная настройка соответствует поведению по умолчанию - она будет использоваться в случае, если дополнительная конфигурация парсера не указана.

<XmlParser> <DOCTYPE> <Zones> !все XML-элементы образуют поисковые зоны с таким же именем _ = _ </Zones> <Attributes> !для всех зон все XML-атрибуты соответствующих элементов образуют поисковые зонные атрибуты !с таким же именем, как имя XML-атрибута и типом TEXT _ = TEXT,any/_._ </Attributes> <TextFlags> !все XML-элементы независимо от XML-атрибутов и их значений разбивают текст на абзацы BREAK_PARAGRAPH = _._ </TextFlags> </DOCTYPE> </XmlParser>

Конфигурация XML-парсера Проектирование конфигурации XML-парсера

В процессе разработки конфигурации XML-парсера рекомендуется придерживаться тех же основных шагов, что подробно описаны в разделе Проектирование конфигурации HTML-парсера:

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

Для каждой поисковой зоны указать список имен XML-элементов, содержимое которых должно принадлежать данной поисковой зоне. Определить, будут ли некоторые поисковые зоны условными.

Для каждого поискового атрибута выбрать его тип и список пар (имя XML-элемента, имя XML-атрибута этого элемента), определяющих атрибут.

Дополнительно, для каждого XML-элемента можно определить способ обработки текста - границы слов и абзацев, способ обработки пробелов и вес слов.

Конфигурирование группировочных соответствий

Конфигурационный файл источника данных может содержать необязательную секцию Dump, предназначенную для автоматического создания группировочных файлов c2n и c2p (см. обсуждение в разделе Группировочные атрибуты). Эта секция содержит несколько директив, по числу файлов, которые надо создать.

Ключем каждой директивы служит имя файла, а значение состоит из трех полей, разделенных символом /. В первом поле задается SQL-запрос, результатом которого должен быть набор записей из двух полей, а в двух других - названия этих полей. Файлы будут созданы в той же директории, что и остальные индексные файлы.

Пример: cat.c2n = SELECT catid, category FROM categories/catid/category cat.c2p = SELECT catid, owner FROM categories/catid/owner При такой записи будут созданы два файла cat.c2n и cat.c2p, в первом будут записи <catid>\t<category>\n, во втором <catid>\t<owner>\n.

Конфигурирование источника данных

Основная секция конфигурационного файла источника данных должна содержать следующие директивы.

HostName

Имя хоста или IP адрес SQL-сервера.

BaseName

Имя SQL-базы.

User

Имя пользователя.

Значение по умолчанию: текущий логин.

Password

Пароль для доступа к SQL-серверу

Если Password не задан, то будут проверены только те записи в таблице пользователей, которые не имеют пароля.

UnixSocket

Номер unix-сокета.

Значение по умолчанию: не задан.

Port

Номер порта.

Значение по умолчанию: не задан.

UrlQuery

SQL-запрос, при помощи которого можно получить список всех записей базы данных, подлежащих индексированию. Обычно это оператор SELECT по полю или нескольким полям с неповторяющимися значениями (по первичному ключу, если пользоваться терминологией баз данных).

Примеры. UrlQuery SELECT id FROM mydata - так как результатом этого запроса является совокупность всех записей таблицы по полю id, то проиндексированы будут все данные, содержащиеся в mydata. При этом важно чтобы содержимое поля id было уникально, т.е. зная конкретное значение id, мы должны быть уверены, что ему соответствует одна и только одна запись в данной таблице. Зачем это необходимо, станет понятно позже.

UrlQuery SELECT id,name FROM mydata - то же, что и в первом случае, однако, значения в поле id или в поле name могут повторяться. Но любые их комбинации должны быть уникальны.

UrlQuery SELECT id,name FROM mydata WHERE id - проиндексирована будет лишь та часть таблицы, поле id которой меньше 1000.

DocQuery

SQL-запрос для получения конкретной записи базы. Это тоже оператор SELECT, но оформленный таким образом, чтобы в качестве результата запроса возвращался стандартный документ (HTML, например), содержащий запрошенные данные.

Пример: DocQuery SELECT concat( \ 'Content-Type: text/html\n',\ 'Last-Modified: ',m_time,'\n\n',\ '<HTML><HEAD>',\ '<TITLE>',user,'</TITLE>',\ '</HEAD>\n',\ '<BODY>\n',content,'\n</BODY></HTML>'\ ) FROM programs WHERE id=$1 здесь m_time, user, content и id - имена полей таблицы programs.

Из этого примера видно, что ответ SQL-сервера для внешнего получателя (индексатора или поисковика) будет выглядеть как стандартная HTML-страница. Присутствуют все ее атрибуты - HTTP-заголовок (первые две строки, отделенные от основной части документа двумя символами новой строки - "\n\n") и тело документа с необходимым набором тэгов. Непонятным остается только последнее выражение id=$1. Что оно значит, мы объясним ниже.

Redirect Необязательная директива, используется при поиске для вывода ссылки на найденный документ . При отображении ссылки на веб-странице будут подставлены нужные значения полей.

Примеры: Redirect http://www.myhost.ru/cgi-bin/message? Redirect http://www.myhost.ru/cgi-bin/message?id=$1

KeepAliveКлюч дает поисковому серверу команду установить соединение с SQL-сервером при запуске и не закрывать его до завершения работы. Это уменьшает время доступа и повышает производительность системы в целом. По умолчанию соединение с SQL-сервером устанавливается каждый раз при запросе конкретной записи SQL-базы.

HTTP-заголовок может состоять из любых разрешенных данным протоколом модификаторов, но на текущий момент Яndex.Server 3.1 умеет обрабатывать только два их типа: Content-Type и Last-Modified. Content-Type может иметь те же значения, что и соответствующий HTTP-заголовок;

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

Как уже не раз упоминалось, для хранения всех обработанных документов Яndex.Server 3.1 использует один набор индексных файлов. Это же относится и к данным, полученным из SQL-баз. Они хранятся совместно со всеми остальными. Но, так как в отличие от стандартных HTML-страниц записи базы данных не имеют URL, то этот атрибут формируется искусственно по следующим правилам.

К имени или IP-адресу хоста, на котором находится SQL-сервер (задается ключом HostName - см.

ниже) прибавляются значения полей, указанных в операторе SELECT (ключ UrlQuery), разделенные символом '/' (слеш). В результате этого получается уникальный идентификатор записи в стиле адресов Web, по которому ее однозначно можно определить (вот почему список значений, полученный в результате запроса в UrlQuery, должен состоять из неповторяющихся данных).

Например, ключам: HostName localhost UrlQuery SELECT id,ch_id,name FROM programs при значениях id=11, ch_id=123, name=myprog будет соответствовать такой искусственный URL записи в индексной базе: localhost/00000011/000000123/myprog

Для ускорения индексации все числовые поля при генерации URL'a расширяются слева нулями до максимальной ширины поля.

Вообще вопросам производительности при проектировании Яndex.Server 3.1 уделялось самое пристальное внимание, и разработчики постарались учесть большинство нюансов, влияющих на скорость работы системы. Однако далеко не все зависит от программистов. Большое значение для эффективного функционирования поискового сервера имеет конкретная его конфигурация. Так, например, обработка SQL-базы индексатором может производиться двумя разными способами, целесообразность применения которых зависит от конкретной ситуации:для примера, приведенного выше, индексирование напоминает обход сайта по дереву файлов на диске. При этом курсор в SQL-базе перемещается последовательно от записи к записи. В данном случае важно, чтобы список записей базы данных, возвращаемый SQL-сервером в ответ на запрос ключа UrlQuery, был отсортирован по возрастанию. Неотсортированный список приведет к ненужной переиндексации части документов и, соответственно, к падению производительности;

если по каким-либо причинам воспользоваться первым способом индексации не удается, то можно организовать обход SQL-базы роботом в произвольном порядке. При этом курсор текущей записи будет перемещаться по базе произвольно, и необходимость в сортировке отпадает. Индексатор переходит в данный режим работы, если встречает в SQL-запросе ключ UrlQuery символ '(' UrlQuery SELECT concat(id,'/',ch_id,'/',name) FROM programs

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

В процессе индексации значения полей оператора SELECT заносятся в переменные вида $n, где n - порядковый номер поля в операторе SELECT ключа UrlQuery начиная с 1: localhost/00000011/000000123/myprog $1 $2 $3

Для данного примера значение поля id будет содержаться в переменной $1, значение поля ch_id в переменной $2, а значение поля name в переменной $3.

Эти переменные можно свободно использовать при подготовке SQL-запроса для ключа DocQuery. Отсюда выражение id=$1, встретившееся ранее, означает, что у SQL-сервера будут запрошены записи с полем id, равным текущему значению переменной $1.

Конфигурирование поисковых атрибутов

Формальные правила описания поисковых атрибутов можно представить следующим набором выражений: <Attributes> yxattr = TYPE/htelem.htattr(,htelem.htattr)* yxattr = TYPE,yxzone/htelem.htattr(,htelem.htattr)* yxattr = TYPE,yxzone,function/htelem.htattr(,htelem.htattr)* yxattr = TYPE,yxzone,function,ignore/htelem.htattr(,htelem.htattr)* ;только для атрибутов типа URL yxattr = TYPE,yxzone,function,ignore,ext( ext)*/htelem.htattr(,htelem.htattr)* yxattr = TYPE,yxzone,function,ignore,ext( ext)*,local/htelem.htattr(,htelem.htattr)* </Attributes> Где

yxzone - имя поисковой зоны

yxattr - имя поискового атрибута

htelem - имя HTML-тега

htattr - имя HTML-атрибута

(...)* - ноль, один или несколько элементов

TYPE - тип поискового атрибута, как описано в разделе Типы атрибутов

function - одно из строковых значений, указанных ниже, определяющих правила распознавания текста атрибута

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

ext - список расширений имен файлов разделенных пробелами

local - флажок для пометки только локальных (внтурисайтовых) ссылок

Символ _ (подчеркивание) вместо имени HTML-тега или HTML-атрибута обозначает любой элемент или атрибут. Если символ _ задан вместо имени поискового атрибута, имя поискового атрибута будет совпадать с именем HTML-атрибута.

Пример: Многие HTML-теги могут иметь всплывающую подсказку, заданную через HTML-атрибут title. Чтобы проиндексировать все эти атрибуты, можно определить поисковый атрибут tooltip следующим образом: tooltip = TEXT/_.title Каждое из слов текста атрибута title любого HTML-тега войдет в индекс с учетом морфологии.

Особый случай представляют собой теги <META> и <LINK>. Для удобства их использования принято, что именем атрибута тега <META> является значение атрибутов NAME или HTTP-EQUIV, а значением - содержимое атрибута CONTENT. Для тега <LINK> именем атрибута считается значение атрибутов REL/REV, а значением - содержимое атрибута HREF.
Пример: Каждый документ в электронной библиотеке содержит meta-тег следующего вида: <meta name="author" content="_имя_автора_"> Чтобы обеспечить поиск документов, принадлежащих конкретному автору, определим поисковый атрибут author: author = TEXT/meta.author

Пример: email = URL/link.made _ = TEXT/meta._ _ = URL/link._

Это означает, что будут проиндексированы все встретившиеся в документах META и LINK теги. Причем, если в LINK значение одного из его атрибутов окажется равно made, то поисковый атрибут будет иметь имя email. Во всех остальных случаях (это касается и META) будут образовываться поисковые атрибуты с именами, равными соответствующим значениям атрибутов данных тегов. Это позволяет решить проблему постоянного добавления в конфигурацию записей при каждом появлении нового, еще не описанного META или LINK тега. В настройках подобного вида приоритет имеют явно заданные имена атрибутов.

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

ЗначениеОписание

doc	это документный атрибут, тот же самый результат получается, если имя зоны не указывать
empty	это атрибут данной точки документа, то есть атрибут специальной зоны нулевой длины, как обсуждалось в Поисковые зоны и атрибуты
any	если для содержимого данного HTML-элемента сформирована поисковая зона, поисковый атрибут является атрибутом этой зоны. В противном случае это атрибут данной точки документа.
другое имя	если из содержимого HTML-элемента не сформирована поисковая зона с данным именем, поисковый атрибут не создается

Пример: Для поиска картинок по именам файлов определим поисковый атрибут image: image = URL,empty/img.src

Аргумент function может принимать следующие значения: ЗначениеОписание

parse_http_expires	распознавать текст атрибута по правилам, применяемым для meta.expires
parse_http_refresh	распознавать текст атрибута по правилам, применяемым для meta.refresh
parse_http_charset	распознавать текст атрибута по правилам, применяемым для meta.content-type
parse_meta_robots	распознавать текст атрибута по правилам, применяемым для meta.robots
parse_data_integer	распознавать текст атрибута как дату и время и преобразовывать результат в целое число

Аргумент function может быть пропущен. В этом случае применяются правила распознавания атрибута по умолчанию, в соответствии с его типом.

Имена поисковых атрибутов типа URL могут определяться не только наличием или отсутствием соответствующих тегов и их атрибутов, но и расширениями имен файлов, составляющих значение HTML-атрибута, а также фактом, является ли ссылка локальной для данного сайта или уходит на внешние ресурсы. Пример: Создадим дополнительные поисковые атрибуты для случаев, когда HTML-атрибут представляет собой внутрисайтовую ссылку или ссылается на музыкальный файл: ; По умолчанию - расширения не даны link = URL,anchor/a.href link = URL,any/frame.src,iframe.src,area.href ; В случае музыкальных расширений или внутренних ссылок меняем имя атрибута linkmp3 = URL,anchor,,,mp3 mpga mp2 ra/a.href linkint = URL,anchor,,,,local/a.href linkint = URL,any,,,,local/frame.src,iframe.src,area.href Если в конфигурации зон сформирована условная зона anchor по правилу anchor = a/link то текст внутрисайтовых и музыкальных ссылок в эту зону не попадет.

Конфигурирование поисковых зон

Формальные правила описания зон можно представить следующим набором выражений: <Zones> yxzone = htelem (,htelem)* yxzone = htelem (,htelem)* /yxattr </Zones> Где

yxzone - имя поисковой зоны

htelem - имя HTML-тега

yxattr - имя поискового атрибута, определяющего условную поисковую зону

(...)* - ноль, один или несколько элементов

Имя поисковой зоны не может совпадать с одним из зарезервированных имен doc, empty, any. Вместо имени HTML-тега допустимо использовать символ _ (подчеркивание). Он означает любой тег.

Пример: Текст внутри тега title принадлежит поисковой зоне title. title = title

Пример: Текст внутри всех элементов Hn, а также заголовки таблиц принадлежат поисковой зоне header. header = h1,h2,h3,h4,h5,h6,caption

Пример: Текст внутри тега a принадлежит поисковой зоне anchor только при условии, что имеется поисковый атрибут link. anchor = a/link

Конфигурирование правил обработки текста

Формальные правила обработки текста можно представить следующим набором выражений: <TextFlags> ybreak = (xelem)* (, xelem.xattr)* (, xelem.xattr.xval)* </TextFlags> Где

ybreak - один из флагов обработки текста, перечисленных ниже

xelem - имя XML-элемента

xattr - имя XML-атрибута

xval - значение XML-атрибута

(...)* - ноль, один или несколько элементов

Символ _ (подчеркивание) вместо имени XML-элемента обозначает любой элемент.

Флажки обработки текста

BREAK_NONE, BREAK_WORD, BREAK_SENTENCE, BREAK_PARAGRAPH

Определяет, будет ли текст внутри XML-элемента отделен границами слова, предложения или абзаца в дополнение к обычным пунктуационным правилам.

Значение по умолчанию: BREAK_NONE

SPACE_DEFAULT, SPACE_PRESERVE

Определяет, значимы ли пробельные символы в тексте внутри XML-элемента.

Значение по умолчанию: SPACE_DEFAULT

WEIGHT_ZERO, WEIGHT_LOW, WEIGHT_NORMAL, WEIGHT_HIGH, WEIGHT_BEST

Определяет относительный вес слов в тексте внутри XML-элемента. В случае значения WEIGHT_ZERO текст проиндексирован не будет.

Значение по умолчанию: WEIGHT_NORMAL

Важно: Чтобы у найденного документа было определено свойство "заголовок документа", необходимо, чтобы в настройках парсера была определена зона title с флагом обработки текста BREAK_PARAGRAPH, и документ содержал не менее одного предолжения в этой зоне.

Конфигурирование шаблона документа

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

UrlQuery

Пример. UrlQuery: SELECT id FROM mydata Так как результатом этого запроса является совокупность всех записей таблицы по полю id, будут проиндексированы все данные, содержащиеся в mydata. При этом важно, чтобы содержимое поля id было уникально. UrlQuery : SELECT id FROM mydata WHERE id Будет проиндексирована лишь та часть таблицы, поле id которой меньше 1000.

KeyFields

Список имен полей, формирующих первичный ключ в наборе записей, полученном с помощью UrlQuery. Каждому документу, соответствующему одной записи, в индексе будет сопоставлен URL, компонетами которого являются значение директивы Name секции DataSource конфигурационного файла индексатора, имя секции конфигурационного файла источника данных, в которой описывается данный шаблон документа, значения полей, указанных в директиве KeyFields.

Пример: KeyFields: id

DocQuery

SQL-запрос для получения конкретной записи базы. Запрос должен быть оформлен таким образом, чтобы в качестве результата запроса возвращалась ровно одна запись, содержащая данные для формирования документа. В запросе следует употребить параметры с именами $1-$N, где $k - порядковый номер поля в директиве KeyFields

Пример: DocQuery: SELECT id, m_time, title, content FROM mydata WHERE id=$1 Здесь m_time, title, content - имена полей таблицы mydata.

IndexFields

Список имен полей в наборе записей, полученном с помощью DocQuery, которые содержат данные документа. Значения этих полей будут подставлены в шаблон документа.

Пример: IndexFields: id, title, content

TimeStamp Необязательная директива. Имя поля из набора записей, полученного с помощью DocQuery, в котором содержатся данные, имеющие смысл времени последнего обновления записи. Если задано, будет возможна ускоренная переиндексация.

Пример: TimeStamp: m_time

Template Указывает путь к файлу с шаблоном документа. В шаблоне следует употребить параметры с именами $1-$N, где $k - порядковый номер поля в директиве IndexFields. В процессе индексирования будут подставлены значения для текущей записи.

Пример: Template: c:\mydoc.htm Файл c:\mydoc.htm имеет следующий вид: <HTML> <HEAD> <META NAME="docid" CONTENT="$1"> <TITLE>$2</TITLE> </HEAD> <BODY>$3</BODY> </HTML>

MimeType Необязательная директива. Указывает формат документа, генерируемого с помощью шаблона Template. Формат документа должен совпадать с одним из форматов, определенных в секциях DocFormat

Значение по умолчанию: text/html

Redirect Необязательная директива, используется при поиске для вывода ссылки на найденный документ. Если отсутствует, будет показана ссылка на внутренний скрипт, выводящий документ по шаблону, указанному в Template. Значение директивы представляет собой адрес серверного скрипта с CGI-параметрами, вместо значений которых указаны параметры с именами $1-$N, где $k - порядковый номер поля в директиве KeyFields. При отображении ссылки на веб-странице будут подставлены нужные значения полей.

Пример: Redirect: http://myserver.ru/script.asp?id=$1

Конфигурирование зон и атрибутов

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

Конфигурация зон и атрибутов, встроенная в парсеры по умолчанию, достаточна для подавляющего большинства случаев. Однако если необходимо работать с какими-либо специфическими данными, содержащимися в документах, можно изменить эту конфигурацию, описав новое поведение в конфигурационном файле соответствующего парсера. Для этого в секциях DocFormat конфигурационного файла индексатора нужно задать файл конфигурации парсера соответствующего формата. После этого нужно отредактировать конфигурацию парсера в соответствии с его документацией. Настройка парсера формата HTML описана в разделе Конфигурация HTML-парсера, а настройка парсера формата XML описана в разделе Конфигурация XML-парсера.

Механизм взаимодействия Яndex.Server с SQL-сервером

Обобщим все вышесказанное и кратко опишем ключевые моменты механизма взаимодействия Яndex.Server 3.1 с SQL-сервером:

индексация информации из базы данных организуется при помощи двух SQL-запросов, определенных в ключах UrlQuery и DocQuery. Используя ключ UrlQuery, индексатор имеет возможность получить список всех записей, подлежащих индексации, а используя DocQuery - конкретную запись из этого списка.

Ключ DocQuery оформляется таким образом, чтобы возвращать данные в одном из стандартных форматов. Это необязательно должен быть HTML-документ, как в рассмотренных ранее примерах. Данные допустимо оформить в виде text/plain или можно использовать любой другой формат, известный индексатору (подробнее см. ниже).

Индексатор получает информацию и обрабатывает ее обычным образом. В качестве ссылки на исходный документ в индексный файл записывается искусственный URL.

Поисковый сервер производит стандартный поиск по ключевому слову и подготавливает обычную страницу результатов. Она в качестве ссылок на найденные документы содержит URL'ы, сформированные по определенным правилам, которые должны уметь правильно интерпретировать процедуры, отвечающие за извлечение данных из SQL-базы.

В качестве средств для доступа к SQL-серверу и выдачи найденного документа могут быть использованы как скрипты, написанные администратором Яndex.Server 3.1, так и сам поисковый сервер, настроенный соответствующим образом:

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

Пример.

Для выдачи найденного документа используется CGI-скрипт message. Допустим, ключи HostName и UrlQuery для вашей базы выглядят следующим образом: HostName localhost UrlQuery SELECT id,name FROM programs тогда в настройках поискового сервера должна быть следующая запись: Redirect http://www.myhost.ru/cgi-bin/message?

В этом случае URL для записи с id=1 и name=user1 на странице результатов поиска будет выглядеть следующим образом: http://www.myhost.ru/cgi-bin/message?/0001/user1

Это значит, что при использовании своего CGI-скрипта для выдачи искомого документа он в качестве параметров получит строку /0001/user1, которую необходимо обработать и на ее основе сформировать корректный SQL-запрос к базе.

Для тех случаев, когда работать со строкой /0001/user1 не очень удобно, существует альтернативный вариант задания ключа Redirect - с использованием переменных $n. Если ключ имеет вид: Redirect http://www.myhost.ru/cgi-bin/message?id=$1&name=$2будет сформирован так: http://www.myhost.ru/cgi-bin/message?id=0001&name=user1 и скрипт message получит строку параметров стандартного для CGI формата. С данными в таком виде гораздо проще работать, особенно если приходится адаптировать уже существующие процедуры под новые возможности Яndex.Server 3.1.

Эти изменения позволяют задействовать внутренние механизмы Яndex.Server 3.1, обычно используемые для получения подсвеченных документов. В результате поисковик будет сам формировать необходимые SQL-запросы к базе, получать требуемые данные и, пользуясь содержимым ключа DocQuery как шаблоном, генерировать результирующие документы.

Механизм взаимодействия с поисковым

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

sub UserInit

Используется только для языка Perl. Вызывается только один раз при старте поискового сервера для инициализации перловых переменных.

int UserHttpHeaders(ISearchContext* ysc)
sub UserHttpHeaders

Вызывается в самом начале формирования страницы с результатами поиска для установки дополнительных HTTP-заголовков.

void UserRequest(ISearchContext* ysc)
sub UserRequest

Вызывается до выполнения поискового запроса. Предназначена для преобразования полей поисковой формы в строку запроса на языке запросов Яндекса. Использование этой функции полезно, если пользователи системы не знакомы с языком запросов и используют переключатели формы для уточнения области поиска. В этой функции также можно установить поля запроса, влияющие на сортировку и группировку с помощью вызова FormFieldInsert. На C++ текст запроса следует установить с помощью функции void IReqResults::SetUserRequest(const char *req), на Perl запрос является возвращаемым значением.

int UserReport(ISearchContext* ysc)
sub UserReport

Вызывается после выполнения запроса для формирования страницы с результатами поиска. Вся структура и дизайн страницы результатов задается в этой функции.

В процессе формирования документа с подсвеченными словами поисковый сервер вызывает следующие функции, которые могут быть написаны разработчиком страницы с результатами поиска. Если какая-либо из функций не предоставлена разработчиком поисковой страницы, будет использована реализация по умолчанию, такая же, как во встроенном дизайне. void HitStartBody(ISearchContext* ysc)
Hit::StartBody()

Верхняя вывеска-табличка в подсвеченном документе.

void HitEndBody(ISearchContext* ysc, int DocChanged, int FoundInBody, int FoundInCData)
Hit::EndBody(DocChanged, FoundInBody, FoundInCData)Нижняя вывеска-табличка в подсвеченном документе.

DocChanged - равен 0, если документ не был изменен с момента последнего индексирования, в противном случае равен 1.

FoundInBody - найдено слов в теле документа (можно подсветить)

FoundInCData - найдено слов в области, не разрешающей подсветку (заголовок документа, меню, многострочные области ввода)

void HitFirst(ISearchContext* ysc)
Hit::First()Стрелочка-ссылка на первое найденное слово.

void HitLast(ISearchContext* ysc)
Hit::Last()Стрелочка-ссылка на последнее найденное слово.

void HitLeft(ISearchContext* ysc, int word_num, int word_prev_num)
Hit::Left(word_num, word_prev_num)Стрелочка-ссылка на предыдущее найденное слово.

word_num - номер найденного слова

word_prev_num - номер предыдущего найденного слова

void HitRight(ISearchContext* ysc, int word_num)
Hit::Right(word_num)Стрелочка-ссылка на следующее найденное слово.

word_num - номер найденного слова

Метапоиск и его настройка

Поисковый сервер может работать в так называемом метапоисковом режиме. В этом случае одновременно с основным поиском, настройка которого описана в разделе Директивы конфигурационного файла, выполняются поиски по одному или нескольким дополнительным индексам. Результаты поисков по каждому индексу затем объединяются (сливаются) в окончательный результат, форма представления которого задается точно также, как и в режиме обычного поиска (см. Формирование страниц с результатами поиска и Директивы секции SearchPageTemplate).

Дополнительные индексы для метапоиска и соответствующие им коллекции документов называются метапоисковыми источниками и описываются в секциях SearchSource, по одной секции на индекс. Эти дополнительный индексы должны быть предварительно созданы либо данным Яндекс.Сервером (в этом случае соответствующие коллекции документов описываются в других секция Collection конфигурации Яндекс.Сервера), либо другими Яндекс.Серверами или индексаторами, совместимыми с ним, на этом же или на другом компьютере.

В случае метапоиска наличие секции QueryCache в конфигурации поиска является обязательным.

Секция SearchSource должна включать одну из директив IndexDir или CgiSearchPrefix. Сначала анализируется наличие директивы IndexDir. Если такая директива есть, данный поисковый источник считается локальным. В противном случае должна присутствовать директива CgiSearchPrefix и поисковый источник считается удаленным. Поиски по локальным источникам выполняются в том же процессе, что и основной поиск. Поиски по удаленным источникам выполняются в своих собственных процессах, работающих на этом же или на других компьютерах. Данный метапоисковый процесс направляет удаленным источникам запросы и получает от них результаты поиска по протоколу HTTP в специальном формате, после чего объединяет полученные результаты в окончательный результат поиска. В рамках одного метапоиска могут присутствовать как локальные, так и удаленные источники.

Директивы секции SearchSource

IndexDir

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

CgiSearchPrefixУказывает HTTP- префикс адреса поисковой страницы на удаленном поисковом источнике. Пусть, например, удаленный поисковый источник является коллекцией документов Яндекс.Сервера, установленного на порту 17000 компьютера с интернет-адресом www.metasource.ru. Эта коллекция описывается в секции Collection конфигурационного файла этого удаленного Яндекс.Сервера, имеющей атрибут id со значением name1. Тогда значением данной директивы, описывающим этот удаленный источник, будет http://www.metasource.ru:17000/name1/.

В случае метапоиска конфигурация поискового сервера может также включать необязательную директиву MetaSearchOptions.

MetaSearchOptionsДиректива может иметь несколько аргументов, задающих тот или иной параметр метапоиска. Внутри каждой группы аргументов, указанных ниже, нужно выбрать один.

Поиск по основному индексу

SearchOnMainУказывает, что в число поисковых источников нужно включать индекс, описанный в директиве IndexDir конфигурации коллекции документов.

DontSearchOnMainУказывает, что искать по основному индексу не нужно. Тем не менее, этот индекс должен присутствовать.

Значение по умолчанию: SearchOnMain

Метод получения цитат с найденными словами

OneStepQueryВ случае удаленных источников получать всю информацию в одном запросе.

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

Значение по умолчанию: OneStepQuery

Copyright © 1997 ? 2004 «Яндекс»

Назад	Содержание	Вперед
Настройка и использование поискового сервера	Уровень выше	Формирование страниц с результатами поиска

Что вы ищете:

на сайтев интернете

Службы Яндекса:

Обратная связь

Модули расширения для внешних источников данных

h2>8.1.2. Поиск

Функция YDS_OpenDataSrc вызывается при выполнении первого поискового запроса, в результате которого нашлись документы из внешнего источника данных, и дизайн страницы результатов поиска предполагает ссылку на содержимое документа, с подсветкой или без. В третьем параметре передается 0. После формирования страницы выдачи вызывающий тред заканчивает свою работу. Гарантируется отсутствие повторных или одновременных вызовов.

Если библиотека содержит функцию YDS_OpenParseDocUrl, то при формировании показываемого пользователю URL, ведущему на содержание документа, последовательно вызываются функции YDS_OpenParseDocUrl и YDS_CloseDocQuery для каждого URL. YDS_OpenParseDocUrl возвращает YDS_OK, установив третий параметр на область памяти, включающую URL со схемой, которую понимает браузер, и остающуюся корректной до вызова YDS_CloseDocQuery. Этот URL будет показан на странице выдачи. Например, это может быть адрес скрипта на веб-сервере, принимающего CGI-параметры, сформированные на основании идентификатора документа, переданного во втором параметре функции YDS_OpenParseDocUrl. Если же YDS_OpenParseDocUrl отсутствует или возвращает YDS_EOF, в качестве URL, ведущего на содержание документа, будет показан тот же адрес, что и для подсвеченного документа, но без подсветки.

При выполнении запроса на получение подсвеченного документа последовательно вызываются YDS_OpenDocQuery, YDS_GetDocument, и YDS_CloseDocQuery в новом треде. В третьем параметре в YDS_GetDocument всегда передается 0, что соответствует необходимости получить содержание документа. После этого вызывающий тред заканчивает свою работу.

Функция YDS_CloseDataSrc вызывается из еще одного треда в момент остановки поискового сервиса.

Назад	Содержание	Вперед
Язык запросов Яndex.Server 3.1		Программа attributer

Что вы ищете:

на сайтев интернете

Службы Яндекса:

Общие директивыВ этом разделе

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

HttpPrefix

Префикс URL документов, абсолютный или относительно пути, заданного в DefaultHttpPrefix. Все документы, имеющие данный префикс, индексируются по правилам, указанным в Options. Если указан относительный путь, изменение директивы DefaultHttpPrefix при переиндексировании не вызывает переиндексирования данной области индексирования.

Пример: <IndexedArea> HttpPrefix / </IndexedArea>

FilePrefix

Локальный путь, соответствующий значению HttpPrefix. Используется, если требуется получать содержимое документов с помощью чтения файлов. Должен быть указан абсолютный путь или путь относительно WorkDir. Если директива HttpPrefix не задана, в качестве префикса URL используется этот же путь, преобразованный к протоколу file.

Значение по умолчанию: не задан

Пример: <IndexedArea> FilePrefix C:\Inetpub\wwwroot </IndexedArea>

Options

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

Значение по умолчанию: не задан

Пример: <IndexedArea> HttpPrefix / FilePrefix C:\Inetpub\wwwroot Options windows-1251 </IndexedArea>

Определение типов XML-документов

Правила интерпретации каждого типа XML-документов описываются в отдельной секции <DOCTYPE>. Каждая такая секция может иметь атрибуты public, system и root. Анализ значений этих атрибутов позволяет установить соответствие между данным XML-документом и нужными настройками парсера. Сначала анализируется атрибут public, который, в случае своего наличия, содержит подстроку, содержащуюся в значении одноименного атрибута элемента <DOCTYPE> XML-документа. Если соответствие не найдено, аналогичный анализ проводится для атрибутов system. Если соответствие опять не найдено (это может случиться, в частности, если элемент <DOCTYPE> отсутствует в XML-документе), сравнивается значение атрибута root секции <DOCTYPE> конфигурационного файла и имени корневого элемента XML-документа.

Если ни одна из секций <DOCTYPE> конфигурационного файла, имеющая атрибуты, не соответствует XML-документу, будет использована конфигурация, описанная в секции без атрибутов. Если секция <DOCTYPE> без атрибутов отсутствует, будет использована конфигурация, описанная в разделе Конфигурация по умолчанию.

Директивы секции <DOCTYPE>

LocalDTD

Необязательная директива. Определяет локальный файл DTD, который будет импользоваться парсером вместо внешнего, в случае, если он указан в элементе <DOCTYPE> XML-документа.

Особые названия зон и атрибутов

Ряд документных атрибутов попадают в индекс независимо от настроек парсеров и не требуют никаких действий по их описанию. К таким атрибутам относятся размер документа в байтах (size), дата последнего изменения файла с документом (date), дата последнего переиндексирования документа (idate) и некоторые другие.

Механизм индексирования с получением новых ссылок из ранее проиндексированных документов ("сетевой паук") работает, только если определены атрибуты link, и в качестве ссылок используются значения этих атрибутов.

Функция, возвращающая заголовок документа на странице с результатами поиска, работает только в том случае, если при индексировании документа была определена поисковая зона title, содержащая не менее одного предложения и являющаяся границей абзаца.

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

Поисковые зоны и атрибуты

Документ размечается на зоны во время индексирования, в соответствии с метками, возвращаемыми парсером. Каждая зона получает уникальное имя (текстовую строку), используемое в языке запросов, и может быть предметом поиска независимо от других зон. Мы будем называть эти размеченные области документа поисковыми зонами. Каждая поисковая зона имеет точки начала и конца в теле документа. Начало и конец зон всегда приходятся на границы слов. Разные зоны могут быть вложены друг в друга.

Свойства (атрибуты) зон также могут быть помечены в качестве независимых объектов поиска. Такие свойства зон будем называть поисковыми атрибутами, или просто атрибутами. Каждый атрибут имеет уникальное имя (текстовую строку), и значение, которое может быть различного типа, в зависимости от способа его обработки при индексировании. Зона, в общем случае, может иметь произвольное число атрибутов. Каждый атрибут может иметь несколько различных значений. Разумеется, не все атрибуты, определенные в данном массиве документов, должны быть определены для данной зоны. Язык запросов Яндекса позволяет искать в нужной зоне с нужным значением атрибута. Значения атрибутов назначаются зонам во время индексирования, в соответствии с метками, возвращаемыми парсером, и хранятся в том же индексном файле, что и слова, встречающиеся в документе.

Существуют два важных частных случая зон - документ как целое и зона нулевой длины. Атрибуты документа как целого называются документными атрибутами. Примерами документных атрибутов являются размер документа, его автор, дата создания или принадлежность к определенному разделу сайта. Поиск по таким атрибутам является важным частным случаем зонно-атрибутивного поиска. Назначение документных атрибутов возможно не только во время индексирования, как для других зон, но и дополнительно, в конфигурационном файле индексатора (см. подраздел Набор атрибутов документа раздела Директива Options главы Ключи конфигурационного файла индексатора).

Зона нулевой длины введена для того, чтобы иметь возможность назначить атрибуты определенной точке внутри документа. Это может быть полезным в случае, когда документ имеет "вложенные потоки", отличающиеся форматом или медиа-типом и не индексируемые с помощью основного парсера. Например, у картинок в HTML-документе может быть всплывающий сверху текст - параметр alt тега <img>. Этот текст - свойство (атрибут) точки документа, в которой расположена картинка.

Пример 5-4. Документные атрибуты

Рассмотрим массив из двух документов, включающих литературные произведения. Каждый из них имеет документный атрибут datecreated, имеющий значение даты написания произведения его автором. Первый документ имеет атрибут author со значением Pushkin, а у второго документа этот атрибут имеет два значения - Shecly и Zelazny, так как произведение написано в соавторстве. Наконец, у первого документа имеется атрибут in_meter со значением iambus, а у второго документа этот атрибут отсутствует.

Правила индексирования, не описываемые в конфигурационном файле

h2>5.3.2. Файл robots.txt

При индексировании документов по протоколу HTTP Яndex.Server 3.1 поддерживает стандарт исключений для роботов. В соответствии с этим стандартом, правила, управляющие поведением поискового робота, должны располагаться в файле /robots.txt, лежащем в корне Web-сервера.

Детальное описание спецификации файла можно прочитать,например, по адресу: http://www.citforum.ru/internet/search/rbtspec.shtml.

В простейшем виде (разрешено все, кроме директории скриптов) файл robots.txt выглядит следующим образом: User-Agent: * Disallow: /cgi-bin/

Если нужно, чтобы Яndex.Server 3.1 при индексировании вашего сайта не учитывал общие правила для поисковых роботов, модифицируйте robots.txt, добавив специальное правило для User-Agent, заданного при конфигурировании HTTP-запросов. Например, в следующем примере директория скриптов закрывается от всех роботов, кроме робота MyYandexServer, которому открыто все User-Agent: * Disallow: /cgi-bin/ User-Agent: MyYandexServer Disallow:

При написании robots.txt обратите внимание на следующие часто встречающиеся ошибки.

Строка с полем User-Agent является обязательной и должна предшествовать строкам с полем Disallow. Так, приведенный ниже файл robots.txt не запрещает ничего: Disallow: /cgi-bin Disallow: /forum

Пустые строки в файле robots.txt являются значимыми, они разделяют записи, относящиеся к разным роботам. Например, в следующем фрагменте файла robots.txt строка "Disallow: /forum" игнорируется, поскольку перед ней нет строки с полем User-Agent. User-Agent: * Disallow: /cgi-bin Disallow: /forum

Строка с полем Disallow может запретить индексирование документов только с одним префиксом. Для запрета нескольких префиксов нужно написать несколько строк. Например, нижеприведенный файл запрещает индексирование документов, начинающихся с "/cgi-bin /forum", которых, скорее всего, не существует (а не документов с префиксами "/cgi-bin" и "/forum"). User-Agent: * Disallow: /cgi-bin /forum

В строках с полем Disallow записываются неабсолютные, а относительные префиксы. То есть файл: User-Agent: * Disalow: www.myhost.ru/cgi-bin запрещает, например, индексирование документа http://www.myhost.ru/www.myhost.ru/cgi-bin/counter.cgi, но НЕ запрещает индексирование документа http://www.myhost.ru/cgi-bin/counter.cgi

В строках с полем Disallow указываются именно префиксы, а не что-нибудь еще. Так, файл: User-Agent: * Disallow: * запрещает индексирование документов, начинающихся с символа * (которых в природе не существует), и сильно отличается от файла: User-Agent: * Disallow: / который запрещает индексирование всего сайта.

Copyright © 1997 ? 2004 «Яндекс»

Назад	Содержание	Вперед
Директивы конфигурационного файла	Уровень выше	Конфигурация HTTP-запросов

Что вы ищете:

на сайтев интернете

Службы Яндекса:

Обратная связь

Пример файла конфигурации для индексирования и поиска по MySQL-базе.

Содержимое файла mysql_datasrc.cfg может быть таким: KeepAlive yes HostName localhost BaseName mydb User search_user Password search_user_pass UrlQuery SELECT id,ch_id FROM programs DocQuery SELECT concat( \ 'Content-Type: text/html\n',\ 'Last-Modified: ',UNIX_TIMESTAMP(m_time),'\n\n',\ '<HTML><HEAD>',\ '<TITLE>',user,'</TITLE>',\ '<META NAME="Description" Content="',pr_name,' ',pr_descr,'">',\ '</HEAD>\n',\ '<BODY>\n',content,'\n</BODY></HTML>'\ ) FROM programs WHERE id=$1 ! где UNIX_TIMESTAMP(m_time) - время модификации записи в секундах; ! user, pr_name, pr_descr, content - индексируемые поля SQL-базы, ! из которых генерируется html-документ.

В данном примере для каждой записи MySQL-базы генерируется HTML-документ. Это видно по содержимому ключа DocQuery. В нем определен медиа тип text/html. Кроме того, обратите внимание на то, что для получения списка индексируемых записей в UrlQuery используется два поля базы данных (id и ch_id), а для формирования результирующего документа задействовано лишь одно из них (id=$1). На первый взгляд кажется, что второй параметр здесь лишний. И в данном случае это действительно так.

Однако часто встречаются ситуации, в которых без дополнительной информации из SQL-базы не обойтись. Например, на вашем сайте размещена программа телепередач, и вы организовали поиск по ней. Для наглядности страницу с результатами поиска вы хотите оформить так, чтобы рядом с названием передачи выдавалась иконка канала, на котором она будет идти. Имя этой иконки очень удобно передавать через дополнительный параметр (в $2). Подобное возможно, т.к. переменные вида $n (в которые заносятся текущие значения полей ключа UrlQuery) можно использовать не только для формирования внешнего вида исходного документа (в ключе DocQuery), но и при подготовке дизайна страницы результатов поиска.

Ранее мы неоднократно упоминали, что результирующий документ не обязательно должен являться HTML-страницей. Данные из базы могут быть представлены в любом другом формате. Вот, например, как можно представить найденную информацию в текстовом виде (медиа-тип text/plain): DocQuery SELECT concat( \ 'Content-Type: text/plain\n',\ 'Last-Modified: ',UNIX_TIMESTAMP(m_time),'\n\n',\ content) FROM programs WHERE id=$1

Таким образом, внешним представлением поступающих от SQL-сервера данных вы можете свободно управлять.

Программа attributer

h2>8.2.3. Динамическая библиотека пользователя

Динамическая библиотека пользователя, путь к которой задается в директиве Module, должна экспортировать следующую структуру, содержащую указатели на функции. typedef struct ATTRGEN_LIB { FUNC_Attrgen_OpenSession OpenSession; FUNC_Attrgen_CloseSession CloseSession; FUNC_Attrgen_GetGroupAttr GetGroupAttr; FUNC_Attrgen_GetIndexAttr GetIndexAttr; FUNC_Attrgen_GetArchiveAttr GetArchiveAttr; } ATTRGEN_LIB; Структура описана в заголовочном файле aglib.h. Пример реализации функций для группировки по хостам приведен в файле aghost.cpp.

Функции структуры ATTRGEN_LIB

int (*FUNC_Attrgen_OpenSession)(GA_SESSION *obj, const char* cmdline)

Вызывается программой attributer один раз на каждую секцию AttrProvider в самом начале работы для того, чтобы дать возможность инициализировать данные, которые нужно передавать между вызовами функций, получающих атрибуты. В первом аргументе передается указатель, который следует установить на указанные данные: typedef void* GA_SESSION; Если таких данных нет, первый аргумент можно игнорировать. Во втором аргументе передается значение директивы Config. Функция должна возвращать AGOK в случае успеха. Если будет возвращено другое значение, текущая секция AttrProvider не будет использована.

int (*FUNC_Attrgen_CloseSession)(GA_SESSION obj)

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

int (*FUNC_Attrgen_GetGroupAttr)(GA_SESSION obj, const char* url, const char* attrname, ui32* attrvalue)

Вызывается один или несколько раз для каждого документа, имеющегося в существующем индексе, (второй аргумент - адрес документа) и для каждого атрибута из директивы Groups (третий аргумент - имя атрибута). Должна передать в последнем аргументе числовое значение атрибута.

Функция должна возвратить одно из следующих значений.

AGCONTINUE - в последнем аргументе передано числовое значение атрибута и для данного документа и данного имени атрибута существуют еще значения.

AGOK - в последнем аргументе передано числовое значение атрибута и других значений больше нет

AGFALSE - данный документ не имеет атрибутов с данным именем.

AGERROR - случилась ошибка.

int (*FUNC_Attrgen_GetIndexAttr)( GA_SESSION obj, const char* url, const char* attrname, char** attrvalue)Никогда не вызывается в текущей версии программы attributer.

int (*FUNC_Attrgen_GetArchiveAttr)(GA_SESSION obj, const char* url, const char* attrname, char** attrvalue)Никогда не вызывается в текущей версии программы attributer.

Техническое замечание. С точки зрения эффективности реализации желательно, чтобы диапазон значений группировочных атрибутов был как можно более "компактен" и его нижняя граница была недалека от нулевого значения. Максимальное число группировочных атрибутов равно 20. Максимальное число уровней в иерархии данного атрибута равно 10. Максимальное число значений данного атрибута, которое может иметь документ, равно 20 (без учета верхних уровней возможной иерархии).

Copyright © 1997 ? 2004 «Яндекс»

Назад	Содержание
Документация для разработчиков	Уровень выше

Что вы ищете:

на сайтев интернете

Службы Яндекса:

Обратная связь

Секция DataSource

Конфигурационный файл может включать несколько секций DataSource, каждая из которых описывает внешний источник данных. Каждая секция должна включать обязательные директивы Name и Module. Также могут присутствовать необязательные директивы Config и Options.

Name

Задает произвольное имя источника данных, уникально идентифицирующее этот источник данных.

Пример: Name mybase

Module

Задает локальный путь к модулю связи с источником данных, абсолютный или относительно WorkDir.

Пример: Module ../bin/mysql.dll

Config

Задает строку инициализации, которая будет передана источнику данных при его инициализации. Формат этой строки определяется документацией к модулю связи с источником данных. Для модулей связи с базами данных, поставляемых вместе с Яndex.Server 3.1, эта директива является обязательной и определяет путь к файлу конфигурации модуля связи с источником данных, формат которого описан в документации к модулю связи. См. Индексирование данных через интерфейс OLEDB (Windows) и Индексирование баз данных MySQL (Unix)

Значение по умолчанию: не задан

Пример: Config mysql.cfg

Options

Параметры индексирования документов из источника данных. Параметры индексирования сначала наследуются значения директивы DefaultAreaOptions, или от значения по умолчанию, а затем дополняются параметрами, указанными в данной директиве. Аргументы этой директивы описаны в разделе Директива Options

Значение по умолчанию: не задан

Пример: Options windows-1251

Пример: <DataSource> Name zakladki Module oledb.dll Config sqldb.ini <DataSource>

Секция Dump

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

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

Например: Dump.channels.c2n SELECT id,name FROM channels Dump.channels.c2p SELECT id,region FROM channels При такой записи будут созданы два файла channels.c2n и channels.c2p, в первом будут записи вида <id>\t<name>', во втором <id>\t<region>'.

Синтаксис конфигурационного файла

Описание настроек HTML-парсера можно размещать как в общем конфигурационном файле, так и в отдельном файле. В любом случае в секции DocFormat конфигурационного файла индексатора нужно задать путь к файлу конфигурации парсера. Вся конфигурация парсера должна быть размещена внутри секции <HtmlParser>. Директивы, определяющие поисковые зоны, располагаются внутри подсекции <Zones>, а директивы, определяющие поисковые атрибуты - внутри подсекции <Attributes>.

Далее приводятся формальные правила написания конфигураций, и даются конкретные примеры с подробными комментариями.

Структура документа

Каждый документ имеет внутреннюю структуру - деление на параграфы, абзацы, заголовки и т.п. Например, формат электронного письма подразумевает наличие в нем полей from, to, служебных областей, поля сообщения и т.п. Документы принятого в интернете формата HTML также имеют внутреннюю структуру - заголовок, тело документа, ключевые слова. В теле могут присутствовать заголовки различных уровней, ссылки, картинки и т.д. Различные части структурированых таким образом документов будем называть зонами.

Каждая зона может иметь одно или несколько скрытых свойств, не связанных непосредственно с ее текстом. Например, зона to в электронном письме могла бы иметь свойство количество адресов рассылки, а зона ссылка на другой документ в HTML-документе имеет свойство URL документа. Такие свойства зон будем называть атрибутами.

Основная задача парсера - выделить из документа нужный для индексирования текст. Текст, выделяемый парсером, может быть помечен как принадлежащий определенной зоне документа, или как имеющий определенные свойства (атрибуты). На основании элементов форматирования документа парсер может указать границы предложений и абзацев, а также вес данного отрывка текста. Ниже мы рассмотрим зоны и атрибуты более подробно.

Типы атрибутов

По способам распознавания и обработки различаются следующие типы атрибутов:

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

Значение атрибута распознается как неделимая последовательность символов, участвующая в индексировании и поиске как целое. Правила морфологии к такой последовательности не применяются. Такие атрибуты будут называться атрибутами типа LITERAL. Для данного типа атрибутов возможен поиск в интервале значений, с учетом лексикографического сравнения.

Значение атрибута распознается как дата или время. Такие атрибуты будут называться атрибутами типа DATE.

Значение атрибута распознается как Uniform Resource Locator. Такие атрибуты будут называться атрибутами типа URL.

Значение атрибута распознается как целое число. Такие атрибуты будут называться атрибутами типа INTEGER.

Пример 5-5. Типы атрибутов

Некоторый документ имеет атрибут abstract типа TEXT со значением "A general formula is derived for the main gravitomagnetic clock effect in the case of slow motion along an arbitrary elliptical orbit in the exterior field of a slowly rotating mass", атрибут field типа LITERAL со значением "General Relativity and Quantum Cosmology", атрибут publication_date типа DATE со значением "12 Oct 2001 00:00:02 GMT" и атрибут gr-qc типа LITERAL со значением 0110055, идентифицирующий этот документ в международной базе научных публикаций xxx.lanl.gov.

Значения директив секции DocFormat по умолчанию

h2>5.2.4. Примеры настройки индексатора

Пример 5-1. Настройка при обходе сайта по дереву каталогов

! Имя каталога с индексными файлами IndexDir myworkindex ! Имя каталога для временных файлов TempDir mynewindex ! Индексируемый каталог <IndexedArea> HttpPrefix www.company.ru FilePrefix /path/to/www.company.ru/data </IndexedArea> ! Выводить информацию о настройках индексатора и индексируемых документах Debug config, base, exclude

Пример 5-2. Настройка при обходе сайта по ссылкам

! Имя каталога с индексными файлами IndexDir myworkindex ! Имя каталога для временных файлов TempDir mynewindex ! Начальная ссылка StartUrls www.company.ru/ ! Выводить информацию о настройках индексатора и индексируемых документах Debug config, base, exclude

Назад	Содержание	Вперед
Настройка и использование индексатора	Уровень выше	Правила индексирования, не описываемые в конфигурационном файле

Что вы ищете:

на сайтев интернете

Службы Яндекса:

Обратная связь