какие номера у кодировок utf16?

Здравствуйте!

Я кажется забыл номера кодировок. Странно. В таблице написано что utf-16 это 1200 и 1201. Но не работает!
https://msdn.microsoft.com/en-us/library/wi...ror=-2147217396

Некоторые функции, начали отказыватся принимать номера кодировок.

Делаю маленькую тулзу. Обычный MultiByteToWideChar и всё такое.

И вдруг, когда стал указывать ей utf-16 le, utf-16 be, она выдала ошибку.

Я удивился, но в итоге, сделал простенькую проверку.

/* это работает. */
_ASSERTE( ::IsValidCodePage( 65001 ) );
 
/* это ругается. */
_ASSERTE( ::IsValidCodePage( 1200 ) );
_ASSERTE( ::IsValidCodePage( 1201 ) );
_ASSERTE( ::IsValidCodePage( 12000 ) );
_ASSERTE( ::IsValidCodePage( 12001 ) );

Не пойму, в чём я накосячил?
Раньше нечто подобное писал, но такого не проявлялось.

Может быть, в самом деле, напутал с кодировками? А есть ли константы аналогичные CP_UTF8 для других юникодовых страниц?

Сообщение отредактировано: Eric-S - 28.04.16, 13:32

Цитата Eric-S @ 28.04.16, 12:33

И вдруг, когда стал указывать ей utf-16 le, utf-16 be, она выдала ошибку.

А какую, если не секрет?

Цитата B.V. @ 28.04.16, 14:08

А какую, если не секрет?

GetLastError возвращает 0 - всё хорошо. А те функции просто говорят, что "страницы неверные":

Цитата справка

Return Value
Returns a nonzero value if the code page is valid, or 0 if the code page is invalid.

Remarks
A code page is considered valid only if it is installed on the operating system. Unicode is preferred.
Starting with Windows Vista, all code pages that can be installed are loaded by default.

Цитата B.V. @ 28.04.16, 14:08

Цитата Eric-S @ 28.04.16, 12:33

И вдруг, когда стал указывать ей utf-16 le, utf-16 be, она выдала ошибку.

А какую, если не секрет?

Конкретно MultiByteToWideChar... |там у меня ретранслируются в std::system_error), заявила, что неверный параметр.

А соответственно IsValidCodePage, возвращает FALSE.

Попробовал вывести все установленные кодировки:

::EnumSystemCodePages( &output_proc, CP_INSTALLED );

Вывела много, есть 65001, 866, 1251, а вот utf16 и не нашёл.

Цитата Eric-S @ 28.04.16, 14:31

Вывела много, есть 65001, 866, 1251, а вот utf16 и не нашёл.

Открываем редактор Far, создаем "левый" текстовой файл, переключаем кодировку [Shift+F8] и наблюдаем интересующие: UTF-16 (Little endian) 1200, UTF-16 (Big endian) 1201. Бинго. Потом гуглим, и находим подтверждение, вдруг Рошал был не честен. Нет, все ровно

Цитата Eric-S @ 28.04.16, 12:33

Делаю маленькую тулзу. Обычный MultiByteToWideChar и всё такое.
И вдруг, когда стал указывать ей utf-16 le, utf-16 be, она выдала ошибку.

Полагаю, что так и должно быть.
Эта функция преобразует ASCII-строку в UTF-16.
А WideCharToMultiByte - наоборот.
Про UTF-16 они уже знают, это указывать не надо.
---
Если EnumSystemCodePages не находит UTF-16, значит так оно и есть.
Вот Enumerating System Code Pages посмотри пример.

Цитата JoeUser @ 28.04.16, 19:08

и наблюдаем интересующие: UTF-16 (Little endian) 1200, UTF-16 (Big endian) 1201

Дык, всё так. Но почему-то сломалось. Может я винду тавокнул и потерял несколько кодировок.

Добавлено 29.04.16, 02:38

Цитата ЫукпШ @ 28.04.16, 21:14

Полагаю, что так и должно быть.

Нет. так не должно быть. Ибо:
во-первых внутреннее представление, не обязательно utf16le. Оно вобще когда-то было uc-2.
Во-вторых, конвертировать в utf16le из utf16be тоже надо.
Ну и в добавок, всё выше написаное касается не только utf-16 но и utf-32. Оно тоже не работает!

Цитата Eric-S @ 28.04.16, 12:33

Делаю маленькую тулзу. Обычный MultiByteToWideChar и всё такое.

Цитата Eric-S @ 29.04.16, 02:35

Может я винду тавокнул и потерял несколько кодировок.

Eric-S, это конечно оффтопик, тем не менее ... подумай а надо ли оно тебе (привязываться к свойствам/возможностям установленной винды)? Допустим не только у тебя "такая винда" ... Я просто не помню как это в Win 8.1, на которой сейчас сижу, но помню, что в XP - локали типа UTF16* вроде бы не были установлены по умолчанию. Что в итоге имеем? Твоя тулза в некоторых случаях будет "говорить" нечто типа "Эй, товарисч, у тя винда не той системы!". Оно тебе надо? Если не надо - глянь уже готовую либу ICU, там должно все быть. Но народ люто ненавидит, впрочем как и я, эту либу - ибо она компилиться в 25-метровую библиотеку. Но все ж признают, мол для UTF16* лучших альтернатив пока нет.

Цитата JoeUser @ 29.04.16, 07:20

Твоя тулза в некоторых случаях будет "говорить" нечто типа "Эй, товарисч, у тя винда не той системы!

Ну и пусть говорит. Если не той, значит не той.
Собственно это так, мелкая примочка для тулзы. Хотелось, чтоб она умела открывать файлы в разных кодировках.
Но для работы хватает и utf-8 и даже cp-1251.

Я опасался, в первую очередь того, что сам где-то накосячил и затупив, не понял, в чём именно.

Хотя, как-то всё странно. Первый раз с такой фигнёй сталкиваюсь. Раньше всё работало. Или я немного иначе делал...

Тащить стороннюю либу, тоже можно. Размер не пугает. Там же целая куча charset'ов вбита. Я даже восхищаюсь, как они смогли так много затолкать в столь скромный размер.

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

Зато моя мелкая тулза, на 500 строк кода, весом в 25 мегабайт будет смотрется солиднее. Гы-гы-гы.

Добавлено 29.04.16, 08:07

Цитата JoeUser @ 29.04.16, 07:20

глянь уже готовую либу ICU, там должно все быть. Но народ люто ненавидит,

На самом деле, давно её знаю. Но как-то привык, встроенными функциями конвертировать. Привычка, вторая натура. Но всё равно спасибо!

Цитата Eric-S @ 29.04.16, 08:05

Тащить стороннюю либу, тоже можно. Размер не пугает.

У меня есть сильные подозрения - что там махровый быдлокод! Только подозрения, утверждать ниче не могу. Но могу поразмышлять. В свое время я несколько лет изучал японский язык, и малеха знаний осталось. Почему вспомнил про японский? Просто "иероглифические" языки - самые толстые в плане "алфавита". Простая статистика. Школьный минимум по выпуску для японцев - около 10000 иероглифов. "Графоманы" могут использовать около 40000 шт.

Максимум можно рассчитать так. "Ключевых" (их называют ключи) иероглифов около 200, ну пусть 255. Позиций во "слово образовании" - три, левый один, и максимум два правых. В итоге получаем 255*255*255 = 16 581 375. Если тупо строить таблицу соответствий - сразу приходит на ум битовый массив. Итого 16581375/8=2072672. Два метра! Не двадцать пять!

Хорошо, берем китайскую письменность. Но и тут "сюрпризик" Иероглифы - те же "японские". А по сути наоборот. У японцев своей письменности нет - они используют "словообразующие" иероглифы именно китайские, только чтение свое. И тут, кстати, ньюанс. Составные иероглифы читаются "китайскими" "чтениями".

Вот два "толстых" алфавита мы оценили. Про корейсие иероглифы - ниче сказать не могу, тупо не в курсе. Остальная письменность - в большей части алфавитная, с достаточно ограниченным алфавитом. Арабская вязь, письменность Тайланда, и пр.пр

Вот такие размышления. Ну не должно быть там 25 метров!!! Ну не верю

Цитата Eric-S @ 29.04.16, 02:35

Добавлено 29.04.16, 02:38

Цитата ЫукпШ @ 28.04.16, 21:14

Полагаю, что так и должно быть.

Нет. так не должно быть. Ибо:
во-первых внутреннее представление, не обязательно utf16le. Оно вобще когда-то было uc-2.
Во-вторых, конвертировать в utf16le из utf16be тоже надо.

Ошибаешься.
Можно посмотреть документацию на "MultiByteToWideChar" и понять,
что она может и для чего нужна.
А то, что надо конкретному юзеру, это его частные проблемы.
Удовлетворять все возможные потребности эта функция
не обещала.

Цитата JoeUser @ 29.04.16, 08:41

Про корейсие иероглифы - ниче сказать не могу...

Я слышал, что там всё те же самые китайские иероглифы. Они у них все одинаковые.
Сотни дальневосточных народов, сотни диалектов, сотни выговоров, но письменность одна.
Правда, у корейцев, собственный язык, и для него есть собственный, параллельный алфавит из 24 символов. Но буквы стилизованы под иероглифы.

Но, кхе... icu, а точнее unicode, разрабатывали кто попало и как попало. Это уж точно. Так что, сомневаюсь, что там, может быть какая-либо система. Даже нашу кирилицу и то добавляли кусками. Букву "ё" засунули в зад, а церковнославянские символы, вообще только недавно начали добавлять в пятую версию.
Ну и ожидаемо, что такое можно конвертировать только в лоб, суровым индуским быдлокодом.

Добавлено 29.04.16, 09:02

Цитата ЫукпШ @ 29.04.16, 08:47

А то, что надо конкретному юзеру, это его частные проблемы.
Удовлетворять все возможные потребности эта функция
не обещала.

Мне собственно нужно:
1. считать текстовый файл. Скоррее всего он будет в ansi, возможно в utf-8.
2. преобразовать кодировку хранения, в широкие символы LPWSTR.
3. выполнить декомпозиционную нормализацию.
4. обработать текст.
5. и записать его в файл в кодировке utf-8 или ansi по выбору пользователя.
По моему MultiByteToWideChar тут подходит в самый раз.

Цитата Eric-S @ 29.04.16, 08:56

Я слышал, что там всё те же самые китайские иероглифы.

Не не не ... у корейцев - что то корейское Китайские иероглифы я б даже в печатной стилизации распознал. Там свое.

Цитата JoeUser @ 29.04.16, 09:05

Не не не ... у корейцев - что то корейское Китайские иероглифы я б даже в печатной стилизации распознал. Там свое.

У них две письменности. Но китайские иероглифы тоже юзают. http://ru.wikipedia.org/wiki/%D0%A5%D0%B0%D0%BD%D1%87%D0%B0
А так, в основном конечно юзают свою поделку https://ru.wikipedia.org/wiki/%D0%A5%D0%B0%...%8B%D0%BB%D1%8C

Сообщение отредактировано: Eric-S - 29.04.16, 09:34

Цитата Eric-S @ 29.04.16, 08:56

Мне собственно нужно:
1. считать текстовый файл. Скоррее всего он будет в ansi, возможно в utf-8.
2. преобразовать кодировку хранения, в широкие символы LPWSTR.
3. выполнить декомпозиционную нормализацию.
4. обработать текст.
5. и записать его в файл в кодировке utf-8 или ansi по выбору пользователя.
По моему MultiByteToWideChar тут подходит в самый раз.

Да, это возможно.
Могу рекомендовать сделать класс-конвертер.