А тут кто-нибудь знает, какие зависимости у XLib? Что может вызвать такое:

$ locale -a|grep ru_R
ru_RU
ru_RU.iso88595
ru_RU.koi8r
ru_RU.utf8
$ LANG=ru_RU.utf8 uxterm
Warning: locale not supported by Xlib, locale set to C

Оно мне вообше-то не сильно надо. Подозреваю, что кучки старья, которое жалко выкинуть, сломаются. Но интересно, чего еще может быть надо.

А вот это они пофиксили?

$ echo $LANG en_US.UTF-8

GNU grep can handle UTF-8, but it handles it in much the same way that the Samsonite gorilla handles your luggage. (rusage is a non-standard command, but you can pick up a copy on raptor:/home/jpl/src/rusage.c, and the times are all that really matters).

$ rusage egrep '^#I' *bad | wc 336.10 real 335.56 user 0.63 sys 414 pf 76 pr 0 sw 0 rb 0 wb 0 vcx 0 icx 0 mx 0 ix 0 id 0 is 282479 1445076 17370459

330 seconds on a 30 megabyte file may have been acceptable in the PDP-11 days, but it's pretty sad now. Behold the salubrious effect of a change of locale:

$ export LANG=en_US.iso885915 # setenv for you *csh folks $ rusage egrep '^#I' *bad | wc 0.35 real 0.20 user 0.02 sys 399 pf 54 pr 0 sw 0 rb 0 wb 0 vcx 0 icx 0 mx 0 ix 0 id 0 is 282479 1445076 17370459

What originally took over 5 minutes now runs in a fraction of a second. The moral might be, if you aren't dealing with UTF-8 data, make sure you aren't in a UTF locale. (RedHat and fedora users can look under directory /usr/lib/locale for suitable non-UTF-8 locales.) If your $LANG indicates UTF-8, consider resetting it in your .profile or .login.

This speedup of 1000 has been made possible by the GNU (Grep's Now Unusable) project. -- jpl

> GNU (Grep's Now Unusable)
это не grep unusable это этот гребаный utf-8 unusablя и маздай, IMHo единственное usable для не говорящих по-аглицки/европейски - UTF-16.
предстваляете скорость того же для русского текста и UTF8?:(

UTF-16 в топку!

>предстваляете скорость того же для русского текста и UTF8?:(

Нормальная скорость. Чем не нравится-то? Непакованные строки всего раза в полтора длиннее однобайтовых.

И чем алгоритм работы в этом случае будет отличаться?

> это не grep unusable это этот гребаный utf-8 unusablя и маздай, IMHo единственное usable для не говорящих по-аглицки/европейски - UTF-16.
предстваляете скорость того же для русского текста и UTF8?:(

IMHO UTF-8 лучше, чем UTF-16 потому что
поток байт после кодирования текста в эту кодировку одинаков для LE и BE архитектур,
первые 127 символов кодируются так же, как в ASCII.

Ни о чем статья.

угу... файлы перекодировать... я тут тоже хотел PDC на самбе перевести на utf-8, но одумался после того как начал перекодировать содержимое файлухи... выяснилось, что длина имени файла ограничена кол-вом байтов, а не символов, соответственно русские имена длиннее 128 символов не получатся... тоесть када бедный пользователь попытается осликом себе в хоум сохранить страничку с длинным заголовком то получит куй, потому что винда урежет имя до 200 с чем-то символов, а самба записать не даст...

> И чем алгоритм работы в этом случае будет отличаться?

С текстом в utf16 (также как и в 1-байтной кодировке) можно работать как с массивом. Массив позволяет прямое обращение к любому элементу по его номеру. Текст в utf8 -- не массив ни разу. Он список, который можно только перебирать последовательно. Поэтому тормоза -- его врожденное свойство. Ну и плюс потенциальный источник глюков в софте, его поддерживающем (чем сложнее организованы данные, тем сложнее их обработка; чем сложнее код, тем больше в нем багов -- при прочих равных, естественно).

Может тогда сразу UTF32 использовать?

> С текстом в utf16 (также как и в 1-байтной кодировке) можно работать как с массивом. Массив позволяет прямое обращение к любому элементу по его номеру. Текст в utf8 -- не массив ни разу. Он список, который можно только перебирать последовательно.

Враньё! То есть полуправда!

В UTF-8 символ кодируется 1-4 байтами. В UTF-16 - 2,4 байтами!

А вы вообще писали про UCS-2!

>С текстом в utf16 (также как и в 1-байтной кодировке)
utf16 это не однобайтовая кодировка, в ней на символ приходится минимум 2 байта, именно минимум, а не два. Поэтому в общем случае с ней также не получится работать как с массивом (кроме определенного подмножества символов, как впрочем и в случае utf8). Кроме того, как уже отмечали, в utf16 порядок байтов неоднозначен и зависит от платформы. Поэтому utf16 мало пригодна для потоковых данных, не говоря уже о html, xml, текстов программ...
Оптимальный вариант - хранение данных в utf8, а внутренне предстваление в программах 16 (32) битное. Как в java, Qt... и преобразование при вводе/выводе.
Хотя, ести не ошибаюсь, внутреннее представление строк в perl - utf8. Но никто не обвиняет perl в неэффективной работе со строковыми данными.

Qecho

нету смысла - 99,99(9)% случаев охватываются UTF-16.
включая cyrillic, китайские иероглифы, kanji со товарищи, hangul, hebrew, арабскую вязь.

Qecho

> первые 127 символов кодируются так же, как в ASCII.
угу =- мне вот дотсали уже эти первые 127 символов - тяжкое наследие 7-bit ASCII-это только амерам удобно.

а у меня ru_RU ru_RU.CP1251 ru_RU.ISO-8859-5 ru_RU.KOI8-R ru_RU.UTF-8

по моему нужен дефис хотя бы 8859-5

Qecho

> Оптимальный вариант - хранение данных в utf8
а чем отпимально-то? для русского текста коэф-т будет ~1.8 с большим геморром и падением скорости (4 проверки вместо 1 для utf-16).

Qecho

> одинаков для LE и BE архитектур,
сам-то понял что сказал? какая разница LE||BE если у тебя 8-бит?;-)

> Враньё! То есть полуправда!

> В UTF-8 символ кодируется 1-4 байтами. В UTF-16 - 2,4 байтами!

> А вы вообще писали про UCS-2!

Ок, я действительно писал про ucs-2. Я считал, что оно синоним для utf-16. Если это не так, приношу извинения за невольную дезинформацию.

> сам-то понял что сказал? какая разница LE||BE если у тебя 8-бит?;-)

Видимо, имелось в виду следующее: utf8 имеет то преимущество, что не нужно заморочиваться с BE/LE.

>а чем отпимально-то? для русского текста
в мире существует не только русский язык (я постоянно использую 3 - русский, английский и немецкий, а многие люди и больше ;))
utf8 - единственная уникодная кодировка, которая подходит для всех случаев жизни и всех языков. Насколько эффективно с точки зрения скорости обработки или использованию памяти, это другой вопрос, в любом случае решаемый (архивирование, использование внутреннего представления данных одинаковой ширины в виде 16 или 32 бит...).
utf8 легко распознается, используется в потоках, в сети, в xml/html, в коментариях C программ, в строковых литералах...
Другие кодировки unicode (utf16, UCS2, UCS4) для этого не применимы (LE/BE неоднозначности, в потоках (байтовых!) не работают, коментарии/литералы в текстах программ не возможны... Как внутреннее представление они годятся, но как универсальные кодировки для обмена и хранения данных, увы...
Да что мы спорим, все ведущие дистрибутивы перешли на utf8 локаль. Кто нибудь видел utf16 или UCS2 локали?

По ходу дела у X свое предствление о локали. Нужно покопаться в /usr/X11R6/lib/X11/locale и сделать так, чтобы ru_RU.UTF-8 указывала туда же, куда и en_RU.UTF-8. Точно не помню, давно это было. Сейчас в gentoo все по дефолту работает.

> utf8 имеет то преимущество, что не нужно заморочиваться с BE/LE.
с чего бы?
зашибись простые правила - см ниже (rfc2044)
я могу напомнить как UTF-8 обрабатывает примерно половину русских буков: что если вам нужен символ >=0xC0 && <=DFF то он выбирается то-то и тд
UCS-4 range (hex.) UTF-8 octet sequence (binary)
0000 0000-0000 007F 0xxxxxxx
0000 0080-0000 07FF 110xxxxx 10xxxxxx
0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx

0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx

для сравнения - UTF-16 (rfc2781):
- Characters with values less than 0x10000 are represented as a
single 16-bit integer with a value equal to that of the character
number.

- Characters with values between 0x10000 and 0x10FFFF are
represented by a 16-bit integer with a value between 0xD800 and
0xDBFF (within the so-called high-half zone or high surrogate
area) followed by a 16-bit integer with a value between 0xDC00 and
0xDFFF (within the so-called low-half zone or low surrogate area).

- Characters with values greater than 0x10FFFF cannot be encoded in
UTF-16.

> в мире существует не только русский язык
честно говоря мне похрен проблемы работающих с 3 языками - таких единицы. но раз уж так хотите - UTF-16 позволяет решить проблемы практически всех людей - он охватывает все основные страницы UNICODE от иероглифов до вязи.
> utf8 легко распознается
это - спорно.
> в потоках (байтовых!) не работают
да объясните - почему UTF8 то работает там? ему тоже нужны спецсимволы для вывода за прееделы BMP. так не один ли хрен?
экономию он даёт тоже только для BMP.
а в коммнетах - пожалуйста, лепи - н о в UTF-16.
> Кто нибудь видел utf16 или UCS2 локали?
даа. и не только видел. и даже работает. винду поставь.:-)

> честно говоря мне похрен проблемы работающих с 3 языками - таких единицы.

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

Надо читать доки и пускать uxterm через LANG=ru_RU.UTF-8 uxterm

>честно говоря мне похрен проблемы работающих с 3 языками - таких единицы
Весьма конструктивно;) Что то типа, мне пофиг проблемы автомобилистов, их меньшенство, а я пешком хожу;)
>UTF-16 позволяет решить проблемы практически всех людей
utf8 позволяет решать проблемы ВСЕХ людей
>а в коммнетах - пожалуйста, лепи - н о в UTF-16.
редактор не подскажете, который будет это вытворять - C программа ASCII, а коменты в ней UTF-16?
Про xml/html скромно умолчали ;)
>да объясните - почему UTF8 то работает там?
Потому что по каждому байту можно судить, что это за байт - одиночный символ, начало многобайтного символа или его продолжение. Поток не требует дополнительной информации. Вы же сами схему utf8 приводили.
>> Кто нибудь видел utf16 или UCS2 локали?
>даа. и не только видел. и даже работает. винду поставь.:-)
Что работает, и утилиты типа find, grep... корректно работают?
Спасибо, я уж как-нибудь на SuSE с локалью utf8 перебьюсь;)
Если серьезно, то основное преимущество utf8 это универсальность и за это можно простить ее некоторые недостатки. Да это по-моему уже и так поняло все прогресcивное человечество;)

Я фуею, дорога редакция... вопрос решаемый. А три порядка в скорости работки всех GNU утилит, решили вопрос или как? Последний раз, когда мне пришлось прописывать LANG=C в скриптах, это был вопрос ТРЁХ порядков.

> UTF-16 позволяет решить проблемы практически всех людей - он охватывает все основные страницы UNICODE от иероглифов до вязи.

После изучения доков по Юникоду (я на Debian Woody сам перешёл на UTF-8) я представляю всё это следующим образом:

1. Первый стандарт Юникод (iso10646-1) - двухбайтовый номер для каждого символа, входящего в тогдашний набор Юникода (кодировка UCS2). 2. Использовать UCS2 не удобно - придется переконвертировать все имена файлов, текстовые файлы и т.д. в ДВУХбайтовую кодировку! (все имена, даже состоящие из одних латинских букв, потому что на КАЖДЫЙ символ теперь надо ДВА байта а не ОДИН). 3. В итоге появляется UTF-8: если байт с кодом ниже 128 - интерпретируется как символ ASCII, выше - как начало UTF-8 символа. 4. iso10646-2 - четырёхбайтовый номер для каждого символа (набор символов iso10646-1 - подмножество нового набора символов) (добавили кучу иероглифов и не останавливаются до сих пор :)). кодировка UCS4 5. с помощью UTF-8 можно кодировать любой символ UCS4. 6. за время между UCS2 и UCS4 было написано некоторое количество софта, ориентированного на двухбайтовую UCS2. 7. для безболезненного (почти) перехода этого ДВУХбайтового софта на расширенный набор символов - создана UTF-16 (смысл работы как в UTF-8, только база теперь 2 байта).

соответственно, похоже всё время путают в постах UCS4 и UTF-16

мой впечатления от перехода на UTF-8: perl работает прекрасно (советую почитать про utf8::encode, utf8::decode), имена файлов переименовал быстро (юзал правда perl а не sh и konwert вместо iconv), в программах на Си действительно работать удобнее с UCS4, а ввод/вывод - UTF-8. как говорилось в доках, при программировании важно различать: 1. количество байт в строке 2. количество симолов строке 3. количество символьных позиций на экране для строки (некоторые иероглифы занимают 2 симв. позиции)

для определения 1. 2. и 3. есть специальные функции.

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

P.S. возможно я в чём-то ошибаюсь. поправьте.

>$ LANG=ru_RU.utf8 uxterm >Warning: locale not supported by Xlib, locale set to C

Смотрим: grep ru_RU /usr/X11R6/lib/X11/locale/locale.* И скорей всего видем ru_RU.UTF-8 вместо ru_RU.utf8

fi

> честно говоря мне похрен проблемы работающих с 3 языками - таких единицы. но раз уж так хотите - UTF-16 позволяет решить проблемы практически всех людей - он охватывает все основные страницы UNICODE от иероглифов до вязи.

Зачем тебе тогда нужен юникод? Выбери себе любую русскую однобайтовую кодировку, третий язык тебе все-равно не нужен.

>> в потоках (байтовых!) не работают

> да объясните - почему UTF8 то работает там?

Потому что поток байтовый (однобайтовый)! А где ты в utf-16 байты увидел?

> ему тоже нужны спецсимволы для вывода за прееделы BMP. так не один ли хрен? экономию он даёт тоже только для BMP. а в коммнетах - пожалуйста, лепи - н о в UTF-16.

Так чем алгоритм работы с utf-16 будет отличаться от алгоритма работы с utf-8 для того же grep'а? Они обе неравномерные, и их отличие только в том, что у одной база два байта, а у другой один.

Экономию ты получишь только для литературных национальных текстов (3 к 2 для русского). Для английских текстов (точнее для текстов на языках, использующих латинский алфавит), программ, отчетов с большим кол-вом цифр проигрыш будет 2 к 1.

>> Кто нибудь видел utf16 или UCS2 локали?

> даа. и не только видел. и даже работает. винду поставь.:-)

А как их в консоли включить?

> А три порядка в скорости работки всех GNU утилит

Так это проблема этих утилит или utf-8? Если эту же задачу решать в perl, такое же проседание производительности будет?

> >а в коммнетах - пожалуйста, лепи - н о в UTF-16.
> редактор не подскажете, который будет это вытворять - C программа ASCII, а коменты в ней
> UTF-16?

вот поэтому-то давно пора исходные тексты программ хранить в XML
- ни тебе проблем с кодировками, ни с разными стандартами форматирования,
всякие нетекстовые ресурсы, опять-такми, можно в едином виде сохранять.

причем все это можно уже сейчас реализовать почти на любом дистрибутиве
а сборка такого софта для конечного пользователя ничем от того
что принято сейчас отличаться не будет

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

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

особо сомневающимся предлагаю посмотреть на leo (leo.sf.net)
-- уникальный в своем роде редактор, и то что данные там
хранятся в xml никому не мешает. а благодаря реализации
literate programming по удобству и универсальности даст фору
многим фичастым ide.

До тех пор пока не будет жёстко задано, что char это четыре байта, а меньше 32 бит кусков не бывает - проблемы будут. Всякие кодировки с переменным числом байт на букву это костыли и костылями останутся как бы их не рекламировали.

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

> Минусы: размер текстов увеличится в четыре раза (это не сильно страшно, так как это не порядок, в всего в четыре раза, кроме того тексты жаться очень не плохо будут)

Да, не сильно страшно.. x.org будет весить не 60mb, как с UTF8, а 240. Это же надо такое сказать - "всего в четыре раза".

Лучше не char в четыре байта, а 32-битный байт. Иначе возникнут проблемы с порядком байт.

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

> ну это только во время компиляции. в остальное время -- бзипу пофиг какую кодировку сжимать ну разве памяти побольше потребуется при сжатии чтобы тот же объем получить

Да при чем тут компиляция. Качать сколько!

> Да при чем тут компиляция. Качать сколько!

От ить упертый. В пожатом виде - СТОЛЬКО ЖЕ.

> До тех пор пока не будет жёстко задано, что char это четыре байта, а меньше 32 бит кусков не бывает - проблемы будут. Всякие кодировки с переменным числом байт на букву это костыли и костылями останутся как бы их не рекламировали.

перейдя в 4 байта переименовать абсолютно все имена файлов и переконвертировать все текстовые файлы?

зачем?

>> редактор не подскажете, который будет это вытворять - C программа ASCII, а коменты в ней UTF-16?

> вот поэтому-то давно пора исходные тексты программ хранить в XML - ни тебе проблем с кодировками

Как он решает проблему хранения ASCII и UTF-16 в одном файле? Или ты на другой вопрос отвечаешь?

> ни с разными стандартами форматирования, всякие нетекстовые ресурсы, опять-такми, можно в едином виде сохранять.

И все дерево исходников запихнуть "в один большой XML-файл". А следующим этапом перейти на бинарный формат хранения.

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

> кстати, в ядре уникод поддерживается? можно, например, сообщения при загрузке на китайском выводить?

Зачем в ядре уникод? Где оно, вообще, с текстом работает?

http://www.robelle.com/library/smugbook/ascii.html
http://www.robelle.com/library/smugbook/ascii.html
http://www.robelle.com/library/smugbook/ascii.html
http://www.robelle.com/library/smugbook/ascii.html
http://www.robelle.com/library/smugbook/ascii.html
http://www.robelle.com/library/smugbook/ascii.html
http://www.robelle.com/library/smugbook/ascii.html

забыл добавить, всех проблем переход в 4 байта не решит всё равно, я уже писал, что буквы могут на экране занимать разное количество символьных позиций, так что zsh и mc в таком случае продолжат глючить.

кроме того, в 4 байтовой кодировке будут нулевые байты, которые большинство софта воспринимает как конец строки. Всё переписывать???

> http://www.robelle.com/library/smugbook/ascii.html

это Вы к чему?

>Лучше не char в четыре байта, а 32-битный байт
Да, в идеальном мире это было бы решением. Все просыпаются утром, опа, а байт уже 32-битный. И в придачу емкость всех носителей информации осталась прежней только уже в новых байтах. Ляпота;)
А в реальной жизни что делать с огромным зоопарком аппаратно-програмных платформ?

> UTF-16 в топку! не UTF-16 в топку, а UTF-8 Да задравствует UCS-2 & UCS-4

> От ить упертый. В пожатом виде - СТОЛЬКО ЖЕ.

а если из cvs?

когда из cvs - указываешь сжатие -z3 например :)

> Как он решает проблему хранения ASCII и UTF-16 в одном файле? Или ты на другой вопрос отвечаешь?

очень просто. в зюмеле хранится юникод. компилятору (или что у вас там -- интерпретатор, groff какой-нибудь ) он скармливается в родном для компилятора виде через соответствующий xslt-фильтр.

а как это отображается на файловую систему -- дело десятое. посмотрите как это сделано в том же leo.