text_fields PDF'ten Metin Çıkarma star

PDF'in Metin Katmanı Gerçekte Nedir

Bir PDF, çoğu zaman bir sayfanın fotoğrafı değildir. Bir kelime işlemciden, web sayfasından veya dizgi yazılımından üretildiğinde, sayfa içeriği bir dizi çizim komutu olarak saklanır: sayfadaki her karakter için tekrarlanan "G glyph'ini (x, y) konumuna, F fontuyla, S boyutunda yerleştir" komutu. Bu glyph-yerleştirme komutlarının her biri, bir fontun karakter-kodlama tablosuna geri bir referans taşır; yazılımın çizilen şekli sadece bir resim olarak değil, gerçek bir Unicode karaktere geri eşleyebilmesini sağlayan da budur. Bu araç, PDF'i Mozilla'nın açık kaynaklı pdf.js kütüphanesiyle yükleyip her sayfada getTextContent() API'sini çağırarak çalışır — kritik nokta, bu, sayfayı hiçbir zaman piksellere render etmeden komut akışını doğrudan okur; bu yüzden grafik hızlandırması olmayan bir cihazda bile çalışır ve render etmeye kıyasla neredeyse anında sonuç verir.

Bu, taranmış bir PDF'ten temelde farklıdır — kağıt bir belge fotoğraflandığında veya bir tarayıcıdan geçirilip PDF olarak kaydedildiğinde elde ettiğiniz şey budur. Bu durumda "sayfa" arkasında hiç glyph komutu olmayan, tam sayfalık bir JPEG veya TIFF görselinden ibarettir, çünkü hiçbir yazılım metnin ne dediğini bilmemiştir; sadece pikselleri yakalamıştır. Taranmış bir sayfada getTextContent() çağırmak hiçbir şey veya neredeyse hiçbir şey döndürmez, çünkü okunacak bir metin katmanı yoktur — bilgi gerçekten dosyada mevcut değildir, tıpkı normal bir PDF görüntüleyicisinde taranmış bir sayfada metin seçemediğiniz gibi. Taranmış bir belgeden metin kurtarmak tamamen farklı bir teknik gerektirir: piksel şekillerini analiz edip karakterleri tahmin eden OCR (optik karakter tanıma) — bu, temelde farklı, çok daha hataya açık bir süreçtir ve bu araç bunu yapmaz. PDF'iniz bir tarama ise, bunun yerine özel bir resimden-yazıya (OCR) aracına bakın — bu sitede ayrı olarak planlanan bir araç var.

Çıkarılan Metin Neden Sırasız Gelebilir

Gerçek bir metin katmanına sahip PDF'leri bile etkileyen daha ince bir sorun var: getTextContent(), glyph-yerleştirme öğelerini PDF üretildiğinde orijinal olarak çizildikleri sırayla döndürür — bu, bir insanın okuyacağı sırayla aynı olmak zorunda değildir. Çoğu basit, tek sütunlu belge yukarıdan aşağıya, soldan sağa çizilir, doğal okuma sırasıyla eşleşir, bu yüzden çıkarma doğru görünür. Ama bir PDF dışa aktarıcısı içeriği istediği herhangi bir sırada çizmekte serbesttir ve birçoğu görsel sırayı korumaz: iki sütunlu akademik bir makale, bir dergi düzeni, bir tablo veya metin kutuları ile açıklamaları olan bir PDF, çizim sırası okuyucunun gözünün sayfada hareket edeceği sırayla kolayca iç içe geçmiş veya tamamen tersine dönmüş olabilir, çünkü spesifikasyon konumu tanımlar, okuma sırasını değil. Bu araç her sayfanın öğelerini pdf.js'in bildirdiği sırayla birleştirir ve sayfaları net bir --- Sayfa N --- işaretiyle ayırır, böylece her bloğun hangi sayfadan geldiğini tam olarak görebilir ve gerektiğinde çok sütunlu bir sonucu elle yeniden sıralayabilirsiniz.

• Hiçbir şey yüklenmez: PDF, tarayıcınızda çalışan pdf.js kullanılarak tamamen istemci tarafında ayrıştırılır; dosya bu sitenin sunucusuna hiç ulaşmaz.
• Parola korumalı PDF'ler açılamaz — bu araç PDF şifrelemesini veya izinlerini aşmaya çalışmaz.
• Çıkarılan boşluklar görsel düzenden farklı olabilir — özellikle tablolar genelde biçimlendirilmiş bir ızgara yerine düz bir hücre-değeri dizisi olarak çıkarılır, çünkü PDF'in HTML'deki gibi yerleşik bir "tablo" kavramı yoktur.
• Çok sayfalı belgeler sayfa işaretleri alır, böylece bir sayfanın içeriğinin nerede bittiğini ve bir sonrakinin nerede başladığını anlayabilirsiniz, çünkü PDF sayfaları aksi halde aralarında doğal bir paragraf sınırı olmayan bağımsız içerik akışlarıdır.