Работа MySQL со строками

Начиная с версии 4.0, сервер MySQL поддерживает преобразование
шифровок знаков. Эта статья ведает о том, что такое
шифровки, сравнения и о том, как работать с ними применительно
к серверу MySQL.

Русские шифровки

Обычно в Рф использовались четыре шифровки для
представления российских знаков:

CP866 (DOS)
KOI8-R
MacCyrillic
CP1251 (Windows)

Эти четыре шифровки имеют как общие черты, так и различия.
Во-1-х, они все употребляют один б инфы для хранения
1-го знака. Во-2-х, они совместимы с шифровкой cp1251, т.е.
у их совпадают 1-ые 128 б таблицы шифровки. Различаются же
значения знаков с установленным верхним битом (т.е. со значениями
128-255).

Даже четыре шифровки знаков для 1-го языка — это очень
много. Вначале люди не присваивали этому значения, но в последние
пару лет это стало не так. Появились различные трудности
переносимости программ, и люди решили сделать обобщающие шифровки,
содержащие знаки всех языков мира (в том числе, очевидно, и
российского).

Так была сотворена шифровка Unicode (UCS-2). Очевидно,
нереально расположить очень огромное количество знаков в 8 битах,
потому в этой шифровке употребляются 2 б (т.е. 16 бит) на
каждый знак. Строчки в этой шифровке, непременно, занимают больше
места, чем в старенькых шифровках, но зато приложения, использующие
такие строчки, совсем не сложно переносятся на другие языки.

Не глядя на введение UCS-2, некие задачи все-таки остались.
Во-1-х, это уже обозначенное повышение длины строчки. Люди,
использующие только латинские знаки, не могли себе осознать,
почему они должны использовать 16 бит для обозначения знаков,
которые уместятся в 7 бит. Во-2-х, 65536 знаков все равно не
хватает для обозначения всех применяемых знаков на планетке.

Для преодоления этих проблем, была сотворена шифровка с
переменной длиной знака UTF-8. В этой шифровке употребляется 1
б для обозначения первых 128 знаков (т.е. знаков, входящих в
latin1). Если установлен верхний бит первого б, то употребляется
2-ой б (т.е. российские буковкы в этой шифровке занимают 2 б).
Если установлен верхний бит второго б, то употребляется 3-ий
б (и туда входят различные иероглифы и другие восточные
знаки) и т.д..

Такая шифровка во-1-х, может расположить внутри себя случайное
количество знаков (т.к. она позволяет наращивать количество б
динамическим образом). Во-2-х, для британского языка употребляется
1 б, и это очень приятно для англоговорящих государств. Восточные
страны не очень обожают эту шифровку, т.к. им приходится использовать
3 б для обозначения собственных знаков (в UCS-2 они употребляют
только два).

Сравнения знаков

Некие приложения (включая и MySQL, о котором пойдет речь
дальше) употребляют не только лишь шифровки, да и сравнения знаков.
Дело в том, что некие знаки некие языки считают
схожими (а время от времени числятся схожими знак либо
последовательность знаков). К примеру, «u» в германском языке может
быть записан как «ue». С другой стороны, в шведском языке тот же
знак может быть записан как «uy».

В российском языке можно, к примеру, считать схожими буковкы «е» и
«ё» (как нередко делают в официальных документах). Также нередко бывает
полезным не различать огромные и мелкие буковкы (которые имеют
различный код в хоть какой шифровке).

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

Шифровки знаков в MySQL

В сервере MySQL у каждой строчки есть своя шифровка и
сравнение. При разработке таблицы, Вы сможете указать шифровку и
сравнение, в каких будут сохранены строчки снутри таблицы. Вы
сможете даже указывать эти характеристики для каждого поля таблицы.
К примеру:

CREATE TABLE enctest (
    str1
CHAR(10) CHARSET koi8r,
    str2 CHAR(15) COLLATE
utf8_general_ci
);

В данном примере создается таблица с 2-мя полями, одно из
которых будет храниться в шифровке KOI8-R (и с сравнением
по-умолчанию). 2-ое поле будет иметь сравнение utf8_general_ci
и шифровку UTF-8 (шифровка определяется по сравнению, т.к.
сравнение находится в зависимости от нее).

Перечень доступных шифровок и сопоставлений Вы сможете получить,
соответственно, командами

SHOW CHARACTER SET;
SHOW COLLATION;

Шифровки по дефлоту и смена шифровки строк в MySQL

Если Вы не желаете очевидно указывать шифровку строк в таблице, Вы
сможете для этой таблицы указать шифровку знаков по-умолчанию:

CREATE TABLE enctest2 (
    str1
CHAR(10),
    str2 CHAR(15)
) DEFAULT CHARSET
cp1251;

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

Вы также сможете поменять шифровку знаков для определенного поля
таблицы:

ALTER TABLE enctest2 MODIFY str1 CHAR(10) CHARSET
utf8;

В этом случае, в поле str1 меняется шифровка и все строчки
перекодируются. Учтите, что если Вы изменяете шифровку по-умолчанию
для таблицы, то строчки в ней не перекодируются, Вы просто влияете на
создание других полей в этой таблице.

Сравнения в MySQL

В MySQL для каждой шифровки есть по последней мере одно
сравнение (а обычно, несколько). Для того, чтоб осознать, чем они
отличаются, все они имеют очень подробные наименования.

Заглавие каждого сравнения начинается с наименования
соответственной шифровки (к примеру, utf8_). Дальше идет спецификация
сравнения (в большинстве случаев, идет обычное сравнение, general, не
идентифицирующее буковкы) и указание на чувствительность к регистру
(cs — case sensitive — чувствительно к регистру, ci — case
insensitive — не чувствительно).

Раздельно необходимо отметить бинарные сравнения (binary). Если
строчки сопоставляются бинарным образом, то меж ними не делается
никаких сопоставлений и преобразований. Такие строчки не будут
преобразованы командой SET NAMES (см. дальше). Бинарные сравнения
в особенности комфортно использовать при переходе с MySQL 3.23, который не
поддерживал шифровки и который показывает, что все таблицы находятся
в шифровке latin1 (не глядя на то, что таблицы могут содержать
данные, скажем, в KOI8-R).

Клиентские шифровки MySQL

Сервер MySQL автоматом изменяет шифровку строк при занесении
данных в таблицу и при выборке данных из таблицы. При всем этом он
употребляет данные из системных переменных, таких, как
character_set_client. Перечень всех переменных, влияющих на шифровки,
Вы сможете получить, выполнив команду

SHOW VARIABLES LIKE ‘char%’;

Вы сможете указывать либо переменные по-одиночке, либо изменять их
сходу огромным набором (как требуется почти всегда):

SET NAMES koi8r;

После того, как сервер получит такую команду, он будет ждать,
что Вы будете передавать ему все строчки в шифровке KOI8-R и будет
автоматом переводить выводимые им строчки в эту шифровку.

Это комфортно тогда, когда сервер по-умолчанию работает не в той
шифровке, которую Вы ждете (к примеру, в KOI8-R, а Вы желаете
выводить информацию на веб-сайте в CP1251).

Хранение инфы в MySQL

MySQL хранит информацию в согласовании с тем, какую шифровку вы
указали. Так сервер выделяет по 1 б на каждый знак для
однобайтовых шифровок (при всем этом CHAR(10) занимает всегда 10 б,
VARCHAR(10) занимает от 1 до 11 б зависимо от длины строчки,
1 излишний б тратится на хранение длины строчки).

Для шифровки UCS-2 сервер выделяет по 2 б на каждый знак.
Для шифровки UTF-8 сервер выделяет различное количество б для
различных знаков (в согласовании с шифровкой) в случае VARCHAR и 3
б на каждый знак в случае CHAR. Таким макаром, в UTF-8 строчка
CHAR(10) всегда занимает 30 б, а VARCHAR(10) — от 1 до 31
б.При всем этом ни в одном случае при применении UTF-8 сервер не
может хранить знаки длиной от 4 б (вобщем, это не накладывает
особенных ограничений).

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.