ARCHIVE/xrpl-dev-portal
1
0
Fork 0
mirror of https://github.com/XRPLF/xrpl-dev-portal.git synced 2025-12-06 17:27:57 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #2284 from tequdev/ja-outdated_translation-1

Browse Source 
[JA] update outdated_translation and some
This commit is contained in:
Rome Reginelli
2023-12-05 11:32:00 -08:00
committed by GitHub
parent 0ea1455771 b5e9288be6
commit d564710c34
30 changed files with 1412 additions and 215 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
content/@i18n/ja/references/http-websocket-apis/public-api-methods/subscription-methods/subscribe.md
View File

@@ -91,8 +91,8 @@ labels:
| `Field` | 型 | 説明 |
|:-------------|:--------|:----------------------------------------------------|
| `taker_gets` | オブジェクト | オファーを受諾するアカウントが受け取る通貨を[金額なしの通貨オブジェクト](basic-data-types.html#金額なしでの通貨の指定)として指定します。 |
| `taker_pays` | オブジェクト | オファーを受諾するアカウントが支払う通貨を[金額なしの通貨オブジェクト](basic-data-types.html#金額なしでの通貨の指定)として指定します。 |
| `taker_gets` | オブジェクト | オファーを受諾するアカウントが受け取る通貨を[金額なしの通貨オブジェクト](currency-formats.html#金額なしでの通貨の指定)として指定します。 |
| `taker_pays` | オブジェクト | オファーを受諾するアカウントが支払う通貨を[金額なしの通貨オブジェクト](currency-formats.html#金額なしでの通貨の指定)として指定します。 |
| `taker` | 文字列 | オファーを表示するパースペクティブとして使用する一意のアカウントアドレス（XRP Ledgerの[base58][]フォーマット）。（これはオファーの資金提供ステータスと手数料に影響します。） |
| `snapshot` | ブール値 | （省略可、デフォルトではfalse）trueの場合は、更新の送信前にサブスクライブした時点でオーダーブックの現在の状態を一度返します。 |
| `both` | ブール値 | （省略可、デフォルトではfalse）trueの場合は、オーダーブックの両サイドを返します。 |

2
content/@i18n/ja/references/http-websocket-apis/public-api-methods/transaction-methods/submit.md
View File

@@ -13,7 +13,7 @@ labels:
このコマンドには、以下の2つのモードがあります。
* 送信専用モードは、署名済みのシリアル化されたトランザクションをブロブとして取得し、そのままネットワークに送信します。署名済みのトランザクションオブジェクトは不変のものであるため、送信後は、どの部分も修正したり、自動的に内容を入力したりすることはできません。
* 送信専用モードは、署名済みのシリアル化されたトランザクションをBlobとして取得し、そのままネットワークに送信します。署名済みのトランザクションオブジェクトは不変のものであるため、送信後は、どの部分も修正したり、自動的に内容を入力したりすることはできません。
* 署名と送信モードでは、JSONフォーマットのトランザクションオブジェクトを取得し、[signメソッド][]と同じ方法でトランザクションを完成させて署名し、署名済みのトランザクションを送信します。テストと開発に関しては、このモードのみ使用することをお勧めします。
トランザクションを可能な限り確実に送信するには、トランザクションを事前に生成して[sign][sign method]メソッドで署名し、停電発生後もアクセスできるいずれかの場所に保存した後、`tx_blob`として`submit`メソッドで送信します。送信後は、ネットワークを[txメソッド][]コマンドで監視して、トランザクションが正常に適用されたかどうかを確認します。再起動やその他の問題が発生した場合ても、`tx_blob`のトランザクションを問題なく再送信できます。シーケンス番号が以前のトランザクションと同一であるため、トランザクションが2回適用されることはありません。

66
content/@i18n/ja/references/protocol/binary-format.md
View File

@@ -34,9 +34,9 @@ curated_anchors:
5. フィールド（プレフィクスを含む）をソート順に連結します。
その結果、ECDSA（secp256k1楕円曲線を使用）やEd25519などの既知の署名アルゴリズムを使用して署名できるバイナリブロブが1つ作成されます。XRP Ledgerのために、適切なプレフィクス（シングル署名の場合は`0x53545800`、マルシグの場合は`0x534D5400`）を使用してデータを[ハッシュ化][ハッシュ]する必要があります。署名後に、指定されている`TxnSignature`フィールドを使用してトランザクションを再度シリアル化する必要があります。 <!--{# TODO: link docs on how to compute a transaction signature. #}-->
その結果、ECDSA（secp256k1楕円曲線を使用）やEd25519などの既知の署名アルゴリズムを使用して署名できるバイナリBlobが1つ作成されます。XRP Ledgerのために、適切なプレフィクス（シングル署名の場合は`0x53545800`、マルシグの場合は`0x534D5400`）を使用してデータを[ハッシュ化][ハッシュ]する必要があります。署名後に、指定されている`TxnSignature`フィールドを使用してトランザクションを再度シリアル化する必要があります。 <!--{# TODO: link docs on how to compute a transaction signature. #}-->
**注記:** XRP Ledgerでは、[レジャーオブジェクト](ledger-object-types.html)や処理済みのトランザクションなど他のタイプのデータを表す場合にも同じシリアル化フォーマットが使用されます。ただし、署名されるトランザクションに追加するのに適切なフィールドは限られています。（たとえば署名自体が指定されている`TxnSignature`フィールドは、署名するバイナリブロブに含まれていてはなりません。）このように、「署名」フィールドとされてオブジェクトに署名するときにオブジェクトに含まれるフィールドもあれば、「非署名」とされてオブジェクトに含まれないフィールドもあります。
**注記:** XRP Ledgerでは、[レジャーオブジェクト](ledger-object-types.html)や処理済みのトランザクションなど他のタイプのデータを表す場合にも同じシリアル化フォーマットが使用されます。ただし、署名されるトランザクションに追加するのに適切なフィールドは限られています。（たとえば署名自体が指定されている`TxnSignature`フィールドは、署名するバイナリBlobに含まれていてはなりません。）このように、「署名」フィールドとされてオブジェクトに署名するときにオブジェクトに含まれるフィールドもあれば、「非署名」とされてオブジェクトに含まれないフィールドもあります。
### 例
@@ -105,7 +105,7 @@ curated_anchors:
[[ソース - エンコード]](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は、最終的なシリアル化ブロブでこのフィールドの前に付加されます。フィールドIDのサイズは、タイプコードとその結合対象のフィールドコードに応じて1～3バイトとなります。以下の表を参照してください。
フィールドのタイプコードとフィールドコードを結合すると、フィールドの一意のIDになります。このIDは、最終的なシリアル化Blobでこのフィールドの前に付加されます。フィールドIDのサイズは、タイプコードとその結合対象のフィールドコードに応じて1～3バイトとなります。以下の表を参照してください。
| | タイプコード < 16 | タイプコード >= 16 |
|:-----------------|:------------------------------------------------------------------------------|:--|
@@ -184,12 +184,12 @@ curated_anchors:
| [Hash256][] | 5 | 256 | いいえ | 256ビットの任意のバイナリ値。これは通常、トランザクション、レジャーバージョン、またはレジャーデータオブジェクトの「SHA-512ハーフ」ハッシュを表します。 |
| [PathSet][] | 18 | 可変 | いいえ | [複数通貨間ペイメント](cross-currency-payments.html)の有効な[ペイメントパス](paths.html)のセット。 |
| [STArray][] | 15 | 可変 | いいえ | 可変数のメンバーからなる配列。フィールドによってタイプが異なる場合があります。この例として、[memos](transaction-common-fields.html#memosフィールド)や[マルチ署名](multi-signing.html)で使用される署名者のリストがあります。 |
| [STIssue][] | 24 | 160 or 320 | いいえ | 数量を含まない、資産(XRPまたはトークン)を指定します。 |
| [STObject][] | 14 | 可変 | いいえ | 1つ以上のネストされたフィールドを含むオブジェクト。 |
| [UInt8][] | 16 | 8 | いいえ | 8ビットの符号なし整数。 |
| [UInt16][] | 1 | 16 | いいえ | 16ビットの符号なし整数。`TransactionType`は、このタイプの特殊なフィールドで、特定の文字列から整数値へのマッピングを含みます。 |
| [UInt32][] | 2 | 32 | いいえ | 32ビットの符号なし整数。このタイプの例として、すべてのトランザクションの`Flags`フィールドと`Sequence`フィールドがあります。 |
<!-- | [STIssue][] | 24 | 320 | いいえ | :not_enabled: 数量を含まない、資産(XRPまたはトークン)を指定します。 | -->
[長さプレフィクスを付加する]: #長さプレフィクスを付加する
@@ -227,7 +227,7 @@ curated_anchors:
トークンは以下の3つのセグメントで構成され、セグメントの順序は以下のとおりです。
1. [内部通貨フォーマット](currency-formats.html#トークンの計算)の額を示す64ビット。1番目のビットは、これがXRPではないことを示す`1`です。
1. [トークンの数量フォーマット](#トークンの数量フォーマット)の額を示す64ビット。1番目のビットは、これがXRPではないことを示す`1`です。
2. [通貨コード](currency-formats.html#通貨コード)を示す160ビット。標準APIでは、[標準通貨コードフォーマット](currency-formats.html#標準通貨コード)を使用して「USD」などの3文字のコードが160ビットのコードに変換されますが、160ビットのカスタムコードも使用できます。
3. イシュアーのアカウントIDを示す160ビット。（関連項目: [アカウントアドレスエンコード](addresses.html#アドレスのエンコード)
@@ -235,7 +235,40 @@ curated_anchors:
以下の図に、XRPの額とトークン額のシリアル化フォーマットを示します。
![「非XRP」ビット、符号ビット、および62ビットの精度で構成されるXRPの額。「非XRP」ビット、符号ビット、指数（8ビット）、仮数（54ビット）、通貨コード（160ビット）、イシュアー（160ビット）で構成されるトークンの額。](img/serialization-amount.ja.png)
![「非XRP」ビット、符号ビット、および62ビットの精度で構成されるXRPの額。「非XRP」ビット、符号ビット、指数（8ビット）、仮数（54ビット）、通貨コード（160ビット）、イシュアー（160ビット）で構成されるトークンの額。](img/serialization-amount.ja.svg)
#### トークンの数量フォーマット
[[ソース]](https://github.com/XRPLF/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/STAmount.cpp "ソース")
{{ include_svg("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.html)は、3文字のASCIIコードを160ビットの16進数に変換するための**標準フォーマット**を以下のようにサポートしています。
{{ include_svg("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ビットのデータです。
### 配列フィールド
@@ -252,10 +285,10 @@ curated_anchors:
![配列フィールドID、各配列要素のフィールドIDと内容、および「配列の終わり」を示すフィールドID](img/serialization-array.ja.png)
### ブロブフィールド
[Blob]: #ブロブフィールド
### Blobフィールド
[Blob]: #blobフィールド
ブロブタイプは、任意のデータを持つ[長さプレフィクスが付加されている](#長さプレフィクスを付加する)フィールドです。このタイプを使用する2種類の一般的なフィールドとして、`SigningPubKey`と`TxnSignature`があります。これらのフィールドにはそれぞれ、トランザクションの実行を承認する公開鍵と署名が含まれています。
Blobタイプは、任意のデータを持つ[長さプレフィクスが付加されている](#長さプレフィクスを付加する)フィールドです。このタイプを使用する2種類の一般的なフィールドとして、`SigningPubKey`と`TxnSignature`があります。これらのフィールドにはそれぞれ、トランザクションの実行を承認する公開鍵と署名が含まれています。
両方のフィールドにはこれ以上の内容構造がないため、フィールドIDと長さプレフィクスの後に可変長エンコードで示される正確なバイト数で構成されます。
@@ -269,20 +302,13 @@ XRP LedgerのハッシュタイプにはHash128、Hash160、Hash256がありま
これらのフィールドは、長さインディケーターを使用せずに、ビッグエンディアンバイトオーダーで特定数のビットとしてシリアル化されます。
<!--
### Issueフィールド
[STIssue]: #issueフィールド -->
<!-- TODO: translate this section -->
[STIssue]: #issueフィールド
<!--
_(The "Issue" or "STIssue" type is part of multiple proposed extensions to the XRP Ledger protocol, including [XLS-30d: Automated Market Maker](https://github.com/XRPLF/XRPL-Standards/discussions/78) :not_enabled: and [Federated Sidechains](federated-sidechains.html) :not_enabled:)_
-->
いくつかのフィールドは、XRPや[トークン](tokens.html)といったアセットタイプを指定します。これらのフィールドは、1つまたは2つの160ビットから構成されています：
<!--
Some fields specify a _type_ of asset, which could be XRP or a fungible [token](tokens.html), without an amount. These fields have consist of two 160-bit segments in order:
1. The first 160 bits are the [currency code](currency-formats.html#通貨コード) of the asset. For XRP, this is all 0's.
2. The next 160 bits are the [AccountID of the token issuer](#accountidフィールド). For XRP, this is all 0's. -->
1. 最初の160ビットはアセットの[通貨コード](#通貨コード)です。XRPの場合、これはすべて0です。
2. 最初の160ビットが全て0の場合(アセットがXRPの場合)、フィールドはそこで終了します。そうでない場合、アセットはトークンであり、次の160ビットは[トークン発行者のAccountID](#accountidフィールド)です。
### オブジェクトフィールド
[STObject]: #オブジェクトフィールド

90
content/@i18n/ja/references/protocol/data-types/basic-data-types.md
View File

@@ -1,13 +1,13 @@
---
html: basic-data-types.html
parent: protocol-reference.html
blurb: さまざまなタイプのオブジェクトがそれぞれ異なる方法で一意に識別されます。
blurb: アドレス、レジャーインデックス、通貨コードなどの基本的なデータタイプのフォーマットと意味について説明します。
---
# 基本的なデータ型
さまざまなタイプのオブジェクトがそれぞれ異なる方法で一意に識別されます。
[アカウント](accounts.html)は[アドレス][]で識別されます。例えば、`"r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"`など。アドレスは常に「r」で始まります。`rippled`メソッドの多くは、16進数表記に対応しています。
[アカウント](accounts.html)は`"r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"`のような[アドレス][]で一意に識別されます。アドレスは常に「r」で始まります。`rippled`メソッドの多くは、16進数表記に対応しています。
[トランザクション](transaction-formats.html)は、トランザクションのバイナリフォーマットの[ハッシュ][]で識別されます。また、トランザクションは送信アカウントと[シーケンス番号][]でも識別できます。
@@ -72,79 +72,59 @@ blurb: さまざまなタイプのオブジェクトがそれぞれ異なる方
APIメソッドの多くは、レジャーのインスタンスを指定する必要があります。その場合、共有されたレジャーの特定バージョンで最新と見なされるデータで指定する必要があります。レジャーバージョンを受け入れるコマンドは、すべて同様に機能します。使用するレジャーを指定するには、以下の3つの方法があります。
1. `ledger_index`パラメーターにレジャーの[レジャーインデックス][]を指定します。閉鎖された各レジャーには識別用のレジャーインデックスが付いていて、その前に検証されたレジャーより1つ大きい番号になります。（最初のレジャーのインデックスは1です。）
2. `ledger_hash`パラメーターにレジャーの[ハッシュ][]値を指定します。
3. `ledger_index`パラメーターに以下のいずれかのショートカットを指定します。
* `validated`: ネットワーク全体で検証された最新のレジャー
1. `ledger_index`パラメータにレジャーの[レジャーインデックス][]を指定します。閉鎖された各レジャーには識別用のレジャーインデックスが付いていて、その前に検証されたレジャーより1つ大きい番号になります。（最初のレジャーのインデックスは1です。）
"ledger_index": 61546724
2. `ledger_hash`パラメータにレジャーの[ハッシュ][]値を指定します。
"ledger_hash": "8BB204CE37CFA7A021A16B5F6143400831C4D1779E6FE538D9AC561ABBF4A929"
3. `ledger_index`パラメータに以下のいずれかのショートカットを指定します。
* `validated`: [コンセンサスで検証](consensus-structure.html#検証)された最新のレジャー
"ledger_index": "validated"
* `closed`: 変更できないように閉鎖され、検証を提案されている最新のレジャー
* `current`: サーバーで現在処理中のレジャーバージョン
上記3つのフォーマットすべてを受け入れる、廃止予定の`ledger`パラメーターもあります。このパラメーターは使用*しないでください*。今後予告なしに廃止される可能性があります。
レジャーを指定しない場合、デフォルトで`current`（処理中）レジャーが選択されます。レジャーを指定するフィールドを複数指定した場合、廃止予定の`ledger`フィールドが最初に使用され（存在する場合）、`ledger_hash`に戻ります。`ledger_index`フィールドは、他の2つのフィールドがいずれも存在しない場合を除いて無視されます。
レジャーを指定しない場合、デフォルトで`current`（処理中）レジャーが選択されます。レジャーを指定しなかった場合、サーバはリクエストにどのレジャーを使うかを決めます。デフォルトでは、サーバは`current`(進行中)のレジャーを選択します。[レポートモード](rippled-server-modes.html#レポートモード)では、サーバは最新の検証済みレジャーを使います。レジャーを指定するフィールドは複数指定しないでください。
**注記:** レジャーを指定する際に上記のデフォルトの動作に頼らないでください。変更される場合があります。可能であれば、常にリクエストでレジャーバージョンを指定してください。
レポートモードでは、検証済みとなるまでレジャーデータは記録されません。レポートモードサーバに`current`または`closed`のレジャーをリクエストすると、サーバはそのリクエストを P2Pモードサーバに転送します。検証されていないレジャー番号またはハッシュを要求した場合、レポートモードのサーバは`lgrNotFound`エラーを返します。
**注記:** レジャーを指定する際に上記のデフォルトの動作に頼らないでください。変更される場合があります。可能であれば、常に要求にてレジャーバージョンを指定してください。
### 通貨額の指定
一部のAPIメソッドでは、通貨額を指定する必要があります。取扱通貨がネットワーク固有のXRP通貨であるかその他の通貨単位（_イシュアンス_）であるかによって、指定方法が大きく異なります。
XRP LedgerにはXRPとトークンの2種類の通貨があります。これら2種類の通貨は、異なるフォーマット、異なる精度と丸め動作で指定されます。
#### XRP
[XRPのdrop数]: #xrp
[XRP、drop単位]: #xrp
[Paymentトランザクション][]で送金する`Amount`のようないくつかのフィールドは、どちらのタイプにもすることができます。`Fee`フィールド（[トランザクションコスト](transaction-cost.html)）のように、XRPのみを使用可能なフィールドもあります。
XRPの額は文字列で表します。（XRPの精度は64ビット整数と同等ですが、JSON 整数は32ビットに制限されるため、JSON整数で表す場合はXRPがオーバーフローする恐れがあります。）XRPは正式には「drop」で指定します。これは0.000001（百万分の1）のXRPと等価です。したがって、JSON文書で1.0 XRPを表示するには、次のように書きます。
XRPは、XRPの “drop"数を含む整数の文字列として指定され、100万ドロップが1XRPに相当します。トークンは、10進数の金額、通貨コード、発行者のフィールドを持つオブジェクトとして指定されます。
```
"1000000"
```
- **XRP** - `Amount`フィールドに13.1 XRPを指定するには:
**XRPをオブジェクトに指定しないでください。**
"Amount": "13100000"
単体テストでは、XRPの値（dropではありません）を小数点を使用して指定できます。例えば、「1.23」は1.23 XRPを意味します。それ以外のすべての場合では、XRPは常にdrop単位で指定し、小数点は使用しません。例えば、「1230000」は1.23 XRPを意味します。
- **トークン** - `rf1B...`が発行した13.1 FOOという値で`Amount`フィールドを指定するには：
#### 非XRP
"Amount": {
"value": "13.1",
"currency": "FOO",
"issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn"
}
XRP以外の通貨（法定通貨としてのドル、貴金属、暗号資産、その他のカスタム通貨を含む）を指定する場合、通貨指定オブジェクトを使用して指定する必要があります。以下は、3つのフィールドを持つJSONオブジェクトです。
| `Field` | 型 | 説明 |
|:-----------|:---------------------------|:-----------------------------------|
| `currency` | 文字列 - [通貨コード][] | 通貨を発行するための任意コード。`XRP`は使用できません。 |
| `value` | 文字列 | 通貨の金額を表す引用符付き10進数表記。これには科学的記数法が含まれ、例えば`1.23e11`は123,000,000,000を意味します。`e`と`E`のどちらも使用できます。 |
| `issuer` | 文字列 | 通貨を発行する組織の一意のアカウントアドレス。つまり、通貨を清算できる個人または企業です。 |
**注意:** これらのフィールド名は大文字小文字の区別があります。
例えば、アカウント`r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59`によって発行された$153.75 USドルは、以下のように指定します。
```
{
"currency": "USD",
"value": "153.75",
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"
}
```
単体テストでは、非XRP通貨の金額値をスラッシュで区切られた文字列で指定できます。例えば、`"amount/currency/issuer"`のフォーマットになります。その他すべての場合では、前述のJSONオブジェクトのフォーマットを使用する必要があります。
#### 金額なしでの通貨の指定
XRP以外の通貨を金額なしで指定する場合は（主に、通貨取引オファーのオーダーブックを定義する場合など）、上記のように指定しますが、`value`フィールドは省略します。
XRPを金額なしで指定する場合は（主に、オーダーブックを定義する場合など）、JSONオブジェクトとして指定しますが、使用するフィールドは`currency`フィールド _のみ_ です。XRPの場合は`issuer`フィールドを指定してはいけません。
最後に、支払いの受取人アカウントが複数のイシュアー（通貨発行者）を信頼している場合は、受取人が受け入れているイシュアーがどのように組み合わされても支払いが行われるように指定できます。これを行うには、受取人アカウントのアドレスをJSONオブジェクトに`issuer`値として指定します。
### 通貨コード
[通貨コード]: #通貨コードs
{% include '_snippets/data_types/currency_code.ja.md' %}
<!--{#_ #}-->
詳しくは[通貨フォーマット](currency-formats.html)をご覧ください。
## 時間の指定
`rippled`サーバーとそのAPIでは、時間を符号なし整数で表します。この数値は、「Rippleエポック」である2000年1月1日（00:00 UTC）から経過した秒数を表しています。これは[UNIXエポック](http://en.wikipedia.org/wiki/Unix_time)と同様に機能しますが、RippleエポックはUNIXエポックより946684800秒遅れています。
`rippled`サーバとそのAPIでは、時間を符号なし整数で表します。この数値は、「Rippleエポック」である2000年1月1日（00:00 UTC）から経過した秒数を表しています。これは[UNIXエポック](http://en.wikipedia.org/wiki/Unix_time)と同様に機能しますが、RippleエポックはUNIXエポックより946684800秒遅れています。
Rippleエポック時間を32ビット変数でUNIXエポック時間に変換しないでください。整数のオーバーフローが発生する恐れがあります。

144
content/@i18n/ja/references/protocol/data-types/currency-formats.md
View File

@@ -1,74 +1,134 @@
---
html: currency-formats.html
parent: basic-data-types.html
blurb: 通貨番号の精度と範囲、カスタム通貨コードのフォーマットです。
blurb: XRP Ledgerで利用可能な通貨の精度と範囲、カスタム通貨コードのフォーマットについて説明します。
labels:
- XRP
- トークン
---
# 通貨フォーマット
XRP Ledgerには2種類の通貨 XRP と[トークン](tokens.html)）があります。XRP Ledgerでは、これらの通貨のフォーマットは異なりますが、いずれの通貨も高精度です。
XRP Ledgerには2種類の通貨、XRPと[トークン](tokens.html)があります。XRP Ledgerでは、これらの通貨のフォーマットは異なりますが、どちらも高精度です。
## 比較
以下の表は、XRP LedgerにおけるXRPとトークンの違いをまとめたものです。
| XRP | トークン |
|:---------------------------------------------------------|:------------------|
| 発行者は存在しません。 | XRP Ledgerのアカウントから発行されます。 |
| 文字列形式で指定します。 | オブジェクト形式で指定します。 |
| [アカウント](accountroot.html)に記録されます。 | [トラストライン](ripplestate.html)に記録されます。 |
| バーンするのみで作成することはできません。 | 自由に発行・償還が可能です。 |
| 最小値: `0` (負の値はありません) | 最小値: `-9999999999999999e80` ゼロでない絶対値の最小値: `1000000000000000e-96`
| 最大値 `100000000000` (10<sup>11</sup>) XRP (`100000000000000000` (10<sup>17</sup>) "drops") | 最大値 `9999999999999999e80` |
| 最小の精度: "drop" (0.000001 XRP) | 小数点以下15桁の精度 |
| [凍結](freezes.html)できません | 発行者は残高を[凍結](freezes.html)することができます |
| 送金手数料はかかりません。XRP同士の支払いは常に直接行われます | 間接的な[パス](paths.html)を取ることができ、各発行者は一定の[送金手数料](transfer-fees.html)を請求できます |
| [ペイメントチャンネル](payment-channels.html)と[エスクロー](escrow.html)で使用できます | ペイメントチャネルやエスクローには対応していません |
詳しくは [XRPとは?](what-is-xrp.html)や[トークン](tokens.html)をご覧ください。
## 通貨額の指定
指定する通貨の適した形式を使用してください。
- [XRPの金額](#xrpの金額)
- [トークンの金額](#トークンの金額)
### XRPの金額
XRPの金額はdropの値(1XRP = 1,000,000drop)で[文字列フォーマット]で表します。これは0.000001（百万分の1）のXRPと等価です。したがって、JSONで13.1 XRPを表示するには、次のように書きます。
```
"13100000"
```
**XRPをオブジェクト形式で指定しないでください。**
XRPの金額は負になることはありません。
### トークンの金額
[(代替可能な)トークン](tokens.html)の金額を指定するには、Amountオブジェクトを使用します。これは、3つのフィールドを持つJSONオブジェクトです。
| `Field` | 型 | 説明 |
|:-----------|:---------------------|:-----------------------------------|
| `currency` | 文字列 - [通貨コード][] | トークンの任意の通貨コード。`XRP`は使用できません。 |
| `value` | [文字列フォーマット][] | トークンの金額を10進数で表します。1.23e11`は123,000,000,000を意味します。e` と `E` の両方を使用することができます。残高を表示する場合には負の値を指定することができますが、送信金額を指定する場合などには負の値を指定することはできません。 |
| `issuer` | 文字列 | 一般的には、このトークンを発行する[アカウント](accounts.html)を指します。特殊なケースでは、トークンを保持しているアカウントを指します(例えば、[Clawback](clawback.html)トランザクションの場合など)。 |
[文字列フォーマット]: #文字列フォーマット
**注意:** これらのフィールド名は大文字小文字の区別があります。
例えば、アカウント`r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59`によって発行された$153.75 USドルは、以下のように指定します。
```json
{
"currency": "USD",
"value": "153.75",
"issuer": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59"
}
```
#### 金額なしでの通貨の指定
場合によっては、[分散型取引所](decentralized-exchange.html)でオーダーブックを指定するときなど、特定の金額なしで資産(XRPやトークン)を定義する必要があります。
金額なしでトークンを記述するには、通貨オブジェクトとして指定し、`value`フィールドを省略します。例えば
```json
{
"currency": "TST",
"issuer": "rP9jPyP5kyvFRb6ZiRghAGw5u8SGAmU4bd"
}
```
XRPを金額なしで記述するには、JSONオブジェクトとして`currency`フィールドのみを指定してください。XRPの`issuer`フィールドは含めないでください。例えば
```json
{
"currency": "XRP"
}
```
## 文字列フォーマット
{% include '_snippets/string-number-formatting.md' %}
<!--{#_ #}-->
{% include '_snippets/string-number-formatting.ja.md' %}
## XRPの精度
XRPの精度は、64ビット符号なし整数と同等であり、各単位は0.000001 XRPと同等です。プロパティは次の通りです。
* 最小値: `0`
* 最大値: `100000000000`（10<sup>11</sup>）XRP
- `"100000000000000000"`（10<sup>17</sup>） dropのXRP
* `0.000001`（10<sup>-6</sup>）XRPに近い精度
- `"1"` dropのXRP
XRPは64ビットの符号なし整数と同じ精度を持ち、各単位は0.000001 XRPに相当します。XRPは整数計算を使用するため、1dropに満たない金額は切り捨てられます。
## トークンの精度
XRP Ledgerのトークンは、以下の精度のカスタムフォーマットで表現されます。
トークンは、一般的に非常に小さい額や非常に大きい額で取引されるものを含め、さまざまな資産を表すことができます。このフォーマットは、科学的記数法と同様に、有効数字と10の累乗指数を使用します。このフォーマットは、指定された範囲内で有効数字の正負と指数をサポートしています。整数でない数の一般的な浮動小数点表現とは異なり、この形式ではすべての計算に整数演算を使用するため、常に小数点以下15桁の精度を維持します。掛け算と割り算には、最下位桁の丸めすぎを補正する調整があります。
* 非ゼロの最小絶対値: `1000000000000000e-96`
* 最大値: `9999999999999999e80`
* 最小値: `-9999999999999999e80`
* 10進15桁の精度
## トークンの計算
[[ソース]](https://github.com/XRPLF/rippled/blob/35fa20a110e3d43ffc1e9e664fc9017b6f2747ae/src/ripple/protocol/impl/STAmount.cpp "Source")
![トークンの金額フォーマットの図](img/currency-number-format.ja.png)
`rippled`内部ではトークンの数値はカスタムの数値フォーマットで表現されます。このフォーマットではさまざまな資産（一般的にごく小さな単位または極めて大きな単位で測定される資産を含む）を保管できます。このフォーマットでは、有効数字と10のべき乗の指数を科学的記数法と同様の方法で使用します。このフォーマットは、指定された範囲内のプラスまたはマイナスの有効桁数と指数に対応しています。非整数値の一般的な浮動小数点表記とは異なり、このフォーマットでは整数を用いて計算します。このため、常に15桁の精度が維持されます。乗算と除算には、最下位の有効数字の丸め過ぎを補う調整機能があります。
「任意精度」の数値フォーマットとは異なり、カスタムフォーマットは64ビットの固定サイズで格納できます。このようにシリアル化される場合、このフォーマットは「非XRP」ビット、符号ビット、有効桁数、指数で構成されます。これらは次の順で表示されます。
1. トークン金額の1番目のビット（最上位ビット）は、XRPの額ではないことを示す`1`です。（XRPの額である場合、最上位ビットは常に`0`に設定され、このフォーマットからXRPの額が区別されます。）
2. 符号ビットは、金額のプラスマイナスを示します。標準的な[2の補数で表される](https://en.wikipedia.org/wiki/Two%27s_complement)整数とは異なり、`1` はXRP Ledgerフォーマットでは**プラス**を示し`0`はマイナスを示します。
3. 次の8ビットは、指数を符号なし整数で表しています。指数は、小数点以下桁数（有効桁数に乗算する10のべき乗）を-96以上+80以下の範囲で示します。ただしシリアル化では、この指数に97を加算して符号なし整数としてシリアル化できるようにします。したがってシリアル化された値が`1`の場合は指数`-96`、シリアル化された値が`177`の場合は指数80を示します。
4. 残りの54ビットは、有効数字を符号なし整数で表します。シリアル化では、値0の特殊なケースを除き、この値は10<sup>15</sup>（`1000000000000000`）以上10<sup>16</sup>-1（`9999999999999999`）以下の範囲で正規化されます。値0の特殊なケースがあります。この場合符号ビット、指数、および仮数はすべてゼロであるため、64ビット値は`0x8000000000000000000000000000000000000000`としてシリアル化されます。
XRP Ledgerのピアツーピアネットワークでトークンの金額を送信する場合、サーバは金額を64ビットのバイナリ値に[シリアライズ](serialization.html)します。
**ヒント：** 分割不可能なトークンについては、[非代替性トークン(NFT)](non-fungible-tokens.html)をご覧ください。
## 通貨コード
[通貨コード]: #通貨コード
{% include '_snippets/data_types/currency_code.ja.md' %}
<!--{#_ #}-->
XRP LedgerのXRP以外の通貨には160ビットの通貨コードがあります。[`rippled`API](http-websocket-apis.html)では、標準マッピングを使用して3文字のASCII文字列（大文字と小文字の区別あり）が160ビットの通貨コードにマッピングされます。通貨コード`XRP`はトークンには使用できません。同一コードの通貨は接続トラストラインを通じて[ripple](rippling.html)できます。通貨コードには、XRP Ledgerに組み込まれるその他の動作はありません。
### 標準通貨コード
標準通貨マッピングによりビットが次のように割り当てられます。
通貨コードの標準フォーマットは`USD`のような3文字の文字列です。これは[ISO 4217 Currency Codes](https://www.xe.com/iso4217.php)で使用するためのものです。以下のルールがあります。
![標準通貨コードのフォーマット](img/currency-code-format.ja.png)
- 通貨コードの長さは正確に3文字のASCII文字でなければなりません。すべての大文字と小文字、桁数、および記号`?`、`!`、`@`、`#`、`$`、`%`、`^`、`&`、`*`、`<`、`>`、`(`、`)`、`{`、`}`、`[`、`]`、および<code>|</code>の組み合わせが利用可能です。
- 通貨コードは大文字と小文字を区別します。
- 通貨コード`XRP`（すべて大文字）は使用できません。ネイティブトークンとしてのXRPは通常、XRP Ledgerプロトコルでは通貨コードを使用しません。
1. 最初の8ビットは`0x00`でなければなりません。
2. 次の88ビットは予約済みであり、すべて`0`です。
3. 次の24ビットは3つのASCII文字を表します。
[ISO 4217](https://www.xe.com/iso4217.php)コードまたはよく利用されている疑似ISO 4217コード（BTCなど）の使用が推奨されます。ただし、すべての大文字と小文字、桁数、および記号`?`、`!`、`@`、`#`、`$`、`%`、`^`、`&`、`*`、`<`、`>`、`(`、`)`、`{`、`}`、`[`、`]`、および<code>|</code>の組み合わせを使用できます。通貨コード`XRP`（すべて大文字）はXRP用に予約されており、トークンには使用できません。
4. 次の40ビットは予約済みであり、すべて`0`です。
通常、XRP額の指定時には通貨コードは使用しません。フィールドにXRPの通貨コードが指定されている稀なケースでは、通貨コードのバイナリ形式はすべてゼロになります。
プロトコルレベルでは、このフォーマットは[シリアライズ](serialization.html#通貨コード)され、`0x00`で始まる160ビットのバイナリ値になります。
### 非標準通貨コード
通貨コードとして160ビット（40文字）16進文字列（例: `015841551A748AD2C1F76FF6ECB0CCCD00000000`）を使用して、その他のタイプの通貨を発行することもできます。異なる通貨コードタイプとして扱われないようにするには、先頭8ビットが`0x00`であってはなりません。
また、`015841551A748AD2C1F76FF6ECB0CCD000000`のような160ビット(40文字)の16進文字列を通貨コードとして使用することもできます。これが「標準的な」通貨コードとして扱われるのを防ぐために、最初の8ビットは`0x00`にしてはいけません (MUST NOT)。
**廃止予定:** 一部の旧バージョンの[ripple-lib](https://github.com/XRPLF/xrpl.js)では通貨コードタイプとして「有利子」または「マイナス利子」がサポートされていました。これらの通貨の先頭8ビットは`0x01`です。マイナス利子/有利子通貨はサポートされなくなりましたが、レジャーデータにこのような通貨が現れることがあります。詳しくは、[マイナス利子](demurrage.html)を参照してください。
**廃止予定:** 一部の旧バージョンの[ripple-lib](https://github.com/XRPLF/xrpl.js)では通貨コードの種類として「有利子」または「マイナス利子」がサポートされていました。これらの通貨の先頭8ビットは`0x01`です。マイナス利子/有利子通貨はサポートされなくなりましたが、レジャーデータにこのような通貨が現れることがあります。詳しくは、[マイナス利子](demurrage.html)をご覧ください。

22
content/@i18n/ja/references/protocol/data-types/nftoken.md
View File

@@ -7,11 +7,11 @@ labels:
---
# NFToken
`NFToken`オブジェクトは、1つの非代替性トークン(NFT)を表します。単体では保存されず、他のNFTと共に[NFTokenPage オブジェクト][]に格納されます。
`NFToken`オブジェクトは、1つの非代替性トークン(NFT)を表します。単体では保存されず、他の`NFToken`オブジェクトと共に[NFTokenPage オブジェクト][]に格納されます。
_([NonFungibleTokensV1_1 amendment][]により追加されました。)_
{{currentpage.name}} JSONの例
## {{currentpage.name}} JSONの例
```json
{
@@ -20,11 +20,12 @@ _([NonFungibleTokensV1_1 amendment][]により追加されました。)_
}
```
通常の[ledger entries](ledger-object-types.html)とは異なり、`NFToken`にはオブジェクトのタイプや現在の所有者を特定するフィールドはありません。`NFToken`オブジェクトは、そのオブジェクトのタイプを暗黙的に定義し、所有者を特定するページにグループ化されます。
通常の[レジャーエントリ](ledger-object-types.html)とは異なり、`NFToken`にはオブジェクトのタイプや現在の所有者を特定するフィールドはありません。`NFToken`オブジェクトは、そのオブジェクトのタイプを暗黙的に定義し、所有者を特定するページにグループ化されます。
## NFTokenID
NFTokenID, 任意, 文字列, Hash256
この複合フィールドは、トークンを一意に識別するものであり、以下のセクションから構成されます。
@@ -43,7 +44,6 @@ E) 32ビットの（自動生成される）単調増加するのシーケンス
16ビットのフラグ、送金手数料フィールド、32ビットの`NFTokenTaxon`、シーケンス番号フィールドはビッグエンディアン形式で格納されます。
## NFToken フラグ
フラグは、`NFToken`オブジェクトに関連するプロパティやその他のオプションです。
@@ -53,15 +53,15 @@ E) 32ビットの（自動生成される）単調増加するのシーケンス
|:------------------|:-----------|:--------------------------------------------|
| `lsfBurnable` | `0x0001` | 設定されている場合、発行者（または発行者が許可したエンティティ）が`NFToken`を破棄できることを示します。オブジェクトの所有者は常に破棄することができます。 |
| `lsfOnlyXRP` | `0x0002` | 設定されている場合、`NFToken`はXRPに対してのみオファーまたは売却できることを示します。 |
| `lsfTrustLine` | `0x0004` | **廃止** 設定されている場合、送金手数料を保持するための[トラストライン](trust-lines-and-issuing.html)を自動的に作成します。設定されていない場合、発行者がそのトークンのトラストラインを持っていない場合、この`NFToken`をそのトークンで売買することは失敗します。[fixRemoveNFTokenAutoTrustLine amendment][]により、このフラグは利用できなくなります。|
| `lsfTrustLine` | `0x0004` | **廃止予定** 設定されている場合、送金手数料を保持するための[トラストライン](trust-lines-and-issuing.html)を自動的に作成します。設定されていない場合、発行者がそのトークンのトラストラインを持っていない場合、この`NFToken`をそのトークンで売買することは失敗します。[fixRemoveNFTokenAutoTrustLine amendment][]により、このフラグは利用できなくなります。|
| `lsfTransferable` | `0x0008` | 設定されている場合、この`NFToken`は所有者から別の所有者に転送することができます。設定されていない場合、所有者は発行者との間でのみ譲渡が可能です。 |
| `lsfReservedFlag` | `0x8000` | 本提案では、このフラグを将来の使用に備えて確保します。このフラグを設定しようとすると失敗します。 |
| `lsfReservedFlag` | `0x8000` | 将来の使用に備えて確保されています。このフラグを設定しようとすると失敗します。 |
`NFToken`のフラグは変更できません。[NFTokenMint トランザクション][]でのみ設定可能で、後で変更することはできません。
### 例
この例では、`lsfBurnable`(0x0001), `lsfOnlyXRP`(0x0002), `lsfTransferable`(0x0008)の3つのフラグを設定しています。1+2+8 = 11、つまりビッグエンディアン形式で0x000Bです。
この例では、`lsfBurnable`(`0x0001`), `lsfOnlyXRP`(`0x0002`), `lsfTransferable`(`0x0008`)の3つのフラグを設定しています。1+2+8 = 11、つまりビッグエンディアン形式で`0x000B`です。
![フラグ](img/nftokena.png "フラグ")
@@ -84,13 +84,14 @@ E) 32ビットの（自動生成される）単調増加するのシーケンス
### NFTokenTaxon(分類群)
4番目のセクションは、発行者が作成する`NFTokenTaxon`です。
![NFTokenTaxon](img/nftokend.png)
4番目のセクションは、発行者が指定する`NFTokenTaxon`です。
![`NFTokenTaxon` の概要図](img/nftokend.png)
発行者は同じ`NFTokenTaxon`を持つ複数の`NFToken`を発行する可能性があります。`NFToken`が複数のページにまたがるようにするため、`NFTokenTaxon`は第5セクションの連番を乱数発生器のシード値として乱数化されています。乱数化された値は`NFToken`と共に保存されますが、乱数化されていない値が実際の`NFTokenTaxon`となります。
`NFTokenTaxon`の値は`0xBC8B858E`ですが、これは発行者が指定した`NFTokenTaxon`の値が乱数化されたものであることに注意してください。`NFTokenTaxon`の実際の値は乱数化されていない値です。
`NFTokenTaxon`の値は`0xBC8B858E`ですが、これは発行者が指定した`NFTokenTaxon`の値が乱数化されたものであることに注意してください。`NFTokenTaxon`の実際の値は _乱数化されていない_ 値です。
### トークン連番
@@ -100,7 +101,6 @@ E) 32ビットの（自動生成される）単調増加するのシーケンス
[NFTokenMint トランザクション][]では`NFTokenID`のこのフィールドを`Issuer`アカウントの`MintedNFTokens`フィールドを基に自動的に設定します。発行者の[AccountRoot オブジェクト][]が`MintedNFTokens`フィールドを持っていない場合、そのフィールドは値 0 と見なされます。フィールドの値は1ずつ増加します。
## URI
URIフィールドは、`NFToken`に関連するデータまたはメタデータを指します。このフィールドはHTTPやHTTPSのURLである必要はありません。IPFS URIや紐づくリンク、[RFC2379 "data" URL](https://datatracker.ietf.org/doc/html/rfc2397)、あるいはカスタムされたのエンコード値である可能性もあります。URIの有効性はチェックされませんが、フィールドの長さは最大256バイトに制限されます。

6
content/@i18n/ja/references/protocol/transactions/index.md
View File

@@ -1,12 +1,12 @@
---
html: transaction-formats.html
parent: protocol-reference.html
blurb: トランザクションは、XRP Ledgerを変更する唯一の方法です。
blurb: プロトコルのすべてのトランザクションタイプとその結果を説明します。
template: pagetype-category.html.jinja
---
# トランザクションのフォーマット
# トランザクションリファレンス
_トランザクション_ は、XRP Ledgerを変更する唯一の方法です。[コンセンサスプロセス](consensus.html)に従って署名され、送信され、検証済みのレジャーバージョンに承認された場合にのみ、トランザクションは最終的なものになります。レジャーのルールによっては、 _[疑似トランザクション](pseudo-transaction-types.html)_ も生成されます。このトランザクションは署名も送信もされませんが、コンセンサスによって承認されなければならないことは同様です。失敗したトランザクションも、スパム対策の[トランザクションコスト][]を支払うためにXRPの残高が変更されることから、レジャーに含まれます。
_トランザクション_ は、XRP Ledgerを変更する唯一の方法です。[コンセンサスプロセス](consensus.html)に従って署名され、送信され、検証済みのレジャーバージョンに承認された場合にのみ、トランザクションは[最終](finality-of-results.html)的なものになります。レジャーのルールによっては、 _[疑似トランザクション](pseudo-transaction-types.html)_ も生成されます。このトランザクションは署名も送信もされませんが、コンセンサスによって承認されなければならないことは同様です。失敗したトランザクションも、スパム対策の[トランザクションコスト][]を支払うためにXRPの残高が変更されることから、レジャーに含まれます。
<!--{# common link defs #}-->

69
content/@i18n/ja/references/protocol/transactions/metadata.md
View File

@@ -1,7 +1,7 @@
---
html: transaction-metadata.html
parent: transaction-formats.html
blurb: トランザクションのメタデータは、トランザクションの処理後にトランザクションに追加されるひとまとまりのデータです。
blurb: トランザクションのメタデータは、トランザクションが成功したかどうかに関係なく、トランザクションの結果を詳細に記述します。
labels:
- ブロックチェーン
---
@@ -15,9 +15,72 @@ labels:
{% include '_snippets/tx-metadata-field-table.ja.md' %} <!--_ -->
## メタデータの例
次のJSONオブジェクトは、[複雑なクロスカレンシー支払い](https://livenet.xrpl.org/transactions/8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B)のメタデータを示しています。
```json
{% include '_api-examples/metadata/cross-currency-payment.json' %}
```
## AffectedNodes
`AffectedNodes`配列には、このトランザクションが何らかの変更を加えた[レジャーエントリ](ledger-object-types.html)の完全なリストが格納されます。この配列の各項目は、何が起こったかを示すトップレベルのフィールドを1つ持つオブジェクトです。
- `CreatedNode`: トランザクションが新しいレジャーエントリを作成したことを示します。
- `DeletedNode`: トランザクションが新しいレジャーエントリを削除したことを示します。
- `ModifiedNode`: トランザクションが既存のレジャーエントリを更新したことを示します。
これらの各フィールドの値は、レジャーエントリに行われた変更を記述するJSONオブジェクトです。
### CreatedNodeのフィールド
`CreatedNode`オブジェクトは次のフィールドを含みます。
| フィールド | 値 | 説明 |
|:------------------|:--------------------|:-------------------------------------|
| `LedgerEntryType` | 文字列 | 作成された[レジャーエントリの種類](ledger-object-types.html)。 |
| `LedgerIndex` | 文字列 - [ハッシュ][] | レジャーの[状態ツリー](ledgers.html)内のこの[レジャーエントリのID](ledger-object-ids.html)。**注意:** 名前が非常に似ていますがこれは[レジャーインデックス](basic-data-types.html#レジャーインデックス)とは**異なります**。 |
| `NewFields` | オブジェクト | 新しく作成されたレジャー エントリの内容を示すフィールド。どのフィールドが存在するかは、作成されたレジャーエントリの種類によって異なります。 |
### DeletedNodeのフィールド
`DeletedNode`オブジェクトは次のフィールドを含みます。
| フィールド | 値 | 説明 |
|:------------------|:--------------------|:-------------------------------------|
| `LedgerEntryType` | 文字列 | 削除された[レジャーエントリの種類](ledger-object-types.html)。 |
| `LedgerIndex` | 文字列 - [ハッシュ][] | レジャーの[状態ツリー](ledgers.html)内のこの[レジャーエントリのID](ledger-object-ids.html)。**注意:** 名前が非常に似ていますがこれは[レジャーインデックス](basic-data-types.html#レジャーインデックス)とは**異なります** |
| `FinalFields` | オブジェクト | 削除されたレジャーエントリの最後の内容を示すフィールド。どのフィールドが存在するかは、削除されたレジャーエントリの種類によって異なります。 |
### ModifiedNodeのフィールド
`ModifiedNode`オブジェクトは次のフィールドを含みます。
| フィールド | 値 | 説明 |
|:--------------------|:---------------------------|:---------------------------|
| `LedgerEntryType` | 文字列 | 更新された[レジャーエントリの種類](ledger-object-types.html)。 |
| `LedgerIndex` | 文字列 - [ハッシュ][] | レジャーの[状態ツリー](ledgers.html)内のこの[レジャーエントリのID](ledger-object-ids.html)。**注意:** 名前が非常に似ていますがこれは[レジャーインデックス](basic-data-types.html#レジャーインデックス)とは**異なります**。 |
| `FinalFields` | オブジェクト | このトランザクションからの変更を適用した後のレジャーエントリの内容を示すフィールド。どのフィールドが存在するかは、作成されたレジャーエントリの種類によって異なります。ほとんどのタイプのレジャーエントリには`PreviousTxnID`フィールドと`PreviousTxnLgrSeq`フィールドがありますが、これは省略されます。 |
| `PreviousFields` | オブジェクト | このトランザクションの結果として変更されたオブジェクトのすべてのフィールドの以前の値。トランザクションがオブジェクトにフィールドを追加しただけの場合、このフィールドは空のオブジェクトです。 |
| `PreviousTxnID` | 文字列 - [ハッシュ][] | _(省略可能)_ このレジャーエントリを変更する前のトランザクションの[識別用ハッシュ][]。`PreviousTxnID`フィールドを持たないレジャーエントリの種類では省略されます。 |
| `PreviousTxnLgrSeq` | 数値 - [レジャーインデックス][] | _(省略可能)_ このレジャーエントリを変更する前のトランザクションを含むレジャーバージョンの[レジャーインデックス][]。`PreviousTxnLgrSeq`フィールドを持たないレジャーエントリの種類では省略されます。 |
**注記:** 変更されたレジャーエントリに`PreviousTxnID`フィールドと`PreviousTxnLgrSeq`フィールドがある場合、トランザクションは常にトランザクションの識別ハッシュとトランザクションを含むレジャーバージョンのインデックスでそれらを更新しますが、これらのフィールドの新しい値は`ModifiedNode`オブジェクトの`FinalFields`にはリストされず、以前の値はネストされた`PreviousFields`オブジェクトではなく `ModifiedNode` オブジェクトのトップレベルにリストされます。
## NFTのフィールド
NFTを含むトランザクション（`tx` と `account_tx`）はメタデータに以下のフィールドを含むことができます。これらの値はリクエスト時にサーバによって追加され、ハッシュ化されたバイナリメタデータには格納されません。
| フィールド | 値 | 説明 |
|:--------------------|:--------------------------|:---------------------------|
| `nftoken_id` | 文字列 | トランザクションの結果、レジャー上で変更された`NFToken`の`NFTokenID`を示します。トランザクションが`NFTokenMint`または`NFTokenAcceptOffer`の場合のみ表示されます。[NFTokenID](nftoken.html#nftokenid)をご覧ください。 |
| `nftoken_ids` | 配列 | トランザクションの結果、レジャー上で変更された`NFToken`のすべての`NFTokenID`を表示します。トランザクションが `NFTokenCancelOffer`の場合のみ表示されます。 |
| `offer_id` | 文字列 | `NFTokenCreateOffer`トランザクションからのレスポンスに、新しい`NFTokenOffer`の`OfferID`を表示します。 |
## delivered_amount
[Paymentトランザクション][]の`Amount`。`Destination`に送金された金額を示し、トランザクションが成功すると、**[Partial Payments](partial-payments.html)であった場合を除いて、** 宛先は当該の金額を受取ります（Partial Paymentsの場合、`Amount`を上限とする正の金額が受取られます）。`Amount`フィールドを信頼するかどうかを選択するのではなく、メタデータの`delivered_amount`フィールドを使用して、宛先に実際に到達する金額を確認してください。
[Paymentトランザクション][]によって`Destination`に実際送金された金額を表します。トランザクションが成功すると、**[Partial Payments](partial-payments.html)であった場合を除いて、** 宛先は当該の金額を受取ります（Partial Paymentsの場合、`Amount`を上限とする正の金額が受取られます）。`Amount`フィールドを信頼するかどうかを選択するのではなく、メタデータの`delivered_amount`フィールドを使用して、宛先に実際に到達する金額を確認してください。
トランザクションのメタデータの`delivered_amount`フィールドは、成功したすべてのPaymentトランザクションが保持しており、フォーマットは通常の通貨額と同様です。ただし、送金額は、以下の両方の条件に該当するトランザクションについては使用できません。
@@ -26,6 +89,8 @@ labels:
両方の条件に該当する場合、`delivered_amount`には、実際の金額ではなく文字列値`unavailable`が記述されます。この場合、トランザクションのメタデータにあるAffectedNodesを読み取ることが、実際に送金された金額を割り出せる唯一の手段になります。
**注記:** `delivered_amount`フィールドはリクエストに対してオンデマンドで生成され、トランザクションメタデータのバイナリフォーマットには含まれず、トランザクションメタデータの[ハッシュ](basic-data-types.html#ハッシュ)を計算する際にも使用されません。一方、`DeliveredAmount`フィールドは2014-01-20以降のpartial paymentトランザクションのバイナリフォーマットに _含まれます_ 。
関連項目: [Partial Payments](partial-payments.html)
<!--{# common link defs #}-->

20
content/@i18n/ja/references/protocol/transactions/transaction-results/tel-codes.md
View File

@@ -13,19 +13,23 @@ labels:
| コード | 説明 |
|:----------------------|:-----------------------------------------------------|
| `telBAD_DOMAIN` | トランザクションで指定されたドメイン値（[AccountSetトランザクション][]の`Domain`フィールドなど）は、レジャーに保管するには長すぎるために使用できません。 |
| `telBAD_DOMAIN` | トランザクションで指定されたドメイン値（[AccountSetトランザクション][]の`Domain`フィールドなど）は、レジャーに保管するには長すぎます。 |
| `telBAD_PATH_COUNT` | トランザクションに含まれているパスが多過ぎるため、ローカルサーバーが処理できません。 |
| `telBAD_PUBLIC_KEY` | トランザクションで指定された公開鍵値（[AccountSetトランザクション][]の`MessageKey`フィールドなど）は長すぎるために使用できません。 |
| `telBAD_PUBLIC_KEY` | トランザクションで指定された公開鍵値（[AccountSetトランザクション][]の`MessageKey`フィールドなど）の長すぎます。 |
| `telCAN_NOT_QUEUE` | このトランザクションは[オープンレジャーコスト](transaction-cost.html)を満たしていませんが、[キュー制限](transaction-queue.html#キューの制約事項)を満たしていなかったため、サーバーはこのトランザクションをキューに入れませんでした。たとえば、送信者のキューにすでに10個のトランザクションが入っている場合には、トランザクションからこのコードが返されます。後で再試行するか、`Fee`フィールドに高いコストを指定して代わりのトランザクションに署名して送信することができます。 |
| `telCAN_NOT_QUEUE_BALANCE` | トランザクションが[オープンレジャーコスト](transaction-cost.html)を満たしておらず、またすでにキューに入っているトランザクションの予測XRPコストの合計が、アカウントの予想残高よりも大きいために、このトランザクションはトランザクションキューに追加されませんでした。後で再試行するか、別のサーバーへの送信を試みることができます。[新規: rippled 0.70.2][] |
| `telCAN_NOT_QUEUE_BLOCKS` | トランザクションは[オープンレジャーコスト](transaction-cost.html)を満たしておらず、トランザクションキューにも追加されませんでした。このトランザクションはキュー内の既存のトランザクションを置き換えることができませんでした。これは、認証メソッドを変更することで、すでにキューに入っている同じ送信者からのトランザクションがブロックされる可能性があるためです。（これには[SetRegularKey][]トランザクションと[SignerListSet][]トランザクションのすべて、およびRequireAuth/OptionalAuth、DisableMaster、AccountTxnIDフラグを変更する[AccountSet][]トランザクションなどがあります。）後で再試行するか、別のサーバーへの送信を試みることができます。[新規: rippled 0.70.2][] |
| `telCAN_NOT_QUEUE_BLOCKED` | トランザクションが[オープンレジャーコスト](transaction-cost.html)を満たしておらず、トランザクションキューにも追加されませんでした。これは、このトランザクションの前にキューに入れられた同じ送信者のトランザクションによってブロックされるためです。（これには[SetRegularKey][]トランザクションと[SignerListSet][]トランザクションのすべて、およびRequireAuth/OptionalAuth、DisableMaster、AccountTxnIDフラグを変更する[AccountSet][]トランザクションなどがあります。）後で再試行するか、別のサーバーへの送信を試みることができます。[新規: rippled 0.70.2][] |
| `telCAN_NOT_QUEUE_FEE` | トランザクションは[オープンレジャーコスト](transaction-cost.html)を満たしておらず、トランザクションキューにも追加されませんでした。このコードは、送信者とシーケンス番号が同じトランザクションがすでにキューに入れられており、新しいトランザクションが、既存のトランザクションを置き換えるのに十分なトランザクションコストを支払わない場合に発生します。キュー内のトランザクションを置き換えるには、新しいトランザクションの`Fee`値に25%以上の上乗せ（[手数料レベル](transaction-cost.html#手数料レベル)で評価）が必要となります。`Fee`の値を大きくして再試行するか、大きな数字の`Sequence`番号でこのトランザクションを送信して既存のトランザクションを置き換えないようにするか、別のサーバーへ送信を試みることができます。[新規: rippled 0.70.2][] |
| `telCAN_NOT_QUEUE_FULL` | このトランザクションは[オープンレジャーコスト](transaction-cost.html)を満たしておらず、またこのサーバーのトランザクションキューが一杯であるため、サーバーはこのトランザクションをキューに入れませんでした。`Fee`の値を大きくして再試行するか、後で試してみるか、別のサーバーへの送信を試みることができます。新しいトランザクションのトランザクションコスト（[手数料レベル](transaction-cost.html#手数料レベル)で評価）は、キュー内でトランザクションコストが最も低いトランザクションよりも高くなければなりません。[新規: rippled 0.70.2][] |
| `telCAN_NOT_QUEUE_BALANCE` | トランザクションが[オープンレジャーコスト](transaction-cost.html)を満たしておらず、またすでにキューに入っているトランザクションの予測XRPコストの合計が、アカウントの予想残高よりも大きいために、このトランザクションはトランザクションキューに追加されませんでした。後で再試行するか、別のサーバーへの送信を試みることができます。 |
| `telCAN_NOT_QUEUE_BLOCKS` | トランザクションは[オープンレジャーコスト](transaction-cost.html)を満たしておらず、トランザクションキューにも追加されませんでした。このトランザクションはキュー内の既存のトランザクションを置き換えることができませんでした。これは、認証メソッドを変更することで、すでにキューに入っている同じ送信者からのトランザクションがブロックされる可能性があるためです。（これには[SetRegularKey][]トランザクションと[SignerListSet][]トランザクションのすべて、およびRequireAuth/OptionalAuth、DisableMaster、AccountTxnIDフラグを変更する[AccountSet][]トランザクションなどがあります。）後で再試行するか、別のサーバーへの送信を試みることができます。 |
| `telCAN_NOT_QUEUE_BLOCKED` | トランザクションが[オープンレジャーコスト](transaction-cost.html)を満たしておらず、トランザクションキューにも追加されませんでした。これは、このトランザクションの前にキューに入れられた同じ送信者のトランザクションによってブロックされるためです。（これには[SetRegularKey][]トランザクションと[SignerListSet][]トランザクションのすべて、およびRequireAuth/OptionalAuth、DisableMaster、AccountTxnIDフラグを変更する[AccountSet][]トランザクションなどがあります。）後で再試行するか、別のサーバーへの送信を試みることができます。 |
| `telCAN_NOT_QUEUE_FEE` | トランザクションは[オープンレジャーコスト](transaction-cost.html)を満たしておらず、トランザクションキューにも追加されませんでした。このコードは、送信者とシーケンス番号が同じトランザクションがすでにキューに入れられており、新しいトランザクションが、既存のトランザクションを置き換えるのに十分なトランザクションコストを支払わない場合に発生します。キュー内のトランザクションを置き換えるには、新しいトランザクションの`Fee`値に25%以上の上乗せ（[手数料レベル](transaction-cost.html#手数料レベル)で評価）が必要となります。`Fee`の値を大きくして再試行するか、大きな数字の`Sequence`番号でこのトランザクションを送信して既存のトランザクションを置き換えないようにするか、別のサーバーへ送信を試みることができます。 |
| `telCAN_NOT_QUEUE_FULL` | このトランザクションは[オープンレジャーコスト](transaction-cost.html)を満たしておらず、またこのサーバーのトランザクションキューが一杯であるため、サーバーはこのトランザクションをキューに入れませんでした。`Fee`の値を大きくして再試行するか、後で試してみるか、別のサーバーへの送信を試みることができます。新しいトランザクションのトランザクションコスト（[手数料レベル](transaction-cost.html#手数料レベル)で評価）は、キュー内でトランザクションコストが最も低いトランザクションよりも高くなければなりません。 |
| `telFAILED_PROCESSING` | トランザクションの処理中に不明なエラーが発生しました。 |
| `telINSUF_FEE_P` | トランザクションの`Fee`が、サーバーの負荷レベルに基づいて定められるサーバーの現在の[トランザクションコスト](transaction-cost.html)要件を満たすのに十分な値ではありあません。 |
| `telLOCAL_ERROR` | 不明なローカルエラー。 |
| `telNO_DST`_`PARTIAL` | トランザクションは、新しいアカウントに資金を供給するXRPの支払ですが、[tfPartialPaymentフラグ](partial-payments.html)が有効になっていました。これは許可されていません。 |
| `telNETWORK_ID_MAKES_TX_NON_CANONICAL` | トランザクションは[`NetworkID`フィールド](transaction-common-fields.html#networkidフィールド)を指定していますが、現在のネットワークルールでは`NetworkID`フィールドは指定しないことになっています。(メインネットやその他のチェーンIDが1024以下のネットワークではこのフィールドは使用されません)。もしトランザクションが`NetworkID`を使用しないネットワーク向けであった場合、そのフィールドを削除して再試行してください。トランザクションが別のネットワーク向けだった場合は、正しいネットワークに接続されているサーバに送信してください。 [新規: rippled 1.11.0][] |
| `telNO_DST`_`PARTIAL` | トランザクションは、新しいアカウントに資金を供給するためのXRPによる支払いですが、[tfPartialPaymentフラグ](partial-payments.html)が有効になっていました。これは許可されていません。 |
| `telREQUIRES_NETWORK_ID` | トランザクションは[`NetworkID`フィールド](transaction-common-fields.html#networkidフィールド)を指定していません。トランザクションが`NetworkID`を必要とするネットワーク向けであった場合、フィールドを追加して再試行してください。トランザクションが別のネットワーク向けであった場合、正しいネットワークに接続されているサーバに送信してください。[新規: rippled 1.11.0][] |
| `telWRONG_NETWORK` | トランザクションが現在のネットワークに対して間違った [`NetworkID` 値](transaction-common-fields.html#networkidフィールド) を指定しています。目的のネットワークに対して正しい `NetworkID`値を指定するか、正しいネットワークに接続されているサーバーにトランザクションを送信してください。[新規: rippled 1.11.0][] |
<!--{# common link defs #}-->
{% include '_snippets/rippled-api-links.md' %}

2
content/@i18n/ja/references/protocol/transactions/types/ammcreate.md
View File

@@ -44,7 +44,7 @@ AMMを表す[AMMエントリ][]と[特殊なAccountRootエントリ](accountroot
| `Amount2` | [通貨額][] | Amount | はい | このAMMの最初の資金となる2つの資産のうち、2つ目の資産です。これは正数である必要があります。 |
| `TradingFee` | 数値 | UInt16 | はい | このAMMインスタンスに対する取引に課される手数料を1/100,000単位で指定します（値1は0.001%に相当）。最大値は`1000`で、1%の手数料を意味します。最小値は `0`です。 |
`Amount`と`Amount2`の一方または両方は[トークン](tokens.html)であり、最大でどちらか一方を[XRP](xrp.html)にすることが可能です。通貨コードと発行者が同じものは使用できません。AMMのLPトークンは、別のAMMの資産の1つとして使用することができます。トークンの発行者は[Default Ripple](rippling.html#defaultrippleフラグ)を有効にしていなければなりません。[Clawback Amendment][] :not_enabled: が有効になっている場合、それらの発行者はAllow Clawbackフラグを有効にしていてはいけません。AMMのLPトークンは、別のAMMの資産の一つとして使用することができます。
`Amount`と`Amount2`の一方または両方は[トークン](tokens.html)であり、最大でどちらか一方を[XRP](xrp.html)にすることが可能です。通貨コードと発行者が同じものは使用できません。AMMのLPトークンは、別のAMMの資産の1つとして使用することができます。トークンの発行者は[Default Ripple](rippling.html#defaultrippleフラグ)を有効にしていなければなりません。[Clawback Amendment][] :not_enabled: が有効になっている場合、それらの発行者はAllow Clawbackフラグを有効にしていてはいけません。AMMのLPトークンは、別のAMMの資産の一つとして使用することはできません。
## 特殊なトランザクションコスト

6
content/@i18n/ja/references/protocol/transactions/types/offercreate.md
View File

@@ -47,9 +47,9 @@ OfferCreate型のトランザクションについては、[`Flags`フィール
| フラグ名 | 16進数 | 10進数 | 説明 |
|:----------------------|:-------------|:--------------|:-------------------|
| `tfPassive` | `0x00010000` | 65536 | 有効な場合、オファーはオファーが完全に一致するオファーを消費せず、代わりにレジャーのOfferオブジェクトになります。それはまだクロスしたオファーを消費します。 |
| `tfImmediateOrCancel` | `0x00020000` | 131072 | オファーを[IOC注文](http://en.wikipedia.org/wiki/Immediate_or_cancel)として扱います。有効な場合、オファーはレジャーオブジェクトにはなりません。レジャー内の既存のオファーと一致させようとするだけです。即時にオファーがどのオファーとも一致しない場合、どの通貨とも取引せずに「正常に」実行します。この場合、トランザクションは`tesSUCCESS`の[結果コード](transaction-results.html)を返しますが、レジャー内には、[Offerオブジェクト](offer.html)を作成しません。 |
| `tfFillOrKill` | `0x00040000` | 262144 | オファーを[FOK注文](http://en.wikipedia.org/wiki/Fill_or_kill)として扱います。レジャー内の既存のオファーのみを一致私用とします。またこれは、全`TakerPays`の数量が取得できる場合に限られます。[fix1578 amendment][]が有効な場合でオファーを配置した時に実行できない場合、トランザクションは`tecKILLED`の[結果コード](transaction-results.html)を返します。そうでない場合は、トランザクションは、どの通貨とも取り引きせずにキャンセルされた場合でも`tesSUCCESS`の結果コードを返します。 |
| `tfPassive` | `0x00010000` | 65536 | 有効な場合、オファーはオファーが完全に約定するオファーを消費せず、代わりにレジャーのOfferオブジェクトになります。それはまだクロスしたオファーを消費します。 |
| `tfImmediateOrCancel` | `0x00020000` | 131072 | オファーを[IOC注文](http://en.wikipedia.org/wiki/Immediate_or_cancel)として扱います。有効な場合、オファーはレジャーオブジェクトにはなりません。レジャー内の既存のオファーと約定させようとするだけです。即時にオファーがどのオファーとも約定しない場合、どの通貨とも取引せずに「正常に」実行します。この場合、トランザクションは`tesSUCCESS`の[結果コード](transaction-results.html)を返しますが、レジャー内には、[Offerオブジェクト](offer.html)を作成しません。 |
| `tfFillOrKill` | `0x00040000` | 262144 | オファーを[FOK注文](http://en.wikipedia.org/wiki/Fill_or_kill)として扱います。レジャー内の既存のオファーのみを約定しようとします。またこれは、全`TakerPays`の数量が取得できる場合に限られます。[fix1578 amendment][]が有効な場合でオファーを配置した時に実行できない場合、トランザクションは`tecKILLED`の[結果コード](transaction-results.html)を返します。そうでない場合は、トランザクションは、どの通貨とも取り引きせずにキャンセルされた場合でも`tesSUCCESS`の結果コードを返します。 |
| `tfSell` | `0x00080000` | 524288 | 取引所で`TakerPays`Amountよりも多く取得することになっても、`TakerGets` Amountを交換します。 |
## エラーケース