Кто-нибудь знает, почему latin1_swedish используется по умолчанию для MySQL. Мне кажется, что UTF-8 будет более совместим, верно?
Значения по умолчанию обычно выбираются потому, что они являются лучшим универсальным выбором, но в данном случае, похоже, они этого не сделали.
Насколько я вижу, latin1 был набором символов по умолчанию в предмультибайтовые времена, и похоже, что это было продолжено, вероятно, по причинам обратной совместимости (например, для более старых операторов CREATE, которые не указывали сопоставление).
Из здесь:
Что сделал 4.0
MySQL 4.0 (и более ранние версии) поддерживали только то, что составляло комбинированное понятие набора символов и сортировки с однобайтовыми кодировками символов, которые были указаны на уровне сервера. По умолчанию было
latin1, что соответствует набору символов latin1 и сопоставлениюlatin1_swedish_ciв MySQL 4.1.
Что касается того, почему шведский, я могу только догадываться, что это потому, что MySQL AB является/был шведским. Я не вижу никакой другой причины для выбора этой сортировки, она имеет некоторые особенности сортировки (я думаю, ÄÖÜ идет после Z), но они и близко не соответствуют международному стандарту.
latin1 — это набор символов по умолчанию. В MySQL latin1 совпадает с набором символов Windows cp1252. Это означает, что он такой же, как официальный ISO 8859-1 или IANA (Internet Assigned Numbers Authority) latin1, за исключением того, что IANA latin1 рассматривает кодовые точки между 0x80 и 0x9f как «неопределенные», тогда как cp1252 и, следовательно, MySQL latin1 присваивают символы для тех должностей.
от
http://dev.mysql.com/doc/refman/5.0/en/charset-we-sets.html
Может помочь вам понять, почему.
latin1 символах. Конечно, это может относиться только к прошлому. было не есть...
- person ebyrob; 31.07.2017
Использование однобайтовой кодировки имеет некоторые преимущества перед многобайтовой кодировкой, например. длина строки в байтах равна длине этой строки в символах. Поэтому, если вы используете такие функции, как SUBSTRING, интуитивно непонятно, имеете ли вы в виду символы или байты. Также по тем же причинам требуется довольно большое изменение внутреннего кода для поддержки многобайтовых кодировок.
Большинство странных особенностей такого рода имеют историческое значение. Они сделали это давно, и теперь они не могут изменить это, не сломав какое-то приложение в зависимости от этого поведения.
Возможно, тогда UTF8 не был популярен. Или, возможно, MySQL не поддерживал наборы символов, в которых несколько байтов кодируют символ.
Чтобы уточнить, почему не utf8, и объяснить ошибку, не упомянутую в другом месте в этой теме, имейте в виду, что есть ошибка с mysql utf8. Это не utf8! Mysql существует уже давно, еще до появления utf8. Как объяснялось выше, вероятно, именно поэтому он не используется по умолчанию (обратная сопоставимость и ожидания от стороннего программного обеспечения).
В то время, когда utf8 был новым и редко использовался, похоже, разработчики mysql добавили базовую поддержку utf8, неправильно используя 3 байта памяти. Теперь, когда он существует, они решили не увеличивать его до 4 байтов и не удалять. Вместо этого они добавили utf8mb4 multi byte 4, что является реальным 4 байтом utf8.
Важно, чтобы любой, кто переносит базу данных mysql на utf8 или создает новую, знал, что нужно использовать utf8mb4. Для получения дополнительной информации см. https://adamhooper.medium.com/in-mysql-never-use-utf8-use-utf8mb4-11761243e434
