Форум
mysql/phpmyadmin нет кодировки utf8_general_ci
Вопросы по работе с Apache, PHP, MySQL и т.д.
Первое новое сообщение • 4 сообщения • Страница 1 из 1
jenokizm Сообщения: 8 Зарегистрирован: 27 ноя 2017, 20:22
mysql/phpmyadmin нет кодировки utf8_general_ci
Привет! Работал ранее на os 5.3.7 с активированным mysql 8 и phpmyadmin вашим, кодировка была на месте. Сегодня дошли руки начисто самую свежую версию поставить 5.4.3 поставил. Выставил также mysql 8, после захожу в phpmyadmin и пытаюсь создать базы чтобы потом восстановить свои дампы, но сейчас в выборе кодировки нет utf8_general_ci и самого раздела utf8
ps я понимаю что для новых проектов лучше использовать utf8mb4_0900_ai_ci я так и делаю. Но у меня все еще есть старые проекты которые должны работать на utf8_general_ci
Максим Сообщения: 6024 Зарегистрирован: 11 дек 2010, 20:29
Re: mysql/phpmyadmin нет кодировки utf8_general_ci
В чём ваш вопрос, в том что в MySQL разработчики убрали кодировку utf8_general_ci? Ну они правильно сделали, кодировка имела большие проблемы с сортировкой. Запускайте ваш проект на совместимой старой версии MySQL, раз ему требуется именно такая старая кодировка.
SagePointer Сообщения: 342 Зарегистрирован: 27 ноя 2020, 20:52
Re: mysql/phpmyadmin нет кодировки utf8_general_ci
jenokizm писал(а): ↑ 18 сен 2022, 16:17 ps я понимаю что для новых проектов лучше использовать utf8mb4_0900_ai_ci я так и делаю. Но у меня все еще есть старые проекты которые должны работать на utf8_general_ci
Всё на месте, просто называется это сравнение явно: utf8mb3_general_ci для 3-байтовых и utf8mb4_general_ci для 4-байтовых.
Менять в старом коде ничего не надо, старый utf8_general_ci является алиасом для utf8mb3_general_ci и корректно обрабатывает, если он указан в тексте дампа при импорте, например. Но в большинстве случаев ничего не должно сломаться даже и при переходе на новую кодировку, она обратно совместима, можно так выразиться, разве что в редких случаях индексы 4-байтные могут не влезть в ограничение на длинных полях. А при переименовании из «utf8» в явный utf8mb3 ничего вообще не может сломаться, это только лишь названия одного и того же.
jenokizm Сообщения: 8 Зарегистрирован: 27 ноя 2017, 20:22
Re: mysql/phpmyadmin нет кодировки utf8_general_ci
Максим писал(а): ↑ 18 сен 2022, 16:30 В чём ваш вопрос, в том что в MySQL разработчики убрали кодировку utf8_general_ci?
В том числе и в этом. Я бы понял если бы это сделали в мажорном релизе, но никак не ожидал в минорном обновлении и не смог найти в интернете информации по этому поводу. Я как использовал MySQL 8.0 так и продолжаю его использовать.
SagePointer писал(а): ↑ 19 сен 2022, 11:43 старый utf8_general_ci является алиасом для utf8mb3_general_ci
Спасибо большое! Разобрался. Да это работает для меня.
Что касается перевода всех сайтов на utf8mb4_0900_ai_ci даже если захочу не имею такой возможности. На хостинге бегет до сих пор нет MySQL 8.0, вот скриншот из панели моего хостинга
Выбор кодировки для MySQL
Начал свой проект, хочется сразу использовать лучшие наработки. Понял, что одна из utf8_general_ci или utf8_unicode_ci . Склоняюсь к utf8_unicode_ci . Но наткнулся на информацию, что это немного уже устарело и стоит использовать utf8mb4_general_ci и utf8mb4_unicode_ci . Посоветуйте какую кодировку выбрать для БД.
Отслеживать
5,746 3 3 золотых знака 22 22 серебряных знака 44 44 бронзовых знака
задан 13 дек 2017 в 11:15
320 2 2 золотых знака 4 4 серебряных знака 14 14 бронзовых знаков
stackoverflow.com/a/766996/5441700 Итог — используйте utf8mb4_unicode_ci . С базой у вас тоже должно быть установлено соединение в режиме utf8mb4 .
13 дек 2017 в 11:36
Спасибо, понял.
13 дек 2017 в 11:50
Плюсую utf8mb4, современные движки постепенно переходят на неё. Например, в Laravel 5.4 перешли на utf8mb4 и указали, что она «поддерживает хранение эмодзи в базе данных». Куда ж в современном мире без смайликов-то, а? )) Даже на гитхабе их ввели. А вопрос очень популярный, переведу-ка я пожалуй его на русский.
13 дек 2017 в 13:01
ассоциация: stackoverflow.com/a/766996/5441700
13 дек 2017 в 13:06
1 ответ 1
Сортировка: Сброс на вариант по умолчанию
Обе эти кодировки ( utf8_general_ci и utf8_unicode_ci ) работают с символами UTF-8, разница в сортировке строк и их сравнении.
Заметьте: начиная с MySQL версии 5.5.3 предпочтительнее использовать utf8mb4 , а не utf8 . Они обе являются кодировками UTF-8, но более старая uft8 имеет специфические для MySQL ограничения символов UTF-8 выше 0xFFFD.
Сравнение по отдельным параметрам.
Точность
- utf8mb4_unicode_ci основана на стандарте Unicode по сортировке и сравнению строк, который более точно сортирует строки в широком диапазоне языков/алфавитов.
- utf8mb4_general_ci не реализует все правила сортировки Unicode, что
зачастую влечёт нежелательный результат в некоторых ситуациях для
определённых языков/символов.
Производительность
- utf8mb4_general_ci быстрее в сравнении и сортировке, потому что она содержит большое число оптимизаций. На современных серверах, это приращение скорости будет всегда, но незначительно. Оптимизации были задуманы во время, когда мощности серверов были значительно меньше сегодняшних.
- utf8mb4_unicode_ci , которое использует правила Unicode для сортировки и сравнения, по-честному использует более сложные алгоритмы для точной сортировки для широкого числа языков и при использовании спецсимволов. Эти правила принимают во внимание специфические соглашения для языка, не всегда сортировки идёт в соответствии с «алфавитным» порядком.
В принципе, для группы т.н. «европейских» языков нет особой разницы между строгой сортировкой по Unicode и упрощенной сортировкой utf8mb4_general_ci , но несколько различий:
Например, Unicode сортирует «ß» так же как и «ss», и «Œ» как «OE» так же как это делают люди, в то время как utf8mb4_general_ci сортирует их как отдельные символы (предположительно как «s» и «e» соответственно).
Некоторые символы Unicode определены как незначимые, что означает, что они не должны влиять на порядок сортировки и сравнение должно переходить к следующему символу. И utf8mb4_unicode_ci обрабатывает эти символы корректно.
Для группы неевропейских языков, таких как азиатские языки или языки с другим алфавитом существует гораздо больше различий между сортировкой Unicode и упрощённой сортировкой в utf8mb4_general_ci . То, насколько подходит utf8mb4_general_ci будет зависеть от конкретного языка. Для некоторых языков разница может быть сильно недостаточной.
Что же использовать?
Практически нет смысла предпочитать utf8mb4_general_ci по соображениям производительности, потому что на современных процессорах разница не будет играть роль «бутылочного горлышка».
Какая-то разница в производительности может быть в каких чрезмерно специализированных ситуациях и если это ваш случай вы должны знать об этом.
Раньше некоторые специалисты рекомендовали использовать utf8mb4_general_ci кроме тех случаев, когда необходима точная сортировка и это важнее проседания производительности. Сегодня больше обращают внимание на точную поддержку интернационализации, чем на незначительное проседание производительности.
И ещё я добавлю, что даже если ваше приложение должно поддерживать только английский язык — в нём может оказаться ситуация, когда в приложении будут вводиться имена людей и часто вводимые имена должны содержать символы, которые встречаются в других языках, поэтому так важно использовать корректные правила сортировки. Использование Unicode во всех местах, где это возможно, поможет вам разработать более качественные приложения.
Проблема с кодировками
Здравствуйте. При создание сайта на Denwer возникла необходимость импорта csv файла в MySQL базу данных. Для этих нужд выбрал программу SQL Manager 2010 for MySQL. Но как бы я не менял кодировку исходного файла в базу данных все-равно импортируются какие-то крякозябры. Как сделать эти крякозябры читабельны? В php и MySQL, к сожалению новичок. Заранее спасибо за ответ!
2 Ответ от Hanut 2011-10-18 12:16:15
Re: Проблема с кодировками
Я бы посоветовал использовать для импорта CSV данных phpMyAdmin, для чего следует создать таблицу с необходимым количеством полей в соответствии с CSV данными и их кодировкой, перейти на страницу импорта, выбрать формат импортируемого файла CSV и, при необходимости, настроить параметры импорта.
3 Ответ от 1Ruslan1 2011-10-18 13:43:08 (изменено: 1Ruslan1, 2011-10-18 13:44:42)
Re: Проблема с кодировками
Спасибо большое за совет. Но мне необходимо импортировать данные в раннее созданные таблицы (импортирую для virtuemart 2.0.0). Введя запрос SHOW VARIABLES LIKE ‘char%’ получил следующие данные:
character_set_client utf8
character_set_connection utf8
character_set_database utf8
character_set_filesystem binary
character_set_results utf8
character_set_server cp1251
character_set_system utf8
character_sets_dir \usr\local\mysql-5.1\share\charsets\
Пробовал импортировать csv файл в кодировках UTF-8, UTF-8 без BOM. Результат — крякозябры на сайте, в phpmyadmin, MySQL Manager. Пробовал импортировать в ANSI. Результат — крякозябры на сайте, в phpmyadmin, а в MySQL Manager все прекрасно читается. Пробовал экспортировать читабельные кирилические строки из базы и их же импортировать — с ними та же история. Даже не знаю что уже делать.
4 Ответ от Hanut 2011-10-18 14:17:03
Re: Проблема с кодировками
1Ruslan1 сказал:
Пробовал импортировать в ANSI. Результат — крякозябры на сайте, в phpmyadmin, а в MySQL Manager все прекрасно читается.
Это хорошо, значит так и импортируйте. Получается таблицы у вас должны быть в кодировке cp1251, а страницы сайта в windows-1251.
Чтобы на сайте кириллица выводилась нормально, надо найти конфигурационную директиву скрипта, с помощью которой можно установить кодировку соединения с MySQL, и прописать в ней cp1251. Еще один момент — это обязательно надо создать отдельного пользователя MySQL, наделить его необходимыми привилегиями (не выбирайте привилегии администрирования) на базу данных скрипта и прописать в конфигурации скрипта подключение этим пользователем. Нельзя подключать скрипт под root.
5 Ответ от 1Ruslan1 2011-10-18 14:57:37
Re: Проблема с кодировками
Огромное Вам спасибо. В кодировке соединения с MySQL установил cp1251 и все сразу заработало!
6 Ответ от seofantom 2011-10-19 12:48:59
Re: Проблема с кодировками
Дабы не создавать новую тему. Простые вопросы от чайника.
Собрался переносить несколько сайтов с одного хостинга на другой. Делаю дамп базы — спрашивает кодировку. Импортируешь на другом хостинге — то же. Отсюда вопросы:
1. В какой кодировке делать дамп? От чего это зависит? Где смотреть? И вообще, не понимаю, у базы наверное, уже есть какая-то кодировка, а дамп это просто заархивированная копия (или я не прав), зачем при создании дампа кодировку уточнять.
2. Где в базе смотреть кодировку? Она там указана во многих местах.
3. Предполагаю, что при импорте базы необходимо указать ту же кодировку, что и при создании дампа. Однако, если у меня есть дамп базы, который делал не я, какую кодировку ставить в phpmyadmin при импорте? От чего это зависит и где смотреть?
7 Ответ от Hanut 2011-10-19 13:27:54
Re: Проблема с кодировками
seofantom сказал:
В какой кодировке делать дамп?
Последние версии phpMyAdmin не будут спрашивать необходимую кодировку дампа и всегда экспортируют в utf8, в независимости от данных, они будут предварительно перекодированы. Это самый лучший вариант, который не вызовет проблем при импорте, но в этом случае необходимо на странице импорта выбрать кодировку файла utf8, опять-таки независимо от того в какой кодировке были таблицы.
seofantom сказал:
Где в базе смотреть кодировку? Она там указана во многих местах.
Именно по той причине, что в базе данных могут находиться таблицы с различной кодировкой, и даже разной кодировкой полей, дамп необходимо создавать в utf8, в этом случае проблем с переносом не будет.
seofantom сказал:
Однако, если у меня есть дамп базы, который делал не я, какую кодировку ставить в phpmyadmin при импорте? От чего это зависит и где смотреть?
По умолчанию, в phpMyAdmin будет импорт файла в кодировке utf8, что является рекомендуемым способом переноса данных. Менять кодировку вручную необходимо только в том случае, если phpMyAdmin не смог импортировать данные, или импортировал их в искаженном виде. Узнать кодировку файла дампа можно открыв его в текстовом редакторе, например в Notepad++, в статусной строке которого будет указано ANSI или UTF8. ANSI таблица для хранения кириллицы равнозначна кодировке windows-1251.
Помощь
Проблемы с кодировками MySQL могут возникать для версий 4.1 и выше, поскольку для них введена возможность задания разной кодировки для разных уровней иерархии базы данных (сервер, база данных, таблица, столбец) и отдельно для соединения сервера с клиентом. По умолчанию MySQL имеет кодировку latin1 на всех уровнях.
Кодировка, в которой хранятся данные на сервере MySQL, должна совпадать с кодировкой самих данных. Например, для русских символов используется кодировка cp1251. Если в таблице будут храниться записи русскими буквами, то и кодировка этой таблицы должна быть задана cp1251, иначе отображаться будут не русские символы, а знаки вопроса или другие знаки.
При создании баз данных сразу указывайте кодировку для хранения символов, поскольку в случае отсутствия явно заданной кодировки будет использовано значение по умолчанию (latin1). Например, создавайте базу данных командой:
create database `my-db` default charset cp1251;
Кодировка соединения сервера с клиентом устанавливает, в каком виде будут передаваться данные между ними. Например, если в скрипте на сайте используются русские символы, то при обращении сайта к базе данных MySQL должен правильно распознать эти символы, чтобы корректно выполнить скрипт. Если кодировка соединения использует значение по умолчанию latin1, то русские символы сервер баз данных не сможет правильно распознать, следовательно, скрипт выполнится с ошибкой.
Установите нужную вам кодировку соединения сразу после подключения к серверу MySQL запросом:
set names cp1251
Существует ряд клиентов, которые не могут установить нужную кодировку, имеют свою собственную. Для подобных случаев внесите в файл my.cnf в секцию [mysqld] строку:
set init_connect="set names cp1251" где cp1251 – это нужная вам кодировка.
В этом случае сервер выполнит команду «set names cp1251» сразу после соединения с клиентом и установит указанную в запросе кодировку.
Самые распространенные в России кодировки следующие:
utf8, cp866 (DOS), cp1251 (Windows), koi8r
Установка и использование на всех уровнях сервера баз данных одинаковой кодировки устраняет 90% проблем с кодировкой в MySQL.
Как русифицировать MySQL?
Внесите следующие изменения в файл my.cnf:
[client] default-character-set=cp1251 [mysqld] character-set-server=cp1251 collation-server=cp1251_general_ci init-connect = "set names cp1251"
Перезапустите MySQL сервер.