UTF-8

UTF-8 — Unicode code pointlarini 1 dan 4 baytgacha bo‘lgan o‘zgaruvchan uzunlikdagi ketma-ketlik bilan kodlaydigan character encoding.

UTF-8 web, Linux, API, database va zamonaviy dasturlash muhitlarida eng keng tarqalgan text encodinglardan biridir.

U ASCII bilan to‘liq bayt darajasida mos: U+0000–U+007F belgilar aynan bir bayt bilan saqlanadi.

O‘zgaruvchan uzunlik

Code point diapazoniga qarab baytlar soni:

Code point	Bayt soni
U+0000–U+007F	1
U+0080–U+07FF	2
U+0800–U+FFFF	3
U+10000–U+10FFFF	4

Masalan, lotin ASCII harfi 1 bayt, ko‘p kirill va arab harflari 2 bayt, ko‘p emoji 4 bayt bo‘lishi mumkin.

Bayt patterni

UTF-8 leading byte ketma-ketlik uzunligini bildiradi.

0xxxxxxx
110xxxxx 10xxxxxx
1110xxxx 10xxxxxx 10xxxxxx
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

Davomiy baytlar 10 prefiksi bilan boshlanadi.

Bu parserga sequence chegarasini aniqlashga yordam beradi.

ASCII mosligi

ASCII matn UTF-8da o‘zgarmaydi.

Masalan:

A → 0x41

Shu sababli eski ASCII protocol va vositalar UTF-8ning ASCII qismi bilan ishlay oladi.

ASCII bo‘lmagan belgilar esa ko‘p baytli.

Code point va bayt

String uzunligini baytlar soni bilan o‘lchash foydalanuvchi ko‘radigan belgilar soniga teng emas.

Masalan:

ASCII A — 1 bayt;
ayrim lotin kengaytmasi — 2 bayt;
o‘zbek kirill harfi — 2 bayt;
emoji — 4 bayt;
combining sequence — bir nechta code point.

Database column va protocol limitlari baytmi, code pointmi yoki grapheme clustermi aniq belgilanadi.

Self-synchronization

Continuation byte 10 bilan boshlangani sababli tasodifiy o‘rtadan boshlab oldinga yurib keyingi character chegarasini topish mumkin.

ASCII baytlar boshqa multi-byte sequence ichida paydo bo‘lmaydi.

Bu qidiruv va error recovery uchun qulay.

Valid sequence

UTF-8 decoder quyidagilarni rad etishi kerak:

continuation byte noto‘g‘ri joyda;
sequence tugallanmagan;
code point diapazondan tashqari;
surrogate code point;
overlong encoding;
taqiqlangan leading byte.

Strict decoding security uchun muhim.

Overlong encoding

Bir code point minimaldan ko‘proq bayt bilan ifodalansa overlong encoding deyiladi.

Masalan, ASCII NULni ikki baytli shaklda kodlash valid emas.

Eski decoderlar qabul qilsa, filter va parser bir baytlarni turlicha talqin qilishi mumkin.

Invalid UTF-8

Invalid sequence bilan ishlash siyosati:

xato qaytarish;
replacement character U+FFFD;
baytlarni yo‘qotish;
pass-through;
maxsus escape.

Security-sensitive parser strict rejim ishlatishi mumkin.

Text editor esa faylni ochish uchun replacement ko‘rsatishi mumkin.

BOM

UTF-8 byte orderga bog‘liq emas, shuning uchun BOM talab qilinmaydi.

UTF-8 BOM baytlari:

EF BB BF

Ba’zi Windows vositalari encoding belgilash uchun qo‘shadi.

Unix shebang yoki protocol boshida BOM keraksiz belgiga aylanishi mumkin.

Encoding va decoding

Encoding:

Unicode code point → UTF-8 baytlar

Decoding:

UTF-8 baytlar → Unicode code point

Baytlarni noto‘g‘ri ISO-8859-1 yoki Windows-1252 sifatida decode qilish mojibake yaratadi.

Mojibake

UTF-8 baytlar boshqa encoding sifatida o‘qilganda g‘alati belgilar paydo bo‘ladi.

Masalan, bitta Unicode belgi bir nechta noto‘g‘ri lotin belgilariga aylanishi mumkin.

Muammoni tuzatish uchun asl baytlar va qaysi bosqichda noto‘g‘ri decode bo‘lgani aniqlanadi.

Noto‘g‘ri matnni qayta encode qilish ba’zan ma’lumotni yanada buzadi.

Database

Database connection, table column va client encoding mos bo‘lishi kerak.

Tekshiriladi:

database encoding;
connection encoding;
driver;
collation;
column type;
migration;
index length.

“UTF-8” nomi ayrim database mahsulotlarida tarixan Unicode’ning to‘liq 4-bayt diapazonini qamramagan variantni anglatgan bo‘lishi mumkin.

JSON

JSON Unicode text format.

Networkda JSON odatda UTF-8 bilan uzatiladi.

Parser invalid UTF-8, escaped surrogate va duplicate key siyosatini aniq boshqaradi.

Headerdagi charset va haqiqiy baytlar mos bo‘lishi kerak.

URL

URL ichida ASCII bo‘lmagan text UTF-8 baytlariga aylantirilib percent-encoding qilinishi mumkin.

Masalan:

bayt → %HH

Percent decoding va UTF-8 decoding ikki alohida bosqich.

Ikki marta decode qilish security xatosiga olib kelishi mumkin.

File

Text faylning o‘zida encoding metadata bo‘lmasligi mumkin.

Vosita UTF-8ni default qabul qiladi yoki BOM, config va detectiondan foydalanadi.

Encoding detection taxminiy; barcha bayt ketma-ketligi uchun ishonchli aniqlash mumkin emas.

Normalization

UTF-8 bir xil ko‘rinadigan Unicode matnning turli normalization shakllarini saqlashi mumkin.

UTF-8 validity matn NFC ekanini bildirmaydi.

Search, filename va unique key uchun normalization alohida qo‘llanadi.

Security

UTF-8 bilan bog‘liq xavflar:

invalid sequence;
overlong encoding;
mixed normalization;
confusable;
bidi control;
byte va character limit farqi;
truncation sequence o‘rtasida;
double decoding.

Barcha qatlam bir xil strict decoder va normalization policy ishlatishi kerak.

Diagnostika

UTF-8 muammosida:

raw hex baytlar;
decoder;
invalid offset;
BOM;
database connection;
HTTP charset;
normalization;
byte length;
double encoding;
replacement character

tekshiriladi.

U+FFFD ko‘rinishi xato aynan shu joyda yaratilganini emas, oldingi decodingda ma’lumot yo‘qolganini bildirishi mumkin.

Truncation

UTF-8 stringni bayt limiti bo‘yicha kesishda multi-byte sequence o‘rtasida to‘xtash mumkin. Kesishdan keyin oxirgi to‘liq code point chegarasi topiladi. UI limiti uchun grapheme cluster chegarasi ham hisobga olinadi.

Sort tartibi

UTF-8 baytlarning lexicographic tartibi code point tartibiga ma’lum darajada mos, ammo foydalanuvchi kutgan alifbo tartibini bermaydi. Locale-aware collation alohida ishlatiladi.

Bog‘liq tushunchalar

Unicode, Character encoding, Code point, ASCII, UTF-16, UTF-32, BOM, Mojibake, Normalization, Percent-encoding