что такое UTF-8

UTF-8 (от англ. Unicode Transformation Format — формат преобразования Юникода) — в настоящее время распространённая кодировка, реализующая представление Юникода, совместимое с 8-битным кодированием текста.

Текст, состоящий только из символов с номером меньше 128, при записи в UTF-8 превращается в обычный текст ASCII. И наоборот, в тексте UTF-8 любой байт со значением меньше 128 изображает символ ASCII с тем же кодом. Остальные символы Юникода изображаются последовательностями длиной от 2 до 6 байтов (реально только до 4 байт, поскольку использование кодов больше 221 не планируется) , в которых первый байт всегда имеет вид 11xxxxxx, а остальные — 10xxxxxx.

Проще говоря, в формате UTF-8 символы латинского алфавита, знаки препинания и управляющие символы ASCII записываются кодами US-ASCII, a все остальные символы кодируются при помощи нескольких октетов со старшим битом 1. Это приводит к двум эффектам.

* Даже если программа не распознаёт Юникод, то латинские буквы, арабские цифры и знаки препинания будут отображаться правильно.
* В случае, если латинские буквы и простейшие знаки препинания (включая пробел) занимают существенный объём текста (например, в европейских языках, включая основанные на кириллице) , UTF-8 даёт выигрыш по объёму по сравнению с UTF-16.[1][2]
* На первый взгляд может показаться, что UTF-16 удобнее, так как в ней большинство символов кодируется ровно двумя байтами. Однако это сводится на нет необходимостью поддержки суррогатных пар, о которых часто забывают при использовании UTF-16, реализовывая лишь поддержку символов UCS-2.[1]

Формат UTF-8 был изобретён 2 сентября 1992 года Кеном Томпсоном и Робом Пайком и реализован в Plan 9[3]. Сейчас стандарт UTF-8 официально закреплён в документах RFC 3629 и ISO/IEC 10646 Annex D.

кодировка кириллическая

Что такое UNICODE_FSS
Это кодовая страница InterBase (в народе, она называется UTF-8), которая отображает двухбайтные и четырех байтные символы UNICODE (UCS-2 и UCS-4, соответственно) в последовательности символов размером от одного до шести байт. Основными пред назначениями этого извращения являются:

Предоставление транспорта для UNICODE текста на базе обычного ASCII текста.
Упаковка данных. Символы с кодом меньше 128 по-прежнему представляются в виде одного байта
Между UTF-8 и UCS-2 (UCS-4) существует взаимное и однозначное преобразование, которое основано на использовании следующей таблицы:

Bits
Hex Min
Hex Max
UTF-8 Binary Encoding

7
00000000
0000007F
0xxxxxxx

11
00000080
000007FF
110xxxxx 10xxxxxx

16
00000800
0000FFFF
1110xxxx 10xxxxxx 10xxxxxx

21
00010000
001FFFFF
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

26
00200000
03FFFFFF
111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

31
04000000
7FFFFFFF
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

UNICODE формат, с которым, как правило, мы имеем дело при программировании под Windows, представляет собой двухбайтные символы - UCS-2. Как видно из таблицы, для представления UNICODE символов с кодом от 0x0000 до 0xFFFF в формате UTF-8 достаточно от одного до трех байт.

InterBase также исходит из того, что в UTF-8 будут храниться UNICODE символы из диапазона [0x0000,0xFFFF]. Поэтому, при определении количества байт для хранения текстовых данных с кодовой страницей UNICODE_FSS, умножает число символов на 3 байта. Кроме того, все текущие версии InterBase, при работе с CHAR/VARCHAR данными, контролируют число байт в представлении данных, а не число символов. Поэтому, например, в колонку CHAR(3) с кодовой страницей UNICODE_FSS можно без проблем записать до девяти однобайтных символов.

Основным неудобством UTF-8 является невозможность определения количества символов в строке без её полного просмотра. Поэтому для внутренней работы текстовые данные в формате UTF-8 лучше всего перекодировать в кодовую страницу с символами фиксированного размера, например в тот же UCS-2.

Создание базы данных с использованием UNICODE_FSS
Ничего экзотического, все как обычно - create database ...default character set unicode_fss.

Подключение к базе данных с кодовой страницей UNICODE_FSS
Существует устойчивое мнение, что при создании конструкций базу данных мы можем использовать одну кодовую страницу, а при подключении к базе данных – использовать другую. Отчасти это так – сервер, при общении с клиентом, пытается перекодировать текстовые данные. Однако у этого механизма существуют ограничения и исключения, которые (если не забуду) будут описаны далее, поэтому лучше не экспериментировать и при подключении к базе данных указывать именно ту кодовую страницу, которая использована при создании базы данных. В нашем случае это UNICODE_FSS. Это означает, что мы хотим получать текстовые данные в формате UTF-8, и будем передавать текст в этом же формате.

Работа с базой данных
Обмен с сервером подразумевает следующие категории данных

Обычные текстовые колонки с типом CHAR, VARCHAR
Текстовые BLOB поля
Массивы
Текст SQL запроса.
Текстовые колонки
При чтении текстовых колонок сервер требует предоставить буфер размером (максимальный размер символа) *(число символов) . Именно такое значение будет указано в XSQLVAR.sqllen после подготовки текста запроса на выборку данных. То есть вы не должны предпринимать какие-либо усилия для вычисления размера буфера под данные текстовой колонки. Просто используйте указанное значение. Только не забывайте, что для VARCHAR колонок (тип SQL_VARYING) к указанному значению нужно добавлять 2 байта, чтобы выделить место под индикатор длины колонки. Длина будет возвращена в байтах.

Кстати говоря, одной из недокументированных возможностей InterBase является то, что для текстовых колонок в XSQLVAR.subtype в младшем байте указывается номер кодой страницы колонки,

UTF-8 (от англ. Unicode Transformation Format — формат преобразования Юникода) — в настоящее время распространённая кодировка, реализующая представление Юникода, совместимое с 8-битным кодированием текста.

Текст, состоящий только из символов с номером меньше 128, при записи в UTF-8 превращается в обычный текст ASCII. И наоборот, в тексте UTF-8 любой байт со значением меньше 128 изображает символ ASCII с тем же кодом. Остальные символы Юникода изображаются последовательностями длиной от 2 до 6 байтов (реально только до 4 байт, поскольку использование кодов больше 221 не планируется) , в которых первый байт всегда имеет вид 11xxxxxx, а остальные — 10xxxxxx.

Проще говоря, в формате UTF-8 символы латинского алфавита, знаки препинания и управляющие символы ASCII записываются кодами US-ASCII, a все остальные символы кодируются при помощи нескольких октетов со старшим битом 1. Это приводит к двум эффектам.

* Даже если программа не распознаёт Юникод, то латинские буквы, арабские цифры и знаки препинания будут отображаться правильно.
* В случае, если латинские буквы и простейшие знаки препинания (включая пробел) занимают существенный объём текста (например, в европейских языках, включая основанные на кириллице) , UTF-8 даёт выигрыш по объёму по сравнению с UTF-16.[1][2]
* На первый взгляд может показаться, что UTF-16 удобнее, так как в ней большинство символов кодируется ровно двумя байтами. Однако это сводится на нет необходимостью поддержки суррогатных пар, о которых часто забывают при использовании UTF-16, реализовывая лишь поддержку символов UCS-2.[1]

Формат UTF-8 был изобретён 2 сентября 1992 года Кеном Томпсоном и Робом Пайком и реализован в Plan 9[3]. Сейчас стандарт UTF-8 официально закреплён в документах RFC 3629 и ISO/IEC 10646 Annex D.