今日、私は鍵を検討する2つの理由があります。
まず、先週
jParserのドキュメントを翻訳した後（jParserを
使用してBMPファイルを分析する RReverserの例を読んだ後）、次のステップに進むのが適切だと
思います ：トピックを開発し、読者と自分の例を共有してくださいjParserを使用して、やや複雑なデータ構造を分析します。 （一部、これは
alekciyがjParserの実際の使用のさらなる例に興味を持って尋ね
た 質問に答えます。）
第二に、約6か月前
（ 2011年11月26日 ）
ertaquoが、FidonetでNode.jsを使用したい理由を尋ねました。 それから私は名前が好きだと言いました（明確にせずにロシアのコンピューター世界で「ノード」
または「ノード」という用語が明確に使用されていた場合、デフォルトではフィドネットノードを意味していたことを覚えています）、私は作業コードの明確な例を与えることができませんでした今すぐ持っていきます
したがって、例は二重になります。 JAM形式で保存されたFidonet電子メールメッセージのヘッダーの分析に注目します。 この形式は、遠い昔からフィドネットで人気がありました
（ ウィキペディアによると、JAMの登場は1993年に遡ります）。 私
はすぐに別の一般的な形式
（ Squish ）よりもJAMを好んでい
たことを
言わなければなりません。この最後の1つはメッセージヘッダーに9個以下の応答の識別子を格納するのに対し、JAMは制限された長さの配列（
リンクリスト ）ではなく、より柔軟なデータ構造を使用するためです最も活発で分断されたディスカッションでも、完全な回答ツリーを構築できます。
JAMのドキュメントはさまざまなBBSファイドで簡単に見つけることができますが、BBSは時間の経過とともに住所を閉鎖または変更する傾向があるため、信頼性のために、5年前に自分の
手紙を参照します。 （チェコのBBSは、その後私のソースとして使用されていましたが、すでに閉鎖されています。この世界のすべてが荒れ狂っています。）
ご覧のとおり、Fidonetの
電子メールメッセージのヘッダーは
JHRファイル内に保存されてい
ます。 このファイルは、固定長ヘッダー（
FixedHeaderInfoStruct ）で構成され、その後に実際のメッセージヘッダー（
MessageHeader ）が続きます。各ヘッダーは、再び固定サイズ構造（
MessageFixedHeader ）と、いくつかのフィールド（
SubFieldXX ）これは、
MessageFixedHeader構造内の
SubfieldLenフィールドで設定されます。
SubFieldXXフィールドは、固定サイズのヘッダーと、それに続くバイトの文字列で構成されます。バイトの長さは、前の
datlen numberで指定されています。 （これは、同じ90年代に共通のPascal方言での文字列の実装を思い起こさせます
-Turbo -Pascal、 UCSD Pascal。ただし、Pascalでは、長さは1バイトで示され、JAMでは、
datlenの数は
ulong 型 です 。つまり、32ビットです。これは賢明です。 ）
もう1つの重要な状況はあまり目立ちません
。JHR ファイル内では、
MessageHeaderヘッダーは必ずしもエンドツーエンドに従うとは限りません。 「メッセージヘッダーの更新」サブセクションは、レターを編集または処理した後、ヘッダーのボリュームが大きくなり、ファイルの最後に配置され、前のヘッダーが削除済みとしてマークされることを示します。 見出しが増えていないが減少している文字の運命については
何も言われていないが、実際には、多くのFidonetプログラムは以前の見出しに新しい見出しを書き込み、それに応じて
SubfieldLen値（および必要に応じて個々の
datlen値）を
変更します。 これと後続の
MessageHeaderの間には、直前の最後の
SubFieldXXフィールドの内容で構成されるゴミがあります。 そのため、次の
MessageHeaderヘッダーを読み取った後、次の
MessageHeaderヘッダーに移動する合理的な方法はありません。ただし、3つの「JAM」
ASCII文字の後に
ヌルバイトが続く文字列を見つけることです。これは、
MessageFixedHeaderヘッダーを開始する
署名シーケンスです。
したがって
、JHRファイルからRAMにエコーメールヘッダーを読み取るNode.jsのモジュールコードは、次のように概説できます。
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;
このスケッチは、エクスポートされた
JAMオブジェクト（
JHRフィールド内
）内の
JHRファイルからの生データのキャッシングを使用し
ます -現在のモジュール設計の観点からは不経済なソリューションですが、
ReadHeadersメソッドとともに、たとえば、
FixedHeaderInfoStructヘッダーのみ。 フィールドは、JAM形式（JDT、およびJDX、およびJLR）の他の3つのファイルにも提供されますが、コメント化されています。 （理想的には、キャッシュの関連性に
注意を払う必要があります
-stat （）を
実行するか、
watchFile （）をまったく
実行しません
-しかし、このコードがモジュールなしでモジュールの初期ドラフトで機能することは明らかです。）
JAMドキュメントのデータ型（たとえば
ulong ）は jParserによって設定されて
いません（たとえば、
'' ulong '：' uint32 ' ）が、 JavaScript変数として宣言されています（たとえば、
var ulong =' uint32 ' ）、その値はデータ構造の説明。 これは速度のためです。V8javascriptエンジンのコードはjParserモジュールのコードよりもはるかに高速に動作することは明らかです。
SubField構造体の説明には、コメント化された
タイプフィールドがあります。このフィールドには、JAMドキュメントから借用したニーモニックフィールド指定を含むjavascript関数が入力されています。 デバッグ目的で使用できます。
MessageHeader構造内の
Subfieldsフィールドは、2つの方法で定義されます。 最初の（高速）は、このフィールドをサイズ
SubfieldLenのバイト文字列として読み取ります。 2番目の（コメントアウト）は、このフィールドを完全に処理し、jParserを使用してサブフィールドを分離します。モジュールを使用するアプリケーションがフィードのヘッダーの可変部分のメタデータを必要とする場合、長いボックスで分析を延期します。
AfterSubfieldsフィールドには、3バイトの
ASCII文字 「JAM」とそれに続くゼロバイトの文字列の単純な検索が含まれます。この理由は、前の段落の1つで説明されています。
console.log（）へのコメントアウトされた呼び出しには、デバッグの意味があります。 （内部変数
moveSIGの名前は、「
すべてのベースは私たちのものです」というミームを暗示してい
ます 。）
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;
スクリプトは
テストサブディレクトリにあるため、最初の行では親ディレクトリを使用します
。メインディレクトリのテキストは
index.jsファイルに
あります
。 Node.jsではこの名前が
デフォルトで暗示されているため、親ディレクトリのみを指定するだけで十分です。
blog-MtW.jhrファイルのテストデータには、2007年3月以降に蓄積さ
れた私のFidonetブログブログエコー
（ Ru.Blog.Mithgol ）の
ブログエントリが含まれて
います 。
シングルコアPentium IV（2.2 GHz）でテストを実行すると、ヘッダーが
3〜4秒で処理されることがわかります。
Subfields配列の単純な読み取り値がその分析（現在はコメントアウトされています）に置き換えられた場合、この時間はまだ2倍になります。
Fidonetサイトでは、このようなエコー会議が100を超えることがあり、電子メールヘッダーの合計分析時間は数分になるため、これは1つのエコー会議にとっては多くのことです。
しかし、fidotniksはおそらく、人気のあるGoldEDメールエディターGoldED（GoldED +、
GoldED-NSF）がエコーカンファレンス（作業の開始時）をはるかに速くスキャンし、スプラッシュスクリーンのステータスバーで名前が点滅して見やすいことを思い出す必要はないでしょう。ほんの数秒が費やされ、それ以上はありません。 意図せずに不快な結論に達しなければなりません。バイナリデータのJavascript分析は、高速V8エンジンでも、1桁以上遅く、さらに1桁以上遅くなることはありません。
作業の開始時のGoldEDがファイル全体を高速化するのではなく、1つのヘッダー構造
FixedHeaderInfoStructのみを疑うのは皮肉なままです（エコー会議のメッセージ数を表示するにはデータが十分であり、作業の開始時にはGoldED
は何もし
ません
）-真実、
CVS GoldED +を理解する時間がなかったので、この疑いを確認も否定もできません。
私のモジュール（JAMヘッダーの
リーダー ）のコードを無料のMITライセンスの下
でGithubに投稿しました。