DataContractJsonSerializer を使用したスタンドアロン JSON シリアル化

JSON (JavaScript Object Notation) は、ブラウザー内の Web ページで実行されている JavaScript コードで使用されるように特別に設計されたデータ形式です。 これは、Windows Communication Foundation (WCF) で作成 ASP.NET AJAX サービスで使用される既定のデータ形式です。

この形式は、ASP.NET と統合せずに AJAX サービスを作成するときにも使用できます。この場合、XML が既定ですが、JSON を選択できます。

最後に、JSON のサポートが必要であっても、AJAX サービスを作成していない場合、 DataContractJsonSerializer を使用すると、.NET オブジェクトを JSON データに直接シリアル化し、そのようなデータを .NET 型のインスタンスに逆シリアル化することができます。 これを行う方法の詳細については、「 方法: JSON データをシリアル化および逆シリアル化する」を参照してください。

JSON を使用する場合は、同じ .NET 型がサポートされます。ただし、 DataContractSerializerでサポートされているのと同様に、いくつかの例外があります。 サポートされている型の一覧については、「 データ コントラクト シリアライザーでサポートされる型」を参照してください。 これには、ほとんどのプリミティブ型、ほとんどの配列とコレクション型、および DataContractAttribute と DataMemberAttributeを使用する複合型が含まれます。

.NET 型を JSON 型にマップする

次の表は、シリアル化と逆シリアル化の手順によってマップされた場合の .NET 型と JSON/JavaScript 型の対応関係を示しています。

列挙型と JSON

列挙メンバー値は JSON では数値として扱われます。これは、メンバー名として含まれるデータ コントラクトでの処理方法とは異なります。 データ コントラクトの処理の詳細については、「データ コントラクトの列挙型」を参照してください。

• たとえば、 public enum Color {red, green, blue, yellow, pink}がある場合、 yellow をシリアル化すると、文字列 "yellow" ではなく数値 3 が生成されます。

• すべての enum メンバーはシリアル化できます。 EnumMemberAttribute属性とNonSerializedAttribute属性は使用すると無視されます。

• 存在しない enum 値を逆シリアル化できます。たとえば、対応する色名が定義されていない場合でも、値 87 を以前の Color 列挙型に逆シリアル化できます。

• enumフラグは特殊ではなく、他のenumと同じように扱われます。

日付/時刻と JSON

JSON 形式では、日付と時刻は直接サポートされません。 ただし、これらは非常に一般的に使用され、ASP.NET AJAX はこれらの型に対して特別なサポートを提供します。 ASP.NET AJAX プロキシを使用する場合、.NET の DateTime 型は JavaScript の DateTime 型に完全に対応します。

• ASP.NET を使用しない場合、 DateTime 型は JSON で、このトピックの「詳細情報」セクションで説明されている特殊な形式の文字列として表されます。

• DateTimeOffset は、複合型 {"DateTime":d ateTime,"OffsetMinutes":offsetMinutes} として JSON で表されます。 offsetMinutesメンバーは、グリニッジ標準時 (GMT) からの現地時刻オフセットであり、現在は世界協定時刻 (UTC) とも呼ばれ、関心のあるイベントの場所に関連付けられています。 dateTime メンバーは、対象のイベントが発生したときのインスタンスを表します (AJAX が使用されている場合は JavaScript のDateTimeになり、使用されていない場合は文字列 ASP.NET になります)。 シリアル化では、 dateTime メンバーは常に GMT でシリアル化されます。 したがって、ニューヨーク時間の午前 3 時を説明する場合、 dateTime の時間の構成要素は午前 8 時 00 分で、 offsetMinutes は 300 (GMT から 300 分または 5 時間を引く) です。

  注

  DateTime と DateTimeOffset オブジェクトは、JSON にシリアル化されるときに、ミリ秒単位の精度でのみ情報を保持します。 シリアル化中にミリ秒未満の値 (マイクロ/ナノ秒) が失われます。

XML 型と JSON

XML 型は JSON 文字列になります。

• たとえば、XElement 型のデータ メンバー "q" に <abc/> が含まれている場合、JSON は {"q":"<abc/>"} になります。

• XML のラップ方法を指定する特別な規則がいくつかあります。詳細については、この記事の後半の「詳細情報」セクションを参照してください。

• ASP.NET AJAX を使用していて、JavaScript で文字列を使用したくないが、代わりに XML DOM が必要な場合は、 ResponseFormat プロパティを WebGetAttribute の XML に設定し、 ResponseFormat プロパティを WebInvokeAttributeの XML に設定します。

コレクション、ディクショナリ、配列

すべてのコレクション、ディクショナリ、および配列は、JSON で配列として表されます。

• を使用するカスタマイズは、JSON 表現では無視されます。

• ディクショナリは、JSON を直接操作する方法ではありません。 Dictionary<string、object> は、WCF で他の JSON テクノロジを使用する場合と同じ方法でサポートされない場合があります。 たとえば、"abc" が "xyz" にマップされ、"def" がディクショナリの 42 にマップされている場合、JSON 表現は {"abc":"xyz","def":42} ではなく、[{"Key":"abc","Value":"xyz"},{"Key":"def","Value":42}" になります。

• JSON を直接操作する (厳密なコントラクトを事前に定義せずにキーと値に動的にアクセスする) 場合は、いくつかのオプションがあります。

  • 弱い型指定の JSON のシリアル化 (AJAX) のサンプルの使用を検討してください。

  • ISerializable インターフェイスと逆シリアル化コンストラクターの使用を検討してください。これら 2 つのメカニズムを使用すると、シリアル化と逆シリアル化でそれぞれ JSON キーと値のペアにアクセスできますが、部分信頼シナリオでは機能しません。

  • シリアライザーを使用する代わりに 、JSON と XML の間のマッピング を使用することを検討してください。

  • シリアル化のコンテキストにおけるポリモーフィズムとは、基本型が必要な派生型をシリアル化する機能を指します。 コレクションをポリモーフィックに使用する場合 (たとえば、 Objectにコレクションを割り当てる場合) には、JSON 固有の特別な規則があります。 この問題については、この記事の後半の「詳細情報」セクションで詳しく説明します。

追加の詳細

データメンバーの順序

JSON を使用する場合、データ メンバーの順序は重要ではありません。 具体的には、 Order が設定されている場合でも、JSON データは任意の順序で逆シリアル化できます。

JSON 型

JSON 型は、逆シリアル化時に前のテーブルと一致する必要はありません。 たとえば、通常、 Int は JSON 番号にマップされますが、その文字列に有効な数値が含まれている限り、JSON 文字列から正常に逆シリアル化することもできます。 つまり、{"q":42} と {"q":"42"} の両方が有効なのは、"q" という Int データ メンバーがある場合です。

ポリモーフィズム

ポリモーフィックなシリアル化は、基本型が必要な派生型をシリアル化する機能で構成されます。 これは、XML シリアル化がサポートされている方法に相当する WCF による JSON シリアル化でサポートされます。 たとえば、MyDerivedTypeが必要なMyBaseTypeをシリアル化したり、Intが必要なObjectをシリアル化したりできます。

複合型を逆シリアル化する場合を除き、基本型が必要な場合は、派生型を逆シリアル化するときに型情報が失われる可能性があります。 たとえば、Uriが想定される場所でObjectをシリアル化すると、JSON 文字列になります。 この文字列を Objectに逆シリアル化すると、.NET String が返されます。 デシリアライザーは、文字列が最初に Uri型であることを認識しません。 一般に、Objectを想定すると、すべての JSON 文字列が .NET 文字列として逆シリアル化され、.NET コレクション、ディクショナリ、および配列をシリアル化するために使用されるすべての JSON 配列は、実際の元の型が何であったかに関係なく、Array型の .NET Objectとして逆シリアル化されます。 JSON のブール型は .NET の Boolean にマップされます。 ただし、 Objectが必要な場合、JSON 番号は .NET Int32、 Decimal 、または Doubleとして逆シリアル化され、最も適切な型が自動的に選択されます。

インターフェイス型に逆シリアル化すると、 DataContractJsonSerializer は宣言された型がオブジェクトであるかのように逆シリアル化されます。

独自の基本型と派生型を使用する場合は、通常、 KnownTypeAttribute、 ServiceKnownTypeAttribute 、または同等のメカニズムを使用する必要があります。 たとえば、Animal戻り値を持つ操作があり、実際に (Cat から派生した) Animalのインスタンスを返す場合は、KnownTypeAttributeをAnimal型に適用するか、操作にServiceKnownTypeAttributeを適用し、これらの属性でCat型を指定する必要があります。 詳細については、「 データ コントラクトの既知の型」を参照してください。

ポリモーフィックなシリアル化のしくみの詳細と、それを使用する際に考慮する必要があるいくつかの制限事項の説明については、この記事の後半の「詳細情報」セクションを参照してください。

バージョン管理

IExtensibleDataObject インターフェイスを含むデータ コントラクトのバージョン管理機能は、JSON で完全にサポートされています。 さらに、ほとんどの場合、型を 1 つの形式 (XML など) で逆シリアル化し、それを別の形式 (JSON など) にシリアル化し、データを IExtensibleDataObjectで保持することができます。 詳細については、「 Forward-Compatible データ コントラクト」を参照してください。 JSON は順序付けされていないため、注文情報が失われることに注意してください。 さらに、JSON では、同じキー名を持つ複数のキーと値のペアはサポートされていません。 最後に、 IExtensibleDataObject に対するすべての操作は本質的にポリモーフィックであり、派生型はすべての型の基本型である Object に割り当てられます。

URL の JSON

HTTP GET 動詞 ( WebGetAttribute 属性を使用) で ASP.NET AJAX エンドポイントを使用する場合、受信パラメーターはメッセージ本文ではなく要求 URL に表示されます。 JSON は要求 URL でもサポートされているため、"number" という Int を受け取る操作と、"p" という Person 複合型を受け取る操作がある場合、URL は次の URL のようになります。

http://example.com/myservice.svc/MyOperation?number=7&p={"name":"John","age":42}

ASP.NET AJAX Script Manager コントロールとプロキシを使用してサービスを呼び出す場合、この URL はプロキシによって自動的に生成され、表示されません。 NON-ASP.NET AJAX エンドポイントの URL では JSON を使用できません。

詳細情報

ISerializable のサポート

サポートされる ISerializable 型とサポートされない ISerializable 型

一般に、 ISerializable インターフェイスを実装する型は、JSON のシリアル化/逆シリアル化時に完全にサポートされます。 ただし、これらの型の一部 (一部の .NET Framework 型を含む) は、JSON 固有のシリアル化の側面によって正しく逆シリアル化されないように実装されています。

• ISerializableでは、個々のデータ メンバーの種類が事前に認識されることはありません。 これにより、型をオブジェクトに逆シリアル化するのと同様のポリモーフィックな状況が発生します。 前述のように、これにより JSON の型情報が失われる可能性があります。 たとえば、enum実装でISerializableをシリアル化し、(適切なキャストなしで) enumに直接逆シリアル化しようとする型は失敗します。これは、JSON の数値を使用してenumがシリアル化され、JSON 番号が組み込みの .NET 数値型 (Int32、Decimal、Double) に逆シリアル化されるためです。 したがって、 enum 値として使用された数値は失われます。

• 逆シリアル化コンストラクターの逆シリアル化の特定の順序に依存する ISerializable 型は、ほとんどの JSON シリアライザーが特定の順序を保証しないため、一部の JSON データを逆シリアル化できない場合もあります。

ファクトリの種類

IObjectReference インターフェイスは JSON で一般的にサポートされていますが、"ファクトリ型" 機能を必要とする型 (インターフェイスを実装する型とは異なる型のインスタンスをGetRealObject(StreamingContext)から返す) はサポートされません。

DateTime ワイヤープロトコル形式

DateTime 値は"/Date(700000+0500)/" の形式で JSON 文字列として表示されます。ここで、最初の数値 (指定された例では 700000) は GMT タイム ゾーンのミリ秒 (1970 年 1 月 1 日午前 0 時からの通常の (夏時間以外の) 時間です。 前の時刻を表すには、数値が負の値になる場合があります。 この例の "+0500" で構成される部分は省略可能であり、時刻が Local の種類であることを示します。つまり、逆シリアル化時にローカル タイム ゾーンに変換する必要があります。 存在しない場合、時刻は Utcとして逆シリアル化されます。 実際の数値 (この例では "0500" ) とその符号 (+ または -) は無視されます。

DateTimeをシリアル化する際、LocalとUnspecifiedはオフセット付きで記録され、Utcはオフセットなしで記録されます。

ASP.NET AJAX クライアント JavaScript コードは、このような文字列を JavaScript DateTime インスタンスに自動的に変換します。 .NET に DateTime 型ではない同様の形式の他の文字列がある場合は、同様に変換されます。

変換は、"/" 文字がエスケープされている場合にのみ行われます (つまり、JSON は "\/Date(700000+0500)\/" のようになります)。このため、WCF の JSON エンコーダー ( WebHttpBinding で有効) は常に "/" 文字をエスケープします。

JSON 文字列内の XML

XmlElement

XmlElement は、ラップされずにそのままの状態でシリアル化されます。 たとえば、XmlElementabc/< を含む型>のデータ メンバー "x" は次のように表されます。

{"x":"<abc/>"}

XmlNode の配列

Array XmlNode型のオブジェクトは、その型の標準データ コントラクト名前空間の ArrayOfXmlNode という要素にラップされます。 "x" が、"value" と空の要素ノード "M" を含む名前空間 "ns" の属性ノード "N" を含む配列の場合、表現は次のようになります。

{"x":"<ArrayOfXmlNode xmlns=\"http://schemas.datacontract.org/2004/07/System.Xml\" a:N=\"value\" xmlns:a=\"ns\"><M/></ArrayOfXmlNode>"}

XmlNode 配列の先頭 (他の要素の前) にある空の名前空間の属性はサポートされていません。

IXmlSerializable 型には XElement および DataSet が含まれます

ISerializable 型は、"コンテンツ タイプ"、"DataSet 型"、および "要素型" に分割されます。 これらの型の定義については、「 データ コントラクトの XML 型と ADO.NET 型」を参照してください。

"Content" 型と "DataSet" 型は、前のセクションで説明したArrayのXmlNode オブジェクトと同様にシリアル化されます。 これらは、名前と名前空間が対象の型のデータ コントラクトに対応している要素で包まれています。

XElementなどの "要素" 型は、この記事で既に説明したXmlElementと同様に、そのままシリアル化されます。

ポリモーフィズム

型情報の保持

前述のように、ポリモーフィズムは JSON でサポートされており、いくつかの制限があります。 JavaScript は弱く型指定された言語であり、型 ID は通常問題ではありません。 ただし、JSON を使用して厳密に型指定されたシステム (.NET) と弱く型指定されたシステム (JavaScript) の間で通信する場合は、型 ID を保持すると便利です。 たとえば、データ コントラクト名が "Square" と "Circle" の型は、データ コントラクト名が "Shape" の型から派生します。 "Circle" が .NET から JavaScript に送信され、後で "Shape" を期待する .NET メソッドに返される場合、対象のオブジェクトが元は "Circle" であることを .NET 側が把握すると便利です。それ以外の場合は、派生型に固有の情報 ("Circle" の "radius" データ メンバーなど) が失われる可能性があります。

型 ID を保持するために、複合型を JSON にシリアル化するときに、"型ヒント" を追加でき、逆シリアライザーはヒントを認識して適切に動作します。 "type hint" は JSON キーと値のペアで、キー名は "__type" です (2 つのアンダースコアの後に "type" という単語が続きます)。 値は、"DataContractName:DataContractNamespace" という形式の JSON 文字列です (最初のコロンまでは名前です)。 前の例を使用すると、次のように "Circle" をシリアル化できます。

{"__type":"Circle:http://example.com/myNamespace","x":50,"y":70,"radius":10}

型ヒントは、XML スキーマ インスタンス標準で定義され、XML のシリアル化/逆シリアル化時に使用される xsi:type 属性によく似ています。

型ヒントと競合する可能性があるため、"__type" と呼ばれるデータ メンバーは禁止されています。

型ヒントのサイズを小さくする

JSON メッセージのサイズを小さくするために、既定のデータ コントラクト名前空間プレフィックス (http://schemas.datacontract.org/2004/07/) は "#" 文字に置き換えられます。 (この置換を元に戻すために、エスケープルールが使用されます。名前空間が "#" または "\" 文字で始まる場合は、余分な "\" 文字が追加されます)。 したがって、"Circle" が .NET 名前空間 "MyApp.Shapes" の型である場合、その既定のデータ コントラクト名前空間は http://schemas.datacontract.org/2004/07/MyApp。 図形と JSON 表現は次のとおりです。

{"__type":"Circle:#MyApp.Shapes","x":50,"y":70,"radius":10}

逆シリアル化では、切り捨てられた (#MyApp.Shapes) と完全な (http://schemas.datacontract.org/2004/07/MyApp.Shapes) の両方の名前が認識されます。

JSON オブジェクトの型ヒントの位置

型ヒントは、JSON 表現で最初に表示する必要があることに注意してください。 これは、JSON 処理でキーと値のペアの順序が重要な唯一のケースです。 たとえば、次は型ヒントを指定する有効な方法ではありません。

{"x":50,"y":70,"radius":10,"__type":"Circle:#MyApp.Shapes"}

WCF クライアント ページと ASP.NET AJAX クライアント ページで使用される DataContractJsonSerializer は、常に最初に型ヒントを出力します。

複合型にのみ適用される型ヒント

非複合型の型ヒントを出力する方法はありません。 たとえば、操作に Object 戻り値の型があるが、Circle を返す場合、JSON 表現は前に示したようにすることができ、型情報は保持されます。 ただし、Uri が返された場合、JSON 表現は文字列であり、URI を表すために使用される文字列は失われます。 これはプリミティブ型だけでなく、コレクションや配列にも適用されます。

型ヒントが出力されるタイミング

型ヒントによってメッセージ サイズが大幅に増加する可能性があります (これを軽減する 1 つの方法は、可能であれば短いデータ コントラクト名前空間を使用することです)。 したがって、型ヒントが出力されるかどうかは、次の規則によって制御されます。

• ASP.NET AJAX を使用する場合、基本/派生の割り当てがない場合でも、可能な限り常に型ヒントが生成されます。たとえば、円が円に割り当てられている場合でも同様です。 (これは、弱く型指定された JSON 環境から厳密に型指定された .NET 環境への呼び出しプロセスを完全に有効にするために必要です。驚くべき情報の損失はありません)。

• ASP.NET 統合のない AJAX サービスを使用する場合、型ヒントは、基本/派生の割り当てがある場合にのみ生成されます。つまり、Circle が Shape または Object に割り当てられている場合に生成されますが、Circle に割り当てられている場合には生成されません。 これにより、JavaScript クライアントを正しく実装するために必要な最小限の情報が提供されるため、パフォーマンスは向上しますが、正しく設計されていないクライアントでは型情報の損失から保護されません。 クライアントでこの問題に対処しないようにする場合は、サーバー上で基本/派生の割り当てを完全に回避します。

• DataContractSerializer型を使用する場合、alwaysEmitTypeInformation コンストラクター パラメーターを使用すると、上記の 2 つのモードから選択できます。既定値は "false" です (必要な場合にのみ型ヒントを出力します)。

重複するデータ メンバー名

派生型情報は、基本型情報と共に同じ JSON オブジェクトに存在し、任意の順序で発生する可能性があります。 例えば、 Shape は次のように表され得る。

{"__type":"Shape:#MyApp.Shapes","x":50,"y":70}

一方、円は次のように表され得る。

{"__type":"Circle:#MyApp.Shapes","x":50, "radius":10,"y":70}

基本 Shape 型に "radius" というデータ メンバーも含まれている場合、シリアル化 (JSON オブジェクトにはキー名を繰り返すことができないため) と逆シリアル化 ("radius" が Shape.radius または Circle.radiusを参照しているかどうかが不明であるため) の競合が発生します。 そのため、"プロパティの非表示" (ベースクラスと派生クラスに基づく同じ名前のデータ メンバー) の概念は通常、データ コントラクト クラスでは推奨されませんが、JSON の場合は実際には禁止されています。

ポリモーフィズムと IXmlSerializable 型

IXmlSerializable 通常のデータ コントラクト ルールに従って、既知の型の要件が満たされている限り、型は通常どおりにポリモーフィックに割り当てることができます。 ただし、IXmlSerializableの代わりにObject型をシリアル化すると、結果として JSON 文字列であるため、型情報が失われます。

ポリモーフィズムと特定のインターフェイスの種類

IXmlSerializable ではないコレクション型以外の型 (IXmlSerializable を除きます) が必要な場合、コレクション型または Object を実装する型をシリアル化することは禁止されています。 たとえば、IMyInterfaceと呼ばれるカスタム インターフェイスと、MyType型とIEnumerable<T>型の両方のintを実装する型IMyInterfaceです。 戻り値の型がMyTypeされた操作からIMyInterfaceを返すことを禁止します。 これは、 MyType は JSON 配列としてシリアル化する必要があり、型ヒントが必要であるためです。前述のように、複合型でのみ、配列に型ヒントを含めることはできません。

既知の種類と構成

DataContractSerializerで使用されるすべての既知の型メカニズムは、DataContractJsonSerializerでも同じようにサポートされます。 どちらのシリアライザーも、<> で同じ構成要素<>を読み取り、構成ファイルを介して追加された既知の型を検出します。

オブジェクトに割り当てられたコレクション

Object に割り当てられたコレクションは、 IEnumerable<T>を実装するコレクションであるかのようにシリアル化されます。複合型の場合は、型ヒントを持つ各エントリを含む JSON 配列です。 例えば、型List<T>のShapeがObjectに割り当てられている場合は次のようになります。

[{"__type":"Shape:#MyApp.Shapes","x":50,"y":70},
{"__type":"Shape:#MyApp.Shapes","x":58,"y":73},
{"__type":"Shape:#MyApp.Shapes","x":41,"y":32}]

Objectに逆シリアル化された場合:

• Shape は、既知の型の一覧に含まれている必要があります。 既知の型にList<T>型のShapeがあることは影響しません。 この場合、シリアル化時に既知の型に Shape を追加する必要はありません。これは自動的に行われます。

• コレクションは、Array インスタンスを含むObject型のShapeとして逆シリアル化されます。

基本コレクションに割り当てられた派生コレクション

派生コレクションが基本コレクションに割り当てられると、通常、コレクションは基本型のコレクションであるかのようにシリアル化されます。 ただし、派生コレクションの項目の型を基本コレクションの項目の型に割り当てることができない場合は、例外がスローされます。

型ヒントとディクショナリ

ディクショナリが Objectに割り当てられると、ディクショナリ内の各キーと値のエントリは、 Object に割り当てられているかのように扱われ、型ヒントを取得します。

ディクショナリ型をシリアル化する場合、"Key" メンバーと "Value" メンバーを含む JSON オブジェクトは alwaysEmitTypeInformation 設定の影響を受けず、前述のコレクション 規則で必要な場合にのみ型ヒントが含まれます。

有効な JSON キー名

シリアライザーは、有効な XML 名ではないキー名を XML エンコードします。 たとえば、"123" という名前のデータ メンバーは、"_x0031__x0032__x0033_" などのエンコードされた名前になります。これは、"123" が無効な XML 要素名 (数字で始まる) であるためです。 一部の国際文字セットが XML 名で無効な場合も、同様の状況が発生する可能性があります。 JSON 処理に対するこの XML の影響の詳細については、「 JSON と XML の間のマッピング」を参照してください。

こちらも参照ください

• JSON およびその他のデータ転送形式のサポート