PDF मेटाडेटा और छिपा डेटा
अंतिम अपडेट:
दस्तावेज़ मेटाडेटा वह जानकारी है जो कोई फ़ाइल पेज के कंटेंट से परे अपने बारे में साथ ले जाती है: उसके फ़ील्ड किसे उसका लेखक बताते हैं, किस एप्लिकेशन ने उसे बनाया, वह कब बनाई और बदली गई बताती है, और कौन-सी पुरानी सामग्री अभी भी उसके अंदर है। एक PDF दो अतिव्यापी मेटाडेटा प्रणालियाँ, पुराने संशोधनों की एक शृंखला, पूरी एम्बेडेड फ़ाइलें और अदृश्य रूप से रंगा गया टेक्स्ट रख सकती है; एक JPEG तस्वीर कैमरे की डायरी रखती है; एक साधारण PNG स्क्रीनशॉट भी उस सॉफ़्टवेयर का नाम बताता है जिसने उसे बनाया। यह लेख इनमें से हर छिपने की जगह कहाँ है, डेटा सामान्य संपादन से क्यों बच जाता है, और असली लीक कैसे हुए, यह बताता है। पढ़ते हुए अपनी कोई फ़ाइल जाँचने के लिए, डॉक्यूमेंट फ़ोरेंसिक टूल चलाएँ — यह आपके ब्राउज़र में स्थानीय रूप से काम करता है — और उन्हीं फ़ाइलों के पठन-संरचना पक्ष के लिए, आपकी PDF आपकी वेबसाइट की एक्सेसिबिलिटी का हिस्सा हैं देखें।
हर PDF के अंदर दो मेटाडेटा प्रणालियाँ साथ चलती हैं
दोनों में पुरानी है जानकारी शब्दकोश, फ़ाइल के ट्रेलर में संग्रहीत कुंजी–मान युग्मों का एक छोटा समूह: Title, Author, Creator (मूल दस्तावेज़ बनाने वाला एप्लिकेशन), Producer (PDF बनाने वाला एप्लिकेशन), CreationDate और ModDate। ये फ़ील्ड निर्यात के समय स्वतः लिखे जाते हैं, और अधिकांश दस्तावेज़ लेखक वह गुण संवाद कभी नहीं खोलते जो उन्हें दिखाए — और ठीक यही कारण है कि वे लीक होते हैं। व्यक्तिगत लैपटॉप से निर्यात की गई रिपोर्ट उस लैपटॉप के खाता नाम को अपने लेखक के रूप में साथ ले जाती है। पिछले साल के टेम्पलेट से शुरू किया गया दस्तावेज़ अभी भी पिछले साल के लेखक का नाम बताता है। इनमें से कुछ भी छपे हुए पेज पर दिखाई नहीं देता, और यह सब फ़ाइल के हर प्राप्तकर्ता से सिर्फ़ एक गुण पैनल की दूरी पर है।
नई प्रणाली है XMP, दस्तावेज़ में एम्बेडेड एक XML पैकेट, जो Adobe के एक्सटेंसिबल मेटाडेटा प्लेटफ़ॉर्म पर बना है और स्वयं PDF विनिर्देश, ISO 32000-2, के साथ वर्णित है। XMP नामस्थानों में उसी क्षेत्र का अधिकांश दोहराता है: शीर्षक के लिए dc:title, pdf:Producer, xmp:CreateDate और xmp:ModifyDate, साथ में वे फ़ील्ड जो पुराने शब्दकोश में कभी नहीं थे, जैसे निर्माता टूल। दो प्रणालियाँ होना हानिरहित होता यदि उन्हें तालमेल में रखा जाता, लेकिन वे रखी नहीं जातीं: एक टूल जानकारी शब्दकोश को अपडेट करता है और XMP को अनदेखा करता है, दूसरा XMP को फिर से लिखता है और शब्दकोश को पुराना छोड़ देता है, तीसरा एक को हटाता है और दूसरे को रखता है। परिणाम यह है कि एक ही फ़ाइल नियमित रूप से अपने बारे में दो थोड़ी अलग कहानियाँ सुनाती है — और असहमति स्वयं एक जानकारी है, क्योंकि यह दर्ज करती है कि एक से अधिक टूल ने, एक से अधिक क्षणों में, उस दस्तावेज़ को छुआ है।
वृद्धिशील अपडेट: वह अनुच्छेद जो हटाया गया पर कभी गया नहीं
PDF को केवल-जोड़ संपादन के लिए बनाया गया था। जब कोई संपादक बदलाव को वृद्धिशील रूप से सहेजता है, तो वह फ़ाइल को फिर से नहीं लिखता: वह बदली हुई वस्तुओं, एक नए क्रॉस-रेफ़रेंस सेक्शन और एक नए ट्रेलर को अंत में जोड़ता है, और /Prev पॉइंटर से पिछले ट्रेलर से शृंखला बनाता है। हर संशोधन अपने स्वयं के %%EOF मार्कर के साथ समाप्त होता है, इसलिए उन मार्करों को गिनने से यह न्यूनतम सीमा मिलती है कि फ़ाइल इस तरह कितनी बार सहेजी गई है — और हर पुराना संशोधन भौतिक रूप से बाइट में मौजूद और पठनीय रहता है। ऐसी फ़ाइल को सामान्य दर्शक में खोलें तो आपको सिर्फ़ सबसे नया संशोधन दिखता है। बाइट पढ़ें, या शृंखला को पीछे जाएँ, तो दस्तावेज़ की पुरानी स्थिति अभी भी वहाँ है: तालिका का पुराना आँकड़ा, खंड का पिछला शब्द-विन्यास, प्रकाशन से पहले हटाया गया अनुच्छेद।
यही वह तंत्र है जो उन रिडैक्शन विफलताओं के पीछे है जो ख़बरों में आती रहती हैं। एक टीम को नाम या आँकड़े रोके गए रिपोर्ट प्रकाशित करनी होती है, इसलिए कोई संवेदनशील अंशों पर काले आयत बनाता है — एक ड्रॉइंग ऑपरेशन जो पेज की दिखावट बदलता है और नीचे कुछ नहीं छूता — या किसी ऐसे संपादक में टेक्स्ट हटाता है जो फिर वृद्धिशील रूप से सहेजता है, हटाई गई वस्तुओं को पुराने संशोधन में छोड़ देता है। प्रकाशित फ़ाइल साफ़ दिखती है। कुछ दिनों बाद, कोई पाठक “रिडैक्ट किए गए” क्षेत्र को चुनता है, उसे कॉपी करता है, और मूल शब्दों को टेक्स्ट संपादक में चिपका देता है; या कोई शोधकर्ता संशोधन शृंखला को पार्स करता है और हटाई गई चीज़ को पुनः प्राप्त करता है। असली रिडैक्शन ढकने से अलग ऑपरेशन है: अंतर्निहित कंटेंट को कंटेंट स्ट्रीम से हटाना होता है और फ़ाइल को पूरी तरह फिर से लिखना होता है, ताकि स्वयं बाइट में वह न रहे जो पेज अब नहीं दिखाता। यदि आप जो फ़ाइल प्रकाशित करने वाले हैं उसमें कई %%EOF मार्कर हैं, तो उसका इतिहास अभी भी उसके अंदर है — मानकर चलें कि कोई प्रेरित पाठक वह इतिहास पढ़ेगा।
एम्बेडेड फ़ाइलें और छिपा टेक्स्ट: वह माल जिसे कोई सूचीबद्ध नहीं करता
एक PDF पूरे फ़ाइलों को अपने अंदर साथ ले जा सकती है। यह फ़ॉर्मेट एक एम्बेडेड फ़ाइलें नाम ट्री परिभाषित करता है, जिस तक /EmbeddedFiles और /Filespec वस्तुओं के माध्यम से पहुँचा जाता है, और लेखन टूल इसे स्रोत स्प्रेडशीट, डेटा परिशिष्ट और पोर्टफोलियो दस्तावेज़ों के लिए उपयोग करते हैं। उन्हें उजागर करने वाला अटैचमेंट पैनल वह है जिसे अधिकांश पाठक कभी नहीं खोलते, इसलिए एम्बेडेड माल चुपचाप यात्रा करता है: चमकदार PDF सारांश प्रकाशित करें और आप उसके पीछे की कार्यशील स्प्रेडशीट भी प्रकाशित कर सकते हैं, उसके अपने मेटाडेटा, उसकी ड्राफ़्ट शीट और उसकी टिप्पणियों के साथ। प्राप्तकर्ताओं के लिए इसका उल्टा भी सच है — प्राप्त PDF के अंदर का अटैचमेंट अपने चारों ओर के दस्तावेज़ का विश्वास विरासत में पाता है, और यही कारण है कि एम्बेडेड फ़ाइलें किसी भी निरीक्षण चेकलिस्ट में एक पंक्ति की हक़दार हैं, संयोग से खोजे जाने की नहीं।
टेक्स्ट अलग फ़ाइल बने बिना भी छिप सकता है। PDF टेक्स्ट को एक रेंडरिंग मोड से रंगता है, और मोड 3 — 3 Tr ऑपरेटर से सेट किया गया — न भरता है न रेखा खींचता है: अक्षर कंटेंट स्ट्रीम में होते हैं, उन्हें चुना, खोजा और निकाला जा सकता है, और वे पेज पर पूरी तरह अदृश्य होते हैं। कुछ अदृश्य टेक्स्ट वैध और मूल्यवान है: स्कैन किए गए पेज के पीछे की OCR परत ठीक यही है, छिपा टेक्स्ट जो किसी छवि को खोज-योग्य बनाता है। समस्या वह सब है जो मोड 3 या उसके संबंधियों में पहुँचता है — सफ़ेद पृष्ठभूमि पर सफ़ेद टेक्स्ट, दृश्य पेज से बाहर कटा हुआ टेक्स्ट, खोज इंजनों के लिए जोड़ी गई कीवर्ड परत — क्योंकि टेक्स्ट परत निकालने वाला पाठक वे शब्द पाता है जो पेज ने कभी नहीं दिखाए। जब छिपी परत दृश्य परत से असहमत होती है, तो फ़ाइल एक साथ दो बातें कह रही होती है, और उनमें से सिर्फ़ एक का प्रूफ़ पढ़ा गया होता है।
छवियाँ भी डायरी रखती हैं: PNG चंक और JPEG Exif
एक PNG फ़ाइल नामित चंकों का अनुक्रम है, और कई चंक प्रकार केवल टेक्स्ट साथ ले जाने के लिए मौजूद हैं: tEXt, उसका संपीड़ित भाई zTXt और अंतरराष्ट्रीयकृत iTXt। निर्यात टूल उन्हें आदतन लिखते हैं — संपादक का नाम बताने वाला एक Software कीवर्ड, एक निर्माता टूल स्ट्रिंग, कभी-कभी एक पूरा एम्बेडेड XML प्रोफ़ाइल — और वे हर क्रॉप और आकार-परिवर्तन से बच जाते हैं जो चंक सूची को अक्षुण्ण छोड़ता है। tIME चंक अंतिम-संशोधन टाइमस्टैम्प जोड़ता है, एक eXIf चंक पूरा कैमरा मेटाडेटा ब्लॉक रख सकता है, और समापन IEND चंक के बाद जोड़े गए बाइट हर दर्शक द्वारा अनदेखा किए जाते हैं जबकि फ़ाइल में रहते हैं। एक स्क्रीनशॉट जो खिड़की की तटस्थ तस्वीर जैसा दिखता है, इस प्रकार मशीन के सॉफ़्टवेयर का नाम बता सकता है, स्वयं को दिनांकित कर सकता है, और वह डेटा साथ ले जा सकता है जो उसके लेखक ने कभी नहीं देखा।
JPEG तस्वीरें और आगे जाती हैं। फ़ाइल मार्कर सेगमेंटों की एक शृंखला है: APP0 JFIF हेडर रखता है, APP1 या तो Exif ब्लॉक रखता है या XMP पैकेट — कभी-कभी दोनों। Exif के IFD0 फ़ील्ड कैमरे की डायरी जैसे पढ़े जाते हैं: डिवाइस का Make और Model, वह DateTime जब तस्वीर ली गई या आख़िरी बार बदली गई, उसे प्रोसेस करने वाला Software, और विस्तारित निर्देशिकाओं में GPS निर्देशांक। कैमरा रोल से सीधे प्रकाशित फ़ोन तस्वीरों ने संगठनों और व्यक्तियों दोनों को शर्मिंदा किया है, उन्हें ठीक उस समय और स्थान पर रखकर जो तस्वीर ने स्वयं कभी नहीं दिखाया। टिप्पणी (COM) सेगमेंट फ़ाइल को आख़िरी बार सहेजने वाले टूल से मुक्त टेक्स्ट जोड़ते हैं, अतिरिक्त बाइट छवि-अंत मार्कर के बाद रह सकते हैं, और यह सब पढ़ने वाला टूल — Phil Harvey का ExifTool, स्रोतों में सूचीबद्ध — एक मुफ़्त डाउनलोड है, जिसका अर्थ है कि आपके प्राप्तकर्ता भी उसे पढ़ सकते हैं।
टाइमस्टैम्पों की परस्पर जाँच करें, फिर प्रकाशित करने से पहले साफ़ करें
एक अकेला टाइमस्टैम्प एक दावा है; कई टाइमस्टैम्प एक कहानी हैं जिसे स्वयं से परस्पर जाँचा जा सकता है। संशोधन तारीख़ के बाद पड़ने वाली निर्माण तारीख़ उस दस्तावेज़ का वर्णन नहीं कर सकती जो एक टूल ने एक ही बार में बनाया हो। उसी घटना के लिए जानकारी शब्दकोश की तारीख़ का XMP तारीख़ से असहमत होना दो घड़ियों वाले दो टूल दर्ज करता है। भविष्य की तारीख़ ग़लत सेट की गई घड़ी, हाथ से संपादित फ़ील्ड, या टुकड़ों से जोड़ी गई फ़ाइल दर्ज करती है। स्वयं PDF तारीख़ प्रारूप भी अस्पष्टता को न्योता देता है — D: स्ट्रिंग अपना समय क्षेत्र छोड़ सकती है, जिससे पाठकों को अनुमान लगाना पड़ता है कि संख्याएँ किस घड़ी से आईं। हर असंगति को वैसे ही लें जैसे कोई लेखा परीक्षक बही-खाते की विसंगति को लेता है: इसका आमतौर पर एक मासूम स्पष्टीकरण होता है — टेम्पलेट का पुनः उपयोग, लैपटॉप की घड़ी, अपलोड पर फ़ाइल को फिर से लिखने वाला ऑप्टिमाइज़र — और यह तौले जाने योग्य साक्ष्य है, अपने आप में कभी निर्णय नहीं। मेटाडेटा फ़ील्ड मुफ़्त टूल वाले कोई भी व्यक्ति संपादित कर सकता है, इसलिए वे किसी कहानी का समर्थन या विरोध कर सकते हैं; वे उसे साबित नहीं कर सकते।
इसलिए सफ़ाई एक कार्यप्रवाह है, कोई बटन नहीं। पहला, निरीक्षण करें: फ़ाइल को डॉक्यूमेंट फ़ोरेंसिक टूल से गुज़ारें और नोट करें कि वह किसी अजनबी को क्या बताएगी — लेखक और टूल नाम, संशोधनों की संख्या, एम्बेडेड फ़ाइलें, छिपा टेक्स्ट, एक-दूसरे से बहस करते टाइमस्टैम्प। दूसरा, जहाँ संभव हो स्रोत पर ठीक करें: उसके आउटपुट पर पैबंद लगाने के बजाय लेखन एप्लिकेशन में दस्तावेज़ गुणों को ठीक करें। तीसरा, एक ताज़ा, पूर्ण पुनर्लेखन निर्यात करें — PDF में प्रिंट करना, एक समर्पित क्लीनर, या छवियों के लिए ExifTool — क्योंकि पूर्ण पुनर्लेखन पुराने संशोधनों, अनाथ वस्तुओं और अतिरिक्त डेटा को उस तरह त्यागता है जो वृद्धिशील सहेजना कभी नहीं करेगा। अंत में, उस प्रति की फिर से जाँच करें जिसे आप वास्तव में भेजते हैं, उसकी नहीं जिसे आप भेजना चाहते थे। और वह भेद बनाए रखें जिस पर पूरा लेख टिका है: आंतरिक मूलों को अपना मेटाडेटा बनाए रखना चाहिए, क्योंकि उद्गम, अभिलेख मूल्य और यहाँ तक कि एक्सेसिबिलिटी — दस्तावेज़ शीर्षक भी मेटाडेटा है — इस पर निर्भर करती है। प्रकाशित प्रति को साफ़ करें और रिकॉर्ड को घर पर अक्षुण्ण रखें।