Mermaid.js パケット図の構文とレイアウトガイド

パケット図は、ネットワークエンジニア、セキュリティアナリスト、システム開発者が、ネットワークプロトコル、メモリ割当、またはカスタムハードウェアパケットヘッダーの正確なバイナリ構造を可視化するために使用する専門的な可視化コンポーネントです。Mermaid.jsにネイティブに導入されたこのツールは、クリーンでテキストベースのフィールド分解から、応答性があり、完全に整列されたビットレベルのグリッドマップを自動的にレンダリングすることで、面倒な手作業のテーブル作成を置き換えます。

パケットグリッドレイアウトの理解

標準的な自由形式のフローチャートとは異なり、パケット図はネットワーキングのRFCに直接基づいた厳密な数学的グリッドシステムに依存しています：

• ビット幅（水平軸）： レイアウトエンジンは、デフォルトで各行を32ビットグリッドシステム（ビット0から31まで）に自動的に分割します。
• 自動ビット計算： それぞれのフィールドに対してビット長を宣言するだけでよいです。レンダリングエンジンが計算を処理します——隣接するフィールドを同じ行に自動的に詰め込み、累積サイズが32ビットのしきい値を超えると、次行にきれいに折り返します。

基本的な構文構造

すべてのパケットマップは、packetという宣言ヘッダーから始まります。その後、厳密な"フィールド名": ビットサイズというパターンに従って、各行に順次ペアでフィールドを宣言します。

packet
  0-3: "バージョン"
  4-7: "IHL"
  8-15: "サービス種別"
  16-31: "総長さ"

構文リファレンス

以下の表は、Mermaid.jsでパケット図を構築するために必要な基盤となるデータパラメータとフォーマットレイアウトルールを分解しています。

実世界のブループリント：IPv4パケットヘッダー構造マップ

この包括的なブループリントは、標準のインターネットルーティングパケット構造（IPv4）を追跡します。マルチビットフィールド、単一ビットフラグ、および大きな16ビットブロックが、標準の32ビット水平グリッドレイアウト内で順次組み合わされる様子を示しています。32ビットのマーカーに達するフィールドは、自動的に次の行にスムーズに移行します。

packet
  0-3: "バージョン"
  4-7: "IHL"
  8-15: "サービス種別"
  16-31: "合計長さ"
  32-47: "識別"
  48-50: "フラグ"
  51-63: "フラグメントオフセット"
  64-71: "TTL"
  72-79: "プロトコル"
  80-95: "ヘッダーチェックサム"

構文のヒント： 単一の宣言されたフィールドが32ビットより大きい場合（たとえば64ビットの暗号化ソルトやタイムスタンプなど）、レンダリングエンジンはそのブロックを複数の連続する行にわたって滑らかに折り返し、垂直方向に伸ばし、読みやすさを保つために明確な接続インジケータを使用します。

一般的な構文の落とし穴とシステム制約

非常に正確なバイトレベルのドキュメントマップを設計する際には、コンパイルエラーを防ぐために、以下のトラブルシューティングパラメータを念頭に置いてください：

• 必須の引用符ラッパー： すべてのフィールド記述テキスト文字列は、二重引用符で囲まれている必要があります。引用符を省略すると、即座に構文解析エラーが発生します。
• 無効な文字列ビットサイズ： コロン区切りの後の値の厚さ割り当ては、そのままの未引用の整数でなければなりません。小数やアルファベットサイズ（例："Data": 8bits）を渡すと、図のコンパイルが停止します。
• グリッド端部の整列 均一で箱型のヘッダーダイアグラムを得るには、結合されたフィールドの合計が32の倍数にちょうど一致するようにしてください。未割り当てのビットが残る行を残しておくと、見た目が不均一な終端ブロックが生じる可能性があります。
• スケールビューの制約： エンジンはレイアウト幅を動的に計算しますが、超長のテキスト説明を小さな1ビットまたは2ビットのブロックに詰め込むと、タイプグラフィが切り捨てられたり、視覚的にごちゃついたりする可能性があります。小さなビット数のラベルは簡潔に保ってください。