JSONをProtobufに変換｜protocが通る.protoにする

このツールの動作

JSON の標本が proto3 のメッセージになります。オブジェクト一つにつき一つです。

{ "id": 1, "name": "Ada", "tags": ["admin"], "address": { "city": "Paris" } }

syntax = "proto3";

message Root {
  int64 id = 1;
  string name = 2;
  repeated string tags = 3;
  Address address = 4;
}

message Address {
  string city = 1;
}

項目番号は各メッセージで 1 から始まり、鍵の現れた順に振られます。protobuf が線の上に流すのはこの番号です。名前は人のため、番号が取り決めです。

元の鍵は残す

protobuf の項目名は慣例として [a-z_][a-z0-9_]* で、ハイフンを含みません。そこで content-type は content_type になります。ここが噛みます。proto3 の JSON 対応づけは、JSON の鍵を項目名から lowerCamelCase で導きます。content_type は contentType になり、それはあなたのデータの鍵ではありません。

string content_type = 1 [json_name = "content-type"];

json_name が元の鍵を固定し、メッセージは生成元の文書を読み続けます。この選択肢は、名前を直したときにだけ付きます。すでに snake_case の鍵には要りません。proto3 の解析器は項目名そのままの鍵も受け取るからです。

これは本物の欠陥でした。生成された .proto が、自分の入力と黙って合わなくなっていたのです。この文章を書く過程で見つけ、直しました。

64 ビット整数は文字列で運ばれる

整数は int64 になります。proto3 の JSON 対応づけでは、int64 は文字列として符号化されます。

{ "id": "12345678901" }

これは仕様であって、ここでの選択ではありません。JSON の数値は 64 ビットを安全に運べないので、対応づけがそれを避けています。とはいえ、protobuf を往復すると、受け手の見る型が変わるということです。その項目が小さな計数なら、int32 に直すだけの理由があります。

proto3 が言えないことは Value で言う

• null と型の分からない値は google.protobuf.Value になり、import "google/protobuf/struct.proto" が加わります。必要なときだけです。
• 入れ子の配列は google.protobuf.ListValue になります。proto3 は repeated repeated を禁じるので、配列の配列に直接の形はありません。
• 型の混ざった配列は repeated google.protobuf.Value になります。整数と小数だけが混ざっている場合は repeated double が両方を覆います。

「ある/ない」は思うようには扱われない

proto3 では、optional の付かないスカラー項目に存在の区別がありません。復号したあと、項目が無いことと、0・""・false であることは見分けられません。どの鍵が本当に省略可能かは JSON の標本のどこにも書かれていないので、ここでは optional を付けません。その違いが効く場面——null になりうる点数、未設定の旗——では、この語を足すのが正しい手入れです。

プライバシー

すべての処理はブラウザ内のJavaScriptだけで完結します。データがアップロードされることはないため、機密情報でも安心して利用でき、オフラインでも動作します。