WWW and cyrillic
Ivan Popov
: Предлагаю для обсуждения новую идею (а может быть и не новую) способа
: определения кодировки кириллицы на клиенте.
... пропущено ...
: Какие будут замечания/предложения?
: Может быть у кого-нибудь есть более интересные варианты?
По существу - ЗАЧЕМ надо стандартизовать _кучу_ способов выдачи
сервером кириллицы? Если проще серверам
самим знать, которые из документов - на русском,
и выдавать их все в одной кодировке (не важно, какой, лишь бы
годилась для русских текстов - вот ее стандартизовать стоит).
Пущай перекодируют, если в их системе другая - это их локальное дело.
А дело клиента - показать эту кодировку (пущай перекодирует на лету,
если в его системе другая - это его локальное дело)
Лирическое отступление:
Ежели принимать во внимание существование и других не-ASCII языков,
то может быть полезен атрибут документа - язык, на котором написано.
Но и тогда не стоит забивать себе голову разными кодировками для
одного алфавита.
А вообще-то, язык не является свойством документа! Нет проблем
столкнуться с текстом на смеси русского и японского :) Тогда
уж никак не обойтись без двухбайтовой кодировки. И даже смесь
русского с украинским - нетривиально.
Конец лирики.
Наконец, как обычно, обсуждается языковая проблема в контексте
ровно двух языков - русского и английского. Как будто к нашим серверам
из прочего мира никто никогда не обратится. А почему при отсутствии
настройки на кириллицу должен приезжать документ на _английском_?
А не на русском латинскими буквами? Для нашенских - русский точно полезнее...
И из прочих - далеко не все по аглицки умеют...
Тогда уж на Эсперанто, что ли - тоже прекрасно в ASCII вписывается.
Иван Попов <p...@demos.su>
Evgeny Mironov
Предлагаю для обсуждения новую идею (а может быть и не новую) способа
определения кодировки кириллицы на клиенте.
Большая просьба - отвечать только по существу.
------------------------------------------------------
Идея использования различных портов для различных кодировок кириллицы
неподходит, когда требуется создать распределённую в сети систему
взаимосвязанных серверов.
Этот способ нормально работает только тогда, когда клиент общается только
с одним и тем же сервером.
Дело в том, что если на сервере A есть ссылка на русский документ
на сервере B, то клиент не сможет понять - какой порт использовать
при обращении к серверу B. Ведь внутри документа (а он один на все кодировки)
можно указать только один порт.
Есть решение, но оно мне не очень нравится:
- Внутри документов, в ссылках еа другие серверы, после имени сервера
вставлять специальное ключевое слово, например %PORT%.
(напр - <A HREF="http://host.domain:%PORT%/document.html"> )
- Когда сервер посылает документ клиенту он просматривает этот документ
и заменяет ключевые слова %PORT% на номер своего порта.
Если все будут придерживаться одного стандарта на номера портов - всё будет
работать.
Недостатки:
- Опять эти идиотские порты :-)
- Ухудшается производительность сервера
- нарушается стандарт на URL в документах.
Я хочу предложить новый вариант.
Думаю этот вариант более перспективный, т.к. практически полность соответствует
стандарту HTTP 1.0.
Суть идеи:
Согласно HTTP 1.0 в заголовке запроса есть поле "Accept:" в котором
указываются форматы содержимого (content types) документов, которые
клиент может принимать. Эта информация перенастраивается в каждом
клиенте.
Допустим мы договорились о использовании следующих "виртуальных"
форматов:
text/x-cyrillic-iso-8859-5
text/x-cyrillic-koi8
text/x-cyrillic-cp866 (Alt)
text/x-cyrillic-cp1251 (Windows)
В настройку клиента добавляется один из этих форматов.
Когда клиент запрашивает документ с сервера он вставляет в
поле "Accept:" заголовка запроса этот формат.
Сервер получив запрос проверяет в поле "Accept:" наличие одного из
этих форматов и устанавливает - какую кодировку использует клиент.
Если документ существует и он в формате "text/plain" или "text/html"
и кодировка клиента отлична от кодировки сервера, то сервер перекодирует
этот документ в соответствующую кодировку.
Если сервер не может перекодировать (незнает имя кодировки), то клиенту
возвращается сообщение об ошибке.
Если сервер не обнаружил в запросе ни одного формата
типа - "text/x-cyrillic-*", то:
- если документ написан на русском языке (это сервер должен уметь отличать),
то клиенту возвращается сообщение (на английском), что документ
русскоязычный и если
пользователь хочет его получить, то должен правильно настроить
свой интерфейс. Далее указывается ссылка на документ в котором по-английски
написано - как настроить WWW клиент.
- если документ написан на английском языке, то он пересылается клиенту
без перекодировки.
Поле "Accept:" точно задействовано в клиентах Mosaic для всех систем.
О других клиентах - надо выяснять, но я думаю, что *качественный*
клиент *должен* использовать это поле всегда.
Т.к. поле "Accept-language:" пока не имплементировано во многих
распространенных клиентах ( в частности в Mosaic), то его пока можно
игнорировать на сервере либо считать не обязательным и по умолчанию
подразумевать, что все клиенты принимают доки на русском языке.
А можно обрабатывать и так ( в случае наличия этого поля в запросе):
1. Если в поле указано Accept-language: ru en
(т.е. русский и английский)
- если есть формат "x-cyrillic-*" в запросе, то возвратить русский док в
соответствующей кодировке
- если нет форматa "x-cyrillic-*" в запросе, то возвратить английский
док (если есть) либо собщение о неправильной настройке.
2. Если в поле указано Accept-language: en (т.е. только английский)
- если есть английский док - возвратить его
- если есть только русский док, то выдать сообщение о наличии только
русского дока и ссылку на правила настройки клиента для работы с русскими
доками
3. Если в поле указано Accept-language: ru (т.е. только русский)
- если есть русский док:
- если есть формат "x-cyrillic-*" в запросе, то возвратить русский
док в соответствующей кодировке
- если нет форматa "x-cyrillic-*" в запросе, то возвратить
собщение о неправильной настройке.
- если есть только английский док выдать сообщение о наличии только
английского дока и ссылку на него.
Какие будут замечания/предложения?
Может быть у кого-нибудь есть более интересные варианты?
--EM
PS. Просьба не начинать дискуссию по вопросам типа:
- "Какая кодировка лучше?"
- "У нас стандарт де-факто, а остальное мы не признаём"
- "Нафига нам это надо? У нас и так всё работает."
Alexander Ermolaev
> Извиняюсь, в прошлый раз не удалось послать :-)
> Предлагаю для обсуждения новую идею (а может быть и не новую) способа
> определения кодировки кириллицы на клиенте.
> Большая просьба - отвечать только по существу.
постараюсь...
> ------------------------------------------------------
> Идея использования различных портов для различных кодировок кириллицы
> неподходит, когда требуется создать распределённую в сети систему
> взаимосвязанных серверов.
> Этот способ нормально работает только тогда, когда клиент общается только
> с одним и тем же сервером.
хм, ну вот тут двоякий момент, дело в том, что это не есть плохо, если этот
сервер cache+proxy, что, например, использую я в локальной сети и для
клиентов BBS, с быстродействием особых проблем нет зато все перекодируется в
одном месте и есть некоторый траффик не качается по сто раз... этот вариант
локально решает почти все проблемы, кроме некоторых тонкостей с
перекодировкой <head>, но это не фатально...
> Дело в том, что если на сервере A есть ссылка на русский документ
> на сервере B, то клиент не сможет понять - какой порт использовать
> при обращении к серверу B. Ведь внутри документа (а он один на все кодировки)
> можно указать только один порт.
см. выше, там вообще вопросов не возникает, снаружи всегда ожидается koi8,
ну а на выходе по выбору, в принципе ничто не мешает извращаться в любых
комбинациях, вот только зачем? мне кажется разумнее рекомендовать именно
такой вариант, правда он требует хотя бы одной Unix тачки или договоренности
с кем-то, кто возьмется взять на себя подобное бремя.
> Есть решение, но оно мне не очень нравится:
> - Внутри документов, в ссылках еа другие серверы, после имени сервера
> вставлять специальное ключевое слово, например %PORT%.
> (напр - <A HREF="http://host.domain:%PORT%/document.html"> )
> - Когда сервер посылает документ клиенту он просматривает этот документ
> и заменяет ключевые слова %PORT% на номер своего порта.
> Если все будут придерживаться одного стандарта на номера портов - всё будет
> работать.
> Недостатки:
> - Опять эти идиотские порты :-)
> - Ухудшается производительность сервера
> - нарушается стандарт на URL в документах.
>
последнее самое смертельное, так что можно забыть об этом решении сразу...
выйдет новая версия, появится новый продукт и плевать ему на эту приблуду, а
весь мир под свой шаг не переделаешь, так что... увы...
> Я хочу предложить новый вариант.
> Думаю этот вариант более перспективный, т.к. практически полность соответствует
> стандарту HTTP 1.0.
> Суть идеи:
> Согласно HTTP 1.0 в заголовке запроса есть поле "Accept:" в котором
[skipped]
> Какие будут замечания/предложения?
когда появятся клиенты с полноценным language-support тогда и можно об
этом говроить, беда Internet в том, что они пользуется стандартами де-факто,
те всегда с реализациями, так что, пишите клиент, будем обсуждать, а так
вилами по воде... пока я могу сказать, что, конечно MIME самое правильное
решение и поле Accept тоже правильное, но вот речь-то идет о паре
сервер/клиент и единственная точка их пересечения -- HTTP и набор rfc... те
типы должны быть внесены в mime, впрочем, тк инициализатор клиент, то вроде
бы можно этого избежать, но вот опасность, что сделает сервер, который
не настроен? будет ли он игнорировать поле или в каком-то случае случится
фатализм, серверов много, надо проверить, если какие-либо неадекватно уже
реагируют, то об идее придется забыть...
> Может быть у кого-нибудь есть более интересные варианты?
см. выше...
> --EM
> PS. Просьба не начинать дискуссию по вопросам типа:
> - "Какая кодировка лучше?"
> - "У нас стандарт де-факто, а остальное мы не признаём"
> - "Нафига нам это надо? У нас и так всё работает."
вот касательно последнего, в самом деле... я не говорю, что это самое
_лучшее_ решение, но самое независимое от остальных -- точно, а это
немаловажно, впрочем, есть и тут проблемы, очень долго ИАЭ эксплуатировал
сервер, который вовсе не соответсвовал HTTP 1.0 и соответсвенно никакие
proxy и cache его не брали... впрочем, они вовремя одумались и отказались от
кривой самоделки, тк не смогли ее довести до работоспособного уровня, как бы
история не повторилась с различными клиентами, впрочем, идея вполне здравая,
вот только нужно проверить сперва существующие сервера, наиболее популярные,
естественно...
--
AE
"Communication Company MARK-ITT", Ltd., +7-3412-250149,250040,250057
Rudnev Aleksei
>------------------------------------------------------
Rudnev Aleksei
> хм, ну вот тут двоякий момент, дело в том, что это не есть плохо, если этот
>сервер cache+proxy, что, например, использую я в локальной сети и для
>клиентов BBS, с быстродействием особых проблем нет зато все перекодируется в
>одном месте и есть некоторый траффик не качается по сто раз... этот вариант
>локально решает почти все проблемы, кроме некоторых тонкостей с
>перекодировкой <head>, но это не фатально...
ожидаю КОИ-8 (я понимаю возможные возражения, но это такой же факт,
как и то, что стандарт для MS DOS - ALT код). Но
в остальном я не согласен с Сашей.
>такой вариант, правда он требует хотя бы одной Unix тачки или договоренности
>с кем-то, кто возьмется взять на себя подобное бремя.
Но все равно - факт, что -
- кодировки на машине КЛИЕНТА разные (так как системы разные),
- клиенты бывают тоже РАЗНЫЕ. И даже имея очень хорошую программу
'мозаика-XXX', вы не убедите очередного Ваню Голубкова, что она лучше
'мозаики-YYY', и не напеределываетесь оных программ.
- языки клиента тоже бывают разные.
Так что мне очень нравится идея ввести (сначала де-факто, а потом и
забить) стандартрый способ указания, какую кодировку и какой язык хочет
клиент. При условии, что это легко сделать в наиболее распространенных
клиентах. Proxy на всех не напасешься, однако.
>> Какие будут замечания/предложения?
> когда появятся клиенты с полноценным language-support тогда и можно об
>этом говроить, беда Internet в том, что они пользуется стандартами де-факто,
>те всегда с реализациями, так что, пишите клиент, будем обсуждать, а так
>вилами по воде... пока я могу сказать, что, конечно MIME самое правильное
>решение и поле Accept тоже правильное, но вот речь-то идет о паре
>сервер/клиент и единственная точка их пересечения -- HTTP и набор rfc... те
Я не понял. Так есть или нет в http поля запроса, которые -
- можно легко установить в СУЩЕСТВУЮЩИХ клиентах,
- которые им не помешают работать с СУЩЕСТВУЮЩИМИ серверами,
- и которые легко принять и обработать в модифицированном сервере ncsa
или других (впрочем, сервер есть программа - его всегда поправить можно, так
что последнее наименее важное).
>типы должны быть внесены в mime, впрочем, тк инициализатор клиент, то вроде
>бы можно этого избежать, но вот опасность, что сделает сервер, который
>не настроен? будет ли он игнорировать поле или в каком-то случае случится
>фатализм, серверов много, надо проверить, если какие-либо неадекватно уже
>реагируют, то об идее придется забыть...
>сервер, который вовсе не соответсвовал HTTP 1.0 и соответсвенно никакие
>proxy и cache его не брали... впрочем, они вовремя одумались и отказались от
>кривой самоделки, тк не смогли ее довести до работоспособного уровня, как бы
Ну не совсем. Мы не смогли остановить вовремя энтузиаста Вакуленко.
на самом деле было бы зачем его (этот kid) вести - а так получился сервер,
во всем абсолютно хуже NCSA - естественно, отказались.
Alexander Ermolaev
> >такой вариант, правда он требует хотя бы одной Unix тачки или договоренности
> >с кем-то, кто возьмется взять на себя подобное бремя.
> А как настраивается твой Proxy вариант? И с чем работает?
вот дойду до noc и покажу, в понедельник не обещаю, но я всю неделю буду в
столице и около и, очевидно, придется ждать пятницы во всех отношениях...
;-)
> Так что мне очень нравится идея ввести (сначала де-факто, а потом и
> забить) стандартрый способ указания, какую кодировку и какой язык хочет
> клиент. При условии, что это легко сделать в наиболее распространенных
> клиентах. Proxy на всех не напасешься, однако.
а вот тут ты ошибаешься, на всех и всего один, ладно, очно обсудим плюсы и
минусы и не только этого, но и кривого сервера статистики от АО, он опять
меня вынудил непристойно ругаться...
> >сервер, который вовсе не соответсвовал HTTP 1.0 и соответсвенно никакие
> >proxy и cache его не брали... впрочем, они вовремя одумались и отказались от
> >кривой самоделки, тк не смогли ее довести до работоспособного уровня, как бы
> Ну не совсем. Мы не смогли остановить вовремя энтузиаста Вакуленко.
> на самом деле было бы зачем его (этот kid) вести - а так получился сервер,
> во всем абсолютно хуже NCSA - естественно, отказались.
хм, ну есть моменты, где ncsa хуже cern, мне вот приходится два сервера
разных держать, да я вот тут посчитал у меня в локальной сети крутятся 5 WWW
серверов на 3-х машинах разного назначения и сделать меньше никак не
получается... издержки технологии, увы, но это в любом случае много дешевле,
чем остальные решения с руссификацией... мы вот сейчас делаем сервер
статистики через www, точнее уже кое-что сделано и работает, но пока не
полный копплекс, показать наружу, увы не могу, security, впрочем, будучи
очно в noc могу показать из Lynx со своей тачки, мало того, сейчас у нас у
каждого uucp'шного юзера есть возможность смотреть свою статистику довольно
подробно через Lynx, пользуясь своим login/password, с ведущими конференций,
те с конторами кому мы платим за информацию мы не смогли найти лучшего
решения... сейчас вот еще есть заготовки для факсового пункта коллективного
пользования с выносом на другую площадку чрезе www опять же, ну кое-какие
штучки выпадают наружу... так что технология www реально позволяет экономить
очень немалые деньги...
Alexander Ermolaev
> Ежели нету текстов - существуют фонты для rfc1489 и драйверы клавиатуры.
> И проблемы как-то становится не видно... А без перекодировщиков все
> равно не прожить, даже без WWW (это к тому, что делать с выкачанным файлом).
угу, особенно глупо наворачивать все эти дела на Lynx/Mosaic, если будет
случаться ftp и там в кои-8 чего-нибудь, во, точно, надо забабахать такой
сервер для прикола... или еще гуще -- telnet... короче, таблица
перекодировки должна быть в клиенте, а в сети есть стандарты... rfc они тут
называются... ну так сложилось...
Alexander Ermolaev
> Но перекодировеа в клиенте, конечно, более правильно. Вот занялся бы
> кто-нибудь этим...
есть такое понятите -- ttymap, те перекодировка на уровне драйвера
терминала, очевидно, это самое универсальное и старое решение...
Dima Antipov
>Ivan Popov (p...@demos.su) at 3 Oct 1994 10:12:02 GMT wrote:
>> Ежели нету текстов - существуют фонты для rfc1489 и драйверы клавиатуры.
>> И проблемы как-то становится не видно... А без перекодировщиков все
>> равно не прожить, даже без WWW (это к тому, что делать с выкачанным файлом).
> угу, особенно глупо наворачивать все эти дела на Lynx/Mosaic, если будет
>случаться ftp и там в кои-8 чего-нибудь, во, точно, надо забабахать такой
>сервер для прикола... или еще гуще -- telnet... короче, таблица
Не, ну FTP можно скриптом обойти, как это у нас и сделано (кстати, FTP'шных
серверов с КОИ8 - полно), на WAIS - тоже скриптик у нас есть. А telnet все
равно отдельный клиент.
Но перекодировеа в клиенте, конечно, более правильно. Вот занялся бы
кто-нибудь этим...
>перекодировки должна быть в клиенте, а в сети есть стандарты... rfc они тут
>называются... ну так сложилось...
>
>--
> AE
>
>"Communication Company MARK-ITT", Ltd., +7-3412-250149,250040,250057
Dmitry.
Dima Antipov
>Dima Antipov (di...@elvis.ru) at 9 Oct 1994 15:20:22 GMT wrote:
>
>> Но перекодировеа в клиенте, конечно, более правильно. Вот занялся бы
>> кто-нибудь этим...
> есть такое понятите -- ttymap, те перекодировка на уровне драйвера
>терминала, очевидно, это самое универсальное и старое решение...
Но не для графических терминалов... :(
Dmitry.
Vladimir Barmin
Dima Antipov
xmodmap(1) User Commands xmodmap(1)
xmodmap - utility for modifying keymaps in X
Дык это - (1) для клавиатуры, и (2) для иксов...
А для виндов?
Dmitry.
Alexander Ermolaev
> Dmitry.
проверю постепенно и для X, но вот для ptty и tty работает с равным
успехом, так какая разница X-м, если там ptty перекодирует? я говорю о SYSV,
может просто в Sun чего недокрутили...
Vladimir Barmin
> In article e...@simtel.ru, b...@simtel.ru (Vladimir Barmin) writes:
> >Dima Antipov (di...@elvis.ru) wrote to relcom.tcpip:
> >> In article m...@hq.izhmark.udmurtia.su, a...@mark-itt.ru (Alexander Ermolaev) writes:
> >> >Dima Antipov (di...@elvis.ru) at 9 Oct 1994 15:20:22 GMT wrote:
> >> >
> >> >> Но перекодировеа в клиенте, конечно, более правильно. Вот занялся бы
> >> >> кто-нибудь этим...
> >> > есть такое понятите -- ttymap, те перекодировка на уровне драйвера
> >> >терминала, очевидно, это самое универсальное и старое решение...
> >
> >> Но не для графических терминалов... :(
> >
> >xmodmap
> xmodmap(1) User Commands xmodmap(1)
> xmodmap - utility for modifying keymaps in X
> Дык это - (1) для клавиатуры, и (2) для иксов...
> А для виндов?
Так те, кто хотят юзать всякие WWW очень быстро понимают,
что винды для этого мало пригодны. И переезжают под полуось,
ну а после полуоси под юникс уже совсем быстро... месяца не проходит:-)
> Dmitry.
--
Vladimir Barmin