JSONって何?って思ったら、なりたてのSE・PGが意識しておくこと



じぇいそ~ん、じょんそん、ろんどん、ろびんそん
いきなりこんなですいまめーん、ほんとに、すいまめーん!!

というような ジョイマンのテンションまで
今は上がりませんので普通に始めます。

強引に一言でいうと

jsonとは、
データフォーマットの一種です。

妥協してもらってもちょっと追加すると

わかりやすく、階層構造や、連想配列が表現でき
人間もコンピュータもすぐに簡単に使い始められ、
問題少なる利用できるデータフォーマットです。

データ構造

データフォーマットを見ながら、特徴点を確認してみてください。

  • {}で大枠を囲み 設定したい名前と値を1対1で指定しつつ、階層構造で宣言できます。
  • 名前と値の間は  コロンで区切り、
  • 同じ階層に複数ある場合は カンマで区切ります。
  • 子要素を作りたい場合、値のところに {}で囲うようにして 深くすることもできます。
    (もちろん、その階層で複数あったら{}や []の後ろにも同様にカンマを付けます)
  • 配列や人間にとって扱いやすい連想配列も作れます。
  • テキストだけのデータ

{



"設定したいことの名前A": "設定値",
"設定したいことの名前B": "設定値",

"food":{


"設定したいことの名前a": "設定値",
"設定したいことの名前b": "設定値",

"fruits":{
   "apple": 3,
   "needs": false
},


"vegitable":{
     "shop": [ "A店", "B店"]
}
}
}


数字、null, true, falseなど以外は基本  ""で囲むのが正式です。
JavaScriptの場合、 プロパティ名側は括弧で囲まなくても、良いです。

多くの人が ini かもう一歩進んだ、 csv とまじった jsonに近いデータ構造は考えていたと思いますが、
Web API や REST の発展、 script 言語などの距離感から
バイナリではない、html/txt 形式をよく扱っていた JavaScript 界隈の重鎮が整理して
発表したデータです。

JSONの「発見者」クロックフォード氏が語る、JSON伝説 - Publickey

正式なフォーマットは RFCを見てください。

好まれている特徴

以上のような形式にはどういうメリットがあるでしょうか?
どういうメリットを残してきたでしょうか?
使う上で、抑えておきたいポイントは、まあわかると思いますがこんな感じです。

  •  人間の目から見てわかりやすい
  • コンピュータからも扱いやすいのが特徴です。
  • また記述量も同じように階層構造ができる XML などに比べたら少ないのが人気のポイントです。

子要素が柔軟に作れるツリー構造、作りやすさが、
ジョイマンと違い?、受けた秘密だと思います。

一定のパターンがあれば、視覚的にもわかりやすく、コピペ的にも作りやすいです。
テンプレート的に、繰り返しデータも配列で見やすく作ることも違和感なくできます。

その他補足的な特徴

  • コメント記載方法なし
    • 設定ファイルとして使いにくい
  • 通信やデータ連携用に向いてます。

比較


さっきは比較対象を間違えた気がしますが
どれくらい、良いのか悪いのか、どういうときjsonの選択が妥当なのか比べてみます。

よくあるのが csv, xml, iniファイルです。

iniファイル

よく考える普通のデータです。
わかりやすいですが、1見出しレベルぐらいまでで、階層構造ができません。

csv

csv などのリレーショナルDB型は、縦と横が決まっているので
階層構造も難しく、人間の目から、横方向のずれなど見ずらいものがあります。
見やすくするにしても、テキスト処理だけでは確認しにくいです。
大量の同じ形式のデータに対して効率や マシン間の連携にも柔軟性は高いです。

XML

階層構造もでき、連想配列もできますが
HTMLと同様で、データが作りにくいです。
また、素のテキストデータと言えど、そのままでは見ずらいですし
制約も多く、データ構造以外の部分に意識を取られます。

別要素にXSTLなど準備したりと、そのファイルで完結しないことも多いです。
SOAPや WSDLも期待されていましたが、
あきらかにデータフォーマットの点では失敗に近いでしょう。
   ※WEBサービスや  WEB API、マッシュアップという意味では期待しています。

この極端に面倒で、作りにくく、わかりにくい。
そしてコンピュータも扱いずらい(作るのも読むのも計算量が多い)という欠点があります。


JSONならどれくらい使いやすいかというと、大抵のprogrammerなら、どんな言語を扱う人でも
このフォーマットのパーサーを作るのにそれほど抵抗を感じないくらいです。
そのため、証拠に、多くの言語で使え、ライブラリもあることがほとんどです。
JavaScript , Java() , android, ruby, python  など
また、なくとも作ればいいので、どの言語か?という制約に影響されにくいです。

計算量として
XMLデータなら大量のトランザクションの時、
性能が出ないことがありえそうですが、
jsonでは、XMLよりも余裕がありますし、
関係者全員がフォーマットを深く理解しながら対応できます。

作るとき・使うとき気にしないといけないことは

先ほどの大まかなフォーマット以外気にすることは少ないです。
ファイル以外に、気にしなければいけないことは少ないので
その場で自由にフォーマットを決めても問題はありません。
大抵のデータ構造は作れるでしょう。

せいぜい、カンマや ””でくくったりエスケープ文字に気を付けたりするぐらいです。

使うときは、コメントがないので、
設定ファイルとしてはそこのところを加味したほうがいいでしょう。

テキストなので、圧縮かけようが、ハッシュ値で変更を検知しようが、
暗号をかけようが自由です。

まあ、少なくとも、業務や重要な中心的なシステムのデータ構造に合わせたほうがいいです。

javascript サンプル

JSON と JavaScript両方を満たす形式で欠けるので、
JSONファイルをそのままJavaScript上にデータとして読み込ませることもできます。

使用例の一例として JavaScript(ECMA Script)のケースを上げます。
JSON - JavaScript | MDN

また、ピリオドにより、階層構造が表現できるので
最近のオブジェクト指向言語や、クラス定義が可能な言語、またその使用者からみて
違和感なく扱うことができ、学習コストが1時間もかかりません。

参考

JavaScript Object Notation - Wikipedia

JSONLint - The JSON Validator  JSONのデータの文法をチェックできる Lint

JSON  JSONの定義(日本語)

Delicious にシェア
Digg にシェア
reddit にシェア
LinkedIn にシェア
LINEで送る
email this
Pocket




コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です