Fidonet साइट पर Node.js: हम एक जावास्क्रिप्ट के साथ JAM प्रारूप में संग्रहीत एकोमाइल के हेडर पढ़ते हैं

आज मेरे पास चाबियों पर जाने के दो कारण हैं।

सबसे पहले, मैंने पिछले हफ्ते jParser प्रलेखन का अनुवाद करने के बाद ( BMP फ़ाइलों का विश्लेषण करने के लिए jParser का उपयोग करने के RReverser उदाहरण को पढ़ने के बाद), यह अगले चरण पर जाने के लिए उचित लगता है: एक विषय विकसित करना, पाठकों के लिए अपना खुद का उदाहरण साझा करना थोड़ा और अधिक जटिल डेटा संरचना का विश्लेषण करने के लिए jParser का उपयोग करना। (आंशिक रूप से, यह उस प्रश्न का उत्तर देगा जो alekciy ने पूछा था, jParser के व्यावहारिक उपयोग के आगे के उदाहरणों में रुचि रखता है।)

दूसरे, ≈ छह महीने पहले ( 26 नवंबर, 2011 ) ertaquo ने पूछा कि मैं फिडोनेट में Node.js का उपयोग क्यों करना चाहूंगा। फिर मैंने कहा कि मुझे सिर्फ नाम पसंद है (मुझे याद है कि जब "नोड" या "नोड" शब्द, अगर बिना स्पष्टीकरण के उपयोग किया जाता है , तो रूसी कंप्यूटर की दुनिया में डिफ़ॉल्ट रूप से फिडोनेट नोड का मतलब है), लेकिन मैं काम करने वाले कोड का कोई स्पष्ट उदाहरण नहीं दे सका। अब मैं इसे लाऊंगा

तो उदाहरण डबल होगा। मैं आपके ध्यान में JAM प्रारूप में संग्रहीत Fidonet के ई-मेल संदेशों के शीर्षकों का विश्लेषण लाता हूं। दूर और अनादिकाल से यह प्रारूप फ़िदेनेट में लोकप्रिय रहा है ( विकिपीडिया का कहना है कि JAM की उपस्थिति 1993 तक है)। मुझे तुरंत यह कहना होगा कि मैंने लंबे समय से JAM को एक अन्य लोकप्रिय प्रारूप ( स्क्विश ) के लिए पसंद किया है, क्योंकि यह पिछले एक के बाद एक संदेश भेजने वालों के नौ से अधिक प्रतिक्रियाओं की पहचान करता है, जबकि JAM एक सीमित लंबाई वाले सरणी ( लिंक की गई सूची ) के बजाय अधिक लचीली डेटा संरचना का उपयोग करता है, इसलिए जो आपको सबसे जीवंत और कांटे की चर्चाओं में भी एक पूर्ण उत्तर पेड़ बनाने की अनुमति देता है।

JAM दस्तावेज़ीकरण विभिन्न BBS फ़िडोस पर आसानी से पाया जा सकता है, लेकिन BBS समय के साथ पते बंद करने या बदलने के लिए जाता है, इसलिए विश्वसनीयता के लिए मैं अपने स्वयं के पत्र को पांच साल पहले संदर्भित करूंगा, जिसमें मैंने इस दस्तावेज़ को शब्दशः और पूर्ण रूप से उद्धृत किया है। (चेक बीबीएस, जो तब मेरे स्रोत के रूप में कार्य करता था, अब पहले से ही बंद है। इस दुनिया में सब कुछ उग्र है।)

जैसा कि आप देख सकते हैं, Fidonet के ई- मेल संदेशों के हेडर JHR फ़ाइल के अंदर संग्रहीत हैं । इस फ़ाइल में एक निश्चित लंबाई के हेडर ( फिक्स्डहेडइन्फो स्टे्रस्ट ) होते हैं, इसके बाद वास्तविक संदेश हेडर ( मैसेजहेडर ) होता है, जिनमें से प्रत्येक में फिर से एक निश्चित आकार की संरचना ( मेसेजफीडहेडर ) और एक चर पूंछ होती है जिसमें कई क्षेत्र ( सबफिल्डएक्सएक्स ) शामिल होते हैं, कुल लंबाई। जो MessageFixedHeader संरचना के अंदर SubfieldLen फ़ील्ड में सेट किया गया है । SubFieldXX फ़ील्ड में फिर से एक निश्चित आकार के हेडर होते हैं, इसके बाद बाइट्स की एक स्ट्रिंग होती है, जिसकी लंबाई पिछले डेटलेन नंबर में दी गई है । (यह एक ही नब्बे के दशक में पास्कल बोलियों में स्ट्रिंग्स के कार्यान्वयन की याद दिलाता है - टर्बो-पास्कल, यूसीएसडी पास्कल; हालांकि, पास्कल में, लंबाई एक बाइट द्वारा निर्दिष्ट की गई थी, और जेएएम में डेटलेन की संख्या प्रकार के निचले हिस्से की है , अर्थात् , यह बत्तीस-बिट है।) )

एक अन्य महत्वपूर्ण परिस्थिति बहुत कम दिखाई देती है: जेएचआर फ़ाइल के अंदर, मैसेजहेड हेडर आवश्यक रूप से एंड-टू-एंड का पालन नहीं करते हैं। उप-संदेश "अपडेटिंग हेडर" इंगित करता है कि यदि पत्र को संपादित करने या संसाधित करने के बाद, इसका हेडर वॉल्यूम में बढ़ता है, तो इसे फ़ाइल के अंत में रखा जाता है, और पिछले हेडर को हटाए जाने के रूप में चिह्नित किया जाता है। उन अक्षरों के भाग्य के बारे में कुछ नहीं कहा जाता है, जिनकी हेडिंग वॉल्यूम में नहीं बढ़ी है, लेकिन घट गई है, हालांकि, व्यवहार में, कई फ़िडोनेट प्रोग्राम पिछले एक के स्थान पर इस तरह के एक नए हेडिंग को लिखते हैं, जिससे सबफ़ील्ड वैल्यू को बदल दिया जाता है (और, यदि आवश्यक हो, तो इंडिविजुअल वैल्यूज़ )। इस और उसके बाद के MessageHeader के बीच , पिछले पिछले SubFieldXX क्षेत्रों की सामग्री से युक्त कचरा है । यही कारण है कि अगले MessageHeader हेडर को पढ़ने के बाद, अगले MessageHeader हेडर पर जाने के लिए और अधिक उचित तरीका नहीं है , सिवाय इसके कि तीन "JAM" ASCII वर्णों की एक स्ट्रिंग को खोजने के लिए एक अशक्त बाइट के बाद - यह वह सिग्नल अनुक्रम है जिसके साथ MessageFixedHeader हेडर शुरू होना चाहिए ।

Node.js के लिए मॉड्यूल कोड, जो JHR फ़ाइल से RAM में इको-मेल हेडर पढ़ता है, इसलिए निम्नानुसार उल्लिखित किया जा सकता है:

var fs = require('fs'); var jParser = require('jParser'); var ulong = 'uint32'; var ushort = 'uint16'; var JAM = function(echotag){ if (!(this instanceof JAM)) return new JAM(echotag); this.echotag = echotag; // Buffers: this.JHR = null; /* this.JDT = null; this.JDX = null; this.JLR = null; */ } JAM.prototype.readJHR = function(callback){ // (err) if (this.JHR !== null) callback(null); fs.readFile(this.echotag+'.JHR', function (err, data) { if (err) callback(err); this.JHR = data; callback(null); }); } JAM.prototype.ReadHeaders = function(callback){ // err, struct this.readJHR(function(err){ if (err) callback(err); var thisJAM = this; var parser = new jParser(this.JHR, { 'reserved1000uchar': function(){ this.skip(1000); return true; }, 'JAM0' : ['string', 4], 'FixedHeaderInfoStruct': { 'Signature': 'JAM0', 'datecreated': ulong, 'modcounter': ulong, 'activemsgs': ulong, 'passwordcrc': ulong, 'basemsgnum': ulong, 'RESERVED': 'reserved1000uchar', }, 'SubField': { 'LoID': ushort, 'HiID': ushort, 'datlen': ulong, 'Buffer': ['string', function(){ return this.current.datlen }] /* 'type': function(){ switch( this.current.LoID ){ case 0: return 'OADDRESS'; break; case 1: return 'DADDRESS'; break; case 2: return 'SENDERNAME'; break; case 3: return 'RECEIVERNAME'; break; case 4: return 'MSGID'; break; case 5: return 'REPLYID'; break; case 6: return 'SUBJECT'; break; case 7: return 'PID'; break; case 8: return 'TRACE'; break; case 9: return 'ENCLOSEDFILE'; break; case 10: return 'ENCLOSEDFILEWALIAS'; break; case 11: return 'ENCLOSEDFREQ'; break; case 12: return 'ENCLOSEDFILEWCARD'; break; case 13: return 'ENCLOSEDINDIRECTFILE'; break; case 1000: return 'EMBINDAT'; break; case 2000: return 'FTSKLUDGE'; break; case 2001: return 'SEENBY2D'; break; case 2002: return 'PATH2D'; break; case 2003: return 'FLAGS'; break; case 2004: return 'TZUTCINFO'; break; default: return 'UNKNOWN'; break; } } */ }, 'MessageHeader': { 'Signature': 'JAM0', 'Revision': ushort, 'ReservedWord': ushort, 'SubfieldLen': ulong, 'TimesRead': ulong, 'MSGIDcrc': ulong, 'REPLYcrc': ulong, 'ReplyTo': ulong, 'Reply1st': ulong, 'Replynext': ulong, 'DateWritten': ulong, 'DateReceived': ulong, 'DateProcessed': ulong, 'MessageNumber': ulong, 'Attribute': ulong, 'Attribute2': ulong, 'Offset': ulong, 'TxtLen': ulong, 'PasswordCRC': ulong, 'Cost': ulong, 'Subfields': ['string', function(){ return this.current.SubfieldLen; } ], /* 'Subfields': function(){ var final = this.tell() + this.current.SubfieldLen; var sfArray = []; while (this.tell() < final) { sfArray.push( this.parse('SubField') ); } return sfArray; }, */ 'AfterSubfields': function(){ var initial = this.tell(); var bytesLeft = thisJAM.JHR.length - initial - 4; var seekJump = 0; var sigFound = false; var raw = this; if (bytesLeft <= 0) return 0; do { this.seek(initial + seekJump, function(){ var moveSIG = raw.parse('JAM0'); if (moveSIG === 'JAM\0') { sigFound = true; /* if (seekJump > 0){ console.log( 'initial = ' + initial + ', seekJump = ' + seekJump + ', moveSIG = ' + moveSIG ); } */ } }); seekJump++; } while (!sigFound && (seekJump < bytesLeft) ); this.skip(seekJump-1); return seekJump-1; } }, 'JHR': { 'FixedHeader': 'FixedHeaderInfoStruct', 'MessageHeaders': function(){ var mhArray = []; while (this.tell() < thisJAM.JHR.length - 69) { mhArray.push( this.parse('MessageHeader') ); } return mhArray; } } }); callback(null, parser.parse('JHR')); }); } module.exports = JAM; 

यह स्केच एक्सपोर्टेड JAM ऑब्जेक्ट ( JHR फ़ील्ड में ) के अंदर JHR फ़ाइल से कच्चे डेटा के कैशिंग का उपयोग करता है - एक ऐसा समाधान जो वर्तमान मॉड्यूल डिज़ाइन के दृष्टिकोण से अनौपचारिक रूप से उपयोग होता है, लेकिन यह उपयोगी है, रीडहेडर्स विधि के साथ, आपको एक सरल विधि की आवश्यकता होती है जो उदाहरण के लिए पढ़ेगी । केवल FixedHeaderInfoStruct हेडर। JAM प्रारूप (JDT, और JDX, और JLR) के लिए अन्य तीन फ़ाइलों के लिए फ़ील्ड भी प्रदान किए जाते हैं, लेकिन टिप्पणी की जाती है। (आदर्श रूप से, किसी को कैश की प्रासंगिकता पर नज़र रखनी चाहिए - स्टेट करें () , या नहीं वॉच फ़ाइल () बिल्कुल - लेकिन यह स्पष्ट है कि यह कोड उसके बिना मॉड्यूल के प्रारंभिक मसौदे के लिए काम करेगा।)

JAM प्रलेखन से डेटा प्रकार (उदाहरण के लिए, ulong ) jParser (उदाहरण के लिए, " 'ulong': 'uint32' ") द्वारा निर्धारित नहीं किए गए थे , लेकिन जावास्क्रिप्ट चर के रूप में घोषित किए गए (उदाहरण के लिए, " var ulong = 'uv32' "), जिनमें से मान का उपयोग किया जाता है। डेटा संरचनाओं का विवरण। यह गति के लिए है: यह स्पष्ट है कि V8 जावास्क्रिप्ट इंजन का कोड jParser मॉड्यूल के कोड की तुलना में बहुत तेजी से काम करेगा।

SubField संरचना के वर्णन में , आप एक टिप्पणी प्रकार फ़ील्ड पाएंगे - यह एक जावास्क्रिप्ट फ़ंक्शन के साथ आबाद है जिसमें जेएएन प्रलेखन से उधार ली गई मेनेमोनिक फ़ील्ड पदनाम शामिल हैं। इसका उपयोग डीबगिंग उद्देश्यों के लिए किया जा सकता है।

MessageHeader संरचना के अंदर उपक्षेत्र फ़ील्ड को दो तरीकों से परिभाषित किया गया है। पहला (तेज) इस क्षेत्र को सबफील्डलेन आकार के बाइट्स की एक स्ट्रिंग के रूप में पढ़ता है। दूसरा (टिप्पणी की गई) इस क्षेत्र को पूरी तरह से संसाधित करता है, jParser का उपयोग करते हुए उप-क्षेत्रों को अलग करता है - यदि मॉड्यूल का उपयोग करने वाला एप्लिकेशन, किसी भी स्थिति में, फ़ीड के हेडर के चर भाग से मेटाडेटा की आवश्यकता है, तो एक लंबे बॉक्स में उनके विश्लेषण को स्थगित क्यों करें।

AfterSubfields में तीन ASCII- वर्ण "JAM" की एक सरल खोज होती है, जिसके बाद एक शून्य बाइट होता है - इसका कारण पिछले पैराग्राफ में से एक में वर्णित है। कंसोल कॉल के लिए एक टिप्पणी के बाहर। () डिबगिंग अर्थ है, और नहीं। (आंतरिक चर चालन का नाम मेम को " आपके सभी आधार हमसे जुड़े हुए हैं " मेम के लिए एक भ्रम है ।)

JHR संरचना में MessageHeaders फ़ील्ड के विवरण में 69 नंबर "जादू" है; इसका लक्ष्य यह है कि विश्लेषण फ़ाइल के अंत के बहुत करीब नहीं पहुंचता है, जहां कचरा डेटा की भी उम्मीद की जा सकती है।

मैंने इस परीक्षण स्क्रिप्ट का उपयोग करके विश्लेषण की गति की जाँच की:

 var JAM = require('../'); var util = require('util'); console.log( new Date().toLocaleString() ); var blog = JAM('blog-MtW'); blog.ReadHeaders(function(err,data){ if (err) throw err; //console.log( util.inspect(data, false, Infinity, false) ); console.log( new Date().toLocaleString() ); }); 

स्क्रिप्ट परीक्षण उपनिर्देशिका में निहित है, इसलिए, पहली पंक्ति में यह मूल निर्देशिका के संदर्भ का उपयोग करता है, जहां मुख्य मॉड्यूल का पाठ index.js फ़ाइल में निहित है ; चूंकि यह नाम Node.js में डिफ़ॉल्ट रूप से निहित है , इसलिए यह केवल मूल निर्देशिका को निर्दिष्ट करने के लिए पर्याप्त है।

Blog-MtW.jhr फ़ाइल में परीक्षण डेटा में मेरे फ़िडोनेट ब्लॉग ब्लॉग इको ( Ru.Blog.Mithgol ) के लिए ब्लॉग प्रविष्टियाँ हैं जो मार्च 2007 से जमा हुई हैं।

एकल-कोर पेंटियम IV (2.2 गीगाहर्ट्ज) पर एक परीक्षण चलाने से पता चलता है कि हेडर तीन से चार सेकंड में संसाधित होते हैं। यदि सबफील्ड्स ऐरे की सरल रीडिंग को उसके विश्लेषण से बदल दिया जाता है (जो अब टिप्पणी की गई है), तो यह समय अभी भी दोगुना है।

यह एक प्रतिध्वनि सम्मेलन के लिए बहुत कुछ है, क्योंकि फिडोनेट साइट पर इस तरह के सौ से अधिक गूंज सम्मेलन हो सकते हैं, और ई-मेल हेडर का विश्लेषण करने के लिए कुल समय कई मिनट हो जाएगा।

लेकिन फिडोटनिक को शायद यह याद दिलाने की आवश्यकता नहीं है कि लोकप्रिय गोल्डेड मेल एडिटर गोल्डेड (गोल्डेड +, गोल्डेड-एनएसएफ) इको सम्मेलनों (अपने काम की शुरुआत में) को बहुत तेजी से स्कैन करता है, और उनके नाम अपनी छप स्क्रीन पर स्टेटस बार में इतनी तेज़ी से चमकते हैं कि यह देखना आसान है एक सेकंड के अंश प्रत्येक खर्च किए जाते हैं, और नहीं। एक को अनैच्छिक रूप से एक अप्रिय निष्कर्ष पर आना पड़ता है: बाइनरी डेटा का जावास्क्रिप्ट विश्लेषण, यहां तक ​​कि तेज वी 8 इंजन पर, परिमाण के धीमे क्रम का काम करता है - और परिमाण के सिर्फ एक क्रम से भी धीमा नहीं।

यह संदेह करने के लिए केवल निंदनीय है कि काम की शुरुआत में गोल्डेड ने गति के लिए पूरी फाइल नहीं पढ़ी है, लेकिन केवल एक हेडर संरचना FixedHeaderInfoStruct (इससे प्राप्त डेटा इको सम्मेलनों में संदेशों की संख्या प्रदर्शित करने के लिए पर्याप्त होगा, और अधिक गोल्डेड काम की शुरुआत में कुछ भी नहीं करता है) - सच्चाई , मैं इस संदेह की न तो पुष्टि कर सकता हूं और न ही इनकार कर सकता हूं, क्योंकि मेरे पास सीवीएस गोल्डेड + का पता लगाने का समय नहीं था।

मैंने अपने मॉड्यूल का कोड (JAM हेडर्स का रीडर ) एक मुफ्त एमआईटी लाइसेंस के तहत जीथब पर पोस्ट किया।