Что такое код setusercharsize

Содержание

Типы данных SQL

Типы данных SQL

Типы данных SQL разделяются на три группы:
строковые;
с плавающей точкой (дробные числа);
целые числа, дата и время.

  1. Типы данных SQL строковые
    Типы данных SQL Описание
    CHAR(size) Строки фиксированной длиной (могут содержать буквы, цифры и специальные символы). Фиксированный размер указан в скобках. Можно записать до 255 символов
    VARCHAR(size) Может хранить не более 255 символов.
    TINYTEXT Может хранить не более 255 символов.
    TEXT Может хранить не более 65 535 символов.
    BLOB Может хранить не более 65 535 символов.
    MEDIUMTEXT Может хранить не более 16 777 215 символов.
    MEDIUMBLOB Может хранить не более 16 777 215 символов.
    LONGTEXT Может хранить не более 4 294 967 295 символов.
    LONGBLOB Может хранить не более 4 294 967 295 символов.
    ENUM(x,y,z,etc.) Позволяет вводить список допустимых значений. Можно ввести до 65535 значений в SQL Тип данных ENUM список. Если при вставке значения не будет присутствовать в списке ENUM, то мы получим пустое значение.
    Ввести возможные значения можно в таком формате: ENUM ( ‘X’, ‘Y’, ‘Z’)
    SET SQL Тип данных SET напоминает ENUM за исключением того, что SET может содержать до 64 значений.
  2. Типы данных SQL с плавающей точкой (дробные числа) и целые числа
    Типы данных SQL Описание
    TINYINT(size) Может хранить числа от -128 до 127
    SMALLINT(size) Диапазон от -32 768 до 32 767
    MEDIUMINT(size) Диапазон от -8 388 608 до 8 388 607
    INT(size) Диапазон от -2 147 483 648 до 2 147 483 647
    BIGINT(size) Диапазон от -9 223 372 036 854 775 808 до 9 223 372 036 854 775 807
    FLOAT(size,d) Число с плавающей точкой небольшой точности.
    DOUBLE(size,d) Число с плавающей точкой двойной точности.
    DECIMAL(size,d) Дробное число, хранящееся в виде строки.
  3. Типы данных SQL — Дата и время
    Типы данных SQL Описание
    DATE() Дата в формате ГГГГ-ММ-ДД
    DATETIME() Дата и время в формате ГГГГ-ММ-ДД ЧЧ:ММ:СС
    TIMESTAMP() Дата и время в формате timestamp. Однако при получении значения поля оно отображается не в формате timestamp, а в виде ГГГГ-ММ-ДД ЧЧ:ММ:СС
    TIME() Время в формате ЧЧ:ММ:СС
    YEAR() Год в двух значной или в четырехзначном формате.

Типы данных MySQL

Типы данных MySQL разделяются на следующие типы:

  • Числовыетипы данных
    Типы данных Байт От До
    TINYINT 1 -128 127
    SMALLINT 2 -32768 32767
    MEDIUMINT 3 -8388608 8388607
    INT 4 -2147483648 2147483647
    BIGINT 8 -9223372036854775808 9223372036854775807
  • Типы данныхдаты и времени
    Типы данных Значение «Ноль»
    DATETIME ‘0000-00-00 00:00:00’
    DATE ‘0000-00-00’
    TIMESTAMP 00000000000000 (длина зависит от количества выводимых символов)
    TIME ’00:00:00′
    YEAR 0000
  • СимвольныеТипы данных
    Типы данных Макс. размер Байт
    TINYTEXT или TINYBLOB 2^8-1 255
    TEXT или BLOB 2^16-1 (64K-1) 65535
    MEDIUMTEXT или MEDIUMBLOB 2^24-1 (16M-1) 16777215
    LONGBLOB 2^32-1 (4G-1) 4294967295

Типы данных Oracle

Типы данных Oracle разделяются на следующие группы:

  • СНAR – фиксированные текстовые строки до 2000 байт. Значение типа CHAR дополняется до указанной длины пробелами.
  • VARCHAR 2 — текстовые строки переменной длины до 4000 байт.
  • NUMBER — числовые данные.
  • DECIMAL — числовые данные
  • DATE — используется для хранения дат.
  • RAW — используется для хранения двоичных данных до 2000 байт.
  • LONG — используется для хранения текстовых данных длиной до 2 ГБ
  • LONG RAW — используется для хранения двоичных данных до 2 ГБ
  • ROWID — используется для хранения идентификаторов ROWID базы данных Oracle в специальном формате (адреса строк таблицы).
  • BLOB — сохраняется до 4 ГБ двоичных данных. Данные этого типа хранятся вне таблицы, а в таблице Oracle находятся лишь указатели на объекты
  • CLOB, NCLOB — сохраняется до 4 ГБ текстовых данных. NCLOB – это тип данных NLS большой фиксированной длины (NLS означает National Language Set – набор для национальных языков – и используется для работы в Oracle на языках, отличных от английского. В английском для хранения одного символа нужен 1 байт, а в некоторых языках мира с наборами больших символов (японском, китайском, корейском), языках, где текст читается справа налево (арабский, иврит) для хранения одного символа требуется несколько байт). Данные этого типа хранятся вне таблицы, а в таблице находятся лишь указатели на объекты.
  • BFILE — сохраняется до 4 ГБ неструктурированных данных, причем в файлах операционной системы (внешние файлы).

ANSI SQL стандарт распознает только текст и число, в то время как большинство коммерческих программ используют другие специальные типы, такие как DATЕ и TIME — фактически почти стандартные типы. Некоторые пакеты также поддерживают такие типы, как, например, MONEY и BINARY. Типы данных, распознаваемые с помощью ANSI, состоят из строк символов и различных типов чисел, которые могут классифицироваться как точные числа и приблизительные числа.

CHARACTER(length) определяет спецификацию строк символов, где length задает длину строк заданного типа. Значения этого типа должны быть заключены в одиночные кавычки. Большинство реализаций поддерживают строки переменной длины для типов данных VARCHAR и LONG VARCHAR (или просто LONG).

В то время, как поле типа CHAR всегда может распределить память для максимального числа символов, которое может сохраняться в поле, поле VARCHAR при любом количестве символов может распределить только определенное количество памяти, чтобы сохранить фактическое содержание поля, хотя SQL может установить некоторое дополнительное пространство памяти, чтобы следить за текущей длиной поля. Поле VARCHAR может быть любой длины, включая реализационно-определяемый максимум. Этот максимум может меняться от 254 до 2048 символов для VARCHAR и до 16000 символов для LONG. LONG обычно используется для текста пояснительного характера или для данных, которые не могут легко сжиматься в простые значения полей; VARCHAR может использоваться для любой текстовой строки, чья длина может меняться.

Извлечение и модифицирование полей VARCHAR — более сложный, и, следовательно, более медленный процесс, чем извлечение и модифицирование полей CHAR. Кроме того, некоторое количество памяти VARCHAR, остается всегда неиспользованной для гарантии вмещения всей длины строки. При использовании таких типов следует предусматривать возможность полей к объединению с другими полями.

Точные числовые типы — это числа, с десятичной точкой или без десятичной точки, которые могут представляться в виде [+|-] [. ] и специфицироваться как:

DECIMAL(precision [, scale]) — аргумент размера имеет две части: точность и масштаб. Масштаб не может превышать точность. Точность указывает сколько значащих цифр имеет число. Масштаб указывает максимальное число цифр справа от десятичной точки. Масштаб = нулю делает поле эквивалентом целого числа.

NUMERIC(precision [, scale]) — такое же как DECIMAL за исключением того, что максимальное десятичное не может превышать аргумента точности

INTEGER — число без десятичной точки. Эквивалентно DECIMAL, но без цифр справа от десятичной точки, т.е. с масштабом равным 0. Аргумент размера не используется (он автоматически устанавливается в реализационно-зависимое значение).

SMALLINT — такое же как INTEGER, за исключением того, что, в зависимости от реализации, размер по умолчанию может ( или не может ) быть меньше чем INTEGER.

Приблизительные числовые типы — это числа в показательной (экспоненциальной по основанию 10) записи, представляемые как Е и специфицирущиеся следующим образом:

FLOAT[(precision)] — число с плавающей запятой. Аргумент размера состоит из одного числа, определяющего минимальную точность.

REAL — такое же как FLOAT, за исключением того, что никакого аргумента размера не используется. Точность устанавливается реализационно-зависимой по умолчанию.

DOUBLE PRECISION — такое же как REAL, за исключением того, что реализационно-определяемая точность для DOUBLE PRECISION должна превышать реализационно-определяемую точность REAL.

Типы данных Access

Типы данных Access разделяются на следующие группы:

  • Текстовый – максимально 255 байтов.
  • Мемо — до 64000 байтов.
  • Числовой — 1,2,4 или 8 байтов.Для числового типа размер поля м.б. следующим:
    • байт — целые числа от -0 до 255, занимает при хранении 1 байт
    • целое — целые числа от -32768 до 32767, занимает 2 байта
    • длинное целое — целые числа от -2147483648 до 2147483647, занимает 4 байта
    • с плавающей точкой — числа с точностью до 6 знаков от –3,4*1038 до 3,4*1038, занимает 4 байта
    • с плавающей точкой — числа с точностью от –1,797*10308 до 1,797*10308, занимает 8 байт
  • Дата-время — 8 байтов
  • Денежный — 8 байтов, данные о денежных суммах, хранящиеся с 4 знаками после запятой.
  • Счетчик — уникальное длинное целое, генерируемое Access при создании каждой новой записи — 4 байта.
  • Логический — логические данные 1бит.
  • Поле объекта OLE — до 1 гигабайта, картинки, диаграммы и другие объекты OLE из приложений Windows. Объекты OLE могут быть связанными или внедренными.
  • Гиперссылки — поле, в котором хранятся гиперссылки. Гиперссылка может быть либо типа UNC (стандартный формат для указания пути с включением сетевого сервера файлов), либо URL(адрес объекта, документа, страницы или объекта другого типа в Интернете или Интранете. Адрес URL определяет протокол для доступа и конечный адрес).
  • Мастер подстановок — поле, позволяющее выбрать значение из другой таблицы Accesss или из списка значений, используя поле со списком. Чаще всего используется для ключевых полей. Имеет тот же размер, что и первичный ключ, являющийся также и полем подстановок, обычно 4 байта. (Первичный ключ – одно или несколько полей, комбинация значений которых однозначно определяет каждую запись в таблице Accesss. Не допускает неопределенных .Null. значений, всегда должен иметь уникальный индекс. Служит для связывания таблицы с вторичными ключами других таблиц).

Типы данных SQL Server

Microsoft SQL Server поддерживает большинство типов данных SQL 2003. Также SQL Server поддерживает дополнительные типы данных, используемые для однозначной идентификации строк данных в таблице и на многих серверах, например UNIQUEIDENTIFIER , что соответствует аппаратной философии «роста в ширину», исповедуемой Microsoft (т. е. внедрение базы на множестве серверов на платформах Intel), вместо «роста в высоту» (т. е. внедрение на одном огромном мощном UNIX-сервере или Windows Data Center Server).

Типы данных, используемые в SQL Server:

  • BIGINT (тип данных SQL2003: B1GINT )
    Хранит целые числа со знаком и без знака в диапазоне от -9 223 372 036 854 775 808 до 9 223 372 036 854 775 807. Занимает 8 байт. См. тип INT , где указаны правила свойства IDENTITY , также применимые к типу BIGINT .
  • BINARY[(n)] (тип данных SQL2003: BLOB )
    Хранит двоичное значение фиксированной длины от 1 до 8000 байт. Значение типа BINARY занимает п + 4 байта.
  • BIT (тип данных SQL2003: BOOLEAN )
    Хранит значения 1, 0 или NULL, которое обозначает «unknown». В одном байте может храниться до 8 значений из столбцов типа BIT таблицы. В еще одном байте можно разместить дополнительные 8 значений типа BIT Столбцы типа BIT нельзя индексировать.
  • CHAR[(n)] , CHARACTER[(n)] (тип данных SQL2003: CHARACTER[(n)] )
    Хранит символьные данные фиксированной длины от 1 до 8000 символов. Все неиспользованное место по умолчанию заполняется пробелами. (Автоматическое заполнение пробелами можно отключить.) Тип занимает n байт.
  • CURSOR (тип данных SQL2003: отсутствует )
    Специальный тип данных, используемый для описания курсора в форме переменной или параметра хранимой процедуры OUTPUT. Тип нельзя использовать в инструкции CREATE TABLE. Тип CURSOR может принимать значение NULL.
  • DATETIME (тип данных SQL2003: TIMESTAMP)
    Хранит значение даты и времени в диапазоне с 01-01-1753 00:00:00 до 31-12-9999 23:59:59. Для хранения требуется 8 байт.
  • DECIMAL (p. s) , DEC (p. s) , NUMERIC (p, s) (тип данных SQL2003 : DECIMAL (p, s) , NUMERIC (p. s) )
    Хранит десятичные дроби длиной до 38 цифр. Значения р и s определяют, соответственно, точность и масштаб. Масштаб по умолчанию равен 0. Занимаемое значением место определяется используемой точностью.
    При точности 1-9 используется 5 байт.
    При точности 10-19 используется 9 байт.
    При точности 20-28 используется 13 байт.
    При точности 29-39 используется 17 байт.
    См. тип INT, где указаны правила свойства IDENTITY, также применимые к типу DECIMAL .
  • DOUBLE PRECISION (тип данных SQL2003: отсутствует )
    Синоним FLOAT(53) .
  • FLOAT[(n)] (тип данных SQL2003 : FLOAT , FLOAT (n) )
    Хранит значения с плавающей точкой в диапазоне от-1.79Е + 308 до 1.79Е + 308. Точность, определяемая параметром и, может изменяться в пределах от 1 до 53. Для хранения 7 цифр (n — от 1 до 24) требуется 4 байта. Значения, превышающие 7 цифр, занимают 8 байт.
  • IMAGE (тип данных SQL2003 : BLOB )
    Хранит двоичное значение переменной длины до 2 147 483 647 байт. Этот тип данных часто используется для хранения графики, звука и файлов, таких, как документы MS Word и электронные таблицы MS Excel. Значениями типа IMAGE нельзя свободно манипулировать. Столбцы типа IMAGE и TEXT имеют множество ограничений на способы использования. См. описание типа TEXT, где приведен список команд и функций, которые применимы и к типу IMAGE.
  • INT [IDENTITY [(seed, increment)] (тип данных SQL2003 : INTEGER )
    Хранит целые числа со знаком или без знака в диапазоне от -2 147 483 648 до 2 147 483 647. Занимает 4 байта. Все целочисленные типы данных, а также типы, хранящие десятичные дроби, поддерживают свойство IDENTITY, identity — это автоматически инкрементируемый идентификатор строки. Обращайтесь к разделу «Инструкция CREATE/ALTER TABLE » главы 3.
  • MONEY (тип данных SQL2003: отсутствует )
    Хранит денежные значения в диапазоне от -922337203685477.5808 до 922337203685477.5807. Значение занимает 8 байт.
  • NCHAR(n) , NATIONAL CHAR(n) , NATIONAL CHARACTER(n) (тип данных SQL2003 : NATIONAL СНАRACTER(n) )
    Хранит данные формата UNICODE фиксированной длины до 4000 символов. Для хранения требуется n*2 байт.
  • NTEXT , NATIONAL TEXT (тип данных SQL2003: NCLOB )
    Хранит фрагменты текста в формате UNICODE длиной до 1 073 741 823 символа. См. описание типа TEXT, где приведен список команд и функций, которые применимы и к типу NTEXT
  • NUMERIC(p, s) (тип данных SQL2003: DECIMAL (p, s))
    Синоним типа DECIMAL. См. описание типа INT, где приведены правила, относящиеся к свойству IDENTITY.
  • NVARCHAR(n) , NATIONAL CHAR VARYING(n) , NATIONAL CHARACTER VARYING(n) (тип данных SQL2003: NATIONAL CHARACTER VARYING(n))
    Хранит UNICODE-данные переменной длины до 4000 символов.
    Занимаемое место вычисляется как удвоенное значение длины всех символов, вставленных в поле (число символов * 2).
    В SQL Server системный параметр SET ANSI_PADDINGX для полей NCHAR и NVARCHAR всегда установлен (ON).
  • REAL , FLOAT(24) (тип данных SQL2003: REAL )
    Хранит значения с плавающей точкой в диапазоне -3.40Е+38 до 3.40Е+38. Зани¬мает 4 байта. Тип REAL функционально эквивалентен типу FLOAT(24).
  • ROWVERSION (тип данных SQL2003: отсутствует )
    Уникальное число, хранимое в базе данных, которое обновляется всякий раз, когда обновляется строка, В более ранних версиях называется TIMESTAMP.
  • SMALLDATETIME (тип данных SQL2003: отсутствует )
    Хранит дату и время в диапазоне от ’01-01-1900 00:00′ до ’06-06-2079 23:59′ с точностью до минуты. (Минуты округляются до меньшего значения, если значе-ние секунд 29.998 и менее, в противном случае они округляются до большего значения.) Значение занимает 4 байта.
  • SMALLINT (тип данных SQL2003: SMALLINT )
    Хранит целые числа со знаком или без знака в диапазоне от -32 768 до 32 767. Занимает 2 байта. См. описание типа INT, где приведены правила, относящиеся к свойству IDENTITY, которые также применимы и к этому типу.
  • SMALLMONEY (тип данных SQL2003: отсутствует)
    Хранит денежные значения в диапазоне от 214748.3648 до -214748.3647. Значе-ния занимают 4 байта.
  • SQLVARIANT (тип данных SQL2003: отсутствует )
    Хранит значения, относящиеся к другим поддерживаемым SQL Server типам данных, за исключением типов TEXT, NTEXT, ROWVERSION и других значений типа SQL VARIANT. Может хранить до 8016 байт данных, поддерживаются значения NULL и DEFAULT. Тип SQL VARIANT используется в столбцах, параметрах, переменных и возвращаемых функциями и хранимыми процедур, ми значениях.
  • TABLE (тип данных SQL2003: отсутствует )
    Специальный тип, хранящий получившийся в результате работы последнего про¬цесса набор данных. Используется исключительно для процедурной обработки и не может применяться в инструкциях CREATE TABLE. Этот тип данных умень¬шает необходимость создания временных таблиц во многих приложениях. Может уменьшить необходимость перекомпиляций процедур, ускоряя, таким образом, выполнение хранимых процедур и пользовательских функций.
  • TEXT (тип данных SQL2003: CLOB )
    Хранит очень большие фрагменты текста длиной до 2 147 483 647 символов. Значениями типа ТЕХТн IMAGE часто гораздо труднее манипулировать, чем, скажем, значениями типа VARCHAR. Например, нельзя создавать индекс по столбцу типа TEXT или IMAGE. Значениями типа TEXT можно манипулировать при помощи функций DATALENGTH, PATINDEX, SUBSTRING, TEXTPTR и ТЕХTVALID, а также команд READTEXT,SET TEXTSIZE, UPDATETEXT и WRITETEXT.
  • TIMESTAMP (тип данных SQL2003: TIMESTAMP )
    Хранит автоматически генерируемое двоичное число, обеспечивающее уникальность в текущей базе данных и, следовательно, отличающееся от типа данных TIMESTAMP стандарта ANSI. Тип TIMESTAMP занимает 8 байт. В настоящее время вместо TIMESTAMP для однозначной идентификации строк лучше применять значения типа ROWVERSION.
  • TINYINT
    Хранит целые числа без знака в диапазоне от 0 до 255 и занимает 1 байт. См. описание типа INT , где приведены правила, относящиеся к свойству IDENTITY , которые также применимы и к этому типу.
  • UNIQUEIDENTIFIER (тип данных SQL2003: отсутствует )
    Представляет собой значение, уникальное для всех баз данных и всех серверов. Представлено в виде хххххххх-хххх-хххх-хххх-хххххххххххх, в котором каждый «х» представляет собой шестнадцатеричное число в диапазоне 0-9 или а — f. Единственными операциями, которые можно производить над значениями этого типа, являются сравнение и проверка на NULL. В столбцах этого типа можно использо¬вать ограничения и свойства, за исключением свойства IDENTITY.
  • VARBINARY[(n)] (тип данных SQL2003: BLOB )
    Представляет собой двоичное значение переменной длины, до 8000 байт. Занимаемое место соответствует размеру вставленных данных плюс 4 байта.
  • VARCHARf(n)] , CHAR VARYING [(n)] , CHARACTER VARYING [(n)] (тип данных SQL2003: CHARACTER VARYING (n) )
    Хранит символьные данные фиксированной длины размером от 1 до 8000 символов. Занимаемое место равно реальному размеру введенного значения в байтах, а не значению n.

Типы данных PostgreSQL

База данных PostgreSQL поддерживает большинство типов данных SQL2003 плюс огромный набор типов для хранения пространственных и геометрических данных. PostgreSQL может похвастаться богатым набором операторов и функций, специально предназначенных для геометрических типов данных. Сюда входят такие средства, как поворот, поиск пересечений и масштабирование. В PostgreSQL также есть поддержка дополнительных версий существующих типов данных, которые характерны тем, что занимают меньше места на диске, чем соответствующие исходные версии. Например, в PostgreSQL предлагается несколько вариантов типа INTEGER для хранения больших и небольших чисел, соответственно занимающих больше или меньше места.

  • BJGSERJAL
  • BIT (тип данных SQL2003: BIT )
    Битовая строка фиксированной длины.
  • BIT VARYING(n) varbit(n) (тип данных SQL2003: BIT VARYING )
    Обозначает битовую строку переменной длины в n бит.
  • BOOL , BOOLEAN (тип данных SQL2003: BOOLEAN )
    Хранит логическое булево значение (true/false/unknown). Рекомендуемыми значе-ниями являются ключевые слова TRUE и FALSE, хотя PostgreSQL допускает применение нескольких литеральных значений для «true»: TRUE, t, true, у, yes и 1. Допус¬тимыми значениями для «false» являются: FALSE, f, false, n, no и 0.
  • BOX ((xl, у I), (x2, y2)) (тип данных SQL2003: отсутствует )
    Хранит значения, определяющие прямоугольную область на плоскости. Значения занимают 32 байта и представлены в виде ((xl, yl), (х2, у2)), что соответствует противоположным углам прямоугольника (правый верхний и левый нижний соот-ветственно). Внешние скобки являются необязательными.
  • BYTEA (тип данных SQL2003: BINARY LARGE OBJECT )
    Сырые, двоичные данные, используемые, например, для хранения графики, звука и документов. Для хранения этого типа требуется 4 байта плюс реальный размер битовой строки.
  • CHAR(n) , СНАRA CTER(n) (тип данных SQL2003: CHARACTER(n) )
    Содержит символьную строку фиксированной длины, дополняемую пробелами до длины n. Попытка вставить значение, превышающее по длине n, приводит к ошибке (если только лишние символы не представляют собой пробелы, которые в таком случае обрезаются так, чтобы длина составила п символов).
  • CIDR(x.x.x.xZy) (тип данных SQL2003: отсутствует)
    Описывает адрес сети или хоста в формате версии 4 протокола IP Адрес занимает 12 байт. Допустимыми значениями являются любые допускаемые протоколом IPv4 сетевые адреса. В типе CIDR данные представлены в форме х.х.х.х/у, где х.х.х.х — IP-адрес, а у — количество бит сетевой маски. В CIDR не допускается использование ненулевых битов справа от нулевого бита сетевой маски.
  • CIRCLE х, у, r (тип данных SQL2003: отсутствует)
    Описывает окружность на плоскости. Значения занимаю!’ 24 байта и представлены в форме х, у, r. Значения* и у представляют собой координаты центра окружности, а r — длину ее радиуса. Значения х, у и r при желании можно ограничить скобками или фигурными скобками.
  • DATE (тип данных SQL2003: DATE)
    Хранит календарную дату (год, день и месяц) без времени суток. Занимает 4 байта. Даты должны быть в диапазоне от 4713 до п. э. до 32767 и. э. Предел разрешения для типа DATE, естественно, один день.
  • DATETIME (тип данных SQL2003: T1MESTAMP)
    Хранит календарную дату с указанием времени суток.
  • DECIMAL [(p, s)], NUMERIC [(p. s)] (тип данных SQL2003: DECIMAL (PRECISION SCALE), NUMERIC (x, p))
    Хранит точные числовые значения с точностью (р), равной 9, и масштабом (s), равным нулю, без верхнего предела.
  • FLOAT4, REAL (тип данных SQL2003: FLOAT(p))
    Хранит значения с плавающей точкой с точностью, равной 8 или менее, и 6 знаками после занятой.
  • FLOAT8, DOUBLE PRECISION (тип данных SQL2003: FLOAT(p), 7 TEXT (тип данных SQL2003: CLOB)
    Хранит большой массив символьных строк переменной длины до 1 гигабайта. PostgreSQL автоматически сжимает строки типа TEXT, поэтому место, занимаемое на диске, может быть меньше, чем размер строк.
  • TIME [(p)] [WITHOUT TIMEZONE \ WITH TIME ZONE] (тип данных SQL2003: TIME) Хранит время суток либо без учета часового пояса (используется 8 байт), либо с учетом часового пояса, в котором находится сервер базы данных (используется 12 байт). Допустимый диапазон значений: 00:00:00.00 — 23:59:59.99. Наименьшее значение — 1 микросекунда. Заметьте, что в большинстве систем UNIX информация о часовом поясе доступна только для дат с 1902 по 2038 год.
  • TIMESPAN (тип данных SQL2003: отсутствует)
    Хранит значение, представляющее собой конкретный промежуток времени. Наи¬более похожим на тип TIMESPAN в стандарте ANSI является тип INTERVAL.
  • TIMESTAMP [(р)] [WITHOUT TIMEZONE \ WITH TIMEZONE] (тип данных SQL2003: TIMESTAMP [WITH TIMEZONE I WITHOUT TIMEZONE])
    Хранил дату и время с учетом и без учета часового пояса сервера базы данных. Допустимый диапазон значений — от 4713 до н. э. до 1 465 001 н. э. Одно значение типа TIMESTAMP занимает 8 байт. Самое наименьшее значение — 1 микросекунда. Заметьте, что в большинстве систем UNIX информация о часовом поясе доступна только для дат с 1902 по 2038 год.
  • TIMETZ (тип данных SQL2003: TIME WITH TIMEZONE)
    Хранит значение времени суток с учетом часового пояса.
  • VARCHAR(n) , CHARACTER VARYLNG(n) (тип данных SQL2003: CHARACTER VARYING(n))
    Хранит символьные строки переменной длины длиной до п. Заключительные пробелы не сохраняются.
Илон Маск рекомендует:  rt в HTML

Вы должны войти, чтобы оставить комментарий.

Sergey Danielyan

Корректная настройка MySQL для работы с UTF8

Сегодня речь пойдет о MySQL и о настройке UTF8 кодировки по-умолчанию. Тема заезжена, но как я убедился за прошедшую неделю, мало кто в состоянии нормально пояснить какие параметры и куда надо прописать для полноценной работы с UTF8 в MySQL. К сожалению, ситуация на тематических блогах оставляет желать лучшего. Основной тип ответа — приведение соедржимого конфигурационного файла с комментарием типа “попробуй, у меня это работает”.

Основная цель данного поста — выяснить, какие параметры и с какими значениями следует прописать в конфигурационный файл my.cnf (my.ini) для дальнейшей беспроблемной работы с Юникодом.

Рабочее окружение

UTF8 на данный момент у меня успешно работает в Мастер-Слейв конфигурации:

  • MySQL версии 5.1.66
  • Два сервера CentOS версии 6.3
  • Репликация между серверами Master-Slave на базе SSL

Любой внешний клиент в состоянии корректно работать с UTF8 базой (проверено на EMS Manager for MySQL c Windows 8 x64).

Все опции и настройки я привожу для версии сервера 5.1.x, однако с минимальными (а то и вовсе без оных) изменениями все это будет работать и на версиях 5.5.x и 5.6.x.

Параметры кодировок MySQL

Довольно часто приходится видеть в ответах на вопросы о настройке UTF8 следующее:

Предполагается, что после вставки всего этого добра (тут кстати есть противоречащие друг другу опции) в конфигурационный файл my.cnf (my.ini) магический Юникод начнет работать.

Но давайте забудем о списке и попытаемся разбираться со всеми опциями сами и начнем с самого начала. То есть с документации. Потому как все это прекрасно описано в документации MySQL на официальном сайте. Я лишь постараюсь последовательно рассказать о параметрах сервера и прояснить неясные моменты.

Главный раздел по описанию кодировок (character sets) и их представлений (collations — используется например при сортировке) в контексте сервера, базы, таблиц — это секция 10.1.3. Specifying Character Sets and Collations.

Символьная кодировка может быть задана для:

  1. сервера,
  2. базы данных,
  3. таблицы и
  4. колонок в таблице.

Сделано это для гибкой настройки баз данных и доступа клиентов с разными кодировками. Однако, последнее не входит в область рассмотрения данного поста, поэтому будем рассматривать вариант с кодировкой UTF8 настроенной для всего по-умолчанию.

Все параметры могут быть переданы серверу тремя разными способами:

  1. через командную строку mysqld
  2. через конфигурационный файл my.cnf (my.ini)
  3. через опции компиляции.

Второй и третий варианты рассматриваться не будут. Тут уместно будет просто прочитать официальные доки — в каждом разделе приведены примеры конфигурации с использованием всех трех способов. Я же буду использовать первый вариант.

Кодировка (character set) и представление (collation) сервера

Кодировка (characher set) — набор используемых символов.
Представление (collation) — набор правил для сравнения символов в наборе.

Тут есть несколько фундаментальных вещей которые надо понимать.

Основные параметры используемые в контексте сервера — это character_set_server и collation_server . Оба параметра влияют на определение кодировки и отображения сервера MySQL.

Можно задать оба параметра либо только один из них. При этом важно знать как задача того или иного влияет на определение отсутствующего:

Не заданы — используются значения по умолчанию (дефолтные),

Заданы оба — используются указанные кодировка и ее представление,

Задана только кодировка — ее представление выставляется по умолчанию для данного типа кодировки. Что это значит? Для каждого типа кодировки есть ее дефолтное представление, например, дефолтная кодировка сервера — latin1 , а дефолтное отображение для нее — latin1_swedish_ci . Посмотреть соответствие кодировки и ее дефолтного представления можно используя команду:

SHOW COLLATION LIKE ‘your_character_set_name’;

Поле Default дает ответ о представлении выбранной кодировки.

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

Наши команды:
my.cnf (my.ini)

[mysqld]
character-set-server = utf8
collation-server = utf8_unicode_ci

Дефолтное представление для utf8 — utf8_general_ci , так что если бы мы его использовали вместо utf8_unicode_ci , то параметр collation_server можно было бы вообще опустить.

Кодировка (character set) и представление (collation) базы данных

Тут есть два варианта определения кодировки и представления:

явно — при выполнении запроса на создание базы данных:

CREATE DATABASE db_name CHARACTER SET latin1 COLLATE latin1_swedish_ci;

неявно через переменные character_set_database и collation_database . Однако, эти переменные нельзя задать явно ни в командной строке ни в конфигурационном файле. Как они инициализируются — чуть ниже.

Вообще при работе с базой данных огромную роль помимо серверных настроек играют настройки клиент-серверного соединения (connection). На этом этапе вступают в игру следующие специфичные для соединения параметры:

  • character_set_client — кодировка в которой посылается запрос от клиента
  • character_set_connection — кодировка используемая для конвертации пришедшего запроса (statement’а)
  • character_set_results — кодировку, в которую сервер должен перевести результат перед его отправкой клиенту

Есть еще представление кодировки соединения ( colation_connection ). Для чего нужен этот параметр думаю пояснять не надо.

Озадачиваться проблемой инициализации всех этих переменных не стоит (хотя в нашем случае присвоить им значения необходимо). Есть способ проще: существует два типа запросов (statements) которые задают настройки соединения клиента с сервером группой:

Запрос SET NAMES ‘charset_name’ [COLLATE ‘collation_name’]

Параметр определяет в какой кодировке теперь будут приходить сообщения для сервера от клиента. Прелесть в том, что запрос SET NAMES x эквивалентен следующей группе:

SET character_set_client = x;
SET character_set_results = x;
SET character_set_connection = x;

Для определении представления кодировки соединения ( colation_connection ) отличного от дефолтного, следует дополнить запрос:

SET NAMES x COLLATE y

А так как у нас utf8 и ее дефолтное представление utf8_general_ci , то нам нужно выпонить полный запрос:

SET NAMES utf8 COLLATE utf8_unicode_ci

Таким образом, используя только этот запрос, можно добиться корректной UTF8 инициализации соединения.

Однако, тут есть один нюанс:

SET NAMES x , как понятно из определения, определяет настройку клиента при коннекте к серверу. Но что делать, если клиент — сам mysql.exe и нам хочется установить collation_connection по-умолчанию, не выполняя каждый раз SET NAMES x при коннекте?
Для этих целей, существует еще один параметр — default_character_set . Он эквивалентен запросу SET NAMES utf8 . В случае его использования задать collation_connection отличный от дефолтного уже не получится, поэтому придется заюзать еще одну команду init_connect (так как напрямую collation_connection нельзя прописать в конфигурационном файле):

init_connect=‘SET collation_connection = utf8_unicode_ci’

Но и тут есть еще одно но: init_connect команда не выполняется для SUPER пользователей — пользователей, обладающих привилегией SUPER. root входит в этот перечень, поэтому при коннекте root’ом команду SET collation_connection = utf8_unicode_ci все же придется выполнить вручную.

Запрос SET CHARACTER SET charset_name

Запрос групповой и он также эквивалентен следующей группе:

SET character_set_client = x;
SET character_set_results = x;
SET collation_connection = @@collation_database;

Согласно документации, разница между двумя запросами в том, что параметры character_set_connection и collation_connection будут установлены на @@character_set_database и @@collation_database соответственно (выше я про них упоминал).

За более детальной информацией отсылаю по двум источникам — собственно к официальной документации и прекрасно оформленному ответу на stackoverflow.com. Для нашей задачи вполне хватает первого параметра вместе с дополнительной командой.

Подытожим: различные сценарии и что юзается на каждом из них — относительно к настройкам соединения:

  • Если к базе коннектится mysql.exe клиент с пользователем с привилегией SUPER:
    • срабатывает опция в конфигурационном файле default_character_set = utf8
    • надо выполнить вручную команду init_connect=’SET collation_connection = utf8_unicode_ci’
  • Если к базе коннектится mysql.exe клиент с пользователем без привилегии SUPER:
    • срабатывает опция в конфигурационном файле default_character_set = utf8
    • срабатывает команда в конфигурационном файле init_connect=’SET collation_connection = utf8_unicode_ci’
  • Если к базе коннектится внешний клиент:
    • надо выполнить вручную команду SET NAMES utf8 COLLATE utf8_unicode_ci

Наши команды:
my.cnf (my.ini)

[client]
default_character_set = utf8

[mysqld]
init_connect=‘SET collation_connection = utf8_unicode_ci’

Кодировка (character set) и представление (collation) таблиц

Тут все довольно просто. Задать кодировку и ее представление можно через команды:

CREATE TABLE t1 ( … )
CHARACTER SET utf8 COLLATE utf8_unicode_ci;

Тут главное иметь в виду, что если эти настройки не заданы, то берутся настройки базы данных (см. пред. раздел). Нам эти настройки не интересны.

Кодировка (character set) и представление (collation) колонок в таблице

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

Прежде чем перейти к след. разделу, должен сказать, что все команды и запросы относятся к указанной версии MySQL и в случае возникновения каких-либо проблем советую обратиться к соответствующей версии документации.

skip-character-set-client-handshake

Помимо освещенных параметров, есть еще один довольно часто фигурирующий в разного рода источниках — skip-character-set-client-handshake. Установка этого параметра позволит проигнорировать информацию клиента о кодировке. Я данный параметр не использовал.

Верификация настроек

Итак, вот финальный snapshot наших изменений в файле my.cnf (my.ini):

[mysqld]
init_connect=‘SET collation_connection = utf8_unicode_ci’
character-set-server = utf8
collation-server = utf8_unicode_ci

[client]
default-character-set = utf8

После применения всех опций и рестарта сервера mysql для проверки настроек можно воспользоваться командами SHOW VARIABLES LIKE ‘char%’ и SHOW VARIABLES LIKE ‘collation%’ ;

Состояние среды до изменений:

Состояние среды после изменений (в случае, если вы приконнектились не SUPER пользователем):

Для примера, вот отличие при соединении через mysql.exe пользователем с и без привилегии SUPER:

с привилегией и выполненной вручную командой ‘SET collation_connection = utf8_unicode_ci’:

Поздравляю, теперь ваши база, таблицы и все в таблицах по-умолчанию в кодировке UTF8.

Работа с кодировками в MySQL 4.1.11 и выше

Полезность первоисточника информации трудно переоценить, поэтому не поленитесь и скачайте полный мануал от разработчиков MySQL — http://dev.mysql.com/doc/

Тестовая машина

Устанавливаем MySQL 5.1

Пускай это не самый «правильный» способ установки MySQL-сервера, зато быстрый и рабочий.

Начало работы

Итак, sockstat показала, что сервер работает, а установка говорит о том, что сервер абсолютно девственный. Чем это грозит? Кодировки по умолчанию выставлены англоязычные, а значит, будут проблемы при использовании кирилицы. Но как это распознать? Проверяем:

Первым делом используем тестовую базу, которая уже есть на сервере, затем создаём в ней таблицу и вставляем в неё три слова на русском, про кодировки мы пока ничего не знаем и знать не хотим ))).

Пока всё хорошо и радужно, никаких ошибок нет, пробуем сделать выборку:

Как видно, запросы работают абсолютно корректно, так где же грабли. Оказывается мы на них уже стоим:

Запрос на выборку с обратной сортировкой привёл к тому, что записи просто вывелись в обратном порядке, но не по алфавиту. До удара граблей остаются считанные секунды, но пока растянем удовольствие :) Сперва ответим на вопрос — почему поля не сортируются по алфавиту? У MySQL имеется мощный и богатый механизм для работы с интернациональными наборами символов, но.. но откуда MySQL узнает, что наши символы — есть русский алфавит, мы же качали английскую версию? Ничего не остаётся, как идти ковырять мануал на предмет кодировок.

После того, как загрузился 16-метровый мануал, можно не полениться и прочитать первые пару-тройку страниц с оглавлением )), а можно просто сделать поиск на предмет charset или character set. Не суть важно, но через некоторое время можно найти раздел 9.1.2. Character Sets and Collations in MySQL, в котором написано много и интересно, а, главное, содержательно про то, каким образом можно и нужно работать с кодировками.

Расставляя точки над и, Character Set — транслируется как «кодировка», а Collation — сравнение. В чём разница? Сравнение — это правила сравнения букв кодировки. Сравнения работают только в рамках кодировки, и нельзя сравнивать данные в латинице по правилам кирилицы. Поясню на примере: мы, как увидим позже, внесли данные в таблицу на латинице, а сортировать нужно на кирилице, для чего можно использовать ключевое слово collate :

MySQL отказывается это делать. но почему? Потому, что latin1 не поддерживает сравнение в кирилице, а доступные «сравнения» можно увидеть так:

Ни о какой кирилице не может идти и речи. Куда копать. В создание таблицы!

Ага! По-умолчанию при создании таблицы была взята кодировка latin1, значит, если мы изменим таблицу и укажем ей, что надо использовать кирилистическую кодировку, то всё заработает. В мануале написан пример про изменение кодировки таблицы, используем его:

Ок! Проверяем, что получилось.

Хм.. опять та же ошибка, но откуда ей взяться.

Ого, структура таблицы резко изменилась, теперь у неё задана одна кодировка, а у поля совсем другая.. :(( Порыв ещё мануал, можно изменить и кодировку столбца:

Ну вот. Злой кодировки latin1 нет и в помине, можно проверять наш роддом )))

И вот тот страшный удар граблями, который так долго оттягивался! Внимательный читатель мог заметить, что когда была сделана попытка принудительно сменить кодировку столбца, содержащего данные в latin1, то на каждую запись, содержащую русские буквы, у MySQL был варнинг! Это был крик о том, что сервер не знает, каким образом можно перевести данные из latin1 в cp1251, ну и лучшего способа, чем заменить символы не latin1 вопросиками, он не нашёл :))). Роддом безвозвратно потерян потому, что теперь вместо кирилицы в базе содержатся вопросики..

Вопросиков можно было избежать

На самом деле, ситуация, когда изначально выставлена неправильная кодировка, встречается сплошь и рядом. Симптомы можно выявить следующим образом:

Именно эти переменные отвечают за дефолтные значения кодировок.

  • character_set_client — кодировка, в которой данные будут поступать от клиента
  • character_set_connection — кодировка по умолчанию для всего, что в рамках соединения не имеет кодировки
  • character_set_database — кодировка по умолчанию для баз
  • character_set_filesystem — кодировка для работы с файловой системой (LOAD DATA INFILE, SELECT . INTO OUTFILE, и т.д.)
  • character_set_results — кодировка, в которой будет выбран результат
  • character_set_server — кодировка, в которой работает сервер
  • character_set_system — кодировка, в которой задаются идентификаторы MySQL, всегда UTF8
  • character_sets_dir — папка с кодировками

ВАЖНО: Если character_sets_dir установлена неверно, то работа с кодировками будет под угрозой. Не пытайтесь менять её значение, если вы неуверены в своих силах. Если вы системный администратор, то перед установкой лучше ознакомиться с мануалом.

Наиболее значимые для простых пользователей следующие переменные: character_set_client, character_set_results, character_set_connection. Поскольку именно они отвечают за внесение, извлечение информации и создание таблиц/баз соответственно. Какими они могут быть?

Любую из этих кодировок можно пользовать на свой вкус. Обычно русскоязычные пользователи предпочитают cp1251 или utf8, но по сути, неважно, в какой кодировке хранятся данные, важно, чтобы она была изначально правильно указана и данные были корректно внесены.

Настройка кодировок

Мануал предлагает нам три варианта задания кодировок:

ВНИМАНИЕ. Первые два варианта работают только в рамках текущего соединения. Это значит, что при следующем подключении все настройки вернутся в начальное состояние! Чтобы не выставлять кодировку каждый раз, нужно воспользоваться третьим вариантом.

Вариант 1 — Через names

Ну, тут всё ясно, три самые нужные кодировки в одном )))

Вариант 2 — Через непосредственно переменные character_set_*

Более детальная настройка, чем names.

Вариант 3 — Через настройки самого сервера

Тут можно пойти двумя путями — либо через конфиг файл:

Ещё можно при конфигурировании задать кодировку по умолчанию

Но лучше, когда кодировка настраивается прямо в соединении.

Что делать, если данные внесены в неправильной кодировке

Если база/таблица/данные были созданы/внесены в кодировке отличной от нужной, то необходимо сделать следующее:

  1. Создать бэкап базы данных
  2. Создать текстовый дамп базы в SQL-запросах (mysqldump или PhpMyAdmin)
  3. С помощью текстового редактора исправить вхождения неверной кодировки на нужную (а лучше попросту удалить всю информацию о кодировках и сравнениях)
  4. Удалить базу/таблицу
  5. Выставить нужную кодирвку на клиента/соединение
  6. Импортировать данные исправленного SQL-дампа

Этот вариант подходит почти для всех случаев, за исключением некоторых особых ситуаций, например, когда сравнение, выставленное по-умолчанию, не уместно для некоторых полей. Пример — поле для хранения пароля, необходимо сравнивать его с учётом регистра, тогда как по-умолчанию выставляется сравнение без учёта регистра.

Правильный вариант работы с MySQL

Таким образом, клиент работает в KOI8-R, но данные хранятся в cp1251, MySQL знает об этом и делает перекодировку на лету.

Ну и на посошок:

Выбирать данные можно в любой кодировке, так же, как и вносить, главное — правильно сообщить об этом MySQL.

© 2020 Антон Прибора. При копировании материалов с сайта, пожалуйста, указывайте ссылку на источник.

Форум пользователей MySQL

Задавайте вопросы, мы ответим

Страниц: 1

#1 23.02.2010 13:12:25

как изменить значение character_set_results?

Подскажите пожалуйста как изменить значение переменной character_set_results.
Проблема в том что в базе хранится русскоязычный текст в нормальном виде, при выводи получаются разные значки.
Запрос SHOW GLOBAL VARIABLES LIKE ‘char%’
character_set_client cp1251
character_set_connection cp1251
character_set_database cp1251
character_set_filesystem binary
character_set_results cp1251
character_set_server cp1251
character_set_system utf8
character_sets_dir C:\Program Files\Zend\MySQL51\share\charsets\

Запрос SHOW VARIABLES LIKE ‘char%’
character_set_client utf8
character_set_connection cp1251
character_set_database cp1251
character_set_filesystem binary
character_set_results utf8
character_set_server cp1251
character_set_system utf8
character_sets_dir C:\Program Files\Zend\MySQL51\share\charsets\

я так понимаю что переменная character_set_results при выводе перекодирует данные в utf8.
Как изменить ее значение?

#2 23.02.2010 16:41:02

Re: как изменить значение character_set_results?

SET character_set_results = ‘cp1251’;

Проще и правильнее, однако, пользоваться SET NAMES cp1251,
которая сразу ставит все переменные в нужные значения.

#3 24.02.2010 13:45:38

Re: как изменить значение character_set_results?

Ничего не выходит, как только не делаю. (
В базе нормально, на сайте �������-������� �� ���������� �����������

#4 25.02.2010 00:37:05

Re: как изменить значение character_set_results?

FAQ п3 и 8 пробовали?

Страниц: 1

Работает на PunBB
© Copyright 2002–2008 Rickard Andersson

Форум русскоязычного сообщества Ubuntu

За новостями русскоязычного сообщества и Ubuntu в целом можно следить на нашей страничке в Google+

Автор Тема: [Wiki] [HOWTO] Настройка кодировок MySql сервера (Прочитано 25875 раз)

0 Пользователей и 1 Гость просматривают эту тему.

Страница сгенерирована за 0.069 секунд. Запросов: 24.

© 2012 Ubuntu-ru — Русскоязычное сообщество Ubuntu Linux.
© 2012 Canonical Ltd. Ubuntu и Canonical являются зарегистрированными торговыми знаками Canonical Ltd.

11 Character Set Migration

This chapter discusses character set conversion and character set migration. This chapter includes the following topics:

Overview of Character Set Migration

Choosing the appropriate character set for your database is an important decision. When you choose the database character set, consider the following factors:

The type of data you need to store

The languages that the database needs to accommodate now and in the future

The different size requirements of each character set and the corresponding performance implications

A related topic is choosing a new character set for an existing database. Changing the database character set for an existing database is called character set migration . When you migrate from one database character set to another you must choose an appropriate character set. You should also plan to minimize data loss from the following sources:

Илон Маск рекомендует:  Что такое код sqlиспользование like

Data Truncation

When the database is created using byte semantics, the sizes of the CHAR and VARCHAR2 data types are specified in bytes, not characters. For example, the specification CHAR(20) in a table definition allows 20 bytes for storing character data. When the database character set uses a single-byte character encoding scheme, no data loss occurs when characters are stored because the number of characters is equivalent to the number of bytes. If the database character set uses a multibyte character set, then the number of bytes no longer equals the number of characters because a character can consist of one or more bytes.

During migration to a new character set, it is important to verify the column widths of existing CHAR and VARCHAR2 columns because they may need to be extended to support an encoding that requires multibyte storage. Truncation of data can occur if conversion causes expansion of data.

Table 11-1 shows an example of data expansion when single-byte characters become multibyte characters through conversion.

Table 11-1 Single-Byte and Multibyte Encoding

The first column of Table 11-1 shows selected characters. The second column shows the hexadecimal representation of the characters in the WE8MSWIN1252 character set. The third column shows the hexadecimal representation of each character in the AL32UTF8 character set. Each pair of letters and numbers represents one byte. For example, ä ( a with an umlaut) is a single-byte character ( E4 ) in WE8MSWIN1252, but it becomes a two-byte character ( C3 A4 ) in AL32UTF8. Also, the encoding for the euro symbol expands from one byte ( 80 ) to three bytes ( E2 82 AC ).

If the data in the new character set requires storage that is greater than the supported byte size of the data types, then you must change your schema. You may need to use CLOB columns.

Additional Problems Caused by Data Truncation

Data truncation can cause the following problems:

In the database data dictionary, schema object names cannot exceed 30 bytes in length. You must rename schema objects if their names exceed 30 bytes in the new database character set. For example, one Thai character in the Thai national character set requires 1 byte. In AL32UTF8, it requires 3 bytes. If you have defined a table whose name is 11 Thai characters, then the table name must be shortened to 10 or fewer Thai characters when you change the database character set to AL32UTF8.

If existing Oracle usernames or passwords are created based on characters that change in size in the new character set, then users will have trouble logging in because of authentication failures after the migration to a new character set. This occurs because the encrypted usernames and passwords stored in the data dictionary may not be updated during migration to a new character set. For example, if the current database character set is WE8MSWIN1252 and the new database character set is AL32UTF8, then the length of the username scött ( o with an umlaut) changes from 5 bytes to 6 bytes. In AL32UTF8, scött can no longer log in because of the difference in the username. Oracle recommends that usernames and passwords be based on ASCII characters. If they are not, then you must reset the affected usernames and passwords after migrating to a new character set.

Encrypted usernames and passwords stored in the data dictionary are not updated when migration is accomplished with the CSALTER script, but they are updated if the migration is accomplished with the Import and Export utilities.

When CHAR data contains characters that expand after migration to a new character set, space padding is not removed during database export by default. This means that these rows will be rejected upon import into the database with the new character set. The workaround is to set the BLANK_TRIMMING initialization parameter to TRUE before importing the CHAR data.

Oracle Database Reference for more information about the BLANK_TRIMMING initialization parameter

Character Set Conversion Issues

This section includes the following topics:

Replacement Characters that Result from Using the Export and Import Utilities

The Export and Import utilities can convert character sets from the original database character set to the new database character set. However, character set conversions can sometimes cause data loss or data corruption. For example, if you are migrating from character set A to character set B, then the destination character set B should be a superset of character set A. The destination character, B, is a superset if it contains all the characters defined in character set A. Characters that are not available in character set B are converted to replacement characters, which are often specified as ? or ¿ or as a character that is related to the unavailable character. For example, ä ( a with an umlaut) can be replaced by a . Replacement characters are defined by the target character set.

There is an exception to the requirement that the destination character set B should be a superset of character set A. If your data contains no characters that are in character set A but are not in character set B, then the destination character set does not need to be a superset of character set A to avoid data loss or data corruption.

Figure 11-1 shows an example of a character set conversion in which the copyright and euro symbols are converted to ? and ä is converted to a .

Figure 11-1 Replacement Characters in Character Set Conversion

To reduce the risk of losing data, choose a destination character set with a similar character repertoire. Migrating to Unicode may be the best option, because AL32UTF8 contains characters from most legacy character sets.

Invalid Data That Results from Setting the Client’s NLS_LANG Parameter Incorrectly

Another character set migration scenario that can cause the loss of data is migrating a database that contains invalid data. Invalid data usually occurs in a database because the NLS_LANG parameter is not set properly on the client. The NLS_LANG value should reflect the client operating system code page. For example, in an English Windows environment, the code page is WE8MSWIN1252. When the NLS_LANG parameter is set properly, the database can automatically convert incoming data from the client operating system. When the NLS_LANG parameter is not set properly, then the data coming into the database is not converted properly. For example, suppose that the database character set is AL32UTF8, the client is an English Windows operating system, and the NLS_LANG setting on the client is AL32UTF8. Data coming into the database is encoded in WE8MSWIN1252 and is not converted to AL32UTF8 data because the NLS_LANG setting on the client matches the database character set. Thus Oracle assumes that no conversion is necessary, and invalid data is entered into the database.

This can lead to two possible data inconsistency problems. One problem occurs when a database contains data from a character set that is different from the database character set but the same code points exist in both character sets. For example, if the database character set is WE8ISO8859P1 and the NLS_LANG setting of the Chinese Windows NT client is SIMPLIFIED CHINESE_CHINA.WE8ISO8859P1, then all multibyte Chinese data (from the ZHS16GBK character set) is stored as multiples of single-byte WE8ISO8859P1 data. This means that Oracle treats these characters as single-byte WE8ISO8859P1 characters. Hence all SQL string manipulation functions such as SUBSTR or LENGTH are based on bytes rather than characters. All bytes constituting ZHS16GBK data are legal WE8ISO8859P1 codes. If such a database is migrated to another character set such as AL32UTF8, then character codes are converted as if they were in WE8ISO8859P1. This way, each of the two bytes of a ZHS16GBK character are converted separately, yielding meaningless values in AL32UTF8. Figure 11-2 shows an example of this incorrect character set replacement.

Figure 11-2 Incorrect Character Set Replacement

The second possible problem is having data from mixed character sets inside the database. For example, if the data character set is WE8MSWIN1252, and two separate Windows clients using German and Greek are both using WE8MSWIN1252 as the NLS_LANG character set, then the database contains a mixture of German and Greek characters. Figure 11-3 shows how different clients can use different character sets in the same database.

Figure 11-3 Mixed Character Sets

For database character set migration to be successful, both of these cases require manual intervention because Oracle Database cannot determine the character sets of the data being stored. Incorrect data conversion can lead to data corruption, so perform a full backup of the database before attempting to migrate the data to a new character set.

Conversion from Single-byte to Multibyte Character Set and Oracle Data Pump

If Oracle Data Pump is being used, and if a character set migration from single-byte to multibyte is performed, then the Data Pump PL/SQL packages must be reloaded.

Changing the Database Character Set of an Existing Database

Database character set migration has two stages: data scanning and data conversion. Before you change the database character set, you must >data scanning .

Data scanning identifies the amount of effort required to migrate data into the new character encoding scheme before changing the database character set. Some examples of what may be found during a data scan are the number of schema objects where the column widths need to be expanded and the extent of the data that does not exist in the target character repertoire. This information helps to determine the best approach for converting the database character set.

Incorrect data conversion can lead to data corruption, so perform a full backup of the database before attempting to migrate the data to a new character set.

There are three approaches to converting data from one database character set to another if the database does not contain any of the inconsistencies described in «Character Set Conversion Issues». A description of methods to migrate databases with such inconsistencies is out of the scope of this documentation. For more information, contact Oracle Consulting Services for assistance.

The approaches are:

Migrating Character Data Using a Full Export and Import

In most cases, a full export and import is recommended to properly convert all data to a new character set. It is important to be aware of data truncation issues, because columns with character data types may need to be extended before the import to handle an increase in size. Existing PL/SQL code should be reviewed to ensure that all byte-based SQL functions such as LENGTHB , SUBSTRB , and INSTRB , and PL/SQL CHAR and VARCHAR2 declarations are still valid.

Oracle Database Utilities for more information about the Export and Import utilities

Migrating a Character Set Using the CSALTER Script

The CSALTER script is part of the Database Character Set Scanner utility. The CSALTER script is the most straightforward way to migrate a character set, but it can be used only if all of the schema data is a strict subset of the new character set. The new character set is a strict superset of the current character set if:

Each and every character in the current character set is available in the new character set.

Each and every character in the current character set has the same code point value in the new character set. For example, many character sets are strict supersets of US7ASCII.

With the strict superset criteria in mind, only the metadata is converted to the new character set by the CSALTER script, with the following exception: the CSALTER script performs data conversion only on CLOB columns in the data dictionary and sample schemas that have been created by Oracle. CLOB columns that users have created may need to be handled separately. Beginning with Oracle9 i , some internal fields in the data dictionary and sample schemas are stored in CLOB columns. Customers may also store data in CLOB fields. When the database character set is multibyte, then CLOB data is stored in a format that is compatible with UCS-2 data. When the database character set is single-byte, then CLOB data is stored using the database character set. Because the CSALTER script converts data only in CLOB columns in the data dictionary and sample schemas that were created by Oracle, any other CLOB columns that are created must be first exported and then dropped from the schema before the CSALTER script can be run.

To change the database character set, perform the following steps:

Shut down the database, using either a SHUTDOWN IMMEDIATE or a SHUTDOWN NORMAL statement.

Do a full backup of the database, because the CSALTER script cannot be rolled back.

Start up the database.

Run the Database Character Set Scanner utility.

Run the CSALTER script.

Note that the CSALTER script does not perform any user data conversion. It only changes the character set metadata in the data dictionary. Thus, after the CSALTER operation, Oracle behaves as if the database was created using the new character set.

Using the CSALTER Script in an Oracle Real Application Clusters Environment

In an Oracle Real Application Clusters environment, ensure that no other Oracle background processes are running, with the exception of the background processes associated with the instance through which a user is connected, before attempting to issue the CSALTER script. With DBA privileges, use the following SQL statement to verify that no other Oracle background processes are running:

Set the CLUSTER_DATABASE initialization parameter to FALSE to allow the character set change to be completed. Reset it to TRUE after the character set has been changed.

Migrating Character Data Using the CSALTER Script and Selective Imports

Another approach to migrating character data is to perform selective exports followed by rescanning and running the CSALTER script. This approach is most common when the subset character set is single-byte and the migration is to a multibyte character set. In this scenario, user-created CLOB s must be converted because the encoding changes from the single- byte character set to a UCS-2-compatible format which Oracle uses for storage of CLOB s regardless of the multibyte encoding. The Database Character Set Scanner identifies these columns as convertible. It is up to the user to export these columns and then drop them from the schema, rescan, and, if the remaining data is clean, run the CSALTER script. When these steps have been completed, then import the CLOB columns to the database to complete migration.

Migrating to NCHAR Data Types

In Oracle Database, data that is stored in columns of the NCHAR data types is stored exclusively in a Unicode encoding regardless of the database character set. This enables users to store Unicode in a database that does not use Unicode as the database character set.

This section includes the following topics:

Migrating Version 8 NCHAR Columns to Oracle9 i and Later

In version 8 of Oracle Database, Oracle introduced a national character data type ( NCHAR ) that enables a second, alternative character set in addition to the database character set. The NCHAR data types support several fixed-width Asian character sets that were introduced to provide better performance when processing Asian character data.

Beginning with Oracle9 i , the SQL NCHAR data types are limited to Unicode character set encoding (UTF8 and AL16UTF16). Any other version 8 character sets that were available for the NCHAR data types, including Asian character sets such as JA16SJISFIXED are no longer supported.

The steps for migrating existing NCHAR , NVARCHAR2 , and NCLOB columns to NCHAR data types in Oracle9 i and later are as follows:

Export all NCHAR columns from the version 8 or Oracle8 i database.

Drop the NCHAR columns.

Upgrade the database to the later release .

Import the NCHAR columns into the upgraded database.

The migration utility can also convert version 8 and Oracle8 i NCHAR columns to NCHAR columns in later releases. A SQL NCHAR upgrade script called utlnchar.sql is supplied with the migration utility. Run it at the end of the database migration to convert version 8 and Oracle8 i NCHAR columns to the NCHAR columns in later releases. After the script has been executed, the data cannot be downgraded. The only way to move back to version 8 or Oracle8 i is to drop all NCHAR columns, downgrade the database, and import the old NCHAR data from a previous version 8 or Oracle8 i export file. Ensure that you have a backup (export file) of version 8 or Oracle8 i NCHAR data, in case you need to downgrade your database in the future.

Oracle Database Utilities for a description of export and import procedures

Oracle Database Upgrade Guide for NCHAR migration information

Changing the National Character Set

Use the CSALTER script to change the national character set.

Migrating CHAR Columns to NCHAR Columns

You can change a column’s data type definition using the following methods:

The ALTER TABLE MODIFY statement

Online table redefinition

The ALTER TABLE MODIFY statement has the following advantages over online table redefinition:

Online table redefinition has the following advantages over the ALTER TABLE MODIFY statement:

Faster for columns with a large amount of data

Can migrate several columns at one time

Table is available for DML during most of the migration process

Avoids table fragmentation, which saves space and allows faster access to data.

Can be used for migration from the CLOB data type to the NCLOB data type

This section contains the following topics:

Using the ALTER TABLE MODIFY Statement to Change CHAR Columns to NCHAR Columns

The ALTER TABLE MODIFY statement can be used to change table column definitions from the CHAR data types to NCHAR data types. It also converts all of the data in the column from the database character set to the NCHAR character set. The syntax of the ALTER TABLE MODIFY statement is as follows:

If indexes have been built on the migrating column, then dropping the indexes can improve the performance of the ALTER TABLE MODIFY statement because indexes are updated when each row is updated.

The maximum column lengths for NCHAR and NVARCHAR2 columns are 2000 and 4000 bytes. When the NCHAR character set is AL16UTF16, the maximum column lengths for NCHAR and NVARCHAR2 columns are 1000 and 2000 characters, which are 2000 and 4000 bytes. If this size limit is violated during migration, then consider changing the column to the NCLOB data type instead.

CLOB columns cannot be migrated to NCLOB columns using the ALTER TABLE MODIFY statement. Use online table redefinition to change a column from the CLOB data type to the NCLOB data type.

Using Online Table Redefinition to Migrate a Large Table to Unicode

It takes significant time to migrate a large table with a large number of rows to Unicode data types. During the migration, the column data is unavailable for both reading and updating. Online table redefinition can significantly reduce migration time. Using online table redefinition also allows the table to be accessible to DML during most of the migration time.

Perform the following tasks to migrate a table to Unicode data types using online table redefinition:

Use the DBMS_REDEFINITION.CAN_REDEF_TABLE PL/SQL procedure to verify that the table can be redefined online. For example, to migrate the scott.emp table, enter the following command:

Create an empty interim table in the same schema as the table that is to be redefined. Create it with NCHAR data types as the attributes. For example, enter a statement similar to the following:

Start the online table redefinition. Enter a command similar to the following:

If you are migrating CLOB columns to NCLOB columns, then use the TO_NCLOB SQL conversion function instead of the TO_NCHAR SQL function.

Create triggers, indexes, grants, and constraints on the interim table. Referential constraints that apply to the interim table (the interim table is a parent or child table of the referential constraint) must be created in DISABLED mode. Triggers that are defined on the interim table are not executed until the online table redefinition process has been completed.

You can synchronize the interim table with the original table. If many DML operations have been applied to the original table since the online redefinition began, then execute the DBMS_REDEFINITION.SYNC_INTERIM_TABLE procedure. This reduces the time required for the DBMS_REDEFINITION.FINISH_REDEF_TABLE procedure. Enter a command similar to the following:

Execute the DBMS_REDEFINITION.FINISH_REDEF_TABLE procedure. Enter a command similar to the following:

When this procedure has been completed, the following conditions are true:

The original table is redefined so that it has all the attributes, indexes, constraints, grants, and triggers of the interim table.

The referential constraints that apply to the interim table apply to the redefined original table.

Drop the interim table. Enter a statement similar to the following:

The results of the online table redefinition tasks are as follows:

The original table is migrated to Unicode columns.

The triggers, grants, indexes, and constraints defined on the interim table after the START_REDEF_TABLE subprogram and before the FINISH_REDEF_TABLE subprogram are defined for the redefined original table. Referential constraints that apply to the interim table now apply to the redefined original table and are enabled.

The triggers, grants, indexes, and constraints defined on the original table before redefinition are transferred to the interim table and are dropped when you drop the interim table. Referential constraints that applied to the original table before redefinition were applied to the interim table and are now disabled.

PL/SQL procedures and cursors that were defined on the original table before redefinition are invalidated. They are automatically revalidated the next time they are used. Revalidation may fail because the table definition has changed.

Oracle Database Administrator’s Guide for more information about online table redefinition

Post-Conversion Considerations After Character Set Migration

You may need to perform additional tasks to recover a migrated database schema to its original state. Consider the issues described in Table 11-2.

Table 11-2 Issues During Recovery of a Migrated Database Schema

Character WE8MSWIN 1252 Encoding AL32UTF8 Encoding

When table columns are changed from CHAR data types to NCHAR data types by the ALTER TABLE MODIFY statement, indexes that are built on the columns are changed automatically by the database. This slows down performance for the ALTER TABLE MODIFY statement. If you drop indexes before issuing the ALTER TABLE MODIFY statement, then re-create them after migration.

If you disable constraints before migration, then re-enable them after migration.

If you disable triggers before migration, then re-enable them after migration.

If the columns that are migrated to Unicode data types are replicated across several sites, then the changes should be executed at the master definition site. Then they are propagated to the other sites.

The migration from CHAR data types to NCHAR data types involves character set conversion if the database and NCHAR data have different character sets. The binary order of the same data in different encodings can be different. This affects applications that rely on binary order.

You may need to modify your application’s API calls to set the character set form of input and output variables to NCHAR . The exact changes depend on the particular API. Changes required for the common Oracle APIs are described in Chapter 7, «Programming with Unicode».

Урок №35. Символьный тип данных

Обновл. 31 Мар 2020 |

Хоть тип char и относится к целочисленным типам данных (и, таким образом, следует всем их правилам), работа с char несколько отличается, чем с обычными целочисленными типами.

Тип данных char

Переменная типа char занимает 1 байт. Однако, вместо конвертации значения типа char в целое число, оно интерпретируется как символ ASCII.

ASCII (от англ. «American standard code for information interchange») — американский стандартный код для обмена информацией, который определяет способ представления символов английского языка (+ несколько других) в виде чисел от 0 до 127. Например: код буквы ‘а’ — 97, код буквы ‘b’ — 98. Символы всегда помещаются в одинарные кавычки.

Таблица символов ASCII:

Issue Description
Код Символ Код Символ Код Символ Код Символ
NUL (null) 32 (space) 64 @ 96 `
1 SOH (start of header) 33 ! 65 A 97 a
2 STX (start of text) 34 66 B 98 b
3 ETX (end of text) 35 # 67 C 99 c
4 EOT (end of transmission) 36 $ 68 D 100 d
5 ENQ (enquiry) 37 % 69 E 101 e
6 ACK (acknowledge) 38 & 70 F 102 f
7 BEL (bell) 39 71 G 103 g
8 BS (backspace) 40 ( 72 H 104 h
9 HT (horizontal tab) 41 ) 73 I 105 i
10 LF (line feed/new line) 42 * 74 J 106 j
11 VT (vertical tab) 43 + 75 K 107 k
12 FF (form feed / new page) 44 , 76 L 108 l
13 CR (carriage return) 45 77 M 109 m
14 SO (shift out) 46 . 78 N 110 n
15 SI (shift in) 47 / 79 O 111 o
16 DLE (data link escape) 48 80 P 112 p
17 DC1 (data control 1) 49 1 81 Q 113 q
18 DC2 (data control 2) 50 2 82 R 114 r
19 DC3 (data control 3) 51 3 83 S 115 s
20 DC4 (data control 4) 52 4 84 T 116 t
21 NAK (negative acknowledge) 53 5 85 U 117 u
22 SYN (synchronous idle) 54 6 86 V 118 v
23 ETB (end of transmission block) 55 7 87 W 119 w
24 CAN (cancel) 56 8 88 X 120 x
25 EM (end of medium) 57 9 89 Y 121 y
26 SUB (substitute) 58 : 90 Z 122 z
27 ESC (escape) 59 ; 91 [ 123 <
28 FS (file separator) 60 94 ^ 126
31 US (unit separator) 63 ? 95 _ 127 DEL (delete)

Символы от 0 до 31 в основном используются для форматирования вывода. Большинство из них уже устарели.

Символы от 32 до 127 используются для вывода. Это буквы, цифры, знаки препинания, которые большинство компьютеров использует для отображения текста (на английском языке).

Следующие два стейтмента выполняют одно и то же (присваивают переменным типа char целое число 97):

Будьте внимательны при использовании фактических чисел с числами, которые используются для представления символов (с таблицы ASCII). Следующие два стейтмента выполняют не одно и то же:

Вывод символов

При выводе переменных типа char, объект cout выводит символы вместо цифр:

Также вы можете выводить литералы типа char напрямую:

Оператор static_cast

Если вы хотите вывести символы в виде цифр, а не в виде букв, то вам нужно сообщить cout выводить переменные типа char в виде целочисленных значений. Не очень хороший способ это сделать — присвоить переменной типа int переменную типа char и вывести её:

Лучшим способом является конвертация переменной из одного типа данных в другой с помощью оператора static_cast.

Синтаксис static_cast выглядит следующим образом:

static_cast принимает значение из (выражения) в качестве входных данных и конвертирует его в указанный вами .

Пример использования оператора static_cast для конвертации типа char в тип int:

Результат выполнения программы выше:

Запомните, static_cast принимает (выражение) в качестве входных данных. Если мы используем переменную в (выражении) , то эта переменная изменяет свой тип только в стейтменте с оператором static_cast. Процесс конвертации никак не влияет на исходную переменную с её значением! В примере выше, переменная ch остаётся переменной типа char с прежним значением, чему является подтверждением последний стейтмент с cout.

Также в static_cast нет никакой проверки по диапазону, так что если вы попытаетесь использовать числа, которые слишком большие или слишком маленькие для конвертируемого типа, то произойдёт переполнение.

Более подробно о static_cast мы ещё поговорим в соответствующем уроке.

Ввод символов

Следующая программа просит пользователя ввести символ. Затем она выводит этот символ и его ASCII код:

Результат выполнения программы выше:

Input a keyboard character: q
q has ASCII code 113

Обратите внимание, даже если cin позволит вам ввести несколько символов, переменная ch будет хранить только первый символ (именно он и помещается в переменную). Остальная часть пользовательского ввода останется во входном буфере, который использует cin и будет доступна для использования последующим вызовам cin.

Рассмотрим это всё на практике:

Результат выполнения программы выше:

Input a keyboard character: abcd
a has ASCII code 97
b has ASCII code 98

Размер, диапазон и знак типа сhar

В С++ для переменных типа char всегда выделяется 1 байт. По умолчанию, char может быть как signed, так и unsigned (хотя обычно signed). Если вы используете char для хранения ASCII символов, то вам не нужно указывать знак переменной (так как и signed, и unsigned могут содержать значения от 0 до 127).

Но если вы используете тип char для хранения небольших целых чисел, то тогда следует уточнить знак. Переменная типа char signed может хранить числа от -128 до 127. Переменная типа char unsigned имеет диапазон от 0 до 255.

Управляющие символы

В C++ есть управляющие символы (или ещё «escape-последовательность»). Они начинаются с бэкслэша (‘\‘), а затем определённой буквы или цифры.

Наиболее распространённым управляющим символов в С++ является ‘\n’ , который обозначает символ новой строки:

First line
Second line

Ещё одним часто используемым управляющим символом является ‘\t’ , который заменяет клавишу TAB, вставляя большой отступ:

First part Second part

Таблица всех управляющих символов в C++:

Название Символ Значение
alert \a Предупреждение (звуковой сигнал)
backspace \b Перемещение курсора на одну позицию назад
formfeed \f Перемещение курсора к следующей логической странице
newline \n Перемещение курсора на следующую строку
carriage return \r Перемещение курсора в начало строки
horizontal tab \t Вставка горизонтального TAB-а
vertical tab \v Вставка вертикального TAB-а
single quote \’ Вставка одинарной кавычки (или апострофа)
double quote \” Вставка двойной кавычки
backslash \\ Вставка обратной косой черты (бэкслэша)
question mark \? Вставка знака вопроса
octal number \(number) Перевод числа из восьмеричной системы счисления в тип char
hex number \x(number) Перевод числа из шестнадцатеричной системы счисления в тип char

Рассмотрим пример в коде:

Результат выполнения программы выше:

«This is quoted text»
This string contains a single backslash \
6F in hex is char ‘o’

Что использовать: ‘\n’ или std::endl?

Вы могли заметить, что в последнем примере мы использовали ‘\n’ для перемещения курсора на следующую строку. Но мы могли бы использовать и std::endl . Какая между ними разница? Сейчас разберёмся.

При использовании std::cout данные для вывода могут помещаться в буфер, т.е. std::cout может не отправлять данные сразу же на вывод. Вместо этого он может оставить их при себе на некоторое время. Это делается исходя из соображений производительности.

И ‘\n’ , и std::endl оба переносят курсор на следующую строку. Только std::endl ещё гарантирует, что все данные из буфера будут выведены, перед тем, как продолжить.

Так когда же использовать ‘\n’ , а когда std::endl ?

Используйте std::endl , когда нужно, чтобы ваши данные выводились сразу же (например: при записи в файл или при обновлении индикатора состояния какого-либо процесса). Обратите внимание, это может повлечь за собой незначительное снижение производительности, особенно если запись на устройство происходит медленно (например, запись файла на диск).

Используйте ‘\n’ во всех остальных случаях.

Другие символьные типы: wchar_t, char16_t и char32_t

wchar_t следует избегать практически во всех случаях (кроме тех, когда происходит взаимодействие с Windows API).

Так же, как и стандарт ASCII использует целые числа для представления символов английского языка, так и другие кодировки используют целые числа для представления символов других языков. Наиболее известный стандарт (после ASCII) — Unicode, который имеет в запасе более 110 000 целых чисел для представления символов из разных языков. Есть следующие кодировки Unicode:

UTF-32: требует 32 бита для представления символа.

UTF-16: требует 16 бит для представления символа.

UTF-8: требует 8 бит для представления символа.

char16_t и char32_t были добавлены в C++11 для поддержки 16-битных и 32-битных символов Unicode (8-битные символы и так поддерживаются типом char).

В чём разница между одинарными и двойными кавычками при использовании с символами?

Как вы уже знаете, символы всегда помещаются в одинарные кавычки (например: ‘а’ , ‘+’ , ‘5’ ). Переменная типа char представляет только один символ (например: букву а , символ + , число 5 ). Что-то вроде следующего не является корректным:

Текст, который находится в двойных кавычках, называется строкой (например, “Hello, world!”). Строка (тип string) — это набор последовательных символов.

Вы можете использовать литералы типа string в коде:

Более подробно о string мы поговорим в соответствующем уроке.

Использование кодировок в MySQL >= 4.1

Когда я только начал осваивать InnoDB и транзакции в MySQL (понадобилось обновить версию с 3.23 до 4.1) столкнулся с проблемой некорректного обмена данными между PHP и MySQL которая проявлялась в том, что сервер вместо символов кириллицы, в запросах генерируемых php-скриптом, вставлял в ячейки таблиц БД знаки вопроса. В процессе «выкуривания» документации, чтения форумов и изучения статей пришло понимание проблемы и нашелся способ ее решения.

Первопричиной проблемы оказалось то, что до версии 4.1 кодировку можно было задать только для всего сервера (определив значение параметра —default-charset ), а начиная с версии 4.1 разработчики добавили возможность определения кодировки на разных уровнях иерархии СУБД (для всего сервера, БД, таблиц, столбцов).

Немного терминологии

CHARACTER SET — это некий набор символов, называемых кодировкой. Разные CHARACTER SET включают в себя различные наборы символов. Различные CHARACTER SET могут включать примерно одинаковые наборы символов но в различном порядке (см. например koi8ru и cp1251). MySQL необходимо знать какой CHARACTER SET будет использован для данных в таблице, чтобы корректно проводтиь сортировку и индексацию данных.

COLLATION — способ, с помощью которого следует упорядочивать и сравнивать данные в БД.
Для одного и того же CHARACTER SET существует как правило несколько COLLATION. Например: cp1251_general_ci — сравнение не чувствительное к регистру, cp1251_bin — чувствительное к регистру.

Для того чтобы избежать проблем с кодировками нужно иметь представление о том, как для разных уровней иерархии СУБД их можно задать.

Способы задания кодировок

1) Для всего сервера при компиляции, определив параметры —with-charset и —with-collation :

Работа с клиентскими программами

Любой mysql-клиент при соединении с сервером может установить несколько переменных:

  • character_set_client — указывает, в какой кодировке будут поступать данные от клиента;
  • character_set_connection — указывает, в какую кодировку следует преобразовать данные полученые от клиента перед выполнением запроса;
  • collation_connection — указывает, каким образом сравнивать между собой строки в запросах;
  • character_set_results — указывает серверу не необходимость перекодировать результаты запроса в определенную кодировку перед выдачей их клиенту.

Для корректной работы клиента с сервером следует установть как минимум character_set_client, character_set_connection, character_set_results при помощи оператора SET:

Что такое код выхода 201 в Free Pascal?

Я попытался сделать простую игру змеи с Free Pascal, когда я запустил программу, она нарисовала карту точно, что я хочу, но после этого я нажал кнопку, которую я установил для управления змеей, и она вышла с кодом выхода 201,

Я мало знаю об этом коде выхода, не могли бы вы объяснить мне проблемы программы? Это самая длинная программа, которую я когда-либо делал с Pascal.

Я googled это: 201: range error , поэтому вы, вероятно, выходите из границ массива. Единственный массив s индексируется переменными, которые зависят от значения l (странное имя, BTW). Но я вижу одно место, где вы изменяете (увеличиваете) эту переменную и не видите никакой инициализации l . Таким образом, вы используете произвольное начальное значение (здесь, возможно, ноль, потому что l является глобальным).

Обратите внимание, что вы можете обнаружить эту ошибку (и, возможно, другие) с помощью простой отладки.

Например, код 201 объясняется здесь: Ошибка выполнения 201 в fpc

Именно поэтому это происходит в вашем коде, я не знаю.

Pascal-Паскаль

Программирование. Строки и символы Pascal-Паскаль

  • Скачено бесплатно: 6869
  • Куплено: 414
  • Pascal-Паскаль->Программирование. Строки и символы Pascal-Паскаль

Программирование. Строки и символы Pascal-Паскаль

Строки Pascal-Паскаль

Строка представляет собой особую форму одномерного массива символов, которая имеет существенное отличие. Массив символов имеет фиксированную длину (количество элементов), которая определяется при описании. Строка имеет две разновидности длины:

  • Общая длина строки, которая характеризует размер памяти, выделяемый строке при описании;
  • Текущая длина строки (всегда меньше или равна общей длине), которая показывает количество смысловых символов строки в каждый конкретный момент времени.

Строка в Паскале – упорядоченная последовательность символов. Количество символов в строке называется ее длиной. Длина строки в Паскале может лежать в диапазоне от 0 до 255. Каждый символ строковой величины занимает 1 байт памяти и имеет числовой код в соответствии с таблицей кодов ASCII.

Код ASCII (American Code for Information Interchange – Американский стандартный код для обмена информацией) имеет основной стандарт и его расширение. Основной стандарт использует шестнадцатеричные коды 00-7F, расширение стандарта – 80-FF. Основной стандарт является международным и используется для кодирования управляющих символов, цифр и букв латинского алфавита; в расширении стандарта используются символы псевдографики и буквы национальных алфавитов.

32 пробел 48 0 64 @ 80 P 96 ` 112 p
33 ! 49 1 65 A 81 Q 97 a 113 q
34 « 50 2 66 B 82 R 98 b 114 r
35 # 51 3 67 C 83 S 99 c 115 s
36 $ 52 4 68 D 84 T 100 d 116 t
37 % 53 5 69 E 85 U 101 e 117 u
38 & 54 6 70 F 86 V 102 f 118 v
39 ‘ 55 7 71 G 87 W 103 g 119 w
40 ( 56 8 72 H 88 X 104 h 120 x
41 ) 57 9 73 I 89 Y 105 i 121 y
42 * 58 : 74 J 90 Z 106 j 122 z
43 + 59 ; 75 K 91 [ 107 k 123 <
44 , 60 78 N 94 ^ 110 n 126
47 / 63 ? 79 O 95 _ 111 o 127

Строковая константа Паскаля – последовательность символов, заключенная в апострофы. Например, ‘строковая константа’, ‘243’. Два следующих друг за другом апострофа (») обозначают пустую строку, т.е. строку с нулевой длиной.

Описание строковой переменной Паскаля

Для описания строковых переменных в Паскале существует предопределенный тип string.

В общем виде описание строковой переменной будет выглядеть следующим образом:

Пример описания строковой переменной в Паскале:

В приведенном выше описании строковая переменная s1 может содержать не более 10 символов, переменная s2 – не более 20 символов. Если же при описании строки ее максимальная длина не указывается, то по умолчанию принимается максимально допустимая длина, равная 255 символам (переменная smax)..

Символы в строке упорядочены, каждый из них имеет порядковый номер, начиная с первого. Имеется возможность обратиться к любому элементу строки, указав его номер, так же как это делается в одномерных массивах. Например, s1[2] позволяет обратиться ко второму символу в строке s1, при этом мы можем поменять это значение, выполнив оператор присваивания s1[2]:= ‘r’, можем вывести на экран это значение или присвоить его другой переменной.

Действия со строками в Паскале

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

Операции отношения позволяют сравнивать строки на отношение равенства (=), неравенства (<>), больше (>), меньше ( =), меньше или равно ( Пример действий со строками в Паскале:

‘строка’<>‘строки’ (верно, т.к. не совпадают последние символы);

‘Abc’ ‘век’ (отношение верно, т.к. буква ‘г’ в алфавите стоит после буквы ‘в’, а, следовательно, имеет больший код).

Стандартные функции для работы со строками в Паскале

Copy (S, poz, n) выделяет из строки S, начиная с позиции poz, подстроку из n символов. Здесь S – любое строковое выражение, poz, n – целочисленные выражения.

Значение S Выражение Результат
‘строка символов’ Copy(S,3,3) рок

Concat (s1, s2. sn) выполняет слияние строк s1, s2. sn в одну строку.

Выражение Результат
Concat(‘язык’, », ‘Pascal’) ‘язык Pascal’

Length(S) определяет текущую длину строкового выражения S. Результат – значение целого типа.

Значение S Выражение Результат
‘(а+в)*с’ Length(s) 7

Pos(subS, S) определяет позицию первого вхождения подстроки subS в строку S. Результат – целое число, равное номеру позиции, где находится первый символ искомой подстроки. Если вхождение подстроки не обнаружено, то результат функции будет равен 0.

Значение S Выражение Результат
‘предложение’ Pos(‘е’, S) 3
‘предложение’ Pos(‘a’, S)

Стандартные процедуры для работы со строками в Паскале

Delete (S, poz, n) удаляет из строки S, начиная с позиции poz, подстроку из n символов. Здесь S – строковая переменная (в данном случае нельзя записать никакое другое строковое выражение, кроме имени строковой переменной, т.к. только с именем переменной связана область памяти, куда будет помещен результат выполнения процедуры); poz, n – любые целочисленные выражения.

Исходное значение S Оператор процедуры Конечное зн-е S
‘abcdefg’ Delete(s, 2, 3) ‘aefg’

Insert(subS, S, poz) вставляет в строку S, начиная с позиции poz, подстроку subS. Здесь subS – любое строковое выражение, S – строковая переменная (именно ей будет присвоен результат выполнения процедуры), poz – целочисленное выражение.

Исходное значение S Оператор процедуры Конечное зн-е S
‘рис. 2’ Insert(‘№’, S, 6) ‘рис. №2’

Процедуры преобразования типов в Паскале

Str(x, S) преобразует число x в строковый формат. Здесь x – любое числовое выражение, S – строковая переменная. В процедуре есть возможность задавать формат числа x. Например, str(x: 8: 3, S), где 8 – общее число знаков в числе x, а 3 – число знаков после запятой.

Оператор процедуры Значение S
Str (sin(1):6:4, S) ‘0.0175’
Str (3456, S) ‘3456’

Val(S, x, kod) преобразует строку символов S в число x. Здесь S – строковое выражение, x – числовая переменная (именно туда будет помещен результат), kod – целочисленная переменная (типа integer), которая равна номеру позиции в строке S, начиная с которой произошла ошибка преобразования, если преобразование прошло без ошибок, то переменная kod равна 0.

Тип X Оператор процедуры Значение X Значение kod
Real Val(‘12.34’, x, kod) 12.34
Integer Val(‘12.34’, x, kod) 12 3

Программирование

Исходники Pascal (127)

Справочник

Справочник по паскалю: директивы, функции, процедуры, операторы и модули по алфавиту

Илон Маск рекомендует:  Создание окна messagebox
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL