分析と広告のためのCookie
分析と広告のためにCookieを使っており、どちらもGoogleに送られます。拒否しても、目に見える動作は何も変わりません。プライバシーポリシーを読む
JSON を最小化
JSON を貼り付けると、余分な空白がひとつもない同じデータと、それが実際に何を節約したかが得られます。文字数ではなくバイト数です。日本語や絵文字が入ると 2 つは別の数字になるからです。文書は解析して書き直され、置換で編集されるのではありません。だから文字列の中の空白は生き残ります。
処理される場所
ファイルがないので、何もアップロードされません。計算はこのページの中で行われます。
順番待ちもアカウントもなし
お使いの機械の速さで答え、あなたが誰かを尋ねることはありません。
何度でも
回数は数えず、上限もありません。もう一度答えることに費用はかからないからです。
仕組み
- JSON を貼り付けてください。
- 2 つの文書を比べるなら、キーをアルファベット順に並べ替えるかどうかを決めます。
- 1 行をコピーします。何も送信されていません。
切り取るのではなく解析します
JSON を素早く縮める方法は、空白と改行をすべて取り除くことです。同時に誤った方法でもあります。文字列の中の空白はデータの一部だからです。`"山田 太郎"` が `"山田太郎"` になり、結果はなお妥当な JSON なので、誰もずっと後まで気づきません。
ここでは組み込みのパーサーで文書を読み、書き直します。したがって出てくるのは同じデータ構造であることが保証されます。縮めることで内容が変わる入力は存在しません。テキストをテキストとして扱う瞬間がどこにもないからです。
文字数ではなくバイト数
表示される節約量は UTF-8 のバイト数です。それが効く数字だからです。ひらがなも漢字も 1 文字 3 バイト、絵文字は 4 バイトです。日本語のテキストを含む文書は、文字数から想像するよりバイト数でずっと大きくなります。
節約量を文字数で測ると、純粋な ASCII のペイロードではほぼ同じ数字が出て、日本語だらけのものでは 3 倍近く外れます。ここで問題になるのは常に経路か保存先で、どちらもバイトを数えるので、計算もバイトで行います。
Gzip がある場所で最小化に何の意味があるか
ほとんどの API は圧縮して応答し、Gzip は繰り返された空白に対して並外れて強力です。行頭の 4 つの空白が 1000 回あっても、圧縮後にはほとんど費用になりません。したがって経路上の節約はここの数字よりはるかに小さく、しばしば 1 桁パーセントです。
割に合うのは、何も圧縮されない場所です。環境変数、長さ制限のあるデータベースの項目、ログ、サイズ上限のあるキューのメッセージ。そこでは生のバイト数が境界であり、そこでこそ差が現実になります。
キーを並べ替えて何が得られるか
JSON のオブジェクトに定義された順序はないので、2 つのサービスが同じデータを別の順序で返すことがあります。テキストの比較は、そこに差がないのに差を指します。両者が同じことを言っているのに契約テストが赤くなる、よくある理由です。
キーを並べ替えて両方を最小化すれば、素朴な文字列比較が正しい答えを出す形になります。同じ手続きがキャッシュキーと JSON への署名の背後にもあります。ハッシュを取る対象には正規形が要り、さもなければハッシュがシリアライザーの気分に依存します。
並べ替えは正規化ではありません
署名のためには本物の仕様があります。RFC 8785 で、順序以上のことを定めます。数値の書き方、特殊文字のエスケープの仕方、そして並べ替えの基準——言語的な五十音順ではなく UTF-16 の符号単位順です。
ここでの並べ替えは、比較と差分のための実務的な変種であって、暗号署名のための規範ではありません。差分になら十分すぎます。JSON に署名する人は仕様を読むべきです。そこでは、日々の作業では誰の目にも留まらない細部がまさに差を生むからです。
数値が苦しくなる境目
JSON は数値をテキストとして書き、JavaScript はそれを倍精度浮動小数点として読みます。約 9007 兆を超える整数は桁を失います。19 桁の識別子が別物になって出てきて、結果は妥当な数値に見えるので誰も気づきません。
JavaScript のパーサーを通るあらゆる処理が影響を受けます。ここも含みます。よくある引き金は snowflake 形式の識別子と、一部のデータベースの連番です。解決は生成する側にあります。その種の値は文字列として運ぶべきで、そうすればどの段も無事に通り抜けます。
1 行はリポジトリ向きではありません
バージョン管理されたファイルの中の最小化された JSON は、どんな変更も「1 行が変わった」に変えます。差分は全か無かになり、レビューは不可能になり、マージの衝突は問題の 2 項目ではなく文書全体に及びます。
うまくいく分担はこうです。リポジトリでは整形、配信時に最小化。整形のページが逆方向を担い、その 2 つのあいだにあるのが、ビルド工程が自動で踏むべき手順です。
末尾の改行
ここの出力は改行なしで終わります。ファイルではなく 1 行だからです。これをファイルに書く人は改行を足すべきです。POSIX はテキストの行を改行で終わるものと定義しており、`cat` から Git まで、道具はそれを持たないファイルに対して妙な振る舞いをします。
効いてくるのはチェックサムを比べるときです。末尾の改行があるファイルのハッシュは、ないファイルのハッシュとまったく違います。両方が同じ JSON を含んでいてもです。一致すべき 2 つの値が一致しない理由のひとつがこれです。
個人情報保護法から見たときの位置
JSON のペイロードは、動かさないほうがよいものをそのまま含みがちです。顧客の記録、注文データ、氏名や住所の入った webhook。ここでは解析も出力もページの中で行われるので、当方への提供が起きず、その内容についての第三者提供も委託も生じません。
ネットワークパネルで示せます。使っているあいだ、文書を運ぶリクエストは出ません。サーバー版なら社内規程とぶつかる場面でこのツールが使える理由がそこにあり、確認には 1 分もかかりません。
JSON を最小化：よくある質問
文字列の中の空白は残りますか。
はい。文書は解析して書き直され、1 文字ずつ編集されるのではありません。文字列の中の空白はデータの一部なので触れません。消えるのは構造の要素どうしのあいだにあるものだけです。
API がすでに Gzip を使っているなら意味はありますか。
経路上ではほとんどありません。Gzip は繰り返された空白に非常に強いからです。意味があるのは圧縮されない場所です。環境変数、長さ制限のある項目、サイズ上限のあるキューのメッセージ。
長い識別子が変わってしまうのはなぜですか。
JavaScript が数値を倍精度浮動小数点として読み、約 9007 兆を超える整数が桁を失うからです。その種の識別子は JSON では文字列として運ぶべきです。
コメント入りの文書が弾かれるのはなぜですか。
JSON にコメントがないからです。末尾のカンマも引用符なしのキーもありません。設定にコメントが要るなら、適した形式は YAML、TOML、JSON5 です。
JSON は端末から出ますか。
いいえ。解析も出力もこのページの中で行われます。確認はネットワークパネルで。使っているあいだ、文書を運ぶリクエストは出ません。