Форум
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
Максим Сообщения: 6032 Зарегистрирован: 11 дек 2010, 20:29
Re: mysql/phpmyadmin нет кодировки utf8_general_ci
В чём ваш вопрос, в том что в MySQL разработчики убрали кодировку utf8_general_ci? Ну они правильно сделали, кодировка имела большие проблемы с сортировкой. Запускайте ваш проект на совместимой старой версии MySQL, раз ему требуется именно такая старая кодировка.
SagePointer Сообщения: 359 Зарегистрирован: 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 или utf8mb4 (utf8mb4_general_ci, utf8mb4_unicode_ci или utf8mb4_0900_ai_ci). Чем они отличаются, как расшифровываются и возможные ошибки
02.07.21 ИТ / Базы данных 28531
При настройке подключения к базе данных (БД) может возникнуть затруднение при выборе кодировки БД. Обычно предлагается целый список кодировок, а точнее сопоставлений (сравнений или наборов символов) и в каждой версии СУБД предлагаемая кодировка может отличаться.
Например, ранее по умолчанию предлагался набор utf8_general_ci. Пользователь может не знать, какая кодировка используется, так как выбор может происходить автоматически при установки готовых веб-приложений. Кодировка может применяться по умолчанию при создании базы данных вручную при помощи, например, phpMyAdmin. Выбранная кодировка распространяется на все таблицы БД и это влияет на то, как будут обрабатываться данные при запросах. Например, может обнаружиться, что при выборке данных не учитывается регистр или, не сохраняются некоторые символы из других языков и прочие объекты (смайлы и т.д.).
Какую кодировку выбрать для БД и таблиц? Для большинства проектов рекомендуется выбирать из подмножества кодировок, относящихся к utf8. Но здесь есть отличия в названиях сопоставлений. Сопоставления utf8 являются 3-ех байтными, для простоты у них не указывается mb3. Обычная utf8 имеет специфичные ограничения MySQL, которые не позволяют использовать символы выше 0xFFFD.
Для старых приложений возможно стоит использовать utf8_general_ci, для новых – utf8mb4_general_ci, utf8mb4_unicode_ci или utf8mb4_0900_ai_ci. Предпочтительным вариантом является не general, а unicode. Отличаются они тем, что utf8mb4_general_ci немного быстрее при выполнении сортировки, но могут возникать проблемы с сортировкой для некоторых языков, в то время как utf8mb4_unicode_ci не имеет подобного недостатка.
Как расшифровываются названия кодировок? Рассмотрим на примере utf8mb4_0900_ai_ci. Здесь:
– utf8 обозначает кодировку;
– mb4 обозначает версию или сколько байт используется в обработке данных для одного символа. Если не указано, то обычно подразумевается mb3;
– 0900 обозначает версию алгоритма сопоставления Unicode (UCA), на которой базируется сопоставление. Если не указано, то обычно подразумевается версия 4.0.0;
– ai обозначает нечувствительность к диакритическим знакам (например, древнегреческие ᾱ, ᾰ). Если не указано, подразумевается ai или as в зависимости от следующей части в имени сравнения, то есть ai для ci и as для cs;
– ci обозначает нечувствительность к регистру, означает, что не будет разницы между строчными и заглавными символами в запросах к БД. Существуют также версии cs, которые являются чувствительными к регистру.
Различные ошибки и предупреждения можно увидеть в отчете используемой системы. Там обычно предлагается перейти на использования современных кодировок из комплекта utf8mb4. Например, в Drupal в отчете состояния можно увидеть строку:
Database 4 byte UTF-8 support – Отключено. 4 byte UTF-8 for mysql is disabled. See the documentation on adding 4 byte UTF-8 support for more information.
Это означает, что система рекомендует использовать новые 4-ех байтные кодировки взамен старых из коллекции utf8.
При написании программного кода может возникать ошибка вида: Unknown collation: ‘utf8mb4_0900_ai_ci’ (Неизвестное сопоставление: ‘utf8mb4_0900_ai_ci’). Это в большинстве случае означает отсутствие требуемой кодировки на сервере баз данных. Например, utf8mb4_0900_ai_ci – это новое сопоставление, доступное только начиная с MySQL 8.0. Также ошибка может появиться в случае применения кодировки, предназначенной для MySQL в другой СУБД, например, в MariaDB. Наборы кодировок различаются от версии к версии, а также для разных СУБД.
В чём разница между кодировками utf8_general_ci, utf8_unicode_ci, utf8mb4_general_ci, utf8mb4_unicode_ci. Какую кодировку выбрать для базы данных MySQL
Начиная с MySQL 5.5.3 вы должны использовать utf8mb4, а не utf8. Обе эти группы относятся к кодировке UTF-8, но более старая utf8 имеет специфичные для MySQL ограничения, не дающие использовать символы, пронумерованные выше 0xFFFD.
Таким образом, больше не нужно использовать ни utf8_general_ci, ни utf8_unicode_ci.
Что касается новых версий кодировки utf8mb4_general_ci и utf8mb4_unicode_ci. То предпочтительной является unicode, а не general. Вариант utf8mb4_general_ci будет чуть более быстрым при сортировке (в настоящее время это уже неактуально), но имеет проблемы с сортировкой в определённых языках. Кодировка utf8mb4_unicode_ci лишена этих недостатков.
Итак, в настоящее время для баз данных и таблиц MySQL рекомендуется использовать кодировку utf8mb4_unicode_ci.
Совет: для сохранения места с utf8mb4, используйте VARCHAR вместо CHAR. В противном случае MySQL будет резервировать четыре байта для каждого символа в стобце CHAR CHARACTER SET utf8mb4, поскольку это максимально возможная длина. Например, MySQL должна зарезервировать 40 байт для столбца CHAR(10) CHARACTER SET utf8mb4.
Примечание: точнее utf8mb4_unicode_ci не совсем кодировка, в терминах MySQL это называется COLLATION («сравнение») и включает в себя набор символов, а также правила сравнения и сортировки. То есть utf8mb4_unicode_ci это COLLATION, а utf8mb4 это набор символов, а UTF-8 это уже и есть кодировка переменной длины.
Связанные статьи:
- PHP не отображает эмодзи из базы данных MySQL / MariaDB (РЕШЕНО) (61.3%)
- Ошибка «ERROR 1366 (22007): Incorrect string value» в MySQL / MariaDB (РЕШЕНО) (61.3%)
- Решение проблемы с ошибкой mysqldump: Couldn’t execute ‘SHOW VARIABLES LIKE ‘gtid\_mode»: Table ‘performance_schema.session_variables’ doesn’t exist (1146) (51.7%)
- Как импортировать и экспортировать базы данных в MySQL или MariaDB (51.7%)
- Как установить веб-сервер Apache с PHP 7, MariaDB/MySQL и phpMyAdmin (LAMP) на Ubuntu (51.7%)
- Как переименовать таблицу в phpMyAdmin и MySQL (RANDOM — 51.7%)
Что правильнее utf8_general_ci или utf8_unicode_ci ?
Подскажите, в какой кодировке в utf8_general_ci или в utf8_unicode_ci будет меньше проблем и в чем различия между этими двумя кодировками?
Все хвалят utf8_unicode_ci , а чем utf8_general_ci хуже?
- Drupal5
- Блог
- Войдите или зарегистрируйтесь, чтобы отправлять комментарии
Комментарии
blackvl@drupal.org 7 мая 2007 в 12:40
Это НЕ КОДИРОВКА, это способ СРАВНЕНИЯ слов и букв.
http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html
MySQL implements the utf8_unicode_ci collation according to the Unicode Collation Algorithm (UCA) described at http://www.unicode.org/reports/tr10/. The collation uses the version-4.0.0 UCA weight keys: http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt. The following discussion uses utf8_unicode_ci, but it is also true for ucs2_unicode_ci.
Currently, the utf8_unicode_ci collation has only partial support for the Unicode Collation Algorithm. Some characters are not supported yet. Also, combining marks are not fully supported. This affects primarily Vietnamese, Yoruba, and some smaller languages such as Navajo.
The most significant feature in utf8_unicode_ci is that it supports expansions; that is, when one character compares as equal to combinations of other characters. For example, in German and some other languages ‘ß’ is equal to ‘ss’.
utf8_general_ci is a legacy collation that does not support expansions. It can make only one-to-one comparisons between characters. This means that comparisons for the utf8_general_ci collation are faster, but slightly less correct, than comparisons for utf8_unicode_ci.
For example, the following equalities hold in both utf8_general_ci and utf8_unicode_ci:
A difference between the collations is that this is true for utf8_general_ci:
Whereas this is true for utf8_unicode_ci:
MySQL implements language-specific collations for the utf8 character set only if the ordering with utf8_unicode_ci does not work well for a language. For example, utf8_unicode_ci works fine for German and French, so there is no need to create special utf8 collations for these two languages.
utf8_general_ci also is satisfactory for both German and French, except that ‘ß’ is equal to ‘s’, and not to ‘ss’. If this is acceptable for your application, then you should use utf8_general_ci because it is faster. Otherwise, use utf8_unicode_ci because it is more accurate.
utf8_swedish_ci, like other utf8 language-specific collations, is derived from utf8_unicode_ci with additional language rules. For example, in Swedish, the following relationship holds, which is not something expected by a German or French speaker:
The utf8_spanish_ci and utf8_spanish2_ci collations correspond to modern Spanish and traditional Spanish, respectively. In both collations, ‘ñ’ (n-tilde) is a separate letter between ‘n’ and ‘o’. In addition, for traditional Spanish, ‘ch’ is a separate letter between ‘c’ and ‘d’, and ‘ll’ is a separate letter between ‘l’ and ‘m’
- Войдите или зарегистрируйтесь, чтобы отправлять комментарии
- Реакции
Очень короткий перевод(некогда):
Разница между utf8_general_ci и utf8_unicode_ci, в том, что utf8_unicode_ci поддерживает expansions, то есть сопоставление одного символа нескольким (например — в Германии ß = ss ).
- Войдите или зарегистрируйтесь, чтобы отправлять комментарии
- Реакции
по сообщениям синоптиков, utf8_general_ci быстрее, но при сортировке менее точен, utf8_unicode_ci более правильный, поддерживает расширения, но медленнее. Так что если сайт только на русском/английском, то utf8_general_ci — ваш правильный выбор.
- Войдите или зарегистрируйтесь, чтобы отправлять комментарии
- Реакции
blackvl@drupal.org 7 мая 2007 в 12:50
Да, конечно, если в языке нет таких хитрых букв как в немецком.
- Войдите или зарегистрируйтесь, чтобы отправлять комментарии
- Реакции