Схема при которой все xhtml страницы работают на windows-1251, ajax с сервера клиенту кидает windows-1251, а ajax с клиента серверу кидает UTF-8 абсолютна приемлема и используется на большинстве ресурсов.

Но еще более приемлима схема, когда везде UTF :) Тогда и iconv никакой не нужен и в других областях (не ajax) проблем меньше.

caezar Dec 17 2007 at 23:11

и иконм и в других областях и страници вдвое тяжелее....

Angerslave Dec 17 2007 at 23:14

+1, у самого сайт, хоть и не без труда, переведён на UTF-8. Запары бывают только с теми функциями что не понимают UTF, тогда юзаю iconv. Но такое встречается редко.

1mdm Dec 17 2007 at 21:12

Кодировки вроде windows-1251 архаизм.
Зачем каждый раз iconv дёргать, зачем эти трансляции?
UTF-8 наше всё. И если идти в ногу со временем, эта статья бы не появилась.

mihazimin Dec 17 2007 at 22:06

Ребята, этот топик как раз о том как делает большинство профессиональных разработчиков в России сейчас.

Столкнувшись с тем, что, по большому счету, AJAX запрос всегда отправляет UTF-8 молодые разработчики приходят к мнению о том, что нужно и страницы непременно отправлять в нём. Что, в принципе, не является панацеей. И не всегда оптимально сказывается на производительности.

Зачем всё делать на UTF-8 когда страницы содержат только русские и латинские буквы? Сортировки в UTF-8 могут проходить в несколько раз медленнее, количество контента загруженного на страницы увеличивается в 2 раза.

И почему habrahabr.ru и др. не используют UTF-8 как основную кодировку, при этом во всю отправляя AJAX запросы в ней?

Ответ прост: это удобно и эффективно.

UFO just landed and posted this here

gro Dec 18 2007 at 09:14

Зачем всё делать на UTF-8 когда страницы содержат только русские и латинские буквы?

А почему бы и не в UTF?

Сортировки в UTF-8 могут проходить в несколько раз медленнее

Какие сортировки? В базе? Так все нормальные базы внутри в UTF. Если же вы работаете не в UTF, то это означает только, что на входе и выходе базы будет происходить перекодировка, что будет есть ресурсы, за которые вы так волнуетесь. Добавьте сюда бесконечные SET NAMES при запросах и множество тем на форумах: "Ах, почему у меня сплошные вопросики выводятся".

количество контента загруженного на страницы увеличивается в 2 раза

Количество контента будет = верстка + английский контент + русский * 2
По сравнению с общим объемом, включая картинки, прибавка для современных сетей ничтожна. Используйте gzip-сжатие и вообще будет стремится к нулю

UFO just landed and posted this here

aim Dec 17 2007 at 21:28

а можно идиоту пояснить зачем использовать 1251 страницу (Или любую другую не utf-8) если всё остальное идёт в utf-8?!!!!!!

gro Dec 17 2007 at 21:34

Видимо потому что все привыкли к 1251, всё работает и сверстано в 1251 (еще в конце 90х), а теперь бедному программисту приказали быстро навешать на всё это модных фенечек :)

aim Dec 17 2007 at 22:02

что-то я не видел таких проектов. чтобы аякс и свёрстано в конце 90х... да ещё и в 1251...

mihazimin Dec 17 2007 at 22:10

Сейчас вы находитесь на сайте, который отдаёт страницы отнюдь не в UTF-8, при этом вполне сносно AJAX-запросы отправляет, естественно, в UTF-8.

aim Dec 17 2007 at 22:11

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

что касается хабры я так и не могу понять для чего это сделано.

mihazimin Dec 17 2007 at 22:13

не, это не я привел. Это стебался кто-то.

aim Dec 17 2007 at 22:14

да. извиняюсь, это был gro.

mihazimin Dec 17 2007 at 22:21

Ну vkontakte.ru, moikrug.ru, market.yandex.ru всё таки тоже работают на windows-1251 будучи при этом глубоко эйджексовыми.

Для меня это совершенно приемлемо, т.к. всё же (я уже писал где-то) скорость работы с БД на однобайтовой кодировке превышает скорость работы с базой на UTF-8.
Да и xhtml страницы грузятся быстрее.

Буду рад от вас услышать, почему вы считаете, что лучше всё же везде где есть русские буквы использовать UTF-8.

aim Dec 17 2007 at 22:22

я не агитировал за что-либо. я как раз интересовался что движет людьми при выборе 1251.

mihazimin Dec 17 2007 at 22:39

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

Вот, например, здесь где-то есть комментарий, что PHP не поддерживает нативно UTF-8.

Т.е. технологии пока всё таки не дошли до его всестороннего использования, поэтому когда его можно не использовать, я его не использую.

Хотя года через 2-3, возможно, действительно все будут на нем делать.

azproduction Dec 17 2007 at 22:48

Надо делать сеичас. UTF-8 сегодня держит всё даже винда вистовская. А зачем вам поддержка найтив РНР - юзайте mb_string!
Да 2+ байта накладно, да на 20% дольше обработка. Но надо стремиться к какому-то стандарту!

UFO just landed and posted this here

mx2000 Dec 18 2007 at 14:23

XML+XSLT в PHP работают с любыми кодировками, потому что под ними лежит libxml + libxslt. Другое дело, что если работать с XML через DOM в PHP, то надо данные ручками конвертировать в UTF-8.

UFO just landed and posted this here

1mdm Dec 17 2007 at 23:10

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

mihazimin Dec 17 2007 at 23:15

Да, абсолютно с вами согласен. Wikipedia можно было сделать только на UTF-8.

Но я специально написал "русские буквы". Если вы делаете сайт на котором не предполагается многоязычности (т.е. только латиница и русский), то зачем использовать UTF-8?

o4kapuk Dec 18 2007 at 10:37

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

neithere Dec 17 2007 at 23:14

Ага... вот почему у меня на этих сайтах в Конкероре после ajax-запроса половина страницы окракозябливается.

gzigzigzi Dec 18 2007 at 01:02

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

В конце концов, время сейчас такое, когда простота приносится в жертву скорости выполнения. Так что переход к ресурсоёмким, но простым технологиям это ход в духе времени.

1mdm Dec 18 2007 at 10:57

Wikipedia маленький сайт?
Google маленький сайт?
...

-1

gzigzigzi Dec 18 2007 at 18:10

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

Я написал "Я лично". У меня таких мощностей нет, иногда приходится изголяться. И - я написал "Оставляю лазейку для перехода на UTF-8".

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

Вообще, чтоб говорить сколь-нибудь аргументированно на тему гибридный вариант vs UTF-8 нужно иметь какие-то осмысленные данные по потерям производительности на UTF-8. Понятно, что UTF работает медленно, но насколько и можно ли в каждом конкретном случае пренебрегать потерями - не ясно.

-1

mihazimin Dec 17 2007 at 21:57

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

korchasa Dec 17 2007 at 23:47

Show me the code! В смысле результаты бенчей.

azproduction Dec 18 2007 at 00:03

Проводили бенчмарки на SAP с СУБД Oracle.
Windows-1252 vs UTF-8. По скорости обработки UTF-8 отстаёт на 20%

vitamin Dec 19 2007 at 12:07

Железо дешевле, чем труд программистов! 20% - не тот прирост, из-за которого надо сделать всё через жопу. Особенно, если потом придётся переделывать.
Я поражаюсь этой логике, автор статьи предлагает, буквально, удалять гланды электродом через задний проход - авторы js библиотек оторвали кодироки, и правильно сделали - чтобы проблем было меньше.. нет, ведь найдут способ перекодировать туда-сюда, чтоб самим себе геморой создать! А потом - начинается - тут перегодировать, там в UTF отдать.. Тот же хабр - RSS отдаёт в UTF - почему? Да потому что это тру, и никакой feedburner бомжовые cp1251 и koi8 жрать не будет, и правильно делает! И так везде!
Любят же люди себе жизнь усложнять..

Over Dec 17 2007 at 21:28

ничего нового не узнал. новичкам будет полезно.

shiko_1st Dec 17 2007 at 21:33

Проблема надуманна.
Те, кому еще надо поддерживать зоопарк кодировок и так знают, что надо делать.
Все остальные давно используют utf8 и не заморачиваются.

mihazimin Dec 17 2007 at 21:53

Бр. А кто все остальные то? Назовите мне известные успешные сайты, которые используют только русский язык и при этом всё отдают в UTF-8.

kost Dec 18 2007 at 00:31

Результаты поиска на Яндексе отдаеются в utf-8.

bolk Dec 17 2007 at 21:38

А давно в JavaScript объектов нет?

mihazimin Dec 17 2007 at 21:52

В JavaScript нет классов. А объекты там ещё как есть.

MTonly Dec 17 2007 at 21:39

Мне, право, неловко, но всё же кириллические. ;-)

mihazimin Dec 17 2007 at 22:10

спасибо, исправил

denver Dec 17 2007 at 21:45

классов[дефис]то, конечно, в JavaScript нет

mihazimin Dec 17 2007 at 22:12

спасибо, исправил. А что правда так писать правильно?

denver Dec 17 2007 at 22:47

Ага :)

http://www.gramota.ru/idictation/idictat…

AlexeyK Dec 17 2007 at 22:13

Да можно, да, вполне рационально...

НО: хрен я буду использовать кириллицу, пока в том же php не будет нормальной поддержки юникода (пока она не будет native, как планируется в php6).

azproduction Dec 17 2007 at 22:37

А что вы понимаете под нормальной поддержкой?
Если уже вы передали браузеру Content-Type: text/html; charset=utf-8; то отвечать но будет вам ни чем иным как utf-8 и это дело можно с лёгкостью обработать mb_string'ом. и переконвертировать в куда угодно.

AlexeyK Dec 17 2007 at 22:46

Эм, Вы понимаете какая тут штука, mbstring - расширение, это раз.
Я недавно закончил проект, разрабатывался он полностью и везде на utf8, именно по этому поводу есть ряд замечаний. Начну с того, что проект был небольшой, но столкнулся я со следующими проблемами:

- preg_match (это не mbstring), поддерживает utf, но не полностью, и я как раз попал в этот вот кусочек "неподдерживаемости".
- само расширение не позволяет работать с регулярками, кроме как с posix-совместимыми, которые жутко как медленны.
- есть строковые функции (нативные), которые utf не поддерживают вообще, и в mbstring их, соответственно нет. (точно не скажу, но по-моему strstr/stristr).

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

Angerslave Dec 17 2007 at 23:22

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

AlexeyK Dec 17 2007 at 23:35

У меня была проблема следующего плана:
preg_replace/str_ireplace/mb_eregi_replace использовал, чтобы произвести замену "ПрИмЕрНо ВоТ тАкОгО тЕксТа" на "примерно вот такой" с тегами, все в utf, не получилось.

korchasa Dec 17 2007 at 23:53

а mb_strtolower() перестал работать?

AlexeyK Dec 18 2007 at 00:07

Не знаю, но в нем спасения не было.

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

alex93 Dec 17 2007 at 22:20

Здравствуйте ХабраЛюди! Приношу свои извинения что пишу комментарий не по теме. Но мне не обойтись без вашей помощи. Я хочу сделать свой блог. Зарегистрировался, вроде страница существует http://alex93.habrahabr.ru/ но когда нажимаю написать мне выходит окно с рассказами про карму и тд. Помогите мне.

mihazimin Dec 17 2007 at 22:27

Всё, в личном блоге можешь писать.

qprst Dec 17 2007 at 22:23

У меня всегда возникала проблема с получением данных от php скрипты, данные он возвращает в windows-1251, основной скрипт - win1251, но приходят кракозябли ;)

mihazimin Dec 17 2007 at 22:32

А вот такая штука стоит:
header('Content-type: text/html; charset=windows-1251');
?

BaBL Dec 17 2007 at 22:25

я юзаю у себя на стороне браузера escape(), а на стороне сервера накатал функцию, которая все %u1234 перегоняет обратно. В итоге не имею проблем с кодировками вообще, ибо код на латинице передается однозначно.



function uescape($str)

{

	$escape_table = array(

		'%u2116'=>'№',

		'%u0410'=>'А',

		'%u0411'=>'Б',

--------бла бла бла------------

		'%20'=>' ',

		'%21'=>'!',

		'%25'=>'%',

		'%24'=>'$',

		'%5E'=>'^',

		'%5D'=>']',

		'%0A'=>"\n"

	);

	return strtr($str, $escape_table);

}

mihazimin Dec 17 2007 at 22:30

Да, решение похоже на котеровский JsHttpRequest. Интересно кто был первый? :-)

BaBL Dec 17 2007 at 23:18

Не знаю, я у Котерова только про ПХП4 читал, самоучитель, давно... Эту штуку изобрел тоже довольно давно уже, но точных дат не скажу.

oss Dec 18 2007 at 12:22

Жестоко! Работает только с кирилицей? :-)

BaBL Dec 18 2007 at 12:47

ну я туда забил только кирилицу, так что кирилица + латиница, больше ничего и не использую, в принципе. А так, по идее можно заставить, со всем, что можешь закодировать escape();

oss Dec 18 2007 at 13:17

Не кошерно. Допустим это ввод пользователя (комментарий, как на хабре). Фраза на немецком языке с умляутами будет отваливаться. Что собственно и видно на примере хабра:
фраза "Allgemeine Information uber das Projekt" отвалится, только из-за одной буквы "u"(умляут). Вот что мы видим в итоге: "Allgemeine Information

BaBL Dec 18 2007 at 13:25

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

UFO just landed and posted this here

mivlad Dec 17 2007 at 22:41

> На все эти вопросы раз и навсегда ответит эта статья.

Спасибо, о Мудрейший :-)

> encodeURI()
> . . .
> Одобрено W3C.

http://www.google.com/search?q=encodeURI…

> Кстати, мы можем это сделать именно потому, что $_GET работает так, что он понимает escape-последовательности. Спасибо создателям PHP.

[смайлик, безнадёжно бьющий себя по лбу]
Нет, я всё понимаю, но...
[смайлик, безнадёжно бьющий себя по лбу]

> есть такие вот функции, которые переводят текст любой кодировки в UTF-8.

Не любой кодировки, а Unicode. Javascript внутри весь unicode'ный.

> в начале вашего ajax.php пропишите заголовок:
> header('Content-type: text/html; charset=windows-1251');
> И всё будет ок.

И ведь пропишут.

mihazimin Dec 17 2007 at 23:00

О ещё более мудрейший!

1. Да, лоханулся, сейчас исправлю :-)

2. Да я вообще то на php не программирую. На джабескрипт только. Так что тут поспорить не получиться серьёзно. Но всё ж, что не верно-то написано по вашему?

3. Не любой кодировки, а Unicode. Javascript внутри весь unicode'ный.

Т.е. строка в JavaScript всегда храниться в юникод представлении, однако сам скрипт (script) имеет кодировку и когда происходит вывод в DOM, то юникод преобразуется в эту кодировку?

mivlad Dec 17 2007 at 23:14

2. Да вроде всё верно, просто это преобразование — не бог весть что, чтобы за него отдельно Расмуса благодарить. Да, если уж кого и благодарить — то лично его, ибо наверняка это уже в PHP/FI было.

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

ha2bj Dec 17 2007 at 23:09

эээ юзайте utf-8 везде!

BaBL Dec 17 2007 at 23:20

это не всегда возможно.

mihazimin Dec 17 2007 at 23:23

Ваши аргументы?

BaBL Dec 18 2007 at 01:04

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

BaBL Dec 18 2007 at 01:04

ой... я думал это мне ответ был. сорри

SpirITzzz Dec 18 2007 at 00:20

большое спасибо за статью :) В принципе, нечто подобное я раньше и пытался делать, но потом подумал и понял - а почему бы просто не использовать utf-8? Ведь в нем гораздо больше плюсов, да и он все больше и больше встречается на всех ресурсах :)

PS Использую и люблю jQuery, люблю людей и зверей :), дарю, но не получаю подарки :(.

arty Dec 18 2007 at 00:31

> Используйте jQuery, любите людей, дарите подарки.

ну вот зачем было про jQuery?

я совсем не против этой библиотеки, но мне (и 70% javascript-разработчиков) больше нравится prototype.js

не дразните гусей : )

rhrn Dec 18 2007 at 03:17

производительность

arty Dec 18 2007 at 10:30

время выполнения $('#id') = 600ms вы называете высокой производительностью? : ) оно за 1ms должно отрабатывать! : )

согласен, в последней версии они это исправили, но на репутации все равно несмываемое пятно ; )

кроме того, даже в последней версии нету у jQuery однозначного превосходства

RayMan Dec 18 2007 at 14:43

600? ого, это где вы такие страшные цифры берете, даже на ранних версиях я такого не наблюдал.
А превосходство есть, и все кто перешел с прототипа на jQuery скажут сразу - размер!

arty Dec 18 2007 at 14:49

в их блоге и беру

$(”#id”) Improvements
jQuery 1.1.3 — 651ms
jQuery 1.1.4 — 70ms

размер означает отсутствие некоей функциональности. Можно вообще не использовать библиотек, и ничего не нужно будет скачивать :р

в общем, факт я предоставил, в холиворе участвовать не буду

recoilme Dec 18 2007 at 14:44

mootools: быстрее, меньше, сильнее!
Не дразните гусей)

-1

arty Dec 18 2007 at 14:50

ага, давайте ещё все остальные либы перечислим...

neyronius Dec 18 2007 at 08:32

Не знаю, как с jQuery, но при использовании prototype у меня возникли проблемы с конструкцией for(var k in ar){}, где ar-массив. В массиве появляются какие-то посторонние (прототайповские) строковые ключи. Предполагается использование только численных ключей?

arty Dec 18 2007 at 10:27

это было спорное решение в старых версиях, именно ему библиотека обязана названием, как я понимаю

сейчас с этим все хорошо

впрочем, даже известный идеолог яваскрипта Крокфорд, считает цикл for in реализованным неудачно в самом яваскрипте

sp1r1t Dec 18 2007 at 13:32

вместо for(var k in ar){} можно использовать конструкцию
ar.each(function(k){
// где k и будет элементом массива
});

mihazimin Dec 18 2007 at 14:58

Знаете почему я перешел с prototype на jQuery где-то 3 месяца назад?

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

2. Я хочу писать на JavaScript не как на C++ и Ruby, а как на JavaScript: используя все его преимущества.

arty Dec 18 2007 at 15:10

1) я работал и работаю со скриптакулосом, и никаких проблем не ощущаю. И вообще криворукость кодеров очень слабо зависит от библиотеки.

2) я пока что не буду этот пункт называть нелепым : ) Вначале объясните, что имеете в виду, а то такое обвинение в адрес прототайпа я встречаю первый раз.

mihazimin Dec 18 2007 at 15:26

Скажите вы пробовали писать на jQuery или только читали и вам сразу не понравилось?

1) "криворукость кодеров" надо воспринимать просто как составляющую контекста работы. Люди не идеальны. В jQuery стандартизировано не только написание плагинов, но и документации к ним.

2) Вы наверняка знаете, что prototype.js сейчас, - уже практически часть ROR. А все конструкции, - Hash, добавки к Array и т.д. - это напрямую взяты из Core Ruby, как кстати и слово initialize.
Да, это всё круто, когда на сервере лежит Ruby, убыстряет разработку. (Правда).

Я совсем не против Ruby, но если на backendе лежит php, то я не вижу объективных причин его использовать.

arty Dec 18 2007 at 15:46

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

1) html тоже стандартизован, и это не сильно помогает ; ) А приобретая в качестве, всегда теряешь в количестве. Можете не возражать, я в этом уверен :р

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

у меня на бэкэнде именно php, и я с большим удовольствием использую прототайп

rhrn Dec 18 2007 at 18:07

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

arty Dec 18 2007 at 18:16

я не доказываю свою правоту, а реагирую на попытки доказать, что jQuery однозначно лучше Prototype.js. И делаю это не с пеной у рта, а спокойно и цивилизованно.

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

при чем тут карма, я не понял

NonErr Dec 22 2007 at 13:36

Пробовали разные. А работаем с jQuery. Очень довольны. =)

Irokez Dec 18 2007 at 03:09

На сегодняшний день джаваскриптом через объект класса XMLHttpRequest можно отправить не только запросы типа GET и POST, но и PUT, DELETE, HEAD.

mihazimin Dec 18 2007 at 14:52

В каких браузерах возможно отправить XMLHttpRequest типа PUT, DELETE и HEAD?

Irokez Dec 18 2007 at 14:55

ff, ie, opera, safari (win)
проверял в последних версиях (ff - 2.x >, ie - 6.x >, opera 9.x >, safari - не помню какая под вин последняя, уверен, что на маках тоже работает и в более ранних версиях указанных браузерах тоже)
По сути, способ передачи данных у методов не очень отличаются от GET и POST

mihazimin Dec 18 2007 at 15:13

Хм, действительно работает. Спасибо, сейчас внесу изменения в статью. Я вот не проверил, а поверил документации и коду prototype.js:

if (!['get', 'post'].include(this.method)) {
// simulate other verbs over post
params['_method'] = this.method;
this.method = 'post';
}

причем поменять это поведение никакими параметрами поменять невозможно.

gro Dec 18 2007 at 14:56

Лучше вопрос, а какие серверы их обрабатывают? :)

Irokez Dec 18 2007 at 15:20

любые. через PHP можно отловить все запросы.
http://alexpak.name/ru/news/?id=167

recoilme Dec 18 2007 at 12:29

Ну вот. Недавно столкнулся с похожей проблемой. Сойт в вин 1251. Решил её совершенно НЕ так как описывает автор. БОЛЕЕ ТОГО. Никакого ICONV НЕ ИСПОЛЬЗУЮ.
Может быть кто то объяснит как мне это удалось? Я тупо подобрал) Итак:
Дано сайт в кодировке 1251. Задача - встроить гугл мэпс.
Решение:
Параметры карты передаю в БД тупо:
urlparams = "?mode="+"save"+"&name=" + name + "&hello=" + hello + "&sex=" + sex + "&lat=" + lat + "&lng=" + lng + "&baseurl=" + baseurl + "&currurl=" + currurl;
urlinsert = baseurl+"/user/maps_insert.php"+urlparams;
new Ajax(urlinsert, {method: "post"}).request(); (мутулз)

В БД "крякозяблики", при отображении использую функцию UNESCAPE:
for (var i = 0; i < markers.length; i++) {
var name = unescape(markers[i].getAttribute("name"));
Никакого iconv, всё работает (www.msexy.ru). Что я сделал не так??

gro Dec 18 2007 at 12:42

Вы не обрабатываете данные. Вы их получаете, тупо, как вы выражаетесь, передаете в БД и так же тупо выдаете. Поэтому фраза про "Сойт в вин 1251" к делу не относится, он может быть хоть в DOS.

recoilme Dec 18 2007 at 13:20

Сойт=Сайт. Насчет не обрабатываю - не совсем понял. Была проблема - русские буквы из БД выводились кракозябликами) Использование функции unescape - решило проблему кракозябликов. iconv не понадобился (у меня его нет на хостинге). Вот собственно и всё. Просто вроде как в статье утверждается что без iconv не обойтись..
Извините - раз в 5 минут коммент, поэтому тут про атаки спрошу.
Если тупо искать строки select\insert\delete в параметрах и отбрасывать параметры если они там вдруг появились - это будет достаточный уровень защищенности?

gro Dec 18 2007 at 13:48

Вы на стороне сервера какой-нибудь обработкой строковых данных занимаетесь?

\"Кавычки \". Cоставление запросов, слеши, SQL Injection

recoilme Dec 18 2007 at 14:25

1.Нет, данные тупо инсертятся. На то они и данные) Вся обработка(парсинг) в js. Видимо из-за этого и нет проблем с кодировками.
2. Спасибо за ссылку. Теперь более понятно с инъекциями. Честно говоря мне в горячем бреду бы не привиделось допустить ошибки, обработка которых описана в статье)
В Двух словах - статья о том, как сделать всё через жопу(уж как есть говорю), а потом с этим бороться. Проще сразу нормально делать) + спасибо гугл за примеры хорошего кодинга. Тупо передирал у них всякие mysql_real_escape_string и как оказалось не зря)

mihazimin Dec 18 2007 at 14:50

Т.е. вы хотите сказать, что на habrahabr.ru, moikrug.ru, vkontakte.ru и market.yandex.ru всё сделано через жопу ;-) ?

recoilme Dec 18 2007 at 17:44

К сожалению не знаю как сделано на перечисленных сайтах. Приведите пожалуйста пример кусочка исходников с одного из этих сайтов раз уж Вы знаете как они сделаны. Ну или какое то доказательство. Тогда и сможем оценить)
Сильно сомневаюсь что они настолько пренебрегли архитектурой БД, что были вынуждены прибегнуть к динамически формируемым SQL запросам.

mihazimin Dec 18 2007 at 17:49

Прошу прощения. Только теперь понял что вы о "Cоставление запросов, слеши, SQL Injection", а не о основной статье (http://habrahabr.ru/blog/webdev/32618.ht…).

Нет, по то как организована в перечисленных сайтах работа с БД не имею понятия. Я имел в виду JavaScript, xhtml, etc.

recoilme Dec 18 2007 at 22:32

нема зашо)

FanatPHP Jan 12 2008 at 17:24

А можно спросить, где там написано как все сделать через жопу?

BaBL Dec 18 2007 at 12:50

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

mx2000 Dec 18 2007 at 14:30

А заметьте, что 90% комментариев подразумевают использование PHP на стороне сервера. Это при том, что в соседних топиках идет флуд aka PHP suxx. Однако, парадокс..

По теме: все в курсе про баг в IE на тему UTF-8 кодировки при AJAX-запросе? Или дополнить этот пробел в комменте?

mihazimin Dec 18 2007 at 14:50

Дополните пожалуйста: что вы имеете ввиду

mx2000 Dec 18 2007 at 15:28

В ситуации, когда страница отдана в браузер в UTF-8, и по действию пользователя с нее делается AJAX-запрос методом GET, в какой кодировке браузер должен отправлять данные?

mihazimin Dec 18 2007 at 15:57

Не совсем понял. Если запрос типа GET, то передаватся данные будут только через URL.
Так в чём суть бага-то?

maetchkin Dec 18 2007 at 15:30

непременно дополнить.

linche Dec 18 2007 at 23:06

еще бы оттипографить по человечески статью и будет отличное пособие

Mourner Dec 19 2007 at 17:47

Спасибо за статью!

Одно замечание - Ajax давно уже превратился из акронима (AJAX) просто в название, т.к. XMLHttpRequest используется не только в сочетании с XML.

RaSta Dec 19 2007 at 20:52

если нужно юзать cp1251 использую такой вариант:

JavaScript-аналог функций PHP urlencode и urldecode для cp1251

var trans=[];
var snart=[];
for(var i=0x410;i<=0x44F;i++)
{
trans[i]=i-0x350;
snart[i-0x350] = i;
}
trans[0x401]= 0xA8;
trans[0x451]= 0xB8;
snart[0xA8] = 0x401;
snart[0xB8] = 0x451;
window.urlencode = function(str)
{
var ret=[];
for(var i=0;i<str.length;i++)
{
var n=str.charCodeAt(i);
if(typeof trans[n]!='undefined')
n = trans[n];
if (n <= 0xFF)
ret.push(n);
}

return window.escape(String.fromCharCode.apply(null,ret));
}
window.urldecode = function(str)
{
var ret=[];
str = unescape(str);
for(var i=0;i<str.length;i++)
{
var n=str.charCodeAt(i);
if(typeof snart[n]!='undefined')
n = snart[n];
ret.push(n);
}

return String.fromCharCode.apply(null,ret);
}
</code>

таким образом у клиента
str = window.urlencode("строка в cp1251")
а на сервере
$str = urldecode($_REQUEST['str']);

спасибо <a href='http://forum.vingrad.ru/act-ST/f-176/t-154562.html' >Aco</a>

diamant Dec 23 2007 at 23:54

фтопку олдскульные кодировки типа 1251, koi8 etc.

Isis Apr 17 2008 at 02:02

К чему статья, можно было написать 1 стрoкой iconv =\

dimianstudio May 16 2008 at 21:01

большое спасибо!!!!!!!

pumi May 18 2008 at 13:16

Поиски привели меня на эту замечательную подборку:
http://zhilinsky.ru/2007/08/10/php-unicode/

sunsey Aug 18 2009 at 19:50

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

seriyPS Nov 10 2009 at 04:06

Ой спасибоо)))
Вот напоролся очень жестко с тем, что на страничках windows-1251 аяксом передавался UTF-8
И удивлялись: а что-й то у нас как-то криво работает… Эхх… век живи — век учись.

Methos Jul 25 2010 at 21:51

Для koi8-r создал раскладку:

var trans_Koi8r = {«9472»:128,«9474»:129,«9484»:130,«9488»:131,«9492»:132,«9496»:133,«9500»:134,«9508»:135,«9516»:136,«9524»:137,«9532»:138,«9600»:139,«9604»:140,«9608»:141,«9612»:142,«9616»:143,«9617»:144,«9618»:145,«9619»:146,«8992»:147,«9632»:148,«8729»:149,«8730»:150,«8776»:151,«8804»:152,«8805»:153,«160»:154,«8993»:155,«176»:156,«178»:157,«183»:158,«247»:159,«9552»:160,«9553»:161,«9554»:162,«1105»:163,«9555»:164,«9556»:165,«9557»:166,«9558»:167,«9559»:168,«9560»:169,«9561»:170,«9562»:171,«9563»:172,«9564»:173,«9565»:174,«9566»:175,«9567»:176,«9568»:177,«9569»:178,«1025»:179,«9570»:180,«9571»:181,«9572»:182,«9573»:183,«9574»:184,«9575»:185,«9576»:186,«9577»:187,«9578»:188,«9579»:189,«9580»:190,«169»:191,«1102»:192,«1072»:193,«1073»:194,«1094»:195,«1076»:196,«1077»:197,«1092»:198,«1075»:199,«1093»:200,«1080»:201,«1081»:202,«1082»:203,«1083»:204,«1084»:205,«1085»:206,«1086»:207,«1087»:208,«1103»:209,«1088»:210,«1089»:211,«1090»:212,«1091»:213,«1078»:214,«1074»:215,«1100»:216,«1099»:217,«1079»:218,«1096»:219,«1101»:220,«1097»:221,«1095»:222,«1098»:223,«1070»:224,«1040»:225,«1041»:226,«1062»:227,«1044»:228,«1045»:229,«1060»:230,«1043»:231,«1061»:232,«1048»:233,«1049»:234,«1050»:235,«1051»:236,«1052»:237,«1053»:238,«1054»:239,«1055»:240,«1071»:241,«1056»:242,«1057»:243,«1058»:244,«1059»:245,«1046»:246,«1042»:247,«1068»:248,«1067»:249,«1047»:250,«1064»:251,«1069»:252,«1065»:253,«1063»:254,«1066»:255};

window.urlencode_koi8r = function(str)
{
var ret=[];
for(var i=0;i<str.length;i++)
{
var n=str.charCodeAt(i);
if(typeof trans_Koi8r[n]!='undefined')
n = trans_Koi8r[n];
if (n <= 0xFF)
ret.push(n);
}

return window.escape(String.fromCharCode.apply(null,ret));
}

jkeks Sep 10 2011 at 07:50

Кстати, если вы замучались и не понимаете почему UTF8 страница показывается каракулями, хотя meta прописана, то я просто добавлю, посмотрите в htaccess, скорее всего там одна строчка есть такая:
AddDefaultCharset windows-1251

Show the best of all time