Всем рано или поздно приходится работать с различными кодировками. Заметив в коде своей команды различные, порой странные, подходы к решению этих проблем, пришлось провести разъяснительную беседу. Ниже поделюсь своим видением правильной работы с не-ASCII символами в коде. Буду рад конструктивной критике.
Принцип работы
Логика работы с различными кодировками в C++ проста и прозрачна. В общем виде она отражена в схеме. Программа работает в одной — своей внутренней кодировке, а правильно локализованные потоки отвечают за преобразование кодировки данных из внешнего кода во внутренний и обратно. Внутреннюю кодировку программы лучше всего зафиксировать раз и навсегда. Если программа работает с не-ASCII символами, то самый логичный выбор для внутренней кодировки — Юникод, причём использование UTF-8 и char для параметризации STL как правило неоправданно (хотя существуют ситуации, в которых это необходимо); более логично перейти на расширенные символы wchar_t и использовать UCS-2. За преобразование данных из внешней кодировки во внутреннюю отвечает фасет codecvt. Локализованные потоки сами вызовут соответствующие функции фасета при получении данных (о том кто такие фасеты я писал ранее).
Вышесказанное поясню комментированным примером, в котором прочитаем данные из cp1251 файла, покажем как boost::xpressive работает с юникодом и выведем кириллицу в cout в кодировке cp866 (консоль windows по умолчанию).
Кодировка исходников
Прежде чем приступить к рассмотрению примера, следует (на всякий случай) пару слов сказать о кодировке исходных текстов программы. Все свои исходники я держу в UTF-8 (если они содержат широкие строковые константы с не-ASCII символами, то в файлы добавляю BOM), что и всем советую. Современные компиляторы сами преобразуют «широкие» символы, помеченные в исходниках как L"" в UCS-2 (или UCS-4). Понятно, что правильное преобразование зависит от кодировки исходников. gcc по-умолчанию считает, что работает с UTF-8 текстом, чтобы его переубедить придётся специально указывать значение параметра -finput-charset. Компилятору от MS нужно немножечко помочь — добавить в UTF-8 файл BOM (Byte Order Mark). К сожалению у Borland C++ Compiler version 5.5 с UTF-8 проблемы.
Для тех, кто собрался кинуть в меня камень поясню два момента: первый — мне не удобно читать код с «unicode escape» типа:
std::wstring wstr(L"\u0410\u0411\u0412\u0413\u0413");
второй — речь идёт не только об интерфейсе пользователя, поэтому вынести все широкие строковые константы в отдельный модуль и как-то с ними работать (наподобие gettext), не вариант.Итак решено — исходники в UTF-8 с BOM. Если кто не знает, в vim BOM можно добавить к файлу с помощью команды «set bomb». Если BOM в файле уже есть vim его никуда не денет.
Пример работы с различными кодировками
Ну вот и подобрались к самому интересному. Как я и говорил, код простой и понятный. Маленькое замечание по стандартным потокам — по умолчанию фасеты для них не задействуются так как они синхронизированы с stdio для производительности. Следует указать sync_with_stdio(false).
#include <boost/xpressive/xpressive.hpp> #include <locale> #include <fstream> #include <iostream> #include <iterator> #include "codecvt_cp866.hpp" #include "codecvt_cp1251.hpp" #include "unicyr_ctype.hpp" using namespace std; using namespace boost::xpressive; int main() { // Пусть имеется файл input.txt в кодировке cp1251, содержащий банальный // "Привет, мир!" ofstream ofile("input.txt", std::ios::binary); ostreambuf_iterator<char> writer(ofile); writer = 0xCF; // П ++writer = 0xF0; // р ++writer = 0xE8; // и ++writer = 0xE2; // в ++writer = 0xE5; // е ++writer = 0xF2; // т ++writer = 0x2C; // , ++writer = 0x20; // ++writer = 0xEC; // м ++writer = 0xE8; // и ++writer = 0xF0; // р ++writer = 0x21; // ! ofile.close(); // Читаем файл wifstream ifile("input.txt"); // Локаль для ввода locale cp1251(locale(""), new codecvt_cp1251<wchar_t, char, mbstate_t>); ifile.imbue(cp1251); wchar_t wstr[14]; ifile.getline(wstr, 13); // Стандарт C++ предписывает синхронизировать cout, cin, cerr и // clog, как и их расширенные варианты с stdio, поэтому поумолчанию // для этих потоков фасет не будет задействован (во всяком случае при // компиляции gcc, msvc 7 не особо придерживается стандартов). Следует // сообщить ios, что мы не будем синхронизироваться с stdio. ios_base::sync_with_stdio(false); // Локаль для вывода locale cp866(locale(""), new codecvt_cp866<wchar_t, char, mbstate_t>); // Сообщаем потоку, что перед выводом необходимо выполнять // преобразование wcout.imbue(cp866); // Локаль с правильным ctype locale cyrr(locale(""), new unicyr_ctype); wsregex_compiler xpr_compiler; xpr_compiler.imbue(cyrr); wsregex xpr = xpr_compiler.compile(L"МИР", regex_constants::icase); wsmatch match; if(regex_search(wstring(wstr), match, xpr)) wcout << L"icase сработал" << endl; else wcout << L"icase не сработал" << endl; return 0; }
Фасет codecvt для преобразования кириллицы из cp1251 в ucs-2 и обратно
#include <locale> #include <map> /**@brief Фасет codecvt для преобразования символов кириллицы из cp1251 * в UCS-2 и обратно * * Фасет хорошо описан в книге Страуструпа (3-е специальное издание - * приложение). Темным пятном является лишь третий параметр шаблона - * состояние. Дело в том, что фасет codecvt спроектирован для работы с * потоками байт. Символ может представлять собой последовательность из * нескольких байт. В случае, если мы получили только часть байт, * составляющих символ, мы не можем преобразовать его. Необходимые байты * могут быть получены в следующий вызов функций преобразования. State * таким образом выступает в качестве объекта, в который мы сохраняем * информацию о текущем неполном преобразовании для того, чтоб ее можно * было бы сообщить следующему вызову функции преобразования. */ template<class I, class E, class State> class codecvt_cp1251 : public std::codecvt<I, E, State> { public: // результат выполнения операции преобразования typedef typename std::codecvt_base::result result; const result ok, // преобразовано partial, // преобразовано частично (см описание State) error, // произошла ошибка noconv; // не преобразовано explicit codecvt_cp1251(size_t r=0) : std::codecvt<I, E, State>(r), ok(std::codecvt_base::ok), partial(std::codecvt_base::partial), error(std::codecvt_base::error), noconv(std::codecvt_base::noconv) { // расширенные символы кириллицы - см стандарт in_tab[0xA8] = 0x401; out_tab[0x401] = 0xA8; in_tab[0xB8] = 0x451; out_tab[0x451] = 0xB8; // ... остальные коды } ~codecvt_cp1251() { } protected: /**@brief Выполняет преобразование из внешней кодировки во внутреннюю * строки from-from_end, записывая результат в строку in-in_end.*/ virtual result do_in(State&, const E* from, const E* from_end, const E* &from_next, I* to, I* to_end, I* &to_next) const { while(from != from_end) { if(to == to_end) { from_next = ++from; to_next = to; return partial; } // ASCII if(0 <= *from && *from <= 0x7F) { *to = static_cast<I>(*from); } else if(0xC0 <= static_cast<unsigned char>(*from) && static_cast<unsigned char>(*from) <=0xFF) { *to = static_cast<I>(static_cast<unsigned char>(*from) + 0x350); } else { typename std::map<E, I>::const_iterator s; s = in_tab.lower_bound(*from); if(s == in_tab.end()) { // ранее мы удостоверились, что from и next не последние from_next = ++from; to_next = ++to; return error; } *to = s->second; } ++to; ++from; } from_next = from_end; to_next = to; return ok; } /**@brief Если преобразования не нужны, возвращает true*/ virtual int do_encoding() const throw() { return 1; } /**@brief Если преобразования не нужны, возвращает true*/ virtual bool do_always_noconv() const throw() { return false; } /* не будем усложнять пример virtual result do_out(State&, const I* from, const I* from_end, const I* &from_next, E* to, E* to_end, E* &to_next); virtual int do_length(State& s, const E* from, const E* from_end, size_t max) const; virtual int do_max_length() const throw(); */ private: // для хранения расширенной части символов кириллицы std::map<E, I> in_tab; std::map<I, E> out_tab; };
Примечания
Я не стал захламлять статью лишним кодом — фасет codecvt для cp866 реализуется аналогично, а о ctype я рассказывал ранее, но если кому-то нужен рабочий пример, эти фасеты можно взять на github — git://github.com/hoxnox/cyrillic-facets.git.
И прошу прощения за отсутствие номеров строк — чтобы НЛО «проглотило» топик пришлось сокращать highight кода.
Подробней о UNICODE модно почитать тут
Подробней о фасетах — в книге Страуструпа «Язык программирования C++», третье специальное издание, приложение
Подробней о boost::xpressive тут
UPD 20150813:
Хабрапользователь Cyapa провел расследование и выяснил, что фасет codecvt работает только с потоками, работающими с bisic_filebuf. Согласно стандарту (п. 27.9.1.1, кроме того это отмечено у Страуструпа) реализации не обязаны вызывать методы фасета codecvt для других буферов — в частности basic_stringbuf. Таким образом если вы создали локаль со своим фасетом codecvt и надеетесь, что std::stringstream, которому назначена эта локаль (с помощью imbue) будет дергать этот фасет, вы ошибаетесь.
