Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 69
>>всеми возможностями юникода.
А можно поподробней?
А можно поподробней?
Я без юникода не могу правильно написать свое имя :(
Вот интересно, а что препятствует переходу всего и вся на юниког, если это такая "клёвая" штука?
Только то, что многие люди попросту не знают о существовалии юникода.
Геморроя же я здесь не вижу. У самого локаль уже давным-давно ru_RU.UTF-8.
Геморроя же я здесь не вижу. У самого локаль уже давным-давно ru_RU.UTF-8.
в частности, поддержка юникода в пхп даже не планируется.
Но мне кажется, что если юникод станет объективной реальности, разработчики пхп не смогут его игнорировать. Так что не ждём, переходим!
Но мне кажется, что если юникод станет объективной реальности, разработчики пхп не смогут его игнорировать. Так что не ждём, переходим!
А я вот слышал, что PHP будет до мозга костей utf'ным!
Абсурд полнейший. PHP уже полностью поддерживает Юникод. Нет ничего легче, чем сделать сайт в кодировке utf-8 на php. Да что там. Все вап сайты в utf. А большинство из них на php.
Что то я не понял. Все сайты Wordpress написаны на PHP и по дефолту работают на UTF-8
см. мой пост выше.
Все сайты Wordpress по дефолту англоязычные => им плевать на кодировку.
У Wordpress есть функция seems_utf8, с помощью которой он может определить, что ему подсунули юникод и пытается конвертировать строку в обычную кодировку. А это уже не поддержка utf.
В utf проекте кодированию/декодированию должна подвергаться только информация, которая приходит извне или уходит куда-то. Внутри проекта конвертироваться ничего не должно. Иначе это не utf проект!
У Wordpress есть функция seems_utf8, с помощью которой он может определить, что ему подсунули юникод и пытается конвертировать строку в обычную кодировку. А это уже не поддержка utf.
В utf проекте кодированию/декодированию должна подвергаться только информация, которая приходит извне или уходит куда-то. Внутри проекта конвертироваться ничего не должно. Иначе это не utf проект!
В PHP 6 планируется полная родная поддержка Unicode. Вот тогда Unicode и пойдёт в массы. ;-)
Сейчас, к сожалению, только через встроенное расширение mbstring с несколько суженной функциональностью.
Сейчас, к сожалению, только через встроенное расширение mbstring с несколько суженной функциональностью.
Почитайте changelog PHP6
Дело в том, что в обычных кодировках типа windows-1251 один символ занимает один байт. И так было изначально и все функции в языках программирования заточены под это. В юникоде символ может состоять из нескольких байт. Например английские буквы занимают один байт. Кириллица уже 2 байта. Попробуйте например посчитать длину слова "Превед", получите 12. А "Превед, медвед" - 26, т.к. запятая и пробел занимают один байт. В общем не все так просто. Вся проблема в софте.
Для perl существует прагма use utf8; Добавляете ее и perl понимает юникод как надо. Не добавляется - творятся чудеса. В PHP про поддержку юникода ничего не знаю, но вроде как ее там нет.
В общем при работе с юникодом надо чтобы язык умел оперировать символами, а не байтами, а это не все умеют, к сожалению.
Использовать юникод в языках, которые с ним работать не умеют можно, но на свой страх и риск. Можно таких чудес насмотреться. Многие начинаю верить в НЛО. А чудес на самом деле нет (в программировании). С опытом это начинаешь понимать ;)
Для perl существует прагма use utf8; Добавляете ее и perl понимает юникод как надо. Не добавляется - творятся чудеса. В PHP про поддержку юникода ничего не знаю, но вроде как ее там нет.
В общем при работе с юникодом надо чтобы язык умел оперировать символами, а не байтами, а это не все умеют, к сожалению.
Использовать юникод в языках, которые с ним работать не умеют можно, но на свой страх и риск. Можно таких чудес насмотреться. Многие начинаю верить в НЛО. А чудес на самом деле нет (в программировании). С опытом это начинаешь понимать ;)
Насчет php & utf - полный бред. Главное - ровные руки.
Это как же? Постоянный encode/decode? Использование mb_ функций? Не слишком ли дорого обойдется подобный переход на юникод? Тем более, что mb_ функции не включены по умолчанию. Простой пример типа
<?php
$str = "dsип";
print mb_strlen($str);
?>
Если исходник в юникоде - выводит 6! В случае с strlen результат тот же.
Ах, ну да. Вы же сказали прямые руки. Я забыл сказать PHP интерпретатору, что у нас все в utf-8, но зачем тогда в языке для этого более 50 новых функций. Вот это бред.
Чтобы перевести проект на PHP в юникод, придется перелопатить весь код, а не сказать в одном месте, что у нас utf-8. Несомненно, для этого нужны исключительной прямоты руки.
Извините, если резко высказался, но высказывания, подобные Вашему, вызывают у меня чувство, будто меня называют лохом. А мне это не нравится.
И еще, я не обсираю Ваш любимый PHP. Я говорю то, что знаю. Если я не прав, очень прошу меня поправить и направить на путь истинный. А комментарии, в стиле Вашего, могут мне сказать только об одном - о Вашей непрофессиональности.
<?php
$str = "dsип";
print mb_strlen($str);
?>
Если исходник в юникоде - выводит 6! В случае с strlen результат тот же.
Ах, ну да. Вы же сказали прямые руки. Я забыл сказать PHP интерпретатору, что у нас все в utf-8, но зачем тогда в языке для этого более 50 новых функций. Вот это бред.
Чтобы перевести проект на PHP в юникод, придется перелопатить весь код, а не сказать в одном месте, что у нас utf-8. Несомненно, для этого нужны исключительной прямоты руки.
Извините, если резко высказался, но высказывания, подобные Вашему, вызывают у меня чувство, будто меня называют лохом. А мне это не нравится.
И еще, я не обсираю Ваш любимый PHP. Я говорю то, что знаю. Если я не прав, очень прошу меня поправить и направить на путь истинный. А комментарии, в стиле Вашего, могут мне сказать только об одном - о Вашей непрофессиональности.
Точно знаю, что отчасти на Perl, отчасти на Си. Может и PHP где-то используется - не знаю.
По информации из первых рук, используется движок PHP-Nuke.
Вы шутите? На нюке Хабр уже давно бы упал и не встал.
Информация из вторых рук куда более приятна. Хотя эти руки, кажется, более первые ;)
Информация из вторых рук куда более приятна. Хотя эти руки, кажется, более первые ;)
А смайл у "первых рук" видели?
Поддерживаю. Сам стараюсь все свои проекты делать в utf, ждём от хабра :)
Давно пора.
Безусловно давно пора. Ещё в юникоде очень удобно расставлять те же ударения.
Давно пора.
Согласен! Необходимо.
Ой, ребята, не управлять вам серьезными проектами, покуда вы внедряете фичи лишь потому, что существует такая техническая возможность.
На юникод переходить надо!!!
И не из-за возможности расставить ударения, а потому что это универсальная кодировка и ее вскоре понимать будут все. Просто если сейчас переход на юникод это, в некоторой мере, просто дань моде, то скоро это станет жизненной необходимостью.
И не из-за возможности расставить ударения, а потому что это универсальная кодировка и ее вскоре понимать будут все. Просто если сейчас переход на юникод это, в некоторой мере, просто дань моде, то скоро это станет жизненной необходимостью.
Unicode — как был, так и остается злом.
Пока зла мало, его не замечаешь. Когда зла становятся сотни гигабайт, задумываешься, зачем оно?
Пока зла мало, его не замечаешь. Когда зла становятся сотни гигабайт, задумываешься, зачем оно?
А в чем злостность?
Да вы погуглите...
Потом почитайте, например, тут:
http://drdaeman.livejournal.com/86120.ht…
http://www.habrahabr.ru/blog/i_am_clever…
и так далее.
Ну и в любом случае — 10 байт лучше чем 40. И 100 Gb лучше чем 400.
Потом почитайте, например, тут:
http://drdaeman.livejournal.com/86120.ht…
http://www.habrahabr.ru/blog/i_am_clever…
и так далее.
Ну и в любом случае — 10 байт лучше чем 40. И 100 Gb лучше чем 400.
По приведенным Вами ссылка народ хвалит UTF-8 и жаждит поскорее на него перейти :) Почитайте внимательнее ;)
>10 байт лучше чем 40
Знаете, отсутствие гемороя с перекодировками куда лучше чем такие мелочи в современном мире. К тому же не 40, а 20. 40 это для китайцев ;)
>10 байт лучше чем 40
Знаете, отсутствие гемороя с перекодировками куда лучше чем такие мелочи в современном мире. К тому же не 40, а 20. 40 это для китайцев ;)
Если Вы плохо умеете читать, то ссылки, как и Unicode, Вам вряд ли помогут. "Почитайте внимательнее" ©, упоминаний проблем с переходом на Unicode даже по этим ссылкам — предостаточно. Если Вы ничего сложнее домашней странички не делали, Вам эти проблемы покажутся надуманными, но от этого они не перестанут быть проблемами.
Размер базы (не вес страницы!), скорость парсинга — не самые последние параметры в серьезной веб-разработке. Некоторые проекты (в области обработки и поиска информации, к примеру) весьма сильно упираются в скорость работы с диском, и уж поверьте, обработка Unicode этой скорости никак не добавляет.
лучше чем такие мелочи в современном миреНизачОт.
Размер базы (не вес страницы!), скорость парсинга — не самые последние параметры в серьезной веб-разработке. Некоторые проекты (в области обработки и поиска информации, к примеру) весьма сильно упираются в скорость работы с диском, и уж поверьте, обработка Unicode этой скорости никак не добавляет.
Ну тогда XML и XSLT величайшее зло, придуманное человеком. Мало того, что сами по себе занимают много места, так еще и юникодовые по умолчанию. Не говорю уже о скоростях их обработки.
Если "скорость парсинга — не самые последние параметры в серьезной веб-разработке", то объясните, почему Google перешел на юникод, а Яндекс вовсю использует XSLT? Или это тоже не сложнее домашней странички?
Про размер БД можете мне не рассказывать. Приходится работать с таблицами в >50М записей. И все в юникоде.
Если "скорость парсинга — не самые последние параметры в серьезной веб-разработке", то объясните, почему Google перешел на юникод, а Яндекс вовсю использует XSLT? Или это тоже не сложнее домашней странички?
Про размер БД можете мне не рассказывать. Приходится работать с таблицами в >50М записей. И все в юникоде.
Давайте не путать мух с котлетами.
XML хорош для передачи данных, но не для хранения (подумайте над поиском по RDBMS где данные упакованы в XML).
XSLT хорош для преобразовнаий.
XML с лёгкостью может "работать" в cp1251
в XSLT кодировка не имеет ни смысла ни значения.
UTF позволяет "не париться" относительно хранения любых кодировок, но и цена у этого "не париться" велика — бездумно такие вещи делать не стоит. Потому все доводы типа "UTF правильно потому, что правильно" это весьма негибкое (грубо говоря тупое) поведение.
Давайте лучше поговорим о тех реальных дивидендах, которые может принести хабру внедрение UTF. Я пока таковых не вижу, а вы?
XML хорош для передачи данных, но не для хранения (подумайте над поиском по RDBMS где данные упакованы в XML).
XSLT хорош для преобразовнаий.
XML с лёгкостью может "работать" в cp1251
в XSLT кодировка не имеет ни смысла ни значения.
UTF позволяет "не париться" относительно хранения любых кодировок, но и цена у этого "не париться" велика — бездумно такие вещи делать не стоит. Потому все доводы типа "UTF правильно потому, что правильно" это весьма негибкое (грубо говоря тупое) поведение.
Давайте лучше поговорим о тех реальных дивидендах, которые может принести хабру внедрение UTF. Я пока таковых не вижу, а вы?
Верите, нет — но так и есть отчасти. XML — штука местами и хорошая, но то, что разбирается основными XML-парсерами на порядок медленнее, чем, например, JSon — к гадалке не ходи, можете тесты в качестве домашнего задания провести.
Выбор технологий и языка программирования зависит от многих причин. Тот же Гугл, если бы индексировал только рунет, данные в Юникоде бы не хранил. Вот есть такое подозрение ;-)
Выбор технологий и языка программирования зависит от многих причин. Тот же Гугл, если бы индексировал только рунет, данные в Юникоде бы не хранил. Вот есть такое подозрение ;-)
считаю, что неиспользующим Unicode кодерам нужно отрывать ноги. Руки оставлять, чтобы смогли переписать свои творения в Unicode.
В данным момент в софте мы имеет такое:
А хабр просто не пропускает нелатинские и некириллические символы, обрезая сообщения по первому неформатному символу.
Из создавшейся ситуации с кодировками следует вывод, что среднестатический кодер не догадывается о существовании других стран, языков и раскладок, кроме родной и английской, а если и догадывается, то просто ленив или недостаточно грамотен, чтобы использовать Unicode.
К слову, у Google и Microsoft и в массе своей у opensource-разработчиков вполне получается работать с Unicode, да и по примеру на скриншоте видно, что в том конкретном случае это было возможно, просто лениво.
В данным момент в софте мы имеет такое:
А хабр просто не пропускает нелатинские и некириллические символы, обрезая сообщения по первому неформатному символу.
Из создавшейся ситуации с кодировками следует вывод, что среднестатический кодер не догадывается о существовании других стран, языков и раскладок, кроме родной и английской, а если и догадывается, то просто ленив или недостаточно грамотен, чтобы использовать Unicode.
К слову, у Google и Microsoft и в массе своей у opensource-разработчиков вполне получается работать с Unicode, да и по примеру на скриншоте видно, что в том конкретном случае это было возможно, просто лениво.
С чего Вы взяли, что это Unicode?
В заголовке окна на картинке написано "QIP - Спокойное общение", если мне память не изменяет.
Так вот, если бы это был юникод, то было бы "QIP - РЎРїРѕРєРѕР№РЅРѕРµ общение".
У Вас что-то либо со шрифтами, либо с кодовыми страницами, и уж точно не с юникодом ;)
В заголовке окна на картинке написано "QIP - Спокойное общение", если мне память не изменяет.
Так вот, если бы это был юникод, то было бы "QIP - РЎРїРѕРєРѕР№РЅРѕРµ общение".
У Вас что-то либо со шрифтами, либо с кодовыми страницами, и уж точно не с юникодом ;)
Думаю, у автора поста с системой всё в порядке, а лажа на скриншоте — это как раз проявление неюникодного приложения — система для них использует локаль по умолчанию. Если приложенеие юникодное, то проблем быть совсем не должно.
РЎРїРѕРєР — это попытка отобразить текс, закодированный юникодом на неюникодной локали. В винде такое не должно встречаться совсем (за исключением браузера, конечно).
РЎРїРѕРєР — это попытка отобразить текс, закодированный юникодом на неюникодной локали. В винде такое не должно встречаться совсем (за исключением браузера, конечно).
это не Unicode. это его отсутствие. причём проблема не принципиальная - типа, Delphi не умеет работать с Unicode в VCL, а Qt жрёт много ресурсов - а именно ляп разработчиков, что показывает нижняя строка на кириллице, на удивление отображённая правильно.
Надо бы заставить всех разработчиков программировать в чуждой им локали - русских в немецкой, немцев в китайской и т.п., тогда быстро бы привыкли писать всё в Unicode. Делается это всё очень просто - достаточно поменять язык по умолчанию для неюникодных программ с родного на вражеский, и тогдапридёт весна и все увидят, кто где ср.. все ляпы с кодировками станут видны.
Надо бы заставить всех разработчиков программировать в чуждой им локали - русских в немецкой, немцев в китайской и т.п., тогда быстро бы привыкли писать всё в Unicode. Делается это всё очень просто - достаточно поменять язык по умолчанию для неюникодных программ с родного на вражеский, и тогда
Упс. Прошу прощения. Не внимательно читал. Вы сказали "неиспользующим Unicode кодерам нужно отрывать ноги". Прочитал как использующим.
А в чем злостность?
я вот этим иконвом наоборот сайты гоняю в цп1251, хотя кодировка системы именно утф8, и все оттого, что так и не смог добиться нормального отображения сайта в IE, мета-тэги не помогли, если руками каждый раз ставить кодировку, то все нормально, а вот автоматом не хочет ни в какую... а к сожалению на этот _браузер_ еще стоит ориентироваться
iconv с юникодом и cp1251 не всегда корректно работает. Тут аккуратнее надо быть, чтобы однажды не получить битую страницу..
Где-то у вас ошибочка, никаких пробем с utf-8 в IE нет
Нужен вот такой мета-тег <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
Если не помогает, проверьте действительно ли страница в utf-8.
Нужен вот такой мета-тег <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
Если не помогает, проверьте действительно ли страница в utf-8.
function encode($buf) {
return iconv("Windows-1251","UTF-8",$buf);
}
header("Content-type: text/html;charset=utf-8");
ob_start('encode');
блаблабла
ob_end_flush();
В ие имелась описанная вами проблема, решилась дописыванием в head
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
Обратите внимание, что он и так не особо держит нагрузку (kolbaskin error все видели?) А тут вы предлагаете всё пустить через unicode-wrapper и увеличить объём трафика где-то на треть только из любви к искуству? По мне так нужны аргументы поувесистее.
Лично я, хоть и сторонник UTF не вижу никакой необходимости в нём на Хабре.
Лично я, хоть и сторонник UTF не вижу никакой необходимости в нём на Хабре.
Эх, жаль, что об этом посте только сегодня узнал, ибо как раз 15 мая, только за 3 часа до появления этого поста в Хабравики в разделе ToDo появился в графе "Приоритетные большие штуковины" пункт перевода сайта на UTF.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Даёшь UTF-8!