error_log, залитый «charset, не поддерживается», предполагая, что utf-8 «quot; Сообщения
Проблема: Журнал ошибок в блоге WordPress заполнен сообщениями «charset not поддерживается, при условии что utf-8»; увеличивается на 0 байт до 450 Мб за 24 часа (около 28 тыс. просмотров страниц, если статистика верна).
Подробности: У меня есть блог на WordPress, размещенный на общем хостинге. Он работал годами, и это никогда не было проблемой, пока не так давно, но я не могу точно определить точные временные рамки, когда это начало происходить. Несколько месяцев назад я начал превышать разрешенные ресурсы (в основном память), поэтому они переместили меня на другой сервер, и мне пришлось обновить учетную запись для более высокого использования разрешенных ресурсов. Старый сервер работал под управлением php5, этот — под php7. Последние WP + около 15 популярных плагинов, все соответствующие версии. Тема древняя, она была там с самого начала.
Вчера я удалил журнал ошибок 9 ГБ (!) В корне сайта, сегодня, через 24 часа, его 500 МБ. Все линии похожи:
[datetime] PHP Warning: html_entity_decode(): charset `keep-ali0' not supported, assuming utf-8 in /home/accountname/public_html/wp-includes/formatting.php on line 5124
[datetime] PHP Warning: htmlentities(): charset `/[^0-9\.]/' not supported, assuming utf-8 in /home/accountname/public_html/wp-content/plugins/wp-super-cache/wp-cache-base.php on line 5
... etc.
Я проанализировал старый журнал 2 ГБ:
- они пришли из 13 файлов: 3 основных файла WP, другие из 6 различных плагинов
- только из этих функций:
htmlentities(),htmlspecialchars(),html_entity_decode() - более 1000 уникальных «кодировок»: все это мусор, большинство включает непечатаемые символы, другие просто странные вещи: пути (не мои!), регулярные выражения, целые числа, шестнадцатеричные значения …:
#^[a-z]:[/\\]#i,meta_value,0x7fe858ae2920,/home/someone-elses-account-name/public_html/includes/functions.php…
Откуда эти ценности?
Где я могу начать устранять неисправности?
Редактировать: Решение
Ниже есть отличный ответ с объяснением того, почему это происходит. К сожалению, находясь на виртуальном хостинге и используя сторонние приложения, я не мог использовать никаких обходных путей. Но после разговора с хостинг-провайдером они добавили internal_encoding utf-8 Конфиг веб-сервера Apache через include config (что-то в этом роде). И это сработало.
Решение
Похоже, это известная ошибка в PHP, которую трудно воспроизвести, поэтому она застряла на некоторое время.
https://bugs.php.net/bug.php?id=71876
Были предложены различные обходные пути, в том числе:
- настройка
internal_encoding=utf-8в php.ini или используяini_set('internal_encoding', 'utf-8'); - Обеспечение этого
default_charsetявляется не установлен в php.ini - Добавление набора символов к вызову функции, например,
html_entity_decode($x, null, 'utf-8');
Эти обходные пути, кажется, имеют смешанные результаты.
Другие решения
Этот ответ неверный, пожалуйста, смотрите комментарий к вопросу @ miken32.
Я не буду возвращаться к stackoverflow некоторое время, поэтому могу дать вам только первую итерацию процесса для решения вашей проблемы. Поместите следующее в ваш файл functions.php.
set_error_handler( function( $errno, $errstr, $errfile, $errline ) {
static $count = 0;
if ( $count++ < 10 && $errno == E_USER_WARNING ) {
error_log( print_r ( debug_backtrace(), true ) );
}
} );
Это даст вам обратную трассировку при возникновении ошибки. На основании этого следа вам может потребоваться или не потребоваться сбор дополнительных данных, чтобы понять вашу проблему. Функция set_error_handler документирована Вот и функция debug_backtrace документирована Вот. Если есть другие ошибки E_USER_WARNING, вам необходимо выполнить дополнительную фильтрацию файла и номера строки. Опция php.ini error_reporting задокументирована Вот.
Я предполагаю, что эта проблема, вероятно, вызвана неправильными данными в базе данных, которые недавно были введены в вашу базу данных. Надеюсь, обратная трассировка скажет вам, где эти данные.
Надеюсь это поможет. Удачи.
тс