Comments 30
Пожалуй, со времен введения нового драйвера для MySQL (в версии 5.3, если не ошибаюсь) апдейты касающиеся кодировок, и в особенности более глубокой поддержки UTF-8, действительно стОящие внимания, с точки зрения полезности для конечного разработчика. Отличная новость! Это вам не автозагрузка классов и прочая сомнительной пользы ерунда (IMHO).
Насчёт автозагрузки классов я готов поспорить :)
все улучшения связанные с кодировкой в php это пожалуй самое ожидаемое в его обновлениях
Я бы тоже!
Ответ ниже :(
Если вы ранее не использовали SPL это ничего не значит
Надеюсь, когда нибудь utf-8 станет классикой, не придется мучиться с iconv и всем таким. Поэтому, новость радостная.
> когда нибудь utf-8 станет классикой
Классикой в смысле «вымрет за ненадобностью»? ;)
Потому что вместо iconv на смену придет нормализованные и ненормализованные формы, каноникализация и т.д. и т.п., что ни один из языков (кроме, вроде, Perl'а) не поддерживает в полном объеме (если только нет полноценной привязки к ICU)
Классикой в смысле «вымрет за ненадобностью»? ;)
Потому что вместо iconv на смену придет нормализованные и ненормализованные формы, каноникализация и т.д. и т.п., что ни один из языков (кроме, вроде, Perl'а) не поддерживает в полном объеме (если только нет полноценной привязки к ICU)
Увы, чтобы без заморочек выгрузить простейшую таблицу в csv приходится извращаться с перекодировкой в CP1251, чтобы Excel понял… Либо ставить параллельно с M$ Office ещё Open/LibreOffice.
> Надеюсь, когда нибудь utf-8 станет классикой
Всем нам ещё очень много кода придется перебрать и конвертировать в utf-8.
Всем нам ещё очень много кода придется перебрать и конвертировать в utf-8.
Жаль, где-нибудь в php.ini нельзя присвоить значения по умолчанию для флагов, придётся писать обёртку.
> Как вы знаете, третий аргумент для htmlspecialchars это кодировка. Большинство людей просто упускают этот аргумент, таким образом, получая кодировку по умолчанию. Это значение было ISO-8859-1 до PHP 5.4. Новая версия исправляет это, сделав UTF-8 по умолчанию.
На сайтах с win1251 (я знаю, такие до сих пор есть) символы кириллицы будут поняты как неправильный UTF код и функция видимо будет возвращать пустую строку.
Я лично считаю, что дефолтная кодировка ISO это как раз хорошо, так как с ней функция только меняет 5 символов на сущности, а теперь она будет еще анализировать правильность UTF символов, и работать намного медленнее (и я не представляю ситуации где эта проверка нужна).
И еще, хотелось бы сказать всем, кто кричит о поддержке кодировок — идите на свой Питон, Яву или что у вас там есть. PHP всегда работал с бинарными строками, и работал замечательно, и никакой дополнительной поддержки НЕ требется. Все виду русских и нерусских букв давно поддерживаются. Бинарные строки без кодировок работают быстрее. Используйте utf-8 и mb_* функции для строк, флаг u для регулярок с русскими буквами, и никаких проблем (кроме ф-й из раздела preg-*) у вас никогда не будет. Если же вы настолько тупые, что этого не понимаете, то вам никакая встроенная поддержка юникода уже не поможет. Спасибо.
На сайтах с win1251 (я знаю, такие до сих пор есть) символы кириллицы будут поняты как неправильный UTF код и функция видимо будет возвращать пустую строку.
Я лично считаю, что дефолтная кодировка ISO это как раз хорошо, так как с ней функция только меняет 5 символов на сущности, а теперь она будет еще анализировать правильность UTF символов, и работать намного медленнее (и я не представляю ситуации где эта проверка нужна).
И еще, хотелось бы сказать всем, кто кричит о поддержке кодировок — идите на свой Питон, Яву или что у вас там есть. PHP всегда работал с бинарными строками, и работал замечательно, и никакой дополнительной поддержки НЕ требется. Все виду русских и нерусских букв давно поддерживаются. Бинарные строки без кодировок работают быстрее. Используйте utf-8 и mb_* функции для строк, флаг u для регулярок с русскими буквами, и никаких проблем (кроме ф-й из раздела preg-*) у вас никогда не будет. Если же вы настолько тупые, что этого не понимаете, то вам никакая встроенная поддержка юникода уже не поможет. Спасибо.
Радикально!
Жду не дождусь пхп-пример, где производительность упирается в скорость работы utf-8 строк :)
Более того, utf-8 и бинарные строки полностью идентичны в случае, когда не содержат символов кроме латиницы и пунктуации (ну, грубо, печатный ascii). А если содержат, то utf использовать все равно необходимо.
Все проблемы с 1251, как я понимаю, лечатся с помощью default_charset = блабла в php.ini
Нативная поддержка utf нужна везде, сейчас даже url-ы содержат кириллицу и иероглифы. parse_url() уже небезопасно использовать (баг #52923).
Более того, utf-8 и бинарные строки полностью идентичны в случае, когда не содержат символов кроме латиницы и пунктуации (ну, грубо, печатный ascii). А если содержат, то utf использовать все равно необходимо.
Все проблемы с 1251, как я понимаю, лечатся с помощью default_charset = блабла в php.ini
Нативная поддержка utf нужна везде, сейчас даже url-ы содержат кириллицу и иероглифы. parse_url() уже небезопасно использовать (баг #52923).
Недавно в аналогичной дискуссии по поводу PHP + UTF-8 кто-то кинул ссылку на интересную статью: www.amiro.ru/blog/tech/how-was-php6-died
Пишут, что при попытке внедрить UTF-8 везде и всюду на уровне ядра PHP, разработчики столкнулись с непреодолимыми тормозами, что забили на это дело.
Пишут, что при попытке внедрить UTF-8 везде и всюду на уровне ядра PHP, разработчики столкнулись с непреодолимыми тормозами, что забили на это дело.
Не UTF-8, а UTF-16. По той статье неясно насколько бы спасла ситуацию UTF-8, но как-то складывается впечатление, что спсла бы:
Выбор был остановлен на UTF-16. Основным минусами этой кодировки являлось ... множественные сопутствующие преобразования данных ... Как позднее признаются разработчики, если бы они могли начать все сначала, то выбор бы пал на UTF-8.
Как следствие множественных преобразований данных, появилось ощутимое снижение производительности в работе критичных компонент PHP:
Вы случайно не брат Лердорфа? Array dereferncing может тоже не нужен? Если вы настолько тупой что считаете что свалка из функций для работы со строками с дублирующимся функционалом в пхп это хорошо — ну что ж…
Но это же не «дублирующийся функционал», а совершенно разные вещи — байтовая строка и символьная строка.
Два набора функций — это хоть и зло, но едва ли не наименьшее из возможных.
Исторически получилось, что в php были только байтовые строки, и нельзя делать вид, что их больше нет, потому что это моментально ломает любой существующий код, работающий с бинарными файлами или сетевыми протоколами, да и вообще с любыми данными не в utf-8.
Поэтому нельзя просто так взять и «перейти на юникод» одним волшебным патчем — поди разбери, где в старом коде вызов какого-нибудь substr() должен на самом деле работать с байтами, а где с символами.
По этой же причине всякие mbstring.func_overload являются мертворожденными костылями.
По-хорошему, htmlspecialchars и многим другим (не всем) строковым функциям должно быть плевать, latin1 у них на входе или utf-8, пока заменяемые и заменяющие байты укладываются в диапазон 0-127, т.е., совпадают с символами.
Собственно, в этом и есть одно из ключевых преимуществ utf-8 — код, который ничего знает про различие между байтами и символами, в большинстве случаев просто работает (пока не лезет менять старшие байты).
Итого:
проблема есть, простого решения она не имеет, выбранное решение, к сожалению, больше создает новых проблем, чем решает старых.
Потом все будут жаловаться, а что это хостинги не спешат переходить на новую версию — ну а какому хостеру в здравом уме надо, чтобы при апгрейде у него сломались абсолютно все сайты, использующие кодировку, отличную от utf-8.
Два набора функций — это хоть и зло, но едва ли не наименьшее из возможных.
Исторически получилось, что в php были только байтовые строки, и нельзя делать вид, что их больше нет, потому что это моментально ломает любой существующий код, работающий с бинарными файлами или сетевыми протоколами, да и вообще с любыми данными не в utf-8.
Поэтому нельзя просто так взять и «перейти на юникод» одним волшебным патчем — поди разбери, где в старом коде вызов какого-нибудь substr() должен на самом деле работать с байтами, а где с символами.
По этой же причине всякие mbstring.func_overload являются мертворожденными костылями.
По-хорошему, htmlspecialchars и многим другим (не всем) строковым функциям должно быть плевать, latin1 у них на входе или utf-8, пока заменяемые и заменяющие байты укладываются в диапазон 0-127, т.е., совпадают с символами.
Собственно, в этом и есть одно из ключевых преимуществ utf-8 — код, который ничего знает про различие между байтами и символами, в большинстве случаев просто работает (пока не лезет менять старшие байты).
Итого:
проблема есть, простого решения она не имеет, выбранное решение, к сожалению, больше создает новых проблем, чем решает старых.
Потом все будут жаловаться, а что это хостинги не спешат переходить на новую версию — ну а какому хостеру в здравом уме надо, чтобы при апгрейде у него сломались абсолютно все сайты, использующие кодировку, отличную от utf-8.
В чем сложность для хостера предлагать на выбор две разные версии пхп, одна из которых не совместима со старыми не юникод проектами? Надо же когда-то перейти на юникод, навести порядок в свалке функций, перекочевавших из 4 версии? Имена функций с подчеркиванием и без, и существительные и глаголы, гет в начале и гет в конце имени функции, куча функций которые делают одно и то же (в том числе юникод и не юникод версии), разный порядок аргументов в схожих по функционалу функциях (привет array_map и array_walk). А если и дальше стараться, чтобы написанное под 4 пхп работало — порядка никогда не будет.
mb_check_encoding($string, 'UTF-8'), не?
Если ничего в этом плане не поменялось, то вот: http://habrahabr.ru/blogs/php/107945/
Меня давно удивляет, почему такая важная функция, из-за неиспользования которой, в том числе, кросс-скриптится множество сайтов, имеет такое длинное и труднопечатаемое название.
Ад, дикий ад. Разработчиков хочется за это убить, о слове «совместимости» как той же Java они слышать не слышали.
Мало того, default_charset не действует на htmlspecialchars, и чтобы действовал, надо всё равно передавать пустую кодировку. То есть всё равно искать абсолютно все (!) вызовы htmlspecialchars.
Тот же HTTP_GET_VARS и $_GET, ну какая нахрен разница для парсера как оно называется, зачем надо было в 5.4 жестко это запрещать, чтобы абсолютно все старые скрипты перестали работать и их пришлось срочно переписывать, как будто других дел больше нет?
За эту каку и постоянные подножки этим индусам еще и платят.
Ну вот после этого PHP можно называться Enterprise решением, если они ложат на совместимость большой болт?
Подскажите, кроме Java, есть ещё вменяемые языки для web, где разработчики думают о мозгом о совместимости, и добавляя новые возможности, не делают неработоспособными старые?
Мало того, default_charset не действует на htmlspecialchars, и чтобы действовал, надо всё равно передавать пустую кодировку. То есть всё равно искать абсолютно все (!) вызовы htmlspecialchars.
Тот же HTTP_GET_VARS и $_GET, ну какая нахрен разница для парсера как оно называется, зачем надо было в 5.4 жестко это запрещать, чтобы абсолютно все старые скрипты перестали работать и их пришлось срочно переписывать, как будто других дел больше нет?
За эту каку и постоянные подножки этим индусам еще и платят.
Ну вот после этого PHP можно называться Enterprise решением, если они ложат на совместимость большой болт?
Подскажите, кроме Java, есть ещё вменяемые языки для web, где разработчики думают о мозгом о совместимости, и добавляя новые возможности, не делают неработоспособными старые?
Тот же HTTP_GET_VARS и $_GET, ну какая нахрен разница для парсера как оно называется, зачем надо было в 5.4 жестко это запрещать, чтобы абсолютно все старые скрипты перестали работать и их пришлось срочно переписывать, как будто других дел больше нет?
Емнип, дело в идеологии, HTTP_GET_VARS — глобальна, а $_GET — суперглобальна. Хотя могу и ошибаться, лень лезть в ман :)
Подскажите, кроме Java, есть ещё вменяемые языки для web, где разработчики думают о мозгом о совместимости, и добавляя новые возможности, не делают неработоспособными старые?
По слухам (в основном из стана любителей MS) при использовании C# + .NET об обратной совместимости можно не беспокоиться. При использовании C# + Mono никакой инфы на глаза не попадалось по этому поводу.
Емнип, дело в идеологии, HTTP_GET_VARS — глобальна, а $_GET — суперглобальна. Хотя могу и ошибаться, лень лезть в ман :)
Подскажите, кроме Java, есть ещё вменяемые языки для web, где разработчики думают о мозгом о совместимости, и добавляя новые возможности, не делают неработоспособными старые?
По слухам (в основном из стана любителей MS) при использовании C# + .NET об обратной совместимости можно не беспокоиться. При использовании C# + Mono никакой инфы на глаза не попадалось по этому поводу.
Sign up to leave a comment.
Улучшения в htmlspecialchars() в версии 5.4