Metin Temizleyici
Excel, SQL, ticket ve loglar için satır bazlı metni temizle, tekilleştir, sırala ve formatla. Tarayıcıda çalışır. Yükleme yok.
- Ticket ve incident notları için log satırlarını temizlemek.
- Yapıştırılan ID’lerden SQL IN listesi hazırlamak.
- İçe aktarmadan önce e-posta/ID listelerini tekilleştirmek.
- PDF/Excel’den yapıştırılan dağınık metni normalize etmek.
- Diff ve code review için listeleri sıralamak.
b\na\na\nB\n
a\nB\nb\n
123\n456\n789\n
'123',\n'456',\n'789',\n
alpha\nbeta\ngamma\n
alpha, beta, gamma
›Metnim sunucuya yükleniyor mu?
›Büyük girdileri destekliyor mu?
›Tekilleştirmede orijinal sırayı koruyabilir miyim?
›Sayıları doğru sıralayabilir mi?
›SQL IN listesi nasıl oluştururum?
›Yapıştırdığım metinde görünmez karakterler neden var?
›Temizle ve Sıfırla arasındaki fark nedir?
›Bul & değiştir regex destekli mi?
›BOM nedir ve ne zaman sorun çıkarır?
›Yapıştırdığım metin editörümdeki girintiyi neden bozdu?
›Satır sonlarını LF'e mi CRLF'e mi çevirmeliyim?
›İki string aynı görünüyor ama farklı çıkıyor, neden?
Açıklama
En kötü metin hataları görünmeyenlerdir. Bir web sayfasından kopyalanan ürün kodu veritabanındakiyle birebir aynı görünür, string karşılaştırması false döner ve ekranda bunu açıklayan hiçbir şey yoktur. Suçlu genelde görsel karşılığı olmayan bir karakterdir: U+200B genişliksiz boşluk, yapıştırmanın başına takılan U+FEFF byte-order mark, U+2028 satır ayırıcı ya da kelimenin ortasına oturmuş yumuşak tire. Aynı görünen iki string eşleşmiyorsa ilk denenecek şey bu karakter sınıfını temizlemektir.
Kelime işlemciler siz yazarken noktalamayı yeniden yazar ve sonuç nereye yapıştırırsanız oraya taşınır. Düz tırnaklar kıvrık hale gelir, çift tire uzun tireye döner, üç nokta tek bir karaktere dönüşür. Düz yazıda bu bir iyileştirmedir. Config dosyasında, kabuk komutunda veya kod parçasında ise syntax hatasıdır ve hata mesajı beklediğinizle tıpatıp aynı görünen bir karakteri işaret eder. PDF'ten alınan metin için de aynısı geçerlidir: çoğu zaman fi gibi ligatürler tek glif olarak ve orijinal satır sonlarından kalan tirelemeyle gelir.
U+00A0 kırılmaz boşluk kendi uyarısını hak ediyor. Normal boşluk gibi görünür ama hiç öyle davranmaz: girinti duyarlı bir dosyada — YAML, Python, Makefile — satır tamamen hizalı görünürken beklenmeyen girinti hatası alırsınız. Terminale yapıştırılan komut, argüman ayırıcısı gerçekten boşluk olmadığı için command not found der. Her NBSP'yi düz boşluğa çevirmek bu hataların bütün bir ailesini kapatır.
Satır sonları bu sorunların en eskisi ve hâlâ en yaygını. Windows araçları CRLF, Unix araçları LF yazar; ikisi karışınca her satırın değişmiş göründüğü diff'ler, shebang'den sonraki görünmez carriage return yüzünden bad interpreter hatası veren shell script'ler ve her satırın son alanında bir \r bırakan CSV parser'ları çıkar ortaya. Git'e veya build hattına giren her şey için doğru varsayılan LF'tir; CRLF'e yalnızca belirli bir Windows tüketicisi istiyorsa çevirin.
Satır sonundaki boşluklar ve kontrolden çıkmış boş satırlar daha az tehlikeli ama daha gürültülüdür. Satır sonundaki boşluk, code review'da değişmiş satır olarak belirene kadar görünmezdir; bir veri dışa aktarımında iki paragraf arasındaki yarım ekran boşluk ise sadece dolgudur. Commit'ten önce ardışık boş satırları teke indir, satır sonlarını kırp. İki istisna: Markdown satır sonundaki iki boşluğu zorunlu satır sonu olarak kullanır ve test fixture'ları baytları birebir karşılaştırabilir; bu ikisinin üzerinden körlemesine trim geçme.
Unicode normalizasyonu işin ince kısmı. é karakteri tek kod noktası (U+00E9) olarak saklanabileceği gibi, düz bir e ve ardından U+0301 birleşen aksan olarak da saklanabilir. Her fontta aynı görünürler ve bayt karşılaştırmasında eşit değildirler; sorgu boş döner, tekilleştirme kaçırır, UNIQUE index çakışması gereken kaydı kabul eder. macOS dosya sistemleri ayrışmış biçimi tercih ederken Windows ve web kaynaklarının çoğu birleşik biçimi üretir; bir makineden alınan dosya listesinin diğerindekiyle eşleşmemesinin sebebi tam olarak budur. Karşılaştırmadan önce her şeyi NFC'ye çevirmek sorunu bitirir. NFKC daha ileri gider ve kayıplıdır — fi ligatürünü fi, ① karakterini 1, tam genişlikli karakterleri ASCII yapar — bu yüzden onu arama anahtarında kullan, saklayacağın veride kullanma.
İçe aktarmadan önce temizlik yapmak saatlerce veritabanı arkeolojisinden kurtarır. E-posta adresinin sonundaki tek boşluk aynı kişi için ikinci bir hesap açar. Değerin içindeki bir sekme koca bir CSV kolonunu kaydırır. Virgül veya gömülü satır sonu içeren bir alan, düzgün tırnaklanmadıysa tek satırı ikiye böler. Yalnızca boşluktan oluşan hücreler NULL değil boş string olarak gelir ve güvendiğin NOT NULL kontrollerini sessizce etkisiz bırakır. Temizliği mantıklı bir sırayla yap: önce satır sonları, sonra görünmez karakterler, sonra Unicode normalizasyonu, sonra kırpma, sonra boş satırların sadeleştirilmesi ve en son tekilleştirme — çünkü normalize edilmemiş metinde dedupe tam da kaldırmak istediğin kopyaları kaçırır.
Bazı metinler asla temizlenmemeli. Base64 verileri, JWT'ler, özel anahtarlar ve hash'ler baytı baytına sabit dizilerdir; silinen bir satır sonu veya değişen bir harf onları bozar. YAML'da, Markdown kod bloklarında ve Python'da baştaki boşluk anlamlıdır. Bir istek gövdesi üzerinde imza doğrulaman gerekiyorsa dokunulmamış orijinali sakla; CRLF'i LF'e çevirmek kadar masum bir işlem bile imzanın kapsadığı baytları değiştirir. Elle girilmiş dağınık listeleri ve yapıştırılan tablo kolonlarını temizle, makine üretimi blob'ları geldiği gibi bırak.