In article <squbquyoujs.fsf@stellar.co.jp> manmos@stellar.co.jp writes:
>＃あぁあ変なSubject
「lengthの測り方」とか「lengthの数え方」くらいにしとけば良かったかも

>データや、通信のプロトコルなどで、レーコド数やオクテット数をそのデータ
>内に含めることは少なくないわけですが、その数値自体を含めたヘッダ長など
>も、それに含めるかどうかは別れてくると思うのです。

>最近、外からもらう仕様は、それらのデータが含まれていない。というか、
>「仕様書に、どういう数値か書いてないんですけど、headerとtrailerを含め
>ますか？」って聞いたら「普通、入れないでしょう。」見たいなことをいわれ
>るんです。
それはヒドいですね。
「入れるか入れないか」書いてないなんて、明白な欠陥仕様だと思います。

>私が最近使う(実装する)プロトコルでは、
>
>ip、udp、radius、eapol、eap、ppp、tls(ssl)、asn1(snmp他)
>
>ファイル形式では
>snoop、X509(ってASN1 DERやん)
>
>とlengthにヘッダ長を含みます。世の中、これが普通なんだと信じてたんです
>が…
ファイル形式として「AppleDouble/AppleSingle」「MacBinary」「BinHex」を
見てみたんですが、参考にならなかった^_^;
何故かというと、
いずれも「長さフィールド」が「実体」と隣接していないんです。
こういう場合には、当然「ヘッダは含まない」に決まってます。

詳しく言うと、
いずれも全体のヘッダが“固定長”または“固定長パターンの反復”になっていて、
「全体長」を直接記述するフィールドは存在せず、
各データバートの長さは、全体のヘッダの中で集中管理されているわけです。

ちなみに、「BinHex」では、各データバート実体の直後にCRCが来るんですが、
ヘッダに記述されるデータ長は、このCRCを含みません。
この部分は、お代官様の「普通」には属さないかも。

別のファイル形式として、
FACOMの大型汎用計算機（懐かしい名前だ^_^;）における
可変長ファイル（ということは、HITACやIBMも多分同じ）では、
ファイルオープン時に指定する「レコード長（＝許容最大値）」には、
各レコードに付加されるヘッダの長さが含まれます。
ですが、ヘッダ自身に記載される実レコード長がどうだったかは、
手元に資料が無く、判りません。

MacintoshのHFSにおけるResourceForkに含まれる各ResourceDataは、
長さヘッダに続いて実体が来ますが、
この「長さ」にはヘッダは含まれません。
仕様書には「Length of following resource data」とあります。
この「following」という言葉で「含まない」ことを明示しているつもりかな？

                                戸田 孝＠滋賀県立琵琶湖博物館
                                 toda@lbm.go.jp