\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)

Не печатает:

$ echo -e "\u0301"
\u0301

\xHH   byte with hexadecimal value HH (1 to 2 digits)

@madoka~>echo -e "\u0301"          18:24:09

@madoka~>echo -e '\u0301'          18:24:15

УМВР.

у меня в мане

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

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

Debian 6.0

man bash
....
       echo [-neE] [arg ...]
              Output the args, separated by spaces, followed by a newline.  The return status is always 0.  If -n is specified,  the  trailing  newline  is
              suppressed.   If the -e option is given, interpretation of the following backslash-escaped characters is enabled.  The -E option disables the
              interpretation of these escape characters, even on systems where they are interpreted by default.  The xpg_echo shell option may be  used  to
              dynamically determine whether or not echo expands these escape characters by default.  echo does not interpret -- to mean the end of options.
              echo interprets the following escape sequences:
              \a     alert (bell)
              \b     backspace
              \c     suppress further output
              \e     an escape character
              \f     form feed
              \n     new line
              \r     carriage return
              \t     horizontal tab
              \v     vertical tab
              \\     backslash
              \0nnn  the eight-bit character whose value is the octal value nnn (zero to three octal digits)
              \xHH   the eight-bit character whose value is the hexadecimal value HH (one or two hex digits)

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

echo [-neE] [arg ...]
…
              \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)

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

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

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

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

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

$ echo -e '\x0301'
01

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

http://packages.debian.org/squeeze/bash

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

printf «\x21»

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

@madoka~>echo -e '\u0301'|xxd      21:25:21
0000000: cc81 0a                                  ...
@madoka~>printf '\x03\x01\n'|xxd   21:25:24
0000000: 0301 0a    

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

молодец, чо. вместо вызова 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

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

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

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

Индексировать сложно.


x3al:

Да, я имел ввиду какой-то из них, где 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 можно редактировать в обычном текстовом редакторе.

мне по душе RTF

…

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

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

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

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

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

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

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

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

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

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

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

> HIP

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



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

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

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

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

>> HIP

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

Это - кодировка 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 году, и что дальше?

когда под Linux массово использовалась KOI8-R.

Линукс всегда паршиво поддерживал локали. Но это не повод их плодить.