Записать информацию в файл в нужной кодировке

Имеется строка типа wchar_t, нужно записать её в текстовый файл, чтобы можно было открыть его блокнотом и всё читалось без кракозябр. Лучше перевести строку из wchar в string. подскажите функцию, и как ей пользоваться

0

Сообщение от Evg Т.е. я могу написать программу по тупому. Но я для себя не буду иметь "морального права" называть свою программу правильной и не буду других учить делать так же. А сам буду пользоваться подобным "моральным правом" только для того, чтобы сделать программу на коленке, которая не предполагает долго жить

Правильность нужна только в том случае, когда пишется кроссплатформенный код,
либо код с перспективами переноса на другие платформы. Во всех остальных
случаях такие заботы не нужны и приводят к переусложнению на пустом месте, а
также к растрачиванию времени, выделенного на разработку. IMHO.

Сообщение от Evg Тот факт, что wchar_t на разных платформах имеет разный размер разве не наводит на размышления о том, что подобным образом написанная программа будет вести себя по разному?

Есть платформы, где нельзя использовать исключения, а int 16-битный.
Не считаю факт их существования в природе достаточным поводом, чтобы
отказываться от try/catch/throw и не писать "int a = 1000000".

С учётом того, что в винде wchar_t имеет ширину 16 бит, то там хранится не юникод, а кастрированный юникод, насколько я себе это представляю, хотя может быть там есть какие-то особенности для хранения символов с номерами больше 2^16

То, что ты описал - это UCS-2, а в Windows уже полтора десятка
лет используется самый что ни на есть UTF-16:

Surrogates and Supplementary Characters
http://msdn.microsoft.com/en-u... 85%29.aspx

0

Сообщение от Evg Сообщение от zer0mail Пишешь в файл сначала BOM, а потом wchar_t и блокнот без проблем открывает. По большому счёту это кривой способ. Он будет работать под виндой только потому что звёзды стоят правильно (что wchar_t под виндой имеет размер 16 бит), а не потому, что так надо делать.

Он хоть где будет работать. При записи BOM определится порядок байтов (BE или LE) и разрядность (16/32), а блокнот после чтения BOM автоматически считает правильно остальную часть файла (он понимает и BE и LE и Utf-8). Суррогатные пары тоже правильно запишутся-прочитаются, хоть для Windows (LE), хоть для Linux (с 32-битным внутренним представлением), хоть для Unix (BE).

Добавлено через 3 минуты
Evg, насчет кастрированности почитайте хотя бы: http://zelserg.livejournal.com/2570.html

0

Сообщение от Убежденный Правильность нужна только в том случае, когда пишется кроссплатформенный код, либо код с перспективами переноса на другие платформы. Во всех остальных случаях такие заботы не нужны и приводят к переусложнению на пустом месте, а также к растрачиванию времени, выделенного на разработку. IMHO.

Не соглашусь с тобой. Чисто с педагогической точки зрения. Я считаю, что человеку сначала нужно научиться работать правильно, и только потом пытаться сокращать усилия на написание программы, пользуясь имеющимися в голове знаниями. Когда сразу же работаешь по сокращённому варианту, то в мозгу откладывается неверное представление об устройстве вещей. На работе мы уже много раз наступали на грабли с этим вопросом (о неправильном представлении вещей из-за работы в условиях частного случая) с молодыми сотрудниками. Собственно, мои возражения носили именно такой характер. Переносимость программ, вещь, конечно, нужная, но в теории её намного сложнее усвоить. Конкретно в данном теме возражения мои НЕ касались переносимости

Сообщение от Убежденный То, что ты описал - это UCS-2, а в Windows уже полтора десятка лет используется самый что ни на есть UTF-16

При хранении в памяти? Может я что-то не понимаю, но каким образом в ОДНОЙ переменной типа wchar_t хранить символ с номером больше 2^16? По моим представлениям wchar_t заводился именно для хранения данных в памяти и удобной их обработки. Т.е. конкретная кодировка (utf-8, utf-16, utf-32) используется для записи в файл, при передачи по сети и т.п., т.е. там, где критичен в первую очередь размер. А внутри программы используется такое представление, которое максимально удобное для обработки, отрезанное от конкретной кодировки. И именно для таких целей был реализован wchar_t. Т.е. если в файл записать широкую строку (wchar_t*) через fwprintf, настраиваясь на какую-нибудь конкретную кодировку (типа utf-16le), то результат получится одинаковым на любой машине (например, разницы на little endian и big endian не будет), а вот если через fprintf, то мы в файле получим образ того, что хранится в памяти, а потому на разных машинах можем получить разный результат.

Может я что-то не так понимаю с назначением типа wchar_t

0

Сообщение от Evg каким образом в ОДНОЙ переменной типа wchar_t хранить символ с номером больше 2^16?

Почитайте про суррогатные пары

0

Сообщение от zer0mail Он хоть где будет работать

Согласен, я был не прав

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

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

0

Символы больше 2^16 хранятся в ДВУХ wchar_t (по ссылке даже написано, как)

0

Сообщение от zer0mail Почитайте про суррогатные пары

Что такое пара я понимаю. Я не понимаю идеологию такого построения. Нахрена нужно было создавать пары, ведь они ломают концепцию wchar_t как типа, удобного для обработки

Добавлено через 21 секунду

Сообщение от zer0mail Символы больше 2^16 хранятся в ДВУХ wchar_t

Вот в этом я и не вижу логики

Добавлено через 2 минуты
Всякие суррогатные пары - это особенность конкретной кодировки utf-16le или utf-16be. Тип wchar_t по смыслу, как мне казалось, не должен быть привязан к устройству какой-либо конкретной кодировки. wchar_t - это тип для хранения unicode, а не его кодирования

Добавлено через 7 минут
Ну и изначальная моя претензия была основана на том, что если если массив wchar_t'ов записать в файл обычной функцией (которая работает с массивами байтов), то положение звёзд на небе определило бы то, что внутреннее представление wchar_t под виндой совпадает с кодировкой utf16-le и благодаря этому факту мы и получили бы файл в конкретной кодировке utf16-le

0

Боюсь, Вы невнимательно читали статью или не обдумывали прочитанное
Надо исходить не из концепции wchar_t, а из концепции unicode. Как бы Вы решили проблемы перехода расширения количества символов с ~65тыс до 1млн? Переписывать все программы или сделать так, чтобы те, кому новые символы не нужны [почти] не заметили перехода и могли пользоваться старыми программами?

Что касается wchar_t, то у Windows он был и есть 16 битов (он точно соответствовал 1-му варианту unicode, а теперь ему приходится использовать пары), а в Linux 32 бита ("внутри" ему не нужны пары). Наверное, Гейтс предпочел добавить и переделать несколько функций, а не ломать ядро и переписывать приложения (прикиньте, сколько их было к 1996 году) Особенно, если учесть, что эти расширения абсолютному большинству американцев и европейцев не нужны.

Добавлено через 5 минут
Кстати, массив wchar_t НЕ следует писать как массив байтов (хотя часто получается правильно). Пишите его как массив wchar_t, либо делайте явное преобразование в Utf16, Utf32 или utf8. Только надо не забыть записать в начале BOM и все будет корректно и будет читаться везде (собственно, это я и написал в своем первом сообщении темы, только кратко ).

0

Сообщение от zer0mail Надо исходить не из концепции wchar_t, а из концепции unicode

wchar_t, насколько я понимаю, придумали, чтобы работать с unicode. А вовсе не unicode придумали, чтобы было чем занять wchar_t

Сообщение от zer0mail Как бы Вы решили проблемы перехода расширения количества символов с ~65тыс до 1млн? Переписывать все программы или сделать так, чтобы те, кому новые символы не нужны [почти] не заметили перехода и могли пользоваться старыми программами?

Лично я пошёл бы по пути через болезненный переход с 16-битного на 32-битный wchar_t. Опять-таки мой личный опыт говорит о том, что лучше один раз как следует напрячься, чтобы потом этим вопросом больше никогда не заморачиваться и об него больше не спотыкаться

Сообщение от zer0mail он точно соответствовал 1-му варианту unicode

Сообщение от zer0mail Наверное, Гейтс предпочел добавить и переделать несколько функций, а не ломать ядро и переписывать приложения

Да, скорее всего так и есть. Черезжопие (а на мой взгляд это именно черезжопие) возникло как последствие нежелания ломать старую концепцию, пользуясь тем, что за пределами 2^16 лежат статистически незначимые символы

Сообщение от zer0mail Кстати, массив wchar_t НЕ следует писать как массив байтов <> Пишите его как массив wchar_t

Либо тут вопрос терминологии, либо мы говорим о разных вещах. Если исходить из "простых" интерфейсов типа printf/cout, то между двумя озвученными методами разницы нет

Добавлено через 4 минуты
А... про последнее понял. Там будет проблема с символом '\0'. ТОгда printf надо заменить на что-то, не работающее с Си'шным понятием строки (например, fwrite).

Правда теперь я не понимаю, что такое

Сообщение от zer0mail Пишите его как массив wchar_t

а точнее, чем его писать. Если всякими типа fwprintf, то эти интерфейсы, насколько я понимаю, не просто пишут, а конвертируют в соответствие с настройками локали

0

Сообщение от Evg а на мой взгляд это именно черезжопие)

Я думаю, что если бы поломали ядро и сказали программистам: переписывате ваши библиотеки, программы, конвертируйте базы данных, то это и было бы "черезжопие". А так обошлось "малой кровью" и многие программисты, администраторы баз данных (не говоря уж о пользователях) этого перехода не заметили.
Вы всерьез полагаете, что американцы в массе стали бы напрягать себя ради каких-то там иероглифов и прочей ерунды, о которой они не знают и знать не хотят и которой они не пользуются?

Добавлено через 22 минуты
Кроме всего прочего, понадобилось бы удвоить количество дисковой памяти при переходе utf16 - utf32 (а ради чего, спрашивается).

0

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

Тем не менее, они напряглись при переходе от 8-битной к 16-битной кодировке. Тем более они постоянно орут про демократию, а винду поставляют в кучу разных стран, включая Китай. Да и при чём тут американцы, когда напрягаться должны были бы разработчики в микрософте

Сообщение от zer0mail Кроме всего прочего, понадобилось бы удвоить количество дисковой памяти при переходе utf16 - utf32 (а ради чего, спрашивается).

Кодировка при записи в файл - это перпендикулярная (независимая) вещь к размеру типа wchar_t. Никто не мешает иметь 32-битный wchar_t, но файлы хранить в кодировке utf-16le

При изменении wchar_t в системе программирования и какой-нибудь должным образом сделанной дефолтной настройке в библиотеке, весь основной гемор свёлся бы только к тому, что нужно перекомпилировать программу в новой системе программирования. Ну и вылизывание всяких мелких косяков, где явно заложились на то, что размер wchar'а равен 16 битам. При этом динамические библиотеки вполне можно было бы реализовать так, что старые бинарники и пересобирать бы не пришлось, а весь гемор лёг бы на библиотеку, которая одновременно умела бы работать и по старому, и по новому. В линуксе для этого в динамических библиотеках используется версионирование, наверное и в винде что-то подобное есть

0

Разве программы в USA разрабатывает только Microsoft? Смена ядра коснулась бы всех (и независимых разработчиков и пользователей).

Впрочем, я изложил свое мнение, а дальше Ваше дело - соглашаться с ним или иметь свое, отличное (от моего )

0