A USC2 вас устраивает? Строго двухбайтная кодировка.

Как человек, постоянно возящийся с русским, аглийским, испанским и японским, говорю, что юникод есть *правильный* путь, а привычка к 8-битным кодировкам -- следствие привычки к 1-2 языкам.

Думаете, откуда была полоса в истории, когда разный софт настаивал на 7-битности всех символов, а 8-битные "ублюдочные" кодировки гордо не переваривал? Нравилось, а?

(Reply to this) (Thread)

Да - и великие и ужастные символы SI и SO.

(Reply to this) (Parent)

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

(Reply to this) (Parent)

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

(Reply to this) (Parent)

UCS2 меня, кстати, устраивает - именно тем, чт, при нынешнем положении вещей, никому и в голову не придет сувать ее в текстовые файлы.

А в бинарниках, или во внутреннем представлении программ - да сколько угодно!

Почти.

(Reply to this) (Parent)

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

???

Вы что-то общезначимое при этом имели в виду?

(Reply to this) (Thread)

Насколько я понял, он из числа отцов-основателей и активных участников OFISP (в пору его активности), его проектов ofisp-antispam и RBL

Думаю, не надо подробно рассказывать, сколько вреда эта гопота нанесла обществу.

(Reply to this) (Parent) (Thread)

Он, кажется, либертарианец.

(Reply to this) (Parent)

>Думаю, не надо подробно рассказывать, сколько вреда эта
>гопота нанесла обществу.

А можно рассказать? Я совершенно не в курсе

Такие дела
Миша

(Reply to this) (Parent) (Thread)

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

Поэтому я могу интерпретировать твои слова только как несогласие с моими словами.

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

(Reply to this) (Parent) (Thread)

Нет, я правда не знаю. Как-то мимо меня прошло.
При этом я много лет был подписан на ЕЖЕ-лист,
где все такие вещи перетирались весьма активно.

Такие дела
Миша

(Reply to this) (Parent) (Thread)

OFISP (Open Forum of Internet Service Providers) - тусовка сисадминов мелких и мельчайших московских провайдеров. При этом тусовка, естественно, раздувала щеки и претендавала на роль "представителей сетевой общественности". Из их подвигов особенно примечательны написанные ими ими "Правила Пользования Сетью" (aka OFISP-005, OFISP-008) которые, по их заявлениям, являются "нормами оборота в русском интернете" и обязательны для юзеров и провайдеров. Тем, кто их при этом посылал нафиг, они делали всякие технические пакости, доступные им как сисадминам ISP. В особенности они были повернуты на "борьбе со спамом", понимаемом ими весьма своеобразно (см "правила пользования сетью"), но занимались и другими выходками, например развязыванием войны против домена .su, осуществляемой в том же своеобразном стиле.

(Reply to this) (Parent) (Thread)

Я чего-то припоминаю. Это не Санчес ли Милицкий
их писал? Который kirguduev@lj. Инфернальный,
действительно, персонаж

> например развязыванием войны против
> домена .su, осуществляемой в том же
> своеобразном стиле.

Да, редкостное ублюдство, эту компанию я помню.
Но там в основном какие-то фидорасы изощрялись, кажется.

Такие дела
Миша

(Reply to this) (Parent) (Thread)

таки kirguduev@lj его рекламировал в печати. А писал именно что croco@lj.

(Reply to this) (Parent) (Thread)

Фидорасы! Ага.

(Reply to this) (Parent) (Thread)

Пааапрашу без обобщений!!!!

(Reply to this) (Parent) (Thread)

(Reply to this) (Parent)

Unicode как внутреннее представление вполне нелохо решает насущную проблему. Как "внешнее" неплохо ведет себя UTF-8. А работать с мультиязыковостью на уровне locale - еще хуже и глючнее.

(Reply to this) (Thread)

Ну так используя нормальные кодировки, тебе в 90% случаев просто-напросто не придется "работать с мультиязыковостью". Достаточно быть charset-aware, то есть, грубо говоря, не менять тех байт, о которых тебя специально не просили. А в оставшихся 10% речь идет об обработке сложноструктурированной информации на естественных языках, и юникод (в форме ли utf8 или любой другой) сам по себе никаких проблем не решает и хорошо если вообще помогает.

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

Ты почитай, почитай, что там croco@lj пишет.

(Reply to this) (Parent)

Вот мне так нравится желание некоторых побороться с мельницами лишний раз..

(Reply to this)

Не дошло до меня, что ты здесь хотел сказать :-)

(Reply to this)

Ну так и прочие кодировки туда же. Ибо, ты, блин, давно od запускал? И как текст? Кодировка - она по определению для автомата. А уж насколько тупого - это второй вопрос. Моим перловым скриптам, я бы сказал, все равно, какая там кодировка. Главное - чтоб известная. Ибо текст с точки зрения его обработки - это последовательность символов с операциями "следующий символ" и "предыдущий символ" и более высокоуровневыми, построенными на них, а преобразовывать в последовательность символов какую-нибудь однобайтовую, моноширинную (очень характерно в твоем посте путание Unicode и UTF-8, да), мультибайтовую (не обязательно UTF-8) кодировку - это уже не для человека занятие, и даже не для программиста.

А за работу с текстом как с массивом символов (т.е. с произвольной индексацией) вообще убивать на месте надо...

(Reply to this) (Thread)

Это все пфигня.

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

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

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

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

(Reply to this) (Parent) (Thread)

Пойду с конца.

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

2. При вводе-выводе у тебя все равно используется API. Только надо использовать адекватный API - для ввода-вывода символов, а не байт, как сейчас. У перловых read и print почему-то нет никаких проблем с вводом-выводом символов. А у сишных, что printf/scanf, что write/read - почему-то есть. К чему бы это?.. Ну да, при асинхронном вводе-выводе ты можешь оказаться в ситуации, что транспортный уровень донес до тебя нецелый символ. Ну так и сейчас ты можешь оказаться в ситуации, когда транспортный уровень принес тебе нецелую логическую единицу. Ситуация разрешается точно так же, только разрешение ее можно упрятать в API, а не развлекаться этим каждый раз вручную. А то, что единица транспортного уровня в принципе не может гарантированно вместить целый символ - мала слишком - это реальность. данная нам в ощущениях, с этим бороться невозможно.

(Reply to this) (Parent)