# Нужен нормальный текстовый редактор

## Koshh

Скажу сразу - я в линуксе человек новый, однако знаю, какое прерывание использует клава, что делает "xor eax, eax", да и гуглить умею =)

Итак, настроив иксы с прозрачностью, юникодом и прочими "плюшками", которые под вин32 получаешь бесплатно, я конечно же захотел установить прославленный на просторах интернета OpenOffice 2.0. Сказано - сделано, USE="-eds" emerge openoffice

Однако, после 10 минут изучения "лучшей альтернативы..." меня постигло жестокое разочарование - слишком все криво и косо, начиная от убогого интерфейса (панельки в стиле Office 2003 - и рисованные в пейнтрбарше 16-ти цветные иконки без намека на сглаживание), заканчивая мелкими "заусенцами" (типа кривовато проработанных диалоговых окон и неполной перисовки отдельных элементов при закрытии меню) буквально во всем. Не смертельно - но очень неприятно, особенно, когда нормальынй пример перед глазами.

Товарищи! Есть ли под линукс ВМЕНЯЕМЫЕ текстовые редакторы (Koffice еще не пробовал, но везде пишут, что он хуже чем OO) ? С нормально сделанным UI, который не нужно обрабатывать напильником в течении недели, и который не требует постоянного наличия меня рядом с компом, если текст набирает девушка? =)

Требования ведь очень простые - визивиг, минимум работы со шрифтом (+ отступы, межстрочное расстояние), умение вставлять в текст картинки, а также понимать вордовские документы (диаграммы, макросы и прочая хрень не требуется).

ЗЫ MS Office по сравнению с OO - как ACDSee по сравнению с Irfan View. Последний пошустрее кушает 20-ти меговые тифы, и батч-процессинг имеет нормальный, но - ACDsee УДОБНО пользоватсья, чего не скажешь про сделанный на коленке UI ирфана... ИХМО, ессно

PS мда, на этом форуме еще и KOI8-R - как будто так и должно быть. Голубицкий, где же вы? Гоблины ждут! =)

----------

## hermes_jr

 *Koshh wrote:*   

> 
> 
> Слишком все криво и косо, начиная от убогого интерфейса (панельки в стиле Office 2003 - и рисованные в пейнтрбарше 16-ти цветные иконки без намека на сглаживание), заканчивая мелкими "заусенцами"
> 
> 

 

OOO_FORCE_DESKTOP="gnome" или OOO_FORCE_DESKTOP="kde" нагуглить удалось? Всё ещё не нравится UI? Жаль.

Можно попробовать crossover опять же.

 *Koshh wrote:*   

> 
> 
> ЗЫ MS Office по сравнению с OO - как ACDSee по сравнению с Irfan View. Последний пошустрее кушает 20-ти меговые тифы, и батч-процессинг имеет нормальный, но - ACDsee УДОБНО пользоватсья, чего не скажешь про сделанный на коленке UI ирфана... ИХМО, ессно
> 
> 

 

На любителя. Мне ACDsee-like вьюверы всегда были противны, а Irfan как раз очень уважаю.

Пока сам все не перепробуешь, искомого не найдёшь, факт.

Тебе кстати не текстовый редактор нужен, а этот... как их там звать, текст процессинг систем  :Smile:  А редактор лучший - vim. Гы.

----------

## iTux_Tux

А редактор лучший - vim. Гы.

НА ЛЮБИТЕЛЯ, ИМХО ЛУЧШЕ nano ^__^

----------

## viy

Тут надо еще с задачами определиться. Если нужен текстовый редактор, то vim, emacs, nano подойдут.

Если речь идет об WYSIWYG форматировании текста, то это совсем другая песня.

Посмотри тут.

----------

## lefsha

 *Koshh wrote:*   

> 
> 
> Однако, после 10 минут изучения "лучшей альтернативы..." меня постигло жестокое разочарование - слишком все криво и косо, начиная от убогого интерфейса (панельки в стиле Office 2003 - и рисованные в пейнтрбарше 16-ти цветные иконки без намека на сглаживание), заканчивая мелкими "заусенцами" (типа кривовато проработанных диалоговых окон и неполной перисовки отдельных элементов при закрытии меню) буквально во всем. Не смертельно - но очень неприятно, особенно, когда нормальынй пример перед глазами.
> 
> Товарищи! Есть ли под линукс ВМЕНЯЕМЫЕ текстовые редакторы (Koffice еще не пробовал, но везде пишут, что он хуже чем OO) ? С нормально сделанным UI, который не нужно обрабатывать напильником в течении недели, и который не требует постоянного наличия меня рядом с компом, если текст набирает девушка? =)
> ...

 

ОО не идеален. Это факт. Есть много проблем в том числе и то что названо.

НО! Он в состоянии делать все что Вы от него просите. И это тоже факт.

Искать другое не советую. Потеря времени. Опробовано уже все.

Хотя KOffice делает вид, что работает - это только видимость.

Abiword и Gnumeric тоже вроде бы ничего, но уровень не тот.

Даже для данной функциональности их еще полировать и полировать.

Пока другой бесплатной альтернативы нет.

В конечном счете запускайте MS Office под wine.

Хотя должен отметить, что OO Writer имеет много таких функций,

которые не известно других редакторов...

----------

## sa10

 *Koshh wrote:*   

> 
> 
> Итак, настроив иксы с прозрачностью, юникодом и прочими "плюшками", которые под вин32 получаешь бесплатно 

 

Бесплатно?   :Shocked: 

Это юмор такой веселый да?

И наверное я отстал от жизни. 

Например юникод...

Иногда знакомый китаец приносит свой диск, и win32 как-то одновременно и китайские и русские имена файлов не может отобразить, это только в Linux...

Не знаю может ли мсофис языки в текстовом редакторе смешивать, но если ексел сохраняет только в 1251 и кодировку указать нельзя, то откуда там юникоду? Мне как-то приносили текстовый файл с разделителями конвернтуть под OO именно по причине невозможности нормальной работы с юникодом в экселе. С подробностями не разбирался, конвертнул просто и забыл.

 Может у мсофта какие новые версии появились. После офис-2000 ничем ихним не пользовался (только издалека видел), появился OOffice. Я на OO перешел потому как приходится работать с документами страниц по 500-800 с картинками, у мсофиса с этим весьма крупный облом.

И насчет прозрачностей в win32... Это как и спомощью чего? Даже издалека не видел чтобы кто пользовался   :Smile: 

Как я понял настроенная прозрачность, юникод и прочие "плюшки, это ненастроенная прозрачность, юникод и прочие "плюшки. 

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

Для этого знание прерывания клавы, отнюдь, недостаточно.

Меня внешний вид OO-2 меня полностью устраивает, а эти икспишные яркие цветные лепЁхи на экране только раздражают и занимают лишнее место на экране.

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

Есть кудесники, делающие все на TeX. Мечтаю освоить. И наверняка придется.

Там столько наворотов, что подоконникам и не снилось, но для них это хуже киросину.

Из подобных редакторов рекомендуется Kile или ( если надо WYSIWYG) Lyx, TeTeX лучше не надо....

Но это с чужих слов, я пока не имею особого опыта, только несколько попыток....

Смешно, но подоконники думают, что мышь обладает большей функциональностью чем клава  :Smile: 

Это смешно особенно в отношении набора текста. Интересно как они мышью набирают текст?

Наверное посредстом нажатия на иконки с неверояной глубиной цвета   :Wink: 

Ну да ладно, больше не буду издеваться  :Smile: 

Говорят ворд перфект крут, но от добра, добра не ищут. 

Знаю, что он работает под линуксом в вайне, нативной версии не ожидается пока.

Забавно, но я слыхал (сам не проверял), что виндовый опенофис работает под вайном быстрее чем линуксовый, и, что особенно странно, быстрее чем под форточками.  :Smile: 

----------

## lefsha

 *sa10 wrote:*   

> Есть кудесники, делающие все на TeX. Мечтаю освоить. И наверняка придется.
> 
> Там столько наворотов, что подоконникам и не снилось, но для них это хуже киросину.
> 
> Из подобных редакторов рекомендуется Kile или ( если надо WYSIWYG) Lyx, TeTeX лучше не надо....
> ...

 

Во первых TeX не идеал. Во вторых это технология прошлого.

А в третьих - самое главное. Он не имеет никакого отношения к Linux.

Так что приводить его в противовес "подоконникам" не имеет смысла.

Мало того оболочка для него под Windows более удобна чем под Linux.

А уж Lyx совсем не относится к тому, чем можно пользоваться...

 *sa10 wrote:*   

> 
> 
> Смешно, но подоконники думают, что мышь обладает большей функциональностью чем клава 
> 
> Это смешно особенно в отношении набора текста. Интересно как они мышью набирают текст?
> ...

 

Нет, они думают, что мышь более удобна чем клава для своих нужд.

И они правы. Все остальное не имеет к реальности никакого отношения.

 *sa10 wrote:*   

> 
> 
> Ну да ладно, больше не буду издеваться 
> 
> 

 

Издеваться тоже надо уметь...

 *sa10 wrote:*   

> 
> 
> Забавно, но я слыхал (сам не проверял), что виндовый опенофис работает под вайном быстрее чем линуксовый, и, что особенно странно, быстрее чем под форточками. 

 

Это для особых извращенцев?

----------

## sa10

>>Во первых TeX не идеал. Во вторых это технология прошлого.

И какой же железный конь пришел на смену крестьянской лошадке?

Ужели мсофис?

И вообще, это очень спорный вопрос...

Здесь как раз довольно свежий флейм постингов на 200 

"LaTeX VS Word"

http://www.linux.org.ru/view-message.jsp?msgid=1287124

Я еще не начинал читать, но, в принципе, там изредка там из сотни спорщиков может обнаружится человек который  в самом деле пользуется LaTeX.  Можно , в принципе ознакомиться...

Однако там в основно юные студенты. 

Как-то читал форум спецов использующих LaTeX в качестве издательской системы на протяжении доволно большого периода времени. Остался под бАААльшим впечатлением...

А здесь незачем нам животами мериться  :Smile: 

мы же в основном на взаимопомощь ....

Я просто хотел человеку редактор посоветовать из добрых побуждений

Если у меня неуклюже получилось, прошу извинить меня всех кого задело  :Smile: 

----------

## hermes_jr

 *Koshh wrote:*   

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

 

 *sa10 wrote:*   

> 
> 
> ....форум спецов использующих LaTeX в качестве издательской системы....

 

sa10, не пойми неправильно, ссусь кипятком   :Laughing: 

----------

## viy

hermes_jr, а почему? Система как раз для этого...

----------

## Alice in W

 *viy wrote:*   

> hermes_jr, а почему? Система как раз для этого...

 

Koshh просил как раз для девушки, не спеца... :Smile: 

----------

## sa10

 *hermes_jr wrote:*   

>  *Koshh wrote:*   
> 
> ...Есть ли под линукс текстовые редакторы .... который не нужно обрабатывать напильником в течении недели, и который не требует постоянного наличия меня рядом с компом, если текст набирает девушка? 
> 
>  *sa10 wrote:*   
> ...

 

Извини, старик, то я этого просто не могу понять ни правильно ни неправильно  :Smile: 

Это о девушках, в смысле дня солидарности, или о типа спецах?  :Smile: 

И с кипятком тоже непонятно.

Про кипяток принято говорить когда следует указать на крайнюю степень, скажем так, негативного отношения  :Smile: 

А здесь это как-то не подходит по смыслу.

Это значит тебя это злит, или, вероятно, так веселит, что злит?

Короче я запутался... И вообще, нафиг кипяток, пора водку кушать, праздник!

 :Rolling Eyes: 

----------

## lefsha

 *sa10 wrote:*   

> >>Во первых TeX не идеал. Во вторых это технология прошлого.
> 
> И какой же железный конь пришел на смену крестьянской лошадке?
> 
> Ужели мсофис?
> ...

 

Прежде всего следует уяснить одну простую вещь.

TeX это язык программирования. Со всеми вытекающими последствиями.

Кроме того довольно неудачный язык программирования.

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

Таким образом сравнивать его хоть как-то с MS Office или еще каким

либо другим оффисом не имеет смысла, вне зависимости от того

где Вы нашли подборку споров на эту тему.

Даже с приличной издательской системой сравнивать его нельзя.

Из того факта, что TeX это язык программирования вытекает, что

теоретически на нем должно быть можно сделать все, что можно

сделать на компьютере вообще.

Однако практика показывает, что какие-то более сложные вещи

делаются либо с большим трудом либо не делаются вовсе.

Базовые возможности того же LaTeX не хватает для практического

использования. Необходимо использовать packages.

В плане оценки этого языка возьмите разбиритесь как работает

некий package для реализации чего-либо...

Я Вас уверяю крыша поедет на третей строчке.

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

Я теперь представляем нужды обычного пользователя.

Ему надо очевидно написать некий текст. И у него хватает забот,

чтобы думать над самим содержанием этого текста.

Заставлять же его дополнительно думать как запрограммировать

некие вещи при том, что у него стоит последний Пентиум

малоцелесеобразно. Да он и сам не будет.

Вот собственно и весь сказ про TeX.

 *sa10 wrote:*   

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

 

Да. Охотно верю. Точно так же можно остаться под впечатлением романа

или полетов на луну. Но к практической жизни это имеет малое отношение.

 *sa10 wrote:*   

> 
> 
> Я просто хотел человеку редактор посоветовать из добрых побуждений
> 
> 

 

Никто и не говорит, что побуждения были  недобрыми.

Другое дело их практичность.

 *sa10 wrote:*   

> 
> 
> Если у меня неуклюже получилось, прошу извинить меня всех кого задело 
> 
> 

 

 :Smile:  Свою точку зрения надо отстаивать даже если она неправильная.

Это помогает в будущем принимать более правильные точки зрения

а так же развивает мозговой аппарат.

----------

## Koshh

 *lefsha wrote:*   

> 
> 
> Искать другое не советую. Потеря времени. Опробовано уже все.
> 
> 

 

Пока я остановился на ThinkFree Office 3.0 - тормознутый "клон" 2003-го офиса =) Все, что я делаю в ворде, можно делать и в тамошнем write. Ни разу не падал, ни одного глюка замечено не было, интерфейс красивый и достаточно удобный прямо "из коробки". Приятная программка, хотя и не бесплатная.

----------

## Koshh

 *sa10 wrote:*   

> 
> 
> Бесплатно?  
> 
> Это юмор такой веселый да?
> ...

 

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

Теперь по делу. Винда, начиная с версии NT 4.0 (1996 год), все строки хранит исключительно в формате Unicode. Правда, для криворуких программистов (и совместимости) была оставлена лазейка - все функции Win32 API были продублированны. К примеру, CreateFileA (A - от слова ANSI, т.е. однобайтная кодировка), и CreateFileW (Wide, "широкие" символы, юникод). При написании программы программист пишет CreateFile, а нужную буковку в конце добавит макрос во премя компиляции (упрощаю, конечно же). В MS Visual C++, к примеру, достаточно написать "#define UNICODE" =) Ессно, к Вин98 это никакого отношения не имеет, маздай - он и в африке маздай.

Поэтому, все "крякозябры" и несовместимости - на совести криворуких программеров, или же файловых систем, не поддерживающих юникод (это к вопросу о том CD, где китайские буковки).

И именно поэтому кодировку в общем случае указывать _не надо_ - все работает в юникоде.  MS Office, к слову - не часть операционной системы, но и в нем все работает нормально.  Эксель нормально работает с юникодом, VBA работает с юникодом... Не работают только руки у отдельных личностей (надо приводить конкретные примеры).

Прозрачность в вин32 появились начиная с Win2000, достаточно установить расширенный стиль окна WS_EX_LAYERED и вызвать функцию SetLayeredWindowAttributes, установив желаемую прозрачность. А с помощью SetWindowRgn можно задать произвольную форму окна. Например, дрова от nVidia позволяют добавить к каждому окну менюшку для выбора степени прозрачности - это к вопросу о софте. Если есть желание и некоторые навыки программирования - аналогичная тулза будет готова за пару часов.

А вот по поводу _использования_ прозрачности - это совсем отдельная песня =) Может, оно никому нафиг не надо, а?

Вот такая она, "страшная винда"- и юникоду обучена 10 лет назад, и прозрачность 7 лет как поддерживает... Куда там пингвинчикам =)

----------

## lefsha

 *Koshh wrote:*   

>  *lefsha wrote:*   
> 
> Искать другое не советую. Потеря времени. Опробовано уже все.
> 
>  
> ...

 

Никогда не пробовал. Проблема в ней может быть в том,

что она небесплатная. В таком случае вероятность ее распространения

невелика. Слово стандарт игает в этом мире огромную роль.

Как позитивную так и негативную.

Так что как только речь заходит о совместной работе

все отдельно стоящие приложения оказываются в пролете.

Если бы товарищи из Koffice, Gnome Office и ОО

объединились, то могли бы что-то создать вместе.

Но пока каждый будет тянуть одеяло на себя

ничего не изменится.

Этот пример ксати показывает, что людей который могут

проектировать действительно хорошие программы в мире

очень и очень мало.

И обычно они не работают за бесплатно.

----------

## 046

 *Koshh wrote:*   

> 
> 
> Бесплатно - значит, после установки (читай - после покупки, иначе поставить ведь нельзя, так?) все сразу работает, нет нужды править десяток конфигов и читать про баги на форумах.

  Бред. Было бы так никто бы не держал админов, платя им килобаксы ежемесячно.

 *Koshh wrote:*   

> Теперь по делу. Винда, начиная с версии NT 4.0 (1996 год), все строки хранит исключительно в формате Unicode. Правда, для криворуких программистов (и совместимости) была оставлена лазейка - все функции Win32 API были продублированны. К примеру, CreateFileA (A - от слова ANSI, т.е. однобайтная кодировка), и CreateFileW (Wide, "широкие" символы, юникод). При написании программы программист пишет CreateFile, а нужную буковку в конце добавит макрос во премя компиляции (упрощаю, конечно же). В MS Visual C++, к примеру, достаточно написать "#define UNICODE" =) Ессно, к Вин98 это никакого отношения не имеет, маздай - он и в африке маздай.

 

Хранит она не в уникоде, а в UTF16, причём уверена что 1 символ = 16бит. И эта заложеная мина когда-нибудь обязательно бабахнет  :Smile:  Ну да ладно, не будем о грустном... 10 лет назад не было ни шрифтов с более менее полным набором символов, ни файловой системы, хранящей имена в уникоде, ни поддержки писания справа-налево, да и вообще много чего не было.  А в консоли (сейчас, 10 лет спустя), ввод уникода даже не планируется!! И говорить что 10 лет назад была поддержка уникода просто смешно. Возможность выбора кодировки для строк - чушь, она была в unix с самого создания стандарта уникода и его кодировок, просто никому не надо было рисовать пустой и бесполезный макросик в стиле "ёлочка включись".

Плохое у тебя понимание и дела, и ассемблера, судя по твоим выкрутасам  :Smile:  Клавиатура может использовать любое прерывание, а может и вообще не использовать. Только ограниченный и недалёкий может писать про такое "знание".

Окна произвольной формы были в X ещё до того как виндовс появился в проекте. А прозрачность - она не вписывалась в архитектуру Х, где каждая программа отвечает за свою область, и при перекрытие ответственного за перерисовку не найти  :Smile: 

 *Koshh wrote:*   

>  Куда там пингвинчикам =)

  Топай на linux.org.ru, там тебе всё расскажут, покажут и пошлют. Тут тебе ерунду писать не будут.

----------

## lefsha

 *Koshh wrote:*   

> 
> 
> Теперь по делу. Винда, начиная с версии NT 4.0 (1996 год), все строки хранит исключительно в формате Unicode. Правда, для криворуких программистов (и совместимости) была оставлена лазейка - все функции Win32 API были продублированны. К примеру, CreateFileA (A - от слова ANSI, т.е. однобайтная кодировка), и CreateFileW (Wide, "широкие" символы, юникод). При написании программы программист пишет CreateFile, а нужную буковку в конце добавит макрос во премя компиляции (упрощаю, конечно же). В MS Visual C++, к примеру, достаточно написать "#define UNICODE" =) Ессно, к Вин98 это никакого отношения не имеет, маздай - он и в африке маздай.
> 
> Поэтому, все "крякозябры" и несовместимости - на совести криворуких программеров, или же файловых систем, не поддерживающих юникод (это к вопросу о том CD, где китайские буковки).
> ...

 

Все сказано правильно включая последний абзац.

Возникает только немой вопрос как же так вышло, что Мелкософт

включил поддержку уникода в Виндовс, но так и не смог сам его интегрировать.

Ответ Вы собственно привели. Криворукие программисты фирмы Мелкософт

тому виной. Так может в таком случае не стоит считать, что в Виндовс есть

поддержка Уникод если он не работает...?

Функции API меня интересуют меньше всего. Ровно так же как

гениальность TeX, работать на котором неудобно.

В Линух уникод появился недавно. Еще более недавно он заработал.

Но в этом то и огромное отличие Линух от Виндовс.

В первом уникод действительно работает!

----------

## fedukoff

Флеймите господа.   :Exclamation: 

Человек попросил: "дайте мне нормальный текстовый редактор". Ему ответили: "возьми nano, vim, emacs"

Надо типа текстовый процессор - возьми OO. 

Вкуснее нету (зачем?). Не нравиться - не ешь.

Но я таки к флейму присоединюсь. Скажу, что виндозное "собирается из коробки и работает без ползанья по конфигам". Согласен. Но собирать из коробки надо каждый раз при переустановки. А переустанавливать приходится не редко.

Линуксовское надо собрать и поползать по конфигам один раз. И этого достаточно, если тебе нужна просто рабочая станция. 

А если ты эксперементатор, то поползать по конфигам - это очень даже интересно.

По собственному опыту. Собирал последний раз генту с первого стейджа год назад, так как поменял архитектуру с АМД на Интель. До этого два года все работало без каких либо проблемов. После переустановки ползать по конфигам не пришлось на 95% подошли от предыдущего компа. За год поменялись несколько приводов (CD, DVD), пара хардов, пара видях, мамка. 

Замену харда сделал просто загрузился с сидишки и перекопировал все разделы. Винда не выжила.

Заменив мамку (разные чипсеты был 645(вроде) стал 915), в линуксе пришлось поменять драйвер сетевой карточки. Остальное подхватилось без проблем. Винда не выжила. Дабы сохранить все что на винде было (записаные игры Settlers 5) винду поставил поверху. Вроде заработало, но как то через одно место. Все равно пришлось раздел форматнуть. Конечно, не спорю, в винде руки у меня кривоваты.

Да... хоть у меня и ACCEPT_KEYWORDS="~x86", но комп свой использую исключительно как десктоп, без особых экспериментов: немного поиграть, интернет и много программирования на Java. Жена по учебе пользуется OO. Ну и, ессно, музыка, видео и пр. энтертаймент.

----------

## lefsha

 *fedukoff wrote:*   

> Вкуснее нету (зачем?).

 

НЕ ПОРТИТЕ, ПОЖАЛУЙСТА, РУССКИЙ ЯЗЫК.

слово ВКУСНО и его производные употребляются ТОЛЬКО в связи с пищей.

Не учитесь у идиотов, которые плохо учились в школе.

----------

## fedukoff

 *Quote:*   

> НЕ ПОРТИТЕ, ПОЖАЛУЙСТА, РУССКИЙ ЯЗЫК.
> 
> слово ВКУСНО и его производные употребляются ТОЛЬКО в связи с пищей. 

 

В связи с местом проживания, русский язык, к сожалению, "на отлично" знать не могу.

Но, мне кажется, есть такое понятие как аллегорияили метафора (не знаю, какой из терминов лучше подходит)

http://feb-web.ru/feb/litenc/encyclop/le1/le1-0953.htm

К тому же скажу в музыке иногд употребляется словосочетание "вкусный рисунок" и подобные...   :Razz: 

----------

## sa10

 *Koshh wrote:*   

> Вот такая она, "страшная винда"- и юникоду обучена 10 лет назад, и прозрачность 7 лет как поддерживает... Куда там пингвинчикам =)

 

Однако почему я вместо китайских имен файлов вижу кракозябы в винде и сипатичные иероглифы в Linux?

Мегарасширенный стиль окна WS_EX_LAYERED или еще какую хрень надо применить?

Почему мне эта хрень не нужна в Linux?

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

Или юникод в винде, не юникод вовсе?

 Эксель нормально работает с юникодом?

Почему же он не может экспортировать текст с разделителями в кодировке отличной от cp1251?

Он внутри себя работает?

Зачем тогда вообще нужны разговоры о поддержке каких то кодировок? 

Реклама?

--Покупайте наших слонов, они поддерживают все кодировки, но работают только со своей слоновой... 

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

----------

## Koshh

 *046 wrote:*   

> 
> 
> Хранит она не в уникоде, а в UTF16, причём уверена что 1 символ = 16бит. И эта заложеная мина когда-нибудь обязательно бабахнет  Ну да ладно, не будем о грустном... 10 лет назад не было ни шрифтов с более менее полным набором символов, ни файловой системы, хранящей имена в уникоде, ни поддержки писания справа-налево, да и вообще много чего не было.  А в консоли (сейчас, 10 лет спустя), ввод уникода даже не планируется!! И говорить что 10 лет назад была поддержка уникода просто смешно. Возможность выбора кодировки для строк - чушь, она была в unix с самого создания стандарта уникода и его кодировок, просто никому не надо было рисовать пустой и бесполезный макросик в стиле "ёлочка включись".
> 
> Плохое у тебя понимание и дела, и ассемблера, судя по твоим выкрутасам  Клавиатура может использовать любое прерывание, а может и вообще не использовать. Только ограниченный и недалёкий может писать про такое "знание".
> ...

 

Говорим "юникод" - подразумеваем китайские и русские буквы вперемешку. Конкретная реализация - UTF8, UTF16 здесь не важна, а спор "какой UTF лучше в перспективе мирового господства Китая" неуместен, как мне кажется.

Теперь про 10 лет =) Повторяю для тех, кто в танке - NTFS 4-й версии хранит имена файлов в юникоде, поддержка 4-го NTFS'a включена в NT 4.0, которая свободно продавалась в 1996-м году. Сейчас 2006-й год. Какие еще нужны аргументы? Ссылки же на кривые программы не имеют никакого отношения к ОС (операционной системе).

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

----------

## sa10

 *lefsha wrote:*   

> 
> 
> Прежде всего следует уяснить одну простую вещь.
> 
> TeX это язык программирования. Со всеми вытекающими последствиями.
> ...

 

Да уж, мы видим очевидный пример оставивания отстойной точки зрения для развития мозгового аппарата  :Smile: 

А нуждается ли кто либо в Ваших советах типа "как жить, как нам обустроить рабкрин?" и стоит ли Вам искать на них ответ.

Короче, - гоните пургу....  :Smile: 

Я уже намекал, что место для подобных диспутов на linux.org.ru

Предлагаю, еслу Вам так уж скучно, начать там дискусию, что плейн текст устарел и на самом деле это язык программирования  :Smile: 

Но только там.

----------

## sa10

 *Koshh wrote:*   

>  Ссылки же на кривые программы не имеют никакого отношения к ОС (операционной системе).
> 
> 

 

Проводник (explorer) в русской WinXP SP2 не отображает китайских имен файлов.

Или это кривая программа не имеющая никакого отношения к операционной системе?

----------

## Koshh

 *sa10 wrote:*   

> 
> 
> Однако почему я вместо китайских имен файлов вижу кракозябы в винде и сипатичные иероглифы в Linux?
> 
> Мегарасширенный стиль окна WS_EX_LAYERED или еще какую хрень надо применить?
> ...

 

Приведи пожалуйста конкретный пример про иероглифы, хватит уже пустой болтовни "в линуксе все супер, в винде плохо". Конкретный пример, с конкретной версией винды и дистрибутива (хотя здесь уже сложнее) линуха.

Стиль WS_EX_LAYERED отвечает за прозрачность окон, как и написано в моем сообщении (а также в MSDN).

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

Твои "подозрения" по поводу китайской винды беспочвенны, в локализованных версиях виндовс ядро неизменно, меняется только UI.

MS Excel не является частью ОС - если тебе нужно сохранение с разделителями в юникоде, используй платные или бесплатные альтернативы. Все честно, по-моему. И как там работает отдельное приложение под названием Excel - не нашего ума дело. Не работает - не купим =)

----------

## sa10

>> хватит уже пустой болтовни

Абсолютно согласен!

>>  "в линуксе все супер, в винде плохо"

В линуксе не все супер, увы... Этого не говорил и не скажу. Абсолютных лекарств нет, бывают только абсолютные идиоты в это верящие  :Smile: 

И навалом их оппонентов воспринимающих рекламу как "Коран" и готовых записаться в шахиды  :Smile: 

>>  Конкретный пример, с конкретной версией винды и дистрибутива (хотя здесь уже сложнее) линуха.

Конкретный пример на два постинга выше.

Дистрибутив Linux? В форуме gentoo это лишний вопрос  :Smile: 

----------

## Koshh

 *sa10 wrote:*   

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

 

Ну тогда цитатку оттуда - в студию =) С описанием _бага_ или недоработки ОС NT 5.0+, относящегося к поддержке оной ОС юникода. Если не читается диск - ISO на рапидшару (достаточно ведь всего пары файликов китайских). Ждем-с.

----------

## sa10

 *Koshh wrote:*   

>  *sa10 wrote:*   
> 
> >>  Конкретный пример, с конкретной версией винды и дистрибутива (хотя здесь уже сложнее) линуха.
> 
> Конкретный пример на два постинга выше. 
> ...

 

Тебе мелкософт платит, сам и напрягайся. Только не забудь скриншот показать, в эксплорере одновременно китайское имя файла и кирилическое. Фотошопом, конечно, придется поработать  :Smile: 

Удачи!

----------

## Koshh

Это ты мне доказываешь что-то - погляди выше. Не можешь доказать - смирись, или проведи внеочередной ритуал сожжения чучела Билла и тантрического секса с Королевскими Пингвинами - одним словом, делай, что хочешь =) Пользы все равно никому не будет.

----------

## hermes_jr

Так блин! Koshh в угол, остальные на lor!  :Laughing: 

----------

## Koshh

 *hermes_jr wrote:*   

> Так блин! Koshh в угол, остальные на lor! 

 

Гоблины и ефрейторы проснулись =) Есть что-нить по теме сказать, или это просто желание сделать "+1 пост"?

ЗЫ +1...

----------

## hermes_jr

 *Koshh wrote:*   

> Есть что-нить по теме сказать

 

Это Вы мне? Это вот после обсуждения MSDN, WS_EX_LAYERED, MS Visual C++, CreateFileA,  "вкусностей" виндовз и иже с ними в теме о текстовом редакторе на forums.gentoo.org? Шедеврально!

[edit]: И не надо превращать f.g.o. в такой сральник (извините, кого обидел), как lor. До сих пор тут было чистенько и в основном всё по теме. Призываю всех сохранить эту добрую традицию, спасибо за внимание.

----------

## Alice in W

 *Koshh wrote:*   

>  *hermes_jr wrote:*   Так блин! Koshh в угол, остальные на lor!  
> 
> Гоблины и ефрейторы проснулись =) Есть что-нить по теме сказать, или это просто желание сделать "+1 пост"?
> 
> ЗЫ +1...

 

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

Ещё раз - пожалуйста, просто замолчите.

----------

## Koshh

 *hermes_jr wrote:*   

>  *Koshh wrote:*   Есть что-нить по теме сказать 
> 
> Это Вы мне? Это вот после обсуждения MSDN, WS_EX_LAYERED, MS Visual C++, CreateFileA,  "вкусностей" виндовз и иже с ними в теме о текстовом редакторе на forums.gentoo.org? Шедеврально!
> 
> [edit]: И не надо превращать f.g.o. в такой сральник (извините, кого обидел), как lor. До сих пор тут было чистенько и в основном всё по теме. Призываю всех сохранить эту добрую традицию, спасибо за внимание.

 

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

----------

## Koshh

 *Alice in W wrote:*   

> я, в общем, поскольку не в нынешнем году зарегистрировалась на этом форуме, имею Вам сказать - пожалуйста, очень Вас прошу, не надо больше никаких Ваших ответов. И таких откровенно провокативных вопросов больше не надо здесь задавать - как правильно сказал ув. hermes_jr - пусть и дальше чистенько здесь будет.
> 
> Ещё раз - пожалуйста, просто замолчите.

 

Собвственно, я не к Вам домой зашел, и не с Вами беседую. Как бы это помягче сказать, содержание моих вопросов, равно как и ответов - совершенно не Ваше дело. Можете топнуть ножкой (или обоими сразу) - но выполнять Ваши указания здесь, по понятным причинам, никто не будет. Если Вы, конечно, не являетесь представителем администрации данного ресурса =)

----------

## lefsha

 *fedukoff wrote:*   

>  *Quote:*   НЕ ПОРТИТЕ, ПОЖАЛУЙСТА, РУССКИЙ ЯЗЫК.
> 
> слово ВКУСНО и его производные употребляются ТОЛЬКО в связи с пищей.  
> 
> В связи с местом проживания, русский язык, к сожалению, "на отлично" знать не могу.
> ...

 

С местом проживания это не связано никак.

Этого добра полно в сети.

Испокон веков ни в музыке ни где-то еще не употреблялось

выражение вкусный рисунок. Без рассуждения о том какое отношение

к музыке имеет рисунок.

Это очень плохой способ выражать свои мысли.

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

----------

## lefsha

 *Koshh wrote:*   

> 
> 
> Теперь про 10 лет =) Повторяю для тех, кто в танке - NTFS 4-й версии хранит имена файлов в юникоде, поддержка 4-го NTFS'a включена в NT 4.0, которая свободно продавалась в 1996-м году. Сейчас 2006-й год. Какие еще нужны аргументы? Ссылки же на кривые программы не имеют никакого отношения к ОС (операционной системе).
> 
> 

 

Сэр! Вам уже ни один человек объяснил, что уникод в Windows НЕ РАБОТАЕТ!!!

Если Вам ссылки на кривые программы под названием Windows не нужны, тогда

нечего утверждать того чего нет.

Хранить можно что угодно и как угодно. Но если эти функции не предоставлены

пользователю, значит абсолютно все равно есть они или нет.

Как говорят - на заборе тоже много чего пишут, но как правило этого за

ним не оказывается.

----------

## lefsha

 *sa10 wrote:*   

> 
> 
> Предлагаю, еслу Вам так уж скучно, начать там дискусию, что плейн текст устарел и на самом деле это язык программирования 
> 
> 

 

Прошу прощения, но дискуссии на эту тему невозможны.

TeX это язык программирования.

Про plain текст это Ваша отсебятина. Так что спорить будете сами с собой.

----------

## 046

Опять весна 

Опять грачи

Опять не даст

Опять строчи

(сообщение в форум)

----------

## fedukoff

 *lefsha wrote:*   

> Испокон веков ни в музыке ни где-то еще не употреблялось
> 
> выражение вкусный рисунок. Без рассуждения о том какое отношение
> 
> к музыке имеет рисунок.
> ...

 

Как на счет аллегории?

К тому же заниались ли Вы, когданибудь музыкой? Общались ли с музыкантами? Среди них частенько проскальзывают выражения, вроде "вкусно сыграл". 

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

Речи не идет о искажении языка, как происходит, например, у "падонкаф". Такие вот обороты, наоборот, украшают язык, делают его более универсальным.

И, кстати, долго думал отвечать или нет. Но на такую несправедливость решил, все таки, ответить. Так что теперь, как сказал бы "падонак": "Фтопку!"

----------

## Koshh

 *lefsha wrote:*   

> 
> 
> Сэр! Вам уже ни один человек объяснил, что уникод в Windows НЕ РАБОТАЕТ!!!
> 
> Если Вам ссылки на кривые программы под названием Windows не нужны, тогда
> ...

 

Собвственно, при чем здесь собвственно ОС в таком случае? Несколько постов назад мне самозабвенно доказывали, что в винде юникода то ли вообще нет, то ли он есть где-то очень глубоко (что не помешало мне 10 минут назад назвать папку по китайски в проводнике, рядом с русскими) - для чего?

Кривые программы были, есть и будут. Я могу написать нечто кривое под Linux, работающее исключительно с CP866, а потом долго и "аргументированно" обсасывать якобы недостатки ОС =)

Если тут зашла речь о поддержке Юникода ядром и набором _базовых_ программ - то юникод поддерживают _обе_ ОС. Вот с прозрачностью в иксах некторые проблемы - но, это опять таки Unix-way. Важно лишь, что в винде никода не было бардака с 10-ком русских кодировок (а была либо CP1251, она же рус. ANSI, или UNICODE), вследствии чего нет огромного количества нужного, но морально устаревшего ПО. Да и полноценная (т.е. достаточная, и больше практически не меняющиеся) поддержка пресловутого юникода появилась в винде ровно 10 лет назад (про NT 3.51 говорить и в самом деле не стоит) - и проблемы "переползания" на юникод не стояли так остро, как в линуксе (где обработки юзерским напильником требует почти все: Xorg, GTK1, MC, помощь для кучи программ, и т.д.)

----------

## sa10

Смотрим скриншоты

Один и тот же каталог

свежеустановленная русская win2000 sp4 + RUS_Update Rollup 1 for Windows 2000 SP4

http://194.158.195.181/win.png

Видите там один из каталогов квадратиками?

А вот...

Gentoo Linux,  локаль ru_RU.UTF-8

http://194.158.195.181/lin.png

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

Возможно еще пару пачек баксов потребуется заплатить за прибамбасы

Но зачем говорить, что  там юникод 10 лет и прямо из коробки?

И добавлю по теме текстовых редакторов , собственно... 

http://ru.wikipedia.org/wiki/TEX

TeX — система компьютерной вёрстки документов, разработанная американским почётным профессором информатики Дональдом Кнутом. В неё входят средства для секционирования документов, для работы с перекрёстными ссылками, а также для набора сложных математических формул.

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

Если TeX в два-три раза старше Вас, это не значит, что он устарел  :Smile: 

Утверждать, что TeX это язык программирования можно, но тогда языками программирования становятся HTML и SGML, а assembler вполне сойдет за формат для текстовых документов, с помощью  assembler тоже можно документы рендерить  :Smile: 

Что касается удобства виндовых редакторов для LaTeX типа WinEdt или MikTeX, то эти удобства, вероятно, Вы видите в том, что там, по умолчанию, пиктограммы не в один ряд а в 4-5 радов  :Smile: 

Сомнительное удобство для набора текста слепым десятипальцевым методом  :Smile: 

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

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

Тренировать свой мозгопарат можете на лоре  :Smile: 

----------

## Koshh

 *sa10 wrote:*   

> Смотрим скриншоты
> 
> Один и тот же каталог
> 
> свежеустановленная русская win2000 sp4 + RUS_Update Rollup 1 for Windows 2000 SP4
> ...

 

А может мы возьмем свежеустановленную gentoo 2000.6, без ручной настройки ядра? И монтировать раздел будем тоже по-умолчанию (iocharset какой там будет? ты даже флешку с ФАТ16 и русскими именами не увидешь) ?

Теперь серьезно. Единственное телодвижение (связанное именно с локализацией), которое необходимо произвести для корректного отображения китайских символов - выбрать (в данном случае для проводника) шрифт, содержащий символы китайского алфавита - такой, например, как Arial Unicode. Делается посредством 10 кликов (из которых добрая половина - подтверждения) - если нет желания установить китайские региональные настройки.

Количество же телодвижений в линуксе, требуемое для корректного отображения как русских, так и китайских буковок - на порядок больше. И "из коробки" конечно заработает - но, на дистрибутиве, который _специально_ и долго настраивали девелоперы. Ручками же, из stage1 - китайский ты не увидешь довольно долго.

--

TeX и все, что с ним связано - это специализированные продукты, никоим образом не претендующие на замену печатной машинки для домашних пользователей. Сложность продукта, как и его возраст критериями оценки качества служить не могут - просто потому, что не относятся к делу. А по делу - визивиг TeX не поддерживает, и требует _специального_ обучения. Для химика поддержка формул - плюс, для меня - пустой звук. Что же касается 10-ти пальцевого набора - то именно _набор_, а никак не форматирование. И форматировать ли клавиатурными последовательностями, или мышиными кликами - вопрос отдельный, но опять таки не относящийся к делу =)

ЗЫ Призывы "прекратить обсуждение", "закрыть тему", "убить себя", "пойти подальше" и тому подобные всегда вызывают у меня стойкое недоумение - ну какое дело человеку, советующему подобное, до того, открыта темА, или нет, продолжается дискуссия, или нет? Ваша религия требует от вас, что бы все вокруг жили в соотвествии с Вашими же моральными нормами? Если - нет, то прекращение дискуссии в одностороннем порядке - единственный выход для Вас =)

----------

## Azik

Эх, разбудили лешего, окаянные...

 *Koshh wrote:*   

> 
> 
> А может мы возьмем свежеустановленную gentoo 2000.6, без ручной настройки ядра? И монтировать раздел будем тоже по-умолчанию (iocharset какой там будет? ты даже флешку с ФАТ16 и русскими именами не увидешь) ?
> 
> ...
> ...

 

Хм... китайский (при целенаправленных действиях) можно увидеть уже на этапе установки с LiveCD, равно как в любом уважающем себя дистрибутиве Linux. Это так, в целях повышения знаний.

А никто не утверждал что Gentoo - "out-of-box"-продукт. Кто сказал? На этом сайте сплошь альтруисты, и никто им за разработку коробочных версий не платит. Да, была куча проблем с UTF в Linux и в особенности Gentoo, но сколько продолжается внедрение уникода в Linux? От силы лет пять. В 2 раза меньше срока MS.

Много можно сказать по предыдущему посту - и про cp1251, опции iocharset (имхо, винить Linux в том, что он начинает понимать виндовую кодировку виндового раздела, некорректно. Встречный иск - а какую кодировку использует windows при монтировании ext3? Не подскажете?)

И вообще. По существу. Самый вменияемый из текстовых процессоров - OO. Точка. На этот вопрос ответили еще на первой странице обсуждения. Еще вопросы какие?

----------

## Balancer

 *sa10 wrote:*   

> Проводник (explorer) в русской WinXP SP2 не отображает китайских имен файлов.
> 
> Или это кривая программа не имеющая никакого отношения к операционной системе?

 

Про китайский не скажу, а арабский + русский или болгарский + русский - работать доводилось. Немецкий + русский - вообще очень часто.

Или в 1251 появились хотя бы умляуты?  :Very Happy: 

----------

## Balancer

> Важно лишь, что в винде никода не было бардака с 10-ком русских кодировок (а была либо CP1251, она же рус. ANSI, или UNICODE)

И давно консоль в Windows начала в 1251 работать?  :Smile: 

```

dir > dirlist.txt

```

В какой кодировке будет?

А то, что банальный ноутпад уже сегодня предлагает сохранять документы в UTF-8 (не говоря уже про Office) говорит о том, что _сегодня_ для успешного функционирования Windows требуются, как минимум, три кодировки: 1251, 866 и utf-8.

В то время, как мой Gentoo работает исключительно с UTF-8  :Very Happy:  И даже в худшие времена под Linux редко вставал вопрос выбора из более, чем двух кодировок: koi8-r против 1251 или koi8-r против utf-8  :Smile: 

----------

## lefsha

 *fedukoff wrote:*   

> 
> 
> Как на счет аллегории?
> 
> К тому же заниались ли Вы, когданибудь музыкой? Общались ли с музыкантами? Среди них частенько проскальзывают выражения, вроде "вкусно сыграл".

 

Это не музыканты, а люди не знающие русского языка.

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

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

Их нет! 

P.S. Следующий раз будете с музыкантами общаться сообщите

им, что они неправы...

P.P.S. Аллегории надо тоже уметь говорить...

----------

## lefsha

 *Koshh wrote:*   

>  *lefsha wrote:*   
> 
> Сэр! Вам уже ни один человек объяснил, что уникод в Windows НЕ РАБОТАЕТ!!!
> 
> Если Вам ссылки на кривые программы под названием Windows не нужны, тогда
> ...

 

Специально для Вас! Открываем консоль виндовс и пишем слово "Привет"

на трех языках, русском, немецком и китайском  и далее поражаемся своей крутизне

если видим все три слова. В противном случае успокаиваемся и перестаем

нести ерунду.

Я имел достаточно проблем с умлаутами. И не только я один.

В связи с чем очень часто их не используют, чтобы не страдать от проблем, которые они

вызывают.

----------

## Balancer

>Открываем консоль виндовс и пишем слово "Привет" на трех языках

Нормальные люди, мне казалось, должны знать, что консольный command.com - неюникодный. В частности, у подавляющего большинства тут присутствующих, он должен быть с cp866. И он не может иметь иную кодировку из соображений совместимости. DOS-программы никто не отменял.

А вот том же банальном ноутпаде можно хоть на десяти языках написать.

----------

## Koshh

 *lefsha wrote:*   

> 
> 
> Специально для Вас! Открываем консоль виндовс и пишем слово "Привет"
> 
> на трех языках, русском, немецком и китайском  и далее поражаемся своей крутизне
> ...

 

В виндовс нет понятия консолив принципе =) Есть понятие command shell - штука, оставленная для совместимости с DOS, и для более удобного выполняния некоторых административных задач (GUI - не панацея, как и ООП, к примеру). И по понятным причинам этот самый шелл знать не знает про юникод - иделогия у него такая, _legacy_.

----------

## Koshh

 *Balancer wrote:*   

> > Важно лишь, что в винде никода не было бардака с 10-ком русских кодировок (а была либо CP1251, она же рус. ANSI, или UNICODE)
> 
> И давно консоль в Windows начала в 1251 работать? 
> 
> ```
> ...

 

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

 *Balancer wrote:*   

> >Открываем консоль виндовс и пишем слово "Привет" на трех языках
> 
> Нормальные люди, мне казалось, должны знать, что консольный command.com - неюникодный. В частности, у подавляющего большинства тут присутствующих, он должен быть с cp866. И он не может иметь иную кодировку из соображений совместимости. DOS-программы никто не отменял.
> 
> А вот том же банальном ноутпаде можно хоть на десяти языках написать.

 

Вот вы сами себе и ответили - почему в виндах живет до 3-х кодировок:

 - CP866 и иже с ней в cmd.exe - для совместимости с досом и командными сценариями

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

 - Юникод (UTF-16) - как основная кодировка системы, в ней работает ядро, прикладные программы, файловая система.

----------

## lefsha

 *Balancer wrote:*   

> >Открываем консоль виндовс и пишем слово "Привет" на трех языках
> 
> Нормальные люди, мне казалось, должны знать, что консольный command.com - неюникодный. В частности, у подавляющего большинства тут присутствующих, он должен быть с cp866. И он не может иметь иную кодировку из соображений совместимости. DOS-программы никто не отменял.
> 
> А вот том же банальном ноутпаде можно хоть на десяти языках написать.

 

Нормальные люди должны знать, что если система не поддерживает

Уникод частично, значит она его не поддерживает.

Кроме того никто никому не запрещал сделать нормальную консоль.

Кроме того было достаточно проблем с файлами, которые по причине

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

Я к счастью уже давно не имею возможности это продемонстрировать.

----------

## Balancer

>Кроме того было достаточно проблем с файлами, которые по причине

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

Остаётся только удивится, почему я в бытность работы с виндой, имея файлы и тексты на арабском, русском, немецком языках таких проблем не имел  :Very Happy:  Наверное, это не имена кривые были, а что-то другое у кого-то другого...  :Smile: 

...

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

----------

## lefsha

 *Balancer wrote:*   

> >Кроме того было достаточно проблем с файлами, которые по причине
> 
> кривости имени нельзя было удалить никак...
> 
> Остаётся только удивится, почему я в бытность работы с виндой, имея файлы и тексты на арабском, русском, немецком языках таких проблем не имел  Наверное, это не имена кривые были, а что-то другое у кого-то другого... 
> ...

 

Возможно Вы работали на одной машине.

Я же имел проблемы с файлами на разных машинах - разной локализацией,

соединенных в сеть. Если на вашей машине нет данного языка У Вас

получаются проблемы с файлом на другой машине.

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

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

или соотвествующего уровня собеседника.

 *Balancer wrote:*   

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

 

Пока мне сложно привести примеры проблем с уникодом в Linux.

Если Вы знаете хоть один - приведите его.

----------

## lefsha

Ладно. Надо завязывать.

Нормального редактора еще не придумали и приходится пользоваться тем что есть.

----------

## Koshh

 *lefsha wrote:*   

>  *Balancer wrote:*   >Кроме того было достаточно проблем с файлами, которые по причине
> 
> кривости имени нельзя было удалить никак...
> 
> Остаётся только удивится, почему я в бытность работы с виндой, имея файлы и тексты на арабском, русском, немецком языках таких проблем не имел  Наверное, это не имена кривые были, а что-то другое у кого-то другого... 
> ...

 

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

Теперь про проблемы с юникодом в линухе. Да вот они: хелп в MC, крякозябры в GTK-приложениях вроде XMMS (да, виноват xorg - но он де-факто часть ос), сообщения в mplayer - достаточно? Я не говорю про мелкие "затыки" вроде невозможности сделать себе логин "Вася Пупкин" (да, может правкой неких конфигов это и фиксится - но по-умолчанию не работает) =) Также стоит сделать поиск в гугле "utf8 lunux not work" - там очень много интересного. Что самое забавное, аналогичный поиск для винды практически ничего не даст - это или узкоспециальные проблемы, или грабли в старых версиях ПО.

ЗЫ А текстовый редактор я давно нашел, если еще wine оказжется более-менее работоспособным, то жить в линуксе станет возможно.

----------

## 046

 *Koshh wrote:*   

> Но любые операции со строками в UTF-8 - это мучительно и долго. Про отладку я вообще молчу.

 

Поясни почему это операции со строками в UTF-8 долгие? Это же обычный ascii, и все операции (удаление/вставка/замена) выполняются аналогично!! Опять ерунду пишете!

Какая такая отладка? И почему вообще молчишь? Такой бред что самому смешно?

----------

## 046

 *Koshh wrote:*   

> Теперь про проблемы с юникодом в линухе...

  Мухаха. Експлорер файлов это значит левая старая  глючная программа, а mc является неотъемлимой частью linux.

Валяюсь под стулом  :Smile: 

----------

## Balancer

 *046 wrote:*   

>  *Koshh wrote:*   Теперь про проблемы с юникодом в линухе...  Мухаха. Експлорер файлов это значит левая старая  глючная программа, а mc является неотъемлимой частью linux.
> 
> Валяюсь под стулом 

 

Как обычно, комментируем только то, что выгодно?  :Smile: 

----------

## Koshh

 *046 wrote:*   

>  *Koshh wrote:*   Но любые операции со строками в UTF-8 - это мучительно и долго. Про отладку я вообще молчу. 
> 
> Поясни почему это операции со строками в UTF-8 долгие? Это же обычный ascii, и все операции (удаление/вставка/замена) выполняются аналогично!! Опять ерунду пишете!
> 
> Какая такая отладка? И почему вообще молчишь? Такой бред что самому смешно?

 

Это не обычный ascii, посколку 1 символ может занимать как 8 бит, так и 16. Первые 127 символов таблицы ascii оставлены "как есть" - англ. буквы, цифры, скобки и т.д. Все остальные символы Unicode - кодируются 16-ю битами (к примеру, последовательность байтов D1 84 кодирует русскую букву 'ф', а 3E - символ '>'). И кодировка эта разрабатывалась скорее как транспортная - налицо уменьшение трафика при передаче HTTP запросов и XML документов (служебные сисволы там как раз из первой половины таблицы ascii). Но любые операции с такими строками требуют сложных алгоритмов - поскольку строку нельзя представить как массив байт или машинных слов (в случае UTF-16). Отсюда - дополнительные накладные расходы при обработке строк. Проблемы с отладкой проистекают хотя бы из того, что длина строки (в байтах) неизвестна до момента прогона программы - переменная длина символа, как-никак =)

Так что ерунду пишешь именно ты, не понимая сути предмета.

----------

## Koshh

 *046 wrote:*   

>  *Koshh wrote:*   Теперь про проблемы с юникодом в линухе...  Мухаха. Експлорер файлов это значит левая старая  глючная программа, а mc является неотъемлимой частью linux.
> 
> Валяюсь под стулом 

 

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

Что жекасается MC, то проблема заключается не возрасте или глючности программы, а в том, что программа, замечательно работающая с одними настройками ОС, при переходе на более новые (и прогрессивные) работать отказывается. То есть KOI8 и UTF-8 вещи взаимосключаемые в линухе (пляски с конвертацией справки из одного формата в другой - это не решение, фактически это перекомпиляция программы). А винда 3 кодироваки одновременно есть (см. предидущие посты).

----------

## 046

 *Koshh wrote:*   

> Это не обычный ascii, посколку 1 символ может занимать как 8 бит, так и 16. Первые 127 символов таблицы ascii оставлены "как есть" - англ. буквы, цифры, скобки и т.д. Все остальные символы Unicode - кодируются 16-ю битами (к примеру, последовательность байтов D1 84 кодирует русскую букву 'ф', а 3E - символ '>'). И кодировка эта разрабатывалась скорее как транспортная - налицо уменьшение трафика при передаче HTTP запросов и XML документов (служебные сисволы там как раз из первой половины таблицы ascii).
> 
> Но любые операции с такими строками требуют сложных алгоритмов - поскольку строку нельзя представить как массив байт или машинных слов (в случае UTF-16). Отсюда - дополнительные накладные расходы при обработке строк.
> 
> Проблемы с отладкой проистекают хотя бы из того, что длина строки (в байтах) неизвестна до момента прогона программы - переменная длина символа, как-никак =)

 

Поскольку Вы считаете что я не понимаю, то начну учить  :Smile: 

1.

В utf-8 символ может кодироваться последовательностью от одного до 6!! октета. (1 октет = 8 бит, практически тоже самое что и байт)

Все символы unicode НЕ ВЛЕЗАЮТ в 16 бит. И utf-8 была создана не для экономии (экономная она только на ASCII тексте), а для совместимости. Куча библиотек (в том числе и ядро linux) работает со строками как с последовательностями, заканчивающимися нулевым байтом. Для этого кодировка utf-8 подходит.

2. Любые данные можно представить как массив байт или машинных слов в памяти. Кстати машины с размером слова в 16 бит уже жуткая редкость  :Smile:  Переход с 32 на 64 идёт. Да, в utf-8 нельзя в произвольном месте, заменить/вставить/удалить  произвольный байт / слово / ещё какою нибудь фигню, не опасаясь, что изменения затронут весь последующий текст. Ознако заменять utf подстроку на utf, а также удалять и добавлять utf подстроки в любом месте можно совершенно свободно.

И это касается всех кодировок с переменным числом байт  включая utf-16!

Unicode кодировки с постоянным числом бит (лишённые подобных недостатков) называются ucs (в противовес utf). Например ucs-4, в которой каждый символ кодируется 32 битами.

3. Вот именно, что длинна входящей строки часто не известна до момента выполнения программы (а ещё лучше и безопасней это предполагать всегда), а в этом случае, то что символы кодируются переменным числом байт, не имеет никакого значения.   И при чём тут отладка не понятно.

В кодировках с переменным числом байт на символ (включая utf-16), есть недостаток две медленно работающие операции.

1. Количество символов в строке. (в отличии от получения занимаемой строкой памяти, это крайне редкая операция)

2. Получения символа по его позиции. (также редкая операция в отличии от последовательного чтения символов)

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

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

PS: Предлагаю зайти на unicode.org и почитать много интересного  :Smile: Last edited by 046 on Thu Mar 16, 2006 9:02 am; edited 1 time in total

----------

## 046

 *Koshh wrote:*   

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

  Ах Вы про интернет эксплорер? У него с отображением может и нет, а вот с передачей точно есть, как он корёжит данные форм, и как их восстанавливать, об этом целые поэмы написаны на сайтах www программистов.

Я-то имел ввиду китайский компактик (см выше).

 *Koshh wrote:*   

> То есть KOI8 и UTF-8 вещи взаимосключаемые в линухе (пляски с конвертацией справки из одного формата в другой - это не решение, фактически это перекомпиляция программы). А винда 3 кодироваки одновременно есть (см. предидущие посты).

 

1. Лучше бы в виндовс не было 3 кодировок. Это косяк и костыль, правда обклееный войлоком, и описаный во всех путеводителях  :Smile:  Но на него всё равно напарываются, правда проблем сильных обычно не возникает, результат обычно потеря 2-120 секунд и лёгкое раздражение  :Smile: 

2. Автор mc выпендрился объеденив man страницу и встроенную помощь, в результате, помощь не была обработана стандартным инструментом для локализации программ. Все строки, обработанные нормальной локализацией, работают в разных локалях без пересборки и т.п.

----------

## Koshh

 *046 wrote:*   

> 
> 
> Я-то имел ввиду китайский компактик (см выше).
> 
> 1. Лучше бы в виндовс не было 3 кодировок. Это косяк и костыль, правда обклееный войлоком, и описаный во всех путеводителях  Но на него всё равно напарываются, правда проблем сильных обычно не возникает, результат обычно потеря 2-120 секунд и лёгкое раздражение 
> ...

 

Про китайский компактик вроде как уже разобрались - винда китайский показывает, максимум что нужно сделать в не-китайской версии винды - сменить 1 шрифт, заданный по-дефолту. Хватит уже про него.

1. Кодировки в винде нужны для совместимости со старым софтом - который не слышал про юникод, и новых версий которого просто не предвидится. Решения для линуха - "ну... вот сырцы, переделайте сами" или же "ждите, пока кто-нить не портирует". Решение винды - оставить ненавистные тебе две кодировки (вернее, поддержку определенных кодовых страниц, но это не принципиально), дабы у юзеров было меньше проблем. И 120 секунд и раздражение - цветочки по сравнению с пересборкой системы, играми с конфигами и прочим - в случае обнаружения пингвиньих граблей.

2. Авторы xmms, mplayer - тоже "выпендрелись"? - иначе отчего при русской локали ничерта не видно (без неслабой обработки набором напильников)? Кстати, Xorg - часть ос, нравится это тебе, или нет. Алтернатив столько же, сколько и у эксплорера в винде.

ЗЫ Я говорю про оболочку (shell) виндовса. Файлик explorer.exe (как и в случае с ie) - всего лишь фронт-энд, не более.

----------

## Koshh

 *046 wrote:*   

> 
> 
> Поскольку Вы считаете что я не понимаю, то начну учить 
> 
> 1.
> ...

 

Хорошо, что ты решил подучить матчасть =) Однако, мы тут вроде как не меремся объемами copy-paste с unicode.org и иже с ним. Теперь по пунктам:

1. Поскольку HTML и XML (сюда же SOAP) в качестве служебных символов используют исключительно символы ascii, то экономия получается нешуточная - именно при передаче запросов и документов. Узкое место - канал связи, а не объем жесткого диска. Про библиотеки еще смешнее "с последовательностью, оканчивающуюся нулевым байтом". Никто с этим и не спорит. Просто обработка единиц последовательности переменной длины требует дополнительных накладных расходов - в _любом_ случае. И попробуй доказать обратное.

2. Батенька, мы с вами про x86 говорим, где слово (word) имеет размерность 16 бит. И как ни странно, в AMD64 word тоже 16-ти битный. Точно так же как и байты - восьмибитные. Теперь про подстроки - повторяю для самых недогадливых - для получения длины подстроки недостаточно умножения количества символов на их размер (одна операция), а требуется циклических проход по всем символам, и суммирование размера каждого из них. Теперь начинаешь понимать? Однократное умножение ВСЕГДА быстрее цикла с аккамулятором - причем ГОРАЗДО. Что же касается точного и начного названия типов кодировок (а еще можно про порядок байт вспоминить) - это дело десятое. В винде вимвол == 2 байтам. 

3. Ну ты еще про переполнение буфера вспомни, ей богу. Выше я показал, в чем проблема с определением длины строки - в скорости. Про отладку я говорю потому, что "на глазок" определить проблемы при обработке UTF8 строк крайне проблематично, и некорректно выдернутая подстрока может "мутировать" (в случае разрыва последовательности байт, кодирующих символ) во что угодно. В сложных алгоритмах (особенно при активном выделении/особождении памяти) отладка превращается в пытку - особенно, для начинающих программеров.

И два "маленьких пункта":

1. Каким образом ты определишь объем памяти, занимаемый стркутрой с членами переменной длины? Правильно, просуммируешь их размер (см выше). Как определить количество символов в UTF8 - строке? Правильно, оргпнизовать цикл. Итак, у тебя есть два варианта - или каждый раз использовать одну из этих двух _медленных- операций, или сопровождать строку дополнительным параметром, содержащим информацию о ее длине/размере. Первое грозит откровенными тормозами, второе - усложенением кода, и как вариант - потерей одного регистра общего назначения под параметер.

2. Получения символа по позиции - и впрямь редкая операция. Гораздо более частая операция - это получение подстроки. Но... Нам снова требуется ее (подстроки) размер в _байтах_ (нам ведь надо выделить под нее память). Способ получение - медленный цикл (по сравнению с одним умножением).

Сделаю небольшую ремарку - процессоры x86 имееют встроенные средства для облечения работы со строками - это инструкции LODS/SCAS/STOS (для 8, 16 и 32 битных символов). Также попогает режим адресации по базе с индексацией. Естественно, все это непременимо к UTF8.

Теперь займемся "популярными" алгоритмами. Один из самых "популярных" алгоритмов - это выделение подстроки (для UTF8 - медленный). Также довольно популярна операция соеденения строк - "аsвgвавd" + "XыXыX". Вопрос - сколько памяти надо выделить под результат? Ответ - хрен его знает, цикл покажет.

----------

## 046

 *Koshh wrote:*   

> Просто обработка единиц последовательности переменной длины требует дополнительных накладных расходов - в _любом_ случае. И попробуй доказать обратное.

  Так я это успешно делаю. В большинстве случаев работа с UTF имеет аналогичную трудоёмкость.

А для всяких извратов - кодировки  с постоянным числом байт на символ.

 *Koshh wrote:*   

> Батенька, мы с вами про x86 говорим, где слово (word) имеет размерность 16 бит.

  word имеет размер регистра общего назначения. И так везде, а не только в x86. Сексуальные проблемы синтаксиcа ассемблера intel тут не решают.  :Razz: 

 *Koshh wrote:*   

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

  Подстрока у тебя как задаётся? А то я не понимаю в чём проблема? Мне вот (как я писал выше) абсолютно не интересно сколько в строке (подстроке) символов. Мне интересно сколько она занимает места в памяти целиком. А для получения занимаемой памяти НЕ НУЖНО выяснять количество символов и складывать их размеры. (Я про это ещё повторю)

 *Koshh wrote:*   

> В винде вимвол == 2 байтам.

  Китайцы, корейцы, вместе с инженерами, физиками и математиками шутку оценили  :Smile: 

 *Koshh wrote:*   

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

 Ты ничего не показал. А проблема о порчи при некорректном разрыве, касается любой unicode кодировки. Там есть "символы модификаторы", например добавляющий апостроф перед следующим ЛЮБЫМ символом  :Wink: 

 *Koshh wrote:*   

> В сложных алгоритмах (особенно при активном выделении/особождении памяти) отладка превращается в пытку - особенно, для начинающих программеров.

  Не имеет оношения к utf. Работа со строками c ручным управлением памятью не проста сама по себе.

 *Koshh wrote:*   

>  Каким образом ты определишь объем памяти, занимаемый стркутрой с членами переменной длины? Правильно, просуммируешь их размер (см выше). Как определить количество символов в UTF8 - строке? Правильно, оргпнизовать цикл. Итак, у тебя есть два варианта - или каждый раз использовать одну из этих двух _медленных- операций, или сопровождать строку дополнительным параметром, содержащим информацию о ее длине/размере. Первое грозит откровенными тормозами, второе - усложенением кода, и как вариант - потерей одного регистра общего назначения под параметер.

  Ты не хочешь понимать что количество символов нужно в РЕДКИХ случаях. А для получения размера utf-8 строки, ограниченной нулём, можно воспользоваться функцией strlen стандартной библиотеки C.

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

 *Koshh wrote:*   

>  Получения символа по позиции - и впрямь редкая операция. Гораздо более частая операция - это получение подстроки. Но... Нам снова требуется ее (подстроки) размер в _байтах_ (нам ведь надо выделить под нее память). Способ получение - медленный цикл (по сравнению с одним умножением).

  Расскажи что такое подстрока. как ты её из строки получаешь? А места она будет занимать СТОЛЬКО ЖЕ как и занимала в строке!  :Smile:  Адрес конца минус адрес начала  :Smile: 

 *Koshh wrote:*   

> Сделаю небольшую ремарку - процессоры x86 имееют встроенные средства для облечения работы со строками - это инструкции LODS/SCAS/STOS (для 8, 16 и 32 битных символов). Также попогает режим адресации по базе с индексацией. Естественно, все это непременимо к UTF8.

  Жуткий бред. Функция strlen использует scas для определения размера строки и отлично работает с utf-8. Также без проблем работают функции по поиску позиции (адреса в памяти) подстроки. Режим адресации опять не пришей кобыле хвост. Тут не бокланы чтобы пугаться бреда из умных слов.

Резюме -

Для получения занимаемой памяти с utf-8 строкой можно обращатся как с ascii!!

 *Koshh wrote:*   

> Теперь займемся "популярными" алгоритмами. Один из самых "популярных" алгоритмов - это выделение подстроки (для UTF8 - медленный). Также довольно популярна операция соеденения строк - "аsвgвавd" + "XыXыX". Вопрос - сколько памяти надо выделить под результат? Ответ - хрен его знает, цикл покажет.

 

1. Вы не правы (см выше)

2. Всё просто делай как с ASCII строками  :Smile:  Это НАМНОГО проще чем пляски с двухбайтными символами  :Smile: 

PS: Надеюсь что был вам полезен.

----------

## kbps

 :Arrow: 

Сколько дезинформации, прям таки FAQ по шрифтам надо делать!!!

 :Arrow: 

----------

## Koshh

 *046 wrote:*   

> Так я это успешно делаю. В большинстве случаев работа с UTF имеет аналогичную трудоёмкость.
> 
> А для всяких извратов - кодировки  с постоянным числом байт на символ.

 

Еще раз - одно умножение или цикл с суммированием (не забывай про проверку условия при каждой итерации) - что быстрее? Хваит уже голословных утверждений. Я считаю, что быстрее умножение. Твои аргументы в пользу цикла?

[quote="046"]word имеет размер регистра общего назначения. И так везде, а не только в x86. Сексуальные проблемы синтаксиcа ассемблера intel тут не решают. *Quote:*   

> 
> 
> Мы говорим про конкретную архитектуру и вполне конкретный ассемблер, а также язык C. Хочешь опускать С - сходи на форум к разработчикам ядра сам-знаешь-чего =)
> 
> [quote="046"]А для получения занимаемой памяти НЕ НУЖНО выяснять количество символов и складывать их размеры. 

 

Приведи пожалуйста сей магический способ! Например, для строки "АААAAAФФФAAA": сколько байт занимает подстрока "AAФ"?

 *046 wrote:*   

> Ты ничего не показал. А проблема о порчи при некорректном разрыве, касается любой unicode кодировки. Там есть "символы модификаторы", например добавляющий апостроф перед следующим ЛЮБЫМ символом

 

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

 *046 wrote:*   

> Не имеет оношения к utf. Работа со строками c ручным управлением памятью не проста сама по себе

 

Однако язык С (и в меньшей степени - CPP) подразумевают именно такую модель работы с памятью. Указатели, массивы, malloc и так далее. Надеюсь, ты не предлагаешь всем начинающим писать исключительно на VB? =) Тогда линукс зачахнет.

 *046 wrote:*   

> Ты не хочешь понимать что количество символов нужно в РЕДКИХ случаях. А для получения размера utf-8 строки, ограниченной нулём, можно воспользоваться функцией strlen стандартной библиотеки C. 
> 
> Кстати в языках отличных от C где строка встроенный тип данных, часто хранится размер занимаемой памяти. И работет это не медленнее, а если строки большие - то и быстрее.

 

Ну наконец-то дошло. Я тебе пытаюсь растолковать, что библиотечная функция для определения длины строки в UTF8 как раз и содержит тот самый пресловутый цикл. Который сильно медленнее умножения. А т.н. Pascal-строки, где первый байт содержит размер строки, крайне неудобен для применения в C. В С++ же используюся классы, как гораздо более удобный инструмент. Но классы - вещь неоднозначная, как и C++ (поинтересуйся опять таки у девелоперов).

И напоследок - бАкланы пишется через А. Жду в следующем сообщении пояснения, каким образом цикл работает быстрее одной операции умножения.

----------

## Koshh

 *kbps wrote:*   

> Сколько дезинформации, прям таки FAQ по шрифтам надо делать!!!

 

Да ладно тебе, дай повыступать =) Форум - это не средство для поиска истины, а способ отточить свои аргументы в споре. Да и просто забавно про бОкланов почитать =) Короче, мы с этим чудом не серьезно говорим, а развлекаемся.

----------

## Azik

Граждане, а вы нить разговора не потеряли? Может вам того, в другой форум перехать? Для программистов С++ например.

Инересный исторический анекдот откопал: http://groups.google.com/group/relcom.comp.os.cmp/msg/73bd87373d9d09e1?hl=ru&. Вона какие казусы.

----------

## Koshh

 *Azik wrote:*   

> Граждане, а вы нить разговора не потеряли? Может вам того, в другой форум перехать? Для программистов С++ например.
> 
> Инересный исторический анекдот откопал: http://groups.google.com/group/relcom.comp.os.cmp/msg/73bd87373d9d09e1?hl=ru&. Вона какие казусы.

 

Очень даже может быть и потеряли =) Разве это кому-нить мешает? - стоят двое и о какой-то фигне разговаривают =)))

А анекдот и в самом деле интересен. Хотя... Все ведь помнят, как Билл ДОС прикупил, а потом перепродал ее IMB? =)

----------

## 046

 *Koshh wrote:*   

> Например, для строки "АААAAAФФФAAA": сколько байт занимает подстрока "AAФ"?

 strlen("AAФ")

 *046 wrote:*   

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

  Ты сначала узнай как в уникоде кодируются всякие умляуты европейские. А потом пиши фигню  :Smile:  И ни у кого проблем нет если учитывать что кодировка многобайтная. Сдвиг в любом уникоде страшен. А utf-8 портится только до ascii символа  :Smile: 

 *Koshh wrote:*   

> Я тебе пытаюсь растолковать, что библиотечная функция для определения длины строки в UTF8 как раз и содержит тот самый пресловутый цикл. Который сильно медленнее умножения. А т.н. Pascal-строки, где первый байт содержит размер строки, крайне неудобен для применения в C. В С++ же используюся классы, как гораздо более удобный инструмент. Но классы - вещь неоднозначная, как и C++ (поинтересуйся опять таки у девелоперов).

  Цикл поиска нулевого символа? А тебе известен иной способ узнать размер С строки?

Кстати цикл из одной инструкции будет работать быстро  :Smile:  jnz scasb или как-то так  :Smile: 

Ты всё пишешь о каком-то умножении. Что за умножение?

То есть, например, ты занешь что в строке 7 символов, и легко можешь посчитать что она займёт 7*x байт? Я же пишу что это совсем не нужно. Более того ЭТО НИЧЕМ не отличается от того что ты УЖЕ знаешь что строке для размещения в памяти нужно y байт.

А сколько в ней символов НЕ ИМЕЕТ значения.

 *Koshh wrote:*   

> И напоследок - бАкланы пишется через А. Жду в следующем сообщении пояснения, каким образом цикл работает быстрее одной операции умножения.

  Не путай боклановъ с бакланами.

Какой цикл и какого умножения?

И с какой целью? У меня подозрения в целесообразности данных операций.

----------

## Koshh

 *046 wrote:*   

> strlen("AAФ") 

 

Браво! Только в данном случае мы знаем еще и длину подстроки в символах (без этого знания само понятие подстроки не имеет смысла). Таким образом, можно либо послать strlen искать конец строки, либо умножить количество символов в подстроке на размер символа и получить ответ =) Разницу ощущаешь?

 *046 wrote:*   

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

 

А иероглифы ктайские? =) Мы говорим о конкрентных вещах - о том, что кодировки с переменно длиной символа в принципе очень "неповоротливые", и добавляют сложности программному коду.

 *046 wrote:*   

> 
> 
> Цикл поиска нулевого символа? А тебе известен иной способ узнать размер С строки? 
> 
> Кстати цикл из одной инструкции будет работать быстро  jnz scasb или как-то так

 

Снова повторяю - при операциях с подстрокой программисту известны позиции первого и последнего символа, т.е. длина строки в символах. Как это можно использовать - см. выше. Что же касается скорости цикла - то как минимум пара цсловных переходов + inc eax скушают ресурсов больше, чем одинокое умножение. Устал уже об этом говорить.

 *046 wrote:*   

> 
> 
> То есть, например, ты занешь что в строке 7 символов, и легко можешь посчитать что она займёт 7*x байт? Я же пишу что это совсем не нужно. Более того ЭТО НИЧЕМ не отличается от того что ты УЖЕ знаешь что строке для размещения в памяти нужно y байт. 

 

См. тему про подстроки выше. В случае "просто строки" искать конец все равно прийдется, а при вставке/копирвоании/выделении памяти гораздо удобнее (и быстрее) использовать значения индексов символов.

 *046 wrote:*   

> Не путай боклановъ с бакланами. 

 

После пары твоих ответов я в самом деле замечаю разницу между гордыми птицами и бОкланами =)))

----------

## 046

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

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

Вот именно что при операциях с подстрокой известны ПОЗИЦИИ. То есть адреса. В байтах!!! А не в символах. А символы засунь туда, откуда взял длинну подстроки )

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

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

Я не понял кто тебе в Utf-8 мешает использовать индексы?

----------

## Koshh

 *046 wrote:*   

> Вот именно что при операциях с подстрокой известны ПОЗИЦИИ. То есть адреса. В байтах!!! А не в символах. А символы засунь туда, откуда взял длинну подстроки )

 

Остальное можно опустить - эта фраза самая главная. Позиции - это не адреса. Адреса, кстати, не в байтах - а в числах. В байтах - размер. Но это не принципиально - вернемся к позициям =) Итак, позиция - это число. 0, 1, 2, 3 и так далее. Адрес - это адрес в памяти, что-то вроде 0xDEADBEEF. Итак, ты вызываешь функцию поиска подстроки. что она тебе вернет? _Поизицию_, или _адрес_, в зависимости от языка и библиотеки, начала подстроки в исходной строке. Вопрос - сколько выделить памяти под подстроку? Ответ - ХЗ, потому что длина подстроки никому не известна, Pascal-строки мы не рассматриваем. Следовательно - длину подстроки нужно определить.

----------

## 046

Да всё известно, вот пример.

3 строки.

 источник, из которого извлекается подстрока

 начало построки

 конец подстроки

Все нормальные функции поиска вернут адрес. Тк это обоспечивает удобный и прямой доступ к искомому элементу. (раз уж мы говорим про язык C)

После определения адресов начала и конца - вычитаем из конца начало - это и есть размер занимаемой подстрокой памяти.

----------

## Koshh

 *046 wrote:*   

> Да всё известно, вот пример.
> 
> 3 строки.
> 
>  источник, из которого извлекается подстрока
> ...

 

Еще раз - конец подстроки обычно никем не возвращается. http://www.cplusplus.com/ref/cstring/strstr.html - где тут конец подстроки? Можешь и другие функции поглядеть ради интереса - либо позиция, либо адрес...

Ладно, С будем считать устаревшим. Что у нас там еще? Паскаль? Так он, это, давно уже никому не нужен. А все новомодные C#, VB, PHP, Perl и иже с ними про адреса НИЧЕГО не знают. Зато умножать умеют очень неплохо.

----------

## Balancer

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

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

Что имеем: определение длины Cи-строк практически не тормозит. Что в однобайтовых, что в UTF-8 строках нужно тупо сканировать всю строку в поисках нуля. Только в одном случае байт инкрементим, в другом - прибавляем вычисленную константу. (Кстати, хинт: scasb не прокатит, ибо он выполняется медленнее, чем inc/cmp/jnz аж со времён 80486!).

Аналогично - методы поиска подстроки в строке, замена подстроки - всё это будет занимать практически столько же времени.

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

----------

## Koshh

 *Balancer wrote:*   

> Кстати, хинт: scasb не прокатит, ибо он выполняется медленнее, чем inc/cmp/jnz аж со времён 80486!

 

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

Если же чуть более сурьезно, то  я все же прав, производительность с UTF8, пусть и на 0.5%, но меньше, чем при постоянном размере символа. А реально... Я вот на C# серверные приложения пишу - и меня вполне устраивает код, который JIT-компилятор ваяет из IL - с оптимизацией там все в порядке  :Wink: 

----------

## lefsha

 *Koshh wrote:*   

> Что жекасается MC, то проблема заключается не возрасте или глючности программы, а в том, что программа, замечательно работающая с одними настройками ОС, при переходе на более новые (и прогрессивные) работать отказывается.
> 
> 

 

Что мне делать, если у меня работает?

 *Koshh wrote:*   

> 
> 
> То есть KOI8 и UTF-8 вещи взаимосключаемые в линухе

 

Разумеется. И слава богу что это так!

Не хватало мне тут еще зоопарка.

Все что касается документов в KOI8 под UTF-8 проблем не замечено.

Что интернет, что почта, что тексты.

Проблем нет как нет.

----------

## lefsha

 *Koshh wrote:*   

> 
> 
> В винде вимвол == 2 байтам. 
> 
> 

 

Иначе говоря Вы подтверждаете проблему товарища с CD

и кривизну поддержки языков в windows?

Нельзя так подставляться. Тут могут и наказать...

----------

## lefsha

 *046 wrote:*   

>  *Koshh wrote:*   В винде вимвол == 2 байтам.  Китайцы, корейцы, вместе с инженерами, физиками и математиками шутку оценили 
> 
> 

 

 :Rolling Eyes: 

Заметил Ваш ответ позже...

----------

## lefsha

 *Koshh wrote:*   

>  *046 wrote:*   strlen("AAФ")  
> 
> Браво! Только в данном случае мы знаем еще и длину подстроки в символах (без этого знания само понятие подстроки не имеет смысла). Таким образом, можно либо послать strlen искать конец строки, либо умножить количество символов в подстроке на размер символа и получить ответ =) Разницу ощущаешь?
> 
> 

 

Сэр Вы конечно открыли этот топик, который больше не топик.

Но пожалуйста не надо играть из себя непонятливого,

а то ведь правда можно подумать, что до Вас не доходит,

что Вам говорят!

Уважаемый Koshh я бы предложил Вам посидеть и подумать над тем,

что Вам тут говорили. И потом, когда наконец сообразите, тогда

и напишите свои ощущения. Договорились?

----------

## Koshh

 *lefsha wrote:*   

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

 

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

"Вы" - обязательно с большой буквы, словно это карикатура на вежливость может кого-то обмануть. Использование слова "уважаемый" как ругательства ("уважаемый, а чего это вы тут забыли?"). Непонятно чем подтвержденное желание говорить за всех - "нормальных людей", "здравомыслящих", "посетителей этого форума". Фразы вроде "не надо играть из себя непонятливого", "И потом, когда наконец сообразите", несущие исключительно одну цель - унизить собеседника, и показать собвственную "крутость".  Стиль типичного люмпена.

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

ЗЫ Старикан Голубицкий был тысячу раз прав, описывая подобных гоблинов

----------

## lefsha

Мда... все гораздо хуже чем я предполагал.

Я Вам отвечал по теме вашего спора с 046, но Вас кажется захлестнули

эмоции и Вы вообще отказались думать...

Предлагаю все таки успокоится и еще раз внимательно почитать,

что Вам писал 046. Его слова не лишены смысла, проверьте это

с карандашом в руке.

----------

## 046

 *Koshh wrote:*   

> Еще раз - конец подстроки обычно никем не возвращается. http://www.cplusplus.com/ref/cstring/strstr.html - где тут конец подстроки? Можешь и другие функции поглядеть ради интереса - либо позиция, либо адрес...

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

Или ты всё-таки считаешь функцией подстроки получение символа (или диапазона) по позиции(ям)? Так ты сам выше согласился что это редкая операция!!

 *Koshh wrote:*   

> А все новомодные C#, VB, PHP, Perl и иже с ними про адреса НИЧЕГО не знают. Зато умножать умеют очень неплохо.

 

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

----------

## 046

 *Koshh wrote:*   

> Если же чуть более сурьезно, то  я все же прав, производительность с UTF8, пусть и на 0.5%, но меньше, чем при постоянном размере символа.

  Если серьёзно - трудоёмкость имеет смысл только в отношении операций. utf-8 не операция. "На 0,5% меньше" не может быть серьёзным утверждением (как и Ваша правда), так как это просто бессмысленное утверждение.

Операции обьединения, поиска, замены в utf-8 имеют РАВНУЮ трудоёмкость по сравнению с кодировками с постоянным числом байт.

----------

## Laitr Keiows

 *Koshh wrote:*   

>  *sa10 wrote:*   Или юникод в винде, не юникод вовсе? 
> 
> Приведи пожалуйста конкретный пример про иероглифы, хватит уже пустой болтовни "в линуксе все супер, в винде плохо". Конкретный пример, с конкретной версией винды и дистрибутива (хотя здесь уже сложнее) линуха. Твои "подозрения" по поводу китайской винды беспочвенны, в локализованных версиях виндовс ядро неизменно, меняется только UI.

 

В японской винде вместо слеша везде отображается знак иены:

C:¥WINNT¥system32¥drivers¥

----------

## Koshh

"У меня винда виснет" - твое сообщение по смыслу не отличается от этого =) Версия винды, сервиспаки - где? Я тоже могу иену вместо слеша себе сделать - не вопрос. Поэтому, неплохо было бы написать, оно с "рождения" у тебя так отображается, или нет? И что значит "везде" ? Слеш не набирается с клавиатуры принуипиально, или после набора магическим образом трансформируется в денюжку? )

И только после этого можно более менее что-то сказать по поводу собссно проблемы.

----------

## Laitr Keiows

 *Koshh wrote:*   

> Я тоже могу иену вместо слеша себе сделать - не вопрос. Поэтому, неплохо было бы написать, оно с "рождения" у тебя так отображается, или нет? И что значит "везде" ? Слеш не набирается с клавиатуры принуипиально, или после набора магическим образом трансформируется в денюжку?

 

1) C рождения.

2) Везде слеши видны ввиде знака иены. При наборе точно так же.

----------

## Koshh

У тебя виндовс 95 или 98? Если другой - не сочти за труд все же указать версию.

Также хотелось бы узнать о региональных настройках винды (странно да - в винде тоже что-то надо настраивать=))) ) - значение имеют все 3 закладочки )

----------

## Laitr Keiows

 *Koshh wrote:*   

> У тебя виндовс 95 или 98? Если другой - не сочти за труд все же указать версию.
> 
> Также хотелось бы узнать о региональных настройках винды (странно да - в винде тоже что-то надо настраивать=))) ) - значение имеют все 3 закладочки )

 

Винда ХР, в настройках везде японский.

Выглядит все так: http://www.crosslanguage.co.jp/support/jx9/image/02-3_img01.jpg

----------

## Koshh

Ну тогда "хз" =) Тем не менее - простой вопрос - а вообще слеши в системе отображаются? charmap, notepad, IE - что показывают они? Особенно интересно выглядит идея посмотреть слеш разными системными шрифтами.

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

----------

## dasV

А что камрады? Как текстовый редактор нашли? А то я через дебри ваших ..гм…программистских загогулин так и не понял, что человек то выбрал? То ли оОо то ли ЛаТеХ то ли вообще MS.

Вообще уважаемые, как я понял, товарищ просто решил пофлемить. Странно, что все повелись =(

С уважением das

----------

## dragn

 *lefsha wrote:*   

>  *fedukoff wrote:*   Вкуснее нету (зачем?). 
> 
> НЕ ПОРТИТЕ, ПОЖАЛУЙСТА, РУССКИЙ ЯЗЫК.
> 
> слово ВКУСНО и его производные употребляются ТОЛЬКО в связи с пищей.
> ...

 

 :Laughing:  хахаха!! вы это нашей семинаристке по матанализу скажите!!... =))))

(извините за оффтоп, не смог удержаться..))

----------

## 4le

 *Laitr Keiows wrote:*   

>  *Koshh wrote:*    *sa10 wrote:*   Или юникод в винде, не юникод вовсе? 
> 
> Приведи пожалуйста конкретный пример про иероглифы, хватит уже пустой болтовни "в линуксе все супер, в винде плохо". Конкретный пример, с конкретной версией винды и дистрибутива (хотя здесь уже сложнее) линуха. Твои "подозрения" по поводу китайской винды беспочвенны, в локализованных версиях виндовс ядро неизменно, меняется только UI. 
> 
> В японской винде вместо слеша везде отображается знак иены:
> ...

 

Это не бага, это бай дизайн.

----------

## 4le

 *Koshh wrote:*   

>  *046 wrote:*   
> 
> [кусь]
> 
> После определения адресов начала и конца - вычитаем из конца начало - это и есть размер занимаемой подстрокой памяти. 
> ...

 

Кажется я понял причину недопонимания.

Ты, видимо, говоришь о подстроках, заданных как литеральные константы.

Только в этом случае есть альтернатива ::strlen() / string::size() - sizeof().

Т.е. определение их длин происходит на этапе компиляции.

Во всех остальных случаях тебе придётся вычислять длину строки в рантайме.

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

Очевидно, что длина константной строки тоже является константой. Следовательно достаточно столько раз вызвать strlen, сколько определено константных строк.

Учитывая, что действительно большие количества константных строк, как правило, выносятся в ресурсные файлы,

в реальной программе число литеральных константных строк пренебрежительно мало.

Т.о. сколько-нибудь заметного падения производительности из-за "проблемы конца подстроки в utf-8" не будет.

Каково, а?

----------

