И снова (и снова) о вебе и кодировках русского языка

Примерно к 2001 году вопрос с кодировками для русскоязычных WWW-сайтов казался полностью решенным: все сколько-нибудь распространенные браузеры научились кодировке Windows-1251 и только ее можно было оставить на сайтах (выдавая правильный Content-Type)

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

Сейчас расцветает динамика, которую рисуют разными видами яваскрипта (document.write, element.innerHTML=...). При выводе таких блоков есть safe way - выводим все в Unicode через HTML entities вида &#nnnn, правда вывод раздувается в шесть раз, ну да терпеть можно. Если кодировка страницы, на которой мы размещаемся, может быть только одна, то можно выводить в этой кодировке, если возможных кодировок несколько, то вывод Javscript должен соответствовать выводу HTML. А ведь на многих сайтах до сих пор стоит Russian Apache, и ведь предлагали мне делать его через Unicode.....

Ситуация становится резко хуже, когда скрипт и размещающая его страница имеют разных хозяев, разные настройки. Впрочем, safe way через &#nnnn остается.

Все становится еще хуже, если мы пытаемся обработать пользовательский ввод. Скажем так, как сделано у нас в Персональном Поиске или в Гиперпоиске, когда на странице размещается код примерно такого вида:

 &lt;script&gt;<br>
 var url = escape(document.location.href);<br>
 document.write('&lt;script src="http://hypersearch.novoteka.ru/search.js?url='+url+'"&gt;&lt;scr'+'ipt&gt;<br>
 &lt;script&gt;

Этот код рисует поисковую форму, результаты поиска и так далее.

Пользовательский ввод доступен в URL, но в какой он будет кодировке ? Есть ли какой-то разумный способ узнать ? Естественно, кроссброузерный (IE5+, Mozilla, Opera 7+), не зависящий от транзитных перекодировок (т.е. на клиенте) ?

Я, к сожалению, такого способа не знаю: document.characterSet не работает в IE7 и IE5.5 (6-го под рукой не оказалось) и не работает в старых Операх, что сводит его ценность к нулю.

Это счастье усугубляется прочими мелочами, вроде кодирования query string в виде %uNNNN в некоторых случаях. И если UTF-8 еще можно распознать автоматом, то как отличить КОИ-8 от cp1251 по нескольким словам пользовательского ввода — совершенно непонятно.

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

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

p.s. Для нашего поискового скрипта завел отдельный ключик: сайт в UTF-8, который нужно ставить вручную на страницах с такой кодировкой. На КОИ8 наплевал.

Comments

Это не новая беда, это всё таже старая беда, она тянется с еще задолго до 2001, только эти эффекты были на сайтах, сделаных в koi8-r, при попытке импорта контента, отдаваемого в cp1251. Правда при наличии русского Апача сей бардак был заметен только для клиентов, принимающих не в cp1251.

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

Но сейчас все больше сайтов в UTF (и это хорошо, прогрессивно, инструментальные средства почти все работают) и кошмар начался снова.

Алексей, нашел заметку о проблемах с УТФ.
Так вот сегодня запустил у себя персональный поиск от Новотеки и проблема в том, что при вводе кириллического слова query string кодируется в %uNNNN во _всех_ случаях, независимо от кодировку, которая устанавливается в файле.

Результатом является ответа Апача (406):

An appropriate representation of the requested resource /search.html could not be found on this server.

Не подскажете, как решить эту проблему?
Заранее спасибо!

Ага, я уже в курсе :)

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

Но этот ключик надо поддержать с нашей стороны, естественно

Да, utf8=1 ставить пробовал (подсмотрел в хелпе по hypersearch), результат не изменился.

Так что будем ждать, спасибо :)

p.s. Даже странно, что из всех >500 персональных поисков Новотеки, ни один сайт не работает на UTF-8 (судя по отсутсвию "следов" проблемы в интернете).

Hypersearch - другой проект и у него корни из другого места растут.

Но думаю завтра уже все будет. utf8=1 оставьте, в некоторый момент заработает (я думаю)

Вместо параметра, что сайт в utf, можно подставлять произвольную букву русского языка, как этот делает Максим Зотов в коде своего счётчика.

В зависимости от того, в каком виде придёт эта буква, определяется кодировка страницы.

Простой и рабочий способ.

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

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

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