Имеется в виду, что есть три типа, два разных, а третий есть "близнецом" одного из тех двух, но тем не менее, считается отдельным типом. Но, да, это уже всё оффтопик.
символы с кодами 0xD800–0xDFFF (диапазон, включающий верхние и нижние суррогаты).
Именно так мой алгоритм и делает. Но потом, я читаю эти переменные целиком из БД в кодировке utf8, делю их по словам (как пример) и пытаюсь записать в бд в utf8. И иногда снова появляются такие пары.
Как так?
Лучше покажите код, то ли дело в том, что вечер, но я не очень ясно представил, какие преобразования происходят.
Почитал и вступление, вот ещё немного, что попалось на глаза:
все сегодняшни студенты
Одной из слабо описанной частью языка
вопросы локализации я языке C
построено на стандартах POSIX и использование операционной системы Linux
кодовые стран
отображаются в UNT-8
Использование wchar_t - это, пожалуй, худший способ работать с юникодом: ведущий к совершенно ненужным проблемам, просто не возникающим при использовании обычных строк с UTF-8. Да, во многих ЯП использование UTF-32, а то и UTF-16 как внутреннего представления строк не оставляет выбора. Но в C++, где есть простые удобные строки, с которыми можно работать как пачками байт, не вдаваясь в подробности...
с которыми можно работать как пачками байт, не вдаваясь в подробности...
... ровно до тех пор, пока можно обходиться работой со строками целиком и не нужно работать с отдельными символами.
И wchar_t тут особо не поможет. Например: й — это два символа, с точки зрения wchar_t, а й — один. А с точки зрения пользователя — это один символ в любом случае.
И wchar_t тут особо не поможет. Например: й — это два символа, с точки зрения wchar_t, а й — один
И с точки зрения NFC, и с точки зрения NFKC -- один в обоих случаях.
Но да, проблема есть, не все символы произвольного алфавита могут обходиться без combining marks. Однако, это отдельная проблема представления символа набором база+дополнение..., присущая всем вариантам UTF в равной мере.
И с точки зрения NFC, и с точки зрения NFKC -- один в обоих случаях.
Но да, проблема есть, не все символы произвольного алфавита могут обходиться без combining marks. Однако, это отдельная проблема представления символа набором база+дополнение..., присущая всем вариантам UTF в равной мере.
Именно, wchar_t не поможет в задаче NFC/NFD/NKFC/NKFD, всё равно придётся использовать что-то вроде ICU, а там какая разница уже UTF-8 кодировка нативная или UTF-32? Всё равно не получится "идеала" один code-point = один символ.