Напечатать UTF-8 символ в аргумент командной строки

Для одной программы мне надо в качестве аргумента передать UTF-8 символ. Что-то вроде такого:

\uNNNN unicode character code in hexadecimal

В баше (был zsh) то же самое: \uHHHH the Unicode (ISO/IEC 10646) character whose value is the hexadecimal value HHHH (one to four hex digits) \UHHHHHHHH the Unicode (ISO/IEC 10646) character whose value is the hexadecimal value HHHHHHHH (one to eight hex digits)

man bash, /^SHELL BUILTINS man zshbuiltins. man echo — ман по /bin/echo, он тебе нужен?

echo d182cc81d0b5d181d182d18b0a | xxd -p -r т́есты

г мамонта такое г

ну так а что мешает использовать ./program `echo -e '\x0301'` ?

Печально. Меня этот регресс xUSSR (когда мы плетёмся в Unicode-хвосте) удручает.

Ладно, попробую через Python.

ну так а что мешает использовать ./program `echo -e '\x0301'` ?

Банально, 4-значные коды не поддерживаются этой версией bash/echo:

так версию бы озвучил. не у всех тут debian 6.0

а bash -c «echo -e '\x0301'» что говорит?

В смысле printf «\x03\x01»? Нужно будет переводить всё в UTF-8 руками:

> Но хочется, чтобы программа (на Си) не занималась конвертацией обозначения в символ, а генерировать его код где-то вне программы.

молодец, чо. вместо вызова wctomb/wcstombs/sprintf намного проще вызвать левую утилиту через fork+exec с туевой хучей флагов, которая благополучно глюкнет на экзотической локали… тебе в детстве случайно гланды через анус не удаляли?

> тебе в детстве случайно гланды через анус не удаляли?

Через анус - нет. Зато привили чувство грамотности и нормы этики.

> вместо вызова wctomb/wcstombs/sprintf

Я подумаю. Но мне эти программные пляски с бубном вместо обычной передачи через командную строку - не нравятся.

> пляски с бубном вместо обычной передачи через командную строку

ты очень точно описал свои извращённые желания из стартового поста.

> ты очень точно описал свои извращённые желания из стартового поста.

Могу только сказать, что у меня отвращение к UTF-8, начиная с её появления «на публике». Можно было придумать не такую универсальную, но - более удобную для различных конвертаций систему. Например, какое-то подобие UTF-16 меня бы устроило. Китайские символы можно бы было вынести в отдельный стандарт.

>Например, какое-то подобие UTF-16 меня бы устроило. Может, ты хотел сказать «UTF-32»? UTF-16 не fixed-length.

Китайские символы можно бы было вынести в отдельный стандарт.

Закопать. Этому нет оправданий.

> Может, ты хотел сказать «UTF-32»?

Да, я имел ввиду какой-то из них, где fixed ширина символа. Это - очень удобно.

А нынешнюю кашу из UTF-8 символов программисты до сих пор разгребают, затратив на это кучу времени. Да и не все символы есть в том же терминале. less/more уже не посмотреть.

> Могу только сказать, что у меня отвращение к UTF-8

к психологу обращался?

> Можно было придумать не такую универсальную, но - более удобную для различных конвертаций систему.

и чем ISO мотивировала отказ от предложенной тобой системы?

> Например, какое-то подобие UTF-16 меня бы устроило.

да кому ты нужен…

> Китайские символы можно бы было вынести в отдельный стандарт.

тебя бы вынести в отдельную вселенную…

>удобную для различных конвертаций систему а что неудобно-то? Есть символы, есть их коды, всё в порядке. Нормализация есть также.

Китайские символы можно бы было вынести в отдельный стандарт.

«За это убивать надо», — говорил Лёлик в одном известном фильме.

>Да, я имел ввиду какой-то из них, где fixed ширина символа. mbrtowcs в линуксах делает UTF-32 из текущей локали. В win32 он делает UTF-16, что не так весело, но сносно

Да и не все символы есть в том же терминале. less/more уже не посмотреть.

>> Могу только сказать, что у меня отвращение к UTF-8

А что, с психологами какие-то сложности нынче? :)

а что неудобно-то? Есть символы, есть их коды, всё в порядке. Нормализация есть также.

Да, я имел ввиду какой-то из них, где fixed ширина символа.

mbrtowcs в линуксах делает UTF-32 из текущей локали.

Во, спасибо. Может быть, получится эту функцию где-то использовать.

Да и не все символы есть в том же терминале. less/more уже не посмотреть.

Я пробую less example.txt для текста на церковно-славянском (эти коды есть практически все в стандарте), установлен шрифт терминус - многие символы не отображаются посредством less/more.

>установлен шрифт терминус - многие символы не отображаются посредством less/more. less/more не виноваты, как и кодировка. Эмулятор терминала не может найти нужный (да ещё и моноширинный) шрифт.

А в чем проблема юникода, что в твоем терминусе нету церковно-славянского?

Китайские символы можно бы было вынести в отдельный стандарт.

Тебя бы выселить за пределы планеты.

> А в чем проблема юникода, что в твоем терминусе нету церковно-славянского?

Я оцениваю систему в целом - кодировка + шрифты. После внедрения Unicode, с текстом стало неудобно работать. Вот отдельные кодовые таблицы (для каждого языка) - мне нравятся больше. Даже, если бы они были из строго 2-х байтовых символов.

Тебя бы выселить за пределы планеты.

Шаблонное мышление detected. Может лучше китайцев к нам пригласить в РФ, для повышения ВВП, и качества Линукса в частности? )

>После внедрения Unicode, с текстом стало неудобно работать. До внедрения Unicode с мультибайтным текстом вообще невозможно было работать. Это лучше? Unicode, конечно, ужасен (я бы предпочёл troncode), но лучше, чем каша из национальных кодировок.

Даже, если бы они были из строго 2-х байтовых символов.

Переписывать *все* утилиты, считающие, что кодировка всегда совместима с ASCII? Это сколько человеколет?

Может лучше китайцев к нам пригласить в РФ, для повышения ВВП, и качества Линукса в частности?

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

>Я оцениваю систему в целом - кодировка + шрифты. Поздравляю. Только до юникода не было церковнославянских символов вообще. Ни в одной кодировке.

> Это сколько человеколет?

Не знаю. Мы в этой гонке - в самом хвосте. В голове колонны - американцы. Как пример отдельной кодировки - см., например, HIP - стандарт де-факто для церковно-славянского. Он кодируется обычными ASCII 7-bit.

Только до юникода не было церковнославянских символов вообще. Ни в одной кодировке.

Я могу ошибаться конечно, но еще тогда был стандарт HIP: http://www.pechatnyj-dvor.narod.ru/docs.html

P.S. Если сравнивать UTF-8 и RTF, то мне по душе RTF, так как его можно редактировать в обычном текстовом редакторе. Вот если бы еще для каждого языка разработали что-то подобное HIP - было бы вообще замечательно. Там можно указывать ударения и мягкие переносы. Кодировка + базовые вещи для разметки текста.

Вариант 20 языков, хорошенько перемешанных в 1 тексте, не рассмативаем? А зря. В этом случае отдельные кодировки просто сосут. UTF8 наше всё и ты его просто не умеешь готовить вот и всё.

ITT: не осилил → не нужно.

>Как пример отдельной кодировки - см., например, HIP - стандарт де-факто для церковно-славянского. И чем он лучше?

Он кодируется обычными ASCII 7-bit.

Нет, он кодируется ASCII 7-bit + информацией о локали.

Если сравнивать UTF-8 и RTF, то мне по душе RTF, так как его можно редактировать в обычном текстовом редакторе.

UTF-8 можно редактировать в обычном текстовом редакторе.

Там можно указывать ударения и мягкие переносы.

В юникоде есть ударения и мягкие переносы.

> Нет, он кодируется ASCII 7-bit + информацией о локали.

Само понятие - локали - порочно, ИМХО. Для кодирования знаков из церковно-славянского, приходится захватывать символы из разных кодовых страниц Unicode.

В юникоде есть ударения и мягкие переносы.

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

>Само понятие - локали - порочно, ИМХО. Конечно. Отсюда и взялось явление UTF8-монокультуристов, не желающих признавать остальные кодировки в обмене текстом.

Но они (например, мягкие переносы) практически не используются

Это не проблема юникода. Библиотека Мошкова заполнена текстами, созданными в доюникодный период.

>кодовых страниц Unicode

Это что-то типа деревянного железа?

Это вообще разметка текста.

У топик-стартера же наблюдается прогрессирующий ПГМ.

А UTF-32 fixed-length по-вашему? Просто пока символов нет за пределами интервала, представляемого четыремя байтами :)

Только до юникода не было церковнославянских символов вообще.

Они были на бумаге :) И не были никому нужны при наборе текстов в электронном виде.

Это - кодировка ASCII 7-bit символами. Строки легко читаются «с листа». Плюс - разметка. Инфа 100%, почти от разработчиков.

У топик-стартера же наблюдается прогрессирующий ПГМ.

Может не будем о печальном?

>> Только до юникода не было церковнославянских символов вообще.

Они были на бумаге :) И не были никому нужны при наборе текстов в электронном виде.

Именно, что станадрт HIP был еще в 2001 году (шестая редакция стандарта), для набора церковно-славянского в виде: «и= ны'нjь просвjьти` мои` _о='чи мы'сл_енныя, w\тве'рзи моя^ о_у=ста`, поуча'тися словес_е'мъ твои^мъ, . »

Это было еще до 2001 года, когда под Linux массово использовалась KOI8-R.

> Это - кодировка ASCII 7-bit символами

Ой, ошибся. Тут 8 бит. Но от выбора кодировки отдельных символов результат вообще не зависит. Можно использовать и Windows-1251, и KOI8-R, и - CP866. Лишь бы был русский. На базе него и «достраиваются» все буквы церковно-славянского алфавита.

>А UTF-32 fixed-length по-вашему? Да, его с запасом хватает для диапазона в 21 бит (UCS-4). Нет, при контакте с внеземными цивилизациями может понадобиться 128битный UCS-6, но сейчас и этого хватает.

День каменного века на лоре что ли? Такие нехорошие слова как «кодировка», «кодовые страницы» вообще надо забыть, тем более что на линуксах для забывания этого давно созданы все условия. Это винда до сих пор с динозаврами пребывает.

>Именно, что станадрт HIP был еще в 2001 году Unicode был ещё в 1991 году, и что дальше?