Повышаю. Regex обеспечивает широкую поддержку локализации во время выполнения, используемая модель локализации может быть разделена на две части: front-end и back-end.

Фронтальная локализация имеет дело со всем, что видит пользователь — сообщениями об ошибках и синтаксисом регулярного выражения. Например, французское приложение может изменить [[:word:]] на [[:mot:]] и \w на \m. Модификация локала переднего конца требует активной поддержки со стороны разработчика, предоставляя библиотеке каталог сообщений для загрузки, содержащий локализованные строки. Локальность интерфейса зависит только от категории LC_MESSAGES.

Обратная локализация имеет дело со всем, что происходит после разбора выражения — другими словами, со всем, что пользователь не видит или не взаимодействует напрямую. Он имеет дело с преобразованием случая, коллацией и членством в классе персонажей. Бэкэнд-локаль не требует какого-либо вмешательства со стороны разработчика - библиотека будет получать всю информацию, необходимую для текущего местоположения, из базовой операционной системы / библиотеки времени выполнения. Это означает, что если пользователь программы не взаимодействует с регулярными выражениями напрямую — например, если выражения встроены в ваш код C++ — то явной локализации не требуется, так как библиотека позаботится обо всем за вас. Например, встраивание выражения [[:word:]]+ В вашем коде всегда будет совпадать целое слово, если программа запускается на машине с, например, греческим локалом, то она все равно будет соответствовать целому слову, но в греческих символах, а не в латинских. Бэкэнд-локальность зависит от LC_TYPE и LC_. Собрать категории.

Существует три отдельных механизма локализации, поддерживаемых Boost. Регекс:

Win32 localization model.

Это модель по умолчанию, когда библиотека компилируется под Win32 и инкапсулируется классом признаков w32_regex_traits. Когда эта модель действует, каждый объект basic_regex получает свой собственный LCID, по умолчанию это настройка по умолчанию пользователя, возвращенная GetUserDefaultLCID, но вы можете вызвать imbue на объекте basic_regex, чтобы установить его местоположение на какой-либо другой LCID, если хотите. Все настройки, используемые Boost. Regex приобретается непосредственно из операционной системы в обход библиотеки времени выполнения C. Фронтальная локализация требует ресурса dll, содержащего строковую таблицу с определяемыми пользователем строками. Класс признаков экспортирует функцию:

static std::string set_message_catalogue(const std::string& s);

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

boost::w32_regex_traits<char>::set_message_catalogue("mydll.dll");

Библиотека обеспечивает полную поддержку Unicode под NT, под Windows 9x библиотека изящно деградирует — поддерживаются символы от 0 до 255, остальные рассматриваются как «неизвестные» графические символы.

C localization model.

Эта модель была отклонена в пользу локального языка C++ для всех компиляторов, не поддерживающих Windows. Эта локализация инкапсулирована классом признаков c_regex_traits, пользователи Win32 могут заставить эту модель вступить в силу, определив предпроцессорный символ BOOST_REGEX_USE_C_LOCALE. Когда эта модель действует, существует единая глобальная локальность, установленная setlocale. Все настройки приобретаются из вашей библиотеки времени выполнения, поэтому поддержка Unicode зависит от реализации вашей библиотеки времени выполнения.

Локализация переднего края не поддерживается.

Обратите внимание, что вызов setlocale делает недействительными все скомпилированные регулярные выражения, вызов setlocale(LC_ALL, "C") сделает эту библиотеку эквивалентной большинству традиционных библиотек регулярных выражений, включая версию 1 этой библиотеки.

C++ localization model.

Эта модель является стандартной для компиляторов, не относящихся к Windows.

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

static std::string set_message_catalogue(const std::string& s);

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

boost::cpp_regex_traits<char>::set_message_catalogue("mycatalogue");

Обратите внимание, что вызов basic_regex<>::imbue сделает недействительным любое выражение, составленное в данном случае basic_regex.

Наконец, обратите внимание, что если вы создаете библиотеку с моделью локализации без по умолчанию, то соответствующий символ препроцессора (BOOST_REGEX_USE_CPP_LOCALE или BOOST_REGEX_USE_CPP_LOCALE) должен быть определен как при создании библиотеки поддержки, так и при включении boost/regexregex.boostcregex.hpp> в ваш код. Лучший способ обеспечить это - добавить #define к <boost/regex/user.hpp>.

Providing a message catalogue

Чтобы локализовать переднюю часть библиотеки, необходимо предоставить библиотеке соответствующие строки сообщений, содержащиеся либо в таблице строк ресурса dll (модель Win32), либо в каталоге сообщений POSIX (модели C++). В последнем случае сообщения должны отображаться в сообщении, установленном нулем каталога. Сообщения и их идентификаторы следующие:

Пользовательские сообщения об ошибках загружаются следующим образом:

Пользовательские имена классов символов загружаются следующим образом:

И, наконец, пользовательские имена элементов коллаборации загружаются, начиная с идентификатора 400 сообщения, и заканчивая, когда первая загрузка после этого выходит из строя. Каждое сообщение выглядит примерно так: «tagname string», где tagname — это имя, используемое внутри [.tagname.], а string — фактический текст коллатингового элемента. Обратите внимание, что значение коллатингового элемента используется для преобразования строк в числа - если вы замените это другим значением, то это будет использоваться для парсинга строк - например, используйте символ Unicode 0x0660 для [.zero.], если вы хотите использовать арабо-индийские цифры Unicode в ваших регулярных выражениях вместо латинских цифр.

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