2020年4月3日公開 – テキスト版

TOML v1.0.0-rc.1

トムの明白で最小限の言語。

トム・プレストン-ワーナー、プラディウン・ゲダムら著

目的

TOMLは、明白なセマンティクスにより読みやすい、最小限の設定ファイル形式を目指しています。TOMLは、ハッシュテーブルに明確にマッピングされるように設計されています。TOMLは、さまざまな言語のデータ構造に簡単に解析できるはずです。

例

# This is a TOML document.

title = "TOML Example"

[owner]
name = "Tom Preston-Werner"
dob = 1979-05-27T07:32:00-08:00 # First class dates

[database]
server = "192.168.1.1"
ports = [ 8001, 8001, 8002 ]
connection_max = 5000
enabled = true

[servers]

  # Indentation (tabs and/or spaces) is allowed but not required
  [servers.alpha]
  ip = "10.0.0.1"
  dc = "eqdc10"

  [servers.beta]
  ip = "10.0.0.2"
  dc = "eqdc10"

[clients]
data = [ ["gamma", "delta"], [1, 2] ]

# Line breaks are OK when inside arrays
hosts = [
  "alpha",
  "omega"
]

仕様

• TOMLは大文字と小文字を区別します。
• TOMLファイルは、有効なUTF-8エンコードされたUnicodeドキュメントである必要があります。
• 空白とは、タブ(0x09)またはスペース(0x20)を意味します。
• 改行とは、LF (0x0A) または CRLF (0x0D 0x0A) を意味します。

コメント

ハッシュ記号は、文字列内部を除き、行の残りの部分をコメントとしてマークします。

# This is a full-line comment
key = "value"  # This is a comment at the end of a line
another = "# This is not a comment"

タブ以外の制御文字（U+0000～U+0008、U+000A～U+001F、U+007F）はコメント内では許可されません。

キー/値ペア

TOMLドキュメントの主要な構成要素は、キー/値ペアです。

キーは等号の左側にあり、値は右側にあります。キー名と値の周囲の空白は無視されます。キー、等号、および値は同じ行にある必要があります（ただし、一部の値は複数行に分割できます）。

key = "value"

値は、次のいずれかの型である必要があります。

• 文字列
• 整数
• 浮動小数点数
• 真偽値
• オフセット付き日時
• ローカル日時
• ローカル日付
• ローカル時間
• 配列
• インラインテーブル

未指定の値は無効です。

key = # INVALID

キー/値ペアの後には改行が必要です。（例外については、インラインテーブルを参照してください。）

first = "Tom" last = "Preston-Werner" # INVALID

キー

キーは、ベア、引用符付き、またはドット付きのいずれかになります。

ベアキーには、ASCII文字、ASCII数字、アンダースコア、およびダッシュ（A-Za-z0-9_-）のみを含めることができます。ベアキーはASCII数字のみで構成することもできます（例：1234）が、常に文字列として解釈されることに注意してください。

key = "value"
bare_key = "value"
bare-key = "value"
1234 = "value"

引用符付きキーは、基本文字列またはリテラル文字列とまったく同じルールに従い、より広範なキー名を使用できます。絶対に必要な場合を除き、ベアキーを使用するのがベストプラクティスです。

"127.0.0.1" = "value"
"character encoding" = "value"
"ʎǝʞ" = "value"
'key2' = "value"
'quoted "value"' = "value"

ベアキーは空であってはなりませんが、空の引用符付きキーは許可されています（推奨されませんが）。

= "no key name"  # INVALID
"" = "blank"     # VALID but discouraged
'' = 'blank'     # VALID but discouraged

ドット付きキーは、ドットで結合されたベアまたは引用符付きキーのシーケンスです。これにより、同様のプロパティをまとめてグループ化できます。

name = "Orange"
physical.color = "orange"
physical.shape = "round"
site."google.com" = true

JSONの世界では、それは次の構造を提供します

{
  "name": "Orange",
  "physical": {
    "color": "orange",
    "shape": "round"
  },
  "site": {
    "google.com": true
  }
}

ドットで区切られた部分の周りの空白は無視されますが、余分な空白は使用しないのがベストプラクティスです。

キーを複数回定義することは無効です。

# DO NOT DO THIS
name = "Tom"
name = "Pradyun"

ベアキーはASCII整数のみで構成できるため、浮動小数点数のように見えるが2つの部分からなるドット付きキーを記述できます。そうする正当な理由がない限り、これを行わないでください（おそらくそうではないでしょう）。

3.14159 = "pi"

上記のTOMLは、次のJSONにマッピングされます。

{ "3": { "14159": "pi" } }

キーが直接定義されていない限り、そのキーとその中の名前に書き込むことができます。

# This makes the key "fruit" into a table.
fruit.apple.smooth = true

# So then you can add to the table "fruit" like so:
fruit.orange = 2

# THE FOLLOWING IS INVALID

# This defines the value of fruit.apple to be an integer.
fruit.apple = 1

# But then this treats fruit.apple like it's a table.
# You can't turn an integer into a table.
fruit.apple.smooth = true

ドット付きキーを順序を無視して定義することは推奨されません。

# VALID BUT DISCOURAGED

apple.type = "fruit"
orange.type = "fruit"

apple.skin = "thin"
orange.skin = "thick"

apple.color = "red"
orange.color = "orange"

# RECOMMENDED

apple.type = "fruit"
apple.skin = "thin"
apple.color = "red"

orange.type = "fruit"
orange.skin = "thick"
orange.color = "orange"

文字列

文字列を表現する方法は4つあります。基本、複数行基本、リテラル、および複数行リテラルです。すべての文字列には、有効なUTF-8文字のみが含まれている必要があります。

基本文字列は、引用符で囲まれています。引用符、バックスラッシュ、およびタブ以外の制御文字（U+0000～U+0008、U+000A～U+001F、U+007F）を除き、任意のUnicode文字を使用できます。これらはエスケープする必要があります。

str = "I'm a string. \"You can quote me\". Name\tJos\u00E9\nLocation\tSF."

利便性のために、一部の一般的な文字にはコンパクトなエスケープシーケンスがあります。

\b         - backspace       (U+0008)
\t         - tab             (U+0009)
\n         - linefeed        (U+000A)
\f         - form feed       (U+000C)
\r         - carriage return (U+000D)
\"         - quote           (U+0022)
\\         - backslash       (U+005C)
\uXXXX     - unicode         (U+XXXX)
\UXXXXXXXX - unicode         (U+XXXXXXXX)

任意のUnicode文字は、\uXXXXまたは\UXXXXXXXX形式でエスケープできます。エスケープコードは、有効なUnicodeスカラ値である必要があります。

上記にリストされていない他のすべてのエスケープシーケンスは予約されており、使用した場合、TOMLはエラーを生成する必要があります。

テキストのパッセージを表現したり（例：翻訳ファイル）、非常に長い文字列を複数行に分割したい場合があります。TOMLでは、これが簡単に行えます。

複数行の基本文字列は、両側に3つの引用符で囲まれ、改行を許可します。開始デリミターの直後の改行はトリムされます。その他の空白と改行文字はすべてそのまま残ります。

str1 = """
Roses are red
Violets are blue"""

TOMLパーサーは、プラットフォームにとって意味のあるものに改行を正規化することができます。

# On a Unix system, the above multi-line string will most likely be the same as:
str2 = "Roses are red\nViolets are blue"

# On a Windows system, it will most likely be equivalent to:
str3 = "Roses are red\r\nViolets are blue"

余分な空白を導入せずに長い文字列を記述するには、「行末バックスラッシュ」を使用します。行の最後の空白以外の文字が\の場合、次の空白以外の文字または終了デリミターまでのすべての空白（改行を含む）とともにトリムされます。基本文字列で有効なすべてのエスケープシーケンスは、複数行の基本文字列でも有効です。

# The following strings are byte-for-byte equivalent:
str1 = "The quick brown fox jumps over the lazy dog."

str2 = """
The quick brown \


  fox jumps over \
    the lazy dog."""

str3 = """\
       The quick brown \
       fox jumps over \
       the lazy dog.\
       """

バックスラッシュと、タブ、改行、およびキャリッジリターン以外の制御文字（U+0000～U+0008、U+000B、U+000C、U+000E～U+001F、U+007F）を除き、任意のUnicode文字を使用できます。これらはエスケープする必要があります。

複数行の基本文字列の内側の任意の場所に、引用符、または隣接する2つの引用符を記述できます。これらは、デリミターのすぐ内側にも記述できます。

str4 = """Here are two quotation marks: "". Simple enough."""
# str5 = """Here are three quotation marks: """."""  # INVALID
str5 = """Here are three quotation marks: ""\"."""
str6 = """Here are fifteen quotation marks: ""\"""\"""\"""\"""\"."""

# "This," she said, "is just a pointless statement."
str7 = """"This," she said, "is just a pointless statement.""""

Windowsパスや正規表現を頻繁に指定する場合、バックスラッシュをエスケープする必要があるため、すぐに面倒になりやすく、エラーが発生しやすくなります。これを支援するために、TOMLはエスケープをまったく許可しないリテラル文字列をサポートしています。

リテラル文字列は、単一引用符で囲まれています。基本文字列と同様に、1行に記述する必要があります。

# What you see is what you get.
winpath  = 'C:\Users\nodejs\templates'
winpath2 = '\\ServerX\admin$\system32\'
quoted   = 'Tom "Dubs" Preston-Werner'
regex    = '<\i\c*\s*>'

エスケープがないため、単一引用符で囲まれたリテラル文字列の内部に単一引用符を記述する方法はありません。幸い、TOMLはこの問題を解決するリテラル文字列の複数行バージョンをサポートしています。

複数行のリテラル文字列は、両側に3つの単一引用符で囲まれ、改行を許可します。リテラル文字列と同様に、エスケープは一切ありません。開始デリミターの直後の改行はトリムされます。デリミター間の他のすべてのコンテンツは、変更なしにそのまま解釈されます。

regex2 = '''I [dw]on't need \d{2} apples'''
lines  = '''
The first newline is
trimmed in raw strings.
   All other whitespace
   is preserved.
'''

複数行のリテラル文字列内には、1つまたは2つの単一引用符を任意に記述できますが、3つ以上の単一引用符のシーケンスは許可されていません。

quot15 = '''Here are fifteen quotation marks: """""""""""""""'''

# apos15 = '''Here are fifteen apostrophes: ''''''''''''''''''  # INVALID
apos15 = "Here are fifteen apostrophes: '''''''''''''''"

# 'That's still pointless', she said.
str = ''''That's still pointless', she said.'''

タブ以外の制御文字は、リテラル文字列では許可されていません。したがって、バイナリデータには、Base64または他の適切なASCIIまたはUTF-8エンコーディングを使用することをお勧めします。そのエンコーディングの処理はアプリケーション固有になります。

整数

整数は整数です。正の数はプラス記号を接頭辞として付けることができます。負の数はマイナス記号を接頭辞として付けます。

int1 = +99
int2 = 42
int3 = 0
int4 = -17

大きな数値の場合、読みやすくするために、数字の間にアンダースコアを使用できます。各アンダースコアは、両側に少なくとも1つの数字で囲む必要があります。

int5 = 1_000
int6 = 5_349_221
int7 = 1_2_3_4_5     # VALID but discouraged

先頭のゼロは許可されていません。整数値-0と+0は有効であり、接頭辞のないゼロと同じです。

負でない整数値は、16進数、8進数、または2進数で表現することもできます。これらの形式では、先頭の+は許可されず、先頭のゼロは許可されます（プレフィックスの後）。16進数の値は大文字と小文字を区別しません。アンダースコアは数字の間で許可されています（ただし、プレフィックスと値の間ではありません）。

# hexadecimal with prefix `0x`
hex1 = 0xDEADBEEF
hex2 = 0xdeadbeef
hex3 = 0xdead_beef

# octal with prefix `0o`
oct1 = 0o01234567
oct2 = 0o755 # useful for Unix file permissions

# binary with prefix `0b`
bin1 = 0b11010110

64ビット（符号付きロング）範囲が想定されます（−9,223,372,036,854,775,808～9,223,372,036,854,775,807）。

浮動小数点数

浮動小数点数は、IEEE 754 binary64値として実装する必要があります。

浮動小数点数は、整数部分（10進整数値と同じルールに従います）と、それに続く小数部分または指数部分（あるいはその両方）で構成されます。小数部分と指数部分の両方が存在する場合は、小数部分が指数部分より前にある必要があります。

# fractional
flt1 = +1.0
flt2 = 3.1415
flt3 = -0.01

# exponent
flt4 = 5e+22
flt5 = 1e06
flt6 = -2E-2

# both
flt7 = 6.626e-34

小数部分は、小数点とそれに続く1つ以上の数字です。

指数部分は、E（大文字または小文字）と、それに続く整数部分（10進整数値と同じルールに従いますが、先頭のゼロを含めることができます）です。

整数と同様に、読みやすくするためにアンダースコアを使用できます。各アンダースコアは、少なくとも1つの数字で囲む必要があります。

flt8 = 224_617.445_991_228

浮動小数点数値-0.0と+0.0は有効であり、IEEE 754に従ってマッピングする必要があります。

特別な浮動小数点数値を表現することもできます。常に小文字です。

# infinity
sf1 = inf  # positive infinity
sf2 = +inf # positive infinity
sf3 = -inf # negative infinity

# not a number
sf4 = nan  # actual sNaN/qNaN encoding is implementation specific
sf5 = +nan # same as `nan`
sf6 = -nan # valid, actual encoding is implementation specific

真偽値

真偽値は、使い慣れているトークンです。常に小文字です。

bool1 = true
bool2 = false

オフセット付き日時

特定の時点を明確に表現するには、RFC 3339形式のオフセット付き日時を使用できます。

odt1 = 1979-05-27T07:32:00Z
odt2 = 1979-05-27T00:32:00-07:00
odt3 = 1979-05-27T00:32:00.999999-07:00

読みやすくするために、日付と時刻の間のTデリミターをスペースに置き換えることができます（RFC 3339セクション5.6で許可されています）。

odt4 = 1979-05-27 07:32:00Z

小数秒の精度は実装固有ですが、少なくともミリ秒の精度が期待されます。値に実装がサポートできる以上の精度が含まれている場合は、追加の精度は丸められるのではなく、切り捨てられる必要があります。

ローカル日時

RFC 3339形式の日時からオフセットを省略した場合、オフセットまたはタイムゾーンに関係なく、指定された日時を表します。追加情報がないと、特定の時点に変換することはできません。必要な場合の特定時点への変換は、実装固有です。

ldt1 = 1979-05-27T07:32:00
ldt2 = 1979-05-27T00:32:00.999999

小数秒の精度は実装固有ですが、少なくともミリ秒の精度が期待されます。値に実装がサポートできる以上の精度が含まれている場合は、追加の精度は丸められるのではなく、切り捨てられる必要があります。

ローカル日付

RFC 3339形式の日時の日付部分のみを含めると、オフセットまたはタイムゾーンに関係なく、その日全体を表します。

ld1 = 1979-05-27

ローカル時間

RFC 3339形式の日時の時間部分のみを含めると、特定の日、オフセット、タイムゾーンに関係なく、その日の時刻を表します。

lt1 = 07:32:00
lt2 = 00:32:00.999999

小数秒の精度は実装固有ですが、少なくともミリ秒の精度が期待されます。値に実装がサポートできる以上の精度が含まれている場合は、追加の精度は丸められるのではなく、切り捨てられる必要があります。

配列

配列は、内部に値を持つ角かっこです。空白は無視されます。要素はコンマで区切られています。配列には、キー/値ペアで許可されているのと同じデータ型の値を含めることができます。異なる型の値を混在させることができます。

integers = [ 1, 2, 3 ]
colors = [ "red", "yellow", "green" ]
nested_array_of_int = [ [ 1, 2 ], [3, 4, 5] ]
nested_mixed_array = [ [ 1, 2 ], ["a", "b", "c"] ]
string_array = [ "all", 'strings', """are the same""", '''type''' ]

# Mixed-type arrays are allowed
numbers = [ 0.1, 0.2, 0.5, 1, 2, 5 ]
contributors = [
  "Foo Bar <foo@example.com>",
  { name = "Baz Qux", email = "bazqux@example.com", url = "https://example.com/bazqux" }
]

配列は複数行にまたがることができます。配列の最後の値の後に終端コンマ（末尾コンマとも呼ばれる）があってもかまいません。値の前と閉じ括弧の前に、任意の数の改行とコメントを含めることができます。

integers2 = [
  1, 2, 3
]

integers3 = [
  1,
  2, # this is ok
]

テーブル

テーブル（ハッシュテーブルまたは辞書とも呼ばれる）は、キー/値ペアのコレクションです。それらは、それ自体で1行の角かっこで表示されます。テーブルは、配列が値にしかならないため、配列とは区別できます。

[table]

それ以降、次のテーブルまたはEOFまでがそのテーブルのキー/値です。テーブル内のキー/値のペアは特定の順序であることは保証されていません。

[table-1]
key1 = "some string"
key2 = 123

[table-2]
key1 = "another string"
key2 = 456

テーブルの命名規則は、キーと同じです（上記のキーの定義を参照）。

[dog."tater.man"]
type.name = "pug"

JSONの世界では、それは次の構造を提供します

{ "dog": { "tater.man": { "type": { "name": "pug" } } } }

キーの周りの空白は無視されますが、余分な空白を使用しないことが推奨されます。

[a.b.c]            # this is best practice
[ d.e.f ]          # same as [d.e.f]
[ g .  h  . i ]    # same as [g.h.i]
[ j . "ʞ" . 'l' ]  # same as [j."ʞ".'l']

必要がない場合は、すべてのスーパテーブルを指定する必要はありません。TOMLは自動的に処理します。

# [x] you
# [x.y] don't
# [x.y.z] need these
[x.y.z.w] # for this to work

[x] # defining a super-table afterwards is ok

空のテーブルは許可されており、キー/値のペアが含まれていないだけです。

キーと同様に、同じテーブルを複数回定義することはできません。そうすると無効になります。

# DO NOT DO THIS

[fruit]
apple = "red"

[fruit]
orange = "orange"

# DO NOT DO THIS EITHER

[fruit]
apple = "red"

[fruit.apple]
texture = "smooth"

テーブルを順序外に定義することは推奨されません。

# VALID BUT DISCOURAGED
[fruit.apple]
[animal]
[fruit.orange]

# RECOMMENDED
[fruit.apple]
[fruit.orange]
[animal]

ドット付きキーは、各ドットの左側にあるすべてをテーブルとして定義します。テーブルは複数回定義できないため、[table]ヘッダーを使用してそのようなテーブルを再定義することは許可されていません。同様に、ドット付きキーを使用して、[table]形式ですでに定義されているテーブルを再定義することは許可されていません。

ただし、[table]形式を使用して、ドット付きキーで定義されたテーブル内のサブテーブルを定義できます。

[fruit]
apple.color = "red"
apple.taste.sweet = true

# [fruit.apple]  # INVALID
# [fruit.apple.taste]  # INVALID

[fruit.apple.texture]  # you can add sub-tables
smooth = true

インラインテーブル

インラインテーブルは、テーブルを表現するためのよりコンパクトな構文を提供します。特に、冗長になりがちなグループ化されたデータに役立ちます。インラインテーブルは中括弧{と}で囲まれています。中括弧内には、ゼロ個以上のコンマ区切りのキー/値ペアが表示される場合があります。キー/値ペアは、標準テーブルのキー/値ペアと同じ形式になります。インラインテーブルを含む、すべての値タイプが許可されています。

インラインテーブルは、1行に表示することを目的としています。インラインテーブルの最後のキー/値ペアの後には、終端のコンマ（後続のコンマとも呼ばれます）は許可されません。値内で有効な場合を除き、中括弧の間に改行は許可されません。それでも、インラインテーブルを複数行に分割することは強く推奨されません。この欲求に駆られていると感じた場合は、標準テーブルを使用する必要があることを意味します。

name = { first = "Tom", last = "Preston-Werner" }
point = { x = 1, y = 2 }
animal = { type.name = "pug" }

上記のインラインテーブルは、次の標準テーブル定義と同じです。

[name]
first = "Tom"
last = "Preston-Werner"

[point]
x = 1
y = 2

[animal]
type.name = "pug"

インラインテーブルは、その中のキーとサブテーブルを完全に定義します。新しいキーとサブテーブルをそれらに追加することはできません。

[product]
type = { name = "Nail" }
# type.edible = false  # INVALID

同様に、インラインテーブルを使用して、すでに定義されているテーブルにキーまたはサブテーブルを追加することはできません。

[product]
type.name = "Nail"
# type = { edible = false }  # INVALID

テーブルの配列

まだ表現されていない最後のタイプは、テーブルの配列です。これらは、二重角かっこで囲まれたテーブル名を使用することで表現できます。それ以降、次のテーブルまたはEOFまでがそのテーブルのキー/値です。同じ二重角かっこで囲まれた名前を持つ各テーブルは、テーブルの配列の要素になります。テーブルは、検出された順序で挿入されます。キー/値のペアがない二重角かっこで囲まれたテーブルは、空のテーブルと見なされます。

[[products]]
name = "Hammer"
sku = 738594937

[[products]]

[[products]]
name = "Nail"
sku = 284758393

color = "gray"

JSONの世界では、次の構造になります。

{
  "products": [
    { "name": "Hammer", "sku": 738594937 },
    { },
    { "name": "Nail", "sku": 284758393, "color": "gray" }
  ]
}

テーブルのネストされた配列も作成できます。サブテーブルで同じ二重かっこ構文を使用するだけです。二重かっこで囲まれた各サブテーブルは、最後に定義されたテーブル要素に属します。同様に、通常のサブテーブル（配列ではない）も、最後に定義されたテーブル要素に属します。

[[fruit]]
  name = "apple"

  [fruit.physical]  # subtable
    color = "red"
    shape = "round"

  [[fruit.variety]]  # nested array of tables
    name = "red delicious"

  [[fruit.variety]]
    name = "granny smith"

[[fruit]]
  name = "banana"

  [[fruit.variety]]
    name = "plantain"

上記のTOMLは、次のJSONにマッピングされます。

{
  "fruit": [
    {
      "name": "apple",
      "physical": {
        "color": "red",
        "shape": "round"
      },
      "variety": [
        { "name": "red delicious" },
        { "name": "granny smith" }
      ]
    },
    {
      "name": "banana",
      "variety": [
        { "name": "plantain" }
      ]
    }
  ]
}

テーブルまたはテーブル配列の親が配列要素である場合、子を定義する前にその要素を定義しておく必要があります。その順序を逆にする試みは、パース時にエラーを生成する必要があります。

# INVALID TOML DOC
[fruit.physical]  # subtable, but to which parent element should it belong?
  color = "red"
  shape = "round"

[[fruit]]  # parser must throw an error upon discovering that "fruit" is
           # an array rather than a table
  name = "apple"

配列が空であるか、互換性のある型であっても、静的に定義された配列に追加を試みると、パース時にエラーが発生する必要があります。

# INVALID TOML DOC
fruit = []

[[fruit]] # Not allowed

すでに確立された配列と同じ名前で通常のテーブルを定義しようとすると、パース時にエラーが発生する必要があります。同様に、通常のテーブルを配列として再定義しようとすると、パース時エラーが発生する必要があります。

# INVALID TOML DOC
[[fruit]]
  name = "apple"

  [[fruit.variety]]
    name = "red delicious"

  # INVALID: This table conflicts with the previous array of tables
  [fruit.variety]
    name = "granny smith"

  [fruit.physical]
    color = "red"
    shape = "round"

  # INVALID: This array of tables conflicts with the previous table
  [[fruit.physical]]
    color = "green"

必要に応じて、インラインテーブルを使用することもできます。

points = [ { x = 1, y = 2, z = 3 },
           { x = 7, y = 8, z = 9 },
           { x = 2, y = 4, z = 8 } ]

ファイル拡張子

TOMLファイルは拡張子.tomlを使用する必要があります。

MIMEタイプ

インターネット経由でTOMLファイルを転送する場合、適切なMIMEタイプはapplication/tomlです。

他のフォーマットとの比較

TOMLは、YAMLやJSONなど、アプリケーション構成やデータシリアル化に使用される他のファイル形式と特性を共有しています。TOMLとJSONはどちらもシンプルで、ユビキタスなデータ型を使用しているため、マシンでコード化または解析するのが簡単です。TOMLとYAMLはどちらも、特定の行の目的を理解しやすくするコメントなど、人間が読みやすい機能を重視しています。TOMLは、これらを組み合わせて、コメントを許可しながら（JSONとは異なり）、シンプルさ（YAMLとは異なり）を維持するという点で異なります。

TOMLは構成ファイル形式として明示的に意図されているため、解析は簡単ですが、任意のデータ構造をシリアル化するためのものではありません。TOMLには常にファイルの最上位にハッシュテーブルがあり、そのキー内にデータを簡単にネストできますが、最上位の配列や浮動小数点数を許可しないため、一部のデータを直接シリアル化することはできません。また、TOMLファイルの開始または終了を識別する標準もないため、ストリームを介して送信するのが複雑になる可能性があります。これらの詳細は、アプリケーションレイヤーでネゴシエートする必要があります。

INIファイルは、構文が類似しており、構成ファイルとして使用される点で、TOMLと頻繁に比較されます。ただし、INIの標準化された形式はなく、1つまたは2つ以上のレベルのネストを適切に処理しません。

さらに読む

• YAML仕様：https://yaml.org/spec/1.2/spec.html
• JSON仕様：https://tools.ietf.org/html/rfc8259
• INIファイルに関するWikipedia：https://en.wikipedia.org/wiki/INI_file

参加する

ドキュメント、バグレポート、プルリクエスト、およびその他すべての貢献を歓迎します！

Wiki

以下をカタログ化した公式TOML Wikiがあります。

• TOMLを使用しているプロジェクト
• 実装
• バリデーター
• TOMLデコーダーおよびエンコーダー用の言語に依存しないテストスイート
• エディターサポート
• エンコーダー
• コンバーター

リストを表示または追加したい場合は、ぜひご覧ください。TOMLコミュニティに参加していただきありがとうございます！