มีเหตุผลที่เป็นประโยชน์ในการใช้สตริงที่ยกมาสำหรับคีย์ JSON หรือไม่

ตาม Crockford ของjson.orgเป็น JSON วัตถุถูกสร้างขึ้นจากสมาชิกซึ่งถูกสร้างขึ้นจากคู่

ทุกคู่ประกอบด้วยสตริงและค่าโดยมีการกำหนดสตริงเป็น:

สตริงคือลำดับของอักขระ Unicode ที่เป็นศูนย์หรือมากกว่าซึ่งรวมอยู่ในเครื่องหมายคำพูดคู่โดยใช้เครื่องหมายแบ็กสแลช Escape อักขระแสดงเป็นสตริงอักขระเดี่ยว สตริงก็เหมือนกับสตริง C หรือ Java

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

มันสมเหตุสมผลหรือไม่ที่จะรบกวน JSON ของคุณในเครื่องหมายคำพูดคู่?

ตัวอย่างที่ถูกต้อง:

{
  "keyName" : 34
}

ตรงข้ามกับไม่ถูกต้อง:

{
   keyName : 34
}

เหตุผลที่แท้จริงว่าทำไมคีย์ JSON ควรอยู่ในเครื่องหมายคำพูดขึ้นอยู่กับความหมายของตัวระบุของ ECMAScript 3

ไม่สามารถใช้คำสงวนเป็นชื่อคุณสมบัติใน Object Literals โดยไม่มีเครื่องหมายคำพูดตัวอย่างเช่น:

({function: 0}) // SyntaxError
({if: 0}) // SyntaxError
({true: 0}) // SyntaxError
// etc...

แม้ว่าคุณจะใช้เครื่องหมายคำพูดชื่อคุณสมบัติจะถูกต้อง:

({"function": 0}) // Ok
({"if": 0}) // Ok
({"true": 0}) // Ok

Crockford ของตัวเองอธิบายไว้ในการพูดคุยนี้พวกเขาต้องการรักษามาตรฐาน JSON ให้เรียบง่ายและไม่ต้องการมีข้อ จำกัด ด้านความหมายทั้งหมด:

....

นั่นคือตอนที่เราค้นพบปัญหาชื่อที่ไม่ได้อ้างถึง ปรากฎว่า ECMA Script 3 มีนโยบายตีคำสงวน คำสงวนจะต้องถูกยกมาในตำแหน่งสำคัญซึ่งเป็นเรื่องที่น่ารำคาญจริงๆ เมื่อฉันเริ่มกำหนดสิ่งนี้ให้เป็นมาตรฐานฉันไม่ต้องการให้คำสงวนทั้งหมดอยู่ในมาตรฐานเพราะมันจะดูโง่จริงๆ

ตอนนั้นฉันพยายามโน้มน้าวผู้คนใช่คุณสามารถเขียนแอปพลิเคชันใน JavaScript มันใช้งานได้จริงและเป็นภาษาที่ดี ฉันไม่อยากจะพูดในเวลาเดียวกัน: และดูสิ่งที่โง่เขลาจริงๆที่พวกเขาทำ! ดังนั้นฉันจึงตัดสินใจว่าเรามาพูดถึงคีย์แทน
แบบนั้นเราไม่ต้องบอกใครหรอกว่ามันตีกันยังไง

นั่นเป็นเหตุผลที่จนถึงทุกวันนี้คีย์จึงถูกยกมาใน JSON

...

ECMAScript 5th Edition Standard แก้ไขสิ่งนี้ในการใช้งาน ES5 แม้กระทั่งคำสงวนก็สามารถใช้ได้โดยไม่ต้องใส่เครื่องหมายคำพูดทั้งในตัวอักษร Object และการเข้าถึงของสมาชิก ( obj.functionตกลงใน ES5)

สำหรับการบันทึกมาตรฐานนี้ถูกนำไปใช้ในปัจจุบันโดยผู้จำหน่ายซอฟต์แวร์คุณสามารถดูว่าเบราว์เซอร์ใดรวมคุณลักษณะนี้ไว้ในตารางความเข้ากันได้นี้ (ดูคำสงวนเป็นชื่อคุณสมบัติ )

ใช่ JSON ไม่ถูกต้องและจะถูกปฏิเสธในหลาย ๆ กรณีเช่น jQuery 1.4+ มีการตรวจสอบที่ทำให้ JSON ที่ไม่ได้ใส่เครื่องหมายคำพูดล้มเหลวโดยไม่โต้ตอบ ทำไมไม่ปฏิบัติตาม?

ลองดูอีกตัวอย่าง:

{ myKey: "value" }
{ my-Key: "value" }
{ my-Key[]: "value" }

... สิ่งเหล่านี้จะสามารถใช้งานได้ด้วยคำพูดว่าทำไมไม่ให้สอดคล้องและใช้พวกเขาในทุกกรณีการขจัดความเป็นไปได้ของปัญหาหรือไม่

อีกหนึ่งตัวอย่างที่พบบ่อยในโลกของนักพัฒนาเว็บ: มีตัวอย่างของ HTML ที่ไม่ถูกต้องหลายพันตัวอย่างที่แสดงผลในเบราว์เซอร์ส่วนใหญ่ ... นั่นทำให้การดีบักหรือการดูแลรักษาเจ็บปวดน้อยลงหรือไม่? ไม่เลยตรงกันข้ามทีเดียว

นอกจากนี้ยัง @ แมทธิวทำให้จุดที่ดีที่สุดของทั้งหมดในความคิดเห็นด้านล่างนี้แล้วล้มเหลวคีย์ unquoted จะโยนความผิดพลาดทางไวยากรณ์กับJSON.parse()เบราว์เซอร์ที่สำคัญทั้งหมด (และอื่น ๆ ที่ใช้มันอย่างถูกต้อง) คุณสามารถทดสอบได้ที่นี่

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

YAML คือการสูดอากาศบริสุทธิ์และอาจคุ้มค่ากับเวลาที่คุณจะได้ดู จุดเริ่มต้นที่ดีที่สุดคือhttp://en.wikipedia.org/wiki/YAML

มี libs สำหรับทุกภาษาภายใต้ดวงอาทิตย์รวมถึง JS เช่นhttps://github.com/nodeca/js-yaml