IT
OmnvertGörsel • Belge • Ağ

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.

Tarayıcıda yerelde çalışır. Yükleme yok.
Kısayollar: Ctrl/⌘+Enter Apply · Ctrl/⌘+S Download · Ctrl/⌘+C Copy output · Esc Clear
Girdi
İşleme sırası
Oklarla sırayı değiştir.
Adım ayarları
Çıktı
İstatistikler Uygula’dan sonra görünür.
Kullanım senaryoları
  • 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.
Yaygın problemler & çözümler
Listemde gizli boşluk / zero-width karakterler var
Boşluğu sanitize et ve Her satırı kırp seçeneklerini açıp Uygula’ya bas.
Sıralama sayıları bozuyor
Port, ID ve tutar gibi değerler için Sayısal sıralama’yı aç.
Tekilleştirme çok fazla kaldırdı
Büyük/küçük harf duyarsız tekilleştirmeyi kapat veya stabil moda geç.
SQL için çıktı yanlış görünüyor
Önek/sonek bölümündeki tek tırnak veya SQL IN preset’lerini kullan.
Örnekler
Tekilleştir + sırala
Önce
b\na\na\nB\n
Sonra
a\nB\nb\n
SQL IN formatı (tırnak + virgül)
Önce
123\n456\n789\n
Sonra
'123',\n'456',\n'789',\n
Satırları virgülle birleştir
Önce
alpha\nbeta\ngamma\n
Sonra
alpha, beta, gamma
Metin Temizleyici SSS
Metnim sunucuya yükleniyor mu?
Hayır. İşleme tarayıcıda yerelde yapılır; hiçbir şey yüklenmez.
Büyük girdileri destekliyor mu?
Evet. Ağır işlemler Web Worker içinde çalışır ve dönüşümler sadece Uygula’ya bastığınızda uygulanır.
Tekilleştirmede orijinal sırayı koruyabilir miyim?
Evet. Mod olarak “Orijinal sırayı koru (stabil)” seçin.
Sayıları doğru sıralayabilir mi?
Sayısal sıralama’yı açın. Satırlar karışıksa, güvenli şekilde string sıralamaya geri döner.
SQL IN listesi nasıl oluştururum?
Önek/sonek adımını açıp tek tırnak veya SQL IN preset’ini kullanın; her satırı sarıp virgül ekler.
Yapıştırdığım metinde görünmez karakterler neden var?
Bazı kaynaklar bölünmez veya zero‑width boşluklar ekler. Boşluğu sanitize et seçeneği bunları kaldırır.
Temizle ve Sıfırla arasındaki fark nedir?
Temizle girdi/çıktıyı boşaltır. Sıfırla metni korur ama adımları ve ayarları varsayılana döndürür.
Bul & değiştir regex destekli mi?
Hayır. Sadece düz metin bul/değiştir var. Regex için Regex Test Aracı’nı kullanın.
BOM nedir ve ne zaman sorun çıkarır?
Byte-order mark, dosyanın başında kodlamayı ve bayt sırasını belirtmek için kullanılan U+FEFF kod noktasıdır. UTF-8'de gereksizdir ve birçok parser onu içerik sayar: JSON dosyası 1. satır 1. sütunda patlar, CSV içe aktarımında ilk kolonun adı "\ufeffid" olur, PHP dosyası header'lardan önce çıktı üretir. Dosya doğru görünüyor ama ilk alan tuhaf davranıyorsa önce BOM'a bak.
Yapıştırdığım metin editörümdeki girintiyi neden bozdu?
Neredeyse kesinlikle baştaki boşluklara karışmış U+00A0 kırılmaz boşluklar yüzünden; dokümantasyon sitelerinden ve kelime işlemcilerden kopyalanan metinde çok yaygındır. YAML, Python ve Makefile bu karakteri girinti değil sıradan bir sembol sayar, satır hizalı görünse de anlamsız ayrıştırılır. Her NBSP'yi normal boşlukla değiştirdiğinde dosya yeniden derlenir.
Satır sonlarını LF'e mi CRLF'e mi çevirmeliyim?
Git'te duran, sunucuda çalışan veya build aracından geçen her şey için LF. Unix araçlarının varsayılanıdır ve her satırın değişmiş göründüğü diff'leri önler. CRLF'i yalnızca eski bir Excel veya Notepad akışı gibi belirli bir Windows tüketicisi isterse kullan. CRLF'li bir shell script, carriage return yorumlayıcı yolunun parçası olduğu için bad interpreter hatası verir.
İki string aynı görünüyor ama farklı çıkıyor, neden?
Ya birinin içinde görünmez bir karakter saklıdır ya da ikisi farklı Unicode normalizasyon biçimindedir — é karakteri U+00E9 olarak veya e artı U+0301 birleşen aksan olarak. İkisi de aynı görünür, ne bayt karşılaştırması ne de veritabanı index'i onları eşit sayar. Karşılaştırmadan önce iki tarafı da NFC'ye çevir ve genişliksiz karakterleri temizle.

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.