Php mysql одни знаки вопроса

Вопросы вместо кириллицы при выводе информации из MySQL?

За полдня хождения вокруг да около ничего не помогло. Вот результат запроса «SHOW SESSION VARIABLES «:

Подскажите, пожалуйста, что мне с этим делать, уже горит просто
Хотя бы где ошибку искать, в php (использую pdo подключение) или в phpMyAdmin ковыряться.

Простой 34 комментария

SHOW SESSION VARIABLES вообще не при чем.

в пдо чарсет надо задавать в дсн. без опечаток и отсебятины.

надо оттачивать навык копипасты.

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

FanatPHP, мой код:

Даниил Хачатурян, Даниил, вот Вам два раза сказали что вы кодировку неправильно указываете, что непонятного?)
utf8 — неправильно
utf8mb4 — правильно

Илья, ну вообще и то и то будет работать. utf8 только совсем завернутые смайлики типа какашки не будет показывать

И ради бога, убери этот ужас, который у тебя называется errorHandler. Это не обработчик ошибок, а помойка.

function errorHandler($error) < file_put_contents('errors_log', date('c') . ' ' . $error . PHP_EOL, FILE_APPEND); header('Location: /error.php'); exit; >

FanatPHP, http заголовок выставлял, мета тэги прописывал, при соединении с бд делал SET NAMES utf8, и команды такого рода ответов в гугле — ничего не помогло. Хотинг Максхост кстати

FanatPHP, я даже сделал тествую бд и написал голую страницу где только чтение из бд — всё равно знаки вопросов. Как вообще люди работают с бд на этом хосте я не понимаю.

про заголовки
http заголовок выставлял — выставить мало. надо проверить, выставилось ли оно в итоге.
все остальное — бессмысленная ерунда, не надо ей заниматься
в консоли браузера во вкладке сеть смотришь реальный заголовок. там будет никакой не UTF-8

про ошибку
ты сам не понимаешь что твое «Database connection error» — это полная бессмыслица? Когда у тебя происходит ошибка, база данных тебе пишет, какая именно и в чем конкретно проблема. А ты эту бесценную информацию выкидываешь на помойку.

Кроме того, писать file_put_contents(‘errors_log’) это еще одна бессмыслица. пхп САМ умеет логировать ошибки. Надо ОДИН раз написать в коде ini_set(‘log_errors’,1); и все ошибк будут логироваться САМИ. и выкинуть свой бессмысленный errorHandler туда же на помойку.

FanatPHP, да, я тут забыл заменить на $e->getMessage() остальные места с этим хендлером в порядке. Я создавал его чтобы использовать вне конструкций try catch для записи мелких ошибок, просто решил пока его и в try catch вставить, потом переделаю

Да, и никаких Location: /error.php
По стандарту скрипт который завершился с оибкой, не должен никуда перенаправлять.

Если хочется показать кастомную страницу, то пишешь опять же один раз функцию set_exception_handler и внутри неё делаешь include своей страницв ошибок, а не локейшен.

FanatPHP, я понял, спасибо
Скажи лучше что с макхостом делать? я создал тестовую бд и страницу с подключением к ней — всё равно вопросы в ромбах даёт. Могу даже данные входа дать, попробуешь сам

FanatPHP, заголовки отправились

постой.
я туплю.
если ромбики — то страница действительно утф, а вот текст приходит в однобайтной кодировке.
Такое ощущение что ты данные перекодируешь перед отправкой.

$db= mysqli_connect(«localhost», «root», «», «db»);
//Попробуй так:
$huruf= $db->query(«SET NAMES ‘utf8′»);
$huruf2= $db->query(«SET CHARACTER SET ‘utf8′»);
$huruf3= $db->query(«SET SESSION collation_connection = ‘utf8_general_ci'»);
?>

Да, я уже решил проблему, с помощью SET NAMES utf8 вместе с подбором кодировке в базе
Раньше я делал эти действия отдельно друг от друга.

Но странно что указан у меня в настройках подключения PDO charset, но только сет неймс помог.

Не расскажешь ли, чем отличаются те 3 запроса что ты написал?

Судя по принтскрину, в таблице для разных столбцов используются разные кодировки. Проблема может быть в этом. Не знаю, поможет это в твоем случае, но стоит попробовать:

Сделай дамп базы. Открой его в текстовом редакторе. Глазками посмотри что у тебя в тех полях которые идут умляутами и прочими квадратиками и вопросиками. Попробуй разобраться где какая кодировка образовалась и совпадает ли она с тем, что указано при создании таблиц и полей (вполне подходящий инструмент FAR Manager, в нем можно менять кодировки при просмотре и редактировании. Напиши скрипт, который унифицирует кодировки при создании таблиц и полей, а так же сделает перекодировки значений полей при их заполнении данными. Если данных в табличках не много — все можно даже руками сделать в текстовом редакторе.

После залей этот исправленный дамп на сервер.

Скрипт создания БД сделан в MySQL Workbench, должно быть вроде всё норм.
Но я попробую, спасибо за совет!

Если знаки вопроса простым текстом, то кодировку надо задавать в DSN, как показано здесь

Если знаки вопроса в ромбиках, то это кодировка страницы в браузере, а не БД.
Задаётся либо через default_charset в php.ini либо тупо
header(‘Content-Type: text/html; charset=utf-8’);

Источник

В MySQL знаки вопросов вместо русских букв — решение проблемы с кодировкой

При переносе дампа или после нескольких манипуляций в базе неожиданно появились знаки вопросов в MySQL вместо русских букв? Это известная и распространённая проблема в MySQL старших версий.

Это руководство поможет предпринять быстрые шаги в исправлении ситуации.

Мы рассмотрим конкретные действия для быстрого решения. Обратите внимание на официальное руководство по кодировке в MySQL, чтобы вы смогли разбираться в сути и выполнять рекомендации осознанно.

Исправляем знаки вопросов в MySQL на русские буквы

Воспользуйтесь этими быстрыми рекомендациями, чтобы отобразить русские буквы без знаков вопросов и «крякозябр». Ниже мы привели некоторые уточнения.

1. Дождитесь выполнения соединения с сервером
2. Введите запрос:
   set names кодировка «кодировка» — это параметр кодировки, в которой вы выводите данные страницы на сайте.
   То есть запрос для UTF-8 должен выглядеть так:
   set names utf8 А для Windows-1251 вот так:
   set names cp1251
3. Очень часто параметр «Set Names» не помогает решить проблему кодировке при сортировке по имени, хотя буквы отображаются нормально. Как это исправить, читайте далее.

Обратите внимание, что запросы «set names» по факту не влияют на кодировку, которая используется функцией mysql_real_escape_string . Поэтому рекомендуется применять установку кодировки через mysql_set_charset() вместо запроса «set names». Но даже если вы проигнорируете эту рекомендацию, то для Uta8 и других однобайтных кодировок ничего плохого не последует.

Чтобы не задавать кодировку в каждом скрипте, допишите в my.ini
[mysqld]
init-connect=’SET NAMES utf8′

Исправление проблемы кодировки MySQL, если запрос SET NAMES не помог

Перед тем, как изменить кодировку MySQL, вновь выполните запрос «Set Names», но уже с указанием кодировки таблицы (мы должны её выяснить).

1. Причина кроется в том, что для таблиц настройка в одной кодировке, а данные в них — в другой.
2. Попробуйте начать с простого решения — того же запроса «Set Names», но в кодировке таблицы.
3. Для этого задайте запрос для названия вашей таблицы: show create table `table`
4. Используйте полученную кодировку в запросе «Set Names»:
   SET NAMES кодировка
   «кодировка» — это параметр, который показал результат запроса «Show Create Table» из пункта 3 ( DEFAULT CHARSET=кодировка ).
5. Так вы уберёте «крякозябры» и знаки вопросов из MySQL, настроите правильную отдачу и запись русских букв в данных (главное, чтобы у самой веб-страницы была соответствующая кодировка), но проблему сортировки и поиска пока не решите. Идём дальше.

Теперь, зная кодировку таблицы (например, latin1 ) и имея данные в той же кодировке, мы должны изменить фактическую кодировку данных.

1. Через mysqldump создайте дамп базы данных.
2. Используйте эту команду, в которой вместо слова «кодировка» вставьте параметр, выясненный из кодировки таблицы:
   mysqldump -uUSERNAME -pPASSWORD DB_NAME —allow-keywords —create-options —complete-insert —default-character-set=кодировка —add-drop-table > dump.sql
3. Главное не перепутать кодировку таблиц с кодировкой данных.
4. Проверьте дамп на правильное отображение кодировки уже в формате данных таблицы, а не самой таблицы, как в пункте 3 (то есть уже не latin1 , а utf8 , например). Скопируйте бэкап дампа отдельно.
5. В дампе найдите оператор «Create Database» и проверьте, правильная ли в нём кодировка.
6. Если нет, то исправьте. Тоже самое можно (и лучше сделать) с оператором «Create Table».
7. Используйте эту команду для заливки дампа, где «кодировка» — параметр данных таблицы ( utf8 , а не latin1 из нашего примера):
   mysql -uUSERNAME -pPASSWORD DB_NAME —default-character-set=utf8 < dump.sql
8. На веб-странице сайта найдите функцию mysql_connect , затем mysql_select_db и ниже их размещения добавьте строчку, где «кодировка» — это параметр данных таблицы, а не самой таблицы:
   mysql_query(«SET NAMES кодировка»)

Ничего не помогает, проблема кодировки MySQL так и осталась

Объёмный wiki-раздел по кодировке MySQL составили белорусские коллеги, где вы можете получить исчерпывающее описание процесса правильного создания баз данных и таблиц. Ведь именно в этом процессе кроются все причины возникновения проблемы со знаками вопросов MySQL и «крякозябрами» вместо русских букв.

Также обратите внимание и на эти моменты при работе с базами данных

• правильная ли задана кодировка при создании таблиц (можно использовать любую, но она должна отражать кодировку данных в таблице);
• правильная ли кодировка у скрипта, работающего с базой данных (кодировка веб-страницы и скрипта должна быть одной);
• правильная ли кодировка у самого сайта (у веб-страницы и заголовка «Content-Type» сайта она должна быть общая);
• в правильной ли кодировке сохраняются данные на веб-странице через редактор (выберите в редакторе нужную кодировку, следите за этим).

Компания ZEL-Услуги

Не хотите самостоятельно разбираться в настройке MySQL и оптимизировать работу ИТ-инфраструктуры предприятия? Передайте заботы о программном обеспечении в компанию ИТ-аутсорсинга с полноценным ИТ-аудитом и экспертной поддержкой по любым техническим вопросам и задачам.

Читайте также

Может быть интересно

Источник

Почему вместо кириллицы знаки вопросов?

Всем привет, уже сломал голову. Залил сайт на VPS, у меня появилась проблема, что вся кириллица, что выводится из БД отображается в виде знаков вопроса без ромбиков, при этом, вся БД стоит на utf8, в пыхе тоже прописан utf-8 и у сервера тоже прописан utf-8, в чем проблема? На локалке всё работало классно, а на сервере вот такая подстава

Давно пора запилить аналог вот этого ответа.
А то же ведь раз в три дня один и тот же вопрос — кракозябры, вопросики, ромбики.
И везде одна и та же ересь про «meta charset» в ответах.

Именно в варианте чеклист, чтобы каждый проверял по конкретным пунктам, в которых четко написано, что делать, вместо невнятного мычания «ну у меня там утээф и еще здесь и вот тута»

• Кодировка, которую надо выставлять, называется utf8mb4
• Что там стоит на «всей БД» абсолютно без разницы. Кодировка должна быть указана для таблиц (в отдельных случаях — для поля) при создании. Проверить можно командой SHOW CREATE TABLE table_name

• Должна быть быть выставлена кодировка соединения с БД
  • в PDO через DSN $dbh = new PDO(‘mysql:host=. ;charset=utf8mb4’);
  • в mysqli $mysqli->set_charset(‘utf8mb4’);
  • Либо default_charset = «utf-8» в php.ini.
  • Либо руками в коде header(‘Content-Type: text/html; charset=utf-8’);

  Источник

  Читайте также:  Users list templates html