Форум
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 комментариев
А изначально в какой кодировке БД была и в какой сейчас? И отдельные таблицы в какой?
Александр Синицын @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
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 во всех местах, где это возможно, поможет вам разработать более качественные приложения.