Как изменить кодировку базы данных MySQL?
Если информация из базы данных на сайте отображается некорректно, то может потребоваться изменить кодировку всех таблиц базы данных, рассмотрим как это сделать. MySQL может содержать сотни таблиц, поэтому рекомендуем для оперативной смены кодировки выполнить следующие действия:
1. Откройте phpMyAdmin и выберите из списка нужную базу данных.
2. Откройте раздел SQL. (В столбце сравнение показана кодировка сопоставления)
3. Скопируйте запрос, представленный ниже, вставьте его в окно SQL-запроса и измените «нужная_кодировка», «сопоставление» и «имя_базы» на кодировку, которая вам требуется, кодировку сопоставления и имя базы соответственно. Далее нажмите кнопку «Вперед».
SELECT CONCAT(‘ALTER TABLE `’, t.`TABLE_SCHEMA`, ‘`.`’, t.`TABLE_NAME`, ‘` CONVERT TO CHARACTER SET нужная_кодировка COLLATE сопоставление;’) as sqlcode
FROM `information_schema`.`TABLES` t
WHERE 1
AND t.`TABLE_SCHEMA` = ‘имя_базы’
ORDER BY 1
4. В ответе появится список запросов для смены кодировки каждой таблицы. Во вкладке параметры выберите пункт «Полные тексты» и нажмите «Вперед».
5. Скопируйте запросы, которые появились.
6. Вернитесь в раздел SQL и вставьте в окно запроса скопированные данные.
7. Нажмите кнопку «Вперед». Кодировка во всех таблицах базы данных успешно изменена.
Ознакомиться с выгодной линейкой тарифов виртуального хостинга можно на нашем сайте.
Все способы
© 2009–2024 «HANDYHOST.RU» 8-800-505-68-01
- Услуги
- Хостинг сайтов
- Домены
- Конструктор сайтов
- Linux VPS / Windows VPS
- Выделенные серверы
- SSL сертификаты
- Клиентам
- Контакты
- О компании
- Акции
- Оборудование
- Партнерская программа
- Поддержка
- Способы оплаты
- Регламент
- Документы
- Справка
Какую кодировку выбрать для базы чтобы можно было сохранять строки на любом языке и не парить себе мозг?
Добавил модель, передаю post данные с кириллицей, save() отрабатывает, но латиница в базу попадает, а от кириллицы пустое место. боюсь предположить, что будет если кто-то напишет на арабском, китайском или хинди. Что делать?
- Вопрос задан более трёх лет назад
- 3298 просмотров
8 комментариев
Простой 8 комментариев
А изначально в какой кодировке БД была и в какой сейчас? И отдельные таблицы в какой?
Александр Синицын @a_u_sinitsin Автор вопроса
sim3x, utf8_unicode_ci
Александр Синицын, а откуда текст? сами писали или с файла? чужого сайте? сам файл скрипта в utf8? после соединения с БД указывается кодировка?
в целом если не ошибаютсь utf8 за глаза хватает, проблема только с эмоджи и может неправильно сортировать (order by) некоторые редкие языки.
Александр Синицын @a_u_sinitsin Автор вопроса
Arik, Делаю api для андроид приложения. Данные отправляю post через phpStorm/Tools/Test RESTFull Web Service
Александр Синицын @a_u_sinitsin Автор вопроса
Arik, В main-local указано ‘charset’ => ‘utf8’,
если в коде прям указать у какого атрибута кириллицу и сохранить модель?
Александр Синицын @a_u_sinitsin Автор вопроса
Arik, Из кода пишет
Решения вопроса 1
Кирилл Несмеянов @SerafimArts
Senior Notepad Reader
Стоит везде выставить utf8mb4_unicode_ci (работает точнее при сортироваках и проч.) или utf8mb4_general_ci (чуть быстрее работает, крайне незначительно, так что имеет смысл именно первый вариант).
P.S. Указанные выше utf8_general_ci/utf8_unicode_ci поддерживают лишь половину диапазона utf8, отсюда сохранение, например эмодзи, будет физически невозможным.
P.P.S. Суффикс «ci» означает Case Insensitive (нечувствителность к регистру при поиске и сравнении).
Форум
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
Максим Сообщения: 6025 Зарегистрирован: 11 дек 2010, 20:29
Re: mysql/phpmyadmin нет кодировки utf8_general_ci
В чём ваш вопрос, в том что в MySQL разработчики убрали кодировку utf8_general_ci? Ну они правильно сделали, кодировка имела большие проблемы с сортировкой. Запускайте ваш проект на совместимой старой версии MySQL, раз ему требуется именно такая старая кодировка.
SagePointer Сообщения: 347 Зарегистрирован: 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 во всех местах, где это возможно, поможет вам разработать более качественные приложения.