Kolay Araçlar

Taranmış PDF'ten Neden Yazı Kopyalanamıyor?

İçinde metin olan PDF ile taranmış PDF arasındaki fark, OCR'ın ne yaptığı, iki sütunlu belgelerin neden karıştığı ve OCR'ın düzeltemediği hatalar.

13 Ağustos 2026

Bir PDF açıyorsunuz, ekranda gayet net bir yazı duruyor. Fareyle üstünden geçiyorsunuz, hiçbir şey seçilmiyor. Ctrl+File arıyorsunuz, gözünüzle gördüğünüz kelimeyi “bulunamadı” diyor.

Belge bozuk değil. İçinde metin yok, fotoğraf var.

İki farklı PDF türü

PDF adı altında birbirinden çok farklı iki şey dolaşıyor ve dışarıdan ayırt edilmiyorlar.

Doğuştan dijital PDF. Word, Excel veya bir muhasebe programından “PDF olarak kaydet” ile çıkmış belge. İçinde harfler harf olarak duruyor: hangi yazı tipiyle, hangi koordinata, hangi karakterin yazılacağı yazılı. Seçilebiliyor, aranabiliyor, kopyalanabiliyor.

Taranmış PDF. Bir tarayıcı cihazından ya da telefon kamerasından çıkmış belge. İçinde tek bir şey var: sayfanın fotoğrafı. Sizin yazı olarak gördüğünüz şey, bilgisayar için koyu ve açık piksellerden ibaret. Seçilecek harf yok, çünkü harf yok.

Üçüncü bir durum: metin var ama çöp çıkıyor

Daha az bilinen bir ara durum: belge doğuştan dijital, metin seçilebiliyor, ama kopyalayıp yapıştırınca anlamsız karakterler geliyor.

Sebebi şu: PDF, gömülü yazı tipinin her şekli için “bu şekil hangi harfe karşılık geliyor” bilgisini ayrıca taşımak zorunda. Bazı üretici programlar bu eşlemeyi yazmıyor. Sayfa doğru görünüyor (çünkü çizim talimatı doğru) ama kopyalanan şey harflerin kendisi değil, iç numaraları.

Bu durumda yapılabilecek tek şey belgeyi görüntü gibi ele alıp OCR’dan geçirmek. PDF metin çıkarma aracımız bu iki durumu da tespit edip söylüyor; boş ya da çöp çıktı verip sizi tahminde bırakmıyor.

Hangisi olduğunu nasıl anlarsınız

Belgeyi açın, bir kelimenin üstünden fareyle sürükleyin. Seçim vurgusu çıkıyorsa metin var. Çıkmıyorsa taranmış. İkinci sınama: Ctrl+F ile sayfada gözünüzle gördüğünüz bir kelimeyi aratın.

OCR ne yapıyor

OCR) optik karakter tanıma) görüntüdeki harf şekillerini tanıyıp metne çeviriyor. Sayfa parçalara ayrılıyor, her parçadaki şekil bilinen harflerle karşılaştırılıyor, en olası karşılık seçiliyor.

Türkçe için dil verisi ayrıca gerekiyor: ş, ğ, ı, İ, ç, ö, ü harfleri İngilizce modelde yok ve o modelle taranan Türkçe belgede “ı”lar “i”, “ş”ler “s” çıkıyor. Türkçe belgelerde İngilizce terim geçmesi de kural olduğu için aracımız ikisini birlikte çalıştırmayı da sunuyor.

Neden iki sütunlu belgeler karışıyor

OCR’ın en sık görülen kusuru harf hatası değil, sıra hatası. İki sütunlu bir sayfada çıktı şöyle oluyor:

“…belge düzen- Sağ sütun burada başlar ve sol lenmiştir…”

Sebep şu: motor sayfayı tek sütun sayıp aynı yükseklikteki her şeyi tek satır kabul ediyor. Sol sütunun bir satırı ile sağ sütunun aynı hizadaki satırı birleşiyor ve metin okunamaz hâle geliyor.

Çözüm sıralamada: sütun ayrımı, satır gruplamadan önce gelmeli. Yani önce sayfada dikey boşluk şeritleri (oluklar) aranmalı, sütunlar ayrılmalı, satırlar ancak ondan sonra kurulmalı. Sıra ters olduğunda ayrımı yapmanın yolu kalmıyor, iki sütun zaten tek satırda birleşmiş oluyor.

Bizim aracımız bu yüzden motorun hazır satırlarını kullanmıyor, kelimelerini alıp kendi yerleşim motorumuzdan geçiriyor. Bu motor doğuştan dijital PDF’ler için zaten yazılmıştı; OCR çıktısı da aynı hattan geçince sayfa numarası ayıklama, tire birleştirme ve üstbilgi ayıklama kendiliğinden çalışıyor.

Gerçek bir belgede çıkan iki kusur

Bunları 303 sayfalık taranmış bir kitapla ölçtük ve üretilmiş test dosyalarının göremediği iki şey çıktı.

Basılı sayfa numaraları metnin içine giriyordu. 278 sayfada numara vardı ve hiçbiri kenar bölgesinde değildi; çoğu gövdeyle aynı hizada durduğu için cümlenin ortasına karışıyordu: “…daha büyük bir kuvvetle, 29 genellikle tereddüt…”. Konuma bakan bir ayıklama bunu yakalayamıyor. Çözüm konuma değil diziye bakmak: basılı numara ile gerçek sayfa numarası arasındaki fark belge boyunca sabit kalıyor.

Başlık sezimi paragrafları parçalıyordu. Gövdeden bir tık büyük dizilmiş madde listeleri başlık sanılıyor, her satır ayrı blok oluyor ve metin satır satır dağılıyordu. Kural değişti: aynı puntoyu paylaşan üç veya daha fazla ardışık “başlık” artık bloktur, gövdeye döner.

OCR’ın düzeltemedikleri

Kusursuz değil ve bazı hatalar bu yöntemle çözülemiyor:

  • Tiresiz bölünmüş kelimeler. “rezonans” yerine “rezo nans”. Aradaki boşluğun gerçek mi tarama artığı mı olduğunu anlamak sözlük ister.
  • Tarama artıkları. Kağıt lekesi ve cilt gölgesi noktalama işareti olarak okunuyor.
  • El yazısı. Bu araçların tanıdığı şey basılı yazı.
  • Kötü tarama. Eğri, gölgeli, düşük çözünürlüklü sayfada hata oranı hızla artıyor.

Bu yüzden çıktıya bir yüzde başarı oranı vermiyoruz. Motorun ürettiği güven sayısı bir olasılık değil, kendi iç ölçüsü; yüzde olarak sunmak olmayan bir kesinlik iddia etmek olurdu. Üç kademeli bir gösterge veriliyor ve çıktı her hâlükârda okunup düzeltilmeli.

Daha iyi sonuç için

  • Sayfayı düz tarayın; eğri sayfada satırlar birbirine giriyor.
  • Telefonla çekiyorsanız dört köşeyi işaretleyip perspektifi düzeltin.
  • Çözünürlük düşükse artırın; çok küçük yazı tanınmıyor.
  • Gölgeden kaçının, kitap cildinin gölgesi en sık sorun.

OCR aracımızda belge cihazınızdan çıkmıyor: tanıma motoru ve dil verisi kendi sunucumuzdan tarayıcınıza iniyor ve iş orada yapılıyor. Bu alandaki araçların neredeyse tamamı belgeyi kendi sunucularına yüklüyor, kimlik fotokopisi, tapu veya bordro tararken aradaki fark önemli. Sayfa sınırı 50; bedeli hem bellek hem süre.

Belgeyi metne değil de görüntüye çevirmek istiyorsanız PDF’i görsele çevirme aracı ayrı bir yerde.

Yazıda geçen araçlar

Hepsi ücretsiz ve tarayıcınızda çalışıyor; dosyanız cihazınızdan çıkmıyor.