Php ошибки на русском

Вывод ошибки MySQL будет зависеть от самой сборки, LANG на сервере (+еще некоторое количество всякой фигни) и того, как отображает у тебя text WEB-сервер

Я бы посоветовал начать отладку с установки в .htaccess параметра

AddDefaultCharset utf-8

В 90% случаев на этом все и заканчивается

Если не поможет, иди по шагам:

1. На какой ОС все это работает и какая кодировка в этой ОС по умолчанию
2. В какой кодировке живет сервер SQL
3. В какой кодировке живет WEB-сервер

Кстати говоря, полученный текст можешь взять, скопировать в буфер и вставить вот сюда: https://www.artlebedev.ru/decoder/ — классная штука, позволяет быстро и просто понять, что происходит

Только копируй прям сразу где увидел, а не из поста выше, например. Символ � — вполне себе печатный символ UTF-8, кодировать его куда-то еще не получится ) Так случается после вставки кракозябр куда-то, где контент в UTF-8.. они просто преобразуются в обычные UTF-8 символы.

UPD. Я провел эксперимент:

1. Взял вашу исходную предполагаемую строчку mysqli_connect(): (HY000/2002): Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение.

2. Записал ее в файл в кодировке UTF-8:

   $ env | grep LANG
   LANG=ru_RU.UTF-8

   $ echo «mysqli_connect(): (HY000/2002): Подключение не установлено, т.к. конечный компьютер отверг запрос на подключение.» > q686819.txt

3. Полученный файл перегнал из UTF-8 в CP-1251 (она же windows-1251)

   $ iconv -f utf-8 -t windows-1251 ./q686819.txt

   mysqli_connect(): (HY000/2002): ����������� �� �����������, �.�. �������� ��������� ������ ������ �� �����������.

Консоль у меня отображает вывод в UTF-8, но выводимые символы имеют кодировку CP-1251

Отсюда можно сделать следующий полезный для вас вывод: исходный текст ваша сборка MySQL выводит в кодировке windows-1251 (скорее всего потому что собрана под Windows, а там в русской локализации по умолчанию именно windows-1251). А вопросики вы видите потому, что смотрите на символы через призму кодировку utf-8

Решение: либо поменять сборку MySQL на EN, без локализации на русском (возможно там в параметрах можно поменять LANG для ошибок или что-то вроде того — обычно такие пакеты делают мультиязычными, а язык выбирается из параметров ОС), либо ничего не менять и выводить в windows-1251 (как сейчас), но смотреть на это через призму той же кодировки windows-1251, например в .htaccess

AddDefaultCharset windows-1251

Попробуйте, тут нужны эксперименты именно с вашей сборкой и на Windows. К сожалению подробнее я вам не подскажу — пользуюсь Linux и обычными Apache httpd и mariadb из репозиториев. Но направление определенно верное

Время на прочтение
6 мин

Количество просмотров 67K

В статье представлена очередная попытка разобраться с ошибками, которые могут встретиться на вашем пути php-разработчика, их возможная классификация, примеры их возникновения, влияние ошибок на ответ клиенту, а также инструкции по написанию своего обработчика ошибок.

Статья разбита на четыре раздела:

1. Классификация ошибок.
2. Пример, демонстрирующий различные виды ошибок и его поведение при различных настройках.
3. Написание собственного обработчика ошибок.
4. Полезные ссылки.

Классификация ошибок

Все ошибки, условно, можно разбить на категории по нескольким критериям.
Фатальность:

• Фатальные
  Неустранимые ошибки. Работа скрипта прекращается.
  E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR.
• Не фатальные
  Устранимые ошибки. Работа скрипта не прекращается.
  E_WARNING, E_NOTICE, E_CORE_WARNING, E_COMPILE_WARNING, E_USER_WARNING, E_USER_NOTICE, E_STRICT, E_DEPRECATED, E_USER_DEPRECATED.
• Смешанные
  Фатальные, но только, если не обработаны функцией, определенной пользователем в set_error_handler().
  E_USER_ERROR, E_RECOVERABLE_ERROR.

Возможность перехвата ошибки функцией, определенной в set_error_handler():

• Перехватываемые (не фатальные и смешанные)
  E_USER_ERROR, E_RECOVERABLE_ERROR, E_WARNING, E_NOTICE, E_USER_WARNING, E_USER_NOTICE, E_STRICT, E_DEPRECATED, E_USER_DEPRECATED.
• Не перехватываемые (фатальные)
  E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING.

Инициатор:

• Инициированы пользователем
  E_USER_ERROR, E_USER_WARNING, E_USER_NOTICE.
• Инициированы PHP
  E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR, E_WARNING, E_NOTICE, E_CORE_WARNING, E_COMPILE_WARNING, E_STRICT, E_DEPRECATED, E_USER_DEPRECATED, E_USER_ERROR, E_RECOVERABLE_ERROR.

Для нас, в рамках данной статьи, наиболее интересны классификации по первым двум критериям, о чем будет рассказано далее.

Примеры возникновения ошибок

Листинг index.php

<?php
// определеяем уровень протоколирования ошибок
error_reporting(E_ALL | E_STRICT);
// определяем режим вывода ошибок
ini_set('display_errors', 'On');
// подключаем файл с ошибками
require 'errors.php';

Листинг errors.php

<?php
echo "Файл с ошибками. Начало<br>";
/*
 * перехватываемые ошибки (ловятся функцией set_error_handler())
 */
// NONFATAL - E_NOTICE
// echo $undefined_var;
// NONFATAL - E_WARNING
// array_key_exists('key', NULL);
// NONFATAL - E_DEPRECATED
split('[/.-]', "12/21/2012"); // split() deprecated начиная с php 5.3.0
// NONFATAL - E_STRICT
// class c {function f(){}} c::f();
// NONFATAL - E_USER_DEPRECATED
// trigger_error("E_USER_DEPRECATED", E_USER_DEPRECATED);
// NONFATAL - E_USER_WARNING
// trigger_error("E_USER_WARNING", E_USER_WARNING);
// NONFATAL - E_USER_NOTICE
// trigger_error("E_USER_NOTICE", E_USER_NOTICE);

// FATAL, если не обработана функцией set_error_handler - E_RECOVERABLE_ERROR
// class b {function f(int $a){}} $b = new b; $b->f(NULL);
// FATAL, если не обработана функцией set_error_handler - E_USER_ERROR
// trigger_error("E_USER_ERROR", E_USER_ERROR);

/*
 * неперехватываемые (не ловятся функцией set_error_handler())
 */
// FATAL - E_ERROR
// undefined_function();
// FATAL - E_PARSE
// parse_error
// FATAL - E_COMPILE_ERROR
// $var[];

echo "Файл с ошибками. Конец<br>";

Примечание: для полной работоспособности скрипта необходим PHP версии не ниже 5.3.0.

В файле errors.php представлены выражения, инициирующие практически все возможные ошибки. Исключение составили: E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_WARNING, генерируемые ядром Zend. В теории, встретить их в реальной работе вы не должны.
В следующей таблице приведены варианты поведения этого скрипта в различных условиях (в зависимости от значений директив display_errors и error_reporting):

^* Значение ANY означает E_ALL | E_STRICT или 0.
^** Ответ клиенту может отличаться от ответов на реальных скриптах. Например, вывод какой-либо информации до включения файла errors.php, будет фигурировать во всех рассмотренных случаях.
^*** Если в файле errors.php заменить пример для ошибки E_COMPILE_ERROR на require "missing_file.php";, то ошибка попадет во вторую группу.

Значение, приведенной выше, таблицы можно описать следующим образом:

1. Наличие в файле скрипта ошибки, приводящей его в «негодное» состояние (невозможность корректно обработать), на выходе даст пустое значение или же только само сообщение об ошибке, в зависимости от значения директивы display_errors.
2. Скрипт в файле с фатальной ошибкой, не относящейся к первому пункту, будет выполняться в штатном режиме до самой ошибки.
3. Наличие в файле фатальной ошибки при display_errors = Off обозначит 500 статус ответа.
4. Не фатальные ошибки, как и следовало ожидать, в контексте возможности исполнения скрипта в целом, на работоспособность не повлияют.

Собственный обработчик ошибок

Для написания собственного обработчика ошибок необходимо знать, что:

• для получения информации о последней произошедшей ошибке существует функция error_get_last();
• для определения собственного обработчика ошибок существует функция set_error_handler(), но фатальные ошибки нельзя «перехватить» этой функцией;
• используя register_shutdown_function(), можно зарегистрировать свою функцию, выполняемую по завершении работы скрипта, и в ней, используя знания из первого пункта, если фатальная ошибка имела место быть, предпринять необходимые действия;
• сообщение о фатальной ошибке в любом случае попадет в буфер вывода;
• воспользовавшись функциями контроля вывода можно предотвратить отображение нежелательной информации;
• при использовании оператора управления ошибками (знак @) функция, определенная в set_error_handler() все равно будет вызвана, но функция error_reporting() в этом случае вернет 0, чем и можно пользоваться для прекращения работы или определения другого поведения своего обработчика ошибок.

Третий пункт поясню: зарегистрированная нами функция при помощи register_shutdown_function() выполнится в любом случае — корректно ли завершился скрипт, либо же был прерван в связи с критичной (фатальной) ошибкой. Второй вариант мы можем однозначно определить, воспользовавшись информацией предоставленной функцией error_get_last(), и, если ошибка все же была, выполнить наш собственный обработчик ошибок.
Продемонстрируем вышесказанное на модифицированном скрипте index.php:

<?php
/**
 * Обработчик ошибок
 * @param int $errno уровень ошибки
 * @param string $errstr сообщение об ошибке
 * @param string $errfile имя файла, в котором произошла ошибка
 * @param int $errline номер строки, в которой произошла ошибка
 * @return boolean
 */
function error_handler($errno, $errstr, $errfile, $errline)
{
    // если ошибка попадает в отчет (при использовании оператора "@" error_reporting() вернет 0)
    if (error_reporting() & $errno)
    {
        $errors = array(
            E_ERROR => 'E_ERROR',
            E_WARNING => 'E_WARNING',
            E_PARSE => 'E_PARSE',
            E_NOTICE => 'E_NOTICE',
            E_CORE_ERROR => 'E_CORE_ERROR',
            E_CORE_WARNING => 'E_CORE_WARNING',
            E_COMPILE_ERROR => 'E_COMPILE_ERROR',
            E_COMPILE_WARNING => 'E_COMPILE_WARNING',
            E_USER_ERROR => 'E_USER_ERROR',
            E_USER_WARNING => 'E_USER_WARNING',
            E_USER_NOTICE => 'E_USER_NOTICE',
            E_STRICT => 'E_STRICT',
            E_RECOVERABLE_ERROR => 'E_RECOVERABLE_ERROR',
            E_DEPRECATED => 'E_DEPRECATED',
            E_USER_DEPRECATED => 'E_USER_DEPRECATED',
        );

        // выводим свое сообщение об ошибке
        echo "<b>{$errors[$errno]}</b>[$errno] $errstr ($errfile на $errline строке)<br />\n";
    }

    // не запускаем внутренний обработчик ошибок PHP
    return TRUE;
}

/**
 * Функция перехвата фатальных ошибок
 */
function fatal_error_handler()
{
    // если была ошибка и она фатальна
    if ($error = error_get_last() AND $error['type'] & ( E_ERROR | E_PARSE | E_COMPILE_ERROR | E_CORE_ERROR))
    {
        // очищаем буффер (не выводим стандартное сообщение об ошибке)
        ob_end_clean();
        // запускаем обработчик ошибок
        error_handler($error['type'], $error['message'], $error['file'], $error['line']);
    }
    else
    {
        // отправка (вывод) буфера и его отключение
        ob_end_flush();
    }
}

// определеяем уровень протоколирования ошибок
error_reporting(E_ALL | E_STRICT);
// определяем режим вывода ошибок
ini_set('display_errors', 'On');
// включаем буфферизацию вывода (вывод скрипта сохраняется во внутреннем буфере)
ob_start();
// устанавливаем пользовательский обработчик ошибок
set_error_handler("error_handler");
// регистрируем функцию, которая выполняется после завершения работы скрипта (например, после фатальной ошибки)
register_shutdown_function('fatal_error_handler');

require 'errors.php';

Не забываем, что ошибки смешанного типа, после объявления собственного обработчика ошибок, стали не фатальными. Плюс к этому, весь вывод скрипта до фатальной ошибки вместе с стандартным сообщением об ошибке будет сброшен.

Вообще, рассмотренный пример обработчика ошибок, обработкой, как таковой, не занимается, а только демонстрирует саму возможность. Дальнейшее его поведение зависит от ваших желаний и/или требований. Например, все случаи обращения к обработчику можно записывать в лог, а в случае фатальных ошибок, дополнительно, уведомлять об этом администратора ресурса.

Полезные ссылки

• Первоисточник: php.net/manual/ru/book.errorfunc.php
• Описание ошибок: php.net/manual/ru/errorfunc.constants.php
• Функции контроля вывода: php.net/manual/ru/ref.outcontrol.php
• Побитовые операторы: php.net/manual/ru/language.operators.bitwise.php и habrahabr.ru/post/134557
• Тематически близкая статья: habrahabr.ru/post/134499

Доброго времени суток, мой дорогой гость.

При использовании локального сервера на компьютере под управлением Windows, будь то Denwer или лбой другой набор, возникает проблема с отображением русских символов и букв при выводе страницы в браузер. Причины этой проблемы могут быть разными, в данной статье я расскажу о некоторых из них и постараюсь помочь с их решением.

Если не отображаются русские символы при обычном выводе через echo, появляются знаки вопроса (?) вместо букв, то проблемой может быть неверно указанная кодировка файла. Стандартная программа блокнот Windows по умолчанию сохраняет файл в кодировке ANSI, в результате чего появляется такая проблема как на картинке.

Решить проблему можно сохранив файл в формате UTF-8, для этого в блокноте достаточно нажать Файл->Сохранить как… и в появившемся окне выбрать тип файла «Все файлы» и выбрать кодировку UTF-8. После чего нажать кнопку сохранить и подтвердить замену файла.

Открываем вновь в браузере и видим, что проблема решена.

Этот способ показан для программы Блокнот Windows, т.к. чаще всего проблема возникает именно с ней у начинающих программистов PHP. Для программирования лучше использовать специальный текстовый редактор (Sublme Text, Notepad++ и др.) или IDE PhpStorm, они по умолчанию работают UTF-8.

Ошибки с русским текстом в базе данных MySQL

Проблема проявляет себя во время сохранения данных в базе данных MySQL. Обычно это происходит из-за того, что пользователь, при создании новой базы данных и таблицы, не выбирает сравнение(кодировку) и она устанавливается по умолчанию как latin1_swedish_ci.

СУБД возвращает ошибку при попытке добавить русский текст в поле записи.

#1366 — Incorrect string value

Чтобы не сталкиваться с такой проблемой необходимо всегда выбирать сравнение utf8_general_ci при создании базы данных, таблиц и столбцов.

Знаки вопроса при выводе данных из базы данных MySQL

Иногда возникает проблема с отображением данных, полученных из базы данных MySQL. Обычно вместо русских символов выводятся знаки вопроса.

Проблема решается путем установления кодировки подключения к базе данных.

Если вы пользуетесь старыми функциями для работы с БД MySQL, то сразу после функций подключения к базе данных необходимо добавить:

mysql_set_charset("utf8");

и при этом советую вам почитать про PDO, так как библиотека для работы с БД MySQL, включающая функции mysql_connect(), mysql_select_db() и прочие уже устарела, а в версии PHP 7 вообще убрана.

Если вы работаете с PDO, то в DSN(способ соединения с БД у PDO) необходимо в параметре charset устанавливать кодировку utf8. Пример соединения с кодировкой:

$ms_host = "localhost"; // Хост
$ms_db = ""; // Имя БД
$charset = "utf8"; // Кодировка соединения
$dsn = "mysql:host=$ms_host;dbname=$ms_db;charset=$charset";

Если ничего не помогает

Попробуйте после подключения к БД добавить mysql_query(«SET NAMES utf8»);

Попробуйте в начале PHP скрипта добавить header(‘Content-Type: text/html; charset=utf8’);

А так же не забывайте о meta-теге между <head> и </head>

<meta charset="utf-8" />

Буду рад, если кому-нибудь помогли данные советы. Вы можете задать вопрос со своей проблемой в комментарии и мы попробуем вместе разобраться. Удачи в устранении ошибок и багов!

За уровень обработки ошибок в PHP отвечает директива error_reporting конфигурационного файла php.ini. Данный параметр определяет типы ошибок, о которых PHP информирует выводом текстового сообщения в окно браузера.

Возможные значения директивы

Вышеуказанные значения (цифровые или символьные) используются для построения битовой маски, которая специфицирует выводимое сообщение об ошибке. Вы можете использовать битовые операции для маскирования определённых типов ошибок. Обратите внимание, что только ‘|’, ‘~’, ‘!’ и ‘\&’ будут понятны в php.ini и что никакие битовые операции не будут понятны в php3.ini.

В PHP 4 значением по умолчанию для error_reporting будет E_ALL & ~E_NOTICE, что означает отображение всех ошибок и предупреждений, которые не имеют уровень E_NOTICE-level. В PHP 3 значение по умолчанию — E_ERROR | E_WARNING | E_PARSE означает то же самое.

Заметьте, однако, что, поскольку константы не поддерживаются в PHP 3 в файле php3.ini, установка error_reporting должна выполняться цифрами; то есть 7 по умолчанию.

Настройка при помощи php.ini

Параметр error_reporting позволяет устанавливать несколько уровней, используя побитовые флаги. К примеру, уровень:

error_reporting = E_ALL & ~E_NOTICE

позволяет выводить все ошибки, за исключением замечаний.

А для того чтобы показывать только ошибки (исключая предупреждения и замечания), директива должна быть настроена так, как показано ниже:

error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR

Настройка при помощи .htaccess

Включаем вывод ошибок в окно браузера и устанавливаем нужный уровень.

<br />
php_flag display_errors On<br />
php_value error_reporting E_ALL<br />

Настройка при помощи PHP

Включаем вывод ошибок в окно браузера и устанавливаем нужный уровень.

<?php
error_reporting(E_ALL);
ini_set("display_error", true);
ini_set("error_reporting", E_ALL);
?>

Ссылки

• Функция error_reporting
• Директива error_reporting файла php.ini

PHP Документация