За несколько часов я перепробовал почти все возможные и невозможные варианты, и когда провалилась бинарная запись в файл — я понял — надо что-то менять, не в данных, не во мне, а в подходе. До того момента я старался избегать "грязных" хаков, трюков, основанных на знании работы компилятора и задачи программы, за которые она /никогда/ не выйдет. Я старался абстрагироваться, делать все максимально прозрачно (насколько мне позволяла лень :Р) и грамотно. Но у меня не осталось выхода. И так, я знал три(?) вещи: 1. Итераторы не трогали данные, во всяком случае без моего приказа. 2. Итераторы предоставляли прямой доступ к данным 3. При создании итераторов я использовал метод std::basic_string c_str()/data() из описания которых следует: Modifying the character array accessed through data is *undefined behavior*. В дополнение ко всему этому я знал, что строка изменяться уже не будет, и взглотнув побольше воздуха я сделал это — получил прямой доступ к данным через итератор, нагло избавился от const модификатора, который имел место быть благодаря c_str()/data() и стал записывать туда данные. В исходном тексте замена пробельного символа на перенос стала выглядеть так: (*(xmlChar*)u8_word.base()) = '\n'; Дописав код я скомпилировал, запустил и... выдохнул. Оно работало! Данные отображались верно, без доп. копирования, проверок (ранее я пытался записывать по слову) и прочего. "Dirty hack" — то самое выражение, которое пришло в голову сразу после получения (ожидаемого?) результата. Будь у меня более свежая голова, мозг товарища и пицца, я думаю мы разделались бы с этим за 10 минут. Но это был веселый опыт разработки. Больше, пожалуй, мне добавить нечего. Пишите код правильно ребята, не давайте доводить себя до отчаянья. У меня не было ни времени ни возможности обратиьтся к товарищу, и я решил эту проблему иначе. Тем не менее, ссылки по теме: https://github.com/spumer/tenzor-test/ — исходный код, виновник торжества. http://en.cppreference.com/w/cpp/string/basic_string/data — ... through data is undefined behavior. http://utfcpp.sourceforge.net/ — utf8 C++ portable library http://www.xmlsoft.org/html/libxml-xmlstring.html#xmlChar
Сталось так, что при работе с библиотекой libxml2 понадобилось подсчитывать кол-во символов в строке, с целью ограничить длину строки в N символов и остальную ее часть перенести на новую(строку). Символы в этой строке естественно могут занимать от 1 до 6 байт, в соответствии с форматом UTF-8. Самолично парсить строку по стандарту не было никакого желания, а уж темболее проходиться по граблям желания было еще меньше. Благо это тема довольно изъезженная и решение в виде небольшой портабильной библиотеки уже было написано.
Язык С++, и библиотека была написана в виде итераторов для прохода по последовательности байт и функций, которые осуществляют некоторые простые операции как с итераторами, так и с самими последовательностями. libxml2 для хранения данных использует свой собственный тип xmlChar, хотя на деле это ни что иное как unsigned char. Камнем преткновения стала запись в файл, ведь именно туда мне было необходимо выгрузить все отформатированные данные. unsigned char в принципе не хотел записываться в файл и каждый раз он получался пустым, запись же в бинарном виде либо полностью колечило данные, либо их non-ASCII составляющую. Все попытки воссоздать правильную последовательность xmlChar байт с разбивкой на N символов в строке заканчивались одним — полный бред на выходе.
Немного о том, как работает UTF-8 библиотечка: созданные итераторы как и предполагается не трогают данные по которым следуют, но доступ к ним предоставляют. Доступ к символу в моем случае можно было осуществить двумя способами: operator* и метод base(), где первый возвращает данные типа unsigned int, второй же возвращает указатель на место в последовательности, в котором он в данный момент находится. Так, например, если *u8_it вернет нам 'c', то (*u8_it.base()) будет равен &("ascending"[2]). Если же вы(как и я) передавали при создании итератора константный указатель на данные (e.g. const xmlChar *) то при использовании base() для записи вам придется избавиться от const модификатора, но об этом далее.
For Qt’s own source code, we have decreed that the source should be UTF-8 only, and so I proceeded a few weeks ago to find and recode all non-UTF-8 sources. And I’m going even further than that: if you don’t use UTF-8 for your source code, you’ll be on your own. Though it’s possible to make it work, do not ask us for help and do not expect us to add convenience functions. I am also discarding any arguments of the form “my editor/IDE/OS/environment does not support UTF-8″. This is 2012 and we live in a global world, with global data. Any such editor or environment should be left where it belongs: in a museum dedicated to the 80s and 90s.macieira.org
