---
html: serialization.html
parent: protocol-reference.html
seo:
    description: XRP Ledgerトランザクションやその他のオブジェクトの場合のJSONフォーマットと正規バイナリーフォーマットとの変換です。
labels:
  - アカウント
  - トランザクション送信
curated_anchors:
  - name: サンプルコード
    anchor: "#サンプルコード"
  - name: フィールドの正規順序
    anchor: "#フィールドの正規順序"
  - name: タイプリスト
    anchor: "#タイプリスト"
---
# バイナリフォーマット
[[ソース]](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/STObject.cpp#L696-L718 "Source")

このページでは、XRP Ledgerのトランザクションとその他のデータの正規バイナリフォーマットについて説明します。このバイナリフォーマットは、トランザクションの内容のデジタル署名を作成および検証するために必要であり、[サーバ間のピアツーピア通信](../../concepts/networks-and-servers/peer-protocol.md)を含む他の用途にも使用されます。通常、[`rippled` API](../http-websocket-apis/index.md)は、JSONを使用してクライアントアプリケーションと通信します。ただしJSONは、同じデータをさまざまな同等の方法で表現できるため、デジタル署名を付与するトランザクションをシリアル化するのに適したフォーマットではありません。

トランザクションをJSONまたはその他の表現から正規バイナリフォーマットへシリアル化するプロセスのステップを、以下にまとめます。

1. すべての必須フィールドが指定されていること（必須の[「自動入力可能」フィールド](transactions/common-fields.md#自動入力可能なフィールド)を含む）を確認します。

   [トランザクションフォーマットリファレンス](transactions/index.md)に、XRP Ledgerトランザクションの必須フィールドと省略可能なフィールドが定義されています。

   {% admonition type="info" name="注記" %}`SigningPubKey`もこのステップで指定する必要があります。署名の際に、署名用に指定された秘密鍵から[このキーを導出](../../concepts/accounts/cryptographic-keys.md#鍵導出)できます。{% /admonition %}

2. 各フィールドのデータを[「内部」バイナリフォーマット](#内部フォーマット)に変換します。

3. フィールドを[正規順序](#フィールドの正規順序)でソートします。

4. 各フィールドの前に[フィールドID](#フィールドid)を付加します。

5. フィールド（プレフィクスを含む）をソート順に連結します。

その結果、ECDSA（secp256k1楕円曲線を使用）やEd25519などの既知の署名アルゴリズムを使用して署名できるバイナリBlobが1つ作成されます。XRP Ledgerのために、適切なプレフィクス（シングル署名の場合は`0x53545800`、マルシグの場合は`0x534D5400`）を使用してデータを[ハッシュ化][ハッシュ]する必要があります。署名後に、指定されている`TxnSignature`フィールドを使用してトランザクションを再度シリアル化する必要があります。 <!--{# TODO: link docs on how to compute a transaction signature. #}-->

{% admonition type="info" name="注記" %}XRP Ledgerでは、[レジャーオブジェクト](ledger-data/ledger-entry-types/index.md)や処理済みのトランザクションなど他のタイプのデータを表す場合にも同じシリアル化フォーマットが使用されます。ただし、署名されるトランザクションに追加するのに適切なフィールドは限られています。（たとえば署名自体が指定されている`TxnSignature`フィールドは、署名するバイナリBlobに含まれていてはなりません。）このように、「署名」フィールドとされてオブジェクトに署名するときにオブジェクトに含まれるフィールドもあれば、「非署名」とされてオブジェクトに含まれないフィールドもあります。{% /admonition %}

### 例

署名済みトランザクションと未署名のトランザクションはいずれも、JSONフォーマットとバイナリフォーマットの両方で表すことができます。同じ署名済みトランザクションのJSONフォーマットとバイナリフォーマットの例を以下に示します。

**JSON:**

{% code-snippet file="/_code-samples/tx-serialization/py/test-cases/tx1.json" language="json" /%}

**バイナリ（16進数として表現）:**

{% code-snippet file="/_code-samples/tx-serialization/py/test-cases/tx1-binary.txt" language="text" /%}

## サンプルコード

ここで説明するシリアル化プロセスは複数の場所にさまざまなプログラミング言語で実装されています。

- C++: [`rippled`コードベース](https://github.com/XRPLF/rippled/blob/develop/src/ripple/protocol/impl/STObject.cpp)
- JavaScript: [`ripple-binary-codec`](https://github.com/ripple/ripple-binary-codec/)パッケージ
- Python 3: {% repo-link path="_code-samples/tx-serialization/" %}このリポジトリのコードサンプルセクション{% /repo-link %}

これらのすべての実装には、一般利用が可能なオープンソースライセンスが提供されているので、学習のためにドキュメントと合わせて使用するだけでなく、必要に応じてコードをインポート、使用、または変更することができます。



## 内部フォーマット

各フィールドには「内部」バイナリフォーマットがあります。このフォーマットは、`rippled`ソースコードで署名時に（およびその他のほとんどの場合に）そのフィールドを表示するのに使用されます。すべてのフィールドの内部フォーマットは、[`SField.cpp`](https://github.com/XRPLF/rippled/blob/master/src/ripple/protocol/impl/SField.cpp)のソースコードに定義されています。（このフィールドには、トランザクションフィールド以外のフィールドも含まれています。）[トランザクションフォーマットリファレンス](transactions/index.md)にも、すべてのトランザクションフィールドの内部フォーマットが記載されています。

たとえば`Flags`[共通トランザクションフィールド](transactions/common-fields.md)はUInt32（32ビット符号なし整数）になります。

### 定義ファイル

以下のJSONファイルには、XRP Ledgerデータをそのバイナリフォーマットにシリアル化し、バイナリからシリアル化解除するのに必要な重要な定数が定義されています。

**<https://github.com/ripple/ripple-binary-codec/blob/master/src/enums/definitions.json>**

この定義ファイルの最上位フィールドの定義を以下の表に示します。

| フィールド             | 内容                                                 |
|:----------------------|:-----------------------------------------------------|
| `TYPES` | フィールドIDの作成と正規順序でのフィールドのソートのためのデータタイプからその[「タイプコード」](#タイプコード)へのマップ。1未満のコードは実際のデータには含まれません。10000を超えるコードは、他のオブジェクト内部ではシリアル化できない「トランザクション」などの特殊な「上位」オブジェクトタイプを表します。各タイプのシリアル化方法についての詳細は、[タイプリスト](#タイプリスト)をご覧ください。 |
| `LEDGER_ENTRY_TYPES` | [レジャーオブジェクト](ledger-data/ledger-entry-types/index.md)から対応するデータタイプへのマップ。これはレジャー状態データと、処理されたトランザクションの[メタデータ](transactions/metadata.md)の「affected nodes」セクションに含まれます。 |
| `FIELDS` | トランザクション、レジャーオブジェクト、あるいはその他のデータに含まれる可能性があるすべてのフィールドを表すタプルからなるソート済み配列。各タプルの1番目のメンバーはフィールドの文字列名であり、2番目のメンバーはそのフィールドのプロパティーが含まれているオブジェクトです。（これらのフィールドの定義については、以下の「フィールドプロパティー」の表をご覧ください。） |
| `TRANSACTION_RESULTS` | [トランザクション結果コード](transactions/transaction-results/index.md)から対応する数値へのマップ。レジャーに含まれない結果タイプにはマイナスの値が含まれています。`tesSUCCESS`に数値0が含まれています。[`tec`クラスコード](transactions/transaction-results/tec-codes.md)は、レジャーに含まれている失敗を示しています。 |
| `TRANSACTION_TYPES` | [トランザクションのタイプ](transactions/types/index.md)から対応する数値へのマップ。 |

署名と送信のためにトランザクションをシリアル化するという目的から、`FIELDS`、`TYPES`、および`TRANSACTION_TYPES`フィールドが必要です。

`FIELDS`配列のフィールド定義オブジェクトには以下のフィールドが含まれています。

| フィールド        | 型      | 内容                                            |
|:-----------------|:--------|:------------------------------------------------|
| `nth` | 数値 | このフィールドの[フィールドコード](#フィールドコード)。このコードは、[フィールドID](#フィールドid)の作成時と、同一データタイプの他のフィールドとのソート時に使用されます。 |
| `isVLEncoded` | ブール値 | `true`の場合、このフィールドには[長さプレフィクスが付加されています](#長さプレフィクスを付加する)。 |
| `isSerialized` | ブール値 | `true`の場合、このフィールドはシリアル化バイナリデータにエンコードされる必要があります。このフィールドが`false`の場合、一般にフィールドは保管されず、オンデマンドで再作成されます。 |
| `isSigningField` | ブール値 | `true`の場合、署名のためにトランザクションを準備する際にこのフィールドをシリアル化する必要があります。`false`の場合、このフィールドは署名対象データから省略する必要があります。（これはトランザクションに含まれていない可能性があります。） |
| `type` | 文字列 | このフィールドの内部データタイプ。これは、このフィールドの[タイプコード](#タイプコード)を示す`TYPES`マップのキーにマップします。 |

### フィールドID

[[ソース - エンコード]](https://github.com/seelabs/rippled/blob/cecc0ad75849a1d50cc573188ad301ca65519a5b/src/ripple/protocol/impl/Serializer.cpp#L117-L148 "Source")
[[ソース - デコード]](https://github.com/seelabs/rippled/blob/cecc0ad75849a1d50cc573188ad301ca65519a5b/src/ripple/protocol/impl/Serializer.cpp#L484-L509 "Source")

フィールドのタイプコードとフィールドコードを結合すると、フィールドの一意のIDになります。このIDは、最終的なシリアル化Blobでこのフィールドの前に付加されます。フィールドIDのサイズは、タイプコードとその結合対象のフィールドコードに応じて1～3バイトとなります。以下の表をご覧ください。

|                  | タイプコード < 16                                                             | タイプコード >= 16 |
|:-----------------|:------------------------------------------------------------------------------|:--|
| **フィールドコード < 16** | ![1バイト: 上位4ビットがタイプを定義し、下位4ビットがフィールドを定義します。](/docs/img/field-id-common-type-common-field.ja.png) | ![2バイト: 1番目のバイトの下位4ビットがフィールドを定義し、次のバイトがタイプを定義します。](/docs/img/field-id-uncommon-type-common-field.ja.png) |
| **フィールドコード >= 16** | ![2バイト: 1番目のバイトの上位4ビットがタイプを定義し、1番目のバイトの下位4ビットは0になります。次のバイトがフィールドを定義します。](/docs/img/field-id-common-type-uncommon-field.ja.png )| ![3バイト: 1番目のバイトは0x00、2番目のバイトはタイプを定義します。3番目のバイトはフィールドを定義します。](/docs/img/field-id-uncommon-type-uncommon-field.ja.png) |

デコードの際には、**1番目のバイト**のどのビットがゼロであるかによって、フィールドIDのバイト数を把握できます。これは、上記の表の例に対応しています。

|                  | 上位4ビットがゼロ以外である                                                     | 上位4ビットがゼロである |
|:-----------------|:------------------------------------------------------------------------------|:--|
| **下位4ビットがゼロ以外である** | 1バイト: 上位4ビットがタイプを定義し、下位4ビットがフィールドを定義します。 | 2バイト: 1番目のバイトの下位4ビットがフィールドを定義し、次のバイトがタイプを定義します。 |
| **下位4ビットがゼロである** | 2バイト: 1番目のバイトの上位4ビットがタイプを定義し、1番目のバイトの下位4ビットは0になります。次のバイトがフィールドを定義します。 | 3バイト: 1番目のバイトは0x00、2番目のバイトはタイプを定義します。3番目のバイトはフィールドを定義します。 |

{% admonition type="warning" name="注意" %}フィールドIDは、フィールドのソートに使用される2つの要素で構成されますが、シリアル化されたフィールドID自体に基づいてソートを実行しないでください。これは、フィールドIDのバイト構造によってソート順序が変わるためです。{% /admonition %}

### 長さプレフィクスを付加する

一部の可変長フィールドの前には、長さインディケーターが付加されています。`Blob`フィールド（任意のバイナリデータを含む）がこれに該当します。長さプレフィクスが付加されているタイプのリストについては、[タイプリスト](#タイプリスト)の表をご覧ください。

{% admonition type="info" name="注記" %}一部のタイプの可変長フィールドには、長さプレフィクスが付加されません。このようなタイプでは、他の方法で内容の終わりが示されます。{% /admonition %}

長さプレフィクスはフィールドの長さを示す1～3バイトで構成され、タイププレフィクスと内容の間に挿入されます。

- フィールドに0～192バイトのデータが含まれている場合、1番目のバイトは内容の長さを示し、長さバイトの直後にそのバイト数のデータが続きます。

- フィールドに193～12480バイトのデータが含まれている場合、最初の2バイトは以下の式で算出されるフィールドの長さを示します。

    ```
    193 + ((byte1 - 193) * 256) + byte2
    ```

- フィールドに12481～918744バイトのデータが含まれている場合、最初の3バイトは以下の式で算出されるフィールドの長さを示します。

    ```
    12481 + ((byte1 - 241) * 65536) + (byte2 * 256) + byte3
    ```

- 長さプレフィクスが付加されているフィールドに格納できる最大データは918744バイトです。

デコード時に、1番目の長さバイトの値から、追加の長さバイト（0、1、または2）が存在するかどうかを把握できます。

- 1番目の長さバイトの値が192以下の場合、これは唯一の長さバイトであり、フィールドの内容の長さはこのバイトが示すバイト数です。
- 1番目の長さバイトの値が193～240の場合、2つの長さバイトがあります。
- 1番目の長さバイトの値が241～254の場合、3つの長さバイトがあります。


## フィールドの正規順序

トランザクションのすべてのフィールドは、まずフィールドのタイプ（特に各タイプに割り当てられている数値の「タイプコード」）に基づいて特定の順序でソートされ、次にフィールド自体（「フィールドコード」）に基づいてソートされます。（たとえば、姓がフィールドのタイプ、名前がフィールド自体とすると、姓で最初にソートし、次に名でソートすることになります。）

### タイプコード

各フィールドタイプには任意のタイプコードが含まれており、番号が小さいコードから最初にソートされます。これらのコードは[`SField.h`](https://github.com/XRPLF/rippled/blob/master/include/xrpl/protocol/SField.h#L60-L98)で定義されています。

たとえば [UInt32のタイプコードが2である](https://github.com/XRPLF/rippled/blob/master/include/xrpl/protocol/SField.h#L67)ので、すべてのUInt32フィールドは、すべての[Amountフィールド（タイプコード6）](https://github.com/XRPLF/rippled/blob/master/include/xrpl/protocol/SField.h#L71)よりも前に位置します。

[定義ファイル](#定義ファイル)には、`TYPES`マップの各タイプのタイプコードがリストされています。

### フィールドコード

各フィールドにはフィールドコードが含まれています。フィールドコードは、同じタイプのフィールドをソートするときに使用され、番号が小さいコードが最初になるようにソートされます。これらのフィールドは[`sfields/macro`](https://github.com/XRPLF/rippled/blob/master/include/xrpl/protocol/detail/sfields.macro)で定義されています。

たとえば[Paymentトランザクション][]の`Account`フィールドの[ソートコードが1である](https://github.com/XRPLF/rippled/blob/master/include/xrpl/protocol/detail/sfields.macro#L269)場合、このフィールドは`Destination`フィールド（[ソートコードが3である](https://github.com/XRPLF/rippled/blob/master/include/xrpl/protocol/detail/sfields.macro#L271)フィールド）よりも前に位置します。

フィールドコードは異なるフィールドタイプのフィールドで再利用されますが、同じタイプのフィールドに同じフィールドコードが含まれることはありません。タイプコードとフィールドコードを組み合わせると、フィールドの一意の[フィールドID](#フィールドid)になります。



## タイプリスト

トランザクションの指示には、以下のタイプのフィールドを指定できます。

| タイプ名       | タイプコード | ビット長 | [長さプレフィクスを付加する]? | 説明    |
|:--------------|:----------|:-----------|:-------------------|----------------|
| [AccountID][] | 8 | 160 | はい | [アカウント](../../concepts/accounts/index.md)の一意のID。 |
| [Amount][] | 6 | 64または384 | いいえ | XRPまたはトークンの金額。フィールドの長さは、XRPの場合は64ビット、トークンの場合は384ビット（64+160+160）です。 |
| [Blob][] | 7 | 可変 | はい | 任意のバイナリデータ。このようなフィールドの中で重要なフィールドとして、`TxnSignature`（トランザクションを承認する署名）があります。 |
| [Hash128][] | 4 | 128 | いいえ | 128ビットの任意のバイナリ値。該当する唯一のフィールドは`EmailHash`です。これは、[Gravatar](https://www.gravatar.com/)を取得する目的でアカウント所有者のメールのMD-5ハッシュを保管するフィールドです。 |
| [Hash160][] | 17 | 160 | いいえ | 160ビットの任意のバイナリ値。これにより通貨コードまたはイシュアーが定義されます。 |
| [Hash256][] | 5 | 256 | いいえ | 256ビットの任意のバイナリ値。これは通常、トランザクション、レジャーバージョン、またはレジャーデータオブジェクトの「SHA-512ハーフ」ハッシュを表します。 |
| [PathSet][] | 18 | 可変 | いいえ | [クロスカレンシー支払い](../../concepts/payment-types/cross-currency-payments.md)の有効な[ペイメントパス](../../concepts/tokens/fungible-tokens/paths.md)のセット。 |
| [STArray][] | 15 | 可変 | いいえ | 可変数のメンバーからなる配列。フィールドによってタイプが異なる場合があります。この例として、[memos](transactions/common-fields.md#memosフィールド)や[マルチ署名](../../concepts/accounts/multi-signing.md)で使用される署名者のリストがあります。 |
| [STIssue][]   | 24        | 160 or 320 | いいえ                   | 数量を含まない、資産(XRPまたはトークン)を指定します。 |
| [STObject][] | 14 | 可変 | いいえ | 1つ以上のネストされたフィールドを含むオブジェクト。 |
| [UInt8][] | 16 | 8 | いいえ | 8ビットの符号なし整数。 |
| [UInt16][] | 1 | 16 | いいえ | 16ビットの符号なし整数。`TransactionType`は、このタイプの特殊なフィールドで、特定の文字列から整数値へのマッピングを含みます。 |
| [UInt32][] | 2 | 32 | いいえ | 32ビットの符号なし整数。このタイプの例として、すべてのトランザクションの`Flags`フィールドと`Sequence`フィールドがあります。 |
| [XChainBridge][] | 25 | 可変 | いいえ | 2つのブロックチェーン間のブリッジで、両方のチェーン上のドアアカウントと発行された資産によって識別されます。 |


[長さプレフィクスを付加する]: #長さプレフィクスを付加する

上記のフィールドタイプの他に、[レジャーオブジェクト](ledger-data/ledger-entry-types/index.md)や[トランザクションメタデータ](transactions/metadata.md)などのコンテキストでは以下のタイプが含まれることがあります。

| タイプ名     | タイプコード | [長さプレフィクスを付加する]? | 説明                 |
|:------------|:----------|:-------------------|:------------------------------|
| Transaction | 10001 | いいえ | [トランザクション](transactions/index.md)全体を含む「上位」タイプ。 |
| LedgerEntry | 10002 | いいえ | [レジャーオブジェクト](ledger-data/ledger-entry-types/index.md)全体を含む「上位」タイプ。 |
| Validation | 10003 | いいえ | ピアツーピア通信で[コンセンサスプロセス](../../concepts/consensus-protocol/index.md)の検証投票を表すために使用される「上位」タイプ。 |
| Metadata | 10004 | いいえ | [1つのトランザクションのメタデータ](transactions/metadata.md)を含む「上位」タイプ。 |
| [UInt64][] | 3 | いいえ | 64ビットの符号なし整数。このタイプはトランザクションの指示には含まれませんが、さまざまなレジャーオブジェクトでこのタイプのフィールドが使用されます。 |
| Vector256 | 19 | はい | このタイプはトランザクションの指示には含まれませんが、[Amendmentレジャーオブジェクト](ledger-data/ledger-entry-types/amendments.md)の`Amendments`フィールドでは、現在有効な[Amendment](../../concepts/networks-and-servers/amendments.md)を示すためにこのタイプが使用されます。 |


### AccountIDフィールド
[AccountID]: #accountidフィールド

このタイプのフィールドには、XRP Ledger[アカウント](../../concepts/accounts/index.md)の160ビットのIDが含まれています。JSONではこれらのフィールドは[base58][] XRP Ledger「アドレス」および追加のチェックサムデータとして表示されます。このため、スペルミスが有効なアドレスとなることがありません。（このエンコードは「Base58Check」とも呼ばれ、誤ったアドレスへの送金を防止します。）これらのフィールドのバイナリフォーマットにはチェックサムデータは含まれておらず、また[アドレスのbase58エンコード](../../concepts/accounts/addresses.md#アドレスのエンコード)で使用される`0x00`「タイププレフィクス」も含まれていません。（ただし、バイナリフォーマットは主に署名済みトランザクションに使用されるため、署名済みトランザクションを転記する際にスペルミスなどのエラーが発生すると署名が無効となり、送金できなくなります。）

スタンドアロンフィールドとして表示されるAccountID（`Account`や`Destination`など）の長さは固定長の160ビットですが、[長さプレフィクスが付加](#長さプレフィクスを付加する)されます。その結果、これらのフィールドの長さインディケーターは常に`0x14`バイトになります。特殊フィールドの子として示されるAccountID（[Amount `issuer`][Amount]、[PathSet `account`][PathSet]など）では長さプレフィクスは付加 _されません_ 。


### Amountフィールド
[Amount]: #amountフィールド

「Amount」タイプは、通貨（XRPまたはトークン）の額を表す特殊なフィールドタイプです。このタイプは2つのサブタイプで構成されます。

- **XRP**

  XRPは64ビット符号なし整数（ビッグエンディアンオーダー）としてシリアル化されます。ただし、XRPであることを示すため最上位ビットが常に0であり、プラスの値であることを示す最上位から2番目のビットは`1`となります。XRPの最大額（10<sup>17</sup> drop）には57ビットが必要であるため、XRPのシリアル化フォーマットを計算するには、標準の64ビット符号なし整数をとり、`0x4000000000000000`のビットOR演算を行います。

- **トークン**

トークンは以下の3つのセグメントで構成され、セグメントの順序は以下のとおりです。

  1. [トークンの数量フォーマット](#トークンの数量フォーマット)の額を示す64ビット。1番目のビットは、これがXRPではないことを示す`1`です。
  2. [通貨コード](data-types/currency-formats.md#通貨コード)を示す160ビット。標準APIでは、[標準通貨コードフォーマット](data-types/currency-formats.md#標準通貨コード)を使用して「USD」などの3文字のコードが160ビットのコードに変換されますが、160ビットのカスタムコードも使用できます。
  3. イシュアーのアカウントIDを示す160ビット。（関連項目: [アカウントアドレスエンコード](../../concepts/accounts/addresses.md#アドレスのエンコード)

1番目のビットに基づいて2つのサブタイプのいずれに該当するかを確認できます。`0`の場合はXRP、`1`の場合はトークンです。

以下の図に、XRPの額とトークン額のシリアル化フォーマットを示します。

[{% inline-svg file="/docs/img/serialization-amount.ja.svg" /%}](/docs/img/serialization-amount.ja.svg "「非XRP」ビット、符号ビット、および62ビットの精度で構成されるXRPの額。「非XRP」ビット、符号ビット、指数（8ビット）、仮数（54ビット）、通貨コード（160ビット）、イシュアー（160ビット）で構成されるトークンの額。")

#### トークンの数量フォーマット
[[ソース]](https://github.com/XRPLF/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/STAmount.cpp "ソース")

[{% inline-svg file="/docs/img/currency-number-format.ja.svg" /%}](/docs/img/currency-number-format.ja.svg "トークンの数量フォーマットの図")

XRP Ledgerは64ビットを使って(代替可能な)トークンの金額をシリアライズします。(JSONフォーマットでは、通貨量オブジェクトの`value`フィールドが数値量になります)。バイナリ形式では、数値は"非XRP"ビット、符号ビット、指数、有効数字の順で構成されます。

1. トークン数量の最初の(最上位)ビットは`1`で、XRP数量ではないことを示します。(XRPの金額は、このフォーマットと区別するために、最上位ビットが常に`0`に設定されています)。
2. 符号ビットは、金額がプラスかマイナスかを示します。標準的な[2の補数](https://ja.wikipedia.org/wiki/2の補数)整数とは異なり、XRP Ledgerフォーマットでは`1`は**正**を表し、`0`は**負**を表します。
3. 次の8ビットは指数を符号なし整数で表します。指数は、-96から+80(含む)の範囲でスケール（有効桁を10の何乗にするか）を示します。しかし、シリアライズするときには、指数に97を加えて符号なし整数としてシリアライズできるようにします。したがって、シリアル化された値`1`は指数`-96`を表し、シリアル化された値`177`は指数`80`を表します。
4. 残りの54ビットは、符号なし整数として有効数字(_mantissa_ と呼ばれることもあります)を表します。シリアライズするとき、この値は10<sup>15</sup>(`1000000000000000`)から10<sup>16</sup>-1(`9999999999`)の範囲に正規化されます。0の特別なケースでは、符号ビット、指数、有効数字はすべて0ですので、64ビットの値は`0x800000000000000000000000`としてシリアライズされます。

数値の金額は、[通貨コード][]および発行者とともにシリアライズされ、完全な[トークン金額](#amountフィールド)を形成します。

#### 通貨コード

プロトコルレベルでは、XRP Ledgerの通貨コードは任意の160bit値ですが、以下の値には特別な意味があります。

- 通貨コード`0x0000000000000000000000005852500000000000`は**使用できません** 。(これは"標準フォーマット"において"XRP"を表します)。
- 通貨コード`0x0000000000000000000000000000000000000000`(すべてゼロ)は、**許可されません**。通常、XRPの金額を通貨コードで指定することはありません。しかし、XRPの通貨コードを指定しなければならないフィールドが存在する場合、このコードはXRPを示すために使用されます。

[`rippled` API](../http-websocket-apis/index.md)は、3文字のASCIIコードを160ビットの16進数に変換するための**標準フォーマット**を以下のようにサポートしています。

[{% inline-svg file="/docs/img/currency-code-format.ja.svg" /%}](/docs/img/currency-code-format.ja.svg "標準通貨コードのフォーマット")

1. 最初の8ビットは`0x00`でなければなりません。
2. 次の88ビットは予約済みで、すべて`0`でなければなりません。
3. 次の24ビットはASCIIの3文字を表します。
    [ISO 4217](https://www.xe.com/iso4217.php) コード、または "BTC"のような一般的な擬似 ISO 4217コードの使用を推奨します。すべての大文字と小文字、数字、記号 `?`, `!`, `@`, `#`, `$`, `%`, `^`, `&`, `*`, `<`, `>`, `(`, `)`, `{`, `}`, `[`, `]`, <code>&#124;</code>が利用可能です。 通貨コード`XRP`(すべて大文字)はXRPのために予約済みであり、トークンで使用することはできません。
4.  次の40ビットは予約済みで、すべて`0`でなければなりません。

**非標準フォーマット**は、最初の8ビットが`0x00`以外の160ビットのデータです。


### 配列フィールド
[STArray]: #配列フィールド

一部のトランザクションフィールド（[SignerListSetトランザクション][]の`SignerEntries`や[`Memos`](transactions/common-fields.md#memosフィールド)など）はオブジェクトの配列です（「STArray」タイプと呼ばれます）。

配列には、さまざまな[オブジェクトフィールド](#オブジェクトフィールド)がそのネイティブバイナリフォーマットで特定の順序で含まれています。JSONでは、各配列メンバーが1つのフィールド（メンバーオブジェクトフィールドの名前）を含むJSON「ラッパー」オブジェクトです。そのフィールドの値は（「内部」）オブジェクト自体です。

バイナリフォーマットでは、配列の各メンバーにはフィールドIDプレフィクス（ラッパーオブジェクトの単一キーに基づく）と内容（[オブジェクトとしてシリアル化された](#オブジェクトフィールド)内部オブジェクトからなる）が含まれています。配列の終わりをマークするため、アイテムにフィールドID `0xf1`（配列のタイプコードとフィールドコード1）を付加し、内容は指定しません。

以下の例は、配列のシリアル化フォーマットを示します（`SignerEntries`フィールド）。

[{% inline-svg file="/docs/img/serialization-array.ja.svg" /%}](/docs/img/serialization-array.ja.svg "配列フィールドID、各配列要素のフィールドIDと内容、および「配列の終わり」を示すフィールドID")


### Blobフィールド
[Blob]: #blobフィールド

Blobタイプは、任意のデータを持つ[長さプレフィクスが付加されている](#長さプレフィクスを付加する)フィールドです。このタイプを使用する2種類の一般的なフィールドとして、`SigningPubKey`と`TxnSignature`があります。これらのフィールドにはそれぞれ、トランザクションの実行を承認する公開鍵と署名が含まれています。

両方のフィールドにはこれ以上の内容構造がないため、フィールドIDと長さプレフィクスの後に可変長エンコードで示される正確なバイト数で構成されます。


### ハッシュフィールド
[Hash128]: #ハッシュフィールド
[Hash160]: #ハッシュフィールド
[Hash256]: #ハッシュフィールド

XRP LedgerのハッシュタイプにはHash128、Hash160、Hash256があります。これらのフィールドには特定のビット数のバイナリデータが含まれており、それらのデータはハッシュ演算の結果を表す場合とそうでない場合があります。

これらのフィールドは、長さインディケーターを使用せずに、ビッグエンディアンバイトオーダーで特定数のビットとしてシリアル化されます。

### Issueフィールド
[STIssue]: #issueフィールド

いくつかのフィールドは、XRPや[トークン](../../concepts/tokens/index.md)といったアセットタイプを指定します。これらのフィールドは、1つまたは2つの160ビットから構成されています：

1. 最初の160ビットはアセットの[通貨コード](#通貨コード)です。XRPの場合、これはすべて0です。
2. 最初の160ビットが全て0の場合(アセットがXRPの場合)、フィールドはそこで終了します。そうでない場合、アセットはトークンであり、次の160ビットは[トークン発行者のAccountID](#accountidフィールド)です。

### オブジェクトフィールド
[STObject]: #オブジェクトフィールド

トランザクションフィールドの一部（[SignerListSetトランザクション][]の`SignerEntry`や`Memos`配列の`Memo`など）はオブジェクトです（「STObject」タイプと呼ばれます）。オブジェクトのシリアル化は配列のシリアル化に似ていますが、唯一異なる点としてオブジェクトフィールド内では**オブジェクトのメンバーを正規順序に従って配置する必要がある**点があげられます。配列フィールドではすでに順序が明示的に設定されています。

オブジェクトフィールドの[正規フィールド順序](#フィールドの正規順序)は、すべての最上位フィールドの正規フィールド順序と同じですが、オブジェクトのメンバーはオブジェクト内でソートする必要があります。最終メンバーの後には、「オブジェクトの終わり」を示すフィールドID（`0xe1`）があり、このフィールドには内容がありません。

以下の例は、オブジェクトのシリアル化フォーマットを示します（`Memos`配列内の1つの`Memo`オブジェクト）。

[{% inline-svg file="/docs/img/serialization-object.ja.svg" /%}](/docs/img/serialization-object.ja.svg "オブジェクトフィールドID、各オブジェクトメンバーのオブジェクトIDと内容（正規順序）、および「オブジェクトの終わり」を示すフィールドID")


### PathSetフィールド
[PathSet]: #pathsetフィールド

クロスカレンシーの[Paymentトランザクション][]の`Paths`フィールドは、JSONで配列からなる配列として表される「PathSet」です。使用されるパスについての詳細は、[パス](../../concepts/tokens/fungible-tokens/paths.md)をご覧ください。

PathSetは、**1～6**の個別パスとして順序どおりにシリアル化されます[[ソース]](https://github.com/XRPLF/rippled/blob/4cff94f7a4a05302bdf1a248515379da99c5bcd4/src/ripple/app/tx/impl/Payment.h#L35-L36 "Source")。それぞれの完全なパスの後には、パスの後に続く内容を示すバイトが配置されます。

- `0xff`は別のパスが続くことを示します。
- `0x00`はPathSetの終わりを示します。

各パスには**1～8**のパスステップがこの順序で含まれています[[ソース]](https://github.com/XRPLF/rippled/blob/4cff94f7a4a05302bdf1a248515379da99c5bcd4/src/ripple/app/tx/impl/Payment.h#L38-L39 "Source")。各ステップは**タイプ**を示すバイトで始まり、その後にパスステップを記述する1つ以上のフィールドが続きます。タイプは、ビット単位のフラグを使用してそのパスステップに含まれるフィールドを示します。（たとえば値が`0x30`の場合、通貨とイシュアーの両方が変更されます。）複数のフィールドが含まれている場合、フィールドは常に特定の順序で配置されます。

以下の表に、有効なフィールドと、タイプバイトでフィールドを示すために設定されるビット単位のフラグを示します。

| タイプフラグ | 含まれるフィールド | フィールドタイプ | ビットサイズ | 順序 |
|:----------|:--------------|:------------------|:---------|:------|
| `0x01` | `account` | [AccountID][] | 160ビット | 1番目   |
| `0x10` | `currency` | [通貨コード][] | 160ビット | 2番目   |
| `0x20` | `issuer` | [AccountID][] | 160ビット | 3番目   |

[通貨コード]: data-types/currency-formats.md#標準通貨コード

いくつかの組み合わせは無効です。詳細は、[パスの仕様](../../concepts/tokens/fungible-tokens/paths.md#パスの仕様)をご覧ください。

`account`フィールドと`issuer`フィールドのAccountIDには、長さプレフィクスは付加 _されていません_ 。`currency`がXRPの場合、通貨コードは160ビットのゼロとして表されます。

各ステップの直後にはパス上の次のステップが続きます。前述したように、パスの最終ステップの後には`0xff`（別のパスが続く場合）または`0x00`（これが最終パスの終わりの場合）が続きます。

以下の例は、PathSetのシリアル化フォーマットを示します。

[{% inline-svg file="/docs/img/serialization-pathset.ja.svg" /%}](/docs/img/serialization-pathset.ja.svg "PathSetは複数のパスからなり、各パスの後に継続または終了を示すバイトが続きます。各パスは複数のパスステップからなり、各パスステップはタイプバイトと、タイプバイトに基づく1つ以上の160ビットフィールドで構成されます。")


### UIntフィールド
[UInt8]: #uintフィールド
[UInt16]: #uintフィールド
[UInt32]: #uintフィールド
[UInt64]: #uintフィールド

XRP Ledgerには符号なし整数タイプUInt8、UInt16、UInt32、UInt64があります。これらのタイプはすべて、指定されたビット数の標準ビッグエンディアンバイナリー符号なし整数です。

JSONオブジェクトにこれらのフィールドが含まれている場合、ほとんどはデフォルトでJSONの数値として表されます。例外として、UInt64は文字列として表されます。これは、一部のJSONデコーダーがこれらの整数を64ビットの「倍精度」浮動小数点数として表現しようとするためです。64ビットの「倍精度」浮動小数点数では、すべてのUInt64値を完全な精度で表現することができません。

もう1つの特殊なケースとして`TransactionType`フィールドがあります。JSONではこのフィールドは便宜上、トランザクションタイプの名前の文字列として表現されますが、バイナリではこのフィールドはUInt16です。[定義ファイル](#定義ファイル)内の`TRANSACTION_TYPES`オブジェクトにより、これらの文字列が特定の数値にマップされます。


### XChainBridgeフィールド
[XChainBridge]: #xchainbridgeフィールド

[{% inline-svg file="/docs/img/serialization-xchainbridge.ja.svg" /%}](/docs/img/serialization-xchainbridge.ja.svg "XChainBridgeのフォーマットの図")

`XChainBridge`フィールドは、[クロスチェーンブリッジ](../../concepts/xrpl-sidechains/cross-chain-bridges.md)に関連するトランザクションとレジャーエントリで使用され、XChainBridgeタイプの唯一のフィールドです。XChainBridgeフィールドは4つの要素から構成され、ブロックチェーン間のブリッジを定義します。

- ロックチェーンのドアアカウント、長さ接頭辞付きの[AccountID][]。
- ロックチェーンの資産タイプ、[STIssue][]。
- 発行チェーンのドアアカウント、長さ接頭辞付きの[AccountID][]。
- 発行チェーンの資産タイプ、[STIssue][]。

ネストされた2つの[STIssue][]タイプは、それぞれ160ビットまたは320ビットです。STIssueフィールドに含まれる通貨コードがすべて0の場合、STIssueフィールドは160ビットで、ブリッジされた資産がそれぞれのチェーンのネイティブ資産、例えばXRP Ledger MainnetのXRPであることを意味します。通貨コードが0でない場合、STIssueフィールドにはトークンのネイティブチェーンにおける発行者の(長さ接頭辞のない)AccountIDも含まれます。

{% admonition type="info" name="注記" %}ドアアカウントのAccountIDの値は長さ接頭辞付きですが、発行者のAccountIDの値は長さ接頭辞付きではありません。{% /admonition %}

全体として、XChainBridgeフィールドは常に656、816、または976ビット（82、102、または122バイト）のいずれかになります。

{% raw-partial file="/@l10n/ja/docs/_snippets/common-links.md" /%}