Какую кодировку выбрать в phpmyadmin
Перейти к содержимому

Какую кодировку выбрать в phpmyadmin

  • автор:

Форум

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

Максим Сообщения: 6022 Зарегистрирован: 11 дек 2010, 20:29

Re: mysql/phpmyadmin нет кодировки utf8_general_ci

В чём ваш вопрос, в том что в MySQL разработчики убрали кодировку utf8_general_ci? Ну они правильно сделали, кодировка имела большие проблемы с сортировкой. Запускайте ваш проект на совместимой старой версии MySQL, раз ему требуется именно такая старая кодировка.

SagePointer Сообщения: 341 Зарегистрирован: 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, вот скриншот из панели моего хостинга

Проблема с кодировками

Здравствуйте. При создание сайта на 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.

Какую кодировку выбрать для базы чтобы можно было сохранять строки на любом языке и не парить себе мозг?

Добавил модель, передаю post данные с кириллицей, save() отрабатывает, но латиница в базу попадает, а от кириллицы пустое место. боюсь предположить, что будет если кто-то напишет на арабском, китайском или хинди. Что делать?

  • Вопрос задан более трёх лет назад
  • 3196 просмотров

8 комментариев

Простой 8 комментариев

sim3x

А изначально в какой кодировке БД была и в какой сейчас? И отдельные таблицы в какой?

a_u_sinitsin

Александр Синицын @a_u_sinitsin Автор вопроса
sim3x, utf8_unicode_ci

Александр Синицын, а откуда текст? сами писали или с файла? чужого сайте? сам файл скрипта в utf8? после соединения с БД указывается кодировка?

в целом если не ошибаютсь utf8 за глаза хватает, проблема только с эмоджи и может неправильно сортировать (order by) некоторые редкие языки.

a_u_sinitsin

Александр Синицын @a_u_sinitsin Автор вопроса

Arik, Делаю api для андроид приложения. Данные отправляю post через phpStorm/Tools/Test RESTFull Web Service

a_u_sinitsin

Александр Синицын @a_u_sinitsin Автор вопроса
Arik, В main-local указано ‘charset’ => ‘utf8’,
если в коде прям указать у какого атрибута кириллицу и сохранить модель?

a_u_sinitsin

Александр Синицын @a_u_sinitsin Автор вопроса
Arik, Из кода пишет
Решения вопроса 1

SerafimArts

Кирилл Несмеянов @SerafimArts
Junior HTML Developer

Стоит везде выставить utf8mb4_unicode_ci (работает точнее при сортироваках и проч.) или utf8mb4_general_ci (чуть быстрее работает, крайне незначительно, так что имеет смысл именно первый вариант).

P.S. Указанные выше utf8_general_ci/utf8_unicode_ci поддерживают лишь половину диапазона utf8, отсюда сохранение, например эмодзи, будет физически невозможным.

P.P.S. Суффикс «ci» означает Case Insensitive (нечувствителность к регистру при поиске и сравнении).

Выбор кодировки для MySQL

Начал свой проект, хочется сразу использовать лучшие наработки. Понял, что одна из utf8_general_ci или utf8_unicode_ci . Склоняюсь к utf8_unicode_ci . Но наткнулся на информацию, что это немного уже устарело и стоит использовать utf8mb4_general_ci и utf8mb4_unicode_ci . Посоветуйте какую кодировку выбрать для БД.

Отслеживать
5,728 3 3 золотых знака 21 21 серебряный знак 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 во всех местах, где это возможно, поможет вам разработать более качественные приложения.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *