Комментарии 125
Про habracut - забыли?
День JS на хабре? :)
Не сказать, чтобы она ответила на все вопросы.
Как из недр JS можно передать не unicode-кодировку?
Но еще более приемлима схема, когда везде UTF :) Тогда и iconv никакой не нужен и в других областях (не ajax) проблем меньше.
На все эти вопросы раз и навсегда ответит эта статья.
Не сказать, чтобы она ответила на все вопросы.
2. Можно передавать строки как бы "в любых других кодировках", если нелатинские символы
при этом за-escape-ены.
Как из недр JS можно передать не unicode-кодировку?
Схема при которой все xhtml страницы работают на windows-1251, ajax с сервера клиенту кидает windows-1251, а ajax с клиента серверу кидает UTF-8 абсолютна приемлема и используется на большинстве ресурсов.
Но еще более приемлима схема, когда везде UTF :) Тогда и iconv никакой не нужен и в других областях (не ajax) проблем меньше.
Кодировки вроде windows-1251 архаизм.
Зачем каждый раз iconv дёргать, зачем эти трансляции?
UTF-8 наше всё. И если идти в ногу со временем, эта статья бы не появилась.
Зачем каждый раз iconv дёргать, зачем эти трансляции?
UTF-8 наше всё. И если идти в ногу со временем, эта статья бы не появилась.
Ребята, этот топик как раз о том как делает большинство профессиональных разработчиков в России сейчас.
Столкнувшись с тем, что, по большому счету, AJAX запрос всегда отправляет UTF-8 молодые разработчики приходят к мнению о том, что нужно и страницы непременно отправлять в нём. Что, в принципе, не является панацеей. И не всегда оптимально сказывается на производительности.
Зачем всё делать на UTF-8 когда страницы содержат только русские и латинские буквы? Сортировки в UTF-8 могут проходить в несколько раз медленнее, количество контента загруженного на страницы увеличивается в 2 раза.
И почему habrahabr.ru и др. не используют UTF-8 как основную кодировку, при этом во всю отправляя AJAX запросы в ней?
Ответ прост: это удобно и эффективно.
Столкнувшись с тем, что, по большому счету, AJAX запрос всегда отправляет UTF-8 молодые разработчики приходят к мнению о том, что нужно и страницы непременно отправлять в нём. Что, в принципе, не является панацеей. И не всегда оптимально сказывается на производительности.
Зачем всё делать на UTF-8 когда страницы содержат только русские и латинские буквы? Сортировки в UTF-8 могут проходить в несколько раз медленнее, количество контента загруженного на страницы увеличивается в 2 раза.
И почему habrahabr.ru и др. не используют UTF-8 как основную кодировку, при этом во всю отправляя AJAX запросы в ней?
Ответ прост: это удобно и эффективно.
Зачем всё делать на UTF-8 когда страницы содержат только русские и латинские буквы?
А почему бы и не в UTF?
Сортировки в UTF-8 могут проходить в несколько раз медленнее
Какие сортировки? В базе? Так все нормальные базы внутри в UTF. Если же вы работаете не в UTF, то это означает только, что на входе и выходе базы будет происходить перекодировка, что будет есть ресурсы, за которые вы так волнуетесь. Добавьте сюда бесконечные SET NAMES при запросах и множество тем на форумах: "Ах, почему у меня сплошные вопросики выводятся".
количество контента загруженного на страницы увеличивается в 2 раза
Количество контента будет = верстка + английский контент + русский * 2
По сравнению с общим объемом, включая картинки, прибавка для современных сетей ничтожна. Используйте gzip-сжатие и вообще будет стремится к нулю
а можно идиоту пояснить зачем использовать 1251 страницу (Или любую другую не utf-8) если всё остальное идёт в utf-8?!!!!!!
Видимо потому что все привыкли к 1251, всё работает и сверстано в 1251 (еще в конце 90х), а теперь бедному программисту приказали быстро навешать на всё это модных фенечек :)
что-то я не видел таких проектов. чтобы аякс и свёрстано в конце 90х... да ещё и в 1251...
Сейчас вы находитесь на сайте, который отдаёт страницы отнюдь не в UTF-8, при этом вполне сносно AJAX-запросы отправляет, естественно, в UTF-8.
я знаю. просто вы привели аргумент что де в конце 90х наделали супер-дизайнов. что теперь их переделывать нельзя, а можно лишь добавить ajax-перделок. как-то мне сразу в это не поверилось.
что касается хабры я так и не могу понять для чего это сделано.
что касается хабры я так и не могу понять для чего это сделано.
не, это не я привел. Это стебался кто-то.
Ну vkontakte.ru, moikrug.ru, market.yandex.ru всё таки тоже работают на windows-1251 будучи при этом глубоко эйджексовыми.
Для меня это совершенно приемлемо, т.к. всё же (я уже писал где-то) скорость работы с БД на однобайтовой кодировке превышает скорость работы с базой на UTF-8.
Да и xhtml страницы грузятся быстрее.
Буду рад от вас услышать, почему вы считаете, что лучше всё же везде где есть русские буквы использовать UTF-8.
Для меня это совершенно приемлемо, т.к. всё же (я уже писал где-то) скорость работы с БД на однобайтовой кодировке превышает скорость работы с базой на UTF-8.
Да и xhtml страницы грузятся быстрее.
Буду рад от вас услышать, почему вы считаете, что лучше всё же везде где есть русские буквы использовать UTF-8.
я не агитировал за что-либо. я как раз интересовался что движет людьми при выборе 1251.
А, понятно. На самом деле пробовал я один раз на UTF-8 поднять сайт (потому что как раз решил заюзать там AJAX), но оказалось, что не так всё с этим UTF-8 гладко как хотелось бы. Вообще почему то в реальных разработках серверные программисты на нем не любят работать.
Вот, например, здесь где-то есть комментарий, что PHP не поддерживает нативно UTF-8.
Т.е. технологии пока всё таки не дошли до его всестороннего использования, поэтому когда его можно не использовать, я его не использую.
Хотя года через 2-3, возможно, действительно все будут на нем делать.
Вот, например, здесь где-то есть комментарий, что PHP не поддерживает нативно UTF-8.
Т.е. технологии пока всё таки не дошли до его всестороннего использования, поэтому когда его можно не использовать, я его не использую.
Хотя года через 2-3, возможно, действительно все будут на нем делать.
Надо делать сеичас. UTF-8 сегодня держит всё даже винда вистовская. А зачем вам поддержка найтив РНР - юзайте mb_string!
Да 2+ байта накладно, да на 20% дольше обработка. Но надо стремиться к какому-то стандарту!
Да 2+ байта накладно, да на 20% дольше обработка. Но надо стремиться к какому-то стандарту!
Не везде, где есть русские буквы, а везде, где есть мультиязычность.
Unicode является универсальной кодировкой. Он позволяет на одной странице общаться китайцу и русскому. И немец еще будет комментарии на родном языке оставлять (они же все друг друга понимают, да?)
Unicode является универсальной кодировкой. Он позволяет на одной странице общаться китайцу и русскому. И немец еще будет комментарии на родном языке оставлять (они же все друг друга понимают, да?)
Да, абсолютно с вами согласен. Wikipedia можно было сделать только на UTF-8.
Но я специально написал "русские буквы". Если вы делаете сайт на котором не предполагается многоязычности (т.е. только латиница и русский), то зачем использовать UTF-8?
Но я специально написал "русские буквы". Если вы делаете сайт на котором не предполагается многоязычности (т.е. только латиница и русский), то зачем использовать UTF-8?
Ага... вот почему у меня на этих сайтах в Конкероре после ajax-запроса половина страницы окракозябливается.
Аргумент один: отсутствие необходимости следить за кодировкой. Там где критична скорость выполнения - то есть на сайтах с большой посещаемостью - лучше использовать гибридный вариант. На маленьких я лично использую UTF-8 и на клиенте и на сервере, но оставляю лазейку чтоб в случае чего без проблем мигрировать на этот самый гибридный вариант.
В конце концов, время сейчас такое, когда простота приносится в жертву скорости выполнения. Так что переход к ресурсоёмким, но простым технологиям это ход в духе времени.
В конце концов, время сейчас такое, когда простота приносится в жертву скорости выполнения. Так что переход к ресурсоёмким, но простым технологиям это ход в духе времени.
Wikipedia маленький сайт?
Google маленький сайт?
...
Google маленький сайт?
...
Нихрена не понял, что Вы хотели сказать. Если они используют UTF-8 - здорово, это шаг к упрощению, тем более, если учесть, что они могут позволить себе наращивать мощности серверов до бесконечности.
Я написал "Я лично". У меня таких мощностей нет, иногда приходится изголяться. И - я написал "Оставляю лазейку для перехода на UTF-8".
Кроме того, я не очень представляю как гугл обошёлся бы искомой 1251 на клиенте, если учесть всё многообразие его многоязычных версий.
Вообще, чтоб говорить сколь-нибудь аргументированно на тему гибридный вариант vs UTF-8 нужно иметь какие-то осмысленные данные по потерям производительности на UTF-8. Понятно, что UTF работает медленно, но насколько и можно ли в каждом конкретном случае пренебрегать потерями - не ясно.
Я написал "Я лично". У меня таких мощностей нет, иногда приходится изголяться. И - я написал "Оставляю лазейку для перехода на UTF-8".
Кроме того, я не очень представляю как гугл обошёлся бы искомой 1251 на клиенте, если учесть всё многообразие его многоязычных версий.
Вообще, чтоб говорить сколь-нибудь аргументированно на тему гибридный вариант vs UTF-8 нужно иметь какие-то осмысленные данные по потерям производительности на UTF-8. Понятно, что UTF работает медленно, но насколько и можно ли в каждом конкретном случае пренебрегать потерями - не ясно.
Потому что иногда 1 байт лучше UTF-8. Обработка текстов, например, в 1-байтовых кодировках проходит в разы быстрее.
Show me the code! В смысле результаты бенчей.
Проводили бенчмарки на SAP с СУБД Oracle.
Windows-1252 vs UTF-8. По скорости обработки UTF-8 отстаёт на 20%
Windows-1252 vs UTF-8. По скорости обработки UTF-8 отстаёт на 20%
Железо дешевле, чем труд программистов! 20% - не тот прирост, из-за которого надо сделать всё через жопу. Особенно, если потом придётся переделывать.
Я поражаюсь этой логике, автор статьи предлагает, буквально, удалять гланды электродом через задний проход - авторы js библиотек оторвали кодироки, и правильно сделали - чтобы проблем было меньше.. нет, ведь найдут способ перекодировать туда-сюда, чтоб самим себе геморой создать! А потом - начинается - тут перегодировать, там в UTF отдать.. Тот же хабр - RSS отдаёт в UTF - почему? Да потому что это тру, и никакой feedburner бомжовые cp1251 и koi8 жрать не будет, и правильно делает! И так везде!
Любят же люди себе жизнь усложнять..
Я поражаюсь этой логике, автор статьи предлагает, буквально, удалять гланды электродом через задний проход - авторы js библиотек оторвали кодироки, и правильно сделали - чтобы проблем было меньше.. нет, ведь найдут способ перекодировать туда-сюда, чтоб самим себе геморой создать! А потом - начинается - тут перегодировать, там в UTF отдать.. Тот же хабр - RSS отдаёт в UTF - почему? Да потому что это тру, и никакой feedburner бомжовые cp1251 и koi8 жрать не будет, и правильно делает! И так везде!
Любят же люди себе жизнь усложнять..
ничего нового не узнал. новичкам будет полезно.
Проблема надуманна.
Те, кому еще надо поддерживать зоопарк кодировок и так знают, что надо делать.
Все остальные давно используют utf8 и не заморачиваются.
Те, кому еще надо поддерживать зоопарк кодировок и так знают, что надо делать.
Все остальные давно используют utf8 и не заморачиваются.
А давно в JavaScript объектов нет?
Мне, право, неловко, но всё же кириллические. ;-)
классов[дефис]то, конечно, в JavaScript нет
Да можно, да, вполне рационально...
НО: хрен я буду использовать кириллицу, пока в том же php не будет нормальной поддержки юникода (пока она не будет native, как планируется в php6).
НО: хрен я буду использовать кириллицу, пока в том же php не будет нормальной поддержки юникода (пока она не будет native, как планируется в php6).
А что вы понимаете под нормальной поддержкой?
Если уже вы передали браузеру Content-Type: text/html; charset=utf-8; то отвечать но будет вам ни чем иным как utf-8 и это дело можно с лёгкостью обработать mb_string'ом. и переконвертировать в куда угодно.
Если уже вы передали браузеру Content-Type: text/html; charset=utf-8; то отвечать но будет вам ни чем иным как utf-8 и это дело можно с лёгкостью обработать mb_string'ом. и переконвертировать в куда угодно.
Эм, Вы понимаете какая тут штука, mbstring - расширение, это раз.
Я недавно закончил проект, разрабатывался он полностью и везде на utf8, именно по этому поводу есть ряд замечаний. Начну с того, что проект был небольшой, но столкнулся я со следующими проблемами:
- preg_match (это не mbstring), поддерживает utf, но не полностью, и я как раз попал в этот вот кусочек "неподдерживаемости".
- само расширение не позволяет работать с регулярками, кроме как с posix-совместимыми, которые жутко как медленны.
- есть строковые функции (нативные), которые utf не поддерживают вообще, и в mbstring их, соответственно нет. (точно не скажу, но по-моему strstr/stristr).
Нормальная поддержка - дефолтный utf8 для всего, что делается на этом языке + нехилое расширение для работы со всеми возможными кодировками (не какая-то перезагрузка в существующем расширении, а что-то более удобное).
Я недавно закончил проект, разрабатывался он полностью и везде на utf8, именно по этому поводу есть ряд замечаний. Начну с того, что проект был небольшой, но столкнулся я со следующими проблемами:
- preg_match (это не mbstring), поддерживает utf, но не полностью, и я как раз попал в этот вот кусочек "неподдерживаемости".
- само расширение не позволяет работать с регулярками, кроме как с posix-совместимыми, которые жутко как медленны.
- есть строковые функции (нативные), которые utf не поддерживают вообще, и в mbstring их, соответственно нет. (точно не скажу, но по-моему strstr/stristr).
Нормальная поддержка - дефолтный utf8 для всего, что делается на этом языке + нехилое расширение для работы со всеми возможными кодировками (не какая-то перезагрузка в существующем расширении, а что-то более удобное).
Насколько я знаю, если текст в UTF-8 и паттерн тоже в UTF-8, то достаточно добавить модификатор u и всё будет нормально работать.
Здравствуйте ХабраЛюди! Приношу свои извинения что пишу комментарий не по теме. Но мне не обойтись без вашей помощи. Я хочу сделать свой блог. Зарегистрировался, вроде страница существует http://alex93.habrahabr.ru/ но когда нажимаю написать мне выходит окно с рассказами про карму и тд. Помогите мне.
У меня всегда возникала проблема с получением данных от php скрипты, данные он возвращает в windows-1251, основной скрипт - win1251, но приходят кракозябли ;)
я юзаю у себя на стороне браузера escape(), а на стороне сервера накатал функцию, которая все %u1234 перегоняет обратно. В итоге не имею проблем с кодировками вообще, ибо код на латинице передается однозначно.
function uescape($str)
{
$escape_table = array(
'%u2116'=>'№',
'%u0410'=>'А',
'%u0411'=>'Б',
--------бла бла бла------------
'%20'=>' ',
'%21'=>'!',
'%25'=>'%',
'%24'=>'$',
'%5E'=>'^',
'%5D'=>']',
'%0A'=>"\n"
);
return strtr($str, $escape_table);
}
Да, решение похоже на котеровский JsHttpRequest. Интересно кто был первый? :-)
Жестоко! Работает только с кирилицей? :-)
ну я туда забил только кирилицу, так что кирилица + латиница, больше ничего и не использую, в принципе. А так, по идее можно заставить, со всем, что можешь закодировать escape();
Не кошерно. Допустим это ввод пользователя (комментарий, как на хабре). Фраза на немецком языке с умляутами будет отваливаться. Что собственно и видно на примере хабра:
фраза "Allgemeine Information uber das Projekt" отвалится, только из-за одной буквы "u"(умляут). Вот что мы видим в итоге: "Allgemeine Information
фраза "Allgemeine Information uber das Projekt" отвалится, только из-за одной буквы "u"(умляут). Вот что мы видим в итоге: "Allgemeine Information
> На все эти вопросы раз и навсегда ответит эта статья.
Спасибо, о Мудрейший :-)
> 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');
> И всё будет ок.
И ведь пропишут.
Спасибо, о Мудрейший :-)
> 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');
> И всё будет ок.
И ведь пропишут.
О ещё более мудрейший!
1. Да, лоханулся, сейчас исправлю :-)
2. Да я вообще то на php не программирую. На джабескрипт только. Так что тут поспорить не получиться серьёзно. Но всё ж, что не верно-то написано по вашему?
3. Не любой кодировки, а Unicode. Javascript внутри весь unicode'ный.
Т.е. строка в JavaScript всегда храниться в юникод представлении, однако сам скрипт (script) имеет кодировку и когда происходит вывод в DOM, то юникод преобразуется в эту кодировку?
1. Да, лоханулся, сейчас исправлю :-)
2. Да я вообще то на php не программирую. На джабескрипт только. Так что тут поспорить не получиться серьёзно. Но всё ж, что не верно-то написано по вашему?
3. Не любой кодировки, а Unicode. Javascript внутри весь unicode'ный.
Т.е. строка в JavaScript всегда храниться в юникод представлении, однако сам скрипт (script) имеет кодировку и когда происходит вывод в DOM, то юникод преобразуется в эту кодировку?
2. Да вроде всё верно, просто это преобразование — не бог весть что, чтобы за него отдельно Расмуса благодарить. Да, если уж кого и благодарить — то лично его, ибо наверняка это уже в PHP/FI было.
3. Не знаю, как именно она хранится (может, это от браузера даже зависит), но с точки зрения языка — все строки в Юникоде. И, если в момент загрузки скрипта браузер верно знает его кодировку, то я даже не уверен, что эту кодировку потом в скрипте можно узнать достоверно. Оставаясь в рамках стандартов, по крайней мере.
3. Не знаю, как именно она хранится (может, это от браузера даже зависит), но с точки зрения языка — все строки в Юникоде. И, если в момент загрузки скрипта браузер верно знает его кодировку, то я даже не уверен, что эту кодировку потом в скрипте можно узнать достоверно. Оставаясь в рамках стандартов, по крайней мере.
эээ юзайте utf-8 везде!
это не всегда возможно.
Ваши аргументы?
к примеру если база данных завязана на cp1251, какая-нить от 1С или еще чего-нибудь, тогда получается будет целый зоопарк, возможно даже iconv придется применять, но iconv я выходом не назвал бы, могут быть проблемы при переносе на другую площадку. Не все сайты - домашние странички ученицы 7б класса Маши Соколовой.
большое спасибо за статью :) В принципе, нечто подобное я раньше и пытался делать, но потом подумал и понял - а почему бы просто не использовать utf-8? Ведь в нем гораздо больше плюсов, да и он все больше и больше встречается на всех ресурсах :)
PS Использую и люблю jQuery, люблю людей и зверей :), дарю, но не получаю подарки :(.
PS Использую и люблю jQuery, люблю людей и зверей :), дарю, но не получаю подарки :(.
> Используйте jQuery, любите людей, дарите подарки.
ну вот зачем было про jQuery?
я совсем не против этой библиотеки, но мне (и 70% javascript-разработчиков) больше нравится prototype.js
не дразните гусей : )
ну вот зачем было про jQuery?
я совсем не против этой библиотеки, но мне (и 70% javascript-разработчиков) больше нравится prototype.js
не дразните гусей : )
производительность
время выполнения $('#id') = 600ms вы называете высокой производительностью? : ) оно за 1ms должно отрабатывать! : )
согласен, в последней версии они это исправили, но на репутации все равно несмываемое пятно ; )
кроме того, даже в последней версии нету у jQuery однозначного превосходства
согласен, в последней версии они это исправили, но на репутации все равно несмываемое пятно ; )
кроме того, даже в последней версии нету у jQuery однозначного превосходства
600? ого, это где вы такие страшные цифры берете, даже на ранних версиях я такого не наблюдал.
А превосходство есть, и все кто перешел с прототипа на jQuery скажут сразу - размер!
А превосходство есть, и все кто перешел с прототипа на jQuery скажут сразу - размер!
в их блоге и беру
$(”#id”) Improvements
jQuery 1.1.3 — 651ms
jQuery 1.1.4 — 70ms
размер означает отсутствие некоей функциональности. Можно вообще не использовать библиотек, и ничего не нужно будет скачивать :р
в общем, факт я предоставил, в холиворе участвовать не буду
$(”#id”) Improvements
jQuery 1.1.3 — 651ms
jQuery 1.1.4 — 70ms
размер означает отсутствие некоей функциональности. Можно вообще не использовать библиотек, и ничего не нужно будет скачивать :р
в общем, факт я предоставил, в холиворе участвовать не буду
mootools: быстрее, меньше, сильнее!
Не дразните гусей)
Не дразните гусей)
Не знаю, как с jQuery, но при использовании prototype у меня возникли проблемы с конструкцией for(var k in ar){}, где ar-массив. В массиве появляются какие-то посторонние (прототайповские) строковые ключи. Предполагается использование только численных ключей?
это было спорное решение в старых версиях, именно ему библиотека обязана названием, как я понимаю
сейчас с этим все хорошо
впрочем, даже известный идеолог яваскрипта Крокфорд, считает цикл for in реализованным неудачно в самом яваскрипте
сейчас с этим все хорошо
впрочем, даже известный идеолог яваскрипта Крокфорд, считает цикл for in реализованным неудачно в самом яваскрипте
вместо for(var k in ar){} можно использовать конструкцию
ar.each(function(k){
// где k и будет элементом массива
});
ar.each(function(k){
// где k и будет элементом массива
});
Знаете почему я перешел с prototype на jQuery где-то 3 месяца назад?
1. Потому написание плагинов к нему стандартизированно. Если вы когда-нибудь работали со script.aculo.us, то знаете как сложно исправить код в чужом плагине и то, что все пишут плагины с какими в голову придет интерфейсами.
2. Я хочу писать на JavaScript не как на C++ и Ruby, а как на JavaScript: используя все его преимущества.
1. Потому написание плагинов к нему стандартизированно. Если вы когда-нибудь работали со script.aculo.us, то знаете как сложно исправить код в чужом плагине и то, что все пишут плагины с какими в голову придет интерфейсами.
2. Я хочу писать на JavaScript не как на C++ и Ruby, а как на JavaScript: используя все его преимущества.
1) я работал и работаю со скриптакулосом, и никаких проблем не ощущаю. И вообще криворукость кодеров очень слабо зависит от библиотеки.
2) я пока что не буду этот пункт называть нелепым : ) Вначале объясните, что имеете в виду, а то такое обвинение в адрес прототайпа я встречаю первый раз.
2) я пока что не буду этот пункт называть нелепым : ) Вначале объясните, что имеете в виду, а то такое обвинение в адрес прототайпа я встречаю первый раз.
Скажите вы пробовали писать на jQuery или только читали и вам сразу не понравилось?
1) "криворукость кодеров" надо воспринимать просто как составляющую контекста работы. Люди не идеальны. В jQuery стандартизировано не только написание плагинов, но и документации к ним.
2) Вы наверняка знаете, что prototype.js сейчас, - уже практически часть ROR. А все конструкции, - Hash, добавки к Array и т.д. - это напрямую взяты из Core Ruby, как кстати и слово initialize.
Да, это всё круто, когда на сервере лежит Ruby, убыстряет разработку. (Правда).
Я совсем не против Ruby, но если на backendе лежит php, то я не вижу объективных причин его использовать.
1) "криворукость кодеров" надо воспринимать просто как составляющую контекста работы. Люди не идеальны. В jQuery стандартизировано не только написание плагинов, но и документации к ним.
2) Вы наверняка знаете, что prototype.js сейчас, - уже практически часть ROR. А все конструкции, - Hash, добавки к Array и т.д. - это напрямую взяты из Core Ruby, как кстати и слово initialize.
Да, это всё круто, когда на сервере лежит Ruby, убыстряет разработку. (Правда).
Я совсем не против Ruby, но если на backendе лежит php, то я не вижу объективных причин его использовать.
я видел примеры ее использования, и мне они не понравились. Я не хочу писать такой код.
1) html тоже стандартизован, и это не сильно помогает ; ) А приобретая в качестве, всегда теряешь в количестве. Можете не возражать, я в этом уверен :р
2) ощутимая часть этих конструкций мне хорошо пригождается в самом яваскрипте, поэтому мне все равно, откуда они взяты. И вы не сказали про преимущества js, с которых и началось это обсуждение. Каким образом прототайп не позволяет вам их использовать?
у меня на бэкэнде именно php, и я с большим удовольствием использую прототайп
1) html тоже стандартизован, и это не сильно помогает ; ) А приобретая в качестве, всегда теряешь в количестве. Можете не возражать, я в этом уверен :р
2) ощутимая часть этих конструкций мне хорошо пригождается в самом яваскрипте, поэтому мне все равно, откуда они взяты. И вы не сказали про преимущества js, с которых и началось это обсуждение. Каким образом прототайп не позволяет вам их использовать?
у меня на бэкэнде именно php, и я с большим удовольствием использую прототайп
атри может хваттит с пеной у рта доказыавать свою правоту, пользуйся любой библиотекой, хоть им.Ленина. и не нужно было минусовать мою карму, только из-за того что я выразил свое мение.
я не доказываю свою правоту, а реагирую на попытки доказать, что jQuery однозначно лучше Prototype.js. И делаю это не с пеной у рта, а спокойно и цивилизованно.
каждый может пользоваться библиотекой по своему выбору. Но если он захочет доказать, что она лучше, придется это доказывать.
при чем тут карма, я не понял
каждый может пользоваться библиотекой по своему выбору. Но если он захочет доказать, что она лучше, придется это доказывать.
при чем тут карма, я не понял
Пробовали разные. А работаем с jQuery. Очень довольны. =)
На сегодняшний день джаваскриптом через объект класса XMLHttpRequest можно отправить не только запросы типа GET и POST, но и PUT, DELETE, HEAD.
В каких браузерах возможно отправить XMLHttpRequest типа PUT, DELETE и HEAD?
ff, ie, opera, safari (win)
проверял в последних версиях (ff - 2.x >, ie - 6.x >, opera 9.x >, safari - не помню какая под вин последняя, уверен, что на маках тоже работает и в более ранних версиях указанных браузерах тоже)
По сути, способ передачи данных у методов не очень отличаются от GET и POST
проверял в последних версиях (ff - 2.x >, ie - 6.x >, opera 9.x >, safari - не помню какая под вин последняя, уверен, что на маках тоже работает и в более ранних версиях указанных браузерах тоже)
По сути, способ передачи данных у методов не очень отличаются от GET и POST
Хм, действительно работает. Спасибо, сейчас внесу изменения в статью. Я вот не проверил, а поверил документации и коду prototype.js:
if (!['get', 'post'].include(this.method)) {
// simulate other verbs over post
params['_method'] = this.method;
this.method = 'post';
}
причем поменять это поведение никакими параметрами поменять невозможно.
if (!['get', 'post'].include(this.method)) {
// simulate other verbs over post
params['_method'] = this.method;
this.method = 'post';
}
причем поменять это поведение никакими параметрами поменять невозможно.
Лучше вопрос, а какие серверы их обрабатывают? :)
любые. через PHP можно отловить все запросы.
http://alexpak.name/ru/news/?id=167
http://alexpak.name/ru/news/?id=167
Ну вот. Недавно столкнулся с похожей проблемой. Сойт в вин 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). Что я сделал не так??
Может быть кто то объяснит как мне это удалось? Я тупо подобрал) Итак:
Дано сайт в кодировке 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). Что я сделал не так??
Вы не обрабатываете данные. Вы их получаете, тупо, как вы выражаетесь, передаете в БД и так же тупо выдаете. Поэтому фраза про "Сойт в вин 1251" к делу не относится, он может быть хоть в DOS.
Сойт=Сайт. Насчет не обрабатываю - не совсем понял. Была проблема - русские буквы из БД выводились кракозябликами) Использование функции unescape - решило проблему кракозябликов. iconv не понадобился (у меня его нет на хостинге). Вот собственно и всё. Просто вроде как в статье утверждается что без iconv не обойтись..
Извините - раз в 5 минут коммент, поэтому тут про атаки спрошу.
Если тупо искать строки select\insert\delete в параметрах и отбрасывать параметры если они там вдруг появились - это будет достаточный уровень защищенности?
Извините - раз в 5 минут коммент, поэтому тут про атаки спрошу.
Если тупо искать строки select\insert\delete в параметрах и отбрасывать параметры если они там вдруг появились - это будет достаточный уровень защищенности?
Вы на стороне сервера какой-нибудь обработкой строковых данных занимаетесь?
\"Кавычки \". Cоставление запросов, слеши, SQL Injection
\"Кавычки \". Cоставление запросов, слеши, SQL Injection
1.Нет, данные тупо инсертятся. На то они и данные) Вся обработка(парсинг) в js. Видимо из-за этого и нет проблем с кодировками.
2. Спасибо за ссылку. Теперь более понятно с инъекциями. Честно говоря мне в горячем бреду бы не привиделось допустить ошибки, обработка которых описана в статье)
В Двух словах - статья о том, как сделать всё через жопу(уж как есть говорю), а потом с этим бороться. Проще сразу нормально делать) + спасибо гугл за примеры хорошего кодинга. Тупо передирал у них всякие mysql_real_escape_string и как оказалось не зря)
2. Спасибо за ссылку. Теперь более понятно с инъекциями. Честно говоря мне в горячем бреду бы не привиделось допустить ошибки, обработка которых описана в статье)
В Двух словах - статья о том, как сделать всё через жопу(уж как есть говорю), а потом с этим бороться. Проще сразу нормально делать) + спасибо гугл за примеры хорошего кодинга. Тупо передирал у них всякие mysql_real_escape_string и как оказалось не зря)
Т.е. вы хотите сказать, что на habrahabr.ru, moikrug.ru, vkontakte.ru и market.yandex.ru всё сделано через жопу ;-) ?
К сожалению не знаю как сделано на перечисленных сайтах. Приведите пожалуйста пример кусочка исходников с одного из этих сайтов раз уж Вы знаете как они сделаны. Ну или какое то доказательство. Тогда и сможем оценить)
Сильно сомневаюсь что они настолько пренебрегли архитектурой БД, что были вынуждены прибегнуть к динамически формируемым SQL запросам.
Сильно сомневаюсь что они настолько пренебрегли архитектурой БД, что были вынуждены прибегнуть к динамически формируемым SQL запросам.
Прошу прощения. Только теперь понял что вы о "Cоставление запросов, слеши, SQL Injection", а не о основной статье (http://habrahabr.ru/blog/webdev/32618.ht…).
Нет, по то как организована в перечисленных сайтах работа с БД не имею понятия. Я имел в виду JavaScript, xhtml, etc.
Нет, по то как организована в перечисленных сайтах работа с БД не имею понятия. Я имел в виду JavaScript, xhtml, etc.
А можно спросить, где там написано как все сделать через жопу?
по всей видимости не фильтруешь параметры, таким образом вполне можешь быть (а скорее всего так и есть) подвержен SQL инжект атакам.
А заметьте, что 90% комментариев подразумевают использование PHP на стороне сервера. Это при том, что в соседних топиках идет флуд aka PHP suxx. Однако, парадокс..
По теме: все в курсе про баг в IE на тему UTF-8 кодировки при AJAX-запросе? Или дополнить этот пробел в комменте?
По теме: все в курсе про баг в IE на тему UTF-8 кодировки при AJAX-запросе? Или дополнить этот пробел в комменте?
еще бы оттипографить по человечески статью и будет отличное пособие
Спасибо за статью!
Одно замечание - Ajax давно уже превратился из акронима (AJAX) просто в название, т.к. XMLHttpRequest используется не только в сочетании с XML.
Одно замечание - Ajax давно уже превратился из акронима (AJAX) просто в название, т.к. XMLHttpRequest используется не только в сочетании с XML.
если нужно юзать 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>
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>
фтопку олдскульные кодировки типа 1251, koi8 etc.
К чему статья, можно было написать 1 стрoкой iconv =\
большое спасибо!!!!!!!
Поиски привели меня на эту замечательную подборку:
http://zhilinsky.ru/2007/08/10/php-unicode/
http://zhilinsky.ru/2007/08/10/php-unicode/
как раз то что нада!
спасибо за статью,
теперь уж точно навсегда решу проблему с русским аяксом,
хотя в новых проектах юзаю конечно уже utf8
спасибо за статью,
теперь уж точно навсегда решу проблему с русским аяксом,
хотя в новых проектах юзаю конечно уже utf8
Ой спасибоо)))
Вот напоролся очень жестко с тем, что на страничках windows-1251 аяксом передавался UTF-8
И удивлялись: а что-й то у нас как-то криво работает… Эхх… век живи — век учись.
Вот напоролся очень жестко с тем, что на страничках windows-1251 аяксом передавался UTF-8
И удивлялись: а что-й то у нас как-то криво работает… Эхх… век живи — век учись.
Для 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));
}
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));
}
Кстати, если вы замучались и не понимаете почему UTF8 страница показывается каракулями, хотя meta прописана, то я просто добавлю, посмотрите в htaccess, скорее всего там одна строчка есть такая:
AddDefaultCharset windows-1251
AddDefaultCharset windows-1251
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разберемся раз и навсегда: AJAX, «кириллические символы», кодировки, prototype.js, jQuery, JsHttpRequest