UTF-8

UTF-8 (Unicode Dönüşüm Biçimi, 8 bit), Unicode karakterleri için değişken genişlikli bir kodlamadır. Her kod noktası değerine bağlı olarak 1-4 bayta kodlanır: ASCII karakterleri (U+0000 ile U+007F) bir bayt alır; yaygın Latin uzantıları ve Yunanca/Kirilce iki; CJK ideografları üç; emojiler ve nadir yazı sistemleri dört.

1992'de Ken Thompson ve Rob Pike tarafından tasarlanmıştır; öncelikle Plan 9 için. Temel özellikler:

• ASCII uyumlu. Saf ASCII metni, bayt bayt geçerli UTF-8'dir.
• Kendinden senkronize. Bir akış karakter ortasında bozulursa, kod çözücü geri sarmadan bir sonraki karakter sınırını bulabilir.
• Bayt sırası sorunu yok. Baytlar soldan sağa işlenir; büyük endian ile küçük endian ayrımı yoktur.
• Latin yazı sistemleri için kompakt, CJK ağırlıklı içerik için UTF-16'dan daha az kompakt (karakter başına 2 bayt yerine 3).

UTF-8, webde baskın kodlamadır — 2024 itibarıyla sayfaların %98'inden fazlası. HTML5, JSON (RFC 8259 spesifikasyonu aslında UTF-8'i zorunlu kılar) ve hemen her modern protokolün varsayılanıdır. Eski kodlamalar (Windows-1252, ISO-8859-1, Shift-JIS) eski sistemlerde varlığını sürdürmektedir; ancak modern bir yığına her girişte dönüştürülmelidir.

BOM (Bayt Sırası İşareti) tartışması: UTF-16 ve UTF-32, bayt sırasını belirtmek için dosyanın başına 2 veya 4 baytlık bir BOM ekler; ancak UTF-8'in belirtecek bir bayt sırası yoktur. Microsoft araçları, Unix araçları genellikle eklemezken alışkanlıkla 3 baytlık UTF-8 BOM'u (EF BB BF) başa ekler. Sonuç: Notepad'den kaydedilen kabuk betikleri bozulur, CSV içe aktarmaları ilk hücrede görünmez gereksiz veri gösterir ve YAML/JSON ayrıştırıcıları dosyayı reddeder. Unicode standardı UTF-8 BOM'una izin verir ama zorunlu kılmaz; modern öneri "ekleme"dir. BOM'lu bir dosya alırsanız okumada soyun.

Dize uzunluğu ile bayt uzunluğu — sürekli karşılaşılan tuzak: çoğu dilde "hello".length 5 (karakter) döndürür; ancak Buffer.byteLength("hello", "utf8") 5 (bayt — ASCII için eşit) döndürür. "café" için karakter uzunluğu 4 ama bayt uzunluğu 5'tir (é 2 bayttır). "🎉" için JavaScript'teki karakter uzunluğu 2'dir (vekil çift) ama bayt uzunluğu 4, grafem uzunluğu ise 1'dir. UTF-8 dizelerini grafem farkındalığı olmadan bayt sayısına göre kesmek düzenli olarak bozuk karakter üretir — standart düzeltme Intl.Segmenter API'sini (modern tarayıcılar) veya graphemer npm paketini kullanmaktır. Kaynak: RFC 3629 — UTF-8, ISO 10646'nın dönüşüm biçimi.

Çözümlü örnek

"A€🎉" dizesini kodlayın. Her karakterin kod noktası ve UTF-8 bayt dizisi: A (U+0041) → 1 bayt 0x41. € (U+20AC) → 3 bayt 0xE2 0x82 0xAC (yüksek bitler uzunluğu kodlar: 1110xxxx 10xxxxxx 10xxxxxx). 🎉 (U+1F389) → 4 bayt 0xF0 0x9F 0x8E 0x89. Toplam: 3 karakter için 8 bayt. UTF-8 karakter semantikli VARCHAR(10) olarak tanımlanmış bir veritabanı sütununda (modern PostgreSQL, utf8mb4 ile MySQL) bu rahatlıkla sığar. VARCHAR(10) BYTES olarak tanımlanmış sabit bayt sütununda (aslında 3 baytla sınırlı olan eski MySQL utf8) emojinin 4 baytlık kodlaması sığmaz — kanonik "MySQL'de emoji saklanamıyor" başarısızlık modu. MySQL 5.5.3'ten bu yana düzeltme, sütun ve bağlantı karakter seti olarak utf8mb4 kullanmaktır.

Ne zaman ve neden önem taşır

Modern webde işlediğiniz her baytın büyük olasılıkla UTF-8 olduğunu söylemek mümkün; ancak birkaç katman hâlâ yanlış yapıyor. Açık Content-Type: text/...; charset=utf-8 olmayan HTTP istekleri, eski proxy'lerde varsayılan olarak ISO-8859-1'e düşebilir; eski anabilgisayar ETL işleri, alımda dönüştürülmesi gereken EBCDIC dosyaları teslim eder; Windows konsol çıktısı, sistem kod sayfasına (çoğu ABD-İngilizcesi kurulumunda CP-1252) varsayılan olarak ayarlanır ve önce bir chcp 65001 olmadan aktarılan metni bozar. Savunmacı pratik: UTF-8'i her yerde açıkça belirtin (HTML <meta charset="utf-8">, HTTP başlıkları, dosya kodlaması pragmaları, veritabanı bağlantı karakter setleri) ve gelen her baytı UTF-8 gramerine göre doğrulayın — geçersiz bayt dizileri, yukarı akıştaki bir karakter seti uyumsuzluğunun güvenilir işaretidir. Kaynak: WHATWG Kodlama Standardı.