Язык разметки TOML стремится быть минимальным форматом файла конфигурации, который легко читается благодаря очевидной семантике. TOML предназначен для однозначного сопоставления с хеш-таблицей. TOML должен легко преобразовываться в структуры данных на самых разных языках программирования.
Файлы TOML должны использовать расширение .toml. При передаче файлов TOML через Интернет соответствующим типом MIME является application/toml.
Особенности:
Символ решетки # помечает оставшуюся часть строки как комментарий, за исключением случаев, когда он находится внутри строки.
# Это комментарий во всю строку key = "value" # Это комментарий в конце строки another = "# This is not a comment"
Управляющие символы, кроме табуляции (от U+0000 до U+0008, от U+000A до U+001F, от U+007F), не допускаются в комментариях.
key/value документа TOML.Основным строительным блоком документа TOML является пара key/value.
Ключи находятся слева от знака равенства, а значения - справа. Пробелы вокруг имен ключей и значений игнорируются. Ключ, знак равенства и значение должны находиться в одной строке (хотя некоторые значения могут быть разбиты на несколько строк).
key = "value"
Неуказанные значения недействительны.
key = # INVALID
После пары ключ/значение должен быть символ новой строки (или EOF). Исключения смотрите во встроенной таблице.
key документа TOML.Ключ может быть "голыми" (не заключен в кавычки) или заключенным в кавычки, также ключ в своем имени может содержать точки.
Имена "голых" ключей могут содержать только буквы 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" # НЕДЕЙСТВИТЕЛЬНО "" = "blank" # ДЕЙСТВИТЕЛЬНО, но не рекомендуется '' = 'blank' # ДЕЙСТВИТЕЛЬНО, но не рекомендуется
Ключи с точками представляют собой последовательность простых ключей или ключей в кавычках, соединенных точкой. Это позволяет группировать похожие свойства вместе:
name = "Orange" physical.color = "orange" physical.shape = "round" site."google.com" = true
В мире JSON это даст следующую структуру:
{ "name": "Orange", "physical": { "color": "orange", "shape": "round" }, "site": { "google.com": true } }
Для получения подробной информации о таблицах, которые определяют точечную нотацию, смотрите подраздел Таблицы.
Пробелы вокруг частей, разделенных точками, игнорируются. Однако лучше всего не использовать никаких посторонних пробелов.
fruit.name = "banana" # это наилучшая практика fruit. color = "yellow" # преобразуется в `fruit.color` fruit . flavor = "banana" # преобразуется в `fruit.flavor`
Отступ рассматривается как пробел и игнорируется.
Многократное определение ключа недопустимо.
# НЕ НАДО ТАК ДЕЛАТЬ name = "Tom" name = "Pradyun"
Обратите внимание, что "голые" ключи и ключи в кавычках эквивалентны:
# ТАК ТОЖЕ НЕ ПОЙДЕТ spelling = "favorite" "spelling" = "favourite"
Пока ключ не был определен напрямую, все равно можно писать в него и в имена внутри него.
# Это превращает ключ 'fruit' в таблицу. fruit.apple.smooth = true # Теперь можно добавлять в таблицу 'fruit' следующим образом: fruit.orange = 2 # СЛЕДУЮЩЕЕ НЕДЕЙСТВИТЕЛЬНО # Это определяет значение `fruit.apple` как целое число. fruit.apple = 1 # Но тогда это относится к `fruit.apple`, как будто это таблица. # Нельзя превратить целое число в таблицу. fruit.apple.smooth = true
Не рекомендуется определять точечные ключи не по порядку.
# ДЕЙСТВИТЕЛЬНО, НО НЕ РЕКОМЕНДУЕТСЯ apple.type = "fruit" orange.type = "fruit" apple.skin = "thin" orange.skin = "thick" apple.color = "red" orange.color = "orange" # РЕКОМЕНДУЕТСЯ ДЕЛАТЬ ТАК apple.type = "fruit" apple.skin = "thin" apple.color = "red" orange.type = "fruit" orange.skin = "thick" orange.color = "orange"
Так как "голые" ключи могут состоять только из целых чисел ASCII, то можно записывать ключи с точками, которые выглядят как числа с плавающей запятой, но представляют собой ключи с точками, состоящие из двух частей. Не делайте этого, если нет веской причины.
3.14159 = "pi"
Приведенный выше TOML сопоставляется со следующим JSON.
{ "3": { "14159": "pi" } }
Существует четыре способа выражения строк: базовый, многострочный базовый, литеральный и многострочный литеральный. Все строки должны содержать только допустимые символы UTF-8.
Основные строки заключаются в кавычки ("). Можно использовать любой символ Юникода, за исключением тех, которые должны быть экранированы: кавычка, обратная косая черта и управляющие символы, кроме табуляции (от U+0000 до U+0008, от U+000A до U). +001F, U+007F).
str = "I'm a string. \"You can quote me\". Name\tJos\u00E9\nLocation\tSF."
Для удобства некоторые популярные символы имеют компактную управляющую последовательность.
\b: backspace (U+0008);\t: табуляция (U+0009);\n: перевод строки (U+000A);\f: подача формы (U+000C);\r: возврат каретки (U+000D);\": кавычка (U+0022);\\: обратная косая черта (U+005C);\uXXXX: unicode (U+XXXX);\UXXXXXXXX: unicode (U+XXXXXXXX);Любой символ Unicode можно экранировать с помощью форм uXXXX или UXXXXXXXX. Коды перехода должны быть допустимыми скалярными значениями Unicode.
Все другие управляющие последовательности, не перечисленные выше, зарезервированы. Если они используются, TOML должен выдать ошибку.
Иногда нужно выразить фрагменты текста (например, файлы переводов) или необходимо разбить очень длинную строку на несколько строк. TOML упрощает эту задачу.
Многострочные базовые строки заключаются в три кавычки с каждой стороны и допускают перевод строки. Новая строка сразу после открывающего разделителя будет обрезана. Все остальные пробелы и символы новой строки остаются нетронутыми.
str1 = """ Roses are red Violets are blue"""
Парсеры TOML свободно нормализуют символ новой строки \n в зависимости от того, что имеет смысл для их платформы.
# В Unix, приведенная выше многострочная строка, будет такой же, как: str2 = "Roses are red\nViolets are blue" # В системе Windows это, скорее всего, будет эквивалентно: str3 = "Roses are red\r\nViolets are blue"
Для написания длинных строк, без добавления лишних пробелов, используйте "обратную косую черту в конце строки". Когда последним непробельным символом в строке является неэкранированный обратный слеш \, то он будет обрезан вместе со всеми пробелами (включая новые строки) до следующего непробельного символа или закрывающего разделителя. Все escape-последовательности, допустимые для базовых строк, также допустимы для многострочных базовых строк.
# Следующие строки побайтно эквивалентны: 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.\ """
Можно использовать любой символ Unicode, за исключением тех, которые должны быть экранированы: обратная косая черта и управляющие символы, кроме табуляции, перевода строки и возврата каретки (от U+0000 до U+0008, от U+000B, от U+000C, от U+000E до U). +001F, U+007F).
Можно записать кавычку или две смежные кавычки в любом месте внутри многострочной основной строки. Они также могут быть написаны только внутри разделителей.
str4 = """Here are two quotation marks: "". Simple enough.""" # str5 = """Here are three quotation marks: """.""" # НЕДЕЙСТВИТЕЛЬНО str5 = """Here are three quotation marks: ""\".""" str6 = """Here are fifteen quotation marks: ""\"""\"""\"""\"""\".""" # При разборе TOML возвратит: # "This," she said, "is just a pointless statement." str7 = """"This," she said, "is just a pointless statement.""""
Если часто указываются пути Windows или регулярные выражения, необходимость экранировать обратную косую черту быстро становится утомительной и подверженной ошибкам. Чтобы избежать этого, TOML поддерживает литеральные строки, которые вообще не допускают экранирования.
Литеральные строки заключены в одинарные кавычки. Как и базовые строки, они должны располагаться в одной строке:
# Здесь, как записано, так на выходе и получаем. winpath = 'C:\Users\nodejs\templates' winpath2 = '\\ServerX\admin$\system32\' quoted = 'Tom "Dubs" Preston-Werner' regex = '<\i\c*\s*>'
В связи с тем, что нет экранирования, нет возможности написать одинарную кавычку внутри литеральной строки, заключенной в одинарные кавычки. К счастью, TOML поддерживает многострочную версию литеральных строк, которая решает эту проблему.
Многострочные литеральные строки окружены тремя одинарными кавычками с каждой стороны и допускают перевод строки. Подобно литеральным строкам - нет никакого выхода. Новая строка сразу после открывающего разделителя будет обрезана. Все остальное содержимое между разделителями интерпретируется как есть без изменений.
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 одинарные кавычки в любом месте многострочной литеральной строки, но последовательности из трех или более одинарных кавычек не допускаются.
quot15 = '''Here are fifteen quotation marks: """""""""""""""''' # apos15 = '''Here are fifteen apostrophes: '''''''''''''''''' # НЕДЕЙСТВИТЕЛЬНО apos15 = "Here are fifteen apostrophes: '''''''''''''''" # При разборе TOML возвратит: # 'That,' she said, 'is still pointless.' str = ''''That,' she said, 'is still pointless.''''
В литеральной строке управляющие символы, кроме табуляции, не допускаются. Таким образом, для двоичных данных рекомендуется использовать Base64 или другую подходящую кодировку ASCII или UTF-8. Обработка этой кодировки зависит от приложения.
Перед положительными числами может стоять знак плюс. Перед отрицательными числами ставится знак минус.
int1 = +99 int2 = 42 int3 = 0 int4 = -17
Для больших чисел можно использовать символы подчеркивания между цифрами для улучшения читаемости. Каждое подчеркивание должно быть окружено как минимум одной цифрой с каждой стороны.
int5 = 1_000 int6 = 5_349_221 int8 = 1_2_3_4_5 # ДЕЙСТВИТЕЛЬНО, но не рекомендуется
Ведущие нули не допускаются. Целочисленные значения -0 и +0 допустимы и идентичны нулю без префикса.
Неотрицательные целые значения также могут быть выражены в шестнадцатеричном, восьмеричном или двоичном формате. В этих форматах начальный + не разрешен, а начальные нули разрешены (после префикса). Шестнадцатеричные значения нечувствительны к регистру. Подчеркивания разрешены между цифрами (но не между префиксом и значением).
# шестнадцатеричное число с префиксом `0x` hex1 = 0xDEADBEEF hex2 = 0xdeadbeef hex3 = 0xdead_beef # восьмеричное число с префиксом `0o` oct1 = 0o01234567 oct2 = 0o755 # useful for Unix file permissions # двоичное число с префиксом `0b` bin1 = 0b11010110
Произвольные 64-разрядные целые числа со знаком (от -2 ^ 63 до 2 ^ 63-1) принимаются и обрабатываются без потерь. Если целое число не может быть представлено без потерь, то выдается ошибка.
Число с плавающей запятой состоит из целой части (которая подчиняется тем же правилам, что и десятичные целые значения), за которой следует дробная часть и/или экспоненциальная часть. Если присутствуют и дробная часть, и экспоненциальная часть, то дробная часть должна предшествовать экспоненциальной части.
# fractional flt1 = +1.0 flt2 = 3.1415 flt3 = -0.01 # exponent flt4 = 5e+22 flt5 = 1e06 flt6 = -2E-2 # присутствуют оба flt7 = 6.626e-34
Дробная часть - это десятичная точка, за которой следует одна или несколько цифр.
Показатель степени представляет собой букву E (верхний или нижний регистр), за которой следует целая часть (которая следует тем же правилам, что и десятичные целые значения, но может включать ведущие нули).
Десятичная точка, если она используется, то должна быть окружена как минимум одной цифрой с каждой стороны.
# НЕДОПУСТИМЫЕ ЗАПИСИ invalid_float_1 = .7 invalid_float_2 = 7. invalid_float_3 = 3.e+20
Как и в случае с целыми числами, можно использовать символы подчеркивания для повышения удобочитаемости. Каждое подчеркивание должно быть окружено хотя бы одной цифрой.
flt8 = 224_617.445_991_228
Значения с плавающей запятой -0,0 и +0,0 допустимы и должны отображаться в соответствии со стандартом IEEE 754.
Также могут быть выражены специальные значения с плавающей запятой. Они всегда в нижнем регистре.
# бесконечность sf1 = inf # положительная бесконечность sf2 = +inf # положительная бесконечность sf3 = -inf # отрицательная бесконечность # не число sf4 = nan # фактическое кодирование sNaN/qNaN зависит от реализации sf5 = +nan # такой же, как `nan` sf6 = -nan # действительно, фактическое кодирование зависит от реализации
Значения bool - это просто токены, к которым все привыкли. Записываются всегда в нижнем регистре.
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
Если требуется миллисекундная точность. Дальнейшая точность долей секунды зависит от реализации. Если значение содержит большую точность, чем может поддерживать реализация, то дополнительная точность должна усекается, а не округляется.
Значения массивов в документе TOML записываются в квадратных скобках со значениями внутри. Пробелы игнорируется. Элементы разделяются запятыми. Массивы могут содержать значения тех же типов данных, которые разрешены в парах key/value. Также могут быть смешаны значения разных типов.
integers = [ 1, 2, 3 ] colors = [ "red", "yellow", "green" ] nested_arrays_of_ints = [ [ 1, 2 ], [3, 4, 5] ] nested_mixed_array = [ [ 1, 2 ], ["a", "b", "c"] ] string_array = [ "all", 'strings', """are the same""", '''type''' ] # Допускаются массивы смешанного типа. 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, # Такой комментарий - это нормально ]
Хэш-таблицы (также известные как словари) представляют собой наборы пар key/value. Они определяются заголовками в квадратных скобках в строке сами по себе. Заголовки хэш-таблиц, например [table] отличаются от массивов, так как массивы всегда являются значениями.
Под заголовком и до следующего заголовка или EOF находятся пары key/value этой таблицы. Пары key/value в таблицах не обязательно располагаются в определенном порядке.
[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] # тоже, что и [d.e.f] [ d.e.f ] # тоже, что и [g.h.i] [ g . h . i ] # тоже, что и [j."ʞ".'l'] [ j . "ʞ" . 'l' ]
Отступ рассматривается как пробел и игнорируется.
Не нужно указывать все супер-таблицы (вложенные одна в другую), если это не требуется. TOML знает, как это сделать за вас.
# [x] не нужно # [x.y] указывать # [x.y.z] все уровни # чтобы запись ниже сработала [x.y.z.w] # последующее определение для # супер-таблицы - это нормально [x]
Допускаются пустые хэш-таблицы, в которых просто нет пар key/value. Как и ключи, таблицу нельзя определить более одного раза. Это недопустимо.
# НЕ ДЕЛАЙТЕ ЭТОГО [fruit] apple = "red" [fruit] orange = "orange"
# НЕ ДЕЛАЙТЕ ЭТОГО ТОЖЕ [fruit] apple = "red" [fruit.apple] texture = "smooth"
Не рекомендуется определять хэш-таблицы не по порядку.
# ДЕЙСТВИТЕЛЬНО, НО НЕ РЕКОМЕНДУЕТСЯ [fruit.apple] [animal] [fruit.orange] # РЕКОМЕНДУЕМЫЙ СПОСОБ [fruit.apple] [fruit.orange] [animal]
Хэш-таблица верхнего уровня, также называемая корневой хэш-таблицей, начинается в начале документа и заканчивается непосредственно перед заголовком первой хэш-таблицы (или EOF). В отличие от других хэш-таблиц, она безымянная и не может быть перемещена.
# начинается таблица верхнего уровня. name = "Fido" breed = "pug" # Таблица верхнего уровня заканчивается. [owner] name = "Regina Dogman" member_since = 1999-08-04
Ключи с точками создают и определяют хэш-таблицу для каждой ключевой части перед последней, при условии, что такие таблицы ранее не создавались.
fruit.apple.color = "red" # Определяет таблицу с именем fruit # Определяет таблицу с именем fruit.apple fruit.apple.taste.sweet = true # Определяет таблицу с именем fruit.apple.taste. # fruit и fruit.apple уже были созданы
Поскольку хэш-таблицы не могут быть определены более одного раза, переопределение таких хэш-таблиц с использованием заголовка [table] не допускается. Аналогично, не допускается использование ключей с точками для переопределения хэш-таблиц, уже определенных в форме [table]. Допускается использование формы [table] для определения подтаблиц внутри хэш-таблиц, определенных с помощью ключей c точками.
[fruit] apple.color = "red" apple.taste.sweet = true # [fruit.apple] # НЕДОПУСТИМО # [fruit.apple.taste] # НЕДОПУСТИМО # можно добавлять вложенные таблицы [fruit.apple.texture] smooth = true
Использование однострочной записи хэш-таблиц в документе TOML обеспечивает более компактный синтаксис для выражения хеш-таблиц. Они особенно полезны для сгруппированных данных, которые в противном случае могут быстро стать подробными. Однострочная запись хэш-таблиц полностью определяются в фигурных скобках: { и }. Внутри фигурных скобок может быть ноль или более пар key = value, разделенных запятыми. Пары key = value имеют ту же форму, что и пары key = value в стандартных хэш-таблицах. Разрешены все типы значений, включая вложенные однострочные записи.
Такая определение хэш-таблиц в документе TOML предназначена для размещения в одной строке. После последней пары key = value, завершающая запятая не допускается. Не допускаются символы новой строки между фигурными скобками, если только они должны использоваться внутри значения. Настоятельно не рекомендуется разбивать однострочную запись хэш-таблиц на несколько строк. Если одолевает такое желание, значит, следует использовать стандартную запись хеш-таблицы.
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 # ЗАПИСЬ НЕДЕЙСТВИТЕЛЬНА
Точно так же однострочные хеш-таблицы нельзя использовать для добавления ключей или подтаблиц в уже определенную таблицу.
[product] type.name = "Nail" # type = { edible = false } # ЗАПИСЬ НЕДЕЙСТВИТЕЛЬНА
Последний еще не описанный синтаксис позволяет записывать массивы хеш-таблиц. Их можно выразить с помощью заголовка с именем в двойных скобках [[name]]. Первый экземпляр этого заголовка определяет массив и его первый элемент хеш-таблицы, а каждый последующий экземпляр создает и определяет новый элемент хеш-таблицы в этом массиве. Хеш-таблицы вставляются в массив в порядке их появления.
[[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" } ] }
Любая ссылка на массив хеш-таблиц указывает на последний определенный элемент таблицы массива. Такое поведение позволяет определять подтаблицы и даже подмассивы таблиц внутри самой последней таблицы.
[[fruits]] name = "apple" # подтаблица [fruits.physical] color = "red" shape = "round" # вложенный массив таблиц [[fruits.varieties]] name = "red delicious" [[fruits.varieties]] name = "granny smith" [[fruits]] name = "banana" [[fruits.varieties]] name = "plantain"
Приведенный выше TOML сопоставляется со следующим JSON.
{ "fruits": [ { "name": "apple", "physical": { "color": "red", "shape": "round" }, "varieties": [ { "name": "red delicious" }, { "name": "granny smith" } ] }, { "name": "banana", "varieties": [ { "name": "plantain" } ] } ] }
Если родительский элемент хеш-таблицы или массива хеш-таблиц является элементом массива, то этот элемент должен быть уже определен, прежде чем можно будет определить дочерний элемент. Попытки изменить этот порядок должны привести к ошибке во время синтаксического анализа.
# НЕДЕЙСТВИТЕЛЬНЫЙ ДОКУМЕНТ TOML # подтаблица, но к какому родительскому # элементу она должна принадлежать? [fruit.physical] color = "red" shape = "round" # синтаксический анализатор должен выдаст ошибку, # обнаружив, что `fruit` - это массив, а не таблица [[fruit]] name = "apple"
Попытка добавления к статически определенному массиву, даже если этот массив пуст, приведет к ошибке во время синтаксического анализа.
# НЕДЕЙСТВИТЕЛЬНЫЙ ДОКУМЕНТ TOML fruits = [] # Не допускается [[fruits]]
Попытка определить обычную хеш-таблицу с тем же именем, что и у уже установленного массива, приводит к ошибке во время синтаксического анализа. Попытка переопределить обычную хеш-таблицу как массив также должна привести к ошибке во время синтаксического анализа.
# НЕДЕЙСТВИТЕЛЬНЫЙ ДОКУМЕНТ TOML [[fruits]] name = "apple" [[fruits.varieties]] name = "red delicious" # НЕДОПУСТИМО: Эта таблица конфликтует # с предыдущим массивом таблиц [fruits.varieties] name = "granny smith" [fruits.physical] color = "red" shape = "round" # НЕДОПУСТИМО: Этот массив таблиц # конфликтует с предыдущей таблицей [[fruits.physical]] color = "green"
Вы также можете использовать однострочные записи хеш-таблиц, где это уместно:
points = [ { x = 1, y = 2, z = 3 }, { x = 7, y = 8, z = 9 }, { x = 2, y = 4, z = 8 } ]