基本情報のJSONとXMLの違いを構造・型・変換の具体例で理解する

基本情報でJSONとXMLを見分けるポイントは、JSONがオブジェクト・配列・値でデータを表し、XMLが要素や属性で文書やデータの構造を表すことです。どちらも階層を表せるテキスト形式であり、JSONだけが構造化データを扱えるわけではありません。

見た目の違いだけを覚えると、「数字を引用符で囲むとどうなるか」「XMLからJSONへ変換すれば情報を保てるか」といった問題で迷いやすいですよね。この記事では架空の商品データを同じ内容で書き比べ、値の型、階層の読み取り、文法とデータの妥当性の違いを自作例で確認します。

この記事のポイント

同じ商品情報からJSONとXMLの構造の違いを読める
文字列・数値・真偽値・空の値を区別できる
引用符やカンマとタグの対応の誤りに気付ける
変換と検証で何を確認するべきか判断できる

無料

基本情報技術者試験過去問アプリ

本番形式で繰り返し解ける。スキマ時間に1問から

2,000問以上収録

無料で過去問を解く

基本情報のJSONとXMLの構造を読む

JSONは項目と値の組で表す

JSONはJavaScript Object Notationの略です。JavaScriptの表記に由来しますが、特定のプログラミング言語の実行に限られないデータ交換形式です。JSONで書かれた文字列を受け取っただけで、プログラムとして処理が実行されるわけではありません。読み取り側のプログラムが解析し、必要な値を取り出します。

次は、商品コード007、在庫2個、利用中という状態を表す自作例です。code、stock、active、tagsが項目名で、その右側が値です。例の項目名に国際的な決まりがあるわけではなく、商品情報を受け渡す側どうしで意味を定めたものです。

{
  "code": "007",
  "stock": 2,
  "active": true,
  "tags": ["red", "small"]
}

波括弧で囲んだ部分がオブジェクトです。項目名と値の間はコロン、項目同士の間はカンマで区切ります。項目名は文字列なので二重引用符で囲みます。stockの2は数値、activeのtrueは真偽値です。どの値も同じ文字列として読めばよい、という形式ではありません。

ここで商品コードを数値の7へ変えると、元の007という表記をそのまま保てません。計算する量である在庫と、数字を使った識別子である商品コードは役割が違います。先頭の0を保つ必要があるコードは文字列として扱う、というデータ設計上の判断につながります。

配列とオブジェクトを区別する

角括弧の配列は、値を順番のある列として表します。例のtagsは、redとsmallという二つの文字列を持つ配列です。配列の値には、文字列だけでなく、数値、オブジェクト、別の配列なども入れられます。何を入れてよいかという業務上の条件は、利用するデータ仕様で別に決めます。

オブジェクトは項目名から値を読む構造です。例えばstockという項目を探して2を取得します。JSONのオブジェクトの項目順に意味を依存させる設計は避け、順序が必要なら配列で表すなど、構造の役割を分けます。「二番目に書いてあるから在庫」と読むのではなく、項目名で確認するわけですね。

一方、配列は先頭、次の要素という位置が意味を持ちます。並び順がランキングや処理順を表すこともあるので、勝手に並べ替えないことが大切です。また、一つの商品オブジェクトと、商品を一つだけ含む配列は別の構造です。件数が一つでも配列がオブジェクトに自動で変わるとは限りません。

JSONの基本構造と値の定義はIETFのRFC8259で確認できます。オブジェクトを常に一番外側へ置くことがJSON全体の必須条件というわけでもありません。具体的なAPIやファイルがどんな最上位構造を要求するかは、その仕様と合わせて読みましょう。

数値と文字列と空を分ける

JSONで使える値には、文字列、数値、真偽値のtrueとfalse、null、オブジェクト、配列があります。例えば2と”2″は違います。前者は数値、後者は数字の文字を一つ含む文字列です。見た目が似ていても、読み取り側が計算するのか、識別子として照合するのかで扱いが変わります。

falseと”false”も別です。falseは真偽値ですが、引用符付きの”false”は5文字の文字列です。文字列を真偽値へどう変換するかは言語や処理に依存するので、同じ意味として無条件に入れ替えてはいけません。送る側と受ける側で期待する型をそろえます。

null、空の文字列、項目そのものがない状態も区別します。例えばnameがnullなら値としてnullを持つ項目があります。nameが空文字列なら文字数0の文字列です。nameがないなら項目が存在しません。これらを未入力、未確認、削除指示などへどう対応させるかは、データの契約によります。

また、JSON自体に日付専用の値やundefinedという値はありません。日付を文字列として表すことはできますが、形式やタイムゾーンは別の約束が必要です。JavaScriptで使える値がすべてJSONにそのまま書けるとは考えないようにしましょう。MDNのJSONリファレンスでも、JavaScriptの構文との違いを確認できます。

XMLは要素と属性で構造を作る

XMLはExtensible Markup Languageの略です。開始タグと終了タグで要素を囲み、親子の入れ子で構造を表します。要素に付ける属性も利用できます。先ほどの商品情報を、次のようなXMLへ対応させることができます。これは説明のために決めた一例で、変換方法が一意に決まるという意味ではありません。

<item code="007">
  <stock>2</stock>
  <active>true</active>
  <tags>
    <tag>red</tag>
    <tag>small</tag>
  </tags>
</item>

itemが文書全体を包む要素で、codeはその属性です。stock、active、tagsはitemの子要素で、tagはtagsの子要素です。同じ名前のtag要素を繰り返して、複数の値を表しています。JSONの配列と同じ専用記号がなくても、構造を使って複数項目を表せます。

ただし、stockの中に2と書いてあるだけで、その内容が自動的にJSONの数値型と同じ扱いになるとは限りません。XMLの基本的な文字列の内容を、スキーマやアプリケーションの規則に従って型付きの値として扱う場面があります。「XMLには数字を書けない」でも「数字を書けば必ず数値型」でもありません。

文書の順序と属性の意味を読む

XMLは単なる項目の一覧だけでなく、文章の中へ印や参照を入れるような文書の構造も表せます。例えば、説明文の途中に強調を表す要素を入れ、その前後の文字列と一緒に保持できます。このような混在した内容では、子要素と文字列の並び順が情報の一部になります。

属性と子要素のどちらに値を置くかも、文書の設計によります。商品コードをcode属性ではなくcodeという子要素で表すことも可能です。だからといって既存の属性を勝手に子要素へ変えてよいとは限りません。読み取り側がどの位置を参照するかという契約を保つ必要があります。

違う仕様で同じ要素名を使う場合には、名前空間によって名前の衝突を区別する仕組みもあります。JSONの単なる項目名と、XMLの要素名・属性名・名前空間を無条件に同じものとして扱わないことが、相互変換での注意点になります。

XMLの要素、属性、整形式の基本規則はW3CのXML仕様が一次情報です。基本情報の学習では、まず一つの親の中に何が入っているかをたどり、値が属性なのか要素の内容なのかを区別するところから確認してみてください。

基本情報のJSONとXMLを比較して選ぶ

CSVやHTMLとは目的で分ける

CSVは、行と列で扱えるデータを区切り文字で表す形式です。各行が同じ種類のレコードで、項目を列として整理できる場合に扱いやすい一方、入れ子や複数件の項目をそのまま表すための構造はJSONやXMLとは異なります。例えば商品のタグを一列へ詰め込むなら、その列の解釈を別に決める必要があります。

HTMLはWebページの文書構造を表す言語です。タグを使う点はXMLと似ていますが、見出しや段落、リンクなど、HTMLとして定義された要素を使います。XMLは用途に合わせた語彙で構造を記述できます。「タグがあるからすべてHTML」という読み分けはしないようにしましょう。

JSONとXMLは、どちらも階層構造を表せます。JSONではオブジェクトや配列を入れ子にし、XMLでは要素を入れ子にします。テキストで読めることと、データの意味が人に自明であることも別です。stockという項目名を知っていても、個数の単位や更新時点まで分かるとは限りません。

スクロールできます

形式	構造の読み取り方	先に確認する条件
JSON	項目名と値、順序を持つ配列	値の型と項目の契約
XML	要素・属性・親子関係	要素の語彙と文書構造
CSV	行と区切られた列	区切り文字・引用符・列の意味
HTML	定義された要素による文書構造	Webページとしての要素の役割

JSONの文法と意味を分ける

JSONは、項目名と文字列に二重引用符を使います。単一引用符へ置き換えたり、項目名の引用符を省略したりすると、JavaScriptの式として扱える場面があっても、標準のJSONとは一致しません。オブジェクトや配列の最後の要素の後へ余分なカンマを付けることも、標準JSONの文法では認められません。

true、false、nullは小文字で記述します。数値には書ける形の規則があり、007という先頭0付きの数値を、そのままJSONの数値として書くことはできません。商品コードとして007を残したいなら”007″という文字列にします。例のcodeとstockは、見た目の数字ではなく役割から型を決めています。

文法として正しいことと、必要な商品情報が正しいことは別です。例えばstockが−2のデータでも、JSONの数値という点では書けます。しかし「在庫は0以上」という業務ルールがあれば、別の検証で拒否する必要があります。解析に成功したことを、業務上の妥当性の証明にしないようにしましょう。

同じオブジェクトへ同じ項目名を複数書くことも、相互運用では避けます。受け取り側によってどの値が残るかなどの扱いが異なり得るためです。「項目名が重複しても最後が必ず採用される」と、すべての処理系に共通する規則として覚えないことが大切です。

XMLはタグの対応を確かめる

XMLでは、開始タグと終了タグが対応し、親子関係が正しく閉じている必要があります。例えばitemの中でnameを開いたなら、nameを閉じてからitemを閉じます。itemを先に閉じてしまう交差した入れ子は、整形式のXMLにはなりません。要素名の大文字・小文字も区別します。

文書全体を包む要素は一つです。複数の商品を表したければ、複数のitemを一つのitems要素などで包む設計が考えられます。XML宣言を先頭へ書くことはできますが、宣言があることと、必要な商品構造を満たすことは別です。また、すべてのXMLでXML宣言が必須というわけでもありません。

文字データに特別な意味を持つ記号を入れる際も注意します。例えば商品名A&BをXMLの要素内容へ表すなら、次のようにアンパサンドを参照で表します。画面に見せたい文字と、ファイル内でその文字を表す記述を区別してください。

<name>A&amp;B</name>

整形式はXMLの基本的な構文を満たしていることです。さらに、決められた構造や型などに合うかを検証する場合は、DTDやXML Schemaなどの仕組みが関係します。XML Schemaでは構造や内容に制約を記述できますが、DTDとまったく同じ機能だと覚えないようにしましょう。W3CのXML Schema仕様では、検証に使う構造の定義を確認できます。