PDF ve Word metadata: bir belgenin ne zaman oluşturulduğu nasıl anlaşılır?

“Bu sözleşme gerçekten Mart'ta mı hazırlandı?” sorusu, dosyanın Özellikler penceresine bakılarak cevaplanamaz. O pencere, farklı kaynaklardan gelen tarihleri yan yana gösterir ve her biri başka bir olayı kaydeder. İlk iş, hangi tarihin nereden geldiğini ayırmaktır.

Dosya tarihi ile belgenin içindeki tarih aynı şey mi?

Hayır. Dosya sistemi tarihleri, dosyanın belirli bir diskteki kopyasına aittir ve kopyayla birlikte yeniden doğar. Belge içi tarihler ise belgeyi üreten uygulamanın dosyanın içine yazdığı alanlardır ve dosya nereye kopyalanırsa kopyalansın onunla birlikte taşınır. Windows'ta aynı pencerede ikisini de görürsünüz:

Genel sekmesinde “oluşturma tarihi, değiştirme tarihinden sonra” görüntüsü çoğu zaman manipülasyon değil, kopyalama izidir: içerik eski, bu diskteki kopya yenidir. Dosya sistemi zamanları da kesin değildir. Microsoft'un belgelerine göre NTFS zamanları UTC, FAT zamanları yerel saattir; uygulamalar SetFileTime ile oluşturma, erişim ve değiştirme zamanlarını dosyanın içeriğine dokunmadan değiştirebilir. Bu zamanlar tek başına bir belgeyi tarihlemeye yetmez.

PDF'te tarih ve yazılım bilgisi nerede durur?

PDF'te metadata iki yerde tutulur: dosyanın trailer bölümünden gösterilen Info sözlüğü (document information dictionary) ve PDF 1.4'ten beri tanımlı XMP metadata akışı. İkisinin çelişmesi, incelemenin en verimli başlangıç noktalarından biridir.

Info sözlüğü: Creator, Producer, CreationDate, ModDate

ISO 32000-1'e göre Creator, belge başka bir biçimden dönüştürüldüyse özgün belgeyi oluşturan ürünün adıdır; Producer, onu PDF'e dönüştüren ürünün adıdır. CreationDate belgenin oluşturulduğu, ModDate en son değiştirildiği tarih ve saattir.

Örnek: Word'den “PDF olarak kaydet” ile üretilmiş kurgusal bir belgenin Info sözlüğü:

/Creator      (Microsoft® Word for Microsoft 365)
/Producer     (Microsoft® Word for Microsoft 365)
/CreationDate (D:20260314092212+03'00')
/ModDate      (D:20260314092212+03'00')

Tarih biçimi D:YYYYMMDDHHmmSSOHH'mm şeklindedir: önce yerel tarih ve saat, sonra UTC'ye göre fark. Örnekteki değer 14 Mart 2026, 09:22:12, UTC+3'tür. Ofset kısmı isteğe bağlıdır; yazılmamışsa standart tarihi GMT kabul etmeyi öngörür. Ofset yazmayan bir programın gerçekte yerel saati mi UTC'yi mi yazdığı ise ancak aynı programla üretilmiş bir test belgesiyle anlaşılır.

Creator ile Producer birlikte, belgenin hangi yoldan PDF'e dönüştüğünü anlatır. Sık gördüğümüz görünümler:

• İkisi de aynı ofis programı: belge o programda hazırlanıp doğrudan PDF olarak kaydedilmiştir.
• Creator bir ofis programı, Producer bir sanal yazıcı ya da PDF kütüphanesi: belge “yazdır” menüsüyle PDF'e çevrilmiştir. macOS'ta yazdır menüsüyle üretilen PDF'lerde Producer alanında genellikle Quartz PDFContext görülür.
• Producer bir tarayıcı ya da tarama yazılımı: dosya taranmıştır ve CreationDate taramanın tarihidir, kâğıttaki belgenin değil.
• Producer bir PDF kütüphanesinin adı: belge çoğu zaman bir web hizmetinden ya da başka bir yazılımdan geçmiştir.

XMP akışı ve iki katmanın çelişmesi

XMP akışı aynı bilgileri XML olarak taşır: xmp:CreateDate, xmp:ModifyDate, xmp:MetadataDate, xmp:CreatorTool, pdf:Producer. Buna ek olarak belgenin sürüm ilişkilerini tutan xmpMM:DocumentID (aynı belgenin bütün sürümlerinde ortak kimlik), xmpMM:InstanceID (her kaydetmede yenilenen kimlik) ve düzenleme geçmişi xmpMM:History bulunabilir.

ISO 32000-1 §14.3.2'deki kural pratikte çok işe yarar: XMP'nin tarih damgası Info sözlüğündeki ModDate'ten eski değilse XMP esas alınır. Info'daki ModDate daha yeniyse standart bunu, belgenin XMP'den habersiz bir yazılımla kaydedildiğinin olası işareti sayar. Yani “Info'da 20 Mart, XMP'de 14 Mart” görüntüsü, belgenin 14 Mart'tan sonra Info'yu güncelleyip XMP'ye dokunmayan ikinci bir programdan geçtiğini düşündürür. Bu, yazılım davranışı sınanarak doğrulanacak bir hipotezdir.

PDF'in sonradan değiştirildiği nasıl anlaşılır?

Çoğu zaman dosyanın sonuna bakarak. ISO 32000-1 §7.5.6'ya göre bir PDF artımlı güncellemeyle (incremental update) değiştirildiğinde değişiklikler dosyanın sonuna eklenir ve özgün içerik olduğu gibi kalır. Silinen nesneler dosyadan çıkarılmaz, yalnızca çapraz başvuru tablosunda silindi olarak işaretlenir. Her güncellemenin kendi trailer'ı, bir önceki tabloya işaret eden Prev girdisi ve kendi %%EOF işareti olur. Aynı nesnenin birden çok kopyası dosyada yan yana durabilir.

Sonuç: önceki sürüm çoğu zaman dosyanın içindedir ve ilgili %%EOF noktasında kesilerek açılabilir. Metadata için de böyledir. ExifTool'un belgelerine göre araç PDF metadata'sını artımlı güncellemeyle yazar; değişiklikler “hızlı ve geri alınabilir”dir ve eski bilgi dosyadan hiçbir zaman gerçekten silinmez. Bir PDF'in tarihini değiştiren kişi, eski tarihi dosyanın içinde bırakmış olabilir.

Üç uyarıyla:

• İki %%EOF her zaman iki kaydetme demek değildir. Web'de hızlı görüntüleme için doğrusallaştırılmış (linearized) PDF'lerde ilk sayfa bölümünün trailer'ı da isteğe bağlı olarak %%EOF ile biter (ISO 32000-1, Ek F).
• Artımlı güncelleme yoksa değişiklik yoktur denemez. “Farklı kaydet”, optimize etme ya da yeniden yazdırma dosyayı baştan yazar ve geçmişi siler.
• Metin aramak yetmeyebilir. Modern PDF'lerde nesneler sıkıştırılmış akışlarda durabilir; revizyonlar bir PDF ayrıştırıcıyla çıkarılır.

Kendi dosyanızda ilk bakış için:

pdfinfo belge.pdf              # Creator, Producer, CreationDate, ModDate
pdfinfo -meta belge.pdf        # XMP akışı
exiftool -a -G1 -s belge.pdf   # Info ve XMP alanları, gruplarıyla
grep -a -c "%%EOF" belge.pdf   # kaba revizyon göstergesi

İmzalı bir PDF'te neye bakılır?

Dijital imza, belgenin baytlarından hesaplanan bir özetin imzalanmasıdır. Standarda göre imzanın kapsadığı bayt aralığı (ByteRange), imza değerinin kendisi hariç bütün dosya olmalıdır; farklı aralık kullanılabilir ama önerilmez, çünkü bütün değişiklikleri kapsamaz. İmzadan sonra yapılan değişiklikler artımlı güncelleme olarak eklenir ve imza anındaki hâl dosyanın içinden yeniden oluşturulabilir.

Zaman konusunda dikkat: imza sözlüğündeki M alanı, imza işleyicisine göre doğrulanmamış bir bilgisayar saati olabilir. Güvenilir imza zamanı, imzaya gömülü bir zaman damgasından gelir. “İmza geçerli” uyarısı da revizyon incelemesinin yerini tutmaz: 2021'de yayımlanan bir çalışmada test edilen 29 PDF görüntüleyicisinin 16'sı, imzalı belgede içeriği gizleyen ya da değiştiren “shadow” saldırılarına açık çıktı. Hukuki açıdan HMK m.205/2'ye göre güvenli elektronik imzayla usulüne uygun oluşturulan elektronik veriler senet hükmündedir ve m.205/3'e göre hâkim bunu resen inceler; imzanın teknik doğrulaması bu değerlendirmeye veri sağlar.

Word belgesinin oluşturma tarihi nerede yazar?

DOCX dosyası bir ZIP paketidir. Bir kopyasını arşiv programıyla açtığınızda tarih ve kişi bilgileri birkaç küçük XML dosyasında çıkar karşınıza:

• docProps/core.xml: oluşturan, son değiştiren, oluşturma, değiştirme ve son yazdırma tarihleri, kaydetme sayacı.
• docProps/app.xml: uygulama adı ve sürümü, şablon, toplam düzenleme süresi, sayfa ve kelime sayısı, varsa şirket adı.
• word/settings.xml: düzenleme oturumlarının rsid listesi.
• word/document.xml ve word/comments.xml: metin, değişiklik izleme kayıtları, yorumlar.
• word/media/: belgeye eklenmiş görseller. Bunlar kendi EXIF bilgisini taşıyabilir (bkz. EXIF verisi nedir).

Örnek: Kurgusal bir sözleşme taslağının core.xml dosyasından:

<dc:creator>kullanici</dc:creator>
<cp:lastModifiedBy>Ofis-PC</cp:lastModifiedBy>
<cp:revision>7</cp:revision>
<dcterms:created xsi:type="dcterms:W3CDTF">2026-03-10T07:41:00Z</dcterms:created>
<dcterms:modified xsi:type="dcterms:W3CDTF">2026-03-14T06:22:00Z</dcterms:modified>
<cp:lastPrinted>2026-03-14T06:25:00Z</cp:lastPrinted>

Sondaki Z, saatin UTC olduğunu gösterir; Türkiye saatiyle oluşturma 10 Mart 10:41, son değişiklik 14 Mart 09:22'dir. Okurken bildiğimiz tuzaklar:

• created miras kalabilir. Eski bir belge açılıp içeriği değiştirilerek yeni adla kaydedildiğinde ya da bir şablondan türetildiğinde, oluşturma tarihi yeni metnin değil kaynağın tarihini gösterebilir. “Belge 2019'da oluşturulmuş” bulgusu, metnin 2019'da yazıldığı anlamına gelmeyebilir.
• lastModifiedBy bir kimlik değildir. Office'te ayarlı kullanıcı adıdır.
• TotalTime dakika cinsindendir (Microsoft'un Open XML belgeleri) ve belgenin Word'de açık kaldığı süreye dayanır, yazılan metin miktarını ölçmez. Kırk sayfalık belgede iki dakikalık süre, metnin başka yerden kopyalandığını düşündürebilir ama tek başına bir şey kanıtlamaz.
• Uygulama adı yolu anlatır. LibreOffice ya da bir web editörüyle kaydedilen DOCX'te Application farklıdır, bazı alanlar hiç yazılmaz.
• Şablon adı ipucu verir. Template alanında Normal.dotm dışında bir ad, belgenin belirli bir kurum şablonundan türediğini gösterebilir.

rsid: düzenleme oturumlarının izi

Word her düzenleme oturumuna, yani iki kaydetme arasındaki süreye, bir rsid (revision save ID) değeri verir ve bunları settings.xml içindeki w:rsids listesinde tutar. İlk oturum w:rsidRoot olarak ayrıca yazılır. ECMA-376'ya göre her yeni oturumun değeri öncekilerden büyük olmalıdır; paragraf ve metin parçalarındaki w:rsidR, w:rsidRPr gibi öznitelikler o metnin hangi oturumda eklendiğini gösterir. Standarda göre aynı rsidRoot değerini taşıyan iki belgede aynı rsid, aynı düzenleme oturumu demektir; ortak kök, iki belgenin aynı ilk belgeden türediğine işaret eder. Kökleri farklı belgelerde rsid karşılaştırmasının anlamı tanımlı değildir.

Uygulamada, “bağımsız hazırlandı” denen iki sözleşmenin aynı dosyadan türediğini ya da tartışmalı bir maddenin sonraki bir oturumda eklendiğini göstermeye yarar. Sınırı: standart, üreticinin rsid tutmasını zorunlu kılmaz; rsid'siz bir belge bu yüzden anlamlı bir yokluk taşımayabilir.

Değişiklik izleme, yorumlar ve eski .doc biçimi

Değişiklik izleme açıkken eklenen ve silinen metin w:ins ve w:del öğeleriyle, w:author ve w:date öznitelikleriyle kaydedilir; güncel Microsoft 365 sürümleri buna UTC olarak tanımlanan w16du:dateUtc özniteliğini de ekler (MS-DOCX). Yorumlar da yazar ve tarih taşır. Kabul edilen değişiklikler ise belgeden iz bırakmadan çıkar.

2007 öncesinin .doc biçiminde aynı bilgiler, OLE yapısındaki \005SummaryInformation akışında durur: oluşturma ve son kaydetme zamanı, son yazdırma, toplam düzenleme süresi, son kaydeden ve düzeltme numarası. Zaman alanları Windows FILETIME biçiminde ve UTC'dir; ham değerleri zaman damgası dönüştürücüyle çevirebilirsiniz.

Kendi bilgisayarınızda bu alanlara nasıl bakılır?

1. Windows Gezgini: Dosyaya sağ tıklayın, Özellikler. Genel sekmesi dosya sistemi tarihlerini, Ayrıntılar sekmesi belgenin içinden okunan özellikleri gösterir.
2. Word: Dosya, Bilgi, Özellikler, Gelişmiş Özellikler. İstatistikler sekmesinde oluşturma, değiştirme, erişim ve yazdırma tarihleri, son kaydeden, düzeltme numarası ve toplam düzenleme süresi yer alır. Buradaki erişim tarihi dosya sisteminden gelir.
3. Adobe Acrobat ve Acrobat Reader: Belge Özellikleri penceresi (Windows'ta Ctrl+D, Mac'te ⌘D), Açıklama sekmesi. Oluşturma ve değiştirme tarihleri ile uygulama (Application, yani Creator) ve PDF üreticisi (PDF Producer, yani Producer) satırları buradadır. Ek Meta Veriler (Additional Metadata) düğmesi, bulunduğu sürümlerde XMP ayrıntılarını açar.
4. Mac'te Önizleme: Araçlar, Denetçiyi Göster (⌘I). PDF'in oluşturan ve üreten uygulaması ile tarihleri görünür. Finder'daki Bilgi Al penceresi ise dosya sistemi tarihlerini gösterir.
5. Komut satırı: unzip -p belge.docx docProps/core.xml çekirdek özellikleri ekrana döker; PDF için yukarıdaki komutlar kullanılır.

PDF oluşturma tarihi değiştirilebilir mi? İzler ve hüküm sınırları

Evet; bu yazıdaki tarih katmanlarının hepsi değiştirilebilir. Asıl soru, değiştirildiyse iz kalıp kalmadığıdır. Sık rastladığımız izler:

• Zaman uyumsuzluğu (anakronizm). Producer, AppVersion ya da gömülü yazı tipinde, belgenin iddia edilen tarihinden sonra yayımlanmış bir yazılım sürümünün görünmesi. Belgenin yapısında, iddia edilen tarihte henüz bulunmayan bir biçim özelliğinin yer alması. Sürümlerin yayın tarihleri üreticinin kaynaklarından doğrulanır.
• Info ile XMP tarihlerinin, DocumentID ve InstanceID değerlerinin birbirini tutmaması.
• Artımlı güncellemelerde önceki bir tarih ya da önceki bir metin.
• Kendi içinde çelişen Office alanları: son yazdırmanın oluşturmadan önce olması, on iki kaydetmeye karşılık sıfır dakikalık düzenleme süresi, rsid sayısıyla kaydetme sayacının hiç uyuşmaması.
• Dış kayıtlarla çelişki: belgenin gönderildiği e-postanın zamanı (bkz. e-posta başlığı nasıl okunur), bulut hizmetinin sürüm geçmişi, dosya sunucusu ve yedek kayıtları. Bunlar belgeden bağımsız tutulduğu için çoğu zaman en güçlü tarihtir.

İz bulunmaması belgenin değiştirilmediğini göstermez; baştan yeniden üretilen bir dosya temiz görünebilir. Hangi alanın kim tarafından değiştirildiği metadata'dan okunamaz. Kâğıt belgedeki ıslak imza ve mürekkep, dijital incelemenin değil adli belge incelemesinin konusudur. Biz bulguları “iddia edilen tarih ve yazılımla uyumlu”, “uyumsuz” ya da “bu materyalle belirlenemez” diye raporlarız; “sahtedir” hükmü kurmayız. Sahtecilik bir hukuki nitelendirmedir ve değerlendirmesi mahkemeye aittir.

HMK m.199'a göre elektronik ortamdaki veriler de belgedir. Bir DOCX ya da PDF dosyasının ne zaman ve hangi yazılımla üretildiği sorusunu materyal, yöntem ve sınırlarıyla cevaplayan inceleme görüntü, video ve doküman metadata incelemesi kapsamındadır. Hazırlanan rapor hukuk davasında uzman görüşü, ceza dosyasında bilimsel mütalaa olarak sunulabilir; mahkemeyi bağlamaz, diğer delillerle birlikte değerlendirilir.