Base64 "Çince'yi bozuyor" gibi göründüğünde sorun genellikle karakterler ve baytlar arasındaki sınırdadır. Base64 bir dizinin Çince metni veya emojiyi temsil ettiğini bilmiyor. Baytları korur; uygulama bu baytların nasıl üretilip yorumlanacağını seçer.
Baytları takip edin
中 karakteri U+4E2D'dir. UTF-8 içinde, Base64 gösterimi olan E4 B8 AD baytlarını kullanır. 5Lit. Farklı bir karakter kodlaması, farklı baytlar ve dolayısıyla farklı bir Base64 değeri üretir. Kodlanmış dizeleri karşılaştırmadan önce her iki uçta da UTF-8 üzerinde anlaşın.
const bytes = new TextEncoder().encode('中');
console.log([...bytes]); // [228, 184, 173]
console.log([...bytes].map(b => b.toString(16)).join(' ')); // e4 b8 ad
Emoji başka bir ayrımı gösteriyor: JavaScript '😊'.length iki UTF-16 kod biriminden oluşur ve UTF-8 temsili dört bayta sahiptir. Her iki sayı da tek başına rastgele metinde kullanıcı tarafından algılanan görünür karakterlerin sayısı değildir. Dosya ve aktarım hesaplamaları için bayt uzunluğunu kullanın.
Değiştirmeyi görünür hale getirin
Değiştirme karakteri � daha önceki bir kod çözücünün zaten bilgiyi kaybettiği anlamına gelebilir. Bir dizede bilinmeyen baytlar değiştirildiğinde ve bu dize yeniden kodlandığında, orijinal değerler genellikle yeniden oluşturulamaz. Daha fazla dönüşüm yapmadan önce ham kodu çözülmüş bayt dizisini inceleyin.
const decoder = new TextDecoder('utf-8', { fatal: true });
console.log(decoder.decode(Uint8Array.of(0xe4, 0xb8, 0xad))); // 中
try { decoder.decode(Uint8Array.of(0xff)); }
catch { console.log('Invalid UTF-8; preserve the original byte.'); }
Normalleştirme ayrı bir işlemdir
Farklı Unicode dizileri içerirken iki dize aynı görünebilir. Vurgulu é harfi, önceden oluşturulmuş bir karakter veya bir e ve ardından birleştirici bir vurgu gelebilir. UTF-8 ve Base64 bu farkı doğru şekilde korur. Uygulamanız normalleştirilmiş metin istiyorsa, açıkça bir normalleştirme formu seçin ve kodlamadan önce uygulayın; Değiştirilen bir sonucu asla bayt koruyan onarım olarak adlandırmayın.
Ayrıca sonuçlar farklı olduğunda görünmez karakterleri, satır sonlarını ve olası bayt sırası işaretini de kontrol edin. Bunlar gerçek giriş baytlarıdır, mutlaka kodlayıcı hataları değildir. İmzalı mesajlar ve sağlama toplamları için görünmez bir fark bile sonucu değiştirir.
Güvenilir bir sorun giderme sırası şu şekildedir: kaynağı koruyun, baytları inceleyin, beklenen karakter kodlamasını belirleyin, açık hata işlemeyle kodu çözün ve ancak bundan sonra normalleştirmeyi düşünün. MDN: btoa() doğrudan tarayıcı btoa çağrılarının neden rastgele Unicode metinler için uygun olmadığını açıklıyor. İkili dosyalar metin kod çözme işlemini tamamen atlamalıdır.