Kodlama Dönüştürücü ve Bozuk Karakter Düzeltici

Hızlı yanıtlar

Mojibake nedir?

// The mistake, in three lines of JavaScript
const bytes = new TextEncoder().encode('测试');   // UTF-8: E6 B5 8B E8 AF 95
new TextDecoder('gbk').decode(bytes);            // '娴嬭瘯'  ← mojibake
new TextDecoder('windows-1252').decode(bytes);   // '测试'  ← same bytes, other mistake

Bu araç ne yapar

Çözümlü örnekler

娴嬭瘯

测试

测试

测试

B2 E2 CA D4

测试

鏁版嵁搴�

(yalnızca kısmi)

Bu araç nasıl kullanılır

1. 1

   Bozuk metni yapıştırın

   Doğrudan yapıştırın — önce kodlamayı belirlemeniz gerekmez. Kısa bir parça yeter; on beş kadar karakter genellikle zinciri sabitlemeye yetiyor.

2. 2

   En üstteki adayı ve rozetini okuyun

   Tam, zincirin gidiş-dönüşte girdinizi birebir yeniden ürettiği anlamına gelir. Kısmi ise üretmediği; o sonucu bir ipucu olarak değerlendirin.

3. 3

   Kodlama zincirini kontrol edin

   Her aday, metnin gerçekte hangi kodlamayla yazıldığını ve hangisinin onu yanlış okuduğunu gösterir. Bu size yalnızca metnin ne dediğini değil, yukarı akışta neyi düzelteceğinizi de söyler.

4. 4

   Gerekirse baytlara bakın

   İkinci bölüm herhangi bir metni bütün yaygın kodlamalarda bayt olarak gösterir ve ham onaltılığı ters yönde çözer. Sütun boyu belirlemek ya da protokol çerçevesi kontrol etmek için kullanın.

Durumu daha da kötüleştiren hatalar

iconv -f UTF-8 -t GBK correct.txt > broken.txt

# Önce mevcut kodlamayı doğrulayın
file -I correct.txt   # charset=utf-8 → dönüştürülecek bir şey yok

ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

-- Baytlar yeniden yorumlanmasın diye önce ikili bir tipten geçin
ALTER TABLE t MODIFY c VARBINARY(255);
ALTER TABLE t MODIFY c VARCHAR(255) CHARACTER SET utf8mb4;

// Rozet ne derse desin ilk adayı al
db.update(row.id, candidates[0].text);

// Yalnızca gidiş-dönüşü tamamlayan sonucu geri yaz
if (candidates[0].lossless) db.update(row.id, candidates[0].text);

text = raw.decode('utf-8').encode('gbk').decode('utf-8')

# Sınırda bir kez çözün, dosyanın gerçekten kullandığı kodlamayla
with open(path, encoding='gbk') as f:
    text = f.read()

Buna ne zaman ihtiyaç duyarsınız

Bir veritabanı taşıması çöp üretti

En yaygın tek kaynak, latin1 olarak tanımlanmışken aslında UTF-8 baytları tutan eski MySQL tablolarıdır. ALTER TABLE komutunu yazmadan önce bozuk bir satırı buraya yapıştırıp gerçek zinciri doğrulayın — dönüşümü ters yönde çalıştırmak, kurtarılabilir bir sorunu kalıcı bir soruna çevirir.

Excel'de açılan bir CSV saçmalık gösteriyor

Windows'ta Excel, BOM taşımayan CSV dosyaları için hâlâ sistem kod sayfasını varsayar; bu yüzden UTF-8 dışa aktarımları bozuk karakter olarak açılır. Zinciri burada doğrulayın, sonra BOM ile yeniden dışa aktarın ya da kodlamayı açıkça belirterek metin sihirbazından içe aktarın.

Eski bir servisten gelen kayıt dosyaları

GBK ya da Shift_JIS'e göre yazılmış uygulamalar kayıtlarını o kodlamalarla üretir, modern kayıt toplayıcılar ise her şeyi UTF-8 olarak okur. Bir satırı kurtarmak için yapıştırın — hiçbir şey yüklenmediği için bunu üretim kayıtlarıyla yapabilirsiniz.

ZIP arşivinin bozduğu dosya adları

ZIP biçiminde kodlama alanı yoktur; bu yüzden Çince ya da Japonca Windows üzerinde oluşturulmuş arşivler, Unix araçlarının UTF-8 olarak okuduğu GBK veya Shift_JIS dosya adları taşır. Herhangi bir şeyi yeniden adlandırmadan önce gerçek adları burada kurtarın.

Veritabanı sütunu boyutlandırma

Bayt görünümü aynı metni bütün kodlamalarda aynı anda gösterir. Bir Çince karakter UTF-8'de 3 bayt, GBK'de 2 bayttır; Türkçede ise ş ya da ğ gibi bir harf UTF-8'de 2 bayt tutar. VARCHAR(50) alanını kesme hatasına çeviren fark tam olarak budur.

Bozuk karakterler nasıl oluşur

Baytlar hayatta kalır, anlam kalmaz

Kodlama karakterleri baytlara eşler, çözme baytları geri eşler. Mojibake, yanlış eşlemeyle yapılmış bir çözmedir. Baytlar hiçbir zaman zarar görmemiştir; yanlış çözmeyi tersten çalıştırmanın özgün metni birebir geri getirmesinin nedeni budur — yanlış çözme yol boyunca bir şey atmadığı sürece.

CJK metinleri neden en çok zarar görür

ASCII 0x00–0x7F aralığını kaplar ve her yaygın kodlama bu aralıkta hemfikirdir; İngilizce metin bu yüzden zarar görmeden geçer. Çince, Japonca ve Korece çok baytlı diziler gerektirir ve kodlamalar bunları nasıl gruplayacakları konusunda anlaşamaz. UTF-8 bir Çince karakter için üç bayt kullanır, GBK iki. UTF-8 baytlarını bir GBK çözücüsüne verdiğinizde gruplama kayar ve farklı sayıda, farklı karakter ortaya çıkar. Türkçe bu işten daha ucuz kurtulur: yalnızca ASCII dışındaki harfler iki bayt tuttuğu için cümlenin iskeleti okunur kalır, bozulma tek tek harflerde toplanır.

Gidiş-dönüş denetimi

Araç her aday zincir için kurtarılan metni ilk kodlamayla yeniden kodlar ve ikinci kodlamayla yeniden çözer. Bu işlem girdiyi birebir yeniden üretiyorsa zincir her karakteri açıklıyor demektir ve aday Tam olarak işaretlenir. Denetimden geçemeyen adaylar yine de gösterilir, çünkü kısmi bir kurtarma metni birebir üretemese bile çoğu zaman onu tanımlamaya yeter.

Kodlama tabloları nereden geliyor

Tabloları tarayıcının TextDecoder bileşeni sağlar. Ters yönde kodlama daha zordur, çünkü TextEncoder yalnızca UTF-8 destekler — bu yüzden araç, bayt uzayında gezinip her dizinin ne anlama geldiğini çözücüye sorarak ters bir eşleme kurar. Eşleme böylece her zaman tarayıcının kendi davranışıyla tutarlı olur ve cihazınıza hiçbir arama tablosu indirilmez.

Sıralama sezgiseli ve sınırları

Gidiş-dönüş denetiminin ötesinde adaylar, metnin ne kadarının yaygın Çince karakterlerden oluştuğuna göre puanlanır (GBK öncü baytı 0xB0–0xF7 aralığına düşenler); değiştirme karakterleri, yarım genişlikli katakana ve kontrol karakterleri puan düşürür. Yarım genişlikli katakana güçlü bir Shift_JIS işaretidir, çünkü normal Japonca metin onu neredeyse hiç kullanmaz. Bu bir sezgiseldir; eşitlik bozar, gerçeği belirlemez.

Bir daha olmasını önlemek

Yalnızca dizeyi değil, kaynağı düzeltin

Her adayın altında gösterilen kodlama zinciri hangi bileşenin yanlış yapılandırıldığını söyler. Bağlantı karakter setini, dosya okuyucusunu ya da dışa aktarma ayarını düzeltmeden metni onarmak, yarın taze veriyle aynı işi yeniden yapmak demektir.

Bütün dosyayı dönüştürmeden önce yönü doğrulayın

Önce temsili bir satırı bu sayfadan geçirin. Ters yönde dönüştürmek değiştirme karakterleri üretebilir ve ilk hatanın aksine bu adım geri alınamaz.

Kodlamayı her yerde açıkça belirtin

Veritabanı bağlantı karakter seti, HTTP Content-Type, dosya açma çağrıları, CSV dışa aktarımları. "Sistem kodlaması" varsayılanına düşen her yer, kod başka bir makineye taşındığında aynı hatanın geri döneceği yerdir.

MySQL'de utf8 yerine utf8mb4 kullanın

MySQL'in utf8 biçimi karakter başına en fazla üç bayt saklar; emoji ve bazı ender Çince karakterler sessizce kesilir. Gerçek UTF-8 olan utf8mb4'tür. Bu, mojibake'ten farklı bir arızadır ve kurtarma aracı bu konuda yardımcı olamaz, çünkü baytlar gerçekten yok olmuştur.

Düzeltme doğrulanana kadar özgün baytları saklayın

Bir şeyi dönüştürmeden önce kopyasını alın. Özgün baytlar durduğu sürece her yanlış çözme geri alınabilir — bir kez değiştirme karakterleriyle üzerine yazıldıklarında ne bu sayfadaki ne de başka bir araç onları geri getirebilir.

Sıkça sorulan sorular