В новой версии PHP, как уже было сказано, пофиксено множество неприятных вещей. Среди них и баг за номером 42 090, опубликованный аж в июле 2007. Баг этот позволял грохнуть процесс посылкой непотребного JSON-запроса. Хотя, видимо, работало это только под Ubuntu (мне не на windows ни на freebsd воиспроизвести не удалось), всё же исправление данной ошибки, несомненно, радует.

А вот json_encode() продолжает огорчать. В документации к нему написано This function only works with UTF-8 encoded data. И правда, от любых других кодировок он просто отплёвывается. Но мне это до без разницы, неприятно то, что и с UTF-8, работает он через жопу.

Вызов json_encode("русский текст") выдаёт гомосятину вида \u0440\u0443\u0441\u0441\u043a… Какого хера? Зачем работая only with UTF, выдавая строку для JS, которая так же работает всегда only UTF, кодировать всё этими идиотскими мнемониками?

Мало того, что вывод превращается в кашу, в которой не разобраться визуально при отладке, так ещё вместо 2-х байт на символ, шлём 6. Вот вам и экономия трафика за счёт ajax’а.

Так что нужно или мириться с этим или извращаться самим на PHP, как это делают люди в комментариях к документации.

Если для каких-то высоких целей универсальности и сохранения совместимости это и необходимо, почему не ввести второй аргумент функции, типа, $mneNahuyNeNujnaSovmestimost? Впрочем второй аргумент там есть: [, int $options=0], как написано, это Bitmask consisting of PHP_JSON_HEX_QUOT, PHP_JSON_HEX_TAG, PHP_JSON_HEX_AMP, PHP_JSON_HEX_APOS. Что означают все эти мракобесные константы не уточняется. Впрочем и уточнение тут не поможет — на любой вызов со вторым аргументом функция ругается json_encode() expects exactly 1 parameter, 2 given и Use of undefined constant PHP_JSON_HEX_QUOT.

Вобщем, ждём, когда adw0rd напишет новое расширение. :)