Журнал LinuxFormat - перейти на главную

LXF100-101:Урок грамматики

Материал из Linuxformat
Версия от 12:39, 6 апреля 2009; Crazy Rebel (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Aspell и Enchant Снабдите свои программы функцией проверки орфографии

Содержание

Очепятки не пройдут

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


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

На этом уроке мы не будем задаваться столь философскими вопросами, а просто рассмотрим, как задействовать движок проверки правописания Aspell в своих программах. Мы будем использовать API для языка С, а для большей наглядности практического применения ряд примеров будет дан с привязкой к GTK+ (мы публиковали серию статей о нем в период с LXF86 по LXF95, так что вы найдете все эти уроки на LXFDVD), однако, изложенные общие принципы работы применимы к любой библиотеке. В конце материала будет уделено немного места еще одному движку – Enchant, для сравнения. Также обратите внимание на Hunspell – он уже используется в OpenOffice.org, а со временем должен заменить MySpell и в продуктах Mozilla.

ЧАСТЬ 1: GNU Aspell

Aspell (http://aspell.net) – один из самых популярных движков проверки орфографии. Он состоит из консольной программы (которой, помимо прочего, можно передавать данные через канал), а также библиотеки с «сишным» API, хотя сам Aspell написан на С++. Работы с каналами мы касаться не будем.

Описанию API в документации Aspell уделено мало внимания – несколько примеров да примечания. Чтобы использовать Aspell в своей программе, надо изучить его исходные тексты – причем не только заголовочные файлы. Но сначала не будет излишним прочесть эту статью.

Начнем с проверки, установлена ли LibAspell в системе пользователя, и включения ее в параметры компилятора. По какой-то причине библиотека не оснащена модулем для pkg-config, поэтому искать pc-файл бесполезно. Вместо этого, в случае Autotools, следует добавить в файл configure.in (который будет обработан autogen.sh для создания скрипта configure) макросы для проверки наличия заголовочного файла aspell.h: 

 AC_CHECK_HEADER(aspell.h,
        LIBS=”$LIBS -laspell”
        AC_DEFINE(HAVE_LIBASPELL, 1, [use aspell]),
            [AC_MSG_ERROR([cannot find header for libaspell])]
        )

Напомню формат макроса AC_CHECK_HEADERS: 

AC_CHECK_HEADERS (имя заголовочного файла, [действие в положительном случае], [действие в отрицательном])

Итак, мы проверяем, есть ли в системе файл aspell.h. Если есть, то в файле config.h определяется флаг HAVE_LIBASPELL, чтобы потом в коде программы мы могли написать что-то вроде: 

 #ifdef HAVE_LIBASPELL
 #include “aspell.h”
 #endif

В приведенном выше примере, для вывода сообщения об ошибке был использован макрос AC_MSG_ERROR. Помимо прочего, он вызывает прекращение работы сценария configure. То есть, если aspell.h не была найден, то и настройка исходных текстов будет провалена. Если такое поведение нежелательно, а наличие aspell.h – необязательное условие для сборки вашей программы, то проверка может выглядеть немного иначе: 

 AC_CHECK_HEADER(aspell.h,
            LIBS=”$LIBS -laspell”
            AC_DEFINE(HAVE_LIBASPELL, 1, [use aspell]),
                         echo “aspell.h not found”
            )

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

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

 AspellConfig *config = new_aspell_config ();

После окончания работы его надо будет удалить при помощи функции delete_aspell_config(). Значения полей в классе можно менять при помощи функции aspell_config_replace(). Формат вызова таков: 

aspell_config_replace (config, имя переменной-поля, новое значение);

Давайте для примера настроим класс под русскую локаль и кодировку UTF-8: 

 aspell_config_replace (config, “lang”, “ru”);
 aspell_config_replace (config, “encoding”, “UTF-8”);

Замечу, что у пользователя может быть другая локаль, тогда ваше ‘ru’ будет бесполезным. Поэтому лучше определить локаль программно. Для этого нужно прочитать значение переменной окружения ‘LANG;. В GTK+ это делается вот так: 

 gchar *lang = g_getenv (“LANG”);
 if (lang)
    aspell_config_replace (config, “lang”, lang);
 else
    aspell_config_replace (config, “lang”, “C”);
 aspell_config_replace (config, “encoding”, “UTF-8”);

Если, вдруг, переменная ‘LANG’ не установлена, то мы используем значение ‘C’ (стандартная англоязычная локаль). Что до кодировки, то указывая UTF-8, мы сообщаем движку Aspell, какую кодировку будем использовать для обмена данными с ним. Изнутри Aspell восьмибитный, но мы можем передавать ему текст в UTF-8 и получать его обратно тоже в UTF-8. Полученным текстом может быть, например, список предположительно правильных написаний для данного (переданного в параметре функции проверки) слова. Конечно, никто не мешает вам использовать другую кодировку, но в современных условиях UTF-8 – лучшая, если ваша библиотека виджетов ее поддерживает.

Еще одна подробность – в указанной вами кодировке Aspell будет сохранять новые слова в пользовательском словаре. Aspell создает такие словари в отдельных файлах (по одному на каждый использованный языковый модуль – то есть на тот модуль, куда было виртуально добавлено слово). Файлы эти лежат в домашнем каталоге пользователя. Например, имя файла с пользовательским словарем для русского языка – ~/.aspell.ru.pws.

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

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

 const AspellDictInfo *entry;
 AspellConfig *config = new_aspell_config ();
 AspellDictInfoList *dlist = get_aspell_dict_info_list (config);
 AspellDictInfoEnumeration *dels = aspell_dict_info_list_elements (dlist);
 while ((entry = aspell_dict_info_enumeration_next (dels)) != 0)
      if (entry)
         printf (“%s\n”, entry->name);
 delete_aspell_dict_info_enumeration (dels);
 delete_aspell_config (config);

Итогом работы этого кода будет нечто вроде: 

ru
en
en_CA

и так далее.

Полученные названия можно использовать в aspell_config_replace(), чтобы установить локаль движка Aspell: 

aspell_config_replace (config, “lang”, локаль);

Теперь у нас есть все знания для того, чтобы настроить язык и кодировку. Но этого мало. Надо создать на основе этих данных экземпляр класса, отвечающего за проверку орфографии. Для этого API предоставляет нам две функции, которые мы рассмотрим подробно: 

 struct AspellCanHaveError* new_aspell_speller (struct AspellConfig *config);
 struct AspellSpeller* to_aspell_speller (struct AspellCanHaveError *obj);

Внутри первой функции происходят любопытные вещи. Aspell, как уже упоминалось выше, написан на С++, и «сишной» структуре AspellCanHaveError соответствует внутренний класс CanHaveError, а AspellSpeller – класс Speller. Итак, функция new_aspell_speller() создает экземпляр класса Speller. В случае ошибки new_aspell_speller() возвращает экземпляр CanHaveError. В противном же случае возвращается Speller, которого нужно «вытащить» из CanHaveError функцией to_aspell_speller(). Я понимаю, что API можно было сделать более логичным.

Вот пример. Сначала вызываем new_aspell_speller: 

 AspellCanHaveError *possible_err = new_aspell_speller(spell_config);

На этом этапе мы не знаем, что вернулось в possible_err на самом деле – экземпляр AspellCanHaveError или AspellSpeller. Поэтому объявляем spell_checker и проверяем possible_err – то есть вернулась ли ошибка. Если да, то печатаем сообщение об ошибке, а если нет, то функцией to_aspell_speller приводим possible_err к типу AspellSpeller. 

 AspellSpeller *spell_checker;
 if (aspell_error_number (possible_err) != 0)
     printf (“%s\n”, aspell_error_message (possible_err));
 else
    spell_checker = to_aspell_speller (possible_err);

Пара слов об освобождении памяти. Память для AspellCanHaveError освобождается с помощью функции delete_aspell_can_have_error(), а для AspellSpeller – delete_aspell_speller(). В приведенном выше коде, будь он в рабочей программе, освобождать память следовало бы так. Если вернулся экземпляр AspellSpeller, то память для AspellCanHaveError уже не нужно освобождать, потому что на самом-то деле в possible_err хранится не экземпляр AspellCanHaveError, а экземпляр AspellSpeller, и вызовы обеих функций уничтожения объекта приведут к ошибке сегментации во второй из них.

Лучший вариант работы с памятью таков. Если вернулся AspellCanHaveError – выполняем для него delete_aspell_can_have_error() и завершаем код проверки орфографии. Если вернулся AspellSpeller, то проверяем орфографию и очищаем память с помощью delete_aspell_speller(), однако delete_aspell_can_have_error() для possible_err уже НЕ вызываем.

Тонкая красная линия

Получив на руки работоспособный экземпляр AspellSpeller, мы, наконец, можем проверить написание слова. Для этого служит функция aspell_speller_check(): 

 int aspell_speller_check (struct AspellSpeller *speller, const char *word, int word_size);

Она возвращает нулевое значение, если слова нет в словаре, 1 – если есть, и -1 в случае возникновения ошибки (в движке). То есть в рабочем коде, если нам нужно просто проверить, есть слово в словаре или нет, и нас не волнует возможная внутренняя ошибка, то можно писать так: 

 if (! aspell_speller_check (параметры)) {
    делаем что-то - например, подчеркиваем ошибочное слово
 }

Рассмотрим параметры функции поподробнее. Со speller’ом все понятно. Слово word, передаваемое для проверки, должно быть в той кодировке, которую вы задали для словарного модуля. word_size – размер (в байтах) этого слова, может быть -1, если мы имеем дело со строкой, завершающейся нулем (‘\0’). Обычно так оно и есть.

Попробуем Aspell в деле. Как проверить орфографию в стандартном виджете текстового редактора GTK+ (да и в GtkSourceView, см. LXF97)?

Как вы, наверное, знаете, изменение атрибутов участков текста в GtkTextView осуществляется с помощью объектов-тэгов. Тэг несет в себе параметры шрифта, цвет и так далее. Тэги хранятся в таблице, которая подключается к GtkTextBuffer (именно к буферу, а не к GtkTextView). Сначала надо создать таблицу, а затем поместить в нее тэг.

Давайте создадим пустую таблицу: 

 GtkTextTagTable *tags_table = gtk_text_tag_table_new ();

Затем создадим тэг, которым будем подсвечивать ошибочные слова: 

 GtkTextTag *tag_spell_err = gtk_text_tag_new (“spell_err”);

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

 g_object_set (G_OBJECT (tag_spell_err), “foreground”, “red”, NULL);
 g_object_set (G_OBJECT (tag_spell_err), “underline”, PANGO_UNDERLINE_NORMAL, NULL);

В данном примере мы использовали стиль PANGO_UNDERLINE_NORMAL – обычное подчеркивание прямой линией. Но в библиотеке Pango, начиная с версии 1.4, появился стиль PANGO_UNDERLINE_ERROR, созданный специально для подчеркивания ошибок (волнистая линия мелким зигзагом). Как написать код, проверяющий версию Pango и устанавливающий стиль подчеркивания в зависимости от нее? А вот так: 

 #if defined(PANGO_VERSION_CHECK) && PANGO_VERSION_CHECK(1,4,0)
 g_object_set (G_OBJECT (tag_spell_err), “underline”, PANGO_UNDERLINE_ERROR, NULL);
 #else
 g_object_set (G_OBJECT (tag_spell_err), “underline”, PANGO_ UNDERLINE_SINGLE, NULL);
 #endif

Теперь тэг можно поместить в таблицу: 

gtk_text_tag_table_add (tags_table, tag_spell_err);

Создадим отдельный текстовый буфер с указанной таблицей тэгов: 

GtkTextBuffer *text_buffer = gtk_text_buffer_new (tags_table);

У GtkTextView уже есть буфер по умолчанию. Заменим его на новый буфер с нашей таблицей тэгов: 

gtk_text_view_set_buffer (text_view, text_buffer);

Альтернативный вариант вариант – не создавать свой буфер и таблицу, а получить указатель на уже существующий буфер с помощью функции gtk_text_buffer_get_tag_table(), и добавить тэг в полученную таблицу. Решение зависит от вас и от архитектуры вашей программы.

Приведем код, отвечающий непосредственно за проверку содержимого текстового буфера на ошибки: 

 GtkTextIter iter;
 GtkTextIter a;
 GtkTextIter b;
 gchar *p = NULL;
 gchar *text;
 gtk_text_buffer_get_iter_at_offset (text_buffer, &iter, 0);
 if (gtk_text_iter_starts_word (&iter))
      a = iter;
 do
   {
     if (gtk_text_iter_starts_word (&iter))
        {
          b = iter;
          if (gtk_text_iter_backward_char (&b))
              a = iter;
          if (gtk_text_iter_forward_word_end (&iter))
              if (gtk_text_iter_ends_word (&iter))
                 {
                   text = gtk_text_iter_get_slice (&a, &iter);
                   if (text)
                      {
                        if (g_utf8_strlen (text, -1) > 1)
                           {
                             if (! aspell_speller_check (text_buffer, text, -1))
                                {
                                  gtk_text_buffer_apply_tag (text_buffer, gtk_text_tag_
 table_lookup(gtk_text_buffer_get_tag_table (text_buffer), “spell_err”), &a, &iter);
                                    g_free (text);
                                    continue;
                                  }
                             }
                          g_free (text);
                        }
                   }
            }
        }
 while (gtk_text_iter_forward_char (&iter));
 }

Неплохо, правда? Вначале мы получаем итератор iter, указывающий на начало буфера. Также у нас есть вспомогательные итераторы a и b, которых мы используем для более точного последовательного перебора букв в буфере. Перебирая в цикле один символ за другим, мы получаем слова. Текст каждого слова помещаем в переменную text и передаем эту переменную в функцию aspell_speller_check(). Если слова нет в словаре, то применяем цветовой тэг к участку в буфере, отмеченному итераторами, которые ограничивают текущее слово. Тэг применяется с помощью функции gtk_text_buffer_apply_tag(). Этой функции передаются следующие параметры: text_buffer – текстовый буфер, указатель на тэг. Его мы извлекаем по имени из таблицы тэгов, которая назначена данному буферу. Делается это так: 

gtk_text_tag_table_lookup(gtk_text_buffer_get_tag_table (text_buffer), “spell_err”)

Оставшиеся два параметра – итераторы, задающие начало и конец отмечаемого тэгом участка в буфере. Вот вам задача для самостоятельного решения: перед вызовом кода подчеркивания ошибок надо убрать возможное прежнее подчеркивание, ведь есть вероятность, что пользователь уже проверял орфографию, а затем исправил некоторые слова. Поэтому, прежде чем заново подчеркивать ошибки, найдите в буфере все тэги с именем “spell_err” и удалите их.

Помощь зала

Помимо того, что Aspell может сообщить вам о наличии или отсутствии слова в словаре, он также дает список возможных вариантов верного написания предложенного слова. В приведенном ниже коде предполагается, что ошибочное слово хранится в переменной error_word: 

 AspellWordList *suggestions = aspell_speller_suggest (speller, error_word, -1);
 if (! suggestions)
    ; //например, выходим по return
 //иначе получаем список предположений:
 AspellStringEnumeration *elements = aspell_word_list_elements
 (suggestions);
 const char *word;
 //и перебирая их (elements) по одному, печатаем в консоль:
 while (word = aspell_string_enumeration_next (elements))
        printf (“%s \n”, word);
 //удаляем объект:
 delete_aspell_string_enumeration (elements);

Не буду вдаваться в подробности внутреннего устройства этих функций – скажу лишь, что API можно было сократить наполовину. Память, полученную от aspell_speller_suggest(), освобождать не нужно – возвращается указатель на const. Объект доступен до следующего вызова вышеупомянутой функции.

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

 aspell_speller_add_to_personal (speller, word, strlen (word));
 aspell_speller_save_all_word_lists (speller);

Размер слова указывается в байтах, поэтому годится обычная strlen, даже если слово у вас хранится в UTF-8. И не забывайте вызывать aspell_speller_save_all_word_lists(), иначе слово хотя и добавитсяв текущую сессию проверки орфографии, но не будет сохранено в словарном файле.

ЧАСТЬ 2: Enchant

Enchant – побочный продукт разработчиков AbiWord (http://www.abisource.com/enchant). Собственно говоря, это и не движок сам по себе, а программная прослойка, предоставляющая доступ к другим движкам проверки орфграфии, как-то: Aspell, ISpell, MySpell, Uspell, Hspell, AppleSpell и Hunspell. Разработчики позаботились об удобном подключении библиотеки при компиляции – то бишь предоставили пакет для pkg-config. Поэтому, чтобы проверить наличие библиотеки и подключить ее к своей программе, надо добавить в configure.in примерно следующее: 

 echo -n “checking for enchant... “
 if pkg-config --exists enchant ; then
              LIBS=”$LIBS `pkg-config --libs enchant `”
              CFLAGS=”$CFLAGS `pkg-config --cflags enchant `”
              AC_DEFINE(ENCHANT_SUPPORTED, 1, [ENCHANT_
 SUPPORTED])
              echo “yes”
 else
              echo “no”
 fi
        Ну, а в коде программы:
 #ifdef ENCHANT_SUPPORTED
 #include “enchant.h”
 #endif

Общение с Enchant происходит в кодировке UTF-8, вам не нужно указывать это напрямую. Инициализация словаря выполняется просто: 

 EnchantBroker *broker = enchant_broker_init ();
 EnchantDict *dict = NULL;
 gchar *lang = g_getenv (“LANG”);
 if (lang)
    dict = enchant_broker_request_dict (broker, lang);

Вначале создается брокер, у которого запрашиваем словарь: брокер ими заведует. В приведенном выше примере мы просим у брокера: «Дай нам словарь для языка текущей локали». Но ведь известно, что Enchant поддерживает одновременно несколько движков проверки орфографии. Стало быть, Enchant даст нам (прозрачно, разумеется) тот движок, в котором установлен модуль проверки нужного нам языка. Но что если такой модуль есть для нескольких движков? Например, для Aspell и MySpell? Для этих целей существует файл /usr/share/Enchant/Enchant.ordering, в котором задаются приоритеты движков. Расположение этого файла у вас может быть иным – всё зависит от того, где установлен Enchant. Может также существовать аналогичный пользовательский файл, хранящийся в ~/.enchant.

Далее, где именно Enchant ищет словари? Смотря какие. Для MySpell, Ispell, и Uspell по умолчанию – в подкаталогах /usr/share/enchant (опять же, у вас может быть иначе). Например, словарь MySpell ищется в /usr/share/enchant/myspell. Что до Aspell, то к нему Enchant ищет «общие» словари, без всякой привязки к конкретной установке.

Для проверки слова на правильность написания надо использовать следующую функцию: 

 int
 enchant_dict_check (EnchantDict *dict, const char *const word, ssize_tlen)

Она возвращает 0, если слово присутствует в словаре, положительное значение – если слова там нет, и отрицательное в случае внутренней ошибки движка. Параметры функции: dict – экземпляр словаря, word – передаваемое для проверки слово (в UTF8), len – длина этого слова в байтах, можно использовать strlen либо значение -1, если строка завершается нулем.

Получение списка предположительно верных написаний слова: 

 size_t out_n_suggs;
 gchar **words = enchant_dict_suggest (dict, s, -1, &out_n_suggs);

Здесь слова-предположения помещаются в строковой массив words. Количество элементов массива возвращается в переменной out_n_suggs. А чтобы освободить память, отведенную под этот массив, нужно сделать так: 

enchant_dict_free_string_list (dict, words);

Наконец, после работы с брокером и словарем нужно тоже очищать память: 

 if (dict)
    enchant_broker_free_dict (broker, dict);
 if (broker)
    enchant_broker_free (broker);

Легко видеть, что API у Enchant более простое, чем у Aspell. Использование того или иного движка зависит от программы. Мне кажется, что наилучшее решение – это поддержка сразу нескольких движков в зависимости от того, какие из них установлены. Собственно, этим и занимается Enchant, но Aspell более традиционен для Linux и работает «из коробки» в большинстве дистрибутивов. Кроме того, даже при наличии Enchant, Aspell с его 70 словарями наверняка будет использоваться тем же Enchant в качестве движка. LXF

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF100-101:%D0%A3%D1%80%D0%BE%D0%BA_%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B8&oldid=7531»
Персональные инструменты
купить
подписаться
Яндекс.Метрика