BSON デコーダー・Extended JSON ビューア

使い方

1. .bson ファイルをボックスにドロップします。mongodump の出力でも、ドライバが保存した単一文書でも、MongoDB のツールが書いたものなら何でも構いません。
2. ツリーを読みます。各行が 1 要素で、BSON の型名、実際に流れる型バイト、値、占有バイト数が並ぶので、文書が肥大した理由がそのまま見えます。
3. 型を保ったまま持ち回るなら正準 Extended JSON を、ただ中身を読みたいだけなら緩和 Extended JSON を選びます。$numberInt と $numberLong は別物です。
4. ObjectId の行の下段で生成時刻・乱数・カウンタを、UTC 日時の行の下段で生のミリ秒に対応する日付を確認します。
5. 受け付けられなかったときは、どのエラーかを読みます。長さの不一致、終端の欠落、未定義の型バイトは別々の障害で、バイト位置がどこを見ればよいかを示します。

よくある質問

同じ配列なのに、なぜ BSON のほうが JSON よりずっと大きいのですか。

BSON には配列専用の型がないからです。配列は、フィールド名が十進のインデックス "0"、"1"、"2" … である普通の文書として保存され、そのインデックスは実際に NUL 終端の文字列として流れます。32 ビット整数 1000 個なら値だけで 4 KB のところ、型バイト、1〜3 文字のインデックス名、終端が加わって約 8.9 KB になります。インデックスのキーが誤っていても誰も気づかない理由もここにあります。ドライバは配列を位置で読むため、キーが "0"、"2"、"x" でも要素 3 個として解けてしまい、何かが再シリアライズするまで問題が表に出ません。このツールはその状態を黙って通さず、警告として示します。

正準 Extended JSON と緩和 Extended JSON はどう違いますか。

Extended JSON は BSON をテキストで書くための標準的な方法で、用途が二つあるため形式も二つあります。正準形式はすべての値を型マーカーで包みます。{"$numberInt": "1"} と {"$numberLong": "1"} と {"$numberDouble": "1.0"} は別物であり、だからこそ文書をテキストに出して同じバイト列に戻せます。緩和形式は普通の JSON で表せる値からは包みを外します。数値は数値になり、ISO 8601 の範囲に収まる日付は読める時刻になります。mongoexport の既定でずっと読みやすい一方、情報は落ちます。1 がただの 1 になってしまえば、三つある数値型のどれだったのかは分かりません。

JavaScript で表せない BSON の値は何で、ここではどう扱っていますか。

三つあります。int64 と UTC 日時は符号付き 64 ビット整数、内部の timestamp は 64 ビット 1 語に符号なし 32 ビットが 2 つです。対して JavaScript の数値は倍精度で、整数を正確に保てるのは 9,007,199,254,740,991 までです。それより大きい値は取り込む時点で丸められ、多くのビューアで 9223372036854775807 が 9223372036854775808 になるのはこのためです。このデコーダーは三つとも BigInt で読み、BigInt から桁を出力するので、double を通ることがありません。decimal128 はさらに深刻で、0.1 や 2.675 を正確に保つための十進型なのに double で読んだ時点で採用した理由が消えます。ここでは 128 ビットの係数とバイアス付き指数から直接、十進文字列に展開します。

1970 年より前の日付が負の数で表示されるのはなぜですか。

BSON がそう保存しているからです。UTC 日時型は Unix エポックからのミリ秒を int64 で持ち、その整数には符号があります。したがって 1970-01-01 より前の時刻はすべて負で、1953 年の生年月日はおよそ −526,608,000,000 です。正当な値でどのドライバも正しく往復させますが、このフィールドを符号なしとして扱ったり 0 で切り詰めたりするツールが意外に多く、1953 年が 1970 年になったり 2 億 9200 万年へ飛んだりします。この型が保持できる範囲は多くのソフトウェアが扱う暦よりはるかに広いため、このツールは生のミリ秒を日付の隣に並べ、暦の日付として表せない値はそうと明記します。

バイナリのサブタイプ 0x02 とは何で、なぜ罠と呼ばれるのですか。

廃止された最初のバイナリ配置です。バイナリのフィールドは int32 の長さ、サブタイプ 1 バイト、続いてペイロード、という形ですが、サブタイプ 0x02 だけはペイロードの先頭にもう一つ int32 があり、その値は外側の長さよりちょうど 4 小さくなっています。他のサブタイプと同じに扱う読み手は、先頭に無意味な 4 バイトが付いた塊を返してしまい、その 4 バイトももっともらしいバイナリに見えるため誰も文句を言いません。実際にその値を使おうとしたときに初めて壊れていることが分かります。2.0 より前の古いコレクションにはまだ残っているので、BSON を読むと称するデコーダーはこの場合を特別扱いする必要があります。本ツールはそうしており、内側の長さが外側と合わない場合はそのフィールドを受け付けません。

ObjectId の中身は何ですか。UUID ですか。

いいえ、構造を持った 12 バイトで、たいていはその構造を知りたくて中を見ます。先頭 4 バイトはビッグエンディアンの Unix 秒タイムスタンプです。_id で並べ替えるとおおむね生成順になり、別のフィールドなしで日付で絞り込めるのはこのためです。次の 5 バイトはプロセスごとの乱数、最後の 3 バイトは任意の値から始まり文書ごとに増えるカウンタです。古いバージョンでは中央にマシン識別子とプロセス ID が入っており、サーバーの情報がわずかに漏れていましたが、3.4 で変わりました。チェックサムもバージョン欄もないので、16 進 24 文字であれば文法的にはすべて正しい ObjectId であり、妥当かどうかを示すのは埋め込まれたタイムスタンプだけです。

関連ツール