Чем прочитать текст в UTF-32?

137 байт.

Там строчка без условий в начале мэйна:

setlocale(LC_ALL, "");

ok.

Кстати да, чем читаешь-то.

kwrite, kate, gedit, geany, notepad++, и прочие мелкие блокноты, пробовал даже в веббраузерах открыть.

write(...wchar_t...);

И в какой кодировке ты хочешь сохранить? utf-16le, utf-16be, utf-32le, utf-32be, ...?

ПОРЯДОК БАЙТ!!! В общем случае wchar_t-строки созданы только для внутренней обработки. А выводить их так НЕЛЬЗЯ!!!

Можно подбирать результат в vim:

:e! ++enc=utf-32le

Но ты нарушил одно из основных правил работы с Unicode

1. Внутренне представление: wchar_t или другой доступный
2. Внешнее: UTF-8!!!

Была на просторах интернета старая статья «Что нужно знать о Юникод». Почитай.

UTF-8 лучше лежит в памяти и быстрее обрабатывается

а почему многие библиотеки внутри используют utf-16le/be (в зависимости от архитектуры платформы)?

И в какой кодировке ты хочешь сохранить?

В той которая применяется компилятором gcc и glibc на 86й машине, ucs4 le то бишь. А к чему тебе такая информация?

ПОРЯДОК БАЙТ!!!

ВАЛЕРЬЯНКА!!!

В общем случае wchar_t-строки созданы только для внутренней обработки. А выводить их так НЕЛЬЗЯ!!!

Тебя обманули

Ты сохранил дамп памяти в файл и возмущаешься, что это нет программы для его отображения? Пробуешь, открыть в браузере этот дамп, не почитав что об этом пишет стандарт [www.w3.org]

Ты не понимаешь, что твой код равносилен:

write(...struct my_super_puper_struct...)

Ты с пеной у рта пытаешься доказать, что твой файл в UTF-32. Но этот формат существует только для машинного представления. И не рекомендуется для передачи. И поэтому его нет в большинстве текстовых редакторов. Они для текста, а не для работы с бинарными файлами.

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

Как тут уже заметили, с write есть небольшие сложности.

$ cat test-stream.c
#include <locale.h>
#include <stdio.h>
#include <wchar.h>

int main(void)
{
	const wchar_t string[] = L"пенис\n";

	setlocale(LC_ALL, "");
	fputws(string, stdout);
	return 0;
}
$ cat test-write.c
#include <locale.h>
#include <unistd.h>
#include <wchar.h>

int main(void)
{
	const wchar_t string[] = L"пенис\n";

	setlocale(LC_ALL, "");
	write(1, string, sizeof(string));
	return 0;
}
$ echo пенис | iconv -t utf-32 > data.iconv
$ ./test-stream > data.stream
$ ./text-write > data.write
$ file data.*
data.iconv:  Unicode text, UTF-32, little-endian
data.stream: UTF-8 Unicode text
data.write:  data
$ hexdump -C data.iconv 
00000000  ff fe 00 00 3f 04 00 00  35 04 00 00 3d 04 00 00  |....?...5...=...|
00000010  38 04 00 00 41 04 00 00  0a 00 00 00              |8...A.......|
0000001c
$ hexdump -C data.stream 
00000000  d0 bf d0 b5 d0 bd d0 b8  d1 81 0a                 |...........|
0000000b
$ hexdump -C data.write 
00000000  3f 04 00 00 35 04 00 00  3d 04 00 00 38 04 00 00  |?...5...=...8...|
00000010  41 04 00 00 0a 00 00 00  00 00 00 00              |A...........|
0000001c

Черт, trailing null записал. Но на суть это не влияет.

Издание номер два, поправленное и дополненное:

$ cat test-stream.c
#include <locale.h>
#include <stdio.h>
#include <wchar.h>

int main(void)
{
	const wchar_t string[] = L"пенис\n";

	setlocale(LC_ALL, "");
	fputws(string, stdout);
	return 0;
}
$ cat test-write.c
#include <locale.h>
#include <unistd.h>
#include <wchar.h>

int main(void)
{
	const wchar_t string[] = L"пенис\n";

	setlocale(LC_ALL, "");
	write(1, string, sizeof(string) - sizeof(wchar_t));
	return 0;
}
$ echo пенис | iconv -t utf-32 > data.iconv
$ echo пенис | iconv -t utf-32be > data.iconv-be
$ echo пенис | iconv -t utf-32le > data.iconv-le
$ ./test-stream > data.stream
$ ./text-write > data.write
$ file data.*
data.iconv:    Unicode text, UTF-32, little-endian
data.iconv-be: data
data.iconv-le: data
data.stream:   UTF-8 Unicode text
data.write:    data
$ hexdump -C data.iconv 
00000000  ff fe 00 00 3f 04 00 00  35 04 00 00 3d 04 00 00  |....?...5...=...|
00000010  38 04 00 00 41 04 00 00  0a 00 00 00              |8...A.......|
0000001c
$ hexdump -C data.iconv-be
00000000  00 00 04 3f 00 00 04 35  00 00 04 3d 00 00 04 38  |...?...5...=...8|
00000010  00 00 04 41 00 00 00 0a                           |...A....|
00000018
$ hexdump -C data.iconv-le
00000000  3f 04 00 00 35 04 00 00  3d 04 00 00 38 04 00 00  |?...5...=...8...|
00000010  41 04 00 00 0a 00 00 00                           |A.......|
00000018
$ hexdump -C data.stream 
00000000  d0 bf d0 b5 d0 bd d0 b8  d1 81 0a                 |...........|
0000000b
$ hexdump -C data.write 
00000000  3f 04 00 00 35 04 00 00  3d 04 00 00 38 04 00 00  |?...5...=...8...|
00000010  41 04 00 00 0a 00 00 00                           |A.......|
00000018

Отсюда видно, что у тебя после write() должен получиться utf32le. Если посмотришь, iconv -t utf32 от iconv -t utf32le отличается наличием BOM.

P.S. VIM нормально распознает текст в data.iconv, но не может распознать его в data.iconv-[bl]e.

Что собственно и тредовалось доказать :-)

Дык.

Ого, неплохая работа, спасибо.

Боже, это пять звезд...

Я обратил внимание на ваше сообщение, только попробовать не успел.

Всё получилось, редакторы правда отказывались принимать текст без BOM (хотя BOM и факультатив).

Вам и cvv спасибо, и так же всем кто поучаствовал.

На здоровье. Но, как уже заметили выше, я бы посоветовал тебе останоавиться на UTF-8. Как минимум потому, что половина тулзов не умеет UTF16/32, а glibc вряд-ли добавит поддержку подобных локалей.

Что бы пришёл utf32 каждый должен начать с себя ;)

зачем? utf8-символ, не смотря на своё название, умеет умещаться как в 7бит, так и в 32.

и хранить файлы в utf16/utf32 действительно нет никакого смысла.

Что бы пришёл utf32 каждый должен начать с себя ;)

Штука-то вот в чем: UTF-8 решал довольно острую проблему разношерстных кодировок. Поэтому, несмотря на корявость процесса, на него таки перешли. По сравнению с UTF-8, у UTF-32 довольно мало плюсов (несмотря на то, что в wchar_t влезает любой code point, это все равно не позволяет тебе итерироваться по строке, как по массиву, из-за композитных символов), зато он ломает совместимость с ASCII-only софтом и требует значительных усилий для перехода.

Если существуют композитные символы то тогда и ASCII не позволяет итерироваться.

зато он ломает совместимость с ASCII-only софтом и требует значительных усилий для перехода.

ASCII-only это атавизм, а путь длинною в тысячу километров начинается с одного шага.

Если существуют композитные символы то тогда и ASCII не позволяет итерироваться.

В ASCII их нет. Они есть в Unicode и кодировках разного рода азиатских и скандинавских языков.

ASCII-only это атавизм

Безусловно.

а путь длинною в тысячу километров начинается с одного шага.

Это если идешь один :)

Я имел в виду восьмибитные кодировки на основе ascii.

Я имел в виду восьмибитные кодировки на основе ascii

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

UTF-8 лучше лежит в памяти

Офигенно лучше — одинаковые по количеству символов тексты на разных языках занимают разное (в 2-4 раза) количество байт, адресовать символ невозможно, не пропарсив всё, что находится перед ним и др.

Давайте говорить прямо - UTF-8 лидирует потому, что англоговорящие прогнули под себя всю эту планетку, и планетка согласилась.

«Один маленький шаг для человека, но гигантский скачок для всего человечества»! (c) Нил Армстронг

JEdit

Офигенно лучше — одинаковые по количеству символов тексты на разных языках занимают разное (в 2-4 раза) количество байт, адресовать символ невозможно, не пропарсив всё, что находится перед ним и др.

А зачем тебе символ-то адресовать?

Давайте говорить прямо - UTF-8 лидирует потому, что англоговорящие прогнули под себя всю эту планетку, и планетка согласилась.

А сто лет назад мировым языком был французский. Как человек, его учивший — лучше уж английский.

Давайте говорить прямо - UTF-8 лидирует потому, что англоговорящие прогнули под себя всю эту планетку, и планетка согласилась.

C ASCII попутал, некрофил чертов.

Чем прочитать текст в UTF-32? (комментарий)

Ну сначала был ASCII, да. А потом тихо и незаметно на него натянули UTF-8, который для англоговорящих не отличается от ASCII, зато для большинства остальных неожиданно оборачивается кодировкой с переменной длиной символа.

Не удалось прочитать текст в JEdit?

Понаделают недоязычков, а потом им длинна мешает.

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

и, вследствие того, манной небесной.

некропостинг - такой некропостинг

n7t328IIpnwd

ба-а-али́н, всё не мог вспомнить, как называется тулза. спасибо!

Кажется, у него ещё какая-то утилита была, для вспоминания забытых названий остальных утилит. Не помню, как называется.

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