AI aracının metin akışında bir harf iki parçaya bölünürse.

Ağ parçası her zaman tam bir harfle bitmez

Bir AI aracından gelen metin ekranda AşB yerine A��B görünüyor. Modelin Türkçe karakteri yanlış yazdığını düşünebilirsiniz. Ancak araç doğru UTF-8 baytlarını göndermiş, istemci her parçayı ayrı bir metin gibi çözmüş olabilir. Çok baytlı bir harfin ilk baytı bir parçada, devamı sonraki parçada kaldığında doğru veriyi yanlış şekilde birleştirmek mümkündür. Önce ham baytları ve çözücünün durumunu kontrol edin.

Bu örnekte içerik sentetik AşB metnidir. Sıkıştırma, şifreleme, ağ isteği veya gerçek model çağrısı yoktur. Beklenen kodlama UTF-8 olarak verilmiştir. Baytları onaltılık gösterimle yazacağız; 41 harf A, C5 9F birlikte ş, 42 harf B karşılığıdır. Kaynakta dört bayt, görünen metinde üç karakter vardır. İki aktarım parçasının sınırı ş harfinin ortasına konmuştur.

P1 ve P2 kendi başlarına iki bağımsız mesaj değildir. Aynı metnin sıralı parçalarıdır. Bu kimliği kaybederseniz ikinci parçada gelen 9F baytının neden başta tek kaldığını açıklayamazsınız. Parçaların sayısı, karakter sayısı veya tamamlanmış kayıt sayısı anlamına gelmez. Bir aktarım katmanının sınırını başka bir katmanın sınırı gibi kullanmamak gerekir.

Tamamlanmamış karakteri sonraki parçaya taşıyın

MDN, TextDecoder.decode çağrısında stream seçeneğinin sonraki çağrılarda veri geleceğini belirttiğini açıklar. Parçalı akış sürerken true kullanılır; son parçada veya sonlandırmada false kullanılır. Varsayılan değer false olduğu için her parçayı sıradan bir decode çağrısıyla çözmek, her defasında metin bitmiş gibi davranabilir. Aynı akış boyunca aynı çözücü nesnesinin durumunu korumak gerekir.Kaynak: MDN — TextDecoder.decode

Durum tutan çözücü P1’deki C5 baytını hemen bozuk karakter olarak yazmaz; devamını bekler. P2 başındaki 9F geldiğinde ş tamamlanır. İki parçadan üretilen metinleri sırasıyla birleştirmek AşB sonucunu verir. Buradaki bekleme ağda yeni istek yapmak değildir; eldeki çözücünün tamamlanmamış kodlama durumunu sonraki çağrıya taşımasıdır.

Yeni çözücü yaklaşımında görülen � işareti bir değiştirme karakteridir. Kaynağın o işareti gerçekten göndermesi ile istemcinin kodlama hatası sonucunda üretmesi farklı olaylardır. Son metni görerek hangisinin gerçekleştiğine tek başına karar veremezsiniz. Ham bayt izi ve hata politikası bu yüzden teşhis kaydının parçası olmalıdır.

Küçük bir yerel kontrol çalıştırın

const parts = [[0x41, 0xC5], [0x9F, 0x42]];
const decoder = new TextDecoder("utf-8", { fatal: true });
let text = "";
for (const bytes of parts) {
  text += decoder.decode(Uint8Array.from(bytes), { stream: true });
}
text += decoder.decode();
if (text !== "AşB") throw new Error("Metin uyuşmadı");
console.log(text);

Son boş decode çağrısı gereksiz bir tekrar değildir. Akışın bittiğini bildirerek içeride tamamlanmamış bir dizilim kalıp kalmadığını denetler. fatal seçeneği açık olduğunda çözme hatası TypeError üretir; MDN bu davranışı açıklar. Böylece son baytı gelmemiş bir akışı sessizce tamamlanmış metin gibi kabul etmek yerine hata yoluna ayırabilirsiniz.Kaynak: MDN — TextDecoder.decode

Kaynak UTF-8 AşB; P1=[41 C5], P2=[9F 42], baytlar onaltılık. Parçalar aynı mesaja ait ve sıralı. Yeni çözücüyle bağımsız çözme ile tek çözücüde stream=true kullanımını karşılaştır. Her çağrının metin çıktısını ve sonlandırma sonucunu göster. Sonda fatal kontrolü uygula. P2 hiç gelmezse başarı üretme. Gerçek ağ servisi veya model çalıştırdığını söyleme.

Kod Node.js gibi TextDecoder sağlayan bir JavaScript ortamında yerel olarak sınanabilir. Örnek bayt dizilerini gerçekten çözer, fakat bir AI modelinin aktarım başarısını ölçmez. Uygulamanızdaki ağ kütüphanesi zaten metni çözmüş olarak veriyorsa aynı bayt işlemini körlemesine tekrar uygulamayın. Kontrol edeceğiniz katmanın ham bayt mı yoksa hazır metin mi döndürdüğünü önce belirleyin.

Parça gelmemesi ile akışın bitmesini ayırın

P1 geldikten sonra P2 kaybolduğunu düşünün. Açık akışta yalnız A çıktısını görmek henüz bozulma kanıtı değildir; C5 devam bekliyor olabilir. Ancak protokol akışın bittiğini bildirdiğinde bu eksiklik kapanmalıdır. Aynı fatal çözücüde sonlandırma hataya düşer. A harfi elde edilmiş olsa bile kaynak metnin tamamının başarıyla alındığını söyleyemezsiniz.

Sonlandırmayı yalnızca bir süre veri gelmedi diye kendiliğinden varsaymayın. Uygulamanın protokolü bitişi, iptali ve hata durumunu nasıl bildiriyorsa onu izleyin. Zaman aşımı ile başarıyla kapanış aynı durum değildir. Kısmi metin kullanıcıya gösteriliyorsa kısmi olduğu korunmalı; son denetim geçmeden nihai kayıt veya tamamlandı etiketi üretilmemelidir.

• Kodlamayı ve mesaj kimliğini aktarım sözleşmesinde tutun.
• Aynı mesajın sıralı parçalarında aynı çözücü durumunu kullanın.
• Farklı eşzamanlı mesajların çözücülerini karıştırmayın.
• Akış bittiğinde sonlandırmayı ve hata sonucunu kontrol edin.

Doğru kod çözme, üst katmandaki JSON veya CSV yapısının da tamamlandığını garanti etmez. Tam harflerle biten bir metnin kapanış tırnağı eksik olabilir. Tersine, görünüşte dengeli işaretler bozuk karakter içeren metni doğrulamaz. Önce bayt kodlamasını, ardından mesaj yapısını, sonra alanların iş anlamını ilgili sözleşmelerle ayrı ayrı denetleyin.

Her baytı ayrı parçada gönderin

Aynı dört baytı bu kez [41], [C5], [9F], [42] olarak dört parçaya ayırın. Tek çözücü ve stream=true yaklaşımında her çağrının ürettiği metni tahmin edin; ardından yerel kodla kontrol edin. Ayrı bir hatalı senaryoda üçüncü parçayı çıkartın ve sonlandırmanın başarıyla tamamlanıp tamamlanamayacağını açıklayın.

Doğru dört parçada çağrı çıktıları sırayla A, boş metin, ş, B olur; son boş decode de boş metin verir. Birleşik sonuç AşB. 9F parçası çıkarılıp C5 ardından 42 gelirse fatal çözücü geçersiz devamı hata olarak bildirir; AşB başarı sonucu üretilemez.

Kendi aktarım denemenizde aynı metni farklı parça sınırlarıyla sınayın. Beklenen tam metin aynı kalırken ara çıktının değişmesi normal olabilir. Teslim kaydında son metnin eşitliğini, parça sırasını ve kapanış durumunu birlikte gösterin; böylece karakter bozulmasını doğrudan modelin dil yeteneğine bağlamadan inceleyebilirsiniz.