參考

字串

string 類型用於文字字串。它可以包含 Unicode 字元。

特定語言資訊:
Python
Ruby
Objective-C
Swift
在 Python 中,「字串」類似於 Python 上的 unicode 類型
schema
{ "type": "string" }
資料
"Déjà vu"
符合 schema
資料
""
符合 schema
資料
"42"
符合 schema
資料
42
不符合 schema

長度

字串的長度可以使用 minLengthmaxLength 關鍵字來限制。對於這兩個關鍵字,值必須為非負數。

schema
{ "type": "string", "minLength": 2, "maxLength": 3}
資料
"A"
不符合 schema
資料
"AB"
符合 schema
資料
"ABC"
符合 schema
資料
"ABCD"
不符合 schema

正規表示式

pattern 關鍵字用於將字串限制為特定的正規表示式。正規表示式語法是 JavaScript 中定義的語法(具體而言是 ECMA 262),並支援 Unicode。詳情請參閱正規表示式

在定義正規表示式時,務必注意,如果表示式在字串中的任何位置匹配,則該字串會被視為有效。例如,正規表示式 "p" 將會匹配任何包含 p 的字串,例如 "apple",而不僅僅是單純為 "p" 的字串。因此,通常為了避免混淆,建議將正規表示式用 ^...$ 包圍,例如 "^p$",除非有充分的理由不這麼做。

以下範例匹配一個簡單的北美電話號碼,其中區碼為選填。

schema
{ "type": "string", "pattern": "^(\\([0-9]{3}\\))?[0-9]{3}-[0-9]{4}$"}
資料
"555-1212"
符合 schema
資料
"(888)555-1212"
符合 schema
資料
"(888)555-1212 ext. 532"
不符合 schema
資料
"(800)FLOWERS"
不符合 schema

格式

format 關鍵字允許對常用的特定種類的字串值進行基本語義識別。例如,由於 JSON 沒有「DateTime」類型,因此日期需要編碼為字串。format 允許綱要作者指出字串值應被解釋為日期。預設情況下,format 只是一個註解,不會影響驗證。

或者,驗證器實作可以提供一個組態選項,使 format 作為斷言而不是僅作為註解。這表示如果一個具有 date 格式的值不是可以解析為日期的形式,則驗證將會失敗。這可以使數值的約束超越 JSON 綱要中其他工具(包括正規表示式)可以做到的程度。

實作可能僅為內建格式的子集提供驗證,或者對給定格式進行部分驗證。例如,某些實作可能會認為字串包含 @ 即為電子郵件,而其他實作可能會對格式正確的電子郵件地址的其他方面進行額外檢查。

JSON 綱要規範中偏向與網路相關的格式,這很可能是由於它在網路技術中的起源。但是,只要交換 JSON 文件的各方也交換了自訂格式類型的相關資訊,也可以使用自訂格式。JSON 綱要驗證器會忽略任何它不了解的格式類型。

內建格式

以下是 JSON 綱要規範中指定的格式列表。

日期和時間

日期和時間以 RFC 3339,第 5.6 節表示。這是日期格式的子集,也常稱為ISO8601 格式

  • "date-time":日期和時間組合,例如 2018-11-13T20:20:39+00:00
  • "time":
    在草案 7 中新增
    時間,例如 20:20:39+00:00
  • "date":
    在草案 7 中新增
    日期,例如 2018-11-13
  • "duration":
    在草案 2019-09 中新增
    一個由ISO 8601 ABNF 定義的「duration」表示的持續時間。例如,P3D 表示持續時間為 3 天。

電子郵件地址

  • "email":網際網路電子郵件地址,請參閱 RFC 5321,第 4.1.2 節
  • "idn-email":
    在草案 7 中新增
    網際網路電子郵件地址的國際化形式,請參閱 RFC 6531

主機名稱

IP 位址

資源識別符

  • "uuid":
    在草案 2019-09 中新增
    一個由 RFC 4122 定義的通用唯一識別符。範例:3e4666bf-d5e5-4aa7-b8ce-cefe41c7568a
  • "uri":根據 RFC3986 的通用資源識別符 (URI)。
  • "uri-reference":
    在草案 6 中新增
    根據 RFC3986,第 4.1 節的 URI 參考(URI 或相對參考)。
  • "iri":
    在草案 7 中新增
    根據 RFC3987 的「uri」的國際化對等形式。
  • "iri-reference":
    在草案 7 中新增
    根據 RFC3987 的「uri-reference」的國際化對等形式。

如果綱要中的值能夠相對於特定的來源路徑(例如網頁中的連結),則通常最好使用 "uri-reference"(或 "iri-reference")而不是 "uri"(或 "iri")。只有在路徑必須是絕對路徑時,才應使用 "uri"

URI 樣板

  • "uri-template":
    在草案 6 中新增
    根據 RFC6570 的 URI 樣板(任何層級)。如果您還不知道 URI 樣板是什麼,您可能不需要此值。

JSON 指標

  • "json-pointer":
    在草案 6 中新增
    根據 RFC6901 的 JSON 指標。關於在 JSON 綱要中使用 JSON 指標的更多討論,請參閱建構複雜綱要。請注意,這僅應在整個字串僅包含 JSON 指標內容時使用,例如 /foo/bar。JSON 指標 URI 片段,例如 #/foo/bar/ 應使用 "uri-reference"
  • "relative-json-pointer":
    在草案 7 中新增
    相對 JSON 指標

正規表示式

  • "regex":
    在草案 7 中新增
    一個正規表示式,根據 ECMA 262 方言應為有效。

請注意,實際上,JSON Schema 驗證器只需要接受本文件中其他地方描述的正規表示式的安全子集。

需要協助嗎?

您覺得這些文件有幫助嗎?

幫助我們讓文件更完善!

在 JSON Schema,我們重視文件貢獻,如同其他類型的貢獻一樣!

仍然需要協助嗎?

學習 JSON Schema 通常令人困惑,但別擔心,我們在這裡提供協助!