Индексация *.doc файлов

← →
Glum (2006-05-05 10:30) [0]

Здравствуйте!

Мне необходимо проиндексировать кучу *.doc файлов для дальнейшей организации поиска по ним.

Какие компоненты мне можно использовать для чтения *.doc файлов и записи данных в MySQL?

← →
Сергей М. © (2006-05-05 10:50) [1]

> проиндексировать кучу *.doc файлов

Что это значит ?

← →
Glum (2006-05-05 10:59) [2]

2 Сергей М.

Алгоритм примерно такой: читается файл, составляется список всех слов не короче 3х символов, встречающихся в нём и помещается в БД MySQL. И так со всеми файлами.

Далее скрипт на PHP должен будет искать по этой базе по запросу пользователя, но это уже другая история :)

← →
Плохиш © (2006-05-05 11:11) [3]

> Мне необходимо проиндексировать кучу *.doc файлов для дальнейшей
> организации поиска по ним.

Бесполезная информация

> Какие компоненты мне можно использовать для чтения *.doc
> файлов и записи данных в MySQL?

Здесь 2 вопроса для конференции "Начинающим". Т.к. версия делфи не указана, то отвечаю для Д7: 1й вопрос - компоненты с закладки "Server"; 2й вопрос - компоненты с закладок "ADO" или "dbExpress".

← →
Сергей М. © (2006-05-05 11:26) [4]

> Glum (05.05.06 10:59) [2]

И как это связано с "индексированием *.doc-файла" ?

Что считать "словом" ?

← →
Glum (2006-05-05 17:37) [5]

2 Плохиш
Спасибо. Буду копать в этом направлении.

2 Сергей М.
Я вроде всё достаточно понятно изложил. Мне нужно организовать поиск по файлам, а для этого их нужно прочесть, и меня интересует с помощью какого компонента это можно сделать.

← →
Shirson © (2006-05-06 08:32) [6]

>Glum (05.05.06 17:37) [5]
>Мне нужно организовать поиск по *.doc файлам, а для этого их нужно прочесть, и меня интересует с помощью какого компонента это можно сделать.

uses ComObj; ... var V:Variant; begin V:=CreateOleObject("Word.Application"); V.Documents.Open(FileName:=<FileName.doc>); ... end;

← →
Сергей М. © (2006-05-06 09:01) [7]

> Glum (05.05.06 17:37) [5]

> Мне нужно организовать поиск по файлам

А сами файлы-то где будут храниться ? В той же базе ?
В любом случае для работы с doc-файлами требуется Word (где он при этом будет работать, на стороне сервера или на стороне клиента - не суть как важно), а Word"у никакие "индексы" не нужны - он сам знает как осуществлять эффективный поиск по своим документам.

← →
Shirson © (2006-05-06 09:26) [8]

Сергей М, а вы пробовали осуществлять вордом э... "эффективный поиск по своим(вордовским) документам.", при условии, что этих документов > 10000?
Вот попробуйте, как-нибудь, а потом поделитесь впечатлениями. И про FTS на русском и про скорость и про всё остальное. Это раз.
Два - распишите методу обработки результатов этого самого поиска. Т.е. у вас есть клиент, который должен получить результат посика по файлам ворда. Весь механизм можете расписать?

То что хочет сделать Glum, более чем понятно. Как по сути вопроса, так и по сути "а зачем оно".

Могу влёт привести самый простой пример. Есть электронная библиотека, в которой 50000 книг, свёрстанных в ворде. Нужен механизм поиска по словам в этой библиотеке.
Реализация:
Каждая книга, попадая в библиотеку, проходит обработку "индексатором", который индексирует слова в этом файле (в MySQL). Теперь, при поиске слов по библиотеке, поиск будет производиться средствами СУБД в себе самой и выдавать ссылки на вордовские файлы.
Где при этом хранятся файлы, как они хранятся и на чём они хранятся - сути не имеет НИКАКОЙ. Хоть на шпинделе с сидюками, хоть на стримере, хоть на винте, хоть в BLOB поле самой базы.

P.S. Я, в своё время время, решал очень похожую задачу, только посложнее, порядка на два. На несколько сот тысяч текстов, с многопотоковыми конвейерами индексации, словарями, визуальными инструментами поиска и пр. ужасами.

← →
Сергей М. © (2006-05-06 10:18) [9]

> Shirson © (06.05.06 09:26) [8]

Индекс, насколько я себе представляю, содержит инф-цию не только о наличии того или иного фрагмента, но и "местоположении" этого фрагмента отн-но выбранной "базы", для того чтобы можно было осуществлять быстрое позиционирование на начало фрагмента.
В случае с *.doc-форматом ни о каком "местоположении фрагмента" не может идти и речи, потому что *.doc-формат не является классическим текстовым форматом. Максимум что можно получить и хранить в БД - факт наличия или отсутствия фрагмента в таких-то *.doc-документах.

> Вот попробуйте, как-нибудь, а потом поделитесь впечатлениями

Кто ж заставляет использовать для этой цели именно Word ?
Понятно что этот монстр не слишком эффективно справляется с задачей поиска. Но со структурированными хранилищами в формате ворда (формат этот не представляет большого секрета) с неменьшим успехом можно работать и своими прогр.средствами ! И вот их-то как раз и можно "заточить" именно под эффективный поиск фрагментов.

← →
TUser © (2006-05-06 11:21) [10]

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

← →
Сергей М. © (2006-05-06 11:31) [11]

> TUser © (06.05.06 11:21) [10]

Тогда уж в XML..
Есть немало неплохих инструментов для поисковой работы в XML-формате

← →
Shirson © (2006-05-06 11:56) [12]

> Сергей М. © (06.05.06 10:18) [9]
> Индекс, насколько я себе представляю, содержит инф-цию не
> только о наличии того или иного фрагмента, но и "местоположении"
> этого фрагмента отн-но выбранной "базы", для того чтобы
> можно было осуществлять быстрое позиционирование на начало
> фрагмента.

И да и нет.

Слово "Delphi" содержится в файлах "Help.doc", "User.doc"
Это - индекс.

Файл "Help.doc" находится на третьем снизу сидюке, на шпинделе "Programming"
Это - тоже индекс.

Слово "Delphi" содержится
на позициях 7863, 34555
файл "Help.doc"
сд 3
шпиндель "Programming"

И это индекс.

> В случае с *.doc-форматом ни о каком "местоположении фрагмента"
> не может идти и речи, потому что *.doc-формат не является
> классическим текстовым форматом.
Сорри, но то, что тут написано - ахинея.
Из-за (само)вольного определения индекса, вылезли и проблемы.
(кстати, для справки, в *.doc файле можно отпозиционировать ЛЮБОЙ символ, если понадобится)

> Максимум что можно получить
> и хранить в БД - факт наличия или отсутствия фрагмента в
> таких-то *.doc-документах.

Вы хотели сказать "минимум"?
У меня используется полная индексация по всем словам (с подсчётом количества упоминаний и позициями). Что там можно сделать "максимум", я даже загадывать не берусь, возможностей море.

>Кто ж заставляет использовать для этой цели именно Word ?
Дайте догадаюсь... Заказчик. ТЗ. Политика.

>Понятно что этот монстр не слишком эффективно справляется с задачей поиска. Но со структурированными хранилищами в формате ворда (формат этот не представляет большого секрета) с неменьшим успехом можно работать и своими прогр.средствами ! И вот их-то как раз и можно "заточить" именно под эффективный поиск фрагментов.
Угу. Только два момента - Смысл и Время.
Время на написания нового или затачивание существующего стороннего модуля под свои нужны и смысл сего действа.
Проще, использую Word-сервер, залезать в *.doc файлы и работать с ними по своему усмотрению. Мало того, что это проще, это еще и решает проблему совместимости. Что бы не выдумал МикроСофт в плане форматов, нас это не будет штырить ни разу.

>TUser © (06.05.06 11:21) [10]

>Можно еще воспользоваться программой antiword и перевести текст в текстовый файл. И там уже читать, индексировать ...

Чтобы перевести текст (всмысле из word?) в текстовый файл, не обязательно пользоваться какими-либо сторонними программами.
Кроме того, не стоит забывать, что doc файлы могут содержать широченный спектр форматирования + мультимедия.
А работать с doc файлом как с обычным тектовым не составляет никаких проблем, если установлен Word. А если не установлен, то проще и дешевле его установить :)

← →
Jeer © (2006-05-06 12:02) [13]

Сергей М. © (06.05.06 10:18) [9]

> В случае с *.doc-форматом ни о каком "местоположении фрагмента"
> не может идти и речи, потому что

может идти поскольку row и col - уже дает местоположение.

← →
Anatoly Podgoretsky © (2006-05-06 12:08) [14]

Пишем конкурента Микрософтовскому Index Server

← →
Jeer © (2006-05-06 12:16) [15]

Anatoly Podgoretsky © (06.05.06 12:08) [14]

Просто не все знают как с ним работать, а то и о его наличии.
Деньги тоже не помешают, а что будет плохо работать - какая разница:(

← →
Shirson © (2006-05-06 12:21) [16]

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

← →
Сергей М. © (2006-05-06 12:22) [17]

> Shirson © (06.05.06 11:56) [12]

> Слово "Delphi" содержится
> на позициях 7863, 34555
> файл "Help.doc"

Что ты подразумеваешь под "позицией" в *.doc файле ?

> то, что тут написано - ахинея

С каких пор ахинеей является факт того, что файл документа MSWord не имеет простой текстовый формат ?

> в *.doc файле можно отпозиционировать ЛЮБОЙ символ, если
> понадобится

*.doc-файл и документ MSWord - вовсе не одно и тоже.
Позиция символа в *.doc-файле не имеет ничего общего с позицией того же символа в соответствующем документе MSWord.

Это тоже ахинея ?

> Проще, использую Word-сервер, залезать в *.doc файлы и работать
> с ними по своему усмотрению

Или я тебя не понял или ты сам себе противоречишь, говоря в [8] якобы о малой эффективности использования Ворда для решения задачи поиска в своих же документах.

> два момента - Смысл и Время

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

А время - на то и существуют готовые реализации таких алгоритмов, зачастую они Freeware и OpenSource.

← →
Сергей М. © (2006-05-06 12:31) [18]

> Jeer © (06.05.06 12:02) [13]
> может идти поскольку row и col - уже дает местоположение.

row и col - местоположение в документе, а не в файле, надеюсь, это не вызывает сомнение.

Какие row и col могут быть в бинарном файле, каковым является файл вордового документа ..

А ведь автор ведет речь именно об индексации doc-файлов !

Да, можно "в лоб" просмотреть содержимое этого бин.файла и определить наличие в нем той или иной последовательности (она там действительно будет фигурировать, если вообще имеется). Но это будет лишь факт присутствия модели поиска, не более того.
Ну а для того чтобы построить индекс по вхождениям модели поиска в текст документа (те самые row и col), нужна работа именно с документом, а не с файлом. А уж выбор средств для работы с вордовым документом - это другой вопрос ... Хоть вод это будет хоть что-то альтернативное ..

← →
Jeer © (2006-05-06 12:39) [19]

> А ведь автор ведет речь именно об индексации doc-файлов
> !

А прочесть между строк ? :)))
Стелепатировать ?

← →
Shirson © (2006-05-06 12:39) [20]

>Сергей М

Попробую по-другому.

Есть doc файл, в котором нужно проиндексировать содержание.
С этим файлом можно работать самому, использую "третьи компоненты", либо работать через сам Word.
Открывает файл через Word via OLE. Получаем доступ к содержанию этого файла в виде, для начала, текста. Т.е. по минимуму мы получаем просто текст, с которым уже можно работать, применяя к нему любые желаемые алгоритмы поиска.
В случае необходимости позиционирования найденых слов, поиск можно производить не в plain-text, а обращаясь к тексту по-абзацно (механизмом ворда) и производя поиск чем нам хочется в этом куске (получаем позицию вида НомерАбзаца НомерСимвола).

Хотя я на 90% уверен, что автору топика достаточно иметь схему Слово->Файл.

← →
Shirson © (2006-05-06 12:41) [21]

> Jeer © (06.05.06 12:39) [19]
> А прочесть между строк ? :)))
> Стелепатировать ?

А зачем? Лучше поспорить ;)
А потом пообсуждать не способ решения вопроса, а способ его постановки.

← →
Сергей М. © (2006-05-06 13:06) [22]

> Shirson © (06.05.06 12:39) [20]

Для поиска на предмет обнаружения последовательности символов в бин.файле Ворд вообще не нужен.

← →
Сергей М. © (2006-05-06 13:07) [23]

Равно как и компонент, его заменяющий.

← →
Shirson © (2006-05-06 13:19) [24]

Уже спотыкались.
В бин.файле вы не найдёте "последовательность" если она отформатирована как тут. Это самый простой пример.

← →
Jeer © (2006-05-06 13:31) [25]

Сергей М. © (06.05.06 13:06) [22]

Завтра MS вводит шифрацию файлов формата doc.
Че делаем ?

← →
Сергей М. © (2006-05-06 13:35) [26]

И для таких случаев Ворд тоже не обязателен.

???

Как скажешь.

> Jeer © (06.05.06 13:31) [25]

> Че делаем ?

Нет ничего тайного, что не могло бы стать явным.

Если так рассуждать, то можно сразу мылить веревку.

Я разработал или купил некое прикладное ПО, а завтра MS в очередной столохматой обнове к ОС объявила о прекращении поддержки некоей фичи, без которой работа моего ПО невозможна.

Че делать ?

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

> Jeer © (06.05.06 13:46) [29]

> идти штатными средствами MS

Такой выбор может когда-нибудь больно ударить.
Прикладной софт от самой MS, как бы ни был он очевиден в этом плане, зачастую попросту не надежен.

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

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

Offtop
"Лопату верни" (с) анекдот.

> Glum (05.05.06 10:30)

Могу предложить COM-сервер WCX (WordConverterX).
Продукт коммерческий, с исх.текстами.

С его помощью быстро и без проблем конвертишь doc-документ в любой из удобных тебе (из числа предлагаемых) текстовых форматов (plain text, html, xml и т.д.), после чего обрабатываешь уже результат конверсии - здесь уже полный простор для творчества.

← →
Glum (2006-05-06 22:48) [34]

Тема набирает обороты :)

Немного поясню мою задачу. Имеется большая база рефератов. Необходимо организовать сайт-магазин с возможностью поиска по ним. Раз это магазин, безопасней будет рефераты хранить на отдельной машине (не web-server). Получается что индексатор на одном компе записывает данные о рефератах в БД, а поисковик на другом компе (web-server"e) берет информацию из той же БД и выдает её пользователю.

2 Shirson
Мне нужно реализовать именно такую конструкцию которую вы описали. Не могли бы вы поделиться частью своего алгоритма индексирования? Или хотябы намекнуть :)

2 Сергей М.
Местоположение фрагмента не имеет значения, главное его наличие в файле.

Вообще мне кажется удобней для индексирования использовать Perl - это и проще и быстрее и регулярные выражения рулят, IMHO. Но то что Perl не может работать с doc заставило меня обратиться к Delphi. Сейчас наиболее удобной конструкцией я считаю связку "конвертер doc->txt написанный на Delphi" + "обработчик и индексатор получившегося txt на Perl". А может быть я изобретаю велосипед и конвертеры способные работать из консоли уже есть? Пока что я видел только catdoc, но он работает исключительно под nix.

← →
Glum (2006-05-06 23:07) [35]

2 TUser
Огромная благодарность за наводку! Кажется это то что мне нужно. Начинаю писать индексатор на Perl (да простят меня любители Delphi за вероотступничество).
Может кто-нибудь посоветовать эффективный алгоритм? Ато весь инет перерыл и ничего.

← →
ЛшдлуттнСфе (2006-05-06 23:09) [36]

низнаю насчет консоли, но есть
C:\Program Files\Common Files\Microsoft Shared\TextConv

Glum (06.05.06 22:48) [34]
> 2 Shirson
> Мне нужно реализовать именно такую конструкцию которую вы
> описали. Не могли бы вы поделиться частью своего алгоритма
> индексирования? Или хотябы намекнуть :)

Оно еще надо?

У меня была аналогичная задача - находить woed-файлы, содержащие определенные слова.
При добавлении или изменении документа делаю что-то типа этого:
uses word97; ............................... Word := TWord.Create; ............................... Word.Open(Name); Content := Word.GetText;
А Content можешь разбивать на слова и т.д.
У меня поиск получился более эффективным без разбития на слова.
Просто сохранял Content в Memo-поле и применял к нему регулярные выражения.

Индексация *.doc файлов Найти похожие ветки