スタンドアロン JSON のシリアル化Stand-Alone JSON Serialization

JSON (JavaScript Object Notation) は、ブラウザー内の Web ページで実行される JavaScript コードで使用するために特別に設計されたデータ形式です。JSON (JavaScript Object Notation) is a data format that is specifically designed to be used by JavaScript code running on Web pages inside the browser. これは、Windows Communication Foundation (WCF) を作成する ASP.NET AJAX サービスで使用される既定のデータ形式です。It is the default data format used by ASP.NET AJAX services created in Windows Communication Foundation (WCF).

この形式は、ASP.NET と統合せずに AJAX サービスを作成する場合にも使用できます。この場合、XML が既定のデータ形式になりますが、JSON を選択することもできます。This format can also be used when creating AJAX services without integrating with ASP.NET - in this case, XML is the default but JSON can be chosen.

JSON をサポートする必要はあっても AJAX サービスを作成する予定はない場合は、DataContractJsonSerializer を使用することで、.NET オブジェクトを JSON データに直接シリアル化したり、このようなデータを .NET 型のインスタンスに逆シリアル化したりできます。Finally, if you require JSON support but are not creating an AJAX service, the DataContractJsonSerializer makes it possible to directly serialize .NET objects into JSON data and to deserialize such data back into instances of .NET types. これを行う方法については、次を参照してください。する方法: シリアル化データと JSON データの逆シリアル化です。For a description of how to do this, see How to: Serialize and Deserialize JSON Data.

JSON を使用する場合、一部例外はありますが、DataContractSerializer でサポートされているものと同じ .NET 型 がサポートされます。When working with JSON, the same .NET types are supported, with a few exceptions, as are supported by the DataContractSerializer. サポートされる型の一覧は、次を参照してください。データ コントラクト シリアライザーでサポートされる型です。For a list of the types supported, see Types Supported by the Data Contract Serializer. これには、ほとんどのプリミティブ型、ほとんどの配列型とコレクション型、DataContractAttributeDataMemberAttribute を使用する複合型などがあります。This includes most primitive types, most array and collection types, as well as complex types that use the DataContractAttribute and DataMemberAttribute.

.NET 型から JSON 型へのマッピングMapping .NET types to JSON Types

シリアル化および逆シリアル化の手順でマップされる場合の .NET 型と JSON/JavaScript 型の対応表を次に示します。The following table shows the correspondence between .NET types and JSON/JavaScript types when mapped by serialization and deserialization procedures.

.NET 型.NET Types JSON/JavaScriptJSON/JavaScript メモNotes
すべての数値型 (Int32DecimalDouble など)All numeric types, for example Int32, Decimal or Double 数値Number Double.NaNDouble.PositiveInfinityDouble.NegativeInfinity などの特殊な値はサポートされていないため、無効な JSON になります。Special values such as Double.NaN, Double.PositiveInfinity and Double.NegativeInfinity are not supported and result in invalid JSON.
Enum 数値Number このトピックの「列挙体と JSON」を参照してください。See "Enumerations and JSON" later in this topic.
Boolean ブール型Boolean --
String, CharString, Char StringString --
TimeSpanGuidUriTimeSpan, Guid, Uri StringString JSON でこれらの型の形式は XML に示すように、同じ (基本的に、ISO 8601 期間形式で TimeSpan、"12345678-ABCD-ABCD-ABCD-1234567890AB"形式の GUID と、自然な文字列形式で URI のような"http://www.example.com") です。The format of these types in JSON is the same as in XML (essentially, TimeSpan in the ISO 8601 Duration format, GUID in the "12345678-ABCD-ABCD-ABCD-1234567890AB" format and URI in its natural string form like "http://www.example.com"). 正確な情報は、次を参照してください。データ コントラクト スキーマの参照です。For precise information, see Data Contract Schema Reference.
XmlQualifiedName StringString 形式は "name:namespace" です (最初のコロンの前が名前です)。The format is "name:namespace" (anything before the first colon is the name). 名前または名前空間が存在しない場合があります。Either the name or the namespace can be missing. 名前空間がない場合、コロンも省略されることがあります。If there is no namespace the colon can be omitted as well.
Array 型の ByteArray of type Byte 数値の配列型Array of numbers 各数値は、1 バイトの値を表します。Each number represents the value of one byte.
DateTime DateTime 型または文字列型DateTime or String このトピックの「日付/時刻と JSON」を参照してください。See Dates/Times and JSON later in this topic.
DateTimeOffset 複合型Complex type このトピックの「日付/時刻と JSON」を参照してください。See Dates/Times and JSON later in this topic.
XML 型および ADO.NET 型 (XmlElementXML and ADO.NET types (XmlElement,

XElementXElement. XmlNode の配列、Arrays of XmlNode,

ISerializableISerializable,

DataSet)DataSet).
StringString このトピックの「XML 型と JSON」を参照してください。See the XML Types and JSON section of this topic.
DBNull 空の複合型Empty complex type --
コレクション、ディクショナリ、および配列Collections, dictionaries, and arrays 配列Array このトピックの「コレクション、ディクショナリ、および配列」を参照してください。See the Collections, Dictionaries, and Arrays section of this topic.
複合型 (DataContractAttribute または SerializableAttribute が適用された型)Complex types (with the DataContractAttribute or SerializableAttribute applied) 複合型Complex type データ メンバーは、JavaScript 複合型のメンバーになります。Data members become members of the JavaScript complex type.
ISerializable インターフェイスを実装する複合型Complex types implementing the ISerializable interface) 複合型Complex type 他の複合型と同じですが、一部の ISerializable 型はサポートされません。このトピックの「高度な情報」の「ISerializable のサポート」を参照してください。Same as other complex types but some ISerializable types are not supported – see the ISerializable Support part of the Advanced Information section of this topic.
任意の型の NullNull value for any type NullNull null 許容型もサポートされており、null 非許容型と同様に JSON にマップされます。Nullable types are also supported and map to JSON in the same way as non-nullable types.

列挙体と JSONEnumerations and JSON

列挙メンバー値は、JSON では数値として処理されるため、列挙メンバー値がメンバー名として含まれているデータ コントラクトでの処理方法とは異なります。Enumeration member values are treated as numbers in JSON, which is different from how they are treated in data contracts, where they are included as member names. データ コントラクトの処理方法の詳細については、次を参照してください。データ コントラクトの列挙型です。For more information about the data contract treatment, see Enumeration Types in Data Contracts.

  • たとえば、public enum Color {red, green, blue, yellow, pink} の場合、yellow をシリアル化すると、文字列の "yellow" ではなく、数字の 3 が生成されます。For example, if you have public enum Color {red, green, blue, yellow, pink}, serializing yellow produces the number 3 and not the string "yellow".

  • enum のメンバーはすべて、シリアル化できます。All enum members are serializable. EnumMemberAttribute 属性と NonSerializedAttribute 属性は、使用しても無視されます。The EnumMemberAttribute and the NonSerializedAttribute attributes are ignored if used.

  • 存在しない enum 値を逆シリアル化できます。たとえば、値 87 に対応する色の名前が定義されていなくても、この値を上記の Color 列挙値に逆シリアル化できます。It is possible to deserialize a nonexistent enum value - for example, the value 87 can be deserialized into the previous Color enum even though there is no corresponding color name defined.

  • フラグ enum は特殊ではなく、他の enum と同様に処理されます。A flags enum is not special and is treated the same as any other enum.

日付時刻 とJSONDates/Times and JSON

JSON 形式では、日付と時刻を直接サポートしていません。The JSON format does not directly support dates and times. ただし、日付と時刻は使用されることが非常に多いため、ASP.NET AJAX ではこれらの型を特別にサポートしています。However, they are very commonly used and ASP.NET AJAX provides special support for these types. ASP.NET AJAX プロキシを使用する場合、.NET の DateTime 型は JavaScript の DateTime 型に完全に対応します。When using ASP.NET AJAX proxies, the DateTime type in .NET fully corresponds to the DateTime type in JavaScript.

  • ASP.NET を使用しない場合、JSON では、DateTime 型はこのトピックの「高度な情報」で説明する特殊な形式の文字列として表されます。When not using ASP.NET, a DateTime type is represented in JSON as a string with a special format that is described in the Advanced Information section of this topic.

  • JSON では、DateTimeOffset が複合型 {"DateTime":dateTime,"OffsetMinutes":offsetMinutes} として表現されます。DateTimeOffset is represented in JSON as a complex type: {"DateTime":dateTime,"OffsetMinutes":offsetMinutes}. offsetMinutes メンバーは、当該イベントの場所に関連付けられたグリニッジ標準時 (GMT) (協定世界時 (UTC) とも呼ばれます) からの現地時刻のオフセットです。The offsetMinutes member is the local time offset from Greenwich Mean Time (GMT), also now referred to as Coordinated Universal Time (UTC), associated with the location of the event of interest. dateTime メンバーは、当該イベントが発生した時点のインスタンスを表します (この場合も、ASP.NET AJAX を使用しているときは JavaScript の DateTime になり、使用していないときは文字列になります)。The dateTime member represents the instance in time when the event of interest occurred (again, it becomes a DateTime in JavaScript when ASP.NET AJAX is in use and a string when it is not). シリアル化時には、dateTime メンバーは常に GMT でシリアル化されます。On serialization, the dateTime member is always serialized in GMT. したがって、ニューヨーク時間の午前 3 時を示す場合、dateTime の時刻コンポーネントは 8:00 AM であり、offsetMinutes は 300 (GMT マイナス 300 分 (5 時間)) です。So, if describing 3:00 AM New York time, dateTime has a time component of 8:00 AM and offsetMinutes are 300 (minus 300 minutes or 5 hours from GMT).

    注意

    DateTime オブジェクトと DateTimeOffset オブジェクトを JSON にシリアル化した場合、ミリ秒の精度までしか情報は保持されません。DateTime and DateTimeOffset objects, when serialized to JSON, only preserve information to millisecond precision. 1 ミリ秒未満の値 (マイクロ秒/ナノ秒) は、シリアル化時に失われます。Sub-millisecond values (micro/nanoseconds) are lost during serialization.

XML 型と JSONXML Types and JSON

XML 型は JSON 文字列になります。XML types become JSON strings.

  • たとえば、データ メンバー"q"の XElement の入力が含まれる場合<abc/>、JSON は {"q":"<abc/>"}。For example, if a data member "q" of type XElement contains <abc/>, the JSON is {"q":"<abc/>"}.

  • XML のラップ方法を指定する特別なルールがいくつかあります。詳細については、このトピックで後述する「高度な情報」を参照してください。There are some special rules that specify how XML is wrapped - for more information, see the Advanced Information section later in this topic.

  • ASP.NET AJAX を使用している場合に、JavaScript で文字列ではなく XML DOM を使用するときは、ResponseFormatWebGetAttribute プロパティを XML に設定するか、ResponseFormatWebInvokeAttribute プロパティを XML に設定します。If you are using ASP.NET AJAX and do not want to use strings in the JavaScript, but want the XML DOM instead, set the ResponseFormat property to XML on WebGetAttribute or the ResponseFormat property to XML on the WebInvokeAttribute.

コレクション、ディクショナリ、および配列Collections, Dictionaries and Arrays

コレクション、ディクショナリ、および配列は、JSON ではすべて配列として表されます。All collections, dictionaries, and arrays are represented in JSON as arrays.

  • CollectionDataContractAttribute を使用するカスタマイズは、JSON 表現では無視されます。Any customization that uses the CollectionDataContractAttribute is ignored in the JSON representation.

  • ディクショナリは、直接 JSON を操作する手段ではありません。Dictionaries are not a way to work directly with JSON. ディクショナリ<文字列, オブジェクト > はサポートされない WCF で同じ方法での他の JSON テクノロジの使用から予想されるようにします。Dictionary<string,object> may not be supported in the same way in WCF as expected from working with other JSON technologies. たとえば、ディクショナリで "abc" が "xyz" にマップされ、"def" が 42 にマップされている場合、JSON 表現では {"abc":"xyz","def":42} ではなく、[{"Key":"abc","Value":"xyz"},{"Key":"def","Value":42}] になります。For example, if "abc" is mapped to "xyz" and "def" is mapped to 42 in a dictionary, the JSON representation is not {"abc":"xyz","def":42} but is [{"Key":"abc","Value":"xyz"},{"Key":"def","Value":42}] instead.

  • JSON を直接使用する (厳密なコントラクトをあらかじめ定義せずに、キーと値に動的にアクセスする) 場合、いくつかのオプションがあります。If you would like to work with JSON directly (accessing keys and values dynamically, without pre-defining a rigid contract), you have several options:

    • 使用を検討して、厳密に型指定された JSON シリアル化 (AJAX)サンプルです。Consider using the Weakly-typed JSON Serialization (AJAX) sample.

    • ISerializable インターフェイスと逆シリアル化コンストラクターを使用することを検討します。この 2 つの機構を使用すると、シリアル化と逆シリアル化の実行時にそれぞれ JSON のキーと値のペアにアクセスできます。ただし、これらの機構は、部分信頼シナリオでは機能しません。Consider using the ISerializable interface and deserialization constructors - these two mechanisms allow you to access JSON key/value pairs on serialization and deserialization respectively, but do not work in partial trust scenarios.

    • 使用を検討してください、マッピングの間で JSON および XMLシリアライザーを使用する代わりにします。Consider working with the Mapping Between JSON and XML instead of using a serializer.

    • ポリモーフィズムシリアル化のコンテキストでは、基本型が必要な派生型をシリアル化する機能を参照します。Polymorphism in the context of serialization refers to the ability to serialize a derived type where its base type is expected. コレクションをポリモーフィックに使用する場合は (コレクションを Object に割り当てる場合など)、JSON 固有の特別なルールがあります。There are special JSON-specific rules when using collections polymorphically, when, for example, assigning a collection to an Object. この問題については、後の「高度な情報」で詳しく説明します。This issue is more fully discussed in the Advanced Information section later in this topic.

追加の詳細情報Additional Details

データ メンバーの順序Order of Data Members

JSON を使用する際、データ メンバーの順序は重要ではありません。Order of data members is not important when using JSON. 具体的には、Order が設定されていても、JSON データを任意の順序で逆シリアル化できます。Specifically, even if Order is set, JSON data can still be deserialized in any order.

JSON の型JSON Types

JSON の型は、逆シリアル化時には前述の表と一致する必要はありません。The JSON type does not have to match the preceding table on deserialization. たとえば、Int は通常 JSON の数値にマップされますが、JSON 文字列に有効な数値が含まれていれば、その文字列から正常に逆シリアル化することもできます。For example, an Int normally maps to a JSON number, but it can also be successfully deserialized from a JSON string as long as that string contains a valid number. つまり、"q" という Int データ メンバーが存在する場合は、{"q":42} も {"q":"42"} も有効です。That is, both {"q":42} and {"q":"42"} are valid if there is an Int data member called "q".

ポリモーフィズムPolymorphism

ポリモーフィックなシリアル化は、基本型が必要な場合に派生型をシリアル化できることで成り立ちます。Polymorphic serialization consists of the ability to serialize a derived type where its base type is expected. これはによってサポートされている JSON のシリアル化 WCF XML シリアル化がサポートされる方法に相当します。This is supported for JSON serialization by WCF comparable to the way XML serialization is supported. たとえば、シリアル化できますMyDerivedType場所MyBaseTypeはシリアル化したり、Int場所Objectが必要です。For example, you can serialize MyDerivedType where MyBaseType is expected, or serialize Int where Object is expected.

複合型を逆シリアル化する場合を除き、基本型が必要な場合に派生型を逆シリアル化すると、型情報が失われることがあります。Type information may be lost when deserializing a derived type if the base type is expected, unless you are deserializing a complex type. たとえば、Uri が必要な場合に Object をシリアル化すると、JSON 文字列になります。For example, if Uri is serialized where Object is expected, it results in a JSON string. この文字列を Object に逆シリアル化した場合、.NET の String が返されます。If this string is then deserialized back into Object, a .NET String is returned. デシリアライザーは、この文字列が最初は Uri 型であったことを認識していません。The deserializer does not know that the string was initially of type Uri. 通常、Object を必要とするときに、すべての JSON 文字列が .NET 文字列として逆シリアル化されます。また、.NET のコレクション、ディクショナリ、および配列のシリアル化に使用するすべての JSON 配列は、実際の元の型に関係なく、Array 型の .NET Object として逆シリアル化されます。Generally, when expecting Object, all JSON strings are deserialized as .NET strings, and all JSON arrays used to serialize .NET collections, dictionaries, and arrays are deserialized as .NET Array of type Object, regardless of what the actual original type had been. JSON のブール型は .NET の Boolean にマップされます。A JSON boolean maps to a .NET Boolean. ただし、Object が必要な場合、JSON の数値型は .NET の Int32Decimal、または Double の型として逆シリアル化されます。この場合、最も適切な型が自動的に選択されます。However when expecting an Object, JSON numbers are deserialized as either .NET Int32, Decimal or Double, where the most appropriate type is automatically picked.

インターフェイス型に逆シリアル化する場合、DataContractJsonSerializer は、宣言された型がオブジェクトである場合と同様に逆シリアル化します。When deserializing into an interface type, the DataContractJsonSerializer deserializes as if the declared type were object.

独自の基本型と派生型を使用している場合は、通常、KnownTypeAttributeServiceKnownTypeAttribute、または同等の機構を使用する必要があります。When working with your own base and derived types, using the KnownTypeAttribute, ServiceKnownTypeAttribute or an equivalent mechanism is normally required. 例が、操作を使用していれば、Animal値と、実際にを返しますのインスタンスを返すCat(から派生したAnimal)、いずれかを適用する必要があります、KnownTypeAttributeAnimal型またはServiceKnownTypeAttributeに操作を指定し、Catこれらの属性を入力します。For example, if you have an operation that has an Animal return value and it actually returns an instance of Cat (derived from Animal), you should either apply the KnownTypeAttribute, to the Animal type or the ServiceKnownTypeAttribute to the operation and specify the Cat type in these attributes. 詳細については、次を参照してください。データ コントラクトの既知の型です。For more information, see Data Contract Known Types.

ポリモーフィックなシリアル化のしくみの詳細、およびポリモーフィックなシリアル化を使用するときに留意する必要のある制限事項については、このトピックで後述する「高度な情報」を参照してください。For details of how polymorphic serialization works and a discussion of some of the limitations that must be respected when using it, see the Advanced Information section later in this topic.

バージョン管理Versioning

IExtensibleDataObject インターフェイスをはじめとするデータ コントラクトのバージョン管理機能は、JSON で完全にサポートされています。The data contract versioning features, including the IExtensibleDataObject interface, are fully supported in JSON. また、ほとんどの場合、ある形式 (XML など) で型を逆シリアル化した後、その型を別の形式 (JSON など) にシリアル化しても、IExtensibleDataObject にデータを保持できます。Furthermore, in most cases it is possible to deserialize a type in one format (for example, XML) and then serialize it into another format (for example, JSON) and still preserve the data in IExtensibleDataObject. 詳細については、「上位互換性のあるデータ コントラクト」を参照してください。For more information, see Forward-Compatible Data Contracts. JSON は順序なしであるため、順序情報は失われることに注意してください。Remember that JSON is unordered so any order information is lost. また、JSON では、同じキー名を持つ複数のキーと値のペアをサポートしていません。Furthermore, JSON does not support multiple key/value pairs with the same key name. IExtensibleDataObject でのすべての操作は、本質的にポリモーフィックです。つまり、派生型はすべての型の基本型である Object に割り当てられます。Finally, all operations on IExtensibleDataObject are inherently polymorphic - that is their derived type are assigned to Object, the base type for all types.

URL 内の JSONJSON in URLs

(WebGetAttribute 属性を使用して) HTTP GET 動詞と共に ASP.NET AJAX エンドポイントを使用する場合、受信パラメーターは、メッセージ本文ではなく要求 URL に配置されます。When using ASP.NET AJAX endpoints with the HTTP GET verb (using the WebGetAttribute attribute), incoming parameters appear in the request URL instead of the message body. JSON は、要求 URL であってもサポートされてように取得する操作がある場合、 Int "number"と呼ばれる、Person次の URL、URL である"p"と呼ばれる複合型のようになります。JSON is supported even in the request URL, so if you have an operation that takes an Int called "number" and a Person complex type called "p", the URL may resemble the following URL.

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

ASP.NET AJAX Script Manager コントロールとプロキシを使用してサービスを呼び出すと、この URL はプロキシによって自動的に生成されるため、確認することはできません。If you are using an ASP.NET AJAX Script Manager control and proxy to call the service, this URL is automatically generated by the proxy and is not seen. JSON は、ASP.NET AJAX エンドポイントを使用しない URL では使用できません。JSON cannot be used in URLs on non-ASP.NET AJAX endpoints.

高度な情報Advanced information

ISerializable のサポートISerializable Support

サポートされる ISerializable 型とサポートされない ISerializable 型Supported and Unsupported ISerializable Types

通常、JSON をシリアル化または逆シリアル化するときに、ISerializable インターフェイスを実装する型は完全にサポートされています。In general, types that implement the ISerializable interface are fully supported when serializing/deserializing JSON. ただし、これらの型の一部 (一部の .NET Framework 型を含みます) は、次のような JSON 固有のシリアル化の側面が原因で正しく逆シリアル化されない方法で実装されています。However, some of these types (including some .NET Framework types) are implemented in such a way that the JSON-specific serialization aspects cause them to not deserialize correctly:

  • ISerializable では、個々のデータ メンバーの型は事前にはわかりません。With ISerializable, the type of individual data members is never known in advance. このため、型をオブジェクトに逆シリアル化する場合と同様のポリモーフィックな状況になります。This leads to a polymorphic situation similar to deserializing types into an object. 前述のように、これは JSON で型情報が失われる原因となる場合があります。As mentioned before, this may lead to loss of type information in JSON. たとえば、enum 実装で ISerializable をシリアル化した型を (適切にキャストせずに) enum に直接逆シリアル化しようとした場合、逆シリアル化は失敗します。これは、enum は JSON の数値型を使用してシリアル化されますが、JSON の数値型は .NET の組み込みの数値型 (Int32、Decimal、または Double) に逆シリアル化されるためです。For example, a type that serializes an enum in its ISerializable implementation and attempts to deserialize back directly into an enum (without proper casts) fails, because an enum is serialized using numbers in JSON and JSON numbers deserialize into built-in .NET numeric types (Int32, Decimal or Double). そのため、この数値が enum 値を表すために使用されているという情報が失われます。So the fact that the number used to be an enum value is lost.

  • ISerializable 型が逆シリアル化コンストラクターで特定の順序の逆シリアル化に依存する場合も、一部の JSON データの逆シリアル化に失敗する場合があります。これは、ほとんどの JSON シリアライザーが特定の順序を保証しないためです。An ISerializable type that depends on a particular order of deserialization in its deserialization constructor may also fail to deserialize some JSON data, because most JSON serializers do not guarantee any specific order.

ファクトリ型Factory Types

IObjectReference インターフェイスは JSON で一般にサポートされますが、"ファクトリ型" 機能 (GetRealObject(StreamingContext) から、このインターフェイスを実装する型とは異なる型のインスタンスを返す機能) を必要とする型はサポートされません。While the IObjectReference interface is supported in JSON in general, any types that require the "factory type" feature (returning an instance of a different type from GetRealObject(StreamingContext) than the type that implements the interface) are not supported.

DateTime ワイヤ形式DateTime Wire Format

DateTime 値は、"/Date(700000+0500)/" 形式の JSON 文字列として表されます。ここで、最初の数値 (この例では 700000) は GMT タイム ゾーンのミリ秒数であり、1970 年 1 月 1 日午前 0 時以降の (夏時間ではなく) 通常時間です。DateTime values appear as JSON strings in the form of "/Date(700000+0500)/", where the first number (700000 in the example provided) is the number of milliseconds in the GMT time zone, regular (non-daylight savings) time since midnight, January 1, 1970. これより前の時間を表すために、この数値が負の値になる場合があります。The number may be negative to represent earlier times. この例の "+0500" で構成される部分は省略可能であり、Local の時刻を示します。つまり、逆シリアル化時にローカル タイム ゾーンに変換される必要があります。The part that consists of "+0500" in the example is optional and indicates that the time is of the Local kind - that is, should be converted to the local time zone on deserialization. この部分が指定されていない場合、時刻は Utc として逆シリアル化されます。If it is absent, the time is deserialized as Utc. 実際の数値 (この例では "0500") と記号 (+ または -) は無視されます。The actual number ("0500" in this example) and its sign (+ or -) are ignored.

DateTime をシリアル化すると、LocalUnspecified の時刻はオフセットして書き込まれ、Utc はオフセットせずに書き込まれます。When serializing DateTime, Local and Unspecified times are written with an offset, and Utc is written without.

ASP.NET AJAX クライアントの JavaScript コードにより、このような文字列は JavaScript の DateTime インスタンスに自動的に変換されます。The ASP.NET AJAX client JavaScript code automatically converts such strings into JavaScript DateTime instances. 類似する形式で .NET の DateTime 型ではない他の文字列が存在する場合、これらの文字列も変換されます。If there are other strings that have a similar form that are not of type DateTime in .NET, they are converted as well.

変換の場合は、「/」文字はエスケープだけ行わ (は、次の JSON のように"\/Date(700000+0500)\/")、およびこの理由 WCF の JSON エンコーダー (で有効になって、 WebHttpBinding) 常に「/」文字をエスケープします。The conversion only takes place if the "/" characters are escaped (that is, the JSON looks like "\/Date(700000+0500)\/"), and for this reason WCF's JSON encoder (enabled by the WebHttpBinding) always escapes the "/" character.

JSON 文字列内の XMLXML in JSON Strings

XmlElementXmlElement

XmlElement は、ラップされずにそのままの状態でシリアル化されます。XmlElement is serialized as is, with no wrapping. たとえば、データ メンバー"x"の種類のXmlElementを格納している<abc/> は、次のように表されるようにします。For example, data member "x" of type XmlElement that contains <abc/> is as represented as follows.

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

XmlNode の配列Arrays of XmlNode

Array 型の XmlNode オブジェクトは、この型の標準のデータ コントラクト名前空間にある ArrayOfXmlNode という要素にラップされます。Array objects of type XmlNode are wrapped in an element called ArrayOfXmlNode in the standard data contract namespace for the type. "x" が、"value" と空の要素ノード "M" を含む名前空間 "ns" にある、属性ノード "N" を含む配列である場合、次のように表されます。If "x" is an array that contains attribute node "N" in namespace "ns" that contains "value" and an empty element node "M", the representation is as follows.

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

XmlNode 配列の先頭 (他の要素の前) にある空の名前空間の属性はサポートされません。Attributes in the empty namespace at the beginning of XmlNode arrays (before other elements) are unsupported.

XElement と DataSet を含む IXmlSerializable 型IXmlSerializable Types including XElement and DataSet

ISerializable 型は、"コンテンツ型"、"DataSet 型"、および "要素型" に細分化されます。ISerializable types subdivide into "content types", "DataSet types" and "element types". これらの型の定義は、次を参照してください。 XML および ADO.NET データ コントラクトの種類です。For definitions of these types, see XML and ADO.NET Types in Data Contracts.

"コンテンツ" 型と "DataSet" 型は、前のセクションで説明した ArrayXmlNode オブジェクトと同様にシリアル化されます。"Content" and "DataSet" types are serialized similar to Array objects of XmlNode discussed in the previous section. これらの型は、その型のデータ コントラクトの名前と名前空間に対応する名前と名前空間を持つ要素にラップされます。They are wrapped in an element whose name and namespace corresponds to the data contract name and namespace of the type in question.

XElement などの "要素" 型は、このトピックで既に説明した XmlElement と同様に、そのままの状態でシリアル化されます。"Element" types such as XElement are serialized as is, similar to XmlElement previously discussed in this topic.

ポリモーフィズムPolymorphism

型情報の保持Preserving Type Information

前述のように、ポリモーフィズムは JSON でサポートされていますが、いくつかの制限があります。As stated earlier, polymorphism is supported in JSON with some limitations. JavaScript は厳密に型指定されていない言語であるため、通常、型 ID は問題ではありません。JavaScript is a weakly-typed language and type identity is normally not an issue. ただし、JSON を使用して厳密に型指定されたシステム (.NET) と厳密に型指定されていないシステム (JavaScript) 間で通信する場合、型 ID を保持していると役立ちます。However, when using JSON to communicate between a strongly-typed system (.NET) and a weakly-typed system (JavaScript), it is useful to preserve type identity. たとえば、"Square" と "Circle" というデータ コントラクト名を持つ型が "Shape" というデータ コントラクト名を持つ型から派生したとします。For example, types with data contract names "Square" and "Circle" derive from a type with a data contract name of "Shape". "Circle" が .NET から JavaScript に送信され、後で "Shape" を必要とする .NET メソッドに返された場合、該当のオブジェクトが本来は "Circle" であったことが .NET 側でわかれば役立ちます。そうでない場合、派生型に固有の情報 ("Circle" のデータ メンバー "radius" など) が失われることがあります。If "Circle" is sent from .NET to JavaScript and is later returned to a .NET method that expects "Shape", it is useful for the .NET side to know that the object in question was originally a "Circle" - otherwise any information specific to the derived type (for example, "radius" data member on "Circle") may be lost.

型 ID を保持するために、複合型を JSON にシリアル化するときに "型ヒント" を追加できます。デシリアライザーはこのヒントを認識し、適切に動作します。To preserve type identity, when serializing complex types to JSON a "type hint" can be added, and the deserializer recognizes the hint and acts appropriately. "型ヒント" は、JSON のキーと値のペアです。キー名は "__type" です (2 つのアンダースコアの後に "type" という語が続きます)。The "type hint" is a JSON key/value pair with the key name of "__type" (two underscores followed by the word "type"). 値は、"DataContractName:DataContractNamespace" 形式の JSON 文字列です (最初のコロンまでが名前です)。The value is a JSON string of the form "DataContractName:DataContractNamespace" (anything up to the first colon is the name). 前述の例の "Circle" は、次のようにシリアル化できます。Using the earlier example, "Circle" can be serialized as follows.

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

型ヒントは、XML スキーマ インスタンス標準で定義された xsi:type 属性によく似ており、XML をシリアル化または逆シリアル化するときに使用されます。The type hint is very similar to the xsi:type attribute defined by the XML Schema Instance standard and used when serializing/deserializing XML.

"__type" というデータ メンバーは、型ヒントと競合する可能性があるため、禁止されています。Data members called "__type" are forbidden due to potential conflict with the type hint.

型ヒントのサイズの削減Reducing the Size of Type Hints

JSON のサイズを減らすためにメッセージを既定のデータ コントラクト名前空間プレフィックス (http://schemas.datacontract.org/2004/07/) 「#」文字に置き換えられます。To reduce the size of JSON messages, the default data contract namespace prefix (http://schemas.datacontract.org/2004/07/) is replaced with the "#" character. (この置換を元に戻すことにするには、エスケープの規則を使用: 名前空間が「#」で始まる場合または"\"文字は余分なを付加して、"\"文字)。(To make this replacement reversible, an escaping rule is used: if the namespace starts with the "#" or "\" characters, they are appended with an extra "\" character). したがって、"Circle"が"MyApp.Shapes"の .NET 名前空間内の型の場合は、既定のデータ コントラクト名前空間がhttp://schemas.datacontract.org/2004/07/MyAppです。Thus, if "Circle" is a type in the .NET namespace "MyApp.Shapes", its default data contract namespace is http://schemas.datacontract.org/2004/07/MyApp. 形状と JSON 表現は次のようになります。Shapes and the JSON representation is as follows.

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

切り捨てられた (#MyApp.Shapes) と完全の両方 (http://schemas.datacontract.org/2004/07/MyApp.Shapes)逆シリアル化の名前が認識されます。Both the truncated (#MyApp.Shapes) and the full (http://schemas.datacontract.org/2004/07/MyApp.Shapes) names is understood on deserialization.

JSON オブジェクト内での型ヒントの位置Type Hint Position in JSON Objects

JSON 表現では、型ヒントは最初に出現する必要があります。Note that the type hint must appear first in the JSON representation. JSON の処理でキーと値のペアの順序が重要となるのはこの場合だけです。This is the only case where order of key/value pairs is important in JSON processing. たとえば、型ヒントの次の指定方法は無効です。For example, the following is not a valid way to specify the type hint.

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

両方のDataContractJsonSerializerWCF と ASP.NET AJAX で使用されるクライアント ページ常に生成、型ヒント最初。Both the DataContractJsonSerializer used by WCF and ASP.NET AJAX client pages always emit the type hint first.

複合型にのみ適用される型ヒントType Hints Apply Only to Complex Types

複合型以外の型の型ヒントを出力する方法はありません。There is no way to emit a type hint for non-complex types. たとえば、戻り値の型が Object である操作で Circle を返す場合、前に示したような JSON 表現が可能であり、型情報は保持されます。For example, if an operation has an Object return type but returns a Circle, the JSON representation can be as shown earlier and the type information is preserved. ただし、Uri が返される場合、JSON 表現は文字列であり、この文字列が Uri を表すために使用されているという情報は失われます。However, if Uri is returned, the JSON representation is a string and the fact that the string used to represent a Uri is lost. これは、プリミティブ型だけでなく、コレクションと配列にも適用されます。This applies not only to primitive types but also to collections and arrays.

型ヒントが出力される状況When Are Type Hints Emitted

型ヒントにより、メッセージ サイズが大幅に増加することがあります (これを軽減する 1 つの方法として、可能であれば短いデータ コントラクト名前空間を使用します)。Type hints may increase message size significantly (one way to mitigate this is to use shorter data contract namespaces if possible). そのため、次のルールによって型ヒントを出力するかどうかが制御されます。Therefore, the following rules govern whether type hints are emitted:

  • ASP.NET AJAX を使用する場合、基本型と派生型の割り当てが存在しない場合でも (Circle を Circle に割り当てる場合など)、型ヒントは可能である限り常に出力されます When using ASP.NET AJAX, type hints are always emitted whenever possible, even if there is no base/derived assignment - for example, even if a Circle is assigned to a Circle. (これは、厳密に型指定されていない JSON 環境から厳密に型指定された .NET 環境への呼び出しプロセスにおいて、情報が予想外に失われることのないプロセスを完全に実現するために必要です)。(This is required to fully enable the process of calling from the weakly-typed JSON environment into the strongly-typed .NET environment with no surprising loss of information.)

  • ASP.NET と統合せずに AJAX サービスを使用する場合、基本型と派生型の割り当てが存在する場合にのみ、型ヒントが出力されます。つまり、Circle を Shape または Object に割り当てるときは出力されますが、Circle に割り当てるときには出力されません。When using AJAX services with no ASP.NET integration, type hints are only emitted when there is a base/derived assignment - that is, emitted when Circle is assigned to Shape or Object but not when assigned to Circle. この場合、JavaScript クライアントを適切に実装するために必要な最小限の情報しか提供されないため、パフォーマンスは向上しますが、適切に設計されていないクライアントでの型情報の損失を防ぐことはできません。This provides the minimum information required to correctly implement a JavaScript client, thus improving performance, but does not protect against type information loss in incorrectly-designed clients. クライアントでこの問題に対処することを避ける必要がある場合は、サーバーで基本型と派生型の割り当てを一切行わないようにします。Avoid base/derived assignments altogether on the server if you want to avoid dealing with this issue on the client.

  • DataContractSerializer 型を使用する場合、alwaysEmitTypeInformation コンストラクター パラメーターを使用すると、上記の 2 つのモードのいずれかを選択できます。既定値は "false" (必要な場合にのみ型情報を出力) です。When using the DataContractSerializer type, the alwaysEmitTypeInformation constructor parameter allows you to choose between the preceding two modes, with the default being "false" (only emit type hints when required).

重複するデータ メンバー名Duplicate Data Member Names

派生型情報は、基本型情報と共に同じ JSON オブジェクト内に存在しますが、任意の順序で出現する場合があります。Derived type information is present in the same JSON object together with base type information, and can occur in any order. たとえば、Shape次のように表すことができます。For example, Shape may be represented as follows.

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

Circle は、次のように表されることがあります。Whereas Circle may be represented as follows.

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

場合、ベースShape型も含まれるというデータ メンバー"radius"、それによって、競合するへの両方のシリアル化 (ため、JSON オブジェクトのキー名を繰り返すことはできません) および (を"radius"が参照するかどうか明確ではないために逆シリアル化Shape.radiusまたはCircle.radius)。If the base Shape type also contained a data member called "radius", this leads to a collision on both serialization (because JSON objects cannot have repeating key names) and deserialization (because it is unclear whether "radius" refers to Shape.radius or Circle.radius). そのため、データ コントラクト クラスでは、"プロパティの隠ぺい" (基本クラスと派生クラスに同じ名前のデータ メンバーが存在する) という概念は一般に推奨されていませんが、JSON では実際には禁止されています。Therefore, while the concept of "property hiding" (data members of the same name on based and derived classes) is generally not recommended in data contract classes, it is actually forbidden in the case of JSON.

ポリモーフィズムと IXmlSerializable 型Polymorphism and IXmlSerializable Types

IXmlSerializable 型は、既知の型の要件を満たしている限り、通常のデータ コントラクト規則に従って、通常どおり相互にポリモーフィックな割り当てを行うことができます。IXmlSerializable types may be polymorphically assigned to each other as usual as long as Known Types requirements are met, according to usual data contract rules. ただし、IXmlSerializable の代わりに Object 型をシリアル化すると、結果が JSON 文字列になるため、型情報が失われることになります。However, serializing an IXmlSerializable type in place of Object results in loss of type information as the result is a JSON string.

ポリモーフィズムと一部のインターフェイス型Polymorphism and Certain Interface Types

IXmlSerializable ではないコレクション型以外の型 (IXmlSerializable を除きます) が必要な場合、コレクション型または Object を実装する型をシリアル化することは禁止されています。It is forbidden to serialize a collection type or a type that implements IXmlSerializable where a non-collection type that is not IXmlSerializable (except for Object) is expected. たとえば、カスタム インターフェイスと呼ばれるIMyInterfaceと型MyType両方を実装しているIEnumerable<T>型のintIMyInterfaceです。For example, a custom interface called IMyInterface and a type MyType that implement both IEnumerable<T> of type int and IMyInterface. 返すことは禁止されていますMyType戻り値の型は、操作からIMyInterfaceです。It is forbidden to return MyType from an operation whose return type is IMyInterface. これは、ためMyTypeを JSON 配列としてシリアル化する必要がありますと、型ヒントが必要ですし、前述のように、配列、複合型でのみ、型ヒントを含めることはできません。This is because MyType must be serialized as a JSON array and requires a type hint, and as stated before you cannot include a type hint with arrays, only with complex types.

既知の型と構成Known Types and Configuration

DataContractSerializer が使用する既知の型機構は、DataContractJsonSerializer の場合と同様にすべてサポートされます。All of the Known Type mechanisms used by the DataContractSerializer are also supported in the same way by the DataContractJsonSerializer. 両方のシリアライザーは、同じ構成要素を読み取る <dataContractSerializer > <system.runtime.serialization >、追加の既知の型を検出するには構成ファイル。Both serializers read the same configuration element, <dataContractSerializer> in <system.runtime.serialization>, to discover known types added through a configuration file.

Object に割り当てられたコレクションCollections Assigned to Object

Object に割り当てられたコレクションは、IEnumerable<T> を実装するコレクションと同様にシリアル化されます。複合型の場合は、各エントリに型ヒントが含まれた JSON 配列になります。Collections assigned to Object are serialized as if they are collections that implement IEnumerable<T>: a JSON array with each entry that has a type hint if it is a complex type. たとえば、List<T>型のShapeに割り当てられているObject次のようになります。For example, a List<T> of type Shape assigned to Object looks like the following.

[{"__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 に逆シリアル化するときは、次の点に注意してください。When deserialized back into Object:

  • Shape 既知の型リストにする必要があります。Shape must be in the Known Types list. 持つList<T>型のShape既知の型に影響を与えません。Having List<T> of type Shape in known types has no effect. 追加する必要はありませんShapeシリアル化時に既知の型にこの例では、この自動的に行われます。Note that you do not have to add Shape to known types on serialization in this case - this is done automatically.

  • コレクションとして逆シリアル化、Array型のObjectを格納しているShapeインスタンス。The collection is deserialized as an Array of type Object that contains Shape instances.

基本コレクションに割り当てられた派生コレクションDerived Collections Assigned to Base Collections

派生コレクションを基本コレクションに割り当てると、通常、そのコレクションは基本型のコレクションと同様にシリアル化されます。When a derived collection is assigned to a base collection, the collection is usually serialized as if it was a collection of the base type. ただし、派生コレクションの項目の型を基本コレクションの項目の型に割り当てることができない場合は、例外がスローされます。However, if the item type of the derived collection cannot be assigned to the item type of the base collection, an exception is thrown.

型ヒントとディクショナリType Hints and Dictionaries

ディクショナリを Object に割り当てると、ディクショナリに含まれる Key および Value の各エントリは、Object に割り当てられている場合と同様に処理され、型ヒントを取得します。When a dictionary is assigned to an Object, each Key and Value entry in the dictionary is treated as if it was assigned to Object and gets a type hint.

ディクショナリ型をシリアル化した場合、"Key" メンバーと "Value" メンバーを含む JSON オブジェクトは、alwaysEmitTypeInformation 設定の影響を受けません。オブジェクトに型ヒントが含まれるのは、前述のコレクション ルールで必要とされる場合だけです。When serializing dictionary types, the JSON object that contains the "Key" and "Value" members is unaffected by the alwaysEmitTypeInformation setting and only contains a type hint when the preceding collection rules require it.

JSON の有効なキー名Valid JSON Key Names

シリアライザーは、無効な XML 名のキー名を XML エンコードします。The serializer XML-encodes key names that are not valid XML names. たとえば、「123」の名前を持つデータ メンバーには、エンコードされた名前がなど"x0031__x0032__x0033\"「123」は無効な XML 要素名 (数字で開始) であるためです。For example, a data member with the name of "123" would have an encoded name such as "x0031__x0032__x0033\" because "123" is an invalid XML element name (starts with a digit). XML 名が有効ではない一部の国際文字セットでも、同様の状況が発生する場合があります。A similar situation may arise with some international character sets not valid in XML names. この JSON の処理での XML の影響の詳細については、次を参照してください。マッピングの間で JSON および XMLです。For an explanation of this effect of XML on JSON processing, see Mapping Between JSON and XML.

関連項目See Also

JSON などのデータ転送形式のサポートSupport for JSON and Other Data Transfer Formats