RFC 9839 ve Sorunlu Unicode

• RFC 9839, yazılım geliştirme sırasında metin alanlarında yer alabilecek sorunlu Unicode karakterlerini açık biçimde tanımlar
• Bu RFC, farklı diller ve kütüphaneler arasında bu karakterlerin işlenmesindeki tutarsızlıktan doğan sorunları ele alır
• 9839, daha az sorunlu olan üç alt küme önerir ve bunların isteğe bağlı olarak kullanılabileceğini belirtir
• Mevcut PRECIS framework ile karşılaştırıldığında uygulanması daha kolay ve daha basittir
• RFC 9839 için bir Go dili kütüphanesi de birlikte yayımlandı ve pratik kullanımda yardımcı oluyor

---

Arka plan ve RFC 9839'a genel bakış

• Unicode, neredeyse tüm metin verisi işlemede standart olarak kullanılır
• Ancak gerçek veri yapıları veya protokol tasarımı sırasında tüm Unicode karakterlerine izin vermek sorun yaratabilir
• Paul Hoffman ve yazar, tekrar eden Unicode sorunları için net ölçütler sunmak amacıyla IETF'ye bireysel taslak sundu
• İki yıllık tartışmanın ardından resmî standart olarak kabul edildi ve RFC 9839 olarak yayımlandı
• Bu belge, sorunlu karakter türlerini, neden sorunlu olduklarını (teknik ve standart gerekçeleriyle) ve kullanıcıların seçip kullanabileceği üç alt kümeyi ayrıntılı biçimde açıklar

RFC 9839'un ana içeriği

• Yazılım ve ağ ortamlarında metin alanı tasarlanırken mutlaka başvurulması gereken bir belgedir
• RFC 9839, 10 sayfa uzunluğundadır ve IETF standart belgeleri arasında kısa sayılır
• Temelde yazılım geliştiriciler ve ağ mühendisleri için kolay anlaşılır biçimde yazılmıştır

Sorunlu Unicode karakterlerine örnekler

• Örnek olarak JSON içindeki username alanına aşağıdaki gibi bir dize gelebilir

  {  
      "username": "\u0000\u0089\uDEAD\uD9BF\uDFFF"  
  }  
  

• Her kod noktasının taşıdığı sorunlar
  • U+0000 : Anlamsız bir NULL karakteridir ve bazı programlama dillerinin davranışını bozabilir
  • U+0089 : C1 kontrol kodu (CHARACTER TABULATION WITH JUSTIFICATION) olup davranışı karmaşık ve tutarsızdır
  • U+DEAD : Eşleşmemiş surrogate karakterdir; UTF-16'nın sınırlarından kaynaklanan bir sorundur. İdeal olmayan veri oluşmasına yol açar
  • \uD9BF\uDFFF (gerçekte U+7FFFF) : Noncharacter olup standart gereği değiş tokuş edilmesi yasaktır
• Bu tür kod noktaları, veri yapıları ve protokoller içinde tutarlı biçimde işlenememeye ve beklenmeyen hatalara yol açar
• RFC 9839, bu sorunlu karakterleri resmî olarak tanımlar ve hariç tutulması gereken türleri açıkça belirtir

JSON'un tasarımı ve sınırları

• Bu durum, JSON'un yaratıcısı Doug Crockford'un sorumluluğu değildir
• JSON, Unicode'un yeterince olgunlaşmadığı bir dönemde tasarlandığı için karakter kümesini sıkı biçimde sınırlayamadı
• Artık standardı değiştirmek mümkün olmadığından, sorunlu karakterleri deneyimsel olarak dışlama yaklaşımı gerekir

IETF'nin PRECIS framework'ü ile farkı

• 2025 tarihli RFC 9839'dan önce de IETF, RFC 8264 (PRECIS Framework) gibi çeşitli standartlar sunuyordu
  • Bu framework, uluslararasılaştırılmış dizelerin arındırılması, uygulanması ve karşılaştırılması yöntemlerini ayrıntılı biçimde ele alır
  • 43 sayfa uzunluğundadır ve arka plan açıklamaları ile çözüm yaklaşımı kapsamlıdır
• PRECIS, Unicode sürümlerine güçlü biçimde bağımlıdır; karmaşıktır ve uygulanması zordur
• RFC 9839, kısa ve pratiktir; yeni protokoller tanımlanırken hızlı benimsenmesi daha kolaydır

RFC 9839'un alt kümeleri ve kullanım örnekleri

• 9839, üç gerçekçi alt küme sunar: scalars, XML, assignables
• Her alt küme, hariç tutulacak sorunlu karakter aralığını biraz farklı belirler
• Aşağıda, başlıca veri formatlarının ve RFC 9839 alt kümelerinin sorunlu karakterleri nasıl ele aldığına dair tablonun özeti yer alır
  • CBOR, TOML, XML, YAML gibi bazı formatlar surrogate veya kontrol karakterlerini kısmen dışlar
  • I-JSON, surrogate ve noncharacter karakterleri dışlar
  • Genel JSON, Protobufs bunları dışlamaz
  • XML, YAML, charset özellikleri nedeniyle noncharacter/kontrol kodlarının yalnızca bir kısmını hariç tutar
    • Not: XML ve YAML, Basic Multilingual Plane dışındaki noncharacter karakterleri hariç tutmaz

Go dili için RFC 9839 kütüphanesi

• RFC 9839'un üç alt kümesi için karakter doğrulamasını destekleyen küçük bir Go kütüphanesi yayımlandı
• Yeterince test edildi; optimizasyon çalışmaları ise hâlâ sürüyor
• Gerçek üretim ortamlarında test ve geri bildirim memnuniyetle karşılanıyor

RFC 9839'un önemi ve hazırlık süreci

• RFC 9839, ortak yazarlar ve çok sayıda geri bildirim turunun ardından, 15'ten fazla taslak revizyonundan sonra resmen yayımlandı
• Topluluktaki birçok uzmanın tartışma ve katkıları sayesinde ilk taslaktan çok daha olgun bir belgeye dönüştü
• Katkıda bulunanlar “Acknowledgements” bölümünde belirtiliyor

RFC bireysel gönderim deneyimi

• RFC 9839, bireysel gönderim (individual submission) olarak ilerletildi
• Working Group üzerinden yürüyen geleneksel yönteme göre emek ve süreç yükü daha fazladır
• Working Group katılım deneyimiyle karşılaştırıldığında, geleneksel yöntem daha verimli ve daha fazla tavsiye edilir