[要約] RFC 7049は、CBOR（Concise Binary Object Representation）の仕様を定義しており、データの効率的なバイナリ表現を提供することを目的としています。CBORは、JSONの拡張として設計されており、データのサイズを削減しながら相互運用性を確保します。
Internet Engineering Task Force (IETF) C. Bormann
Request for Comments: 7049 Universitaet Bremen TZI
Category: Standards Track P. Hoffman
ISSN: 2070-1721 VPN Consortium
October 2013
Concise Binary Object Representation (CBOR)
簡潔なバイナリオブジェクト表現（CBOR）
Abstract
概要
The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.
簡潔なバイナリオブジェクト表現（CBOR）は、非常に小さいコードサイズ、かなり小さいメッセージサイズ、およびバージョンネゴシエーションを必要としない拡張性の可能性を設計目標に含むデータ形式です。これらの設計目標は、ASN.1やMessagePackなどの以前のバイナリシリアル化とは異なります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7049.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7049で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Objectives . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Specification of the CBOR Encoding . . . . . . . . . . . . . 6
2.1. Major Types . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Indefinite Lengths for Some Major Types . . . . . . . . . 9
2.2.1. Indefinite-Length Arrays and Maps . . . . . . . . . . 9
2.2.2. Indefinite-Length Byte Strings and Text Strings . . . 11
2.3. Floating-Point Numbers and Values with No Content . . . . 12
2.4. Optional Tagging of Items . . . . . . . . . . . . . . . . 14
2.4.1. Date and Time . . . . . . . . . . . . . . . . . . . . 16
2.4.2. Bignums . . . . . . . . . . . . . . . . . . . . . . . 16
2.4.3. Decimal Fractions and Bigfloats . . . . . . . . . . . 17
2.4.4. Content Hints . . . . . . . . . . . . . . . . . . . . 18
2.4.4.1. Encoded CBOR Data Item . . . . . . . . . . . . . 18
2.4.4.2. Expected Later Encoding for CBOR-to-JSON
Converters . . . . . . . . . . . . . . . . . . . 18
2.4.4.3. Encoded Text . . . . . . . . . . . . . . . . . . 19
2.4.5. Self-Describe CBOR . . . . . . . . . . . . . . . . . 19
3. Creating CBOR-Based Protocols . . . . . . . . . . . . . . . . 20
3.1. CBOR in Streaming Applications . . . . . . . . . . . . . 20
3.2. Generic Encoders and Decoders . . . . . . . . . . . . . . 21
3.3. Syntax Errors . . . . . . . . . . . . . . . . . . . . . . 21
3.3.1. Incomplete CBOR Data Items . . . . . . . . . . . . . 22
3.3.2. Malformed Indefinite-Length Items . . . . . . . . . . 22
3.3.3. Unknown Additional Information Values . . . . . . . . 23
3.4. Other Decoding Errors . . . . . . . . . . . . . . . . . . 23
3.5. Handling Unknown Simple Values and Tags . . . . . . . . . 24
3.6. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.7. Specifying Keys for Maps . . . . . . . . . . . . . . . . 25
3.8. Undefined Values . . . . . . . . . . . . . . . . . . . . 26
3.9. Canonical CBOR . . . . . . . . . . . . . . . . . . . . . 26
3.10. Strict Mode . . . . . . . . . . . . . . . . . . . . . . . 28
4. Converting Data between CBOR and JSON . . . . . . . . . . . . 29
4.1. Converting from CBOR to JSON . . . . . . . . . . . . . . 29
4.2. Converting from JSON to CBOR . . . . . . . . . . . . . . 30
5. Future Evolution of CBOR . . . . . . . . . . . . . . . . . . 31
5.1. Extension Points . . . . . . . . . . . . . . . . . . . . 32
5.2. Curating the Additional Information Space . . . . . . . . 33
6. Diagnostic Notation . . . . . . . . . . . . . . . . . . . . . 33
6.1. Encoding Indicators . . . . . . . . . . . . . . . . . . . 34
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
7.1. Simple Values Registry . . . . . . . . . . . . . . . . . 35
7.2. Tags Registry . . . . . . . . . . . . . . . . . . . . . . 35
7.3. Media Type ("MIME Type") . . . . . . . . . . . . . . . . 36
7.4. CoAP Content-Format . . . . . . . . . . . . . . . . . . . 37
7.5. The +cbor Structured Syntax Suffix Registration . . . . . 37
8. Security Considerations . . . . . . . . . . . . . . . . . . . 38
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Normative References . . . . . . . . . . . . . . . . . . 39
10.2. Informative References . . . . . . . . . . . . . . . . . 40
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 41
Appendix B. Jump Table . . . . . . . . . . . . . . . . . . . . . 45
Appendix C. Pseudocode . . . . . . . . . . . . . . . . . . . . . 48
Appendix D. Half-Precision . . . . . . . . . . . . . . . . . . . 50
Appendix E. Comparison of Other Binary Formats to CBOR's Design
Objectives . . . . . . . . . . . . . . . . . . . . . 51
E.1. ASN.1 DER, BER, and PER . . . . . . . . . . . . . . . . . 52
E.2. MessagePack . . . . . . . . . . . . . . . . . . . . . . . 52
E.3. BSON . . . . . . . . . . . . . . . . . . . . . . . . . . 53
E.4. UBJSON . . . . . . . . . . . . . . . . . . . . . . . . . 53
E.5. MSDTP: RFC 713 . . . . . . . . . . . . . . . . . . . . . 53
E.6. Conciseness on the Wire . . . . . . . . . . . . . . . . . 53
There are hundreds of standardized formats for binary representation of structured data (also known as binary serialization formats). Of those, some are for specific domains of information, while others are generalized for arbitrary data. In the IETF, probably the best-known formats in the latter category are ASN.1's BER and DER [ASN.1].
構造化データのバイナリ表現には、何百もの標準化された形式（バイナリシリアル化形式とも呼ばれます）があります。それらのいくつかは、特定の情報ドメイン用であり、その他は任意のデータ用に一般化されています。 IETFでは、おそらく後者のカテゴリーで最もよく知られているフォーマットは、ASN.1のBERおよびDER [ASN.1]です。
The format defined here follows some specific design goals that are not well met by current formats. The underlying data model is an extended version of the JSON data model [RFC4627]. It is important to note that this is not a proposal that the grammar in RFC 4627 be extended in general, since doing so would cause a significant backwards incompatibility with already deployed JSON documents. Instead, this document simply defines its own data model that starts from JSON.
ここで定義されているフォーマットは、現在のフォーマットでは十分に満たされない特定の設計目標に従っています。基礎となるデータモデルは、JSONデータモデル[RFC4627]の拡張バージョンです。これは、RFC 4627の文法を一般に拡張するという提案ではないことに注意してください。拡張すると、すでにデプロイされているJSONドキュメントとの後方互換性が大幅に低下するためです。代わりに、このドキュメントでは、JSONから始まる独自のデータモデルを定義しています。
Appendix E lists some existing binary formats and discusses how well they do or do not fit the design objectives of the Concise Binary Object Representation (CBOR).
付録Eでは、いくつかの既存のバイナリ形式をリストし、それらが簡潔なバイナリオブジェクト表現（CBOR）の設計目標にどの程度うまく適合していないかを説明します。
The objectives of CBOR, roughly in decreasing order of importance, are:
CBORの目的は、おおよそ重要度の高い順に、次のとおりです。
1. The representation must be able to unambiguously encode most common data formats used in Internet standards.
1. 表現は、インターネット標準で使用される最も一般的なデータ形式を明確にエンコードできる必要があります。
* It must represent a reasonable set of basic data types and structures using binary encoding. "Reasonable" here is largely influenced by the capabilities of JSON, with the major addition of binary byte strings. The structures supported are limited to arrays and trees; loops and lattice-style graphs are not supported.
* バイナリエンコーディングを使用して、基本的なデータタイプと構造の合理的なセットを表す必要があります。ここで「リーズナブル」は、JSONの機能に大きく影響され、バイナリバイト文字列が大幅に追加されています。サポートされる構造は、配列とツリーに制限されています。ループとラティススタイルのグラフはサポートされていません。
* There is no requirement that all data formats be uniquely encoded; that is, it is acceptable that the number "7" might be encoded in multiple different ways.
* すべてのデータ形式を一意にエンコードする必要はありません。つまり、数値「7」が複数の異なる方法でエンコードされている可能性があります。
2. The code for an encoder or decoder must be able to be compact in order to support systems with very limited memory, processor power, and instruction sets.
2. メモリ、プロセッサ能力、および命令セットが非常に限られているシステムをサポートするには、エンコーダまたはデコーダのコードをコンパクトにする必要があります。
* An encoder and a decoder need to be implementable in a very small amount of code (for example, in class 1 constrained nodes as defined in [CNN-TERMS]).
* エンコーダーとデコーダーは非常に少量のコードで実装できる必要があります（たとえば、[CNN-TERMS]で定義されているクラス1制約付きノードで）。
* The format should use contemporary machine representations of data (for example, not requiring binary-to-decimal conversion).
* 形式は、データの最新の機械表現を使用する必要があります（たとえば、2進数から10進数への変換は必要ありません）。
3. Data must be able to be decoded without a schema description.
3. データは、スキーマの説明なしでデコードできる必要があります。
* Similar to JSON, encoded data should be self-describing so that a generic decoder can be written.
* JSONと同様に、エンコードされたデータは自己記述的である必要があり、汎用のデコーダーを作成できます。
4. The serialization must be reasonably compact, but data compactness is secondary to code compactness for the encoder and decoder.
4. シリアル化は適度にコンパクトでなければなりませんが、データのコンパクト性は、エンコーダーとデコーダーのコードのコンパクト性に次ぐものです。
* "Reasonable" here is bounded by JSON as an upper bound in size, and by implementation complexity maintaining a lower bound. Using either general compression schemes or extensive bit-fiddling violates the complexity goals.
* ここで「合理的」とは、サイズの上限としてJSONと、下限を維持する実装の複雑さによって制限されます。一般的な圧縮方式または広範なビット操作のいずれかを使用すると、複雑さの目標に違反します。
5. The format must be applicable to both constrained nodes and high-volume applications.
5. この形式は、制約されたノードと大量のアプリケーションの両方に適用できる必要があります。
* This means it must be reasonably frugal in CPU usage for both encoding and decoding. This is relevant both for constrained nodes and for potential usage in applications with a very high volume of data.
* これは、エンコーディングとデコーディングの両方で、CPU使用量がかなり質素でなければならないことを意味します。これは、制約されたノードと、非常に大量のデータを使用するアプリケーションでの潜在的な使用の両方に関連しています。
6. The format must support all JSON data types for conversion to and from JSON.
6. この形式は、JSONとの間の変換ですべてのJSONデータ型をサポートする必要があります。
* It must support a reasonable level of conversion as long as the data represented is within the capabilities of JSON. It must be possible to define a unidirectional mapping towards JSON for all types of data.
* 表現されるデータがJSONの機能の範囲内である限り、妥当なレベルの変換をサポートする必要があります。すべてのタイプのデータについて、JSONへの単方向マッピングを定義できる必要があります。
7. The format must be extensible, and the extended data must be decodable by earlier decoders.
7. フォーマットは拡張可能である必要があり、拡張データは以前のデコーダでデコード可能でなければなりません。
* The format is designed for decades of use.
* このフォーマットは、何十年も使用できるように設計されています。
* The format must support a form of extensibility that allows fallback so that a decoder that does not understand an extension can still decode the message.
* この形式は、拡張機能を理解しないデコーダでもメッセージをデコードできるように、フォールバックを可能にする拡張性の形式をサポートする必要があります。
* The format must be able to be extended in the future by later IETF standards.
* この形式は、将来のIETF標準によって将来拡張できる必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119, BCP 14 [RFC2119] and indicate requirement levels for compliant CBOR implementations.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119、BCP 14 [RFC2119]で説明されているように解釈され、準拠CBOR実装の要件レベルを示します。
The term "byte" is used in its now-customary sense as a synonym for "octet". All multi-byte values are encoded in network byte order (that is, most significant byte first, also known as "big-endian").
「バイト」という用語は、今では慣習的な意味で「オクテット」の同義語として使用されています。すべてのマルチバイト値は、ネットワークバイトオーダーでエンコードされます（つまり、最上位バイトが最初、「ビッグエンディアン」とも呼ばれます）。
This specification makes use of the following terminology:
この仕様では、次の用語を使用しています。
Data item: A single piece of CBOR data. The structure of a data item may contain zero, one, or more nested data items. The term is used both for the data item in representation format and for the abstract idea that can be derived from that by a decoder.
データ項目：1つのCBORデータ。データ項目の構造には、0個、1個、またはそれ以上のネストされたデータ項目が含まれる場合があります。この用語は、表現形式のデータ項目と、デコーダーからそれから導出できる抽象的なアイデアの両方に使用されます。
Decoder: A process that decodes a CBOR data item and makes it available to an application. Formally speaking, a decoder contains a parser to break up the input using the syntax rules of CBOR, as well as a semantic processor to prepare the data in a form suitable to the application.
デコーダー：CBORデータ項目をデコードし、アプリケーションで使用できるようにするプロセス。正式には、デコーダーには、CBORの構文規則を使用して入力を分割するパーサーと、アプリケーションに適した形式でデータを準備するセマンティックプロセッサが含まれています。
Encoder: A process that generates the representation format of a CBOR data item from application information.
エンコーダー：アプリケーション情報からCBORデータ項目の表現形式を生成するプロセス。
Data Stream: A sequence of zero or more data items, not further assembled into a larger containing data item. The independent data items that make up a data stream are sometimes also referred to as "top-level data items".
データストリーム：ゼロ以上のデータ項目のシーケンス。さらに大きなデータ項目に組み立てられません。データストリームを構成する独立したデータ項目は、「トップレベルのデータ項目」と呼ばれることもあります。
Well-formed: A data item that follows the syntactic structure of CBOR. A well-formed data item uses the initial bytes and the byte strings and/or data items that are implied by their values as defined in CBOR and is not followed by extraneous data.
整形式：CBORの構文構造に従うデータ項目。整形式のデータ項目は、CBORで定義された値によって暗黙的に示され、その後に無関係のデータが続かない初期バイトおよびバイト文字列やデータ項目を使用します。
Valid: A data item that is well-formed and also follows the semantic restrictions that apply to CBOR data items.
有効：整形式であり、CBORデータ項目に適用される意味上の制限にも従うデータ項目。
Stream decoder: A process that decodes a data stream and makes each of the data items in the sequence available to an application as they are received.
ストリームデコーダー：データストリームをデコードし、シーケンス内の各データ項目を受信したときにアプリケーションで使用できるようにするプロセス。
Where bit arithmetic or data types are explained, this document uses the notation familiar from the programming language C, except that "**" denotes exponentiation. Similar to the "0x" notation for hexadecimal numbers, numbers in binary notation are prefixed with "0b". Underscores can be added to such a number solely for readability, so 0b00100001 (0x21) might be written 0b001_00001 to emphasize the desired interpretation of the bits in the byte; in this case, it is split into three bits and five bits.
ビット演算またはデータ型が説明されている場合、このドキュメントでは、プログラミング言語Cでよく知られている表記法を使用しています。ただし、「**」は指数を示しています。 16進数の「0x」表記と同様に、2進数表記の数値には「0b」がプレフィックスとして付加されます。読みやすくするためにアンダースコアをこのような数値に追加することができるため、0b00100001（0x21）が0b001_00001と書き込まれて、バイト内のビットの望ましい解釈を強調する場合があります。この場合、3ビットと5ビットに分割されます。
A CBOR-encoded data item is structured and encoded as described in this section. The encoding is summarized in Table 5.
CBORでエンコードされたデータ項目は、このセクションで説明するように構造化およびエンコードされます。エンコードを表5に要約します。
The initial byte of each data item contains both information about the major type (the high-order 3 bits, described in Section 2.1) and additional information (the low-order 5 bits). When the value of the additional information is less than 24, it is directly used as a small unsigned integer. When it is 24 to 27, the additional bytes for a variable-length integer immediately follow; the values 24 to 27 of the additional information specify that its length is a 1-, 2-, 4-, or 8-byte unsigned integer, respectively. Additional information value 31 is used for indefinite-length items, described in Section 2.2. Additional information values 28 to 30 are reserved for future expansion.
各データ項目の最初のバイトには、メジャータイプ（2.1節で説明する上位3ビット）に関する情報と追加情報（下位5ビット）の両方が含まれています。追加情報の値が24未満の場合は、小さい符号なし整数として直接使用されます。 24から27の場合、可変長整数の追加バイトがすぐ後に続きます。追加情報の値24〜27は、その長さがそれぞれ1、2、4、または8バイトの符号なし整数であることを指定します。セクション2.2で説明されているように、追加情報値31は不定長アイテムに使用されます。追加情報値28〜30は、将来の拡張のために予約されています。
In all additional information values, the resulting integer is interpreted depending on the major type. It may represent the actual data: for example, in integer types, the resulting integer is used for the value itself. It may instead supply length information: for example, in byte strings it gives the length of the byte string data that follows.
すべての追加情報値で、結果の整数は主なタイプに応じて解釈されます。実際のデータを表す場合があります。たとえば、整数型では、結果の整数が値自体に使用されます。代わりに、長さ情報を提供する場合があります。たとえば、バイト文字列では、後続のバイト文字列データの長さを示します。
A CBOR decoder implementation can be based on a jump table with all 256 defined values for the initial byte (Table 5). A decoder in a constrained implementation can instead use the structure of the initial byte and following bytes for more compact code (see Appendix C for a rough impression of how this could look).
CBORデコーダーの実装は、最初のバイト（表5）に256の定義済みの値すべてを含むジャンプテーブルに基づくことができます。制約された実装のデコーダは、代わりに、よりコンパクトなコードのために、最初のバイトと後続のバイトの構造を使用できます（これがどのように見えるかの大まかな印象については付録Cを参照してください）。
The following lists the major types and the additional information and other bytes associated with the type.
以下は、主なタイプと、そのタイプに関連する追加情報およびその他のバイトのリストです。
Major type 0: an unsigned integer. The 5-bit additional information is either the integer itself (for additional information values 0 through 23) or the length of additional data. Additional information 24 means the value is represented in an additional uint8_t, 25 means a uint16_t, 26 means a uint32_t, and 27 means a uint64_t. For example, the integer 10 is denoted as the one byte 0b000_01010 (major type 0, additional information 10). The integer 500 would be 0b000_11001 (major type 0, additional information 25) followed by the two bytes 0x01f4, which is 500 in decimal.
メジャータイプ0：符号なし整数。 5ビットの追加情報は、整数自体（追加情報値0〜23の場合）または追加データの長さです。追加情報24は、値が追加のuint8_tで表されることを意味し、25はuint16_tを意味し、26はuint32_tを意味し、27はuint64_tを意味します。たとえば、整数10は1バイト0b000_01010（メジャータイプ0、追加情報10）として表されます。整数500は0b000_11001（メジャータイプ0、追加情報25）に2バイト0x01f4が続き、10進数で500になります。
Major type 1: a negative integer. The encoding follows the rules for unsigned integers (major type 0), except that the value is then -1 minus the encoded unsigned integer. For example, the integer -500 would be 0b001_11001 (major type 1, additional information 25) followed by the two bytes 0x01f3, which is 499 in decimal.
メジャータイプ1：負の整数。符号化は、符号なし整数（メジャータイプ0）の規則に従いますが、値は-1から符号化された符号なし整数を引いたものです。たとえば、整数-500は0b001_11001（メジャータイプ1、追加情報25）に2バイト0x01f3が続き、10進数で499になります。
Major type 2: a byte string. The string's length in bytes is represented following the rules for positive integers (major type 0). For example, a byte string whose length is 5 would have an initial byte of 0b010_00101 (major type 2, additional information 5 for the length), followed by 5 bytes of binary content. A byte string whose length is 500 would have 3 initial bytes of 0b010_11001 (major type 2, additional information 25 to indicate a two-byte length) followed by the two bytes 0x01f4 for a length of 500, followed by 500 bytes of binary content.
メジャータイプ2：バイト文字列。文字列の長さ（バイト単位）は、正の整数（メジャータイプ0）の規則に従って表されます。たとえば、長さが5のバイト文字列の最初のバイトは0b010_00101（メジャータイプ2、長さの追加情報5）で、その後に5バイトのバイナリコンテンツが続きます。長さが500のバイト文字列には、0b010_11001（メジャータイプ2、2バイトの長さを示す追加情報25）の3つの最初のバイトがあり、その後に長さ500の2バイト0x01f4が続き、その後に500バイトのバイナリコンテンツが続きます。
Major type 3: a text string, specifically a string of Unicode characters that is encoded as UTF-8 [RFC3629]. The format of this type is identical to that of byte strings (major type 2), that is, as with major type 2, the length gives the number of bytes. This type is provided for systems that need to interpret or display human-readable text, and allows the differentiation between unstructured bytes and text that has a specified repertoire and encoding. In contrast to formats such as JSON, the Unicode characters in this type are never escaped. Thus, a newline character (U+000A) is always represented in a string as the byte 0x0a, and never as the bytes 0x5c6e (the characters "\" and "n") or as 0x5c7530303061 (the characters "\", "u", "0", "0", "0", and "a").
メジャータイプ3：テキスト文字列、具体的にはUTF-8 [RFC3629]としてエンコードされたUnicode文字の文字列。このタイプのフォーマットはバイト文字列（メジャータイプ2）のフォーマットと同じです。つまり、メジャータイプ2と同様に、長さはバイト数を示します。このタイプは、人間が読み取れるテキストを解釈または表示する必要があるシステム用に提供されており、非構造化バイトと、指定されたレパートリーおよびエンコーディングを持つテキストを区別できます。 JSONなどの形式とは異なり、このタイプのUnicode文字はエスケープされません。したがって、改行文字（U + 000A）は常に文字列でバイト0x0aとして表され、バイト0x5c6e（文字「\」および「n」）または0x5c7530303061（文字「\」、「u」として決して表されません。 "、" 0 "、" 0 "、" 0 "、および" a "）。
Major type 4: an array of data items. Arrays are also called lists, sequences, or tuples. The array's length follows the rules for byte strings (major type 2), except that the length denotes the number of data items, not the length in bytes that the array takes up. Items in an array do not need to all be of the same type. For example, an array that contains 10 items of any type would have an initial byte of 0b100_01010 (major type of 4, additional information of 10 for the length) followed by the 10 remaining items.
メジャータイプ4：データ項目の配列。配列は、リスト、シーケンス、またはタプルとも呼ばれます。配列の長さは、バイト文字列（メジャータイプ2）の規則に従いますが、長さがデータアイテムの数を表し、配列が占めるバイト単位の長さではない点が異なります。配列内の項目は、すべて同じタイプである必要はありません。たとえば、任意のタイプの10アイテムを含む配列の場合、最初のバイトは0b100_01010（メジャータイプ4、長さとして10の追加情報）となり、その後に残りの10アイテムが続きます。
Major type 5: a map of pairs of data items. Maps are also called tables, dictionaries, hashes, or objects (in JSON). A map is comprised of pairs of data items, each pair consisting of a key that is immediately followed by a value. The map's length follows the rules for byte strings (major type 2), except that the length denotes the number of pairs, not the length in bytes that the map takes up. For example, a map that contains 9 pairs would have an initial byte of 0b101_01001 (major type of 5, additional information of 9 for the number of pairs) followed by the 18 remaining items. The first item is the first key, the second item is the first value, the third item is the second key, and so on. A map that has duplicate keys may be well-formed, but it is not valid, and thus it causes indeterminate decoding; see also Section 3.7.
メジャータイプ5：データ項目のペアのマップ。マップは、テーブル、辞書、ハッシュ、またはオブジェクト（JSON）とも呼ばれます。マップはデータ項目のペアで構成され、各ペアはすぐ後に値が続くキーで構成されます。マップの長さは、バイト文字列（メジャータイプ2）の規則に従いますが、長さがマップの占めるバイト長ではなく、ペアの数を示す点が異なります。たとえば、9つのペアを含むマップの場合、最初のバイトは0b101_01001（メジャータイプ5、ペアの数は9の追加情報）で、その後に残りの18アイテムが続きます。最初の項目は最初のキー、2番目の項目は最初の値、3番目の項目は2番目のキー、というように続きます。重複するキーを持つマップは整形式である可能性がありますが、有効ではないため、デコードが不確定になります。セクション3.7も参照してください。
Major type 6: optional semantic tagging of other major types. See Section 2.4.
メジャータイプ6：他のメジャータイプのオプションのセマンティックタギング。セクション2.4を参照してください。
Major type 7: floating-point numbers and simple data types that need no content, as well as the "break" stop code. See Section 2.3.
メジャータイプ7：内容を必要としない浮動小数点数と単純なデータ型、および「ブレーク」ストップコード。セクション2.3を参照してください。
These eight major types lead to a simple table showing which of the 256 possible values for the initial byte of a data item are used (Table 5).
これらの8つの主要なタイプにより、データ項目の最初のバイトに使用できる256の値のうちどれが使用されるかを示す単純な表が作成されます（表5）。
In major types 6 and 7, many of the possible values are reserved for future specification. See Section 7 for more information on these values.
主要なタイプ6および7では、可能な値の多くは将来の仕様のために予約されています。これらの値の詳細については、セクション7を参照してください。
Four CBOR items (arrays, maps, byte strings, and text strings) can be encoded with an indefinite length using additional information value 31. This is useful if the encoding of the item needs to begin before the number of items inside the array or map, or the total length of the string, is known. (The application of this is often referred to as "streaming" within a data item.)
4つのCBORアイテム（配列、マップ、バイト文字列、およびテキスト文字列）は、追加情報値31を使用して不定の長さでエンコードできます。これは、配列またはマップ内のアイテム数より前にアイテムのエンコードを開始する必要がある場合に役立ちます、または文字列の全長は既知です。 （これの適用は、データ項目内の「ストリーミング」と呼ばれることがよくあります。）
Indefinite-length arrays and maps are dealt with differently than indefinite-length byte strings and text strings.
不定長の配列とマップは、不定長のバイト文字列やテキスト文字列とは異なる方法で処理されます。
Indefinite-length arrays and maps are simply opened without indicating the number of data items that will be included in the array or map, using the additional information value of 31. The initial major type and additional information byte is followed by the elements of the array or map, just as they would be in other arrays or maps. The end of the array or map is indicated by encoding a "break" stop code in a place where the next data item would normally have been included. The "break" is encoded with major type 7 and additional information value 31 (0b111_11111) but is not itself a data item: it is just a syntactic feature to close the array or map. That is, the "break" stop code comes after the last item in the array or map, and it cannot occur anywhere else in place of a data item. In this way, indefinite-length arrays and maps look identical to other arrays and maps except for beginning with the additional information value 31 and ending with the "break" stop code.
不定長の配列およびマップは、31の追加情報値を使用して、配列またはマップに含まれるデータ項目の数を示すことなく単純に開かれます。最初のメジャータイプと追加情報バイトの後に配列の要素が続きますまたは、他の配列やマップと同じようにマップします。配列またはマップの終わりは、次のデータ項目が通常含まれる場所に「ブレーク」ストップコードをエンコードすることで示されます。 「break」はメジャータイプ7および追加情報値31（0b111_11111）でエンコードされていますが、それ自体がデータアイテムではありません。これは、配列またはマップを閉じるための構文機能にすぎません。つまり、「ブレーク」停止コードは配列またはマップの最後のアイテムの後に来て、データアイテムの代わりに他の場所で発生することはありません。このように、不定長の配列とマップは、追加情報値31で始まり、「ブレーク」ストップコードで終わることを除いて、他の配列とマップと同じに見えます。
Arrays and maps with indefinite lengths allow any number of items (for arrays) and key/value pairs (for maps) to be given before the "break" stop code. There is no restriction against nesting indefinite-length array or map items. A "break" only terminates a single item, so nested indefinite-length items need exactly as many "break" stop codes as there are type bytes starting an indefinite-length item.
長さが不定の配列とマップでは、「ブレーク」停止コードの前に、任意の数の項目（配列の場合）およびキーと値のペア（マップの場合）を指定できます。不定長の配列またはマップアイテムのネストに対する制限はありません。 「break」は単一の項目のみを終了するので、ネストされた不定長の項目は、不定長項目を開始するタイプバイトの数とまったく同じ数の「break」停止コードを必要とします。
For example, assume an encoder wants to represent the abstract array [1, [2, 3], [4, 5]]. The definite-length encoding would be 0x8301820203820405:
たとえば、エンコーダが抽象配列[1、[2、3]、[4、5]]を表現したいとします。固定長エンコーディングは0x8301820203820405になります。
83 -- Array of length 3 01 -- 1 82 -- Array of length 2 02 -- 2 03 -- 3 82 -- Array of length 2 04 -- 4 05 -- 5
83-長さ3の配列01-1 82-長さ2の配列02-2 03-3 82-長さ2の配列04-4 05-5
Indefinite-length encoding could be applied independently to each of the three arrays encoded in this data item, as required, leading to representations such as:
不定長エンコーディングは、必要に応じて、このデータ項目でエンコードされた3つの配列のそれぞれに個別に適用でき、次のような表現になります。
0x9f018202039f0405ffff 9F -- Start indefinite-length array 01 -- 1 82 -- Array of length 2 02 -- 2 03 -- 3 9F -- Start indefinite-length array 04 -- 4 05 -- 5 FF -- "break" (inner array) FF -- "break" (outer array)
0x9f018202039f0405ffff 9F-不定長配列01-1 82-長さ2の配列02-2 03-3 9F-不定長配列04-4 05-5 FF-"break"の開始（内部配列）FF-"break"（外部配列）
0x9f01820203820405ff 9F -- Start indefinite-length array 01 -- 1 82 -- Array of length 2 02 -- 2 03 -- 3 82 -- Array of length 2 04 -- 4 05 -- 5 FF -- "break"
0x9f01820203820405ff 9F-不定長配列01-1 82-長さ2の配列02-2 03-3 82-長さ2の配列04-4 05-5 FF-"ブレーク"
0x83018202039f0405ff 83 -- Array of length 3 01 -- 1 82 -- Array of length 2 02 -- 2 03 -- 3 9F -- Start indefinite-length array 04 -- 4 05 -- 5 FF -- "break"
0x83018202039f0405ff 83-長さ3の配列01-1 82-長さ2の配列02-2 03-3 9F-不定長配列の開始04-4 05-5 FF-"ブレーク"
0x83019f0203ff820405 83 -- Array of length 3 01 -- 1 9F -- Start indefinite-length array 02 -- 2 03 -- 3 FF -- "break" 82 -- Array of length 2 04 -- 4 05 -- 5
0x83019f0203ff820405 83-長さ3の配列01-1 9F-不定長配列の開始02-2 03-3 FF-"break" 82-長さ2の配列04-4 05-5
An example of an indefinite-length map (that happens to have two key/value pairs) might be:
不定長マップの例（たまたま2つのキーと値のペアがある）は次のようになります。
0xbf6346756ef563416d7421ff BF -- Start indefinite-length map 63 -- First key, UTF-8 string length 3 46756e -- "Fun" F5 -- First value, true 63 -- Second key, UTF-8 string length 3 416d74 -- "Amt" 21 -- -2 FF -- "break"
0xbf6346756ef563416d7421ff BF-不定長マップの開始63-最初のキー、UTF-8文字列長3 46756e-"Fun" F5-最初の値、true 63-2番目のキー、UTF-8文字列長3 416d74-" Amt "21--2 FF-" break "
Indefinite-length byte strings and text strings are actually a concatenation of zero or more definite-length byte or text strings ("chunks") that are together treated as one contiguous string. Indefinite-length strings are opened with the major type and additional information value of 31, but what follows are a series of byte or text strings that have definite lengths (the chunks). The end of the series of chunks is indicated by encoding the "break" stop code (0b111_11111) in a place where the next chunk in the series would occur. The contents of the chunks are concatenated together, and the overall length of the indefinite-length string will be the sum of the lengths of all of the chunks. In summary, an indefinite-length string is encoded similarly to how an indefinite-length array of its chunks would be encoded, except that the major type of the indefinite-length string is that of a (text or byte) string and matches the major types of its chunks.
不定長のバイト文字列とテキスト文字列は、実際には、0個以上の不定長のバイト文字列またはテキスト文字列（「チャンク」）の連結であり、1つの連続した文字列として一緒に扱われます。不定長文字列は、メジャータイプと追加情報値31で開かれますが、その後に続くのは、一定の長さ（チャンク）を持つ一連のバイト文字列またはテキスト文字列です。一連のチャンクの終わりは、一連の次のチャンクが発生する場所に「ブレーク」ストップコード（0b111_11111）をエンコードすることで示されます。チャンクの内容は連結され、不定長ストリングの全長は、すべてのチャンクの長さの合計になります。要約すると、不定長ストリングは、そのチャンクの不定長配列がエンコードされる方法と同様にエンコードされますが、不定長ストリングのメジャータイプは（テキストまたはバイト）ストリングのメジャータイプであり、メジャーと一致します。そのチャンクのタイプ。
For indefinite-length byte strings, every data item (chunk) between the indefinite-length indicator and the "break" MUST be a definite-length byte string item; if the parser sees any item type other than a byte string before it sees the "break", it is an error.
不定長バイト文字列の場合、不定長インジケータと「ブレーク」の間のすべてのデータ項目（チャンク）は、不定長バイト文字列項目でなければなりません。パーサーが「ブレーク」を確認する前にバイト文字列以外のアイテムタイプを確認すると、エラーになります。
For example, assume the sequence:
たとえば、次のシーケンスを想定します。
0b010_11111 0b010_00100 0xaabbccdd 0b010_00011 0xeeff99 0b111_11111
0b010_11111 0b010_00100 0xaabbccdd 0b010_00011 0xeeff99 0b111_11111
5F -- Start indefinite-length byte string 44 -- Byte string of length 4 aabbccdd -- Bytes content 43 -- Byte string of length 3 eeff99 -- Bytes content FF -- "break"
5F-不定長バイト文字列の開始44-長さ4のバイト文字列aabbccdd-バイトコンテンツ43-長さ3のバイト文字列eeff99-バイトコンテンツFF-"ブレーク"
After decoding, this results in a single byte string with seven bytes: 0xaabbccddeeff99.
デコード後、これは7バイトの1バイト文字列（0xaabbccddeeff99）になります。
Text strings with indefinite lengths act the same as byte strings with indefinite lengths, except that all their chunks MUST be definite-length text strings. Note that this implies that the bytes of a single UTF-8 character cannot be spread between chunks: a new chunk can only be started at a character boundary.
長さが不定のテキスト文字列は、長さが不定のバイト文字列と同じように機能しますが、すべてのチャンクは長さが固定のテキスト文字列でなければならない点が異なります。これは、単一のUTF-8文字のバイトをチャンク間で分散できないことを意味することに注意してください。新しいチャンクは文字境界でのみ開始できます。
Major type 7 is for two types of data: floating-point numbers and "simple values" that do not need any content. Each value of the 5-bit additional information in the initial byte has its own separate meaning, as defined in Table 1. Like the major types for integers, items of this major type do not carry content data; all the information is in the initial bytes.
メジャータイプ7は、浮動小数点数とコンテンツを必要としない「単純な値」の2種類のデータ用です。最初のバイトの5ビットの追加情報の各値は、表1で定義されているように、独自の個別の意味を持っています。整数のメジャータイプと同様に、このメジャータイプのアイテムはコンテンツデータを持ちません。すべての情報は最初のバイトにあります。
+-------------+--------------------------------------------------+
| 5-Bit Value | Semantics |
+-------------+--------------------------------------------------+
| 0..23 | Simple value (value 0..23) |
| | |
| 24 | Simple value (value 32..255 in following byte) |
| | |
| 25 | IEEE 754 Half-Precision Float (16 bits follow) |
| | |
| 26 | IEEE 754 Single-Precision Float (32 bits follow) |
| | |
| 27 | IEEE 754 Double-Precision Float (64 bits follow) |
| | |
| 28-30 | (Unassigned) |
| | |
| 31 | "break" stop code for indefinite-length items |
+-------------+--------------------------------------------------+
Table 1: Values for Additional Information in Major Type 7
表1：メジャータイプ7の追加情報の値
As with all other major types, the 5-bit value 24 signifies a single-byte extension: it is followed by an additional byte to represent the simple value. (To minimize confusion, only the values 32 to 255 are used.) This maintains the structure of the initial bytes: as for the other major types, the length of these always depends on the additional information in the first byte. Table 2 lists the values assigned and available for simple types.
他のすべての主要なタイプと同様に、5ビットの値24は1バイトの拡張を意味します。単純な値を表すために、その後に追加のバイトが続きます。 （混乱を最小限に抑えるために、32〜255の値のみが使用されます。）これにより、初期バイトの構造が維持されます。他の主要なタイプと同様に、これらの長さは常に最初のバイトの追加情報に依存します。表2は、単純型に割り当てられ、使用可能な値を示しています。
+---------+-----------------+
| Value | Semantics |
+---------+-----------------+
| 0..19 | (Unassigned) |
| | |
| 20 | False |
| | |
| 21 | True |
| | |
| 22 | Null |
| | |
| 23 | Undefined value |
| | |
| 24..31 | (Reserved) |
| | |
| 32..255 | (Unassigned) |
+---------+-----------------+
Table 2: Simple Values
表2：単純な値
The 5-bit values of 25, 26, and 27 are for 16-bit, 32-bit, and 64-bit IEEE 754 binary floating-point values. These floating-point values are encoded in the additional bytes of the appropriate size. (See Appendix D for some information about 16-bit floating point.)
25、26、および27の5ビット値は、16ビット、32ビット、および64ビットのIEEE 754 2進浮動小数点値用です。これらの浮動小数点値は、適切なサイズの追加バイトにエンコードされます。 （16ビット浮動小数点に関する情報については、付録Dを参照してください。）
In CBOR, a data item can optionally be preceded by a tag to give it additional semantics while retaining its structure. The tag is major type 6, and represents an integer number as indicated by the tag's integer value; the (sole) data item is carried as content data. If a tag requires structured data, this structure is encoded into the nested data item. The definition of a tag usually restricts what kinds of nested data item or items can be carried by a tag.
CBORでは、データ項目の前にオプションでタグを付けて、その構造を保持しながら追加のセマンティクスを与えることができます。タグはメジャータイプ6であり、タグの整数値によって示される整数を表します。 （唯一の）データアイテムはコンテンツデータとして運ばれます。タグに構造化データが必要な場合、この構造はネストされたデータ項目にエンコードされます。タグの定義は、通常、タグがどのような種類のネストされたデータアイテムを運ぶことができるかを制限します。
The initial bytes of the tag follow the rules for positive integers (major type 0). The tag is followed by a single data item of any type. For example, assume that a byte string of length 12 is marked with a tag to indicate it is a positive bignum (Section 2.4.2). This would be marked as 0b110_00010 (major type 6, additional information 2 for the tag) followed by 0b010_01100 (major type 2, additional information of 12 for the length) followed by the 12 bytes of the bignum.
タグの最初のバイトは、正の整数（メジャータイプ0）の規則に従います。タグの後には、任意のタイプの単一のデータ項目が続きます。たとえば、長さが12のバイト文字列にタグが付けられていて、それが正のbignumであることを示しているとします（セクション2.4.2）。これは、0b110_00010（メジャータイプ6、タグの追加情報2）の後に0b010_01100（メジャータイプ2、長さの追加情報12）、続いて12バイトのbignumとしてマークされます。
Decoders do not need to understand tags, and thus tags may be of little value in applications where the implementation creating a particular CBOR data item and the implementation decoding that stream know the semantic meaning of each item in the data flow. Their primary purpose in this specification is to define common data types such as dates. A secondary purpose is to allow optional tagging when the decoder is a generic CBOR decoder that might be able to benefit from hints about the content of items. Understanding the semantic tags is optional for a decoder; it can just jump over the initial bytes of the tag and interpret the tagged data item itself.
デコーダーはタグを理解する必要がないため、特定のCBORデータ項目を作成する実装と、そのストリームをデコードする実装がデータフロー内の各項目の意味論的な意味を知っているアプリケーションでは、タグはほとんど価値がありません。この仕様の主な目的は、日付などの一般的なデータ型を定義することです。二次的な目的は、デコーダーがアイテムのコンテンツに関するヒントから利益を得ることができる汎用のCBORデコーダーである場合に、オプションのタグ付けを可能にすることです。セマンティックタグの理解は、デコーダではオプションです。タグの最初のバイトを飛び越えて、タグ付けされたデータ項目自体を解釈できます。
A tag always applies to the item that is directly followed by it. Thus, if tag A is followed by tag B, which is followed by data item C, tag A applies to the result of applying tag B on data item C. That is, a tagged item is a data item consisting of a tag and a value. The content of the tagged item is the data item (the value) that is being tagged.
タグは常に、そのすぐ後に続くアイテムに適用されます。したがって、タグAの後にタグBが続き、その後にデータ項目Cが続く場合、タグAは、データ項目CにタグBを適用した結果に適用されます。つまり、タグ付き項目は、タグと値。タグ付けされたアイテムのコンテンツは、タグ付けされているデータアイテム（値）です。
IANA maintains a registry of tag values as described in Section 7.2. Table 3 provides a list of initial values, with definitions in the rest of this section.
セクション7.2で説明するように、IANAはタグ値のレジストリを維持します。表3に、このセクションの残りの部分で定義されている初期値のリストを示します。
+--------------+------------------+---------------------------------+
| Tag | Data Item | Semantics |
+--------------+------------------+---------------------------------+
| 0 | UTF-8 string | Standard date/time string; see |
| | | Section 2.4.1 |
| | | |
| 1 | multiple | Epoch-based date/time; see |
| | | Section 2.4.1 |
| | | |
| 2 | byte string | Positive bignum; see Section |
| | | 2.4.2 |
| | | |
| 3 | byte string | Negative bignum; see Section |
| | | 2.4.2 |
| | | |
| 4 | array | Decimal fraction; see Section |
| | | 2.4.3 |
| | | |
| 5 | array | Bigfloat; see Section 2.4.3 |
| | | |
| 6..20 | (Unassigned) | (Unassigned) |
| | | |
| 21 | multiple | Expected conversion to |
| | | base64url encoding; see |
| | | Section 2.4.4.2 |
| | | |
| 22 | multiple | Expected conversion to base64 |
| | | encoding; see Section 2.4.4.2 |
| | | |
| 23 | multiple | Expected conversion to base16 |
| | | encoding; see Section 2.4.4.2 |
| | | |
| 24 | byte string | Encoded CBOR data item; see |
| | | Section 2.4.4.1 |
| | | |
| 25..31 | (Unassigned) | (Unassigned) |
| | | |
| 32 | UTF-8 string | URI; see Section 2.4.4.3 |
| | | |
| 33 | UTF-8 string | base64url; see Section 2.4.4.3 |
| | | |
| 34 | UTF-8 string | base64; see Section 2.4.4.3 |
| | | |
| 35 | UTF-8 string | Regular expression; see |
| | | Section 2.4.4.3 |
| | | |
| 36 | UTF-8 string | MIME message; see Section |
| | | 2.4.4.3 |
| | | |
| 37..55798 | (Unassigned) | (Unassigned) |
| | | |
| 55799 | multiple | Self-describe CBOR; see |
| | | Section 2.4.5 |
| | | |
| 55800+ | (Unassigned) | (Unassigned) |
+--------------+------------------+---------------------------------+
Table 3: Values for Tags
表3：タグの値
Tag value 0 is for date/time strings that follow the standard format described in [RFC3339], as refined by Section 3.3 of [RFC4287].
タグ値0は、[RFC4287]のセクション3.3で改良された、[RFC3339]で説明されている標準形式に従う日付/時刻文字列用です。
Tag value 1 is for numerical representation of seconds relative to 1970-01-01T00:00Z in UTC time. (For the non-negative values that the Portable Operating System Interface (POSIX) defines, the number of seconds is counted in the same way as for POSIX "seconds since the epoch" [TIME_T].) The tagged item can be a positive or negative integer (major types 0 and 1), or a floating-point number (major type 7 with additional information 25, 26, or 27). Note that the number can be negative (time before 1970-01-01T00:00Z) and, if a floating-point number, indicate fractional seconds.
タグ値1は、UTC時間での1970-01-01T00：00Zを基準とした秒の数値表現用です。 （ポータブルオペレーティングシステムインターフェース（POSIX）が定義する負でない値の場合、秒数はPOSIXの「エポックからの秒数」[TIME_T]と同じ方法でカウントされます。）タグ付きの項目は正または負の整数（メジャータイプ0および1）、または浮動小数点数（メジャータイプ7、追加情報25、26、または27）。数値は負の値（1970-01-01T00：00Zより前の時刻）にすることができ、浮動小数点数の場合は小数秒を示すことに注意してください。
Bignums are integers that do not fit into the basic integer representations provided by major types 0 and 1. They are encoded as a byte string data item, which is interpreted as an unsigned integer n in network byte order. For tag value 2, the value of the bignum is n. For tag value 3, the value of the bignum is -1 - n. Decoders that understand these tags MUST be able to decode bignums that have leading zeroes.
Bignumは、メジャータイプ0および1によって提供される基本的な整数表現に適合しない整数です。これらは、バイト文字列データ項目としてエンコードされ、ネットワークバイトオーダーで符号なし整数nとして解釈されます。タグ値2の場合、bignumの値はnです。タグ値3の場合、bignumの値は-1-nです。これらのタグを理解するデコーダーは、先行ゼロを持つbignumをデコードできる必要があります。
For example, the number 18446744073709551616 (2**64) is represented as 0b110_00010 (major type 6, tag 2), followed by 0b010_01001 (major type 2, length 9), followed by 0x010000000000000000 (one byte 0x01 and eight bytes 0x00). In hexadecimal:
たとえば、数値18446744073709551616（2 ** 64）は0b110_00010（メジャータイプ6、タグ2）、0b010_01001（メジャータイプ2、長さ9）、0x010000000000000000（1バイト0x01、8バイト0x00）の順で表されます。 16進数で：
C2 -- Tag 2 29 -- Byte string of length 9 010000000000000000 -- Bytes content
C2-タグ2 29-長さ9のバイト文字列010000000000000000-バイトコンテンツ
Decimal fractions combine an integer mantissa with a base-10 scaling factor. They are most useful if an application needs the exact representation of a decimal fraction such as 1.1 because there is no exact representation for many decimal fractions in binary floating point.
小数部は、整数の仮数と10を底とするスケーリング係数を組み合わせます。 2進浮動小数点の多くの小数部の正確な表現がないため、アプリケーションが1.1などの小数部の正確な表現を必要とする場合、これらは最も役立ちます。
Bigfloats combine an integer mantissa with a base-2 scaling factor. They are binary floating-point values that can exceed the range or the precision of the three IEEE 754 formats supported by CBOR (Section 2.3). Bigfloats may also be used by constrained applications that need some basic binary floating-point capability without the need for supporting IEEE 754.
Bigfloatは、整数の仮数と2進数のスケーリング係数を組み合わせます。これらは、CBORでサポートされている3つのIEEE 754形式の範囲または精度を超える可能性がある2進浮動小数点値です（2.3節）。 Bigfloatは、IEEE 754をサポートする必要なしに、基本的な2進浮動小数点機能を必要とする制約のあるアプリケーションでも使用できます。
A decimal fraction or a bigfloat is represented as a tagged array that contains exactly two integer numbers: an exponent e and a mantissa m. Decimal fractions (tag 4) use base-10 exponents; the value of a decimal fraction data item is m*(10**e). Bigfloats (tag 5) use base-2 exponents; the value of a bigfloat data item is m*(2**e). The exponent e MUST be represented in an integer of major type 0 or 1, while the mantissa also can be a bignum (Section 2.4.2).
小数またはbigfloatは、指数eと仮数mの2つの整数を含むタグ付き配列として表されます。小数部（タグ4）は、基数10の指数を使用します。小数データ項目の値はm *（10 ** e）です。 Bigfloat（タグ5）は、基数2の指数を使用します。 bigfloatデータ項目の値はm *（2 ** e）です。指数eは、メジャータイプ0または1の整数で表現する必要がありますが、仮数もビッグナムにすることができます（セクション2.4.2）。
An example of a decimal fraction is that the number 273.15 could be represented as 0b110_00100 (major type of 6 for the tag, additional information of 4 for the type of tag), followed by 0b100_00010 (major type of 4 for the array, additional information of 2 for the length of the array), followed by 0b001_00001 (major type of 1 for the first integer, additional information of 1 for the value of -2), followed by 0b000_11001 (major type of 0 for the second integer, additional information of 25 for a two-byte value), followed by 0b0110101010110011 (27315 in two bytes). In hexadecimal:
小数の例としては、数値273.15を0b110_00100（タグのメジャータイプは6、タグのタイプは4の追加情報）、0b100_00010（配列はメジャータイプの4、追加情報）のように表すことができます。配列の長さは2の）、0b001_00001（最初の整数のメジャータイプは1、-2の値は1の追加情報）、0b000_11001（2番目の整数のメジャータイプは0、追加情報） 2バイトの値の場合は25）、その後に0b0110101010110011（2バイトで27315）が続きます。 16進数で：
C4 -- Tag 4 82 -- Array of length 2 21 -- -2 19 6ab3 -- 27315
C4-タグ4 82-長さの配列2 21--2 19 6ab3-27315
An example of a bigfloat is that the number 1.5 could be represented as 0b110_00101 (major type of 6 for the tag, additional information of 5 for the type of tag), followed by 0b100_00010 (major type of 4 for the array, additional information of 2 for the length of the array), followed by 0b001_00000 (major type of 1 for the first integer, additional information of 0 for the value of -1), followed by 0b000_00011 (major type of 0 for the second integer, additional information of 3 for the value of 3). In hexadecimal: C5 -- Tag 5 82 -- Array of length 2 20 -- -1 03 -- 3
bigfloatの例は、数値1.5が0b110_00101（タグのメジャータイプ6、タグのタイプの追加情報5）の後に0b100_00010（アレイのメジャータイプ4の追加情報、配列の長さは2）、0b001_00000（最初の整数のメジャータイプは1、値-1の追加情報は0）、0b000_00011（2番目の整数のメジャータイプは0、追加情報は） 3の値は3）。 16進数で：C5-タグ5 82-長さの配列2 20--1 03-3
Decimal fractions and bigfloats provide no representation of Infinity, -Infinity, or NaN; if these are needed in place of a decimal fraction or bigfloat, the IEEE 754 half-precision representations from Section 2.3 can be used. For constrained applications, where there is a choice between representing a specific number as an integer and as a decimal fraction or bigfloat (such as when the exponent is small and non-negative), there is a quality-of-implementation expectation that the integer representation is used directly.
小数部とビッグフロートは、Infinity、-Infinity、またはNaNの表現を提供しません。これらが小数またはbigfloatの代わりに必要な場合は、セクション2.3のIEEE 754半精度表現を使用できます。特定の数値を整数として表現するか、小数またはbigfloatとして表現するか（指数が小さく負でない場合など）の制約があるアプリケーションでは、整数の実装品質が期待されます。表現は直接使用されます。
The tags in this section are for content hints that might be used by generic CBOR processors.
このセクションのタグは、一般的なCBORプロセッサで使用される可能性のあるコンテンツヒント用です。
Sometimes it is beneficial to carry an embedded CBOR data item that is not meant to be decoded immediately at the time the enclosing data item is being parsed. Tag 24 (CBOR data item) can be used to tag the embedded byte string as a data item encoded in CBOR format.
エンクロージングデータアイテムが解析されているときにすぐにデコードされることを意図していない埋め込みCBORデータアイテムを保持すると便利な場合があります。タグ24（CBORデータ項目）を使用して、埋め込みバイト文字列にCBOR形式でエンコードされたデータ項目としてタグを付けることができます。
Tags 21 to 23 indicate that a byte string might require a specific encoding when interoperating with a text-based representation. These tags are useful when an encoder knows that the byte string data it is writing is likely to be later converted to a particular JSON-based usage. That usage specifies that some strings are encoded as base64, base64url, and so on. The encoder uses byte strings instead of doing the encoding itself to reduce the message size, to reduce the code size of the encoder, or both. The encoder does not know whether or not the converter will be generic, and therefore wants to say what it believes is the proper way to convert binary strings to JSON.
タグ21〜23は、テキストベースの表現と相互運用する場合、バイト文字列に特定のエンコーディングが必要になる場合があることを示しています。これらのタグは、書き込み中のバイト文字列データが後で特定のJSONベースの使用法に変換される可能性が高いことをエンコーダーが知っている場合に役立ちます。その使用法は、一部の文字列がbase64、base64urlなどとしてエンコードされることを指定しています。エンコーダーは、エンコード自体を行う代わりにバイト文字列を使用して、メッセージサイズを小さくするか、エンコーダーのコードサイズを小さくするか、またはその両方を行います。エンコーダーは、コンバーターが汎用になるかどうかを認識していないため、バイナリー文字列をJSONに変換する適切な方法であると考えていることを伝えたいと考えています。
The data item tagged can be a byte string or any other data item. In the latter case, the tag applies to all of the byte string data items contained in the data item, except for those contained in a nested data item tagged with an expected conversion.
タグ付けされたデータ項目は、バイト文字列またはその他のデータ項目です。後者の場合、タグは、予想される変換でタグ付けされたネストされたデータ項目に含まれるものを除いて、データ項目に含まれるすべてのバイト文字列データ項目に適用されます。
These three tag types suggest conversions to three of the base data encodings defined in [RFC4648]. For base64url encoding, padding is not used (see Section 3.2 of RFC 4648); that is, all trailing equals signs ("=") are removed from the base64url-encoded string. Later tags might be defined for other data encodings of RFC 4648 or for other ways to encode binary data in strings.
これらの3つのタグタイプは、[RFC4648]で定義されている3つの基本データエンコーディングへの変換を提案しています。 base64urlエンコーディングの場合、パディングは使用されません（RFC 4648のセクション3.2を参照）。つまり、すべての末尾の等号（ "="）は、base64urlでエンコードされた文字列から削除されます。その後のタグは、RFC 4648の他のデータエンコーディングや、バイナリデータを文字列にエンコードする他の方法で定義される場合があります。
Some text strings hold data that have formats widely used on the Internet, and sometimes those formats can be validated and presented to the application in appropriate form by the decoder. There are tags for some of these formats.
一部のテキスト文字列は、インターネットで広く使用されている形式のデータを保持しています。それらの形式は、デコーダーによって検証され、適切な形式でアプリケーションに提示される場合があります。これらのフォーマットのいくつかにはタグがあります。
o Tag 32 is for URIs, as defined in [RFC3986];
o タグ32は、[RFC3986]で定義されているURI用です。
o Tags 33 and 34 are for base64url- and base64-encoded text strings, as defined in [RFC4648];
o タグ33と34は、[RFC4648]で定義されているように、base64urlおよびbase64でエンコードされたテキスト文字列用です。
o Tag 35 is for regular expressions in Perl Compatible Regular Expressions (PCRE) / JavaScript syntax [ECMA262].
o タグ35は、Perl互換正規表現（PCRE）/ JavaScript構文[ECMA262]の正規表現用です。
o Tag 36 is for MIME messages (including all headers), as defined in [RFC2045];
o タグ36は、[RFC2045]で定義されているMIMEメッセージ（すべてのヘッダーを含む）用です。
Note that tags 33 and 34 differ from 21 and 22 in that the data is transported in base-encoded form for the former and in raw byte string form for the latter.
タグ33と34は、データが前者の場合はベースエンコード形式で転送され、後者の場合は未加工のバイト文字列形式で転送されるという点で21と22とは異なります。
In many applications, it will be clear from the context that CBOR is being employed for encoding a data item. For instance, a specific protocol might specify the use of CBOR, or a media type is indicated that specifies its use. However, there may be applications where such context information is not available, such as when CBOR data is stored in a file and disambiguating metadata is not in use. Here, it may help to have some distinguishing characteristics for the data itself.
多くのアプリケーションでは、データ項目をエンコードするためにCBORが使用されていることがコンテキストから明らかになります。たとえば、特定のプロトコルでCBORの使用を指定する場合や、その使用を指定するメディアタイプが示される場合があります。ただし、CBORデータがファイルに格納されていて、明確なメタデータが使用されていない場合など、このようなコンテキスト情報が利用できないアプリケーションがある場合があります。ここでは、データ自体にいくつかの際立った特徴があると役立ちます。
Tag 55799 is defined for this purpose. It does not impart any special semantics on the data item that follows; that is, the semantics of a data item tagged with tag 55799 is exactly identical to the semantics of the data item itself.
タグ55799はこの目的のために定義されています。後続のデータ項目に特別なセマンティクスを与えることはありません。つまり、タグ55799でタグ付けされたデータ項目のセマンティクスは、データ項目自体のセマンティクスとまったく同じです。
The serialization of this tag is 0xd9d9f7, which appears not to be in use as a distinguishing mark for frequently used file types. In particular, it is not a valid start of a Unicode text in any Unicode encoding if followed by a valid CBOR data item.
このタグのシリアル化は0xd9d9f7です。これは、頻繁に使用されるファイルタイプの識別マークとして使用されていないようです。特に、有効なCBORデータ項目が後に続く場合は、UnicodeエンコーディングのUnicodeテキストの有効な開始ではありません。
For instance, a decoder might be able to parse both CBOR and JSON. Such a decoder would need to mechanically distinguish the two formats. An easy way for an encoder to help the decoder would be to tag the entire CBOR item with tag 55799, the serialization of which will never be found at the beginning of a JSON text.
たとえば、デコーダーはCBORとJSONの両方を解析できる場合があります。このようなデコーダーは、2つのフォーマットを機械的に区別する必要があります。エンコーダーがデコーダーを支援する簡単な方法は、CBORアイテム全体をタグ55799でタグ付けすることです。そのシリアル化は、JSONテキストの先頭では決して見つかりません。
Data formats such as CBOR are often used in environments where there is no format negotiation. A specific design goal of CBOR is to not need any included or assumed schema: a decoder can take a CBOR item and decode it with no other knowledge.
CBORなどのデータ形式は、形式のネゴシエーションがない環境でよく使用されます。 CBORの特定の設計目標は、含まれているスキーマや想定されるスキーマを必要としないことです。デコーダーはCBORアイテムを受け取り、それを他の知識なしにデコードできます。
Of course, in real-world implementations, the encoder and the decoder will have a shared view of what should be in a CBOR data item. For example, an agreed-to format might be "the item is an array whose first value is a UTF-8 string, second value is an integer, and subsequent values are zero or more floating-point numbers" or "the item is a map that has byte strings for keys and contains at least one pair whose key is 0xab01".
もちろん、実際の実装では、エンコーダーとデコーダーはCBORデータ項目に何があるべきかについて共有ビューを持っています。たとえば、合意されたフォーマットは、「項目は最初の値がUTF-8文字列であり、2番目の値が整数であり、後続の値が0以上の浮動小数点数である配列」または「項目はキーのバイト文字列を持ち、キーが0xab01 "であるペアを少なくとも1つ含むマップ。
This specification puts no restrictions on CBOR-based protocols. An encoder can be capable of encoding as many or as few types of values as is required by the protocol in which it is used; a decoder can be capable of understanding as many or as few types of values as is required by the protocols in which it is used. This lack of restrictions allows CBOR to be used in extremely constrained environments.
この仕様では、CBORベースのプロトコルに制限はありません。エンコーダーは、それが使用されるプロトコルで必要とされる限り多くのまたは少ないタイプの値をエンコードすることができます。デコーダーは、それが使用されるプロトコルで必要とされる限り多くのまたは少ないタイプの値を理解することができます。この制限の欠如により、CBORは非常に制約された環境で使用できます。
This section discusses some considerations in creating CBOR-based protocols. It is advisory only and explicitly excludes any language from RFC 2119 other than words that could be interpreted as "MAY" in the sense of RFC 2119.
このセクションでは、CBORベースのプロトコルを作成する際の考慮事項について説明します。これは助言のみであり、RFC 2119の意味で「MAY」と解釈される可能性のある単語以外の言語をRFC 2119から明示的に除外しています。
In a streaming application, a data stream may be composed of a sequence of CBOR data items concatenated back-to-back. In such an environment, the decoder immediately begins decoding a new data item if data is found after the end of a previous data item.
ストリーミングアプリケーションでは、データストリームは、連続して連結された一連のCBORデータアイテムで構成されます。このような環境では、前のデータ項目の終了後にデータが見つかった場合、デコーダーはすぐに新しいデータ項目のデコードを開始します。
Not all of the bytes making up a data item may be immediately available to the decoder; some decoders will buffer additional data until a complete data item can be presented to the application. Other decoders can present partial information about a top-level data item to an application, such as the nested data items that could already be decoded, or even parts of a byte string that hasn't completely arrived yet.
データ項目を構成するすべてのバイトが、デコーダですぐに使用できるとは限りません。一部のデコーダーは、完全なデータ項目をアプリケーションに提示できるようになるまで、追加のデータをバッファーします。他のデコーダーは、既にデコードされている入れ子になったデータアイテムや、まだ完全に到着していないバイト文字列の一部など、トップレベルのデータアイテムに関する部分的な情報をアプリケーションに提示できます。
Note that some applications and protocols will not want to use indefinite-length encoding. Using indefinite-length encoding allows an encoder to not need to marshal all the data for counting, but it requires a decoder to allocate increasing amounts of memory while waiting for the end of the item. This might be fine for some applications but not others.
一部のアプリケーションとプロトコルは、不定長エンコーディングを使用したくないことに注意してください。不定長エンコーディングを使用すると、エンコーダーはカウントするためにすべてのデータをマーシャリングする必要がなくなりますが、アイテムの終わりを待つ間、デコーダーは増加する量のメモリを割り当てる必要があります。これは、一部のアプリケーションでは問題ない場合があります。
A generic CBOR decoder can decode all well-formed CBOR data and present them to an application. CBOR data is well-formed if it uses the initial bytes, as well as the byte strings and/or data items that are implied by their values, in the manner defined by CBOR, and no extraneous data follows (Appendix C).
汎用CBORデコーダーは、すべての整形式CBORデータをデコードして、アプリケーションに提示できます。 CBORで定義されている方法で、CBORデータが初期バイト、およびバイトストリングやその値によって暗示されるデータ項目を使用する場合、整形式であり、無関係なデータは続きません（付録C）。
Even though CBOR attempts to minimize these cases, not all well-formed CBOR data is valid: for example, the format excludes simple values below 32 that are encoded with an extension byte. Also, specific tags may make semantic constraints that may be violated, such as by including a tag in a bignum tag or by following a byte string within a date tag. Finally, the data may be invalid, such as invalid UTF-8 strings or date strings that do not conform to [RFC3339]. There is no requirement that generic encoders and decoders make unnatural choices for their application interface to enable the processing of invalid data. Generic encoders and decoders are expected to forward simple values and tags even if their specific codepoints are not registered at the time the encoder/decoder is written (Section 3.5).
CBORはこれらのケースを最小化しようとしますが、すべての整形式のCBORデータが有効であるとは限りません。たとえば、フォーマットは、拡張バイトでエンコードされた32未満の単純な値を除外します。また、特定のタグは、タグをbignumタグに含めることや、日付タグ内のバイト文字列を追跡することなどにより、違反される可能性のある意味上の制約を作成する場合があります。最後に、[RFC3339]に準拠しない無効なUTF-8文字列や日付文字列など、データが無効である可能性があります。無効なデータの処理を可能にするために、汎用エンコーダーとデコーダーがアプリケーションインターフェイスに対して不自然な選択を行う必要はありません。汎用エンコーダーとデコーダーは、エンコーダー/デコーダーの作成時に特定のコードポイントが登録されていなくても、単純な値とタグを転送することが期待されています（セクション3.5）。
Generic decoders provide ways to present well-formed CBOR values, both valid and invalid, to an application. The diagnostic notation (Section 6) may be used to present well-formed CBOR values to humans.
汎用デコーダーは、有効と無効の両方の整形式のCBOR値をアプリケーションに提示する方法を提供します。診断表記（セクション6）を使用して、整形式のCBOR値を人間に提示できます。
Generic encoders provide an application interface that allows the application to specify any well-formed value, including simple values and tags unknown to the encoder.
汎用エンコーダーは、シンプルな値やエンコーダーに認識されていないタグなど、アプリケーションが整形式の値を指定できるようにするアプリケーションインターフェイスを提供します。
A decoder encountering a CBOR data item that is not well-formed generally can choose to completely fail the decoding (issue an error and/or stop processing altogether), substitute the problematic data and data items using a decoder-specific convention that clearly indicates there has been a problem, or take some other action.
正しく形成されていないCBORデータ項目に遭遇したデコーダーは、通常、完全にデコードに失敗する（エラーを発行する、または処理を完全に停止する）ことを選択できます。問題が発生したか、他のアクションを実行してください。
The representation of a CBOR data item has a specific length, determined by its initial bytes and by the structure of any data items enclosed in the data items. If less data is available, this can be treated as a syntax error. A decoder may also implement incremental parsing, that is, decode the data item as far as it is available and present the data found so far (such as in an event-based interface), with the option of continuing the decoding once further data is available.
CBORデータ項目の表現には特定の長さがあり、その初期バイトと、データ項目に含まれるデータ項目の構造によって決定されます。利用可能なデータが少ない場合、これは構文エラーとして処理できます。デコーダーは、インクリメンタル解析を実装することもできます。つまり、データアイテムが利用可能な限りデコードし、それまでに見つかったデータを（イベントベースのインターフェイスなどで）表示します。さらにデータがあるとデコードを続行するオプションがあります。利用可能です。
Examples of incomplete data items include:
不完全なデータアイテムの例は次のとおりです。
o A decoder expects a certain number of array or map entries but instead encounters the end of the data.
o デコーダは、特定の数の配列またはマップエントリを予期しますが、代わりにデータの終わりに到達します。
o A decoder processes what it expects to be the last pair in a map and comes to the end of the data.
o デコーダーは、マップ内の最後のペアであると予想されるものを処理し、データの最後に到達します。
o A decoder has just seen a tag and then encounters the end of the data.
o デコーダーがタグを見て、データの終わりに到達しました。
o A decoder has seen the beginning of an indefinite-length item but encounters the end of the data before it sees the "break" stop code.
o デコーダーが不定長アイテムの始まりを検出しましたが、「ブレーク」ストップコードを検出する前にデータの終わりを検出しました。
Examples of malformed indefinite-length data items include:
不正な形式の不定長データ項目の例には、次のものがあります。
o Within an indefinite-length byte string or text, a decoder finds an item that is not of the appropriate major type before it finds the "break" stop code.
o 不定長のバイト文字列またはテキスト内で、デコーダーは「ブレーク」ストップコードを見つける前に、適切なメジャータイプではないアイテムを見つけます。
o Within an indefinite-length map, a decoder encounters the "break" stop code immediately after reading a key (the value is missing).
o 不定長マップ内では、デコーダーはキーを読み取った直後に「ブレーク」停止コードに遭遇します（値が欠落しています）。
Another error is finding a "break" stop code at a point in the data where there is no immediately enclosing (unclosed) indefinite-length item.
もう1つのエラーは、データ内の、無限長のアイテムがすぐに囲まれていない（閉じられていない）箇所で「ブレーク」ストップコードを見つけることです。
At the time of writing, some additional information values are unassigned and reserved for future versions of this document (see Section 5.2). Since the overall syntax for these additional information values is not yet defined, a decoder that sees an additional information value that it does not understand cannot continue parsing.
執筆時点では、一部の追加情報の値は割り当てられておらず、このドキュメントの将来のバージョン用に予約されています（セクション5.2を参照）。これらの追加情報値の全体的な構文はまだ定義されていないため、理解できない追加情報値を参照するデコーダは解析を続行できません。
A CBOR data item may be syntactically well-formed but present a problem with interpreting the data encoded in it in the CBOR data model. Generally speaking, a decoder that finds a data item with such a problem might issue a warning, might stop processing altogether, might handle the error and make the problematic value available to the application as such, or take some other type of action.
CBORデータ項目は、構文的には整形式である可能性がありますが、CBORデータモデルでエンコードされたデータを解釈する際に問題が発生します。一般的に、このような問題のあるデータ項目を検出したデコーダーは、警告を発行したり、処理を完全に停止したり、エラーを処理して、問題のある値をアプリケーションで利用できるようにしたり、他のタイプのアクションを実行したりします。
Such problems might include:
このような問題には次のものがあります。
Duplicate keys in a map: Generic decoders (Section 3.2) make data available to applications using the native CBOR data model. That data model includes maps (key-value mappings with unique keys), not multimaps (key-value mappings where multiple entries can have the same key). Thus, a generic decoder that gets a CBOR map item that has duplicate keys will decode to a map with only one instance of that key, or it might stop processing altogether. On the other hand, a "streaming decoder" may not even be able to notice (Section 3.7).
マップ内の重複キー：ジェネリックデコーダー（セクション3.2）は、ネイティブCBORデータモデルを使用するアプリケーションでデータを利用できるようにします。そのデータモデルには、マルチマップ（複数のエントリが同じキーを持つことができるキー値マッピング）ではなく、マップ（一意のキーを持つキー値マッピング）が含まれます。したがって、重複するキーを持つCBORマップ項目を取得する汎用デコーダーは、そのキーのインスタンスが1つだけのマップにデコードするか、完全に処理を停止する可能性があります。一方、「ストリーミングデコーダー」は気付くことさえできない場合があります（セクション3.7）。
Inadmissible type on the value following a tag: Tags (Section 2.4) specify what type of data item is supposed to follow the tag; for example, the tags for positive or negative bignums are supposed to be put on byte strings. A decoder that decodes the tagged data item into a native representation (a native big integer in this example) is expected to check the type of the data item being tagged. Even decoders that don't have such native representations available in their environment may perform the check on those tags known to them and react appropriately.
タグに続く値に許可されないタイプ：タグ（セクション2.4）は、タグに続くデータ項目のタイプを指定します。たとえば、正または負のbignumのタグはバイト文字列に配置されることになっています。タグ付けされたデータ項目をネイティブ表現（この例ではネイティブの大きな整数）にデコードするデコーダーは、タグ付けされているデータ項目のタイプをチェックすることが期待されています。そのようなネイティブ表現を環境で利用できないデコーダでさえ、それらが知っているタグのチェックを実行し、適切に反応する可能性があります。
Invalid UTF-8 string: A decoder might or might not want to verify that the sequence of bytes in a UTF-8 string (major type 3) is actually valid UTF-8 and react appropriately.
無効なUTF-8文字列：デコーダーは、UTF-8文字列（メジャータイプ3）のバイトシーケンスが実際に有効なUTF-8であり、適切に反応することを確認する必要がある場合とない場合があります。
A decoder that comes across a simple value (Section 2.3) that it does not recognize, such as a value that was added to the IANA registry after the decoder was deployed or a value that the decoder chose not to implement, might issue a warning, might stop processing altogether, might handle the error by making the unknown value available to the application as such (as is expected of generic decoders), or take some other type of action.
デコーダーがデプロイされた後にIANAレジストリーに追加された値や、デコーダーが実装しないことを選択した値など、認識しない単純な値（セクション2.3）に遭遇したデコーダーは、警告を発行する場合があります。完全に処理を停止する、アプリケーションで不明な値をそのまま使用できるようにすることでエラーを処理する（一般的なデコーダーで予想されるように）、または他のタイプのアクションを実行する場合があります。
A decoder that comes across a tag (Section 2.4) that it does not recognize, such as a tag that was added to the IANA registry after the decoder was deployed or a tag that the decoder chose not to implement, might issue a warning, might stop processing altogether, might handle the error and present the unknown tag value together with the contained data item to the application (as is expected of generic decoders), might ignore the tag and simply present the contained data item only to the application, or take some other type of action.
デコーダーがデプロイされた後にIANAレジストリーに追加されたタグや、デコーダーが実装しないことを選択したタグなど、認識しないタグ（セクション2.4）に遭遇したデコーダーは、警告を発行したり、処理を完全に停止し、エラーを処理して、含まれているデータ項目と一緒に不明なタグ値をアプリケーションに提示したり（汎用デコーダーで予想されるように）、タグを無視して、含まれているデータ項目をアプリケーションにのみ提示したり、他のタイプのアクション。
For the purposes of this specification, all number representations for the same numeric value are equivalent. This means that an encoder can encode a floating-point value of 0.0 as the integer 0. It, however, also means that an application that expects to find integer values only might find floating-point values if the encoder decides these are desirable, such as when the floating-point value is more compact than a 64-bit integer.
この仕様では、同じ数値のすべての数値表現は同等です。これは、エンコーダーが浮動小数点値0.0を整数0としてエンコードできることを意味します。ただし、整数値を見つけることを期待するアプリケーションは、エンコーダーが望ましいと判断した場合にのみ浮動小数点値を見つける可能性があることも意味します。浮動小数点値が64ビット整数よりもコンパクトである場合と同様です。
An application or protocol that uses CBOR might restrict the representations of numbers. For instance, a protocol that only deals with integers might say that floating-point numbers may not be used and that decoders of that protocol do not need to be able to handle floating-point numbers. Similarly, a protocol or application that uses CBOR might say that decoders need to be able to handle either type of number.
CBORを使用するアプリケーションまたはプロトコルは、数値の表現を制限する場合があります。たとえば、整数のみを処理するプロトコルでは、浮動小数点数は使用できず、そのプロトコルのデコーダーは浮動小数点数を処理する必要がないと言う場合があります。同様に、CBORを使用するプロトコルまたはアプリケーションは、デコーダーがどちらのタイプの数値も処理できる必要があると言うかもしれません。
CBOR-based protocols should take into account that different language environments pose different restrictions on the range and precision of numbers that are representable. For example, the JavaScript number system treats all numbers as floating point, which may result in silent loss of precision in decoding integers with more than 53 significant bits. A protocol that uses numbers should define its expectations on the handling of non-trivial numbers in decoders and receiving applications.
CBORベースのプロトコルでは、表現可能な数値の範囲と精度に異なる言語環境が異なる制約を課すことを考慮に入れる必要があります。たとえば、JavaScriptの数値システムはすべての数値を浮動小数点として扱います。これにより、53を超える有効ビットを持つ整数のデコードで精度が低下する可能性があります。数値を使用するプロトコルは、デコーダーと受信アプリケーションでの重要な数値の処理に対する期待を定義する必要があります。
A CBOR-based protocol that includes floating-point numbers can restrict which of the three formats (half-precision, single-precision, and double-precision) are to be supported. For an integer-only application, a protocol may want to completely exclude the use of floating-point values.
浮動小数点数を含むCBORベースのプロトコルは、3つの形式（半精度、単精度、倍精度）のどれをサポートするかを制限できます。整数のみのアプリケーションの場合、プロトコルは浮動小数点値の使用を完全に除外したい場合があります。
A CBOR-based protocol designed for compactness may want to exclude specific integer encodings that are longer than necessary for the application, such as to save the need to implement 64-bit integers. There is an expectation that encoders will use the most compact integer representation that can represent a given value. However, a compact application should accept values that use a longer-than-needed encoding (such as encoding "0" as 0b000_11101 followed by two bytes of 0x00) as long as the application can decode an integer of the given size.
コンパクト化のために設計されたCBORベースのプロトコルは、64ビット整数を実装する必要性を節約するなど、アプリケーションに必要な長さよりも長い特定の整数エンコーディングを除外したい場合があります。エンコーダーは、特定の値を表すことができる最もコンパクトな整数表現を使用することが期待されています。ただし、アプリケーションが指定されたサイズの整数をデコードできる限り、コンパクトなアプリケーションは、必要以上に長いエンコーディング（「0」を0b000_11101としてエンコードし、その後に2バイトの0x00をエンコードするなど）を使用する値を受け入れる必要があります。
The encoding and decoding applications need to agree on what types of keys are going to be used in maps. In applications that need to interwork with JSON-based applications, keys probably should be limited to UTF-8 strings only; otherwise, there has to be a specified mapping from the other CBOR types to Unicode characters, and this often leads to implementation errors. In applications where keys are numeric in nature and numeric ordering of keys is important to the application, directly using the numbers for the keys is useful.
エンコードおよびデコードアプリケーションは、マップで使用されるキーの種類について合意する必要があります。 JSONベースのアプリケーションと連携する必要があるアプリケーションでは、キーはおそらくUTF-8文字列のみに制限する必要があります。それ以外の場合は、他のCBORタイプからUnicode文字への指定されたマッピングが必要であり、これにより実装エラーが発生することがよくあります。キーが本質的に数値であり、キーの番号順がアプリケーションにとって重要であるアプリケーションでは、キーの番号を直接使用すると便利です。
If multiple types of keys are to be used, consideration should be given to how these types would be represented in the specific programming environments that are to be used. For example, in JavaScript objects, a key of integer 1 cannot be distinguished from a key of string "1". This means that, if integer keys are used, the simultaneous use of string keys that look like numbers needs to be avoided. Again, this leads to the conclusion that keys should be of a single CBOR type.
複数のタイプのキーを使用する場合は、使用する特定のプログラミング環境でこれらのタイプがどのように表されるかを考慮する必要があります。たとえば、JavaScriptオブジェクトでは、整数1のキーは文字列 "1"のキーと区別できません。つまり、整数キーを使用する場合は、数字のように見える文字列キーを同時に使用しないようにする必要があります。この場合も、キーは単一のCBORタイプである必要があるという結論につながります。
Decoders that deliver data items nested within a CBOR data item immediately on decoding them ("streaming decoders") often do not keep the state that is necessary to ascertain uniqueness of a key in a map. Similarly, an encoder that can start encoding data items before the enclosing data item is completely available ("streaming encoder") may want to reduce its overhead significantly by relying on its data source to maintain uniqueness.
CBORデータ項目内にネストされたデータ項目をそれらのデコードと同時に配信するデコーダー（「ストリーミングデコーダー」）は、マップ内のキーの一意性を確認するために必要な状態を維持しないことがよくあります。同様に、囲んでいるデータアイテムが完全に利用可能になる前にデータアイテムのエンコードを開始できるエンコーダー（「ストリーミングエンコーダー」）は、データソースに依存して一意性を維持することにより、オーバーヘッドを大幅に削減したい場合があります。
A CBOR-based protocol should make an intentional decision about what to do when a receiving application does see multiple identical keys in a map. The resulting rule in the protocol should respect the CBOR data model: it cannot prescribe a specific handling of the entries with the identical keys, except that it might have a rule that having identical keys in a map indicates a malformed map and that the decoder has to stop with an error. Duplicate keys are also prohibited by CBOR decoders that are using strict mode (Section 3.10).
CBORベースのプロトコルは、受信アプリケーションがマップ内で複数の同一のキーを見つけたときに何をすべきかについて、意図的に決定する必要があります。結果として得られるプロトコルのルールはCBORデータモデルを尊重する必要があります。マップ内に同じキーを持つことは不正なマップを示し、デコーダーにエラーで停止します。ストリクトモードを使用しているCBORデコーダーでも重複キーは禁止されています（セクション3.10）。
The CBOR data model for maps does not allow ascribing semantics to the order of the key/value pairs in the map representation. Thus, it would be a very bad practice to define a CBOR-based protocol in such a way that changing the key/value pair order in a map would change the semantics, apart from trivial aspects (cache usage, etc.). (A CBOR-based protocol can prescribe a specific order of serialization, such as for canonicalization.)
マップのCBORデータモデルでは、セマンティクスをマップ表現のキー/値ペアの順序に割り当てることができません。したがって、マップ内のキーと値のペアの順序を変更すると、些細な側面（キャッシュの使用など）とは別に、セマンティクスが変更されるような方法でCBORベースのプロトコルを定義することは、非常に悪い習慣です。 （CBORベースのプロトコルは、正規化などの特定のシリアル化順序を規定できます。）
Applications for constrained devices that have maps with 24 or fewer frequently used keys should consider using small integers (and those with up to 48 frequently used keys should consider also using small negative integers) because the keys can then be encoded in a single byte.
頻繁に使用されるキーが24以下のマップを持つ制約付きデバイスのアプリケーションでは、小さい整数の使用を検討する必要があります（頻繁に使用されるキーが最大48のアプリケーションでは、小さい負の整数の使用も検討する必要があります）。これにより、キーを1バイトでエンコードできるようになります。
In some CBOR-based protocols, the simple value (Section 2.3) of Undefined might be used by an encoder as a substitute for a data item with an encoding problem, in order to allow the rest of the enclosing data items to be encoded without harm.
一部のCBORベースのプロトコルでは、Undefinedの単純な値（セクション2.3）が、残りのデータ項目を害することなくエンコードできるようにするために、エンコードの問題があるデータ項目の代わりとしてエンコーダーによって使用される場合があります。 。
Some protocols may want encoders to only emit CBOR in a particular canonical format; those protocols might also have the decoders check that their input is canonical. Those protocols are free to define what they mean by a canonical format and what encoders and decoders are expected to do. This section lists some suggestions for such protocols.
一部のプロトコルでは、エンコーダーが特定の正規形式のCBORのみを発行するように要求する場合があります。これらのプロトコルでは、入力が正規であることをデコーダーにチェックさせる場合もあります。これらのプロトコルは、標準的な形式でそれらが何を意味するか、およびエンコーダーとデコーダーが何をすることが期待されるかを自由に定義できます。このセクションでは、そのようなプロトコルに関するいくつかの提案を示します。
If a protocol considers "canonical" to mean that two encoder implementations starting with the same input data will produce the same CBOR output, the following four rules would suffice:
プロトコルが「正規」と見なし、同じ入力データで始まる2つのエンコーダー実装が同じCBOR出力を生成することを意味する場合、次の4つのルールで十分です。
o Integers must be as small as possible.
o 整数はできるだけ小さくする必要があります。
* 0 to 23 and -1 to -24 must be expressed in the same byte as the
major type;
* 24 to 255 and -25 to -256 must be expressed only with an
additional uint8_t;
* 256 to 65535 and -257 to -65536 must be expressed only with an
additional uint16_t;
* 65536 to 4294967295 and -65537 to -4294967296 must be expressed only with an additional uint32_t.
* 65536〜4294967295および-65537〜-4294967296は、uint32_tを追加する場合にのみ表現する必要があります。
o The expression of lengths in major types 2 through 5 must be as short as possible. The rules for these lengths follow the above rule for integers.
o 主要なタイプ2から5の長さの表現は、できるだけ短くする必要があります。これらの長さの規則は、整数の上記の規則に従います。
o The keys in every map must be sorted lowest value to highest. Sorting is performed on the bytes of the representation of the key data items without paying attention to the 3/5 bit splitting for major types. (Note that this rule allows maps that have keys of different types, even though that is probably a bad practice that could lead to errors in some canonicalization implementations.) The sorting rules are:
o すべてのマップのキーは、最低値から最高値にソートする必要があります。主要なタイプの3/5ビット分割に注意を払わずに、キーデータ項目の表現のバイトでソートが実行されます。 （このルールでは、異なるタイプのキーを持つマップが許可されますが、これはおそらく一部の正規化実装でエラーにつながる可能性がある悪い習慣です）。並べ替えルールは次のとおりです。
* If two keys have different lengths, the shorter one sorts earlier;
* 2つのキーの長さが異なる場合、短い方のキーが先にソートされます。
* If two keys have the same length, the one with the lower value in (byte-wise) lexical order sorts earlier.
* 2つのキーが同じ長さの場合、（バイト単位の）字句順で値が小さい方が先にソートされます。
o Indefinite-length items must be made into definite-length items.
o 不定長アイテムは、定長アイテムにする必要があります。
If a protocol allows for IEEE floats, then additional canonicalization rules might need to be added. One example rule might be to have all floats start as a 64-bit float, then do a test conversion to a 32-bit float; if the result is the same numeric value, use the shorter value and repeat the process with a test conversion to a 16-bit float. (This rule selects 16-bit float for positive and negative Infinity as well.) Also, there are many representations for NaN. If NaN is an allowed value, it must always be represented as 0xf97e00.
プロトコルでIEEE浮動小数点数が許可されている場合は、正規化ルールを追加する必要があります。ルールの1つの例として、すべてのフロートを64ビットのフロートとして開始し、次に32ビットのフロートにテスト変換することができます。結果が同じ数値の場合は、短い方の値を使用して、16ビット浮動小数点へのテスト変換でプロセスを繰り返します。 （このルールは、正と負の無限大にも16ビット浮動小数点を選択します。）また、NaNには多くの表現があります。 NaNが許容値の場合、常に0xf97e00として表す必要があります。
CBOR tags present additional considerations for canonicalization. The absence or presence of tags in a canonical format is determined by the optionality of the tags in the protocol. In a CBOR-based protocol that allows optional tagging anywhere, the canonical format must not allow them. In a protocol that requires tags in certain places, the tag needs to appear in the canonical format. A CBOR-based protocol that uses canonicalization might instead say that all tags that appear in a message must be retained regardless of whether they are optional.
CBORタグは、正規化に関する追加の考慮事項を示します。正規形式のタグの有無は、プロトコルのタグのオプション性によって決まります。どこでもオプションのタグ付けを許可するCBORベースのプロトコルでは、標準形式で許可されてはなりません。特定の場所にタグを必要とするプロトコルでは、タグを正規の形式で表示する必要があります。正規化を使用するCBORベースのプロトコルでは、代わりに、メッセージに表示されるすべてのタグは、それらがオプションかどうかに関係なく保持する必要があると言います。
Some areas of application of CBOR do not require canonicalization (Section 3.9) but may require that different decoders reach the same (semantically equivalent) results, even in the presence of potentially malicious data. This can be required if one application (such as a firewall or other protecting entity) makes a decision based on the data that another application, which independently decodes the data, relies on.
CBORの適用の一部の領域では、正規化は必要ありませんが（3.9節）、悪意のあるデータが存在する場合でも、異なるデコーダーが同じ（意味的に同等）の結果に到達する必要があります。これは、1つのアプリケーション（ファイアウォールやその他の保護エンティティなど）が、データを個別にデコードする別のアプリケーションが依存するデータに基づいて決定を行う場合に必要になることがあります。
Normally, it is the responsibility of the sender to avoid ambiguously decodable data. However, the sender might be an attacker specially making up CBOR data such that it will be interpreted differently by different decoders in an attempt to exploit that as a vulnerability. Generic decoders used in applications where this might be a problem need to support a strict mode in which it is also the responsibility of the receiver to reject ambiguously decodable data. It is expected that firewalls and other security systems that decode CBOR will only decode in strict mode.
通常、あいまいにデコード可能なデータを回避するのは送信者の責任です。ただし、送信者は、CBORデータを特別に作成する攻撃者である可能性があり、それを脆弱性として悪用しようとするさまざまなデコーダーによって異なる解釈が行われます。これが問題になる可能性のあるアプリケーションで使用される汎用デコーダーは、あいまいにデコード可能なデータを拒否することもレシーバーの責任である厳密モードをサポートする必要があります。 CBORをデコードするファイアウォールやその他のセキュリティシステムは、ストリクトモードでのみデコードされることが予想されます。
A decoder in strict mode will reliably reject any data that could be interpreted by other decoders in different ways. It will reliably reject data items with syntax errors (Section 3.3). It will also expend the effort to reliably detect other decoding errors (Section 3.4). In particular, a strict decoder needs to have an API that reports an error (and does not return data) for a CBOR data item that contains any of the following:
ストリクトモードのデコーダーは、他のデコーダーがさまざまな方法で解釈できるデータを確実に拒否します。構文エラーのあるデータ項目を確実に拒否します（セクション3.3）。また、他のデコードエラーを確実に検出するための労力も費やします（セクション3.4）。特に、厳密なデコーダーには、次のいずれかを含むCBORデータ項目のエラーを報告する（データを返さない）APIが必要です。
o a map (major type 5) that has more than one entry with the same key
o 同じキーを持つ複数のエントリを持つマップ（メジャータイプ5）
o a tag that is used on a data item of the incorrect type
o 不正なタイプのデータ項目で使用されているタグ
o a data item that is incorrectly formatted for the type given to it, such as invalid UTF-8 or data that cannot be interpreted with the specific tag that it has been tagged with
o 無効なUTF-8や、タグが付けられた特定のタグで解釈できないデータなど、指定されたタイプに対して正しくフォーマットされていないデータ項目
A decoder in strict mode can do one of two things when it encounters a tag or simple value that it does not recognize:
strictモードのデコーダーは、認識できないタグまたは単純な値を検出すると、次の2つのいずれかを実行できます。
o It can report an error (and not return data).
o エラーを報告する可能性があります（データを返しません）。
o It can emit the unknown item (type, value, and, for tags, the decoded tagged data item) to the application calling the decoder with an indication that the decoder did not recognize that tag or simple value.
o 不明なアイテム（タイプ、値、およびタグの場合は、デコードされたタグ付きデータアイテム）を、デコーダーがそのタグまたは単純な値を認識しなかったことを示すデコーダーを呼び出すアプリケーションに送信できます。
The latter approach, which is also appropriate for non-strict decoders, supports forward compatibility with newly registered tags and simple values without the requirement to update the encoder at the same time as the calling application. (For this, the API for the decoder needs to have a way to mark unknown items so that the calling application can handle them in a manner appropriate for the program.)
厳密でないデコーダーにも適切な後者のアプローチは、呼び出し元のアプリケーションと同時にエンコーダーを更新する必要なしに、新しく登録されたタグと単純な値との上位互換性をサポートします。 （このため、デコーダーのAPIには、未知の項目をマークする方法が必要です。これにより、呼び出し側アプリケーションは、プログラムに適した方法でそれらを処理できます。）
Since some of this processing may have an appreciable cost (in particular with duplicate detection for maps), support of strict mode is not a requirement placed on all CBOR decoders.
この処理の一部にはかなりのコストがかかる可能性があるため（特にマップの重複検出の場合）、厳密モードのサポートはすべてのCBORデコーダーに課せられた要件ではありません。
Some encoders will rely on their applications to provide input data in such a way that unambiguously decodable CBOR results. A generic encoder also may want to provide a strict mode where it reliably limits its output to unambiguously decodable CBOR, independent of whether or not its application is providing API-conformant data.
一部のエンコーダーは、アプリケーションに依存して、明確にデコード可能なCBORが生成されるような方法で入力データを提供します。汎用エンコーダーは、アプリケーションがAPI準拠のデータを提供しているかどうかに関係なく、出力を明確にデコード可能なCBORに確実に制限する厳密モードを提供することもできます。
This section gives non-normative advice about converting between CBOR and JSON. Implementations of converters are free to use whichever advice here they want.
このセクションでは、CBORとJSON間の変換に関する非規範的なアドバイスを提供します。コンバーターの実装は、ここで必要なアドバイスを自由に使用できます。
It is worth noting that a JSON text is a sequence of characters, not an encoded sequence of bytes, while a CBOR data item consists of bytes, not characters.
JSONテキストは文字のシーケンスであり、バイトのエンコードされたシーケンスではないことに注意してください。CBORデータ項目は、文字ではなくバイトで構成されています。
Most of the types in CBOR have direct analogs in JSON. However, some do not, and someone implementing a CBOR-to-JSON converter has to consider what to do in those cases. The following non-normative advice deals with these by converting them to a single substitute value, such as a JSON null.
CBORのタイプのほとんどは、JSONに直接類似しています。ただし、そうでないものもあり、CBOR-JSONコンバーターを実装する誰かがそのような場合に何をするかを検討する必要があります。次の非規範的なアドバイスは、JSON nullなどの単一の代替値に変換することでこれらを扱います。
o An integer (major type 0 or 1) becomes a JSON number.
o 整数（メジャータイプ0または1）はJSON番号になります。
o A byte string (major type 2) that is not embedded in a tag that specifies a proposed encoding is encoded in base64url without padding and becomes a JSON string.
o 提案されたエンコーディングを指定するタグに埋め込まれていないバイト文字列（メジャータイプ2）は、パディングなしでbase64urlでエンコードされ、JSON文字列になります。
o A UTF-8 string (major type 3) becomes a JSON string. Note that JSON requires escaping certain characters (RFC 4627, Section 2.5): quotation mark (U+0022), reverse solidus (U+005C), and the "C0 control characters" (U+0000 through U+001F). All other characters are copied unchanged into the JSON UTF-8 string.
o UTF-8文字列（メジャータイプ3）はJSON文字列になります。 JSONでは特定の文字（RFC 4627、セクション2.5）をエスケープする必要があることに注意してください：引用符（U + 0022）、逆ソリダス（U + 005C）、および「C0制御文字」（U + 0000からU + 001F）。他のすべての文字は変更されずにJSON UTF-8文字列にコピーされます。
o An array (major type 4) becomes a JSON array.
o 配列（メジャータイプ4）はJSON配列になります。
o A map (major type 5) becomes a JSON object. This is possible directly only if all keys are UTF-8 strings. A converter might also convert other keys into UTF-8 strings (such as by converting integers into strings containing their decimal representation); however, doing so introduces a danger of key collision.
o マップ（メジャータイプ5）はJSONオブジェクトになります。これは、すべてのキーがUTF-8文字列である場合にのみ直接可能です。コンバーターは、他のキーをUTF-8文字列に変換する場合もあります（整数を10進表記を含む文字列に変換するなど）。ただし、これを行うと、キーが衝突する危険があります。
o False (major type 7, additional information 20) becomes a JSON false.
o False（メジャータイプ7、追加情報20）はJSON falseになります。
o True (major type 7, additional information 21) becomes a JSON true.
o True（メジャータイプ7、追加情報21）はJSON Trueになります。
o Null (major type 7, additional information 22) becomes a JSON null.
o null（メジャータイプ7、追加情報22）はJSON nullになります。
o A floating-point value (major type 7, additional information 25 through 27) becomes a JSON number if it is finite (that is, it can be represented in a JSON number); if the value is non-finite (NaN, or positive or negative Infinity), it is represented by the substitute value.
o 浮動小数点値（メジャータイプ7、追加情報25〜27）が有限の場合、JSON番号になります（つまり、JSON番号で表すことができます）。値が非有限（NaN、または正または負の無限大）の場合は、代替値で表されます。
o Any other simple value (major type 7, any additional information value not yet discussed) is represented by the substitute value.
o その他の単純な値（メジャータイプ7、まだ説明されていない追加情報値）は、代替値によって表されます。
o A bignum (major type 6, tag value 2 or 3) is represented by encoding its byte string in base64url without padding and becomes a JSON string. For tag value 3 (negative bignum), a "~" (ASCII tilde) is inserted before the base-encoded value. (The conversion to a binary blob instead of a number is to prevent a likely numeric overflow for the JSON decoder.)
o bignum（メジャータイプ6、タグ値2または3）は、そのバイト文字列をパディングなしでbase64urlにエンコードすることによって表され、JSON文字列になります。タグ値3（負のbignum）の場合、ベースエンコードされた値の前に「〜」（ASCIIチルド）が挿入されます。 （数値の代わりにバイナリBLOBに変換するのは、JSONデコーダーの数値オーバーフローを防ぐためです。）
o A byte string with an encoding hint (major type 6, tag value 21 through 23) is encoded as described and becomes a JSON string.
o エンコーディングヒント（メジャータイプ6、タグ値21〜23）を含むバイト文字列は、説明どおりにエンコードされ、JSON文字列になります。
o For all other tags (major type 6, any other tag value), the embedded CBOR item is represented as a JSON value; the tag value is ignored.
o その他すべてのタグ（メジャータイプ6、その他のタグ値）の場合、埋め込まれたCBORアイテムはJSON値として表されます。タグ値は無視されます。
o Indefinite-length items are made definite before conversion.
o 不定長アイテムは、変換前に明確にされます。
All JSON values, once decoded, directly map into one or more CBOR values. As with any kind of CBOR generation, decisions have to be made with respect to number representation. In a suggested conversion: o JSON numbers without fractional parts (integer numbers) are represented as integers (major types 0 and 1, possibly major type 6 tag value 2 and 3), choosing the shortest form; integers longer than an implementation-defined threshold (which is usually either 32 or 64 bits) may instead be represented as floating-point values. (If the JSON was generated from a JavaScript implementation, its precision is already limited to 53 bits maximum.)
すべてのJSON値は、デコードされると、1つ以上のCBOR値に直接マッピングされます。あらゆる種類のCBOR生成と同様に、数値表現に関して決定を行う必要があります。推奨される変換：o小数部分のないJSON番号（整数）は、整数（メジャータイプ0および1、場合によってはメジャータイプ6タグ値2および3）として表され、最も短い形式を選択します。代わりに、実装で定義されたしきい値（通常は32ビットまたは64ビット）より長い整数は、浮動小数点値として表すことができます。 （JSONがJavaScript実装から生成された場合、その精度はすでに最大53ビットに制限されています。）
o Numbers with fractional parts are represented as floating-point values. Preferably, the shortest exact floating-point representation is used; for instance, 1.5 is represented in a 16-bit floating-point value (not all implementations will be capable of efficiently finding the minimum form, though). There may be an implementation-defined limit to the precision that will affect the precision of the represented values. Decimal representation should only be used if that is specified in a protocol.
o 小数部分を持つ数値は、浮動小数点値として表されます。好ましくは、最短の正確な浮動小数点表現が使用される。たとえば、1.5は16ビット浮動小数点値で表されます（ただし、すべての実装が最小形式を効率的に見つけることができるわけではありません）。表現される値の精度に影響を与える、実装定義の精度制限がある場合があります。 10進数表現は、プロトコルで指定されている場合にのみ使用してください。
CBOR has been designed to generally provide a more compact encoding than JSON. One implementation strategy that might come to mind is to perform a JSON-to-CBOR encoding in place in a single buffer. This strategy would need to carefully consider a number of pathological cases, such as that some strings represented with no or very few escapes and longer (or much longer) than 255 bytes may expand when encoded as UTF-8 strings in CBOR. Similarly, a few of the binary floating-point representations might cause expansion from some short decimal representations (1.1, 1e9) in JSON. This may be hard to get right, and any ensuing vulnerabilities may be exploited by an attacker.
CBORは通常、JSONよりもコンパクトなエンコーディングを提供するように設計されています。頭に浮かぶかもしれない実装戦略の1つは、JSONからCBORへのエンコーディングを単一のバッファーで実行することです。この戦略では、いくつかの病理学的なケースを慎重に検討する必要があります。たとえば、CBORでUTF-8文字列としてエンコードされると、エスケープなしまたはエスケープがほとんどなく、255バイトより長い（またははるかに長い）文字列が拡張されることがあります。同様に、少数の2進浮動小数点表現は、JSONの一部の短い10進数表現（1.1、1e9）から拡張される可能性があります。これを正しく行うのは困難な場合があり、その後に続く脆弱性は攻撃者によって悪用される可能性があります。
Successful protocols evolve over time. New ideas appear, implementation platforms improve, related protocols are developed and evolve, and new requirements from applications and protocols are added. Facilitating protocol evolution is therefore an important design consideration for any protocol development.
成功するプロトコルは時間とともに進化します。新しいアイデアが現れ、実装プラットフォームが改善され、関連するプロトコルが開発および進化し、アプリケーションとプロトコルからの新しい要件が追加されます。したがって、プロトコルの進化を促進することは、あらゆるプロトコル開発において重要な設計上の考慮事項です。
For protocols that will use CBOR, CBOR provides some useful mechanisms to facilitate their evolution. Best practices for this are well known, particularly from JSON format development of JSON-based protocols. Therefore, such best practices are outside the scope of this specification.
CBORを使用するプロトコルの場合、CBORはその進化を促進するためのいくつかの有用なメカニズムを提供します。このためのベストプラクティスは、特にJSONベースのプロトコルのJSON形式の開発でよく知られています。したがって、そのようなベストプラクティスはこの仕様の範囲外です。
However, facilitating the evolution of CBOR itself is very well within its scope. CBOR is designed to both provide a stable basis for development of CBOR-based protocols and to be able to evolve.
ただし、CBOR自体の進化を促進することは、その範囲内に十分含まれています。 CBORは、CBORベースのプロトコルを開発するための安定した基盤を提供し、進化できるように設計されています。
Since a successful protocol may live for decades, CBOR needs to be designed for decades of use and evolution. This section provides some guidance for the evolution of CBOR. It is necessarily more subjective than other parts of this document. It is also necessarily incomplete, lest it turn into a textbook on protocol development.
成功したプロトコルは何十年も存続する可能性があるため、CBORは数十年の使用と進化のために設計する必要があります。このセクションでは、CBORの進化に関するいくつかのガイダンスを示します。それは必然的にこのドキュメントの他の部分より主観的です。また、プロトコル開発の教科書にならないように、必ずしも不完全です。
In a protocol design, opportunities for evolution are often included in the form of extension points. For example, there may be a codepoint space that is not fully allocated from the outset, and the protocol is designed to tolerate and embrace implementations that start using more codepoints than initially allocated.
プロトコル設計では、拡張の機会が拡張ポイントの形式で含まれることがよくあります。たとえば、最初から完全に割り当てられていないコードポイントスペースがあり、プロトコルは、最初に割り当てられたよりも多くのコードポイントの使用を開始する実装を許容および採用するように設計されています。
Sizing the codepoint space may be difficult because the range required may be hard to predict. An attempt should be made to make the codepoint space large enough so that it can slowly be filled over the intended lifetime of the protocol.
必要な範囲を予測するのが難しい場合があるため、コードポイントスペースのサイズ変更は難しい場合があります。コードポイントのスペースを十分に大きくして、プロトコルの意図された存続期間にわたってゆっくりと埋められるようにする必要があります。
CBOR has three major extension points:
CBORには3つの主要な拡張ポイントがあります。
o the "simple" space (values in major type 7). Of the 24 efficient (and 224 slightly less efficient) values, only a small number have been allocated. Implementations receiving an unknown simple data item may be able to process it as such, given that the structure of the value is indeed simple. The IANA registry in Section 7.1 is the appropriate way to address the extensibility of this codepoint space.
o 「単純な」スペース（メジャータイプ7の値）。 24個の効率的な（そして224個のわずかに効率が低い）値のうち、割り当てられているのは少数です。未知の単純なデータ項目を受け取る実装は、値の構造が実際に単純である場合、それ自体を処理できる可能性があります。セクション7.1のIANAレジストリは、このコードポイントスペースの拡張性に対処する適切な方法です。
o the "tag" space (values in major type 6). Again, only a small part of the codepoint space has been allocated, and the space is abundant (although the early numbers are more efficient than the later ones). Implementations receiving an unknown tag can choose to simply ignore it or to process it as an unknown tag wrapping the following data item. The IANA registry in Section 7.2 is the appropriate way to address the extensibility of this codepoint space.
o 「タグ」スペース（メジャータイプ6の値）。繰り返しになりますが、コードポイントスペースのごく一部のみが割り当てられており、スペースは豊富です（ただし、初期の数値は後の数値よりも効率的です）。不明なタグを受信する実装は、単にそれを無視するか、次のデータ項目をラップする不明なタグとして処理するかを選択できます。セクション7.2のIANAレジストリは、このコードポイントスペースの拡張性に対処する適切な方法です。
o the "additional information" space. An implementation receiving an unknown additional information value has no way to continue parsing, so allocating codepoints to this space is a major step. There are also very few codepoints left.
o 「追加情報」スペース。不明な追加情報の値を受け取った実装では、解析を続行する方法がないため、このスペースにコードポイントを割り当てることは大きなステップです。残りのコードポイントもほとんどありません。
The human mind is sometimes drawn to filling in little perceived gaps to make something neat. We expect the remaining gaps in the codepoint space for the additional information values to be an attractor for new ideas, just because they are there.
人間の心は、知覚された小さなギャップを埋めて何かをきちんとすることに時々引き寄せられます。コードポイント空間に残っている、追加情報の値のギャップは、そこにあるからといって、新しいアイデアを引き寄せると期待しています。
The present specification does not manage the additional information codepoint space by an IANA registry. Instead, allocations out of this space can only be done by updating this specification.
現在の仕様では、IANAレジストリによる追加情報コードポイントスペースは管理されていません。代わりに、このスペースからの割り当ては、この仕様を更新することによってのみ行うことができます。
For an additional information value of n >= 24, the size of the additional data typically is 2**(n-24) bytes. Therefore, additional information values 28 and 29 should be viewed as candidates for 128-bit and 256-bit quantities, in case a need arises to add them to the protocol. Additional information value 30 is then the only additional information value available for general allocation, and there should be a very good reason for allocating it before assigning it through an update of this protocol.
n> = 24の追加情報値の場合、通常、追加データのサイズは2 **（n-24）バイトです。したがって、追加の情報値28および29は、プロトコルに追加する必要が生じた場合に備えて、128ビットおよび256ビットの数量の候補と見なす必要があります。追加情報値30は、一般的な割り当てに使用できる唯一の追加情報値であり、このプロトコルの更新を通じて割り当てる前に、割り当てる適切な理由があるはずです。
CBOR is a binary interchange format. To facilitate documentation and debugging, and in particular to facilitate communication between entities cooperating in debugging, this section defines a simple human-readable diagnostic notation. All actual interchange always happens in the binary format.
CBORはバイナリ交換形式です。文書化とデバッグを容易にするために、特にデバッグで協力するエンティティ間の通信を容易にするために、このセクションでは、人間が読める簡単な診断表記法を定義します。すべての実際の交換は常にバイナリ形式で行われます。
Note that this truly is a diagnostic format; it is not meant to be parsed. Therefore, no formal definition (as in ABNF) is given in this document. (Implementers looking for a text-based format for representing CBOR data items in configuration files may also want to consider YAML [YAML].)
これは本当に診断フォーマットであることに注意してください。解析するためのものではありません。したがって、この文書では正式な定義（ABNFなど）は提供されていません。 （設定ファイルでCBORデータ項目を表すためのテキストベースのフォーマットを探している実装者も、YAML [YAML]を検討する必要があるかもしれません。）
The diagnostic notation is loosely based on JSON as it is defined in RFC 4627, extending it where needed.
診断表記はRFC 4627で定義されているJSONに大まかに基づいており、必要に応じて拡張されます。
The notation borrows the JSON syntax for numbers (integer and floating point), True (>true<), False (>false<), Null (>null<), UTF-8 strings, arrays, and maps (maps are called objects in JSON; the diagnostic notation extends JSON here by allowing any data item in the key position). Undefined is written >undefined< as in JavaScript. The non-finite floating-point numbers Infinity, -Infinity, and NaN are written exactly as in this sentence (this is also a way they can be written in JavaScript, although JSON does not allow them). A tagged item is written as an integer number for the tag followed by the item in parentheses; for instance, an RFC 3339 (ISO 8601) date could be notated as:
表記は、数値（整数および浮動小数点）、True（> true <）、False（> false <）、Null（> null <）、UTF-8文字列、配列、およびマップ（マップはオブジェクトと呼ばれます）のJSON構文を借用しますJSONでは、診断表記はここでJSONを拡張し、キーの位置に任意のデータ項目を許可します）。 Undefinedは、JavaScriptのように> undefined <と記述されます。非有限浮動小数点数のInfinity、-Infinity、およびNaNは、この文とまったく同じように記述されます（これは、JSONでは許可されていませんが、JavaScriptで記述できる方法でもあります）。タグ付きアイテムは、タグの整数として記述され、その後に括弧内のアイテムが続きます。たとえば、RFC 3339（ISO 8601）の日付は次のように表記できます。
0("2013-03-21T20:04:00Z")
or the equivalent relative time as
または同等の相対時間
1(1363896240)
１（１３６３８９６２４０）
Byte strings are notated in one of the base encodings, without padding, enclosed in single quotes, prefixed by >h< for base16, >b32< for base32, >h32< for base32hex, >b64< for base64 or base64url (the actual encodings do not overlap, so the string remains unambiguous). For example, the byte string 0x12345678 could be written h'12345678', b32'CI2FM6A', or b64'EjRWeA'.
バイト文字列は、パディングなしのベースエンコーディングの1つで表記され、一重引用符で囲まれ、base16の場合は> h <、base32の場合は> b32 <、base32hexの場合は> h32 <、base64またはbase64urlの場合は> b64 <（実際のエンコーディング）重複しないようにして、文字列を明確にしてください）。たとえば、バイト文字列0x12345678は、h'12345678 '、b32'CI2FM6A'、またはb64'EjRWeA 'と書き込むことができます。
Unassigned simple values are given as "simple()" with the appropriate integer in the parentheses. For example, "simple(42)" indicates major type 7, value 42.
割り当てられていない単純な値は、括弧内に適切な整数を含む「simple()」として与えられます。たとえば、「simple（42）」はメジャータイプ7、値42を示します。
Sometimes it is useful to indicate in the diagnostic notation which of several alternative representations were actually used; for example, a data item written >1.5< by a diagnostic decoder might have been encoded as a half-, single-, or double-precision float.
いくつかの代替表現のうち実際に使用されたものを診断表記で示すと便利な場合があります。たとえば、診断デコーダーによって> 1.5 <と記述されたデータ項目は、半精度、単精度、または倍精度の浮動小数点数としてエンコードされている可能性があります。
The convention for encoding indicators is that anything starting with an underscore and all following characters that are alphanumeric or underscore, is an encoding indicator, and can be ignored by anyone not interested in this information. Encoding indicators are always optional.
エンコードインジケータの規則は、アンダースコアで始まり、その後に続くすべての文字が英数字またはアンダースコアであるものはすべてエンコードインジケータであり、この情報に関心がない人は無視できるということです。エンコーディングインジケータは常にオプションです。
A single underscore can be written after the opening brace of a map or the opening bracket of an array to indicate that the data item was represented in indefinite-length format. For example, [_ 1, 2] contains an indicator that an indefinite-length representation was used to represent the data item [1, 2].
マップの左中括弧または配列の左大括弧の後に単一の下線を書き込んで、データ項目が不定長形式で表されたことを示すことができます。たとえば、[_ 1、2]には、データ項目[1、2]を表すために不定長表現が使用されたことを示すインジケーターが含まれています。
An underscore followed by a decimal digit n indicates that the preceding item (or, for arrays and maps, the item starting with the preceding bracket or brace) was encoded with an additional information value of 24+n. For example, 1.5_1 is a half-precision floating-point number, while 1.5_3 is encoded as double precision. This encoding indicator is not shown in Appendix A. (Note that the encoding indicator "_" is thus an abbreviation of the full form "_7", which is not used.)
下線とそれに続く10進数nは、前の項目（または、配列とマップの場合は、前の大括弧または中括弧で始まる項目）が24 + nの追加情報値でエンコードされたことを示します。たとえば、1.5_1は半精度浮動小数点数ですが、1.5_3は倍精度としてエンコードされます。このエンコードインジケーターは付録Aには示されていません（したがって、エンコードインジケーター "_"は、完全な形式 "_7"の省略形であり、使用されていません）。
As a special case, byte and text strings of indefinite length can be notated in the form (_ h'0123', h'4567') and (_ "foo", "bar").
特別な場合として、不定の長さのバイトおよびテキスト文字列は、（_ h'0123 '、h'4567'）および（_ "foo"、 "bar"）の形式で表記できます。
IANA has created two registries for new CBOR values. The registries are separate, that is, not under an umbrella registry, and follow the rules in [RFC5226]. IANA has also assigned a new MIME media type and an associated Constrained Application Protocol (CoAP) Content-Format entry.
IANAは、新しいCBOR値用に2つのレジストリを作成しました。レジストリは独立している、つまり包括的なレジストリの下になく、[RFC5226]のルールに従います。 IANAはまた、新しいMIMEメディアタイプと関連するConstrained Application Protocol（CoAP）Content-Formatエントリを割り当てました。
IANA has created the "Concise Binary Object Representation (CBOR) Simple Values" registry. The initial values are shown in Table 2.
IANAは、「簡潔なバイナリオブジェクト表現（CBOR）の単純な値」レジストリを作成しました。初期値を表2に示します。
New entries in the range 0 to 19 are assigned by Standards Action. It is suggested that these Standards Actions allocate values starting with the number 16 in order to reserve the lower numbers for contiguous blocks (if any).
0〜19の範囲の新しいエントリは、標準アクションによって割り当てられます。これらの標準アクションは、連続するブロック（存在する場合）に小さい数値を予約するために、数値16で始まる値を割り当てることをお勧めします。
New entries in the range 32 to 255 are assigned by Specification Required.
32〜255の範囲の新しいエントリは、Specification Requiredによって割り当てられます。
IANA has created the "Concise Binary Object Representation (CBOR) Tags" registry. The initial values are shown in Table 3.
IANAは、「簡潔なバイナリオブジェクト表現（CBOR）タグ」レジストリを作成しました。初期値を表3に示します。
New entries in the range 0 to 23 are assigned by Standards Action. New entries in the range 24 to 255 are assigned by Specification Required. New entries in the range 256 to 18446744073709551615 are assigned by First Come First Served. The template for registration requests is:
0〜23の範囲の新しいエントリは、標準アクションによって割り当てられます。 24〜255の範囲の新しいエントリは、Specification Requiredによって割り当てられます。 256〜18446744073709551615の範囲の新しいエントリは、先着順で割り当てられます。登録リクエストのテンプレートは次のとおりです。
o Data item
o データ項目
o Semantics (short form)
o セマンティクス（短い形式）
In addition, First Come First Served requests should include:
さらに、先着順のリクエストには以下を含める必要があります。
o Point of contact
o 接点
o Description of semantics (URL) This description is optional; the URL can point to something like an Internet-Draft or a web page.
o セマンティクスの説明（URL）この説明はオプションです。 URLは、インターネットドラフトやWebページなどを指すことができます。
The Internet media type [RFC6838] for CBOR data is application/cbor.
CBORデータのインターネットメディアタイプ[RFC6838]は、application / cborです。
Type name: application
タイプ名：アプリケーション
Subtype name: cbor
サブタイプ名：cbor
Required parameters: n/a
必須パラメーター：なし
Optional parameters: n/a
オプションのパラメーター：n / a
Encoding considerations: binary
エンコーディングに関する考慮事項：バイナリ
Security considerations: See Section 8 of this document
セキュリティに関する考慮事項：このドキュメントのセクション8を参照してください
Interoperability considerations: n/a
相互運用性に関する考慮事項：なし
Published specification: This document
公開された仕様：このドキュメント
Applications that use this media type: None yet, but it is expected that this format will be deployed in protocols and applications.
このメディアタイプを使用するアプリケーション：まだありませんが、この形式がプロトコルとアプリケーションに展開されることが予想されます。
Additional information:
Magic number(s): n/a
File extension(s): .cbor
Macintosh file type code(s): n/a
Person & email address to contact for further information: Carsten Bormann cabo@tzi.org
詳細について連絡する人とメールアドレス：Carsten Bormann cabo@tzi.org
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: none
使用上の制限：なし
Author:
Carsten Bormann <cabo@tzi.org>
Change controller:
The IESG <iesg@ietf.org>
Media Type: application/cbor
メディアタイプ：application / cbor
Encoding: -
エンコーディング：-
Id: 60
Id：60
Reference: [RFC7049]
参照：[RFC7049]
Name: Concise Binary Object Representation (CBOR)
名前：簡潔なバイナリオブジェクト表現（CBOR）
+suffix: +cbor
References: [RFC7049]
参照：[RFC7049]
Encoding Considerations: CBOR is a binary format.
エンコーディングに関する考慮事項：CBORはバイナリ形式です。
Interoperability Considerations: n/a
相互運用性に関する考慮事項：なし
Fragment Identifier Considerations: The syntax and semantics of fragment identifiers specified for +cbor SHOULD be as specified for "application/cbor". (At publication of this document, there is no fragment identification syntax defined for "application/cbor".)
フラグメント識別子の考慮事項：+ cborに指定されたフラグメント識別子の構文とセマンティクスは、「application / cbor」に指定されたとおりである必要があります（SHOULD）。 （このドキュメントの公開時には、「application / cbor」に対して定義されたフラグメント識別構文はありません。）
The syntax and semantics for fragment identifiers for a specific "xxx/yyy+cbor" SHOULD be processed as follows:
特定の「xxx / yyy + cbor」のフラグメント識別子の構文とセマンティクスは、次のように処理する必要があります。
For cases defined in +cbor, where the fragment identifier resolves per the +cbor rules, then process as specified in +cbor.
+ cborで定義されたケースの場合、フラグメント識別子は+ cborルールに従って解決され、+ cborで指定されたとおりに処理されます。
For cases defined in +cbor, where the fragment identifier does not resolve per the +cbor rules, then process as specified in "xxx/yyy+cbor".
+ cborで定義されているケースで、フラグメント識別子が+ cborルールに従って解決されない場合は、「xxx / yyy + cbor」で指定されているように処理します。
For cases not defined in +cbor, then process as specified in "xxx/yyy+cbor".
+ cborで定義されていない場合は、「xxx / yyy + cbor」で指定されているように処理します。
Security Considerations: See Section 8 of this document
セキュリティに関する考慮事項：このドキュメントのセクション8を参照してください
Contact: Apps Area Working Group (apps-discuss@ietf.org)
連絡先：Apps Area Working Group（apps-discuss@ietf.org）
Author/Change Controller: The Apps Area Working Group. The IESG has change control over this registration.
著者/変更コントローラ：アプリ領域作業グループ。 IESGは、この登録を変更管理します。
A network-facing application can exhibit vulnerabilities in its processing logic for incoming data. Complex parsers are well known as a likely source of such vulnerabilities, such as the ability to remotely crash a node, or even remotely execute arbitrary code on it. CBOR attempts to narrow the opportunities for introducing such vulnerabilities by reducing parser complexity, by giving the entire range of encodable values a meaning where possible.
ネットワークに面したアプリケーションは、着信データの処理ロジックに脆弱性を示す可能性があります。複雑なパーサーは、ノードをリモートでクラッシュさせたり、ノード上で任意のコードをリモートで実行したりするなど、このような脆弱性の発生源としてよく知られています。 CBORは、可能な場合はエンコード可能な値の範囲全体に意味を与えることにより、パーサーの複雑さを軽減することにより、このような脆弱性を導入する機会を狭めようとします。
Resource exhaustion attacks might attempt to lure a decoder into allocating very big data items (strings, arrays, maps) or exhaust the stack depth by setting up deeply nested items. Decoders need to have appropriate resource management to mitigate these attacks. (Items for which very large sizes are given can also attempt to exploit integer overflow vulnerabilities.)
リソース枯渇攻撃は、非常に大きなデータアイテム（文字列、配列、マップ）を割り当てるようにデコーダーを誘導したり、深くネストされたアイテムを設定してスタックの深さを使い果たしたりする可能性があります。デコーダーは、これらの攻撃を軽減するために適切なリソース管理が必要です。 （非常に大きなサイズが指定されているアイテムは、整数オーバーフローの脆弱性を悪用することもできます。）
Applications where a CBOR data item is examined by a gatekeeper function and later used by a different application may exhibit vulnerabilities when multiple interpretations of the data item are possible. For example, an attacker could make use of duplicate keys in maps and precision issues in numbers to make the gatekeeper base its decisions on a different interpretation than the one that will be used by the second application. Protocols that are used in a security context should be defined in such a way that these multiple interpretations are reliably reduced to a single one. To facilitate this, encoder and decoder implementations used in such contexts should provide at least one strict mode of operation (Section 3.10).
CBORデータ項目がゲートキーパー機能によって検査され、後で別のアプリケーションによって使用されるアプリケーションは、データ項目の複数の解釈が可能な場合に脆弱性を示す可能性があります。たとえば、攻撃者はマップの重複キーと数値の精度の問題を利用して、ゲートキーパーが2番目のアプリケーションで使用されるものとは異なる解釈に基づいて判断を下す可能性があります。セキュリティコンテキストで使用されるプロトコルは、これらの複数の解釈が確実に単一に解釈されるように定義する必要があります。これを容易にするために、そのようなコンテキストで使用されるエンコーダーとデコーダーの実装は、少なくとも1つの厳密な動作モードを提供する必要があります（セクション3.10）。
CBOR was inspired by MessagePack. MessagePack was developed and promoted by Sadayuki Furuhashi ("frsyuki"). This reference to MessagePack is solely for attribution; CBOR is not intended as a version of or replacement for MessagePack, as it has different design goals and requirements.
CBORはMessagePackに触発されました。 MessagePackは、古橋貞行（ "frsyuki"）によって開発および宣伝されました。このMessagePackへの参照は、帰属のみを目的としています。 CBORは、設計目標や要件が異なるため、MessagePackのバージョンまたはMessagePackの代替としては意図されていません。
The need for functionality beyond the original MessagePack Specification became obvious to many people at about the same time around the year 2012. BinaryPack is a minor derivation of MessagePack that was developed by Eric Zhang for the binaryjs project. A similar, but different, extension was made by Tim Caswell for his msgpack-js and msgpack-js-browser projects. Many people have contributed to the recent discussion about extending MessagePack to separate text string representation from byte string representation.
2012年のほぼ同時に、元のMessagePack仕様を超える機能の必要性が明らかになりました。BinaryPackは、Eric Zhangがbinaryjsプロジェクトのために開発したMessagePackのマイナーな派生物です。 Tim Caswellがmsgpack-jsおよびmsgpack-js-browserプロジェクトに対して同様の、ただし異なる拡張を行いました。 MessagePackを拡張して、テキスト文字列表現をバイト文字列表現から分離することに関する最近の議論に多くの人々が貢献しています。
The encoding of the additional information in CBOR was inspired by the encoding of length information designed by Klaus Hartke for CoAP.
CBORでの追加情報のエンコーディングは、クラウスハートケがCoAPのために設計した長さ情報のエンコーディングに触発されました。
This document also incorporates suggestions made by many people, notably Dan Frost, James Manger, Joe Hildebrand, Keith Moore, Matthew Lepinski, Nico Williams, Phillip Hallam-Baker, Ray Polk, Tim Bray, Tony Finch, Tony Hansen, and Yaron Sheffer.
このドキュメントには、多くの人々、特にダンフロスト、ジェームズマンガー、ジョーヒルデブランド、キースムーア、マシューレピンスキー、ニコウィリアムズ、フィリップハラムベイカー、レイポーク、ティムブレイ、トニーフィンチ、トニーハンセン、ヤロンシェファーによる提案も含まれています。
[ECMA262] European Computer Manufacturers Association, "ECMAScript Language Specification 5.1 Edition", ECMA Standard ECMA-262, June 2011, <http://www.ecma-international.org/ publications/files/ecma-st/ECMA-262.pdf>.
[ECMA262] European Computer Manufacturers Association、「ECMAScript Language Specification 5.1 Edition」、ECMA Standard ECMA-262、2011年6月、<http://www.ecma-international.org/publications/files/ecma-st/ECMA-262。 pdf>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3339]クライン、G、エド。 C.ニューマン、「インターネット上の日付と時刻：タイムスタンプ」、RFC 3339、2002年7月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, December 2005.
[RFC4287]ノッティンガム、M。、エド。およびR.セイヤー編、「The Atom Syndication Format」、RFC 4287、2005年12月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[TIME_T] The Open Group Base Specifications, "Vol. 1: Base Definitions, Issue 7", Section 4.15 'Seconds Since the Epoch', IEEE Std 1003.1, 2013 Edition, 2013, <http://pubs.opengroup.org/onlinepubs/9699919799/ basedefs/V1_chap04.html#tag_04_15>.
[TIME_T]オープングループの基本仕様、「第1巻：基本定義、第7号」、セクション4.15「秒以降の時代」、IEEE Std 1003.1、2013年版、2013年、<http://pubs.opengroup.org/ onlinepubs / 9699919799 / basedefs / V1_chap04.html＃tag_04_15>。
[ASN.1] International Telecommunication Union, "Information Technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, 1994.
[ASN.1] International Telecommunication Union、「Information Technology-ASN.1 encoding rules：Specification of Basic Encoding Rules（BER）、Canonical Encoding Rules（CER）and Distinguished Encoding Rules（DER）」、ITU-T勧告X。 690、1994。
[BSON] Various, "BSON - Binary JSON", 2013, <http://bsonspec.org/>.
[BSON]各種、「BSON-Binary JSON」、2013、<http://bsonspec.org/>。
[CNN-TERMS] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained Node Networks", Work in Progress, July 2013.
[CNN-TERMS] Bormann、C.、Ersue、M.、and A. Keranen、 "Terminology for Constrained Node Networks"、Work in Progress、2013年7月。
[MessagePack] Furuhashi, S., "MessagePack", 2013, <http://msgpack.org/>.
「めっさげぱｃｋ」 ふるはし、 Ｓ。、 ”めっさげぱｃｋ”、 ２０１３、 ＜ｈっｔｐ：／／ｍｓｇぱｃｋ。おｒｇ／＞。
[RFC0713] Haverty, J., "MSDTP-Message Services Data Transmission Protocol", RFC 713, April 1976.
[RFC0713] Haverty、J。、「MSDTPメッセージサービスデータ転送プロトコル」、RFC 713、1976年4月。
[RFC4627] Crockford, D., "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4627] Crockford、D。、「JavaScript Object Notation（JSON）のアプリケーション/ jsonメディアタイプ」、RFC 4627、2006年7月。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, January 2013.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、2013年1月。
[UBJSON] The Buzz Media, "Universal Binary JSON Specification", 2013, <http://ubjson.org/>.
[UBJSON] Buzz Media、「Universal Binary JSON Specification」、2013、<http://ubjson.org/>。
[YAML] Ben-Kiki, O., Evans, C., and I. Net, "YAML Ain't Markup Language (YAML[TM]) Version 1.2", 3rd Edition, October 2009, <http://www.yaml.org/spec/1.2/spec.html>.
[YAML] Ben-Kiki、O.、Evans、C。、およびI. Net、「YAML Ai n't Markup Language（YAML [TM]）バージョン1.2」、第3版、2009年10月、<http：// www。 yaml.org/spec/1.2/spec.html>。
The following table provides some CBOR-encoded values in hexadecimal (right column), together with diagnostic notation for these values (left column). Note that the string "\u00fc" is one form of diagnostic notation for a UTF-8 string containing the single Unicode character U+00FC, LATIN SMALL LETTER U WITH DIAERESIS (u umlaut). Similarly, "\u6c34" is a UTF-8 string in diagnostic notation with a single character U+6C34 (CJK UNIFIED IDEOGRAPH-6C34, often representing "water"), and "\ud800\udd51" is a UTF-8 string in diagnostic notation with a single character U+10151 (GREEK ACROPHONIC ATTIC FIFTY STATERS). (Note that all these single-character strings could also be represented in native UTF-8 in diagnostic notation, just not in an ASCII-only specification like the present one.) In the diagnostic notation provided for bignums, their intended numeric value is shown as a decimal number (such as 18446744073709551616) instead of showing a tagged byte string (such as 2(h'010000000000000000')).
次の表は、CBORでエンコードされた値を16進数で示したもの（右の列）と、これらの値の診断表記（左の列）です。文字列 "\ u00fc"は、単一のUnicode文字U + 00FC、ラテン小文字Uダイアレット（uウムラウト）を含むUTF-8文字列の診断表記の1つの形式であることに注意してください。同様に、「\ u6c34」は単一文字U + 6C34（CJK UNIFIED IDEOGRAPH-6C34、多くの場合「水」を表す）を含む診断表記のUTF-8文字列であり、「\ ud800 \ udd51」は1文字の診断表記U + 10151（ギリシャ語の頭字語のATTIC FIFTY STATERS）。 （これらすべての単一文字の文字列は、現在のようなASCIIのみの仕様ではなく、診断表記でネイティブUTF-8で表すこともできます。）bignumに提供されている診断表記では、意図した数値が表示されます。タグ付きバイト文字列（2（h'010000000000000000 '）など）を表示する代わりに、10進数（18446744073709551616など）として。
+------------------------------+------------------------------------+
| Diagnostic | Encoded |
+------------------------------+------------------------------------+
| 0 | 0x00 |
| | |
| 1 | 0x01 |
| | |
| 10 | 0x0a |
| | |
| 23 | 0x17 |
| | |
| 24 | 0x1818 |
| | |
| 25 | 0x1819 |
| | |
| 100 | 0x1864 |
| | |
| 1000 | 0x1903e8 |
| | |
| 1000000 | 0x1a000f4240 |
| | |
| 1000000000000 | 0x1b000000e8d4a51000 |
| | |
| 18446744073709551615 | 0x1bffffffffffffffff |
| | |
| 18446744073709551616 | 0xc249010000000000000000 |
| | |
| -18446744073709551616 | 0x3bffffffffffffffff |
| | |
| -18446744073709551617 | 0xc349010000000000000000 |
| | |
| -1 | 0x20 |
| | |
| -10 | 0x29 |
| | |
| -100 | 0x3863 |
| | |
| -1000 | 0x3903e7 |
| | |
| 0.0 | 0xf90000 |
| | |
| -0.0 | 0xf98000 |
| | |
| 1.0 | 0xf93c00 |
| | |
| 1.1 | 0xfb3ff199999999999a |
| | |
| 1.5 | 0xf93e00 |
| | |
| 65504.0 | 0xf97bff |
| | |
| 100000.0 | 0xfa47c35000 |
| | |
| 3.4028234663852886e+38 | 0xfa7f7fffff |
| | |
| 1.0e+300 | 0xfb7e37e43c8800759c |
| | |
| 5.960464477539063e-8 | 0xf90001 |
| | |
| 0.00006103515625 | 0xf90400 |
| | |
| -4.0 | 0xf9c400 |
| | |
| -4.1 | 0xfbc010666666666666 |
| | |
| Infinity | 0xf97c00 |
| | |
| NaN | 0xf97e00 |
| | |
| -Infinity | 0xf9fc00 |
| | |
| Infinity | 0xfa7f800000 |
| | |
| NaN | 0xfa7fc00000 |
| | |
| -Infinity | 0xfaff800000 |
| | |
| Infinity | 0xfb7ff0000000000000 |
| | |
| NaN | 0xfb7ff8000000000000 |
| | |
| -Infinity | 0xfbfff0000000000000 |
| | |
| false | 0xf4 |
| | |
| true | 0xf5 |
| | |
| null | 0xf6 |
| | |
| undefined | 0xf7 |
| | |
| simple(16) | 0xf0 |
| | |
| simple(24) | 0xf818 |
| | |
| simple(255) | 0xf8ff |
| | |
| 0("2013-03-21T20:04:00Z") | 0xc074323031332d30332d32315432303a |
| | 30343a30305a |
| | |
| 1(1363896240) | 0xc11a514b67b0 |
| | |
| 1(1363896240.5) | 0xc1fb41d452d9ec200000 |
| | |
| 23(h'01020304') | 0xd74401020304 |
| | |
| 24(h'6449455446') | 0xd818456449455446 |
| | |
| 32("http://www.example.com") | 0xd82076687474703a2f2f7777772e6578 |
| | 616d706c652e636f6d |
| | |
| h'' | 0x40 |
| | |
| h'01020304' | 0x4401020304 |
| | |
| "" | 0x60 |
| | |
| "a" | 0x6161 |
| | |
| "IETF" | 0x6449455446 |
| | |
| "\"\\" | 0x62225c |
| | |
| "\u00fc" | 0x62c3bc |
| | |
| "\u6c34" | 0x63e6b0b4 |
| | |
| "\ud800\udd51" | 0x64f0908591 |
| | |
| [] | 0x80 |
| | |
| [1, 2, 3] | 0x83010203 |
| | |
| [1, [2, 3], [4, 5]] | 0x8301820203820405 |
| | |
| [1, 2, 3, 4, 5, 6, 7, 8, 9, | 0x98190102030405060708090a0b0c0d0e |
| 10, 11, 12, 13, 14, 15, 16, | 0f101112131415161718181819 |
| 17, 18, 19, 20, 21, 22, 23, | |
| 24, 25] | |
| | |
| {} | 0xa0 |
| | |
| {1: 2, 3: 4} | 0xa201020304 |
| | |
| {"a": 1, "b": [2, 3]} | 0xa26161016162820203 |
| | |
| ["a", {"b": "c"}] | 0x826161a161626163 |
| | |
| {"a": "A", "b": "B", "c": | 0xa5616161416162614261636143616461 |
| "C", "d": "D", "e": "E"} | 4461656145 |
| | |
| (_ h'0102', h'030405') | 0x5f42010243030405ff |
| | |
| (_ "strea", "ming") | 0x7f657374726561646d696e67ff |
| | |
| [_ ] | 0x9fff |
| | |
| [_ 1, [2, 3], [_ 4, 5]] | 0x9f018202039f0405ffff |
| | |
| [_ 1, [2, 3], [4, 5]] | 0x9f01820203820405ff |
| | |
| [1, [2, 3], [_ 4, 5]] | 0x83018202039f0405ff |
| | |
| [1, [_ 2, 3], [4, 5]] | 0x83019f0203ff820405 |
| | |
| [_ 1, 2, 3, 4, 5, 6, 7, 8, | 0x9f0102030405060708090a0b0c0d0e0f |
| 9, 10, 11, 12, 13, 14, 15, | 101112131415161718181819ff |
| 16, 17, 18, 19, 20, 21, 22, | |
| 23, 24, 25] | |
| | |
| {_ "a": 1, "b": [_ 2, 3]} | 0xbf61610161629f0203ffff |
| | |
| ["a", {_ "b": "c"}] | 0x826161bf61626163ff |
| | |
| {_ "Fun": true, "Amt": -2} | 0xbf6346756ef563416d7421ff |
+------------------------------+------------------------------------+
Table 4: Examples of Encoded CBOR Data Items
表4：エンコードされたCBORデータ項目の例
For brevity, this jump table does not show initial bytes that are reserved for future extension. It also only shows a selection of the initial bytes that can be used for optional features. (All unsigned integers are in network byte order.)
簡潔にするために、このジャンプテーブルには、将来の拡張のために予約されている最初のバイトは表示されていません。また、オプション機能に使用できる初期バイトの選択のみを示しています。 （すべての符号なし整数はネットワークバイト順です。）
+-----------------+-------------------------------------------------+
| Byte | Structure/Semantics |
+-----------------+-------------------------------------------------+
| 0x00..0x17 | Integer 0x00..0x17 (0..23) |
| | |
| 0x18 | Unsigned integer (one-byte uint8_t follows) |
| | |
| 0x19 | Unsigned integer (two-byte uint16_t follows) |
| | |
| 0x1a | Unsigned integer (four-byte uint32_t follows) |
| | |
| 0x1b | Unsigned integer (eight-byte uint64_t follows) |
| | |
| 0x20..0x37 | Negative integer -1-0x00..-1-0x17 (-1..-24) |
| | |
| 0x38 | Negative integer -1-n (one-byte uint8_t for n |
| | follows) |
| | |
| 0x39 | Negative integer -1-n (two-byte uint16_t for n |
| | follows) |
| | |
| 0x3a | Negative integer -1-n (four-byte uint32_t for n |
| | follows) |
| | |
| 0x3b | Negative integer -1-n (eight-byte uint64_t for |
| | n follows) |
| | |
| 0x40..0x57 | byte string (0x00..0x17 bytes follow) |
| | |
| 0x58 | byte string (one-byte uint8_t for n, and then n |
| | bytes follow) |
| | |
| 0x59 | byte string (two-byte uint16_t for n, and then |
| | n bytes follow) |
| | |
| 0x5a | byte string (four-byte uint32_t for n, and then |
| | n bytes follow) |
| | |
| 0x5b | byte string (eight-byte uint64_t for n, and |
| | then n bytes follow) |
| | |
| 0x5f | byte string, byte strings follow, terminated by |
| | "break" |
| | |
| 0x60..0x77 | UTF-8 string (0x00..0x17 bytes follow) |
| | |
| 0x78 | UTF-8 string (one-byte uint8_t for n, and then |
| | n bytes follow) |
| | |
| 0x79 | UTF-8 string (two-byte uint16_t for n, and then |
| | n bytes follow) |
| | |
| 0x7a | UTF-8 string (four-byte uint32_t for n, and |
| | then n bytes follow) |
| | |
| 0x7b | UTF-8 string (eight-byte uint64_t for n, and |
| | then n bytes follow) |
| | |
| 0x7f | UTF-8 string, UTF-8 strings follow, terminated |
| | by "break" |
| | |
| 0x80..0x97 | array (0x00..0x17 data items follow) |
| | |
| 0x98 | array (one-byte uint8_t for n, and then n data |
| | items follow) |
| | |
| 0x99 | array (two-byte uint16_t for n, and then n data |
| | items follow) |
| | |
| 0x9a | array (four-byte uint32_t for n, and then n |
| | data items follow) |
| | |
| 0x9b | array (eight-byte uint64_t for n, and then n |
| | data items follow) |
| | |
| 0x9f | array, data items follow, terminated by "break" |
| | |
| 0xa0..0xb7 | map (0x00..0x17 pairs of data items follow) |
| | |
| 0xb8 | map (one-byte uint8_t for n, and then n pairs |
| | of data items follow) |
| | |
| 0xb9 | map (two-byte uint16_t for n, and then n pairs |
| | of data items follow) |
| | |
| 0xba | map (four-byte uint32_t for n, and then n pairs |
| | of data items follow) |
| | |
| 0xbb | map (eight-byte uint64_t for n, and then n |
| | pairs of data items follow) |
| | |
| 0xbf | map, pairs of data items follow, terminated by |
| | "break" |
| | |
| 0xc0 | Text-based date/time (data item follows; see |
| | Section 2.4.1) |
| | |
| 0xc1 | Epoch-based date/time (data item follows; see |
| | Section 2.4.1) |
| | |
| 0xc2 | Positive bignum (data item "byte string" |
| | follows) |
| | |
| 0xc3 | Negative bignum (data item "byte string" |
| | follows) |
| | |
| 0xc4 | Decimal Fraction (data item "array" follows; |
| | see Section 2.4.3) |
| | |
| 0xc5 | Bigfloat (data item "array" follows; see |
| | Section 2.4.3) |
| | |
| 0xc6..0xd4 | (tagged item) |
| | |
| 0xd5..0xd7 | Expected Conversion (data item follows; see |
| | Section 2.4.4.2) |
| | |
| 0xd8..0xdb | (more tagged items, 1/2/4/8 bytes and then a |
| | data item follow) |
| | |
| 0xe0..0xf3 | (simple value) |
| | |
| 0xf4 | False |
| | |
| 0xf5 | True |
| | |
| 0xf6 | Null |
| | |
| 0xf7 | Undefined |
| | |
| 0xf8 | (simple value, one byte follows) |
| | |
| 0xf9 | Half-Precision Float (two-byte IEEE 754) |
| | |
| 0xfa | Single-Precision Float (four-byte IEEE 754) |
| | |
| 0xfb | Double-Precision Float (eight-byte IEEE 754) |
| | |
| 0xff | "break" stop code |
+-----------------+-------------------------------------------------+
Table 5: Jump Table for Initial Byte
表5：最初のバイトのジャンプテーブル
The well-formedness of a CBOR item can be checked by the pseudocode in Figure 1. The data is well-formed if and only if:
CBORアイテムの整形式は、図1の疑似コードで確認できます。データが整形式であるのは、次の場合のみです。
o the pseudocode does not "fail";
o 疑似コードは「失敗」しません。
o after execution of the pseudocode, no bytes are left in the input (except in streaming applications)
o 擬似コードの実行後、入力にバイトは残りません（ストリーミングアプリケーションを除く）
The pseudocode has the following prerequisites:
疑似コードには次の前提条件があります。
o take(n) reads n bytes from the input data and returns them as a byte string. If n bytes are no longer available, take(n) fails.
o take（n）は、入力データからnバイトを読み取り、バイト文字列として返します。 nバイトが使用できなくなった場合、take（n）は失敗します。
o uint() converts a byte string into an unsigned integer by interpreting the byte string in network byte order.
o uint()は、バイト文字列をネットワークバイトオーダーで解釈することにより、バイト文字列を符号なし整数に変換します。
o Arithmetic works as in C.
o 算術はCと同様に機能します。
o All variables are unsigned integers of sufficient range.
o すべての変数は、十分な範囲の符号なし整数です。
well_formed (breakable = false) {
// process initial bytes
ib = uint(take(1));
mt = ib >> 5;
val = ai = ib & 0x1f;
switch (ai) {
case 24: val = uint(take(1)); break;
case 25: val = uint(take(2)); break;
case 26: val = uint(take(4)); break;
case 27: val = uint(take(8)); break;
case 28: case 29: case 30: fail();
case 31:
return well_formed_indefinite(mt, breakable);
}
// process content
switch (mt) {
// case 0, 1, 7 do not have content; just use val
case 2: case 3: take(val); break; // bytes/UTF-8
case 4: for (i = 0; i < val; i++) well_formed(); break;
case 5: for (i = 0; i < val*2; i++) well_formed(); break;
case 6: well_formed(); break; // 1 embedded data item
}
return mt; // finite data item
}
well_formed_indefinite(mt, breakable) {
switch (mt) {
case 2: case 3:
while ((it = well_formed(true)) != -1)
if (it != mt) // need finite embedded
fail(); // of same type
break;
case 4: while (well_formed(true) != -1); break;
case 5: while (well_formed(true) != -1) well_formed(); break;
case 7:
if (breakable)
return -1; // signal break out
else fail(); // no enclosing indefinite
default: fail(); // wrong mt
}
return 0; // no break out
}
Figure 1: Pseudocode for Well-Formedness Check
図1：整形式チェックの疑似コード
Note that the remaining complexity of a complete CBOR decoder is about presenting data that has been parsed to the application in an appropriate form.
完全なCBORデコーダの残りの複雑さは、解析されたデータを適切な形式でアプリケーションに提示することです。
Major types 0 and 1 are designed in such a way that they can be encoded in C from a signed integer without actually doing an if-then-else for positive/negative (Figure 2). This uses the fact that (-1-n), the transformation for major type 1, is the same as ~n (bitwise complement) in C unsigned arithmetic; ~n can then be expressed as (-1)^n for the negative case, while 0^n leaves n unchanged for non-negative. The sign of a number can be converted to -1 for negative and 0 for non-negative (0 or positive) by arithmetic-shifting the number by one bit less than the bit length of the number (for example, by 63 for 64-bit numbers).
メジャータイプ0および1は、正/負のif-then-elseを実際に実行せずに、符号付き整数からCでエンコードできるように設計されています（図2）。これは、メジャータイプ1の変換（-1-n）がCの符号なし演算の〜n（ビット単位の補数）と同じであることを使用しています。 〜nは負の場合は（-1）^ nとして表すことができ、0 ^ nは非負の場合はnを変更しません。数値のビット長よりも1ビット短い（たとえば、64の場合は63）数値を算術シフトすることにより、数値の符号を負の場合は-1に、非負（0または正）の場合は0に変換できますビット数）。
void encode_sint(int64_t n) {
uint64t ui = n >> 63; // extend sign to whole length
mt = ui & 0x20; // extract major type
ui ^= n; // complement negatives
if (ui < 24)
*p++ = mt + ui;
else if (ui < 256) {
*p++ = mt + 24;
*p++ = ui;
} else
...
Figure 2: Pseudocode for Encoding a Signed Integer
図2：符号付き整数をエンコードするための擬似コード
As half-precision floating-point numbers were only added to IEEE 754 in 2008, today's programming platforms often still only have limited support for them. It is very easy to include at least decoding support for them even without such support. An example of a small decoder for half-precision floating-point numbers in the C language is shown in Figure 3. A similar program for Python is in Figure 4; this code assumes that the 2-byte value has already been decoded as an (unsigned short) integer in network byte order (as would be done by the pseudocode in Appendix C).
半精度浮動小数点数は2008年にIEEE 754にのみ追加されたため、現在のプログラミングプラットフォームでは、まだサポートされていないことがよくあります。そのようなサポートがなくても、少なくともそれらのデコードサポートを含めることは非常に簡単です。 C言語の半精度浮動小数点数用の小さなデコーダーの例を図3に示します。Python用の同様のプログラムを図4に示します。このコードは、2バイトの値がネットワークバイトオーダーの（符号なし短整数）として既にデコードされていることを前提としています（付録Cの疑似コードによって行われます）。
#include <math.h>
double decode_half(unsigned char *halfp) {
int half = (halfp[0] << 8) + halfp[1];
int exp = (half >> 10) & 0x1f;
int mant = half & 0x3ff;
double val;
if (exp == 0) val = ldexp(mant, -24);
else if (exp != 31) val = ldexp(mant + 1024, exp - 25);
else val = mant == 0 ? INFINITY : NAN;
return half & 0x8000 ? -val : val;
}
Figure 3: C Code for a Half-Precision Decoder
図3：半精度デコーダーのCコード
import struct from math import ldexp
数学から構造体をインポートインポートldexp
def decode_single(single):
return struct.unpack("!f", struct.pack("!I", single))[0]
def decode_half(half):
valu = (half & 0x7fff) << 13 | (half & 0x8000) << 16
if ((half & 0x7c00) != 0x7c00):
return ldexp(decode_single(valu), 112)
return decode_single(valu | 0x7f800000)
Figure 4: Python Code for a Half-Precision Decoder
図4：半精度デコーダーのPythonコード
Appendix E. Comparison of Other Binary Formats to CBOR's Design Objectives
付録E.他のバイナリ形式とCBORの設計目標の比較
The proposal for CBOR follows a history of binary formats that is as long as the history of computers themselves. Different formats have had different objectives. In most cases, the objectives of the format were never stated, although they can sometimes be implied by the context where the format was first used. Some formats were meant to be universally usable, although history has proven that no binary format meets the needs of all protocols and applications.
CBORの提案は、コンピュータ自体の歴史と同じくらい長いバイナリ形式の歴史をたどっています。フォーマットが異なれば目的も異なります。ほとんどの場合、フォーマットの目的は明記されていませんが、フォーマットが最初に使用されたコンテキストによって暗示される場合があります。すべてのプロトコルとアプリケーションのニーズを満たすバイナリ形式はないことが歴史で証明されていますが、一部の形式は普遍的に使用できるように意図されていました。
CBOR differs from many of these formats due to it starting with a set of objectives and attempting to meet just those. This section compares a few of the dozens of formats with CBOR's objectives in order to help the reader decide if they want to use CBOR or a different format for a particular protocol or application.
CBORは、一連の目的から始まり、それらだけに対応しようとするため、これらの形式の多くとは異なります。このセクションでは、読者が特定のプロトコルまたはアプリケーションにCBORを使用するか、別のフォーマットを使用するかを決定できるように、数十のフォーマットのいくつかをCBORの目的と比較します。
Note that the discussion here is not meant to be a criticism of any format: to the best of our knowledge, no format before CBOR was meant to cover CBOR's objectives in the priority we have assigned them. A brief recap of the objectives from Section 1.1 is:
ここでの議論は、いかなる形式の批判でもないことに注意してください。私たちの知る限り、CBORの前の形式は、割り当てられた優先順位でCBORの目的をカバーするものではありませんでした。セクション1.1の目的の簡単な要約は次のとおりです。
1. unambiguous encoding of most common data formats from Internet standards
1. インターネット標準からの最も一般的なデータ形式の明確なエンコーディング
2. code compactness for encoder or decoder
2. エンコーダーまたはデコーダーのコードのコンパクト化
3. no schema description needed
3. スキーマの説明は不要
4. reasonably compact serialization
4. 合理的にコンパクトなシリアル化
5. applicability to constrained and unconstrained applications
5. 制約のあるアプリケーションと制約のないアプリケーションへの適用性
6. good JSON conversion
6. 優れたJSON変換
7. extensibility
7. 拡張性
[ASN.1] has many serializations. In the IETF, DER and BER are the most common. The serialized output is not particularly compact for many items, and the code needed to decode numeric items can be complex on a constrained device.
[ASN.1]には多くのシリアル化があります。 IETFでは、DERとBERが最も一般的です。シリアル化された出力は、多くの項目で特にコンパクトではありません。数値項目をデコードするために必要なコードは、制約のあるデバイスでは複雑になる可能性があります。
Few (if any) IETF protocols have adopted one of the several variants of Packed Encoding Rules (PER). There could be many reasons for this, but one that is commonly stated is that PER makes use of the schema even for parsing the surface structure of the data stream, requiring significant tool support. There are different versions of the ASN.1 schema language in use, which has also hampered adoption.
IETFプロトコルには、Packed Encoding Rules（PER）のいくつかのバリアントの1つを採用しているものがあります（ある場合）。これには多くの理由がありますが、一般的に述べられているのは、PERがデータストリームの表面構造を解析するためにもスキーマを利用するため、重要なツールサポートが必要になることです。使用中のASN.1スキーマ言語にはさまざまなバージョンがあり、その採用も妨げられています。
[MessagePack] is a concise, widely implemented counted binary serialization format, similar in many properties to CBOR, although somewhat less regular. While the data model can be used to represent JSON data, MessagePack has also been used in many remote procedure call (RPC) applications and for long-term storage of data.
[MessagePack]は簡潔で広く実装されているカウントバイナリシリアル化形式で、CBORと多くのプロパティが似ていますが、やや規則的ではありません。データモデルはJSONデータを表すために使用できますが、MessagePackは多くのリモートプロシージャコール（RPC）アプリケーションやデータの長期保存にも使用されています。
MessagePack has been essentially stable since it was first published around 2011; it has not yet had a transition. The evolution of MessagePack is impeded by an imperative to maintain complete backwards compatibility with existing stored data, while only few bytecodes are still available for extension. Repeated requests over the years from the MessagePack user community to separate out binary and text strings in the encoding recently have led to an extension proposal that would leave MessagePack's "raw" data ambiguous between its usages for binary and text data. The extension mechanism for MessagePack remains unclear.
MessagePackは、2011年頃に最初に公開されて以来、本質的に安定しています。まだ移行はありません。 MessagePackの進化は、既存の格納されたデータとの完全な下位互換性を維持する必要がある一方で、拡張に使用できるバイトコードはわずかしかありません。 MessagePackユーザーコミュニティから長年にわたってエンコーディングでバイナリとテキスト文字列を分離するように要求が繰り返されたため、最近拡張機能の提案が行われ、MessagePackの「生」データがバイナリデータとテキストデータの使用法の間であいまいになっています。 MessagePackの拡張メカニズムは不明確なままです。
[BSON] is a data format that was developed for the storage of JSON-like maps (JSON objects) in the MongoDB database. Its major distinguishing feature is the capability for in-place update, foregoing a compact representation. BSON uses a counted representation except for map keys, which are null-byte terminated. While BSON can be used for the representation of JSON-like objects on the wire, its specification is dominated by the requirements of the database application and has become somewhat baroque. The status of how BSON extensions will be implemented remains unclear.
[BSON]は、MongoDBデータベースにJSONのようなマップ（JSONオブジェクト）を格納するために開発されたデータ形式です。その主な際立った特徴は、コンパクトな表現に先行するインプレース更新の機能です。 BSONは、nullバイトで終了するマップキーを除いて、カウントされた表現を使用します。 BSONはネットワーク上のJSONのようなオブジェクトの表現に使用できますが、その仕様はデータベースアプリケーションの要件によって左右され、いくぶんバロックになっています。 BSON拡張がどのように実装されるかについての状況は不明のままです。
[UBJSON] has a design goal to make JSON faster and somewhat smaller, using a binary format that is limited to exactly the data model JSON uses. Thus, there is expressly no intention to support, for example, binary data; however, there is a "high-precision number", expressed as a character string in JSON syntax. UBJSON is not optimized for code compactness, and its type byte coding is optimized for human recognition and not for compact representation of native types such as small integers. Although UBJSON is mostly counted, it provides a reserved "unknown-length" value to support streaming of arrays and maps (JSON objects). Within these containers, UBJSON also has a "Noop" type for padding.
[UBJSON]には、JSONが使用するデータモデルに正確に制限されたバイナリ形式を使用して、JSONをより速く、やや小さくするという設計目標があります。したがって、たとえばバイナリデータをサポートする意図は特にありません。ただし、JSON構文では文字列として表現される「高精度数」があります。 UBJSONはコードのコンパクト化に最適化されておらず、そのタイプバイトコーディングは人間の認識に最適化されており、小さな整数などのネイティブタイプのコンパクトな表現には最適化されていません。 UBJSONはほとんどカウントされますが、配列とマップ（JSONオブジェクト）のストリーミングをサポートするために予約された「不明な長さ」の値を提供します。これらのコンテナー内では、UBJSONにもパディング用の「Noop」タイプがあります。
Message Services Data Transmission (MSDTP) is a very early example of a compact message format; it is described in [RFC0713], written in 1976. It is included here for its historical value, not because it was ever widely used.
メッセージサービスデータ転送（MSDTP）は、コンパクトメッセージ形式のごく初期の例です。 1976年に書かれた[RFC0713]で説明されています。これは、これまで広く使用されていたためではなく、その歴史的価値のためにここに含まれています。
While CBOR's design objective of code compactness for encoders and decoders is a higher priority than its objective of conciseness on the wire, many people focus on the wire size. Table 6 shows some encoding examples for the simple nested array [1, [2, 3]]; where some form of indefinite-length encoding is supported by the encoding, [_ 1, [2, 3]] (indefinite length on the outer array) is also shown.
エンコーダーとデコーダーのコードをコンパクトにするというCBORの設計目標は、ワイヤー上の簡潔さという目的よりも優先されますが、多くの人々はワイヤーのサイズに焦点を当てています。表6は、単純なネストされた配列[1、[2、3]]のいくつかのエンコードの例を示しています。ある形式の不定長エンコーディングがエンコーディングでサポートされている場合、[_ 1、[2、3]]（外部配列の不定長）も表示されます。
+---------------+-------------------------+-------------------------+
| Format | [1, [2, 3]] | [_ 1, [2, 3]] |
+---------------+-------------------------+-------------------------+
| RFC 713 | c2 05 81 c2 02 82 83 | |
| | | |
| ASN.1 BER | 30 0b 02 01 01 30 06 02 | 30 80 02 01 01 30 06 02 |
| | 01 02 02 01 03 | 01 02 02 01 03 00 00 |
| | | |
| MessagePack | 92 01 92 02 03 | |
| | | |
| BSON | 22 00 00 00 10 30 00 01 | |
| | 00 00 00 04 31 00 13 00 | |
| | 00 00 10 30 00 02 00 00 | |
| | 00 10 31 00 03 00 00 00 | |
| | 00 00 | |
| | | |
| UBJSON | 61 02 42 01 61 02 42 02 | 61 ff 42 01 61 02 42 02 |
| | 42 03 | 42 03 45 |
| | | |
| CBOR | 82 01 82 02 03 | 9f 01 82 02 03 ff |
+---------------+-------------------------+-------------------------+
Table 6: Examples for Different Levels of Conciseness
表6：さまざまなレベルの意識の例
Authors' Addresses
著者のアドレス
Carsten Bormann Universitaet Bremen TZI Postfach 330440 D-28359 Bremen Germany
カルステンボルマンブレーメン大学TZI PO Box 330440 D-28359ブレーメンドイツ
Phone: +49-421-218-63921
EMail: cabo@tzi.org
Paul Hoffman VPN Consortium
ポールホフマンVPNコンソーシアム
EMail: paul.hoffman@vpnc.org