JSON 구문은 오브젝트에 중복된 키를 허용합니까?
유효한 json입니까?
{
"a" : "x",
"a" : "y"
}
http://jsonlint.com/은 '네'라고 대답합니다.
http://www.json.org/은 그것이 금지되는 것에 대해 아무 말도 하지 않는다.
하지만 분명히 말이 안 되지, 안 그래?대부분의 구현에서는 해시 테이블을 사용하고 있기 때문에 해시 테이블은 덮어씁니다.
★★★★★★★★ 하지 않습니다.아, 아, 아, 아, 아, 아, 아, 아, 아, 아, 아, 아, 아.
긴 :.신신르르
ECMA-404 "JSON Data Interchange Syntax"에서는 중복된 이름(키)에 대해 아무 말도 하지 않습니다.
단, RFC 8259 "JavaScript Object Notation (JSON) Data Interchange Format"에서는 다음과 같이 기술되어 있습니다.
개체 내의 이름은 고유해야 합니다.
이 문맥에서는 BCP 14에 기재된 바와 같이 다음 사항을 이해해야 합니다.
이 단어 또는 형용사 "Recommended"는 특정 상황에서 특정 항목을 무시할 수 있는 타당한 이유가 존재할 수 있지만, 다른 방법을 선택하기 전에 전체 의미를 이해하고 신중하게 평가해야 한다는 것을 의미한다.
RFC 8259 에서는, 일의의 이름(키)이 유효한 이유에 대해 설명합니다.
이름이 모두 고유한 개체는 해당 개체를 수신하는 모든 소프트웨어 구현이 이름 값 매핑에 동의한다는 점에서 상호 운용할 수 있습니다.개체 내의 이름이 고유하지 않은 경우 이러한 개체를 수신하는 소프트웨어의 동작을 예측할 수 없습니다.많은 구현에서는 성/값 쌍만 보고합니다.다른 구현에서는 오류가 보고되거나 개체를 구문 분석하지 못하고 일부 구현에서는 중복을 포함하여 모든 이름과 값의 쌍을 보고합니다.
또, ECMA-262 「ECMAScript®Language Specification」의 코멘트에서 Serguei가 지적한 것처럼, 다음과 같이 되어 있습니다.
오브젝트 내에 중복된 이름 문자열이 있는 경우, 동일한 키의 사전상 선행 값을 덮어씁니다.
즉, 라스트 밸류 와인스입니다.
중복된 이름의 문자열을 Douglas Crockford(JSON 작성자)에 의한 Java 구현으로 해석하려고 하면 예외가 발생합니다.
org.json.JSONException: Duplicate key "status" at
org.json.JSONObject.putOnce(JSONObject.java:1076)
표준에서 (p. ii) :
다른 표준에서는 JSON 텍스트 형식을 엄격하게 준수하면서 다양한 인코딩 세부 사항에 제한을 가하면서 이를 참조할 것으로 예상됩니다.이러한 표준은 특정 행동을 요구할 수 있다.JSON 자체는 동작을 지정하지 않습니다.
표준(p.2)에서 JSON 객체의 사양은 다음과 같습니다.
오브젝트 구조는 0개 이상의 이름/값 쌍을 둘러싼 한 쌍의 컬리 괄호 토큰으로 나타난다.이름은 문자열입니다.각 이름 뒤에 콜론 토큰이 1개씩 붙어 이름과 값이 구분됩니다.단일 쉼표 토큰으로 값과 다음 이름을 구분합니다.
중복된 키가 무효 또는 유효하다는 것은 기재되어 있지 않기 때문에 사양에 따라서는 그것이 허가된 것으로 상정해도 무방합니다.
JSON 라이브러리의 대부분의 구현은 첫 번째 인용문 때문에 표준과 충돌하지 않습니다.
다음은 C++ 표준 라이브러리와 관련된 두 가지 예입니다.를 "JSON"으로 때std::map중복된 키를 거부하는 것이 타당할 것이다., 일부 할때 JSON은 디시리얼라이즈 합니다.std::multimap중복된 키를 정상적으로 받아들이는 것이 타당합니다.
JSON 형식을 지정하는 문서는 다음 2개입니다.
승인된 답변은 첫 번째 문서에서 인용되었습니다.저는 첫 번째 문서가 더 명확하다고 생각하지만, 두 번째 문서가 더 자세한 내용을 담고 있습니다.
두 번째 문서에는 다음과 같이 기술되어 있습니다.
- 물건들
오브젝트 구조는 0개 이상의 이름/값 쌍(또는 멤버)을 둘러싼 한 쌍의 곱슬 괄호로 표시됩니다.이름은 문자열입니다.각 이름 뒤에는 이름과 값을 구분하는 콜론이1개씩 붙습니다.콤마 하나로 다음 이름과 값을 구분합니다.개체 내의 이름은 고유해야 합니다.
그래서 이름이 중복되는 것이 금지되는 것은 아니지만, 그것은 권장되지 않는다.
XML과 JSON을 모두 수용하는 API를 취급할 때 비슷한 질문을 받았습니다만, JSON에서 수용되는 중복 키를 어떻게 처리하는지 문서화하지 않았습니다.
다음으로 샘플 JSON의 유효한 XML 표현을 나타냅니다.
<object>
<a>x</a>
<a>y</a>
</object>
이것을 JSON으로 변환하면, 다음과 같이 됩니다.
{
"object": {
"a": [
"x",
"y"
]
}
}
중복 키를 처리하는 언어에서 다른 언어로의 자연스러운 매핑은 여기에서 잠재적인 베스트 프랙티스 참조가 될 수 있습니다.
그게 도움이 됐으면 좋겠네요!
JSON 사양에는 다음과 같이 기재되어 있습니다.
개체는 이름/값 쌍의 순서가 정렬되지 않은 집합입니다.
여기서 중요한 것은 "순서 없는" 것입니다.이것은 키의 고유성을 의미합니다.특정 쌍을 참조하기 위해 사용할 수 있는 것은 키뿐이기 때문입니다.
또한 대부분의 JSON libs는 해시 맵/사전에 JSON 개체를 역직렬화합니다.여기서 키는 일의로 보증됩니다.중복 키를 사용하여 JSON 개체를 역직렬화하면 발생하는 작업은 라이브러리에 따라 달라집니다.대부분의 경우 오류가 발생하거나 각 중복 키의 마지막 값만 고려됩니다.
를 들어 Python에서는 "Python"이라고 합니다.json.loads('{"a": 1, "a": 2}'){"a": 2}.
기준에 대한 구태의연한 생각과 혼란이 많기 때문에 투고 및 답변.2017년 12월 현재, 두 개의 경쟁 표준이 있습니다.
RFC 8259 - https://www.rfc-editor.org/rfc/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://www.rfc-editor.org/rfc/rfc2119))에 구체적으로 정의되어 있습니다.
- 이 단어 또는 형용사 "Recommended"는 특정 상황에서 특정 항목을 무시할 수 있는 타당한 이유가 존재할 수 있지만, 다른 방법을 선택하기 전에 전체 의미를 이해하고 신중하게 평가해야 한다는 것을 의미한다.
ECMA-404:
"JSON 구문은 이름으로 사용되는 문자열에 어떠한 제한도 가하지 않으며 이름 문자열이 고유할 필요도 없으며 이름/값 쌍의 순서에 어떠한 의미도 부여하지 않습니다."
즉, 어떤 식으로 잘라도 구문적으로 유효한 JSON입니다.
RFC 8259에서 고유 키를 권장하는 이유는 다음과 같습니다.
이름이 모두 고유한 개체는 해당 개체를 수신하는 모든 소프트웨어 구현이 이름 값 매핑에 동의한다는 점에서 상호 운용할 수 있습니다.개체 내의 이름이 고유하지 않은 경우 이러한 개체를 수신하는 소프트웨어의 동작을 예측할 수 없습니다.많은 구현에서는 성/값 쌍만 보고합니다.다른 구현에서는 오류가 보고되거나 개체를 구문 분석하지 못하고 일부 구현에서는 중복을 포함하여 모든 이름과 값의 쌍을 보고합니다.
즉, RFC 8259의 관점에서는 유효하지만, 파서가 토할 가능성이 있어 어떤 값이 그 키와 페어링 될지는 알 수 없습니다.ECMA-404의 관점(개인적으로는 권한이라고 생각합니다)에서는 유효 기간입니다.나에게 이것은 해석하기를 거부하는 파서가 고장났다는 것을 의미합니다.적어도 이 두 가지 표준에 따라 해석해야 합니다.그러나 어떤 경우에도 고유한 키가 환경과 상황에 따라 완전히 달라지며, 처음부터 표준이 되는 것은 없습니다.
고유해야 한다는 것은 고유해야 한다는 뜻이 아닙니다.그러나 앞에서 설명한 바와 같이 일부 파서는 실패하고 다른 파서는 구문 분석된 마지막 값을 사용합니다.그러나 중복을 허용하기 위해 사양을 조금 정리했다면 JSON을 HTML 또는 다른 형식으로 변환하는 이벤트 핸들러를 사용할 수 있습니다.이 경우 JSON을 해석하고 다른 문서 형식을 만드는 것이 완벽하게 유효합니다.
[
"div":
{
"p": "hello",
"p": "universe"
},
"div":
{
"h1": "Heading 1",
"p": "another paragraph"
}
]
그러면 다음과 같이 쉽게 해석할 수 있습니다.
<body>
<div>
<p>hello</p>
<p>universe</p>
</div>
<div>
<h1>Heading 1</h1>
<p>another paragraph</p>
</div>
</body>
질문의 배경은 알겠지만 현재 상태로는...믿을 수 없어요.
ECMA JSON 표준에는 정의되어 있지 않습니다.그리고 일반적으로 표준에서 정의가 부족하다는 것은 "어디서나 같은 방식으로 작동한다고 기대하지 마세요."를 의미합니다.
도박꾼이라면 "다수의" JSON 엔진을 사용하면 복제가 가능하며 마지막으로 지정한 값을 사용할 수 있습니다.이것은, 다음과 같습니다.
var o = {"a": 1, "b": 2, "a": 3}
다음과 같이 됩니다.
Object {a: 3, b: 2}
하지만 도박꾼이 아니라면 기대하지 마세요!
목적을 묻는 질문에는 다양한 답변이 있습니다.
JSON을 사용하여 오브젝트(JavaScriptObjectNotation)를 시리얼화하면 각 딕셔너리 요소는 개별 오브젝트 속성에 매핑되므로 같은 속성의 값을 정의하는 다른 엔트리는 의미가 없습니다.
그러나 매우 구체적인 사용 사례에서 동일한 질문을 받았습니다.API 테스트용 JSON 샘플을 작성하면서 사용성을 해치지 않고 JSON 파일에 코멘트를 추가할 수 있는 방법을 고민했습니다.JSON 사양에서는 코멘트를 알 수 없기 때문에 매우 심플한 어프로치를 생각해 냈습니다.
중복된 키를 사용하여 JSON 샘플을 코멘트합니다.예:
{ "property1" : "value1", "REMARK" : "... prop1 controls ...", "property2" : "value2", "REMARK" : "... value2 raises an exception ...", }
우리가 사용하고 있는 JSON 시리얼라이저는 이러한 "리마크" 복제에 문제가 없으며, 우리의 애플리케이션 코드는 이 약간의 오버헤드를 무시할 뿐입니다.
따라서 애플리케이션 계층에 아무런 의미가 없는 경우에도 이러한 복제는 JSON의 유용성을 해치지 않고 테스트 샘플에 주석을 추가할 수 있는 유용한 해결 방법을 제공합니다.
표준에는 다음과 같이 기술되어 있습니다.
프로그래밍 언어는 개체를 지원하는지 여부와 지원하는 경우 개체가 제공하는 특성과 제약 조건에 따라 크게 다릅니다.객체 시스템의 모델은 크게 다를 수 있으며 계속해서 진화하고 있습니다.대신 JSON은 이름/값 쌍의 컬렉션을 표현하기 위한 간단한 표기법을 제공합니다.대부분의 프로그래밍 언어에는 레코드, 구조, 딕트, 맵, 해시 또는 오브젝트와 같은 이름으로 사용되는 컬렉션을 나타내는 기능이 있습니다.
이 버그는 적어도 node.js에 있습니다.이 코드는 node.js에서 성공합니다.
try {
var json = {"name":"n","name":"v"};
console.log(json); // outputs { name: 'v' }
} catch (e) {
console.log(e);
}
RFC-7159에 따르면 Internet Engineering Task Force(IETF; 인터넷 기술 특별 조사위원회)에 의해 공표된 JSON의 현재 표준에는 "객체 내의 이름은 고유해야 한다"고 명시되어 있습니다.그러나 IETF 문서에서 사용되는 용어를 정의하는 RFC-2119에 따르면 실제로는 "해야 한다"는 말은 "...특정 상황에서 특정 항목을 무시해야 하는 타당한 이유가 존재할 수 있지만 다른 경로를 선택하기 전에 모든 의미를 이해하고 신중하게 평가해야 한다"는 의미입니다.즉, 고유한 키를 사용하는 것이 권장되지만 반드시 필요한 것은 아닙니다.JSON 개체에는 중복된 키가 있을 수 있으며, 여전히 유효합니다.
JSON에서 중복 키가 발견되었을 때 마지막 키의 값이 고려되는 것을 실용적으로 보았습니다.
에서는, C# 로의하면,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★★★★★★ 。
언급URL : https://stackoverflow.com/questions/21832701/does-json-syntax-allow-duplicate-keys-in-an-object
'programing' 카테고리의 다른 글
| http에서 JSON 응답을 얻는 방법.얻다 (0) | 2023.03.13 |
|---|---|
| SQL에서 JSON으로 - SQL 2016에서 객체 배열에서 값 배열로 (0) | 2023.03.13 |
| 서비스 데이터 변경 시 범위 값 업데이트 (0) | 2023.03.13 |
| Type Script:중복 식별자 'IteratorResult' (0) | 2023.03.13 |
| JavaScript의 Json 데이터에서 백슬래시 제거 (0) | 2023.03.13 |