Программирование проверки правописания: Hunspell
Содержание:
1.Часть I (Вы читаете данный раздел);
2. Часть II.
В этой статье пойдет речь о Hunspell (http://hunspell.sourceforge.net). Скажу сразу: если вам достаточно восьмибитных кодировок, поддерживаемых Aspell, от Hunspell особого проку не будет. Но тем программистам, которые приняли юникод как данность времени, ознакомиться с Hunspell - одно удовольствие. Ныне средства проверки правописания, предоставляемые Hunspell, задействованы в таких программах, как OpenOffice.org, Firefox, Opera, Google Chrome, The Bat! и TEA.
API Hunspell я буду показывать на примере интерфейса под C++, хотя он есть и для C. Разница, во-первых, в заголовочных файлах (hunspell.hxx для C++ и hunspell.h для C) и, конечно же, в коде. Для Си даются обычные функции, а для С++ - класс Hunspell. Всё описанное в этой статье, что не касается кода, относится к UNIX-подобным системам. Под Windows, а в частности Cygwin, мне совладать с Hunspell не удалось, даже несмотря на действия «по бумажке» (по руководству).
Чтобы при сборке вашей программы она «увидела» Hunspell, можно воспользоваться pkg-config. Для autotools это выглядит примерно так (прописываем в configure.in):
То есть, если библиотека найдена, добавляем все нужные для сборки параметры, а также определяем HUNSPELL_ SUPPORTED, чтобы потом в коде можно было написать:
Для сборочной системы qmake делаем так:
Экземпляр класса Hunspell создается следующим конструктором:
В общем случае нас интересуют здесь только два первых параметра:
- dpath - полный путь к файлу словаря;
- affpath - полный путь к так называемому аффиксному файлу. В нем содержатся различные указания, правила проверки правописания, то есть не просто грубый список слов (как обычный словарный файл dpath), а набор команд, внешне напоминающих язык ассемблера. У Hunspell есть целый макроязык для заданий таких правил правописания. В аффикс-ном файле также содержится и название кодировки словаря.
Раз и навсегда проясню положение с кодировками в Hunspell. Словари могут иметь любую кодировку. Внутренне Hunspell работает на основе UTF-8 и UTF-16 - в разных алгоритмах по-разному (например, при анализе - в UTF-8, а при «предположении» - в UTF-16). Пользовательский словарь должен иметь ту же кодировку, что и основной словарь для текущего языка. Работая с Hunspell, вы должны предоставлять его движку строки в кодировке словаря. Например, если словарь в KOI8-R, то вы должны передавать строки именно в KOI8-R. Кодировка задается в файле аффиксов, парном основному словарю. Пользовательский словарь не имеет такого парного файла. Узнать кодировку словаря можно с помощью API-функции char* get_dic_encoding() (она существует как отдельная функция для «сишного» интерфейса и как функция-член класса Hunspell). Память для возвращаемого ею значения освобождать не нужно.
Теперь вернемся к параметрам конструктора. Итак, файлы аффиксов и словаря. В том же Aspell мы не сталкивались с этим напрямую. Там были «общесистемные» словари, устанавливаемые через менеджер пакетов. Aspell заведовал словарями, предоставлял нам через API список доступных языков проверки правописания. В Hunspell такого нет. Словари доступны для скачивания с http://wiki.services.openoffice.org/wiki/Dictionaries. Еще можно использовать Hunspell-словари, установленные для других программ (скажем, OpenOffice.org или Firefox), только при этом у словарей будут разные имена файлов. Например, у словарей с официального сайта Hunspell имена подчинены некоему шаблону: en_US.aff, en_US.dic, ru_RU.aff, ru_RU.dic. Не составит труда написать код, который бы из списка таких файлов вычленял названия локалей, ставил им в соответствие название языка и предоставлял бы такой удобочитаемый список для графического интерфейса, чтобы пользователь мог выбрать нужный ему язык.
В данный момент Вас интересует не программирование проверки правописания посредством Hunspell, а установка и обслуживание 1С (http://mos1s.ru/uslugi-i-ceny-1c/obsluzhivanie-1s/) на ПК вашего предприятия? В таком случае Вам следует обратиться за помощью к опытным специалистам в данной сфере. На их роль идеально подойдут сотрудники компании «Программист 1С»!
1.
2. Часть II.
В этой статье пойдет речь о Hunspell (http://hunspell.sourceforge.net). Скажу сразу: если вам достаточно восьмибитных кодировок, поддерживаемых Aspell, от Hunspell особого проку не будет. Но тем программистам, которые приняли юникод как данность времени, ознакомиться с Hunspell - одно удовольствие. Ныне средства проверки правописания, предоставляемые Hunspell, задействованы в таких программах, как OpenOffice.org, Firefox, Opera, Google Chrome, The Bat! и TEA.
API Hunspell я буду показывать на примере интерфейса под C++, хотя он есть и для C. Разница, во-первых, в заголовочных файлах (hunspell.hxx для C++ и hunspell.h для C) и, конечно же, в коде. Для Си даются обычные функции, а для С++ - класс Hunspell. Всё описанное в этой статье, что не касается кода, относится к UNIX-подобным системам. Под Windows, а в частности Cygwin, мне совладать с Hunspell не удалось, даже несмотря на действия «по бумажке» (по руководству).
Чтобы при сборке вашей программы она «увидела» Hunspell, можно воспользоваться pkg-config. Для autotools это выглядит примерно так (прописываем в configure.in):
echo -n "checking for hunspell... "
if pkg-config —exists hunspell ; then
LIBS="$LIBS 'pkg-config --libs hunspell '" CFLAGS="$CFLAGS 'pkg-config --cflags hunspell '" AC _DEFINE(HUNSPELL_ SUPPORTED, 1, [HUNSPELL _ SUPPORTED]) echo "yes"
else
echo "no"
fi
if pkg-config —exists hunspell ; then
LIBS="$LIBS 'pkg-config --libs hunspell '" CFLAGS="$CFLAGS 'pkg-config --cflags hunspell '" AC _DEFINE(HUNSPELL_ SUPPORTED, 1, [HUNSPELL _ SUPPORTED]) echo "yes"
else
echo "no"
fi
То есть, если библиотека найдена, добавляем все нужные для сборки параметры, а также определяем HUNSPELL_ SUPPORTED, чтобы потом в коде можно было написать:
#ifdef HUNSPELL _ SUPPORTED //код с поддержкой Hunspell #endif
Для сборочной системы qmake делаем так:
CONFIG += link _ pkgconfig
exists("/usr/include/hunspell/hunspell.hxx") {
message ("hunspell enabled")
PKGCONFIG += hunspell
DEFINES += HUNSPELL _ SUPPORTED
}
exists("/usr/include/hunspell/hunspell.hxx") {
message ("hunspell enabled")
PKGCONFIG += hunspell
DEFINES += HUNSPELL _ SUPPORTED
}
Экземпляр класса Hunspell создается следующим конструктором:
Hunspell (const char *affpath, const char *dpath, J const char *key = NULL);
В общем случае нас интересуют здесь только два первых параметра:
- dpath - полный путь к файлу словаря;
- affpath - полный путь к так называемому аффиксному файлу. В нем содержатся различные указания, правила проверки правописания, то есть не просто грубый список слов (как обычный словарный файл dpath), а набор команд, внешне напоминающих язык ассемблера. У Hunspell есть целый макроязык для заданий таких правил правописания. В аффикс-ном файле также содержится и название кодировки словаря.
Раз и навсегда проясню положение с кодировками в Hunspell. Словари могут иметь любую кодировку. Внутренне Hunspell работает на основе UTF-8 и UTF-16 - в разных алгоритмах по-разному (например, при анализе - в UTF-8, а при «предположении» - в UTF-16). Пользовательский словарь должен иметь ту же кодировку, что и основной словарь для текущего языка. Работая с Hunspell, вы должны предоставлять его движку строки в кодировке словаря. Например, если словарь в KOI8-R, то вы должны передавать строки именно в KOI8-R. Кодировка задается в файле аффиксов, парном основному словарю. Пользовательский словарь не имеет такого парного файла. Узнать кодировку словаря можно с помощью API-функции char* get_dic_encoding() (она существует как отдельная функция для «сишного» интерфейса и как функция-член класса Hunspell). Память для возвращаемого ею значения освобождать не нужно.
Теперь вернемся к параметрам конструктора. Итак, файлы аффиксов и словаря. В том же Aspell мы не сталкивались с этим напрямую. Там были «общесистемные» словари, устанавливаемые через менеджер пакетов. Aspell заведовал словарями, предоставлял нам через API список доступных языков проверки правописания. В Hunspell такого нет. Словари доступны для скачивания с http://wiki.services.openoffice.org/wiki/Dictionaries. Еще можно использовать Hunspell-словари, установленные для других программ (скажем, OpenOffice.org или Firefox), только при этом у словарей будут разные имена файлов. Например, у словарей с официального сайта Hunspell имена подчинены некоему шаблону: en_US.aff, en_US.dic, ru_RU.aff, ru_RU.dic. Не составит труда написать код, который бы из списка таких файлов вычленял названия локалей, ставил им в соответствие название языка и предоставлял бы такой удобочитаемый список для графического интерфейса, чтобы пользователь мог выбрать нужный ему язык.
В данный момент Вас интересует не программирование проверки правописания посредством Hunspell, а установка и обслуживание 1С (http://mos1s.ru/uslugi-i-ceny-1c/obsluzhivanie-1s/) на ПК вашего предприятия? В таком случае Вам следует обратиться за помощью к опытным специалистам в данной сфере. На их роль идеально подойдут сотрудники компании «Программист 1С»!
