локализация в коде C/C++ (как писать)

Модератор: Модераторы разделов

NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

Re: локализация в коде C/C++

Сообщение NickLion »

Имеется в виду, что есть три типа, два разных, а третий есть "близнецом" одного из тех двух, но тем не менее, считается отдельным типом. Но, да, это уже всё оффтопик.

azsx писал(а):
02.09.2016 18:40
символы с кодами 0xD800–0xDFFF (диапазон, включающий верхние и нижние суррогаты).

Именно так мой алгоритм и делает. Но потом, я читаю эти переменные целиком из БД в кодировке utf8, делю их по словам (как пример) и пытаюсь записать в бд в utf8. И иногда снова появляются такие пары.
Как так?

Лучше покажите код, то ли дело в том, что вечер, но я не очень ясно представил, какие преобразования происходят.
Спасибо сказали:
Аватара пользователя
Olej
Сообщения: 659
ОС: Fedora, Mint, Debian, QNX
Контактная информация:

Re: локализация в коде C/C++

Сообщение Olej »

NickLion писал(а):
02.09.2016 16:50
Опечатка.
...
Описка.

Выправил всё.
Давайте ещё. :rolleyes:
Спасибо сказали:
NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

Re: локализация в коде C/C++

Сообщение NickLion »

Olej писал(а):
02.09.2016 22:16
Выправил всё.
Давайте ещё. :rolleyes:

Почитал и вступление, вот ещё немного, что попалось на глаза:
все сегодняшни студенты
Одной из слабо описанной частью языка
вопросы локализации я языке C
построено на стандартах POSIX и использование операционной системы Linux
кодовые стран
отображаются в UNT-8
Спасибо сказали:
yoshakar
Сообщения: 259
ОС: Debian Stretch

Re: локализация в коде C/C++

Сообщение yoshakar »

Использование wchar_t - это, пожалуй, худший способ работать с юникодом: ведущий к совершенно ненужным проблемам, просто не возникающим при использовании обычных строк с UTF-8. Да, во многих ЯП использование UTF-32, а то и UTF-16 как внутреннего представления строк не оставляет выбора. Но в C++, где есть простые удобные строки, с которыми можно работать как пачками байт, не вдаваясь в подробности...
Спасибо сказали:
Аватара пользователя
bormant
Сообщения: 1354

Re: локализация в коде C/C++

Сообщение bormant »

yoshakar писал(а):
05.09.2016 00:20
с которыми можно работать как пачками байт, не вдаваясь в подробности...
... ровно до тех пор, пока можно обходиться работой со строками целиком и не нужно работать с отдельными символами.
Спасибо сказали:
NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

Re: локализация в коде C/C++

Сообщение NickLion »

bormant писал(а):
05.09.2016 12:09
yoshakar писал(а):
05.09.2016 00:20
с которыми можно работать как пачками байт, не вдаваясь в подробности...
... ровно до тех пор, пока можно обходиться работой со строками целиком и не нужно работать с отдельными символами.

И wchar_t тут особо не поможет. Например: й — это два символа, с точки зрения wchar_t, а й — один. А с точки зрения пользователя — это один символ в любом случае.
Спасибо сказали:
Аватара пользователя
bormant
Сообщения: 1354

Re: локализация в коде C/C++

Сообщение bormant »

NickLion писал(а):
05.09.2016 12:32
И wchar_t тут особо не поможет. Например: й — это два символа, с точки зрения wchar_t, а й — один

И с точки зрения NFC, и с точки зрения NFKC -- один в обоих случаях.
Но да, проблема есть, не все символы произвольного алфавита могут обходиться без combining marks. Однако, это отдельная проблема представления символа набором база+дополнение..., присущая всем вариантам UTF в равной мере.
Спасибо сказали:
NickLion
Сообщения: 3408
Статус: аватар-невидимка
ОС: openSUSE Tumbleweed x86_64

Re: локализация в коде C/C++

Сообщение NickLion »

bormant писал(а):
05.09.2016 16:26
И с точки зрения NFC, и с точки зрения NFKC -- один в обоих случаях.
Но да, проблема есть, не все символы произвольного алфавита могут обходиться без combining marks. Однако, это отдельная проблема представления символа набором база+дополнение..., присущая всем вариантам UTF в равной мере.

Именно, wchar_t не поможет в задаче NFC/NFD/NKFC/NKFD, всё равно придётся использовать что-то вроде ICU, а там какая разница уже UTF-8 кодировка нативная или UTF-32? Всё равно не получится "идеала" один code-point = один символ.
Спасибо сказали:
Ответить