Как UTF-8 помещается в char?

Question

[Алан Кабисов]

Задался вопросом как символ UTF-8 помещается в тип char, который, например, в C имеет размер в 1 байт, а юникод по логике вещей и если верить википедии может занимать от 1 до 6 байт. Так вот никак не могу понять, как бы это стыдно не было, как юникод помещается в char? Как, например, выводятся русские буквы в консоли? Может кто-нибудь прояснить эту ситуацию для меня?

Answer 1

[Дмитрий]

А никак не помещается.
Потому что Си не поддерживает обработку строк в UTF-8. Для этого нужны сторонние библиотеки, которые умеют делать нормализацию, считать длину строки в абстрактных символах, а не кодпоинтах, и т. д. Поддержки этого всего у Си и C++ из коробки нет.
Ну, вы можете, конечно, запихнуть UTF-8 поток в массив char'ов, но ни одна нативная функция для работы со строками не будет с ним работать правильно. Даже длину строки никогда не сможет посчитать.

Поэтому, ответ прост: в C/C++ для работы с UTF8 используйте стороннюю библиотеку.
И да, никогда не используйте wchar_t нигде, где не можете этого избежать, например, в апи сторонних библиотек. wchar_t это тупо костыль в дизайне языка, который признали даже создатели этих языков.

Comments

[Алан Кабисов]

А как тогда помещается русская буква в char? Также как наверное помещается буква из другого языка.

[Дмитрий]

Алан Кабисов: она туда не помещается. Кириллица занимает 16-битный диапазон, в 8 бит она не поместится. Вы путаете с какой-нибудь CP1251.

[Алан Кабисов]

То есть всегда, когда я ввожу русский символ, то это бывает кодировка CP1251? А как же тогда если пользователь введет символ другого языка?

[Дмитрий]

Кодировка 1251 это исключительно виндовая вещь для русской локали. У другого языка на винде, будет другая кодировка. Например, восточная европа использует 1250, греческий — 1253, и т.д. Но это работает только на винде и нигде больше.
Просто, нужно различать ВХОДНУЮ кодировку, кодировку ХРАНЕНИЯ и ВЫХОДНУЮ. Они ВСЕ могут быть разными и просто преобразовываться из одной в другую, когда это необходимо.

Для понимания достаточно абстрагироваться от типов, типы — это искусственная вещь, придуманная для человека. А учитывая, что язык Си изначально разрабатывался учёными для учёных, то типы у него получились, мягко говоря, странные и неподходящие под современные реалии. Данные же в памяти хранятся вообще независимо от каких либо типов и интерпретаций. Не нужно на них зацикливаться, а воспринимать данные как последовательность бит и ничего более.

И char — это просто тип данных, равный 8 битам. И всё. Он не имеет ничего общего с кодировками, символами, строками. Совсем ничего. Просто, однажды приняли, что он подходит для хранения позиций однобайтовых кодировок типа ASCII, ибо других на то время просто не существовало. С тем же успехом строки можно и в int хранить, и в double. Сейчас же строки в современных кодировках, типа UTF-8, хранятся просто в массивах байтов и не имеют никакого отношения ко встроенным фичам языков Си и C++.

[abcd0x00]

Дмитрий:

Ну, вы можете, конечно, запихнуть UTF-8 поток в массив char'ов, но ни одна нативная функция для работы со строками не будет с ним работать правильно. Даже длину строки никогда не сможет посчитать.

Там надо правильно локаль привязать и всё будет работать.

А учитывая, что язык Си изначально разрабатывался учёными для учёных

Это ты где начитался? Си разрабатывался для переносимости UNIX между разными аппаратными архитектурами.

Поэтому, ответ прост: в C/C++ для работы с UTF8 используйте стороннюю библиотеку.

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

wchar_t это тупо костыль в дизайне языка, который признали даже создатели этих языков.

Ты просто где-то чего-то начитался. wchar_t - это абстрактный широкий символ. Внутри всё должно хранитьсяв wchar_t, а перегоняться снаружи и наружу через функции, опирающиеся на заданную локаль.

Кириллица занимает 16-битный диапазон, в 8 бит она не поместится.

Во-во, ты совсем не ориентируешь, где и что. Какой-то набор слов, далёкий от реальности.

Просто, однажды приняли, что он подходит для хранения позиций однобайтовых кодировок типа ASCII, ибо других на то время просто не существовало.

Тогда существовало много чего.

Алан Кабисов: в общем он тебе втирает изрядно, не понимая конкретно, где и что. Где-то чего-то начитался, то пишет нормально, то туфту какую-то выдаёт из непонятно откуда, требуй с него ссылки, иначе он тебе инфой из блогостатей от неизвестных авторов засрёт мозг.

[Алан Кабисов]

abcd0x00: Спасибо за разъяснения

[Дмитрий]

abcd0x00: В игру вступают теоретики =)) Товарищ, тыкальщик, вы, собственно, когда в последний раз использовали в продакшене то, о чём так люто брызжете слюной? Можно ссылочки на гитхаб, пожалуйста?

Локали прописать? Что-то я не помню адекватной поддержки нормализации юникода в STL. Классический пример: напишите мне ваши пару строк, где нужно "просто локаль привязать" для сравнения\поиска_подстроки в utf8 строках, содержащих символы, типа немецкого эсцета, греческой сигмы, десятков вариаций турецкого "i", тысяч различных диграфов в языках, зависящих от их местоположения в слове, диакритику и т.п. Я очень удивлюсь, если вы сможете это сделать средствами стандартной библиотеки:

to_upper(u8"Maßstab") == to_upper(u8"Maſsstab") == (u8"MASSSTAB") == (u8"MAẞSTAB")
to_lower(u8"ΣΊΓΜΑΣ") == u8"σίγμας" == u8"ϲίγμαϲ" == to_lower(u8"ϹΊΓΜΑϹ")

Про хранение в wchar_t... прикольно. У таких же теоретиков, которые предлагали это в стандарт, да, в идеале они хотели этого. Но идеалов не бывает, к счастью\сожалению. Вы в курсе, что реализация wchar_t у винды не соответствует стандарту ISO/IEC 10646 с бородатейших времён и до сих пор, в отличие от других современных компиляторов, соответственно, ни о какой переносимости кода речи быть не может!? Видимо, не в курсе, погуглите в свободное, от изучения теории, время. Ещё раз повторю: шишек набито на wchar_t очень много, не нужно его использовать нигде, кроме WinAPI! Ну зафейлился он by design, ну что поделать?!

А авторов, в своё время, да, читал, никому неизвестного фреймворка Qt, твиттера, Trello, ICU, Boost и прочих неизвестных вещей.

Вот, как просили, ссылочки, засирайте мозг на здоровье! =):
utf8everywhere.org
https://dev.twitter.com/basics/counting-characters
softwareengineering.stackexchange.com/questions/10...
https://www.reddit.com/r/cpp/comments/2zv2qo/best_...
https://google.github.io/styleguide/cppguide.html#...
www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf (6.10.8, _ _STDC_ISO_10646_ _)
archives.miloush.net/michkap/archive/2005/12/21/50...

[abcd0x00]

Дмитрий:

Локали прописать? Что-то я не помню адекватной поддержки нормализации юникода в STL.

В каком STL, ты не видишь, что мы в разделе по C находимся? А ты их не разделяешь, потому что ты знаток "языка" C/C++. Поэтому я тебе и говорю "раздели эти языки для себя, пока не поздно, иначе случится непоправимое". У них разная разработка и разные люди ими занимаются.

Можно ссылочки на гитхаб, пожалуйста?

https://github.com
https://github.com
https://github.com
Не благодари.

#include <stdio.h>
#include <locale.h>
#include <wchar.h>
#include <wctype.h>

int main(void)
{
    wint_t wc;

    setlocale(LC_ALL, "ru_RU.UTF-8");

#if 1
    wc = L'ẞ';
    wprintf(L"Проверка показывает, что символ <%lc>:\n", wc);
    wprintf(L"Алфавитный: %ls\n", iswalpha(wc) ? L"да" : L"нет");
    wprintf(L"  Цифровой: %ls\n", iswdigit(wc) ? L"да" : L"нет");
    wprintf(L"    Нижний: %ls\n", iswlower(wc) ? L"да" : L"нет");
    wprintf(L"   Верхний: %ls\n", iswupper(wc) ? L"да" : L"нет");
    wprintf(L"Преобразование регистра <%lc>:\n", wc);
    wprintf(L"  В нижний: <%lc>\n", towlower(wc));
    wprintf(L" В верхний: <%lc>\n", towupper(wc));
#endif

    return 0;
}

[guest@localhost wchar]$ gcc -std=c99 -Wall utf8.c -o utf8 
[guest@localhost wchar]$ ./utf8 
Проверка показывает, что символ <ẞ>:
Алфавитный: да
  Цифровой: нет
    Нижний: нет
   Верхний: да
Преобразование регистра <ẞ>:
  В нижний: <ß>
 В верхний: <ẞ>
[guest@localhost wchar]$

Вы в курсе, что реализация wchar_t у винды не соответствует стандарту ISO/IEC 10646 с бородатейших времён и до сих пор

У винды что-то не соответствует стандарту? У компилятора может не соответствовать, но это вообще не аргумент, чтобы продолжать им пользоваться. Если он нарушает стандарт языка, нафиг он нужен тогда вообще. Вот у тебя вторая смесь - винда/компилятор винды.

соответственно, ни о какой переносимости кода речи быть не может

Ты, походу, вообще не понимаешь, для чего стандартизируются языки (и не только языки, а вообще всё). Объекты стандартизуются для того, чтобы быть одинаковыми при любом анализе или синтезе. Поэтому, если кто-то нарушает стандарт, то он реализует язык не в полной мере, потому полноценным компилятором языка его считать нельзя.

А авторов, в своё время, да, читал, никому неизвестного фреймворка Qt, твиттера, Trello, ICU, Boost и прочих неизвестных вещей.

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

www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf (6.10.8, _ _STDC_ISO_10646_ _)

wiki. что такое 10646
И вообще, с чего ты взял, что этот стандарт (C99) относится к C++ как-то? Ты, наверное, не в курсе, но C++ был связан с C только до стандарта ANSI C89. Дальше там всё по-разному идёт. А у тебя из-за каши и получается, что C++ какие-то свои особенности переносит в C99.

В общем, по ссылкам на списки расссылок, где один говорит одно, а другой - другое, я понял, откуда у тебя каша в голове. И хочу тебе сказать: не слушай, что говорят люди, читай официальные документы.

[Дмитрий]

abcd0x00: железные аргументы, аж не поспоришь :D это называется Стандарт Головного Мозга.
Определить — символ это или цифра, думаю, Си в состоянии, но не более того.

#include <stdio.h>
#include <locale.h>
#include <wchar.h>
#include <string.h>

int main(void)
{
    setlocale(LC_ALL, "ru_RU.UTF-8");

    mbstate_t state;

    const char *iy_mb = u8"й";
    const char *iyy_mb = u8"й";

    memset(&state, 0, sizeof state);
    size_t len = 1 + mbsrtowcs(NULL, &iy_mb, 0, &state);
    wchar_t iy_w[len];
    mbsrtowcs(&iy_w[0], &iy_mb, len, &state);

    memset(&state, 0, sizeof state);
    len = 1 + mbsrtowcs(NULL, &iyy_mb, 0, &state);
    wchar_t iyy_w[len];
    mbsrtowcs(&iyy_w[0], &iyy_mb, len, &state);

    // wchar_t from u8 mb
    wprintf(L"%ls\n", !wcscoll(iy_w, iyy_w) ? L"==" : L"!=");
    wprintf(L"%ls\n", !wcscmp(iy_w, iyy_w) ? L"==" : L"!=");
    
    // wchar_t
    wprintf(L"%ls\n", !wcscoll(L"й", L"й") ? L"==" : L"!=");
    wprintf(L"%ls\n", !wcscmp(L"й", L"й") ? L"==" : L"!=");

    return 0;
}

[hv@main-hv tmp]$ clang -std=c11 -Wno-c99-compat -Weverything -pedantic test.c && ./a.out 
!=
!=
!=
!=

й не равно й? Правда? Наверно, gcc и clang тоже не поддерживают стандарты, как и проклятая вижуал студия! :D Приводить примеры с неверными строчными капитализациями и прочими извращениями даже не хочется.

Да, пример достаточно надуманный просто для стёба. Понятно, что в ненормализованной форме никто юникод не сравнивает, и в базах обычно хранится какой-нибудь NFC, но весь к этому NFC ещё как-то надо привести? Либо писать свой костыль на тысячи строк, либо брать готовую библиотеку, которые пишут уже не один десяток лет.

Тогда о какой поддержке Юникода в Си (и вашем ненавистном C++ тоже) может идти речь?

[abcd0x00]

Дмитрий:

Определить — символ это или цифра, думаю, Си в состоянии, но не более того.

Ты говорил, что невозможно найти длину строки в UTF-8. Возможно найти длину строки. Надо просто перегнать байтовые в ширкосимвольные и применить wcslen().

#include <wchar.h>

size_t wcslen(const wchar_t *s);

Да, пример достаточно надуманный просто для стёба. Понятно, что в ненормализованной форме никто юникод не сравнивает, и в базах обычно хранится какой-нибудь NFC, но весь к этому NFC ещё как-то надо привести? Либо писать свой костыль на тысячи строк, либо брать готовую библиотеку, которые пишут уже не один десяток лет.

По твоему примеру ясно, что ты просто (по-простому) писать не умеешь ничего. Что ты пытаешься показать, что "й" невозможно сравнить с "й"? Возможно их сравнить. И с чего ты взял, что прямая "й" и составная "й" должны быть равными? Если ты не в курсе, они даже выглядят по-разному, когда их делаешь. Просто человеку нужно сообщить типа "смотри, это буква "й", а не какая-то другая". Так что я думаю, ты просто придумываешь какую-то хрень, потому что не хочешь разбираться точно, так как со своей C++-фанатичностью ты не привык к ясным и понятным материалам, так как для C++ это не свойственно, там везде бардак и куча ненужного.

[Дмитрий]

abcd0x00: как же тяжко, блин… =)) почему нельзя просто принимать опыт, который люди получили на своих ошибках, набив огромные шишки, исписав тысячи строк на стековерфлоу фразами "Помогите, мужики, нихера не понимаю чё делать с этим юникодом! От от ASCII уж больно отличается!" и, благодаря этому опыту, не ошибаться самому? Гордость не позволяет что ли? Причём, эта проблема, как будто вездесущая. Весь мир упирается против нормальной поддержки UTF-8 везде, где можно. Каждый норовит придумать свою религию или секту кривых кодировок.

Ты говорил, что невозможно найти длину строки в UTF-8. Возможно найти длину строки. Надо просто перегнать байтовые в ширкосимвольные и применить wcslen().

Мы же хотим писать кроссплатформенно, правда? Чтобы было минимум костылей для разных систем. Вот теперь сравните выдачу этой функции у MSVS и у gcc\clang:

size_t len = wcslen(L"здесь готские символы из диапазона 10330 — 1034F, которые ломают разметку Тостера :D ха-ха-ха.");
// вот вам пример крутой поддержки юникода от авторов самого посещаемого ИТ ресурса рунета, очень смешно

ВНЕЗАПНО, VS выдаст 8(восемь!), а гцц и клэнг верно выдают 4. Потому что символы из готской письменности выходят за диапазон 0-FFFF, который может помещать виндовый wchar_t, а по причине закостыливания UTF-16 в wchar_t у винды, им приходится пилить эти символы с помощью суррогатных пар. Отсюда кривой вывод длины. Что происходит на менее популярных компиляторах, я даже проверять не хочу, чтоб настроение не портить.

Что ты пытаешься показать, что "й" невозможно сравнить с "й"? Возможно их сравнить. И с чего ты взял, что прямая "й" и составная "й" должны быть равными?

Ну, потому что, стёб — значит стёб, к тому, что Си не умеет юникод. Ибо в нём нет функций поиска, а нет, потому что не умеет нормализацию. Он умеет лишь примитивный collation 1-го уровня (а их целых 5! www.unicode.org/reports/tr10/#Multi_Level_Comparison), который рассказывает только о том, у какого символа в таблице веса больше. А нам, допустим, нужен полнотекстовый поиск в приложении. Мало того, что отдельно нужен поиск по хранилищу (в котором хранится обычно NFC, а на вход поиска приходит NFD), и отдельно поиск по визуальной части графического интерфейса (NFKC, либо NFKD). Такая же проблема существует при конкатенации строк в разных нормальных формах, более того, если даже форма нормализации одна у обеих строк, это никак не гарантирует, что результирующая окажется в нормальной форме.
unicode.org/reports/tr15/#Canonical_Equivalence
www.unicode.org/reports/tr10/#Asymmetric_Search

Или, если вы пишете какую-то крутую читалку или любое приложение, где важен внешний вид текста, вам нужно делать переносы слов, слогов, абзацев и т. д. Ладно — русский, английский и более-менее понятные европейские языки вы можете захардкодить костылями. Но, попробуйте правильно перенести на иврите, арабском, или каком-нибудь бирманском: "မင်္ဂလာပါကမ္ဘာလောက!" Вот сходу скажете сколько слов в этом предложении? Встроенные средства Си сделают адекватный split хотя бы по словам? А если написание полностью видоизменяется при переносе в некоторых языках? Конечно же ни Си ни C++ этого не сможет, ибо нужна поддержка сегментирования (unicode.org/reports/tr29/).

Как вы это предлагаете делать в Си без сторонних библиотек? Ну вот в упор не вижу, что он это поддерживает, может это в виде пасхалки реализовано или надо секретный флаг компилятору передать?

Если ты не в курсе, они даже выглядят по-разному, когда их делаешь.

Снова смотрим, вами горячо любимый, стандарт:
unicode.org/reports/tr15/#Canon_Compat_Equivalence

Canonical equivalence is a fundamental equivalency between characters or sequences of characters which represent the same abstract character, and which when correctly displayed should always have the same visual appearance and behavior.

always — значит всегда, same — значит одинаковый. Если у вас что-то выглядит по-разному, значит установлены кривые шрифты или что-то не так настроено. Возможно, криво запатчен fontconfig патчами от народных умельцев. У меня выглядят они абсолютно идентично.

В общем, считаю вопрос закрытым. И посоветую использовать для процессинга юникода отличную библиотеку ICU. Хотя, лично мне нравится Boost.Locale, у него можно в качестве бекенда использовать эту же самую ICU, а можно и ваши любимые встроенные средства языка, правда, очень уж ущербненько =)

[Дмитрий]

В строке с символами, ломающими тостер, имелись в виду 4 любых символа, выходящие за диапазон 0-FFFF. Сколько ни бился, ни один тег тостера их не понимает, вся разметка плыть начинает.

[abcd0x00]

Дмитрий:

// вот вам пример крутой поддержки юникода от авторов самого посещаемого ИТ ресурса рунета, очень смешно

Да что тут, что на Хабре очень много косяков алгоритмических, что говорит о том, что они сами мало что пишут, а если и пишут, то пишут безграмотно. Например, в теге code вырезаются лишние пробелы и другие замены происходят, что является существенным косяком, так как тег code для того и существует на всех форумах, чтобы точно передавать содержимое, защитив его от какой-либо обработки. Вот статьи на Хабре так и пишутся: чтобы точно передать содержимое, нельзя его просто вставить в тег code или source, надо сидеть и xmlcharref'ы вставлять (чуть ли не 90-е вспоминаются, когда ручное редактирование html было основным занятием). Но они web-программисты, им можно не шарить в алгоритмах глубоко и интуитивно.

Вот я сейчас набираю это сообщение думаешь где? Прямо здесь? Хрен там, сижу в соседнем вопросе (вообще левом) и там в неотвеченном месте набираю сообщение по одной простой причине - там есть кнопка "предпросмотр" и кнопки тегов кода и квотирования, хотя это всё должно быть в этих маленьких ответах, а нету их, а чтобы поставить кнопки, надо мозгами пораскинуть, а мозги думать не привыкли. Web-программирование - оно и есть web-программирование. То же самое со спойлерами: если в ответах они работают (хотя кнопки нет и многие вообще не знают, что спойлеры можно делать на тостере), то в маленьких ответах они даже не сворачиваются по дефолту, но их можно нажимать и они сворачиваются тогда. И такие мелкие косяки, неудобные для общения, их дофига здесь, но никто их не исправляет, потому что это сложно, это нельзя просто взять, что-то доустановить на движок и чтобы оно работало. Вот и всё.

ВНЕЗАПНО, VS выдаст 8(восемь!)

VS - это не полноценный компилятор, он может нарушать стандарт и он не поддерживает даже уже ставшие старыми стандарты, например C99, а о C11 вообще речи не идёт. Мало того, он пытается пользователей пересадить на свои якобы безопасные функции вывода, что очень сбивает людей, которые плохо знают суть C. Сам же компилятор имеет ошибки ещё. Я одну нашёл - это разделение пространств для названий меток структур и имён переменных внутри структур. Она не давала скомпилировать то, что должно компилироваться по стандарту C89 (хотя официально поддерживает его). Если метка структуры называлась так же, как и переменная в структуре, там была коллизия, которой не должно быть, так как в стандарте эти пространства имён разделены и метки никак не сталкиваются с именами переменных.
Это должно работать по стандарту:
struct x { int x; } x;
Там же оно не компилировалось, говорило мол ошибка. Пришлось тогда полпрограммы переименовывать, которая была нормально написана, просто из-за этого бага не хотела под винду компилиться (там GUI использовался, поэтому VS была компилятором).

Так что, если в VS что-то не работает, я на это внимание не обращаю. Не велика птица.

а гцц и клэнг верно выдают 4.

Ну, выдают, потому что правильные компиляторы - соблюдающие стандарт.

Даже если в C что-то не реализовано, это можно дописать, скорее всего. Не так уж это сложно сделать, особенно тогда, когда не нужен полный функционал. Пишется просто подмножество преобразований, ты потом ставишь это в программу, а потом даже не помнишь, что писал что-то сам, что оно неполное и так далее.

Answer 2

[abcd0x00]

Есть Unicode - это огромная таблица всех символов в мире. У них там свои номера, которые никак не меняются (все символы пронумерованы). И вот для этого юникода есть кодировки, одна из которыз UTF-8 (а другие - UTF-16, UTF-32). Что такое кодировка - это таблица из последовательностей байт, отображаемых на символы. Одна последовательность байт ставится в соответствие одному символу. Соответственно, одна последовательно байт с помощью UTF-8 ставится в соответствие одному символу в Unicode (по его номеру). И наоборот, одному символу в Unicode (его номеру) ставится в соответствие одна последовательность байт в кодировке UTF-8. То есть туда-сюда можно переводить.

Дальше ты читаешь последовательность байт и её можно превратить в одно число по определённому алгоритму и потом это число уже берётся в юникоде и там смотрится символ.

Сама кодировка UTF-8 (закон преобразования) очень просто устроена: она берёт первый байт, в нём записано, сколько там ещё байт нужно взять. Потом эти байты берутся и целиком рассматриваются в виде непрерывной последовательности бит, из которой можно составить число. И потом это число ищется в юникоде уже.

Дальше ты хочешь понять, а что же такое cp1251. Это тоже кодировка, но она никак не связана с Unicode. Вместо Unicode там используется другая таблица (очень маленькая табличка на 256 символов), поэтому там хватает одного байта, чтобы получить код любого символа в этой таблице. И в ней как раз есть своя кириллица, поэтому для неё кириллица помещается в один байт.

Answer 3

[Antony]

Вы же сами ответили на свой вопрос - используется от 1 до 6 char`ов.

Comments

[Алан Кабисов]

Не совсем представляю как это. Если например строка состоит из char'ов с русскими буквами (которые по идее занимают два байта) и мы посчитаем ее размер, то получится нужное нам количество символов, а не в двое больше, как по логике должно получиться.

[Antony]

Насколько я знаю, стандартная сишная библиотека не очень адекватно работает с многобайтными символами. Однако, например, strlen выдаст вам правильный (в байтах) размер строки.

[Антон Жилин]

Antony: strlen говорит об объёме памяти, занимаемом строкой, но никак не соотносится с числом UTF-8 символов (extended grapheme cluster), которые содержатся в строке.Чтобы получить длину UTF-8 строки, нужно использовать сторонние библиотеки.

[Antony]

Антон Жилин: чем мой ответ (размер строки в байтах) отличается от вашего (объем занимаемой памяти) ?

[Антон Жилин]

Antony: Каюсь, мне надо было на комментарий автора вопроса ответить. Я не имел в виду, что с вашим ответом что-то не так.

Answer 4

[rassant]

а как привести число в букву?
например в юникоде 'ф' это 1092.
Как можно это число перевести в букву? wchar_t не работает, и само собой char тоже не работает