ไวยากรณ์ JSON อนุญาตคีย์ที่ซ้ำกันในวัตถุหรือไม่

json นี้ถูกต้องหรือไม่

{
    "a" : "x",
    "a" : "y"
}

http://jsonlint.com/พูดว่าใช่

http://www.json.org/ไม่พูดอะไรเกี่ยวกับเรื่องนี้ว่าเป็นสิ่งต้องห้าม

แต่เห็นได้ชัดว่ามันไม่เข้าท่าใช่มั้ย การใช้งานส่วนใหญ่อาจใช้ hashtable ดังนั้นมันจึงถูก overriden ต่อไป

จากมาตรฐาน (หน้า ii) :

คาดว่ามาตรฐานอื่นจะอ้างอิงถึงสิ่งนี้โดยยึดตามรูปแบบข้อความ JSON อย่างเคร่งครัดขณะที่กำหนดข้อ จำกัด ในรายละเอียดการเข้ารหัสต่างๆ มาตรฐานดังกล่าวอาจต้องการพฤติกรรมที่เฉพาะเจาะจง JSON เองไม่ได้ระบุพฤติกรรม

ยิ่งลงไปในมาตรฐาน (หน้า 2) สเปคสำหรับวัตถุ JSON:

โครงสร้างวัตถุถูกแสดงเป็นคู่ของโทเค็นวงเล็บปีกกาที่ล้อมรอบคู่ชื่อ / ค่าเป็นศูนย์หรือมากกว่า ชื่อคือสตริง โทเค็นโคลอนเดี่ยวติดตามแต่ละชื่อโดยแยกชื่อออกจากค่า โทเค็นเครื่องหมายจุลภาคเดียวคั่นค่าจากชื่อต่อไปนี้

ไม่ได้กล่าวถึงคีย์ที่ซ้ำกันว่าไม่ถูกต้องหรือไม่ถูกต้องดังนั้นตามข้อกำหนดที่ฉันจะถือว่าปลอดภัยหมายความว่าพวกเขาได้รับอนุญาต

การปรับใช้ส่วนใหญ่ของไลบรารี JSON ไม่ยอมรับคีย์ที่ซ้ำกันจะไม่ขัดแย้งกับมาตรฐานเนื่องจากการอ้างอิงครั้งแรก

นี่คือสองตัวอย่างที่เกี่ยวข้องกับไลบรารีมาตรฐาน C ++ เมื่อทำการแยกวัตถุ JSON ออกเป็นวัตถุstd::mapจะทำให้การปฏิเสธคีย์ที่ซ้ำกัน แต่เมื่อทำการแยกวัตถุ JSON บางส่วนออกเป็นสิ่งที่เหมาะสมstd::multimapก็คือการยอมรับคีย์ที่ซ้ำกันตามปกติ

คำตอบสั้น ๆ : ใช่ แต่ไม่แนะนำ
คำตอบที่ยาวนาน: ขึ้นอยู่กับสิ่งที่คุณเรียกว่าถูกต้อง ...

ECMA-404 "ไวยากรณ์การแลกเปลี่ยนข้อมูล JSON" ไม่ได้พูดอะไรเกี่ยวกับชื่อซ้ำ (คีย์)

อย่างไรก็ตามRFC 8259 "รูปแบบการแลกเปลี่ยนข้อมูลวัตถุ JavaScript (JSON)" กล่าวว่า:

ชื่อภายในวัตถุควรเป็นชื่อเฉพาะ

ในบริบทนี้ควรจะต้องเข้าใจตามที่ระบุในBCP 14 :

ควรคำนี้หรือคำคุณศัพท์ "แนะนำ" หมายความว่าอาจมีเหตุผลที่ถูกต้องในบางสถานการณ์ที่จะไม่สนใจรายการใดรายการหนึ่ง แต่ต้องเข้าใจและชั่งน้ำหนักอย่างรอบคอบก่อนเลือกหลักสูตรอื่น

RFC 8259อธิบายว่าทำไมชื่อเฉพาะ (คีย์) จึงดี:

วัตถุที่มีชื่อไม่ซ้ำกันสามารถใช้งานร่วมกันได้ในแง่ที่ว่าการใช้งานซอฟต์แวร์ทั้งหมดที่ได้รับวัตถุนั้นจะตกลงในการแมปชื่อ - ค่า เมื่อชื่อภายในวัตถุไม่ซ้ำกันพฤติกรรมของซอฟต์แวร์ที่ได้รับวัตถุดังกล่าวจะไม่สามารถคาดเดาได้ การใช้งานจำนวนมากรายงานคู่สุดท้ายของชื่อ / ค่าเท่านั้น การใช้งานอื่น ๆ รายงานข้อผิดพลาดหรือล้มเหลวในการแยกวิเคราะห์วัตถุและการใช้งานบางอย่างรายงานชื่อคู่ / ค่าทั้งหมดรวมถึงรายการที่ซ้ำกัน

นอกจากนี้ตามที่ Serguei ชี้ให้เห็นในความคิดเห็น: ECMA-262 "ข้อมูลจำเพาะภาษาECMAScript®" อ่าน:

ในกรณีที่มี Strings ชื่อซ้ำกันภายในวัตถุค่าก่อนหน้าของคำศัพท์สำหรับคีย์เดียวกันจะถูกเขียนทับ

ในคำอื่น ๆ มูลค่าสุดท้ายชนะ

การพยายามแยกสตริงที่มีชื่อซ้ำกับการใช้งาน Java โดย Douglas Crockford (ผู้สร้าง JSON) ส่งผลให้เกิดข้อยกเว้น :

org.json.JSONException: Duplicate key "status"  at
org.json.JSONObject.putOnce(JSONObject.java:1076)

มีเอกสาร 2 ฉบับที่ระบุรูปแบบ JSON:

1. http://json.org/
2. https://tools.ietf.org/html/rfc7159

คำพูดคำตอบที่ยอมรับได้จากเอกสารที่ 1 ฉันคิดว่าเอกสารฉบับที่ 1 มีความชัดเจนยิ่งขึ้น แต่เอกสารฉบับที่ 2 มีรายละเอียดเพิ่มเติม

เอกสารฉบับที่ 2 กล่าวว่า:

4. วัตถุ

   โครงสร้างวัตถุถูกแสดงเป็นคู่ของวงเล็บปีกกาที่ล้อมรอบคู่ชื่อ / ค่าเป็นศูนย์หรือมากกว่า (หรือสมาชิก) ชื่อคือสตริง เครื่องหมายโคลอนเดียวมาหลังชื่อแต่ละชื่อแยกชื่อออกจากค่า เครื่องหมายจุลภาคเดียวคั่นค่าจากชื่อต่อไปนี้ ชื่อภายในวัตถุควรเป็นชื่อเฉพาะ

ดังนั้นจึงไม่ได้รับอนุญาตให้มีชื่อซ้ำกัน แต่มันเป็นสิ่งที่ท้อแท้

ฉันเจอคำถามที่คล้ายกันเมื่อจัดการกับ API ที่ยอมรับทั้ง XML และ JSON แต่ไม่มีเอกสารว่าจะจัดการกับสิ่งที่คุณคาดหวังว่าจะได้รับคีย์ซ้ำใน JSON ที่ยอมรับได้อย่างไร

ต่อไปนี้เป็นตัวแทน XML ที่ถูกต้องของตัวอย่าง JSON ของคุณ:

<object>
  <a>x</a>
  <a>y</a>
</object>

เมื่อสิ่งนี้ถูกแปลงเป็น JSON คุณจะได้รับสิ่งต่อไปนี้:

{
  "object": {
    "a": [
      "x",
      "y"
    ]
  }
}

การทำแผนที่ตามธรรมชาติจากภาษาที่จัดการกับสิ่งที่คุณอาจเรียกว่าคีย์ที่ซ้ำกันไปยังอีกสามารถใช้เป็นข้อมูลอ้างอิงการปฏิบัติที่ดีที่สุดที่นี่

หวังว่าจะช่วยใครบางคน!

ข้อมูลจำเพาะ JSON กล่าวว่า:

วัตถุคือชุดคู่ของชื่อ / ค่าที่ไม่เรียงลำดับ

ส่วนสำคัญที่นี่คือ "ไม่ได้เรียงลำดับ": มันหมายถึงเอกลักษณ์ของคีย์เพราะสิ่งเดียวที่คุณสามารถใช้เพื่ออ้างถึงคู่ที่เฉพาะเจาะจงคือกุญแจของมัน

นอกจากนี้ libs JSON ส่วนใหญ่จะทำการแยกวัตถุ JSON เพื่อแฮชแม็พ / พจนานุกรมที่มีการรับประกันคีย์ที่ไม่ซ้ำกัน จะเกิดอะไรขึ้นเมื่อคุณทำการเลิกวัตถุ JSON ที่มีคีย์ซ้ำกันขึ้นอยู่กับไลบรารี: ในกรณีส่วนใหญ่คุณจะได้รับข้อผิดพลาดหรือเฉพาะค่าสุดท้ายสำหรับแต่ละคีย์ที่ซ้ำกันเท่านั้นที่จะถูกนำมาพิจารณา

ยกตัวอย่างเช่นในหลามผลตอบแทนjson.loads('{"a": 1, "a": 2}'){"a": 2}

ควรเป็นเอกลักษณ์ไม่ได้หมายความว่าจะต้องไม่ซ้ำกัน อย่างไรก็ตามตามที่ระบุไว้ตัวแยกวิเคราะห์บางตัวจะล้มเหลวและบางรายการก็ใช้ค่าสุดท้ายที่แยกวิเคราะห์ อย่างไรก็ตามถ้าข้อมูลจำเพาะถูกทำความสะอาดเล็กน้อยเพื่อให้สามารถทำซ้ำได้ฉันจะเห็นการใช้งานที่คุณอาจมีตัวจัดการเหตุการณ์ซึ่งเปลี่ยน JSON เป็น HTML หรือรูปแบบอื่น ๆ ... ในกรณีเช่นนี้มันจะใช้ได้อย่างสมบูรณ์แบบ วิเคราะห์ JSON และสร้างรูปแบบเอกสารอื่น ...

[
  "div":
  {
    "p":"hello",
    "p":"universe"
  }
  "div":
  {
    "h1":"Heading 1",
    "p":"another paragraph"
  }
]

สามารถแยกวิเคราะห์ตัวอย่างเช่น html ได้อย่างง่ายดาย

<body>
 <div>
  <p>hello</p>
  <p>universe</p>
 </div>
 <div>
  <h1>Heading 1</h1>
  <p>another paragraph</p>
 </div>
</body>

ฉันเห็นเหตุผลที่อยู่เบื้องหลังคำถาม แต่มันยืน ... ฉันไม่เชื่อใจ

การขอจุดประสงค์มีคำตอบต่าง ๆ :

การใช้ JSON เพื่อทำให้เป็นอันดับวัตถุ (JavaScriptObjectNotation) แต่ละองค์ประกอบพจนานุกรมจะจับคู่กับคุณสมบัติของวัตถุที่แยกต่างหากดังนั้นรายการต่าง ๆ ที่กำหนดค่าสำหรับคุณสมบัติเดียวกันไม่มีความหมาย

อย่างไรก็ตามฉันพบคำถามเดียวกันจากกรณีการใช้งานที่เฉพาะเจาะจงมาก: การเขียนตัวอย่าง JSON สำหรับการทดสอบ API ฉันสงสัยว่าจะเพิ่มความคิดเห็นลงในไฟล์ JSON ของเราได้อย่างไรโดยไม่ทำลายการใช้งาน ข้อมูลจำเพาะของ JSON ไม่ทราบความคิดเห็นดังนั้นฉันจึงคิดวิธีที่ง่ายมาก:

เมื่อต้องการใช้คีย์ที่ซ้ำกันจะแสดงความคิดเห็นตัวอย่าง JSON ของเรา ตัวอย่าง:

{ "property1" : "value1", "REMARK" : "... prop1 controls ...", "property2" : "value2", "REMARK" : "... value2 raises an exception ...", }

JSON serializers ที่เราใช้อยู่นั้นไม่มีปัญหากับการซ้ำซ้อน "REMARK" เหล่านี้และรหัสแอปพลิเคชันของเราจะไม่สนใจค่าใช้จ่ายเล็กน้อยนี้

ดังนั้นแม้ว่าจะไม่มีความหมายในเลเยอร์ของแอปพลิเคชัน แต่ข้อมูลที่ซ้ำกันเหล่านี้ให้วิธีการที่มีคุณค่าในการเพิ่มความคิดเห็นในตัวอย่างการทดสอบของเราโดยไม่ทำลายการใช้งานของ JSON

การโพสต์และตอบคำถามเนื่องจากมีความคิดและความสับสนที่ล้าสมัยมากมายเกี่ยวกับมาตรฐาน ณ เดือนธันวาคม 2560 มีสองมาตรฐานการแข่งขัน:

RFC 8259 - https://tools.ietf.org/html/rfc8259

ECMA-404 - http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

json.org แสดงให้เห็น ECMA-404 เป็นมาตรฐาน แต่เว็บไซต์นี้ไม่ได้ปรากฏเป็นผู้มีอำนาจ ในขณะที่ฉันคิดว่ามันยุติธรรมที่จะพิจารณาสิทธิ์ของ ECMA สิ่งที่สำคัญคือที่นี่ความแตกต่างเพียงอย่างเดียวระหว่างมาตรฐาน (เกี่ยวกับคีย์เฉพาะ) คือ RFC 8259 กล่าวว่าคีย์ควรไม่ซ้ำกันและ ECMA-404 กล่าวว่าพวกเขาไม่จำเป็นต้องเป็น เป็นเอกลักษณ์

RFC-8259:

"ชื่อภายในวัตถุควรเป็นชื่อเฉพาะ"

คำว่า "ควร" ในตัวพิมพ์ใหญ่ทั้งหมดนั้นมีความหมายภายในโลก RFC ที่กำหนดไว้ในมาตรฐานอื่น (BCP 14, RFC 2119 - https://tools.ietf.org/html/rfc2119 ) เป็นมาตรฐานอื่น

3. ควรคำนี้หรือคำคุณศัพท์ "แนะนำ" หมายความว่าอาจมีเหตุผลที่ถูกต้องในสถานการณ์พิเศษที่จะไม่สนใจรายการใดรายการหนึ่ง แต่จะต้องเข้าใจและชั่งน้ำหนักอย่างรอบคอบก่อนเลือกหลักสูตรอื่น

ECMA-404:

"ไวยากรณ์ JSON ไม่ได้กำหนดข้อ จำกัด ใด ๆ ของสตริงที่ใช้เป็นชื่อไม่ต้องการให้สตริงชื่อนั้นไม่ซ้ำกันและไม่ได้กำหนดนัยสำคัญใด ๆ ให้กับการเรียงลำดับของคู่ชื่อ / ค่า"

ดังนั้นไม่ว่าคุณจะเชือดมันไม่มีมันเป็น JSON

เหตุผลที่กำหนดสำหรับคำแนะนำคีย์เฉพาะใน RFC 8259 คือ

วัตถุที่มีชื่อไม่ซ้ำกันสามารถใช้งานร่วมกันได้ในแง่ที่ว่าการใช้งานซอฟต์แวร์ทั้งหมดที่ได้รับวัตถุนั้นจะตกลงในการแมปชื่อ - ค่า เมื่อชื่อภายในวัตถุไม่ซ้ำกันพฤติกรรมของซอฟต์แวร์ที่ได้รับวัตถุดังกล่าวจะไม่สามารถคาดเดาได้ การใช้งานจำนวนมากรายงานคู่สุดท้ายของชื่อ / ค่าเท่านั้น การใช้งานอื่น ๆ รายงานข้อผิดพลาดหรือล้มเหลวในการแยกวิเคราะห์วัตถุและการใช้งานบางอย่างรายงานชื่อคู่ / ค่าทั้งหมดรวมถึงรายการที่ซ้ำกัน

กล่าวอีกนัยหนึ่งจากมุมมอง RFC 8259 ใช้ได้ แต่ตัวแยกวิเคราะห์ของคุณอาจมีปัญหาและไม่มีคำสัญญาว่าจะมีการจับคู่กับคีย์นั้นหรือไม่ถ้ามี จากมุมมองของ ECMA-404 (ซึ่งฉันได้รับมอบหมายเป็นการส่วนตัว) เป็นสิ่งที่ถูกต้องเป็นระยะเวลา สำหรับฉันนี่หมายความว่าโปรแกรมแยกวิเคราะห์ใด ๆ ที่ปฏิเสธที่จะแยกวิเคราะห์จะเสีย อย่างน้อยควรแยกวิเคราะห์ตามมาตรฐานทั้งสองนี้ แต่วิธีที่ทำให้มันกลายเป็นวัตถุพื้นเมืองที่คุณเลือกได้ไม่ว่าจะในกรณีใด ๆ คีย์ที่ไม่ซ้ำกันหรือไม่ขึ้นอยู่กับสภาพแวดล้อมและสถานการณ์อย่างสมบูรณ์และไม่มีสิ่งใดในมาตรฐานที่เริ่มต้นด้วย

มันไม่ได้กำหนดไว้ในมาตรฐาน ECMA JSON และโดยทั่วไปแล้วการขาดความหมายในมาตรฐานหมายถึง "อย่าพึ่งพางานนี้ในทุก ๆ ที่"

หากคุณเป็นนักการพนันเอ็นจิ้น JSON "จำนวนมาก" จะอนุญาตการทำซ้ำและเพียงแค่ใช้ค่าสุดท้ายที่ระบุ นี้:

var o = {"a": 1, "b": 2, "a": 3}

กลายเป็นสิ่งนี้:

Object {a: 3, b: 2}

แต่ถ้าคุณไม่ใช่นักการพนันอย่าวางใจในมัน!

มาตรฐานจะบอกสิ่งนี้:

ภาษาการเขียนโปรแกรมนั้นขึ้นอยู่กับว่าพวกเขาสนับสนุนวัตถุหรือไม่และถ้าเป็นเช่นนั้นลักษณะและข้อ จำกัด ของวัตถุที่เสนอ แบบจำลองของระบบวัตถุสามารถแตกต่างกันอย่างดุเดือดและกำลังพัฒนาอย่างต่อเนื่อง JSON ให้สัญกรณ์อย่างง่ายสำหรับการแสดงคอลเลกชันของคู่ชื่อ / ค่า ภาษาการเขียนโปรแกรมส่วนใหญ่จะมีคุณสมบัติบางอย่างในการเป็นตัวแทนของคอลเลกชันดังกล่าวซึ่งสามารถไปตามชื่อเช่นบันทึก, struct, dict, map, hash หรือวัตถุ

ข้อผิดพลาดอยู่ใน node.js อย่างน้อย รหัสนี้สำเร็จใน node.js

try {
     var json = {"name":"n","name":"v"};
     console.log(json); // outputs { name: 'v' }
} catch (e) {
     console.log(e);
}

ตาม RFC-7159 มาตรฐานปัจจุบันของ JSON ที่เผยแพร่โดย Internet Engineering Task Force (IETF) ระบุว่า "ชื่อภายในวัตถุควรเป็นเอกลักษณ์" อย่างไรก็ตามตาม RFC-2119 ซึ่งกำหนดคำศัพท์ที่ใช้ในเอกสาร IETF คำว่า "ควร" ในความเป็นจริงหมายถึง "... อาจมีเหตุผลที่ถูกต้องในสถานการณ์พิเศษที่จะไม่สนใจรายการใดรายการหนึ่ง แต่ต้องเข้าใจและ ชั่งน้ำหนักอย่างรอบคอบก่อนเลือกหลักสูตรอื่น " สิ่งนี้มีความหมายว่าในขณะที่มีการแนะนำปุ่มที่ไม่ซ้ำใครก็ไม่จำเป็นต้อง เราสามารถมีคีย์ที่ซ้ำกันในวัตถุ JSON และมันจะยังคงถูกต้อง

จากการใช้งานจริงฉันเห็นค่าจากคีย์สุดท้ายถูกพิจารณาเมื่อพบคีย์ที่ซ้ำกันใน JSON

ใน C # หากคุณ deserialise ถึง a Dictionary<string, string>จะใช้คู่ของค่าคีย์สุดท้าย:

string json = @"{""a"": ""x"", ""a"": ""y""}";
var d = JsonConvert.DeserializeObject<Dictionary<string, string>>(json);
// { "a" : "y" }

ถ้าคุณพยายามจะเลิก

class Foo
{
    [JsonProperty("a")]
    public string Bar { get; set; }

    [JsonProperty("a")]
    public string Baz { get; set; }
}

var f = JsonConvert.DeserializeObject<Foo>(json);

คุณได้รับNewtonsoft.Json.JsonSerializationExceptionข้อยกเว้น