मैं यह नहीं छिपाऊंगा कि मुझे इन फाइलों में दिलचस्पी थी, लेकिन विवरण के पहले पृष्ठ से आगे मैं इतना आगे नहीं बढ़ सका। हालांकि, खुला गर्भपात बना रहा।
और अब, जीवन बनाया (या अवसर को फेंक दिया) अभी भी अच्छी तरह से ज्ञात दस्तावेजों के इनसाइट्स को समझते हैं, खासकर जब से स्टर्लिंगिट खेलना अब आवश्यक नहीं है, बस Microsoft वेबसाइट से आधिकारिक विनिर्देशों को डाउनलोड करें।
मैं क्या कह सकता हूं? अनजाने में मुझे पुराने अश्लील मजाक याद आते हैं: अच्छी तरह से, डरावनी। खैर, यह सिर्फ डरावनी है, लेकिन यह डरावनी-डरावनी नहीं है।
भगवान का शुक्र है कि मैंने पर्ल पर इन फ़ाइलों को पार्स किया, न कि कुछ सी कोड पर। भाषा का एक उच्च स्तर और तैयार पुस्तकालयों का एक गुच्छा (उदाहरण के लिए, विभिन्न कोड पृष्ठों को पढ़ने के लिए) भगवान का एक उपहार है।
तो एक साथ काम में एक सप्ताह लग गया, और सबसे कठिन था आंतरिक प्रारूप को समझना। बेशक, यह समझ पूरी तरह से पूरी नहीं है, क्योंकि मेरा काम दस्तावेज़ से कुछ पाठों को बिना किसी स्वरूपण के निकालना था, लेकिन मैंने इसे ध्यान से किया।
तो, वर्ड फाइल्स कैसे काम करती हैं?
पात्र
शुरू करने के लिए, ये वर्ड फाइलें बिल्कुल नहीं हैं, लेकिन एक तरह का सार्वभौमिक कंटेनर है जिसमें दस्तावेज़ स्वयं पैक किए जाते हैं। सभी कार्यालय फ़ाइलें, और शायद कुछ और, ऐसे कंटेनर में भर जाती हैं।
कंटेनर प्रारूप को अलग तरह से कहा जाता है - डॉकफाइल, ओले स्टोरेज, कम्पाउंड डॉक्यूमेंट फ़ाइल। पहले से ही नामों में विसंगति संकेत देती है कि इसकी वास्तव में आवश्यकता नहीं है, क्योंकि वास्तव में उपयोगी चीज में आमतौर पर एक और स्पष्ट नाम होता है। इसका मुख्य विचार एक फाइल में कई अन्य लोगों को रटना करने में सक्षम होना है। यह सबसे उचित होगा (जैसा कि उन्होंने ओपनऑफिस में किया था) सब कुछ एक ज़िप आर्काइव में पैक करने के लिए (यह संग्रह के बिना संभव है अगर इसकी आवश्यकता नहीं है)। प्रारूप बड़ी संख्या में कार्यक्रमों के लिए जाना जाता है, कॉम्पैक्ट, समझने में आसान। लेकिन माइक्रोसॉफ्ट में, "यहां आविष्कार नहीं किया गया" सिंड्रोम स्पष्ट रूप से पनपता है। मुख्य बात यह है कि एक साइकिल का आविष्कार करना है, भले ही एक तिपहिया साइकिल हो, लेकिन आपका अपना।
सिद्धांत रूप में, OLE संग्रहण प्रारूप काफी उचित है और कुछ पूरी तरह से बेवकूफ का आभास नहीं देता है। लेकिन ... वह पूरी तरह से अनावश्यक है। वास्तव में, यह FAT16 फाइल सिस्टम की तरह कुछ है, एक अलग फाइल के अंदर अटका हुआ है। यह गौरैया पर गोलाबारी की तरह नहीं है, बल्कि परमाणु टारपीडो द्वारा इन समान गौरैया को भगाना है। अंदर कई फाइलों के साथ एक दस्तावेज को डॉस के समय कम से कम एफएस स्तर पर स्थित एक फ़ाइल सिस्टम की आवश्यकता नहीं होती है।
तो, सीडीएफ फाइलें (यूनिक्स उपयोगिता फ़ाइल उन्हें कॉल करती है) एक हेडर के साथ शुरू होती है। शीर्ष लेख में पहले सौ टीआरएफ रिकॉर्ड (फाइल आवंटन तालिकाओं, बोलचाल - एफएटी) के लिए एक जगह है। वसा वहाँ सबसे प्राकृतिक है, जो डॉसोवस्की फ्लॉपी डिस्क पर पाया जा सकता है। शेष टीआरएफ रिकॉर्ड एक लिंक की गई सूची से जुड़े अलग-अलग क्षेत्रों में हैं। अतिरिक्त सेक्टर केवल बड़ी (> 7mb) फ़ाइलों में होते हैं।
एफएटी / टीआरएफ प्लेट का उपयोग करके, आप किसी भी आंतरिक फ़ाइल की सामग्री को इकट्ठा कर सकते हैं (एमएस शब्दावली में इसे एक धारा कहा जाता है, लेकिन यह केवल मामले को भ्रमित करता है) यदि आप जानते हैं कि यह किस ब्लॉक से शुरू होता है। विभिन्न संरचनाओं के प्रारंभिक ब्लॉक, निश्चित रूप से, शीर्षक में लिखे गए हैं। तालिका से आगे, आप उन क्षेत्रों की पूरी श्रृंखला का विस्तार कर सकते हैं जिनमें इस छद्म फ़ाइल की सामग्री दर्ज की गई है।
विशेष रूप से, सीडीएफ में रूट डायरेक्टरी भौतिक रूप से सेक्टरों के ढेर पर फैली हुई है। यह एक वास्तविक कैटलॉग है, फिर से, पुराने डॉसोवस्की की बहुत याद दिलाता है। सच है, दक्षता के लिए (या दिखावा करने के लिए) यह न केवल एक रेखीय सूची है, बल्कि एक संतुलित बाइनरी ट्री है। इसका मतलब यह है कि खोज दक्षता के नुकसान के बिना व्यक्तिगत रिकॉर्ड के दसियों इसे लिखा जा सकता है। एक फ़ाइल में इसकी आवश्यकता क्यों है, जिसमें आमतौर पर पांच टुकड़े होते हैं, कभी-कभी बीस, अच्छी तरह से, अधिकतम एक सौ टुकड़े (बड़ी संख्या में चित्रों के साथ एक प्रस्तुति) - वे केवल रेडमंड में जानते हैं। वैसे, निर्देशिका में फ़ाइल नाम UTF16 में संग्रहीत हैं - बस मामले में।
निर्देशिका से, आप किसी भी फ़ाइल के प्रारंभिक क्षेत्र को निर्धारित कर सकते हैं और इसकी संपूर्ण प्लेसमेंट श्रृंखला को बाहर निकालने के लिए TRF का उपयोग कर सकते हैं।
लेकिन यह सब नहीं है।
चूंकि ब्लॉक आकार बड़ा है (आमतौर पर 512 बाइट्स के अनुसार, विनिर्देश 4096 के अनुसार भी संभव है), छोटे छद्म फाइलों को संग्रहीत करते समय, सैद्धांतिक रूप से, आप बहुत सारे खाली स्थान खो सकते हैं। इसलिए, 64 बाइट्स के ब्लॉक में विभाजित एक अलग स्टोरेज है। भंडारण फिर से FAT श्रृंखला के साथ बढ़ाया जाता है।
यह इंगित करने के लिए कि कौन सी ब्लॉक किस फ़ाइल से संबंधित है, एक अलग प्लेट एफएटी है या, बल्कि मिनीफैट।
तो, वर्ड डॉक्यूमेंट प्राप्त करने के लिए, आपको निम्नलिखित कार्य करने होंगे:
1. सीडीएफ शीर्षक पढ़ें
2. FAT लोड करें - स्मृति आबंटन तालिका को सेक्टरों की एक श्रृंखला के साथ संग्रह करके लोड करें।
3. TRF श्रृंखला के साथ इकट्ठा करके MiniFAT प्लेट डाउनलोड करें
4. टीआरएफ श्रृंखला के माध्यम से इसे इकट्ठा करते हुए, ब्लॉक स्टोरेज को डाउनलोड करें
5. रूट डायरेक्टरी को डाउनलोड करें, इसे टीआरएफ चेन के माध्यम से इकट्ठा करें
6. निर्देशिका को अलग करें और इसे किसी पठनीय में परिवर्तित करें
7. निर्देशिका में एक वर्डडिमेंटमेंट प्रविष्टि खोजें
8. यदि यह एक छोटी फ़ाइल है, तो इसे ब्लॉक स्टोरेज से मिनीआरटीएफ का उपयोग करके इकट्ठा करें।
9. यदि बड़ा है, तो टीआरएफ श्रृंखला के साथ डिस्क से सेक्टर खींचें।
काहे, यह बात है।
अपने आप में प्रत्येक चरण विशेष रूप से जटिल नहीं है, लेकिन कुल में वे केवल घबराहट का कारण बनते हैं। ऐसी मुश्किलें क्यों? हेडर के बाद एक साधारण रैखिक निर्देशिका को रखना असंभव क्यों था, और इसके बाद यह लगातार एक के बाद एक आंतरिक फाइलें लिखता है?
केवल एक चीज जो यह माना जा सकता है कि यह सब इसलिए किया गया था ताकि मुख्य फ़ाइल की शुरुआत को छूने के बिना सबफ़ाइल्स को जोड़ना संभव हो सके। यह ध्यान दिया जाना चाहिए कि, सबसे पहले, यह एक बहुत जरूरी ऑपरेशन नहीं है, क्योंकि सभी प्रोग्राम आमतौर पर एक पास में शुरुआत से अंत तक दस्तावेजों को रिकॉर्ड करते हैं। अपवाद केवल एमएस वर्ड है और फिर केवल कुख्यात त्वरित सहेजें मोड में, उपयोगकर्ताओं द्वारा शापित। और दूसरी बात, इन शर्तों के तहत, आप अभी भी मुख्य फ़ाइल की शुरुआत को छूने में विफल नहीं हो सकते, क्योंकि आपको निर्देशिकाओं, टीआरएफ और हेडर को अपडेट करने की आवश्यकता है।
सामान्य तौर पर, माइक्रोसॉफ्ट अपनी भूमिका में। यह बस क्यों है, अगर यह मुश्किल और भ्रामक है?
WordDocument
सीडीएफ प्रारूप, इसकी सभी राक्षसी के लिए, कम से कम तार्किक है और बहुत जटिल नहीं है (जब Word दस्तावेज़ की बाकी सामग्री के साथ तुलना की जाती है)। इसका वर्णन वर्ड फॉर्मेट के 300 पेजों की तुलना में केवल कुछ बीस पृष्ठ - pah लेता है।
एक दस्तावेज़ के प्रारूप को शायद ही एक प्रारूप कहा जा सकता है, एक पत्थर के रिकॉर्ड की परिभाषा इसके लिए अधिक उपयुक्त है। ऐसे चट्टानी चट्टान की कल्पना करें, जिसने ग्रह के इतिहास के पचास मिलियन वर्ष अंकित किए। यहाँ मेसोज़ोइक परत है, यहाँ सेनोज़ोइक है, यहाँ पेटरोडैक्टाइल विंग की छाप है, और शीर्ष पर तृतीयक जमा हैं। दस्तावेज़ भी अंदर से लगभग एक जैसा दिखता है।
बस हेडर को देखें, जो लगभग एक तिहाई फ़ाइल लेता है। तीन सुर्खियां हैं। सबसे पहले एक छोटा सा आता है, जिसमें आधे रिकॉर्ड "आरक्षित" या "उपयोग नहीं किए गए" छेद के साथ अंतर कर रहे हैं। इससे पहले, मेसोज़ोइक में, वहाँ स्पष्ट रूप से कुछ पड़ा हुआ था, लेकिन फिर इसे इतिहास के कूड़ेदान में फेंक दिया गया था। रिकॉर्डिंग प्रोग्राम का एक संस्करण भी है, जिसके अनुसार कोड में एक बड़ा स्विच / केस निष्पादित होता है।
फिर सोलह-बिट शब्दों से मिलकर दूसरा शीर्षक आता है। इसमें कुछ भी उपयोगी नहीं है। इसकी शुरुआत में, आकार को इस तरह से स्पष्ट रूप से लिखा गया है कि भविष्य में प्रोटोजोअन गोले यहां जमा किए जाएंगे।
इसके बाद तीसरा शीर्षक आता है, इस बार आधुनिक, लंबे शब्दों (32 बिट्स) से। यह बहुत अधिक लंबाई का है, शुरुआत में यह एक और विस्तार के लिए एक आंख के साथ रिकॉर्ड की संख्या को भी इंगित करता है, और मूल रूप से यह सूची है जहां फ़ाइल के विभिन्न तालिकाओं और टुकड़ों की तलाश करना है - प्रारंभ / आकार जोड़े। वैसे, टेबल स्वयं, यहाँ नहीं हैं, लेकिन एक अलग CDF छद्म फ़ाइल में जिसे 0Table या 1Table कहा जाता है (विकल्प संभव हैं)।
पहला शीर्षक पाठ की लंबाई और इसकी शुरुआत के बारे में बताता है। जाहिर है, राजा मटर के समय में, वह ठीक उसी तरह था जैसे उसे पढ़ा जा सकता है। पाठ एक बड़े टुकड़े में रखा गया है। यह मज़ेदार है कि आप इसे अभी पढ़ सकते हैं, लेकिन ... हमेशा नहीं! दस पठनीय फ़ाइलों के लिए, बीच में आधे अस्पष्ट चंक्स के साथ एक है, अंत में फुटनोट्स हैं जो कि नहीं होना चाहिए, और पाठ का एक बड़ा हिस्सा जो पिछले साल बहुत शुरुआत में मिटा दिया गया था। इसके अलावा, फ़ाइल का आधा हिस्सा चीनी अक्षरों में लिखा जाएगा। यह नोट करना खेदजनक है कि कुछ मामलों में विटस वैगनर की जानी-मानी कैटडॉक उपयोगिता केवल ऐसे परिणाम देती है, जिससे यह निष्कर्ष निकाला जा सकता है कि यह प्रारूप को सही ढंग से पार्स नहीं करता है।
जीवन वास्तव में बहुत अधिक जटिल है। एक बार फ़ाइलों में वास्तव में केवल पाठ था, लेकिन समय के साथ, उपयोगकर्ताओं और विपणन के दबाव में विभिन्न "विशेषताएं" जमा हुईं। उनके अंतर्गत अलग-अलग धाराएँ ली गई थीं - साधारण फुटनोट के लिए, अंतिम पाद के लिए, हेडर और फुटर के लिए, किसी प्रकार के टेक्स्टबॉक्स के लिए (वह विकृति - यह पाठ जैसा दिखता है, लेकिन पाठ नहीं। उद्देश्य स्पष्ट नहीं है)।
इन धाराओं की शुरुआत हेडर में विशेष स्थानों में इंगित की जाती है, लेकिन किसी कारण के लिए बहुत पहले हेडर कुल लंबाई दिखाता है - पाठ ही नहीं, बल्कि पाठ और इन सभी विकृति। यह पहला कारण है कि कई उपयोगिताओं के आउटपुट में पेज 1 जैसे शिलालेख शामिल हैं।
पुरालेख में कहीं, संपादक में एक त्वरित बचत जोड़ी गई थी। इसका अर्थ यह है कि पूरी फाइल को अधिलेखित नहीं किया गया है, और इसके अंत में परिवर्धन और परिवर्तन बस जोड़ा जाता है, जो सैद्धांतिक रूप से तेज होना चाहिए। यह उपयोगकर्ताओं को खुश करने वाला था, लेकिन वास्तव में वे संतुष्ट नहीं थे। लिखने की गति में कोई विशेष अंतर नहीं है, लेकिन फ़ाइल में बहुत अधिक कचरा उत्पन्न होता है, और उन टुकड़ों से जो पहले से ही सैद्धांतिक रूप से मिट चुके हैं। यदि कोई गुप्त सूचना थी, तो बस डंप फ़ाइल को देखकर आसानी से पता लगा सकते हैं।
त्वरित बचत का समर्थन करने के लिए, एक विशेष टुकड़ा तालिका बनाई गई थी, जिसमें प्रत्येक टुकड़े की शुरुआत और फ़ाइल में उसका पता लिखा जाता है। कोई लंबाई नहीं है, लेकिन इसकी गणना वर्तमान टुकड़े की शुरुआत को अगले की शुरुआत से घटाकर की जा सकती है। हालांकि, यहां भी सावधान रहना चाहिए, क्योंकि बिट्स सभी थ्रेड्स से सूचीबद्ध हैं। भगवान का शुक्र है कि वे एक निश्चित क्रम में जाते हैं, इसलिए, पाठ की कुल लंबाई को जानते हुए, समय में रोकना आसान है।
सैद्धांतिक रूप से, इस जटिल प्रारूप का उपयोग केवल तभी किया जाता है जब शीर्ष में विशेष ध्वज fComplex सेट किया गया हो। लेकिन ... यहाँ पर यह "लेकिन" है, कई कन्वर्टर्स भी छेड़े गए हैं।
पहले से ही हमारे समय में, यूनिकोड में रिकॉर्ड करने की क्षमता को दस्तावेजों में जोड़ा गया है। उसी समय, एक समस्या उत्पन्न हुई (जहाँ तक मुझे लगता है, बहुत दूर की बात है): लेकिन फाइलें ठीक दो गुना अधिक समय तक प्राप्त की जाती हैं। चूंकि सॉफ़्टवेयर अमेरिकियों द्वारा विकसित किया गया है जो अपने दिल में अन्य वर्णमालाओं के अस्तित्व में विश्वास नहीं करते हैं, और गुप्त रूप से मानते हैं कि सभी प्रकार के अजीब अक्षर केवल प्राचीन ग्रीस के बारे में शोध प्रबंधों में पाए जाते हैं, और वे केवल कभी-कभी वहां पाए जाते हैं, पहली बात उनके दिमाग में शुद्ध वर्णों को अलग करना था गंदे यूनिकोड से ए.एस.सी.आई.आई. पहला प्रति चरित्र बाइट द्वारा लिखने के लिए, दूसरा - यह कैसे जाता है।
इस विचार से, उदाहरण के लिए, सुरुचिपूर्ण एन्कोडिंग UTF-8, जहां डबल-बाइट वर्ण हफ़मैन कोडिंग की भावना में चालाक दृश्यों द्वारा एन्कोड किए गए हैं। Microsoft ने ऐसा ही किया, लेकिन इतनी खूबसूरती से नहीं। चूंकि हमारे पास स्टब्स की एक तालिका है, हम एक ही समय में वहां लिखेंगे और कौन से पाठ के टुकड़े शुद्ध ASCII (वास्तव में p1252) में लिखे गए हैं, और कौन से सभी प्रकार के अस्पष्ट वर्णमालाओं में जिन्हें यूनिकोड की आवश्यकता है और, तदनुसार, प्रति वर्ण दो बाइट्स। इसलिए, वर्तमान फ़ाइलों को हमेशा एक टुकड़ा तालिका का उपयोग करके अलग किया जाना चाहिए, चाहे वहां सभी प्रकार के झंडे हों। यूनिकोड के टुकड़े वहां ले जाए जाते हैं, केवल आपको इस बात पर विचार करने की आवश्यकता है कि पढ़ने के लिए बाइट्स की संख्या को पढ़ने के लिए वर्णों की संख्या से दो गुना होना चाहिए। एकल-बाइट के टुकड़े दूसरे बाएं (क्यों पहले नहीं) पर उच्च-क्रम बिट के साथ पते में चिह्नित हैं। वास्तविक पते का पता लगाने के लिए, आपको इस बिट को रीसेट करना होगा, और पते को दो (!) में विभाजित करना होगा।
अगर हम इस बात को ध्यान में रखते हैं कि यह स्टब टेबल खुद भी जगह लेती है, और सीडीएफ प्रारूप से अलग-अलग बाइनरी ट्री और सेक्टर चेन लेबल फाइल में और भी अधिक जगह लेते हैं, तो यूनिकोड के पात्रों पर पाठ की बचत के आकार प्राचीन यूनानी शोध प्रबंधों में भी कल्पना को विस्मित नहीं करेंगे। शानदार और शक्तिशाली भाषा में फाइलों के बारे में कुछ नहीं कहना है। वे सब कुछ यूटीएफ -16 में डाल देते हैं और पीड़ित नहीं होते हैं। ठीक है, वे धारा को संग्रहित करेंगे, क्योंकि टॉड इसे कुचल रहा है।
पाठ को पढ़ने के वीर प्रयासों के बाद, विचित्र रूप से पर्याप्त, इसमें कुछ भी जटिल नहीं है। प्लेन टेक्स्ट (एन्कोडिंग के लिए सही), अंतरिक्ष के नीचे कुछ कोड एक आधिकारिक भूमिका निभाते हैं। उदाहरण के लिए, 0x9 को दर्शाता है, जैसा कि अपेक्षित है, एक टैब, 0xA - पृष्ठ का अंत, 0x7 - तालिका सेल का अंत, आदि। खेतों से जुड़ी एकमात्र सूक्ष्मता। फ़ील्ड की सामग्री की शुरुआत को 0x13 के रूप में नामित किया गया है, फ़ील्ड का अंत 0x15 है, फ़ील्ड का नाम और पैरामीटर 0x14 प्रतीक द्वारा अलग किया जाता है, वास्तव में, पाठ में उपयोगकर्ता को दिखाई देता है। लेकिन ... दूसरा भाग अपने आप में एक नेस्टेड फ़ील्ड हो सकता है, जो कई कार्यक्रमों को ध्यान में नहीं रखता है। परिणामस्वरूप, पाठ में INCLUDEPICTURE या PAGEREF * जैसे बिट्स बने हुए हैं।
हालांकि, एक और मामूली गंदी चाल है। कुछ पात्रों का मतलब कुछ अलग हो सकता है, जैसे कि वर्तमान तिथि। यह समझने के लिए कि कोई प्रतीक सरल है या नहीं, आपको प्रतीक संपत्ति तालिकाओं को पार्स करने की आवश्यकता है, जो नीचे वर्णित हैं। मैं स्वीकार करता हूं, मैंने अंतरिक्ष के नीचे दिए गए कोड के साथ सभी पात्रों को काट दिया, जो काफी पर्याप्त नहीं है, लेकिन सस्ता, तेज और व्यावहारिक है।
पाठ का चयन करने के बाद, मैं प्रारूप में आगे नहीं गया। यह पहले से ही युवा और मजबूत इरादों वाले लोगों के लिए एक गतिविधि है - इन सभी तालिकाओं के माध्यम से सीएचपी, पीएपीएक्स, एसएचएसटी, पीएलएफ और सभी समान भावना के साथ। टाइटन्स के लिए पाठ स्वरूपण को फिर से तैयार करना है जैसा कि वर्ड स्वयं करता है।
मैं केवल संक्षेप में बताऊंगा कि सब कुछ विशेष तालिकाओं में संग्रहीत किया जाता है, जो इनपुट स्ट्रीम की शुरुआत से प्रतीक का पता है। शैलियाँ लंबी सूचियों में हैं, शैलियों में परिवर्तन विशेष अपवाद सूचियों में हैं। स्थानीय शैली में परिवर्तन, उदाहरण के लिए, जब एक पैराग्राफ या चरित्र को संपादित करते हैं, तो माता-पिता की शैली की चादर को बदलने के लिए विशेष कमांड के रूप में तालिकाओं में संग्रहीत किया जाता है। टीमें स्वयं एक विशिष्ट खोज गेम से वर्चुअल मशीन कमांड की बहुत याद दिलाती हैं।
यह केवल नैतिकता लाने के लिए बनी हुई है, और यह प्रतिबंधात्मक है: जो एक व्यक्ति के साथ आया था, दूसरा हमेशा के लिए टूट सकता है। विषम प्रणालियों में बड़े पैमाने पर सूचना के आदान-प्रदान के कार्यों के लिए वर्ड प्रारूप कम शर्मनाक, बदसूरत और पूरी तरह से अनुपयुक्त नहीं है।
मुझे लगता है कि Microsoft ने इसे इतने सालों तक नहीं खोला है, इसलिए नहीं कि यह प्रतिस्पर्धा से डरता था, बल्कि सिर्फ इसलिए कि यह ... शर्मनाक था।
आगे पढ़ने:
आधिकारिक प्रारूप विवरण:
http://msdn.microsoft.com/en-us/library/cc313153(office.12).aspx
जे स्पोल्स्की, "कार्यालय प्रारूप इतने जटिल क्यों हैं?"
http://www.joelonsoftware.com/items/2008/02/19.html