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

Inclede itself!とかかっこ良かったかなぁ。

> >データや、通信のプロトコルなどで、レーコド数やオクテット数をそのデータ
> >内に含めることは少なくないわけですが、その数値自体を含めたヘッダ長など
> >も、それに含めるかどうかは別れてくると思うのです。
> 
> >最近、外からもらう仕様は、それらのデータが含まれていない。というか、
> >「仕様書に、どういう数値か書いてないんですけど、headerとtrailerを含め
> >ますか？」って聞いたら「普通、入れないでしょう。」見たいなことをいわれ
> >るんです。
> それはヒドいですね。
> 「入れるか入れないか」書いてないなんて、明白な欠陥仕様だと思います。

「普通、入れない」ので…

そんなのに慣れてないと、受注プログラムはかけません。シクシク。

＃ヘタをすると、「headerとtrailerを含めますか？」って聞いても、その意
＃味すら理解してくれない人は少なくないんです。それが「SE」さんの現状。

> ファイル形式として「AppleDouble/AppleSingle」「MacBinary」「BinHex」を
> 見てみたんですが、参考にならなかった^_^;
> 何故かというと、
> いずれも「長さフィールド」が「実体」と隣接していないんです。
> こういう場合には、当然「ヘッダは含まない」に決まってます。

これは当然ですよね。

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

昔、(fjでも流したような気がするけど)ある(今はなき)ワープロ屋さんのベク
トルフォントをghostscriptで利用するっていうドライバを書いた時、前の方
に、データのオフセットが書かれてて(長さもだったかなぁ)そこから拾ってき
たのを覚えています。(データ自体も少し変わってたなぁ。10bitで読み出す場
合と12bitで読み出す場合が混在してたり、座標がなんか変だったり。)

ランダムアクセスがメインだって場合はこの方が扱いやすいんですよね。当然。
でも、ストリームとして扱う場合はレコード数のチェックをしたり、なかなか、
やりたくないです。

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

ヘッダを含めてtrailerを含めないのは、プログラムを作る上では、「有り」
かも知れません。別々のデータとtrailerは領域に読んでおきたいしなぁ。と
か。

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

rfcでも、そのような書き方を見ることは少なくないです。すぐに、どれ、っ
てのは出てきませんが。

-- 
   ___     わしは、山吹色のかすてーらが大好きでのぅ
 [[o o]]            ふぉっふぉっふぉ
   'J'     森下 お代官様 ＭａＮＭＯＳ 英夫＠ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D  02 74 87 52 7C B7 39 37