CSV (Virgülle Ayrılmış Değerler), 2005'teki RFC 4180'de sadece resmi olarak tanımlanmış olmasına rağmen veri değişimi için evrensel bir dil olmaya devam etmektedir ve kökleri 1972'deki IBM Fortran uygulamalarına kadar uzanmaktadır. İlk uygulamalar, CSV'yi basit metin olarak virgüllerle ayırma olarak ele almış, kodlama karmaşıklıklarını, ayırıcı varyasyonlarını ve çağdaş küreselleşmenin neden olduğu satır sonu belirsizliklerini görmezden gelmiştir. Temel zorluk, CSV'nin kendini tanımlayan meta verilerden yoksun olmasıdır; ayrıştırıcılar, toplu ekleme işlemleri sırasında ACID uyumunu sağlarken ayırıcıları, kodlamaları ve şemaları dolaylı olarak çıkarmak zorundadırlar. Bozulmuş satırlar, görünmez BOM (Bayt Sırası İşareti) varyasyonları ve bellek kısıtlamaları, işlevsel doğrulamanın performans, güvenlik ve veri bütünlüğü ile kesiştiği bir test yüzeyi oluşturur.
Sistematik bir metodoloji, bu riskleri bütünsel olarak ele almak için dört ayrı doğrulama aşaması gerektirir. İlk olarak, başlık bozulmalarını tespit etmek için UTF-8, UTF-16, Windows-1252, ISO-8859-1 ile ve BOM imzalarıyla ve imzasız karakter kodlamaları için eşdeğer bölümlendirme yapılmalıdır. İkinci olarak, dosya boyutları için sınır değer analizi (0 bayt, 1MB, 100MB, 1GB+) yapılmalı ve Node.js veya JVM kısıtlamaları altında akış davranışı ve bellek kararlılığı doğrulanmalıdır. Üçüncü olarak, kapatılmamış alıntılar, karışık satır sonları (CRLF ile LF), formül enjeksiyonu girişimleri ve SQL kaçış dizileri gibi bozulmuş yapılara yönelik olumsuz testler gerçekleştirilmelidir. Dördüncü olarak, kısmi hataların temiz bir şekilde geri alınmasını sağlamak için veritabanı kayıt noktaları veya geçici tablolar kullanılarak işlem bütünlüğü doğrulanmalıdır.
Bir fintech başlangıcında, bulut göçü sırasında müşteri portföylerini eski Oracle veritabanlarından modern PostgreSQL platformuna aktarmamız gerekiyordu. Eski sistem, Windows-1252 kodlamasını ve kıvrımlı akıllı tırnak işaretlerini ve noktalı virgül ayırıcıları kullanarak CSV dışa aktarımları oluşturuyordu, oysa Node.js uygulamamız UTF-8 ile virgüller bekliyordu ve bu da hemen uyumsuzluklar yarattı.
İlk manuel testlerde 10KB boyutunda küçük dosyalar kullanıldı ve bunlar Docker aşama ortamında kolayca geçti. Ancak, 80MB'ı aşan üretim dosyaları, ayrıştırıcının dosyaları RAM'e DOM-tarzı ayrıştırma ile tamamen yüklemesi nedeniyle OOM (Bellek Dışı) hataları ile Heroku dinomuzun çökmesine neden oldu. Ayrıca, 120,000. satırda geçersiz bir tarih formatı (02/30/2023) bulunduğunda, sistem bir istisna fırlattı, ancak önceki 119,999 satırı veritabanına zaten işlemişti. Bu, veritabanını, manuel SQL temizliği gerektiren tutarsız bir durumda bıraktı ve kodlama sorunları, uluslararası müşteri adlarını é karakterlerinin bozulmasıyla etkileyerek veri kalitesinin zarar görmesine neden oldu.
Düşünülen Çözüm 1: Sunucu belleğini 2GB'dan 16GB'a çıkararak dikey ölçeklendirme yapmak ve tüm içe aktarma işlemlerini tek bir monolitik veritabanı işlemi içinde sarmak. Artıları, minimum kod değişiklikleri ve hemen çalışacak basit uygulama. Eksileri, bulut yerel 12-faktör prensiplerini ihlal eden pahalı altyapı, kodlama bozulmasını çözmeme, gelecekteki dosyalar 500MB'a ulaştığında gecikmeli OOM çöküşleri ve içe aktarma sürelerinde canlı kullanıcıları etkileyen genişletilmiş veritabanı tablo kilitleri içeriyor.
Düşünülen Çözüm 2: Python betikleri kullanarak kodlamaları iconv ile dönüştürmek ve büyük dosyaları yüklemeden önce 1000 satırlık parçalara ayırmak için istemci tarafında ön işleme yapmak. Artıları, ana uygulama kod tabanını değiştirmeden anlık bellek ve kodlama sorunlarını çözmek. Eksileri, manuel bir müdahale gerektiren kırılgan dış bağımlılıklar, otomatik iş akışlarının bozulması, parça sınırlarını aşan çapraz-satır doğrulamalarında referans bütünlüğünün bozulması ve Windows ve macOS geliştirici ortamları arasında zor bakım gerekliliğidir.
Düşünülen Çözüm 3: Kodlama tespiti için iconv-lite ile birlikte Papa Parse gibi akış ayrıştırıcıları kullanarak, her 1000 satırda veritabanı kayıt noktaları uygulamak ve doğrulama için geçici tablolar oluşturmak. Artıları, dosya boyutuna bakılmaksızın sürekli bellek ayak izi (yaklaşık 150MB), UTF-8 normalliği, geçerli partileri koruma ve belirli hata satırlarını izole etme yeteneği ile ayrıntılı geri alma kabiliyeti ve işlem pencerelerinde referans bütünlüğünün korunmasıdır. Eksileri, önemli mimari yeniden yapılandırma gereksinimi, veritabanı satır kimliklerini orijinal CSV satır numaralarına geri eşleştirmek için karmaşık hata raporlama mantığı ve işlem sınır koşulları için artan test karmaşıklığıdır.
Seçilen çözüm: Çözüm 3'ü seçtik çünkü temel nedenleri ele aldı ve gelecekteki büyüme için sürdürülebilir bir mimari sağladı. Geliştirme ekibi, dosyaları 64KB parçalar halinde işleyen SAX-tarzı akış uyguladı, tüm girişi UTF-8'e çevirerek ayrıştırdı ve her 1000 satırda komit atan alt işlemler oluşturmak için PostgreSQL kayıt noktalarını kullandı.
Sonuç: Sistem, bellek dalgalanmaları 150MB'ı aşmadan toplamda 4GB olan 50 üretim dosyasını başarıyla içe aktardı. Kodlama dönüşümü, Windows-1252 akıllı tırnak işaretlerini ve Euro sembollerini doğru bir şekilde işledi. 3 dosyada bozulmuş tarih bulunduğunda, sistem verilerin %98'ini başarılı bir şekilde içe aktardı, hangi satırların düzeltilmesi gerektiğini doğru bir şekilde belirleyen hata raporları üretti ve göç süresini tahmin edilen 3 haftadan 4 güne, veritabanı bozulma olayları olmadan kısalttı.
CSV ayrıştırıcınızın doğru bir şekilde BOM (Bayt Sırası İşareti) imzalarını ele aldığını ve sütun başlıklarını bozulmadan geçirdiğini nasıl doğruluyorsunuz?**
Birçok testçi, Excel ve Notepad'in UTF-8 dosyalarına görünmez BOM baytları (0xEF 0xBB 0xBF) eklediğini göz ardı eder, bu da ilk sütun başlığının \ufeffCustomerID olarak değil, CustomerID olarak ayrıştırılmasına neden olur. Ayrıştırıcılar bu baytları doğrudan işlerken, alan eşleme hataları meydana gelir ve bunlar standart hata ayıklama günlüklerinde veya IDE konsollarında görünmez. Bunu test etmek için, BOM ile ve BOM olmadan dosyalar oluşturun, hex editörleri veya printf '\xEF\xBB\xBF' > file.csv gibi kabuk komutlarıyla dosyaları oluşturun, ardından uygulamanın bu baytları alma sırasında çıkarıp çıkarmadığını veya dizeleri Unicode NFC biçimi ile normalleştirip normalleştirmediğini kontrol edin. BOM mevcut olduğunda, bayt uzunluğu hesaplamalarının karakter uzunluğu hesaplamalarından farklı olduğunu doğrulayın, böylece sütun adı uzunluğu üzerindeki veritabanı kısıtlamalarının gizli karakterler tarafından ihlal edilmediğinden emin olun.
UI katmanında CSV ayırıcılarını test etme ile API katmanında test etme arasındaki fark nedir ve bu veri bütünlüğü için neden önemlidir?**
Adaylar genellikle sadece virgüllerle güzel yolu test ederler, Avrupa yerel ayarlarının Excel ayarları nedeniyle noktalı virgül kullandığını göz önünde bulundurmayarak, bu da UI doğrulaması ile API ayrıştırması arasında uyumsuzluklara neden olur. API uç noktaları sekme ile ayrılmış dosyaları kabul edebilecekken, UI bunun için virgül dayatıyor, bu da üretim verileri test verilerinden farklı olduğunda ayrıştırma hatalarına veya veri parçalanmasına yol açar. Test metodolojisi, Content-Type başlığının gerçek ayrıcılarla eşleştiğini doğrulamayı ve ayrıştırıcının otomatik olarak tespit etmesini veya katı bir şekilde doğrulamasını sağlamak için sekmeler, borular (|) ve noktalı virgüller ile test vakaları oluşturmayı gerektirir. Alıntılanmış alanların ayrıcıları (örn. "Smith, Jr., John") içermesi gerektiğini ve ayrı sütunlara ayrılmadıklarından emin olmalısınız, bu da soyad alanlarında veri parçalanmasını önler ve sonraki CRM entegrasyonlarını etkileyebilir.
İçe aktarılan veriler sonrasında dışa aktarılırken veya tabloların içinde görüntülendiğinde CSV enjeksiyon saldırıları için güvenlik test senaryolarını nasıl tasarlarsınız?
Manuel testçiler genellikle CSV formül enjeksiyonunu göz ardı eder, burada kötü amaçlı yükler gibi =cmd|'/C calc'!A0 veya +HYPERLINK("http://evil.com","Tıkla"), yöneticiler dışa aktarılan verileri Excel veya LibreOffice'de indirdiklerinde veya açtıklarında çalıştırılır. Bu, yönetici bilgisayarlarını tehlikeye atabilecek veya verileri dışa aktarabilecek depolanmış XSS şeklinde CSV'dir. Test metodolojisi, formül tetikleyicileri içeren giriş alanları oluşturmayı (=, +, -, @) ve ardından sistem komutları veya JavaScript yükleriyle devam etmeyi, ardından sunucu tarafı sanitizasyonunun formülleri etkisiz hale getirmek için önüne apostrof (') eklediğinden veya tehlikeli karakterleri tamamen temizlediğinden emin olmayı içerir. İçe aktarma, depolama ve dışa aktarım işlemini tamamlayarak, indirilen CSV dosyalarının formülleri gerçek metin olarak render ettiğini doğrulamak gerekir, böylece tablolar açıldığında çalıştırılmaz.