>Готов поддержать UCS2[4] так же как поддерживаю UTF-8. Для меня,
>если честно, не очень важен в данном случае способ представления
>уникода. Для меня важен сам уникод.

2svu: Я считаю, что правильно бы было оставить консоль 8-ми битной,
а все Х-овое на utf-8... Это было бы правильнее с точки зрения большого
кол-ва консольных приложений, которые никогда юникодными не станут,
а если станут, то эта работа затянется не на один год, проще проделать
работу по сосуществованию koi8-r и utf-8 вместе, чем консоль обучать
utf-8....

> Не понял. Их по любому придется "парсить", что бы вычислить длинну - хотя бы тем же strlen(). Так какая нафиг разница ??

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

anonymous

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

В каком смысле "только так" ?? И AFAIK утф-8 - однобайтная кодировка. За что ее все так любят.

> Не проще ли вставлять коды переключения страниц?

Т.е. сделать свою версию утф-8 ?? :-))))

> каком смысле "только так" ?? И AFAIK утф-8 - однобайтная кодировка. За что ее все так любят.

Перекодируй какой-нибудь русский текст в utf-8 и посмотри на него. Для однобайтной кодировки многовато \xD0 \xD1. IMHO разумеется. ;)

> Т.е. сделать свою версию утф-8 ??

Хуже быть уже не может ;)

> Перекодируй какой-нибудь русский текст в utf-8 и посмотри на него.

Мы, видимо, о разных вещах говорим :-))) УТФ-8 однобайтовая, потому как в ней данные представленны __как последовательность единичных байтов__. В отличии от остальных форм юникода, где в качстве единиц хранения идут 16-ти и более битные слова. А вовсе не в том смысле, что в ней одному символу соответсвует один байт. :-))) Как бы она тогда была юникодной ?? :-)))))

> Хуже быть уже не может ;)

Может. Любая codepage :-)))))

> Мы, видимо, о разных вещах говорим

Безусловно.

> Как бы она тогда была юникодной ??

Элементарно. В строку вставляются управляющий код (ну можно же пожертвовать одним значением < 256) и номер кодовой страницы, что означает "рассматривать последующие байты символами такой-то кодировки".

Re:

ясно! но просто жду ченить-типа 8.2 чтоб сразу работало а гцц новый хочется. и glibc. так что хотелось на относительно прямой дистр все это просто поставить. кстати чем меня заколебал генто, угадайте с 3-х раз? правильно - компиляцией :). машина - п2-266, мозила часов 16 собиралась. гсс - полдня и тд и тп. вообщем гентоо дистр для новых компов получается.

bad_karma

>>проще проделать работу по сосуществованию koi8-r и utf-8 вместе, чем консоль обучать utf-8....

ежели честно, то не понял.. а какая работа для этого требуется??
кто/что мешает пользовать это сейчас?
Кроме того, лично мне не понятно, а какие такие кирилистические(в свете koi8-r) приложения нужны в голой консоли? примеры есть?? или это из области я не могу жить без русских названий в MC.

>>В строку вставляются управляющий код (ну можно же пожертвовать одним значением < 256) и номер кодовой страницы, что означает "рассматривать последующие байты символами такой-то кодировки".

Я уж не буду говорить о БД, но как вести себя примитивному grep в этом случае??
%)

to LamerOK
Да, настолько плохо, пока, иные кодировки (отличные от локали) не поддерживаются для ext.
"Парсить" - это гемор не в 0.003%. Провёл эксперемент, У меня простейший пример RightTextEditor на базе Qt сэмплов. Нативно, он хранил и работал с UCS2 кодировкой. Небольшие манипуляции - и всё заставил :-) работать в UTF8. Я понимаю, что не совсем корректный эксперемент, но загрузка для данного приложения при переформатировании документа в 100КСимволов возрасла с <1% до 2% А если таких фенек несколько? А если это везде? Логика простая: пример: 1 строка, 128 символов, операция вычисления длины строки (strlen) для UCS кодировок:

ucstype* mstr;
...
int i = 0;
while ( mstr[i] != NULL ) i++;

Теперь возьмём парсенье с unicode.org для не UCS строк

char* mstr;
int i = 0;
int j = 0;
while ( mstr[j] != NULL)
{
if ( mstr[j] < 0x80) { i ++ ; j++;
} else if (mstr[j] < 0xC0) { i ++ ; j += 2;
} else if (mstr[j] < 0xE0) { i ++ ; j += 3;
} else if (mstr[j] < 0xF8) { i ++ ; j += 4;
} else if (mstr[j] < 0xFC) { i ++ ; j += 5;
} else { i ++ ; j += 6;
}
}

Теперь, как видите, всё стало намного веселее :-). А теперь представьте, где этот механизм может применится? Сколько раз? Да каждый раз, когда надо:
а) Вывести строку
б) Перейти к символу строки
в) Слияние, сравнение ...
и.т.п. Вместо mstr[i] (хотя, это весьма не кошерно, но будем считать: что вызываемая функция для работы с моноширинной кодировкой поступает также просто) вы вызываете целнУ :-) Толстую функцию! :-)
А сколько таких изворотов, допустим, за сеанс grep ? Тут на каждый вызов такой бодяги + 700% :-) Тот-же стлен в 7 раз (это по-скромному) дольше выполняется :-)...
К тому-же, являюсь любителем строгих, ровных, данных :-) Однородных - а тут такая кривизна :-)
Надеюсь, я хоть когото убедил - что UTF8 (в меньшей степени UTF16) это ж. с ручкой. :-) На не-английских локалях :-)

Теперь про то, каким боком мимы подвязались :-)
- ну, вообще - этоа бодяга сама по себе кульная :-)
- если будет некий переход, то надо будет както разгребаться в этом зоопарке - с мимами - это будет более весело :-) и более автоматично :-)
....
(достало уже писать. В ДР, тем более :-))

>>Надеюсь, я хоть когото убедил - что UTF8 (в меньшей степени UTF16) это ж. с ручкой. :-) На не-английских локалях :-)

да жопа, это давно известно, поэтому в активно нагруженых СУБД пользовать unicode вообще не рекомедуеться.

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

Что касаеться имеено UTF-8, то на мой вздял, самая ублюдочная реализация юникода. Но увы, "ехать против движения" не рекомендуеться. Потому и приходиться пользоваться...

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

Начнем хотябы с имен файлов созданных с русскими именами, в локале
koi8-r это будут в кои8, а в utf-8, естественно в utf-8....

>>Начнем хотябы с имен файлов созданных с русскими именами.

Ну это проблема всех времен и народов (у которых алфавит отличен от latin-1). Универсального решения , наверное, не существует, ибо если бы оно было, то уже давно бы его реализовали. (спросите у русскоязычных ITшников как они любят немецкие умляуты на шаровых дисках) так что с эти надо либо мириться (тихо матярясь про себя) либо в административном порядке запрещать использование отличных от latin-1 символов в именах файлов, паролях и т.д.

LamerOk:
   >  utf8  локаль это как золотой крестик весом в 1кг на шее - модно, но
   тяжело, очень дорого,

   Издеваетесь  ??  "Тяжело" ?? "Дорого" ?? Да линукс от темечка до пяток
   весь  обвешан таким количеством свиселок, гуделок, пыхтелок и наколок,
   как  ни  одна другая ось ! Тут хоть реально стоящую вещь предлагают, а
   не  очередной  "прозрачный  терминал",  или  "графический  фронтенд  к
   /bin/cp".
Образец потребительского отношения. А кто это делать-то будет?
   > нефункционально
   А iocharset'ы и codepage'ы - это функционально ???
Это называется гибкость юниксов.
   > и то, без чего спокойно можно обойтись.
   Определенно издеваетесь. Обойтись можно и без русского языка. У R&T на
Странно, жили без утф8 пять лет - а потом оказывается что без него жить
нельзя..
----
   Ещё есть вопросы сортировки символов .... но это вообще труба :-)
   ЗЫ:) ИМХО, всётаки лучше мимовую фс + система на UCS2-UCS4 :-)
Они как раз сильно упрощаются при юникоде и utf8..
----
   >  а  почему  тогда  сразу не перейти на UCS2[4]? сказать gcc вот, мол
   char теперь 4 байта и вперед с песней?

   Собственно,  об этом en и вел речь, как я понимаю? Ибо UTF-8 - грязный
   хак(tm),  для  облегчения  перевода 8-битных систем... А вот когда все
   будет UTF-8 - будет очередной этап перевода с него на UCS4 :))))
Ну может в далеком будущем. Мне вот лично не хочется чтобы объем РАМ моих
машин практически уполовинился/учетверился если произойдет переход на
UCS2/UCS4.
 Хотя программирование это крайне облегчит. Единственная проблема - чтобы
FS давала указывать имена в UCS (сейчас же большинство fs не дает нулевой
байт в имени использовать, посему облом с юникодом).
 Да и написано очень много софта - его одним махом не изменить..
 Ну и еще, глядя на поток UCS2/4 символов (допустим при сниффинге) нельзя
сказать точно что именно передается так как мы не знаем какой байт соотв.
НАЧАЛУ каждого юникодного символа. В utf8 такой проблемы нет. Ну и еще нет
проблемы с порядком байтов в слове при внешнем представлении (хотя для
случая уникода можно договориться - что всегда храним в сетевом, но тогда
на x86 придется строки нормализовать при вводе/выводе..).
----
   Cимвол  евро  (и  фунта,  кстати)  может пригодиться в плейн-тексте...
   Запросто.  Набрать  его в клавиатуре - не проблема. Прислать раскладку
   для  иксов?:) Про "раздувание данных" и их компрессию любым способом -
Думаю что в 99% вместо символа евро можно вставить EUR и хуже автору и читающим
не станет.
   Про  русских  в  Европе  -  это я должен воспринять как наезд?:) А как
:) Нет, как констатацию факта.
   насчет  русских,  ведущих  дела  с  Европой? То, что символ доллара Вы
Как я уже сказал, можно вбивать EUR и все будет пучком..
   можете  использовать  -  это  нормально?  А вот символ евро - ненужная
   роскошь? (опять же, о фунте упоминать не буду).
Ну а у рубля вообще нет символа :) И живем же..
-----
   Готов  поддержать UCS2[4] так же как поддерживаю UTF-8. Для меня, если
   честно,  не  очень важен в данном случае способ представления уникода.
   Для  меня  важен  сам уникод. Только америкосам будет очень сложно - а
Уж тогда голосуй сразу за уникод :)
Просто всего гемора по переходу на utf8 (переписыванию некоторых программ)
легко избежать если перейти сразу на юникод..
-----
   >  Вот  была  кои,  поставвил  РХ8  -  и пользовательским названиям на
   русском - можно сказать "до свидания" :-)

   Все настолько плохо ??? Я думал, они хоть как-то поддержат чтение имен
   в иных кодировках.

Просто fs возвращает что там записано (а там в koi8r), а проги пытаются
трактовать строку как utf8 и обламываются.
   >  С  utf8  в  самом  деле  хак,  ведь для вывода (экранного) придётся
   парсить   все   строки,  чтобы  правильно  вычислить  длину  строки  в
   отображаемых символах:

   Не  понял.  Их по любому придется "парсить", что бы вычислить длинну -
   хотя бы тем же strlen(). Так какая нафиг разница ??
Так как utf8 - многобайтовая, кол-во символов всегда <= кол-ва байт.

Я так понимаю что никто в Гноме с консолью не работает? :) Тем более с русским языком...мда. Жаль.

>>Я так понимаю что никто в Гноме с консолью не работает? :)

Хмм..:)) А что там не так? Поменяй font. :))

ifconfig

> Я уж не буду говорить о БД, но как вести себя примитивному grep в этом случае?? %)

А как он вел себя раньше, так пусть и дальше ведет. Кстати как он (grep) ведет себя с utf-8? Управляющий код + номер кодовой страницы - та же "образцовая" последовательность байтов.

:)

Естественно самое прямое решение (сегодня) - ucs-2, вот только ia32 с 16-битами не в ладах: код опухнет за счет одних только префиксов и movzx/movsx.

>>А как он вел себя раньше, так пусть и дальше ведет.
да ну %)

>> Кстати как он (grep) ведет себя с utf-8?
нормально, он ищет шаблон. шаблон в тойже кодировке.

>>Управляющий код + номер кодовой страницы - та же "образцовая" последовательность байтов.

ага, а ну ка изобрази к примеру поиск шаблона ^[г-д] ежели "Управляющий код" на другой строке остался...

> Думаю что в 99% вместо символа евро можно вставить EUR и хуже автору и читающим не станет.

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

То, что у рубля нет символа - исторический факт. Но вот если бы он был - мы бы имели полное право требовать использовать его при переписке вместо дурацкого RUR. Поэтому - давайте уважать соседей, ага?

Я могу голосовать сразу за уникод как представление - просто мне сложно представить его широкое внедрение (пока). Именно потому что англоговорящие будут "против" (ну любят они решать проблемы за счет "остальных"!). Итак, я голосую за уникод как идею - при любой кодировке (UTF-n/UCS[m]/....). Путь внедрения - от десктопа в консоль (Извините, но если внедрять наполовину - бардак выйдет. В том же xterm...) Голосую ПРОТИВ любых codepages и прочих проявлений 8-битности: поддержка совместимости - да, опция по умолчанию - нет (возможно, не прямо сегодня, в пределе:)

ifconfig

>> Кстати как он (grep) ведет себя с utf-8?

> нормально, он ищет шаблон. шаблон в тойже кодировке.

:)

> ага, а ну ка изобрази к примеру поиск шаблона ^[г-д] ежели "Управляющий код" на другой строке остался...

Какой-такой другой? :)

Даже если вы делаете такую глупость как split по "\n", что вам мешает сохранять контекст при переходе на следующую строку?

Огромное преимущество utf8 - его обратная совместимость с ASCII. Англоговорящий пользователь разницы не заметит, а большинство компьютерных текстов ведь на английском, и англичанину трудно будет объяснить, зачем его текст должен стать в 2-4 раза толще (UCS2[4]). utf8 легко можно использовать в коментариях C программ, в HTML, XML ... (Кто нибудь может написать коментарий в C программе на UCS2[4] ;) utf8 в будущем может быть использован в URL (технически это проще, чем остальные вырианты уникода, так как он трактуется побайтно) Поэтому utf8 из всех вариантов уникода наиболее универсален и переносим. Более простые с точки зрения обработки варианты уникода могут быть использованы как внутренний формат (MS WORD и UCS2 ;)) а для обмена/пересылки/хранения utf8 конкурентов нет. Сложности с обработкой наверняка можно переложить на библиотечные функции (со старыми программами тут, конечно сложнее), а там глядишь и INTEL выпустит новый процессор с utf8 расширениями ;)

>>Какой-такой другой? :)
в какой какой... в предылущей к примеру.
вы имеете что-то против разделения строк \n (\r\n)???
У вас на этот счет тоже есть ДРУГИЕ варианты??

>>что вам мешает сохранять контекст при переходе на следующую строку?

как ты это объяснишь(контекст в смысле) regexp выражению, которое предварительно скомпилировано к определенному виду..

и еще, вместо того чтобы аппелировать, привел бы пример реализации.

2ifconfig

> вы имеете что-то против разделения строк \n (\r\n)???

Я не понимаю зачем в данном случае (grep) вообще разделять на строки. ^ - обычное утверждение, ничем особо не примечательное.

> У вас на этот счет тоже есть ДРУГИЕ варианты??

Ага, я мир собрался спасти :) Просто я пытаюсь сказать, что даже в этом кривом "наколеночном" способе кодировки проблем меньше, чем в utf-8.

> как ты это объяснишь(контекст в смысле) regexp выражению, которое предварительно скомпилировано к определенному виду..

man flex :)

> и еще, вместо того чтобы аппелировать, привел бы пример реализации.

Ради интереса - почему не попробовать сделать самому. Хотя я уверен, что подобная мысля кому-нибудь да стукнула в голову ...

2 anonymous (*) (2002-11-25 21:42:08.01)

> и англичанину трудно будет объяснить, зачем его текст должен стать в 2-4 раза толще (UCS2[4]).

А русскому, значить, легко объяснить почему при переходе на utf-8 его текст стал почти в два раза толще? Основной недостаток "интернационализации по американски" в том, что теи кто ей занимается, плевать на тех кто ей пользуется.

> utf8 легко можно использовать в коментариях C программ, в HTML, XML ... (Кто нибудь может написать коментарий в C программе на UCS2[4] ;)

В С++ можно - \U01ABCDEF, \u1234 - вот только читать это трудновато :)

> utf8 в будущем может быть использован в URL (технически это проще, чем остальные вырианты уникода, так как он трактуется побайтно) Поэтому utf8 из всех вариантов уникода наиболее универсален и переносим. Более простые с точки зрения обработки варианты уникода могут быть использованы как внутренний формат (MS WORD и UCS2 ;)) а для обмена/пересылки/хранения utf8 конкурентов нет. Сложности с обработкой наверняка можно переложить на библиотечные функции (со старыми программами тут, конечно сложнее), а там глядишь и INTEL выпустит новый процессор с utf8 расширениями ;)

Абсолютно не согласен. Разнобайтовые кодировки - г..., со всех точек зрения. Число символов всегда должно быть равно числу байт. Единственное приемлемое решение - 16-битовый байт :)

IoP (*) (2002-11-25 23:16:28.676) К сожалению, 16 битный байт всех тоже не спасет (китайцев например), поэтому в идеале нужен 32 битный или UCS4. Но это в идеальном мире, в реальном, как показывает история, побеждают решения, имеющие обратную совместимость (линейка процессоров Интел, виндовс(дос))... utf-8 обратно совместим и поэтому имеет шанс.

>> как ты это объяснишь(контекст в смысле) regexp выражению, которое предварительно скомпилировано к определенному виду..

>man flex :)

вы явно не понял..
man regcomp %)

или компилить перекомпилять regexp "на лету" после очередной смены "кодовой страницы" %)

начет utf-8. Да я же и тоже говорю что она ублюдочна "по самое немогу".. Но пока это единственая реальноработающая альтернатива отжившим В СЕТИ однобайтовым кодировкам. Но однобайтовые кодировки не умрут пока мощность компов не достигнет того, чтобы можно было принебречь вычстроковыми операциями в БД.

IoP

> Элементарно.

Я вообще то об утф-8 говорил :-)))

asoneofus

> А теперь представьте, где этот механизм может применится? Сколько раз?

Я более или менее знаком, с тем, что такое утф-8 и как оно выглядит. :-) Но ведь ты же не страдаешь от горя при переводе данных в сетевой формат ?? :-)))

> К тому-же, являюсь любителем строгих, ровных, данных :-)

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

ЗЫ. С днем варенья !!! :-)))

hvv

> Образец потребительского отношения. А кто это делать-то будет?

1. А разве мы сейчас это обсуждаем ?? 2. Вот РедХат к примеру взялся. За гуж, я имею в виду :-)))

> Это называется гибкость юниксов.

Такой "гибкости" за глаза в DOS'е имеется.. :-)))

> Странно, жили без утф8 пять лет - а потом оказывается что без него жить нельзя..

Так и без телефонов, и без канализации жили. И что теперь ? "Назад в пампасы ?" (с) один из посетителей лора

> Мне вот лично не хочется чтобы объем РАМ моих машин практически уполовинился/учетверился если произойдет переход на UCS2/UCS4.

Сдается мне, вы сгущаете краски. Если конечно, ваша машина не занята исключительно обратоткой "чисто текста". А иксы графику в памяти не в xpm, слава богу, хранят :-))

> Просто всего гемора по переходу на utf8 (переписыванию некоторых программ) легко избежать если перейти сразу на юникод..

Дык и не надо переходить на утф8 ВЕЗДЕ. Любой другой вид юникода куда как лучше. Но в некоторых случаях выбора то нету.

> Так как utf8 - многобайтовая, кол-во символов всегда <= кол-ва байт.

Ну и ?? (оставим в стороне разногласия по поводу "одно-" и "многобайтовости"). Ну согласен, придется изобретать utf8strlen (), так как ни strlen (), ни wcslen () из glibc не прокатят. А куда деваться то ?? Есть выбор ?? :-(((

2ifconfig

> вы явно не понял..

> man regcomp %)

> или компилить перекомпилять regexp "на лету" после очередной смены "кодовой страницы" %)

Да, я тебя перестал понимать (надеюсь не взаимно ;) ). Зачем "перекомпилять" regexp, когда все необходимые переключения уже "вкомпилены" в него? Regexp'у даже не нужно понимать, что эта последовательность символов переключает страницу, она просто должна присутствовать (последней). С perl'овыми regex'ами похожее можно сотворить уже сейчас.

А flex я упомянул, чтобы показать, как сочетаются зависимость от контекста с регэкcпами :)

> начет utf-8.

Да не о чем спорить. Ты считаешь, что соображения совместимости оправдывают использование utf-8. Мне так не кажется, так как сохранять совместимость с проблемным решением - значит тащить его проблемы с собой.

> Только мне казалось, что важнее возможность использования национальных символов ...

А кто сейчас их мешает исползовать ?? :-)))) И каким боком первое мешает второму ???

> А кто сейчас их мешает исползовать ?? :-)))) И каким боком первое мешает второму ???

Подразумевалось, что словосочетание "использовать уникод" подменяется словосочетанием "использовать utf-8".

P.S. А сообщение я уже удалил. Извиняюсь.

Hi! Будьте добры - растусуйте молодому - какой шрифт мне нужно подпихнуть в konsole (или же в gnome-terminal) дабы миднайт командер не корячило?Предыстория : был апгрейд с 7.3 до 8.0 и было локализовано, следуя указаниям уважаемого McMCC.

Заранее благодарен,Дмитрий.

>Hi! Будьте добры - растусуйте молодому - какой шрифт мне нужно
>подпихнуть в konsole (или же в gnome-terminal) дабы миднайт командер не
>корячило?Предыстория : был апгрейд с 7.3 до 8.0 и было локализовано,
>следуя указаниям уважаемого McMCC.
>
>Заранее благодарен,Дмитрий.

На той же страничке http://rh8koi.narod.ru или на зеркале http://mcmcc.bat.ru,
которое имеет довольно высокую скорость доступа, я добавил раздел
"Дополнения", там этот вопрос рассмотрен, а так же добавлена инструкция по
установке Nvidia драйверов для тех, у кого возникли с этим проблемы, плюс
обновления для консольного MP3 плеера - mpg123...

Насчёт утф-учс :-)
У меня есть тачки на XMS хаканых процах. Там нет обращения с 8-битам, и в любом случае там char = short = int = 32 bit
Сильного раздутия ничего не замечено, кроме маааленькой "привычки" - всё лежит в gz - открывается "автоматом" многими прогами, и абсолютно не напрягает.
Взяться бы на досуге, и скомпилить всё с 32-зарядным символом на ia32(64): -( (как бы это дело подхачить, чтобы на уровне gcc всё так и было)... но это мечты

Кстати, смешная штука случилась. После моего "фикса" intltool произошла большая драка по поводу .po файлов. И было принято _волевое_ решение, что отныне в гноме .po должны быть только в utf-8. Наши в городе!:)

http://mail.gnome.org/archives/gnome-i18n/2002-November/msg00162.html

"The decision to use UTF-8 as the mandatory encoding for all GNOME 2.x po files has been made. Please accept that."

I love this game!:)

В КДЕ они всю дорогу в utf-8 :-), хотя возможность поддержки иных кодировок вроде как была.. :-)

">А проблема с МС из под Хтерминала осталась :(((((( Текстовый нормально, а >вот иксовая консоль КРЯВАЯ!!!!!! :((((

2vada: Нет там никаких проблем, ставишь хтерминалу фонт Andale Monо и все становится нормально...."

Я чайник. Подскажите где так можно настроить иксовую консоль. Что в KDE что в Gnome консоли в опциях очень мало шрифтов Какие конфиги нужно править и есть ли этот шрифт в Красной Шляпе Если нет то где его найти Заранее спасибо

А пробовал кто-то пускать mc через frame bufer? Пишу в grube - vga=788 и что вижу? Сплошные квадратики!!!!!!!!! И еще, в KDE под рутом все нормально, а под обычным пользователем новых шрифтов не видать :(

Привет всем. Хотел бы выразить свою благодарность уважаемому McMCC за свой труд.

Однако проблема со шрифтами и MC оставалась после всех описанных манипуляций, чем я был крайне раздражён. Оказалось что доп. шрифты были установлены - но не были видны в KDE applications.

И только после того как я создал ~/.fonts и залил необходимые шрифты - тогда и только тогда они стали доступны для KDE, а также для терминалов.

С уважением, Дмитрий.

Спасибо,SVU. Это действительно, классная новость. Эра UTF8 - наступает! Кто не понял, пусть барахтается в KOI8 и морочит голову молодым юниксоидам, хотя это, по большому счету, можно рассмотривать как вредительство и кастрацию революционного дистрибутива. Хочу обратиться не к мэтрам (ну привыкли ребята работать - пусть работают), а к новичкам - не лезьте в коизацию - завтра придется переучиваться.

Коизация и утф8изации - одного поля ягоды: хотя, кои-то как раз - поровнее будет.
Народ, а ктонить линки подкинет на UCS4 проект, тот что АЕН упоминал?

X - Server "Down" after give command "LANG=ru_RU.KOI8-R movaTK"

В свое время меня тошнило от M$ Ну не знаю почему Не задумывался. Чувствовалась шаткость. Хотя все работало Но это если честно уже психология(по мне) Перешел на УНИХ Было тяжко да и сейчас новичок ну не вундер короче. Был сильно обрадован всей политикой проводмимой в этой среде что не проблема то гимморой но зато потом - счастье аж со слезами вот такого от мертвой системы никогда не ждал. Видно, что Red Hat задает все права в этом мире и не в лучшую сторону. И также видно что делается это с определенной настойчивостью Что как система подходит на нормальный десктоп то новое ядро Второй раз - новая gcc Третий новая кодировка Нет систем эта есть правда этой нашей человеческой психологии - куда нам смерть! нам жизнь и борьба нужна ну и лучше это всяких OS$ Если честно, страх. А вот представьте, что эти фирмы перейдут на коммерческую политику. Это же совсем другое отношение. А чем они не "люди"?

2All: Я тут выпустил новую версию своего варианта mpg123, взять
можно с http://mcmcc.bat.ru или http://rh8koi.narod.ru. В новой
версии я добавил поддержку тэгов версий id3v2.2 и id3v2.3, чего
раньше небыло, и естествено работает recode для русских тэгов...

Очень интересная, и если не обращать внимания на высказывания типа "сам дурак", нужная дискуссия. Допустим, ознакомившись с различными мнениями, я стал горячим сторонником Unicoda и даже UTF8. Из дискуссии все же не ясно, как я теперь должен жить. Увы, я и мои коллеги, которые профессионально используют Linux, но не являются его разработчиками, накопили довольно много текстовой информации в теперь уже устаревающей кодировке KOI8. Объем этих данных -- террабайты и быстро перевести их в UTF8 просто невозможно, да к тому же и не нужно, поскольку не все мои коллеги и сотрудники испытывают счастье работы в RH8.0, а некоторые (вот чудаки) и вовсе еще работают даже не на пентиумах, а на 486 или 386 машинах, и поставить RH8.0 не имеют возможности. Проблема состоит в том, что, если и нужно переходить на Unicod, то переход этот будет растянут, и какое-то время придется работать и в старой и в новой кодировке. Поэтому, если бы RedHat или его горячие сторонники создали удобные средства и прозрачную методику работы сразу с двумя кодировками, или быстрого перехода от одной кодировки к другой, переход к Unicodу для простых пользователей был бы более безболезненным. Вообще об этих "простых пользователях" как-то не принято много думать, а ведь их значительно больше (и должно быть больше!), чем разработчиков. Взять хотя бы непомерно возросшие требования к ресурсам компьютера, или замену уже привычных программ их менее удачными аналогами. Один мой коллега, например, собирается переходить из RH7.3 в RH6.2(!) только потому, что привычный gv вдруг стал работать много медленнее, чем в более ранних версиях RedHat, а предлагаемый вместо gv ggv работает, конечно, быстрее, но менее удобен, чем старый gv. Боюсь, что и трудности необходимого перехода к Unicodу могут затянуть для простых пользователей сам этот переход.

Желающий перейти на Unicod, но как???

Отстой

Итак. Неудобства новой кодировки для пользователя очевидны - это снижение эффективности, неоправданное раздувание информации в два раза, небезопасность, масса проблем с переходом на 16bit и т.д.

А вот преимуществ (для _нашего_ _пользователя_, не для китайского или американского) в общем-то нет. Не смешите меня символом евро в plain text. Раздувания русского текста вдвое это совершенно не оправдывает.

Поэтому если у нашего пользователя будет выбор (на что хочется надеятся), то вся эта хреновина не приживется. За ненадобностью.

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

БОльшая часть информации никак переходом на UTF-8 локаль не затронута. А именно - код _корректных_ программ, файлы не-текстовых документов (надеюсь, рассказывать, что пресловутые MS форматы внутри уникодные - никому не нужно?). Таким образом, "раздувание" коснется только текстовые документы (.txt), которых, думается, у людей не так уж и много. С БД - отдельная история (хотя, если хотите, можем и про нее поговорить).

Ладно, символ &euro; Вам не указ. Хорошо. А просто имена людей, встречающиеся в email - там ведь тоже разные символы бывают (с точечками, палочками и пр.). Например, один из заметных хакеров на dri.sourceforge.net носит славное имя Jose. И последняя буковка там, если печатать ее корректно, должна иметь косую палочку сверху (сорри, запамятовал, как бишь ее называют лингвисты). Не просто 'e', а 'е' с палочкой. И, если говорить строго, написание этого имени некорректно является невежливостью. Или Вам так дорого число 8, что Вы готовы быть невежливым?

Про сервера международных компаний, где русские и немецкие имена файлов могут жить рядом, тут уже говорилось... А ведь таких компаний в России - совсем не мало. И, хочется надеяться, будет еще больше (есть такое приятное словосочетание "иностранные инвестиции"). Это насчет _нашего_ пользователя.

И очень хочется верить, что если выбор реально будет (т.е. он не будет определяться множеством несовместимых с не-8-битностью прог, а только _свободной_волей_ пользователя) - то эта "хреновина" приживется. В силу бОльшей правильности, чем 8-битные кодировки (хотя, конечно же, лучше бы UTF-18 или другие 2 и 4-байтные кодировки уникода - но это, увы, пока не очень реально).

Так что, будучи РУССКИМ пользователем (и РАЗРАБОТЧИКОМ, немного), я готов терпеть временные неудобства в обмен на потенциальные возможности. Чего и Вам желаю. "Лучше день потерять, зато потом за час добежать" (с) "Крылья, ноги, хвосты"

Мне кажется, "горячим" поклонником UTF-8 становиться, все же, не стОит - не самая это лучшая кодировка для уникода. Хотя и самая "реалистичная".

Извините, а как Вас угораздило накопить террабайты текстов? Без БД? Это Вас именно "угораздило". Если есть БД - тут можно нужно аккуратненько заняться миграцией в уникод. Возможно, через dump/restore, текстовое представление и пр. Короче, с БД нужно разбираться по месту (насколько я знаю, большинство приличных СУБД вполне достойно держат как 8-битные, так и уникодные кодировки - поправьте, если вру).

Если же у Вас именно тексты - iconv Вас спасет.

Или все-таки у Вас что-то другое?

Да, старая техника - это проблема. Старые дистрибуты без уникода, мало памяти и пр. Да, я эту боль понимаю. Я действительно НЕ ЗНАЮ, как с этим поступать (возможно, дизайн инфо-систем с xml мордой слегка упростит жизнь, но все проблемы этой мерой не решить - индивидуальные "гайки" наверняка будут попадаться - да и ресурсов этот xml все-таки требует...).

И, как я уже утверждал, РХ80 - это не для "простых пользователей". Это "концепт-кар" или revolution #8. Подождите до 8.1 (или, лучше, 8.[23]). Свет в конце тоннеля есть. Только до него идти надо, а не "нас и здесь неплохо кормят" (виноват, этот призыв опять же не к Вам, а к разработчикам и составителям дистрибутов). Пока, как мне кажется, дело до "простых пользователей" просто не дошло (это им сильно повезло:). Просто "Будьте Готовы"! Хотя, дорасти до разработчика (или хотя бы активного тестера) никому не возбраняется:)

Увы, увы, увы - не бывать линуксу популярной в народе настольной пользовательской ОС... И сами же линуксоиды тому являются причиной. Что мы сейчас наблюдаем в действии.

>пресловутые MS форматы внутри уникодные

Уникодны только внутренние форматы (doc и пр.) В своих пресловутых MS-форматах MS вольна хранить всё, что ей угодно. Потому что они внутренние и никого не касаются. Поэтому ни одного пользователя при переходе офиса на юникод не пострадало: никто его просто не заметил. Однако желающие всё равно могут работать с doc-файлами в однобайтной кодировке, используя экспорт в Word95. Размер файла при этом уменьшается почти в два раза.

MS уважает своего пользователя - при всех недостатках своих. Она его не заставила перекодировать все свои документы руками в новую кодировку. Все 8-битные программы, использующие cp1251 и cp866, сохранили свою работоспособность. MS поступила вежливо и коммерчески правильно.

>"раздувание" коснется только текстовые документы (.txt), которых, думается, у людей не так уж и много

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

>просто имена людей, встречающиеся в email

Если Вы просто общаетесь по email с лицами западноевропейских национальностей, то Вы можете просто набрать своё письмо в кодировке latin1. Проблемы могут действительно возникнуть только если переписка будет вестись одновременно на двух неанглийских языках. Часто ли это бывает, скажите мне? Однако из уважения к разноговорящим полиглотам допускаю, что в данном конкретном случае юникод может быть оправдан. Как ещё одна дополнительная почтовая кодировка для особых случаев. Но не более того.

>сервера международных компаний

опять же - специальная кодировка для кодирования URL

>есть такое приятное словосочетание "иностранные инвестиции

если мы будем позволять Западу постоянно вытирать об себя ноги - в т.ч. введением всяких кодировок и пр. - подачек от него придется ждать крайне долго и нерегулярно ;)

>бОльшей правильности

Что Вы понимаете под правильностью? Коммерчески это неправильно (см. пример MS, которая здесь ориентир), тогда как?

>я готов терпеть временные неудобства в обмен на потенциальные возможности

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

>Извините, а как Вас угораздило накопить террабайты текстов? Без БД?

Зачем терабайты? Если текст, который раньше помещался на дискету, перестал на неё помещаться - это уже ощутимое неудобство. Ради чего я должен его терпеть?

>Это Вас именно "угораздило".

Вы мне будете указывать, как мне жить, да?

>нужно аккуратненько заняться миграцией в уникод. Возможно, через dump/restore, текстовое представление и пр.

Вы мне предлагаете совершить весьма неслабый объем работы. Опять же, ради чего? Может быть, проще мигрировать в windows раз и навсегда ;)

>Если же у Вас именно тексты - iconv Вас спасет.

Что это такое и от чего он меня спасёт? От несовместимости dvi-файлов (которые зависят от кодировки) он меня спасёт или нет?

>Старые дистрибуты без уникода

WindowsXP - это "старый дистрибут"? Куда я там засуну теховские файлы в юникоде? Или MS Вы решили напрочь игнорировать? И каким образом xml может упростить здесь мне жизнь?

>РХ80 - это не для "простых пользователей". >Пока, как мне кажется, дело до "простых пользователей" просто не дошло

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

> Однако желающие всё равно могут работать с doc-файлами в однобайтной кодировке, используя экспорт в Word95.

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

>Решать за других, не спрашивая Разница между навязыванием и активным продвижением достаточно тонкая. Боюсь, мы с Вами понимаем ее по разному. Впрочем, возможно, Вы вообще являетесь противником активного внедрения новых технологий:).

> специальная кодировка для кодирования URL URL тут не при чем. Я - про файловые сервера.

> если мы будем позволять Западу... Прекрасно, своих денег нет (те, что получаем за нефть, уходят в 2-3 очень толстых кармана). И чужих нам тоже не надо. Национальная гордость великороссов - вечная тема... Давайте замнем ее в этом треде, ладно?

> Что Вы понимаете под правильностью? Отвечу. Уничтожение проблемы 5 (или более?) русских кодировок. Возможность одним движением руки вводить тексты на бОльшей части языков человечества. И стройность, последовательность архитектуры всего это (без 8-битных "дыр"). Это все неправильно?

> А я не хочу терпеть... Я не прав? Это Ваш выбор. Вы его сделали осознанно (будем так считать). Вопрос в том, что IT people часто решают за людей, которые сами не могут сделать осознанный выбор (пользователей). И вот хотелось бы, чтобы в этот ответственный момент в их (IT) головах была некая система технологических ценностей. Одна из ценностей - здоровый консерватизм. Вторая - видение вперед и вверх. Вопрос в балансе...

> раньше помещался на дискету

Да, в обстановке, когда размер измеряется дискетами - наверное, уникоду делать нечего. Я когда-то тоже так жил. И каждый процент сжатия у архиваторов считался достижением. Что же, можно жить и так. Только очень печально. В 2002 году... Хорошо, в подобных условиях уникод сочтем безусловно неуместным. Только добавим для определенности и объем памяти - 4М и ниже:)

> Вы мне будете указывать, как мне жить, да?

Возможно, мой утверждение прозвучало как наезд. Сорри. Учить я Вас, разумеется, не собираюсь...

iconv - Простенькая утилита конвертации текстовых файлов. dvi, действительно, она вряд ли обработает правильно. Только в начале-то был .tex, правда? Потом уже .dvi. Так зачем же конвертировать результат, если проще сконвертировать исходник?

Про XP, MS и тех, извините, не понял. У Вас есть тех-процессор от MS для XP, не поддерживающий уникод?:) Или просто текущий бинарник теха для вин32 не поддерживает уникод? Так на это-то я и ругаюсь. И требую, чтоб поддерживал (в виде багрепортов для прог, которыми пользуюсь, и которые не поддерживают). XML хорош тем, что всегда содержит в явном виде указание кодировки (если это правильный XML:). И большинство тулз для XML спокойно умеют работать с любыми кодировками (в первую очередь UTF-8). Поэтому если Ваша инфосистема будет иметь в качестве внутренних форматов разные языки XML - среди них спокойно сможет оказаться и UTF-8. Просто и естественно.

> до простых пользователей вообще никому нет дела.

Да, конечно. Только в этом случае на компах кроме 7-битного ASCII вообще ничего бы не было. Потому как программер может изучить английский, а до остальных....