Когда использовать utf-8 и когда использовать latin1 в MySQL?

Я знаю, что в MySQL имеет значение по умолчанию латинских типа 1 кодировка и, по-видимому, требуется 1 байт для хранения символа в латинских типа 1 и 3 байта для хранения символа в кодировка UTF-8 - Это верно?

Я работаю на сайт, который я надеюсь, будет использоваться во всем мире. Мне абсолютно необходимо иметь кодировка UTF-8? Или я смогу уйти с использованием latin1?

кроме того, я попытался изменить некоторые таблицы из латинских типа 1 to utf8 в но я получил эту ошибку: Speficief key was too long; max key length is 1000 bytes Кто-нибудь знает решение этой проблемы? И должен ли я действительно решить это или может быть достаточно latin1?

спасибо, Алекс!--10-->

7 ответов


требуется 1 байт для хранения символа в latin1 и 3 байта для хранения символа в utf-8-это правильно?

проходит 1 байт для хранения latin1 характера и 1 до 3 байт для хранения UTF8 символ.

если вы используете только основные латинские символы и знаки препинания в ваших строках (0 to 128 на Unicode), оба набора символов будут занимать одинаковую длину.

кроме того, я пытался измените некоторые таблицы с latin1 на utf8, но я получил эту ошибку:" ключ Speficief был слишком длинным; максимальная длина ключа составляет 1000 байт " кто-нибудь знает решение этого? И должен ли я действительно решить это или может быть достаточно latin1?

если у вас есть столбец VARCHAR(334) и более MyISAM не позволит вам создать индекс на нем, так как есть удаленная возможность столбца занимать больше, чем 1000 байт.

обратите внимание, что ключи такой длины редко бывают полезны. Вы можете создайте префиксный индекс, который будет почти таким же избирательным для любых реальных данных.


как минимум, я бы предложил использовать UTF-8. Ваши данные будут совместимы с любой другой базой данных в настоящее время, так как 90% из них-UTF-8.

Если вы идете с LATIN1 / ISO-8859-1 вы рискуете данные не хранятся должным образом, потому что он не поддерживает международные символы... таким образом, вы можете столкнуться с чем-то вроде левой стороны этого изображения:

enter image description here

Если вы идете с UTF-8, то вам не нужно общаться с этими головные боли.

Что касается вашей ошибки, похоже, вам нужно оптимизировать свою базу данных. Рассматривайте это: http://bugs.mysql.com/bug.php?id=4541#c284415

помогло бы, если бы вы дали особенности на вашей схеме таблицы и столбце для этой проблемы.


Если вы разрешаете пользователям размещать сообщения на своих языках, и если вы хотите, чтобы пользователи из всех стран участвовали, вы должны переключить, по крайней мере, таблицы, содержащие эти сообщения, на UTF-8 - Latin1 охватывает только ASCII и западноевропейские символы. То же самое верно, если вы собираетесь использовать несколько языков для пользовательского интерфейса. См.этот пост для того, чтобы справиться с миграцией.


по моему опыту, если вы планируете поддерживать арабский, русский, азиатские языки или другие, инвестиции в поддержку UTF-8 авансом окупятся по линии. Однако, в зависимости от ваших обстоятельств вы можете быть в состоянии уйти с английский на некоторое время.

Что касается ошибки, у вас, вероятно, есть поле ключа или индекса с более чем 333 символами, максимум, разрешенный в MySQL с кодировкой UTF-8. Смотрите это сообщить об ошибке.


мы сделали приложение с использованием латыни, потому что это было по умолчанию. Но позже нам пришлось изменить все на UTF из-за испанских символов, не невероятно сложно, но нет смысла менять вещи без необходимости.

поэтому короткий ответ просто идет с UTF-8 с самого начала, это избавит вас от проблем позже.


Так как максимальная длина ключа составляет 1000 байт, Если вы используете utf8, то это ограничит вас до 333 символов.

однако MySQL отличается формой Oracle для кодировки. В Oracle вы не можете иметь другой набор символов для столбца, где в MySQL вы можете, поэтому, возможно, вы можете установить ключ к latin1 и другим столбцам в utf8.

наконец, я считаю, что только несуществующая версия 6.0 alpha (ditched, когда Sun купил MySQL) может вместить символы unicode beyound BMP (базовый многоязычный план). Таким образом, в принципе, даже с UTF-8 у вас не будет всех весь набор символов Unicode. На практике это проблема только для редких китайских иероглифов, если это действительно важно для вас.


Я не эксперт, но я всегда понимал, что UTF-8 на самом деле является 4-байтовым широким набором кодировок, а не 3. И, как я понимаю, реализация MySQL utf8_unicode_ci обрабатывает только 3-байтовый широкий набор кодировок...

Если вы хотите полную 4-байтовую кодировку UTF-8, вам нужно использовать кодировку utf8mb4_unicode_ci для вашей базы данных/таблиц MySQL.