Comments 30
Пожалуй, со времен введения нового драйвера для MySQL (в версии 5.3, если не ошибаюсь) апдейты касающиеся кодировок, и в особенности более глубокой поддержки UTF-8, действительно стОящие внимания, с точки зрения полезности для конечного разработчика. Отличная новость! Это вам не автозагрузка классов и прочая сомнительной пользы ерунда (IMHO).
все улучшения связанные с кодировкой в php это пожалуй самое ожидаемое в его обновлениях
Надеюсь, когда нибудь utf-8 станет классикой, не придется мучиться с iconv и всем таким. Поэтому, новость радостная.
> когда нибудь utf-8 станет классикой

Классикой в смысле «вымрет за ненадобностью»? ;)

Потому что вместо iconv на смену придет нормализованные и ненормализованные формы, каноникализация и т.д. и т.п., что ни один из языков (кроме, вроде, Perl'а) не поддерживает в полном объеме (если только нет полноценной привязки к ICU)
Увы, чтобы без заморочек выгрузить простейшую таблицу в csv приходится извращаться с перекодировкой в CP1251, чтобы Excel понял… Либо ставить параллельно с M$ Office ещё Open/LibreOffice.
Используй utf 16 + BOM, 2007-й офис открывает такие файлы нормально и символы не потеряешь
> Надеюсь, когда нибудь utf-8 станет классикой

Всем нам ещё очень много кода придется перебрать и конвертировать в utf-8.
Хочется, чтобы то, что пишется сейчас, использовали в большинстве своем utf-8, так нет, сколько натыкаюсь на недокодеров, руки у них к cp1251 тянутся.
А в чем проблема? Если не предполагается работать с языками, отличными от русского и английского, не вижу проблем в cp1251. По крайней мере, памяти потребляется в два раза меньше, и строковые операции соответственно в два раза быстрее, на высоконагруженных проектах это может иметь значение.
Жаль, где-нибудь в php.ini нельзя присвоить значения по умолчанию для флагов, придётся писать обёртку.
> Как вы знаете, третий аргумент для htmlspecialchars это кодировка. Большинство людей просто упускают этот аргумент, таким образом, получая кодировку по умолчанию. Это значение было ISO-8859-1 до PHP 5.4. Новая версия исправляет это, сделав UTF-8 по умолчанию.

На сайтах с 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).
Недавно в аналогичной дискуссии по поводу PHP + UTF-8 кто-то кинул ссылку на интересную статью: www.amiro.ru/blog/tech/how-was-php6-died

Пишут, что при попытке внедрить 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.
В чем сложность для хостера предлагать на выбор две разные версии пхп, одна из которых не совместима со старыми не юникод проектами? Надо же когда-то перейти на юникод, навести порядок в свалке функций, перекочевавших из 4 версии? Имена функций с подчеркиванием и без, и существительные и глаголы, гет в начале и гет в конце имени функции, куча функций которые делают одно и то же (в том числе юникод и не юникод версии), разный порядок аргументов в схожих по функционалу функциях (привет array_map и array_walk). А если и дальше стараться, чтобы написанное под 4 пхп работало — порядка никогда не будет.
Там скорее с php3 свалка, если не раньше (с тройки начинал). Есть ничем необоснованная надежда, что к PHP6 всё же порядок наведут — разбросают функции по классам/объектам/неймспейсам, а нынешний бардак сделают алиасами и деприкэйтед.
Э… а можно вопрос в кучу?

Есть ли какая альтернатива совершенно идиотскому использованию htmlspecialchars для проверки строки в UTF-8 на валидность? Друпальщики используют эту функцию в check_plain, что время от времени приводит к ошибкам, поскольку htmlspecialchars меняет строку, а это не всегда нужно.
Меня давно удивляет, почему такая важная функция, из-за неиспользования которой, в том числе, кросс-скриптится множество сайтов, имеет такое длинное и труднопечатаемое название.
Ад, дикий ад. Разработчиков хочется за это убить, о слове «совместимости» как той же Java они слышать не слышали.
Мало того, 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 не суперглобальна, но какая нахрена разница в этом случае для старого кода, где везде написано global $HTTP_GET_VARS? Почему это вдруг код, работающий много лет, вдруг становится нерабочим на 5.4, а те же программы на C, написанные в 75, до сих пор компилируются?
Only those users with full accounts are able to leave comments. Log in, please.