[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]
INTERNET STANDARD
Errata ExistInternet Engineering Task Force (IETF) T. Bray, Ed.
Request for Comments: 8259 Textuality
Obsoletes: 7159 December 2017
Category: Standards Track
ISSN: 2070-1721
자바스크립트 객체 표기법(JSON) 데이터 교환 형식
요약
자바스크립트 객체 표기법(JSON)은 가볍고, 텍스트 기반이며, 언어에 독립적인 데이터 교환 형식입니다.
ECMAScript 프로그래밍 언어 표준에서 파생되었습니다.
JSON은 구조화된 데이터를 이식 가능하게 표현하기 위한 소수의 포맷 규칙을 정의합니다.
본 문서는 JSON의 다른 명세와의 불일치를 제거하고, 명세 오류를 수정하며, 경험에 기반한 상호운용성 안내를 제공합니다.
이 문서의 상태
이 문서는 인터넷 표준화 단계 문서입니다.
이 문서는 인터넷 엔지니어링 태스크 포스(IETF)의 산출물입니다.
IETF 커뮤니티의 합의를 반영하고 있으며, 공개 검토를 받았고 인터넷 엔지니어링 지명 그룹(IESG)의 승인을 통해 게시가 허용되었습니다.
인터넷 표준에 대한 추가 정보는 RFC 7841의 섹션 2에서 확인할 수 있습니다.
이 문서의 최신 상태, 정정 사항, 피드백 제공 방법 등은
https://www.rfc-editor.org/info/rfc8259에서 확인할 수 있습니다.
Bray Standards Track [Page 1]
RFC 8259 JSON December 2017
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Bray Standards Track [Page 2]
RFC 8259 JSON December 2017
목차
1. 소개 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. 이 문서에서 사용된 관례 . . . . . . . . . . . . . . 4
1.2. JSON의 명세 . . . . . . . . . . . . . . . . . . 4
1.3. 이 개정판의 소개 . . . . . . . . . . . . . . . 5
2. JSON 문법 . . . . . . . . . . . . . . . . . . . . . 5
3. 값 . . . . . . . . . . . . . . . . . . . . . . . . 6
4. 객체 . . . . . . . . . . . . . . . . . . . . . . . 6
5. 배열 . . . . . . . . . . . . . . . . . . . . . . . 7
6. 숫자 . . . . . . . . . . . . . . . . . . . . . . . 7
7. 문자열 . . . . . . . . . . . . . . . . . . . . . . 8
8. 문자열 및 문자 관련 사항 . . . . . . . . . . . . . 9
8.1. 문자 인코딩 . . . . . . . . . . . . . . . . . 9
8.2. 유니코드 문자 . . . . . . . . . . . . . . . . 10
8.3. 문자열 비교 . . . . . . . . . . . . . . . . . 10
9. 파서 . . . . . . . . . . . . . . . . . . . . . . . 10
10. 생성기 . . . . . . . . . . . . . . . . . . . . . . 10
11. IANA 고려사항 . . . . . . . . . . . . . . . . . . . 11
12. 보안 고려사항 . . . . . . . . . . . . . . . . . . . 12
13. 예시 . . . . . . . . . . . . . . . . . . . . . . . 12
14. 참고문헌 . . . . . . . . . . . . . . . . . . . . . 14
14.1. 표준 참고문헌 . . . . . . . . . . . . . . . 14
14.2. 참고용 참고문헌 . . . . . . . . . . . . . . . 14
부록 A. RFC 7159과의 변경점 . . . . . . . . . . . . . . . 16
기여자 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
저자 주소 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. 소개
JavaScript 객체 표기법(JSON)은 구조화된 데이터를 직렬화하기 위한 텍스트 형식입니다.
이는 ECMAScript 프로그래밍 언어 표준 3판 [ECMA-262]에서 정의된 JavaScript의 객체 리터럴에서 파생되었습니다.
JSON은 네 가지 원시 타입(문자열, 숫자, 불리언, null)과 두 가지 구조적 타입(객체, 배열)을 표현할 수 있습니다.
문자열은 0개 이상의 유니코드 문자 [UNICODE]로 이루어진 일련의 문자입니다.
이 인용문은 특정 버전이 아닌 최신 유니코드 버전을 참조합니다.
앞으로의 유니코드 명세 변경이 JSON의 문법에 영향을 미칠 것이라 기대하지 않습니다.
객체는 0개 이상의 이름/값 쌍의 순서 없는 모음입니다. 여기서 이름은 문자열이며, 값은 문자열, 숫자, 불리언, null, 객체, 배열이 될 수 있습니다.
배열은 0개 이상의 값으로 이루어진 순서가 있는 시퀀스입니다.
Bray Standards Track [Page 3]
RFC 8259 JSON December 2017
"object"와 "array"라는 용어는 JavaScript의 관례에서 유래되었습니다.
JSON의 설계 목표는 최소화, 이식성, 텍스트 기반, 그리고 JavaScript의 부분집합이 되는 것이었습니다.
1.1. 이 문서에서 사용된 관례
이 문서에서 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "OPTIONAL"과 같은 주요 용어들은 BCP
14 [RFC2119] [RFC8174]에서 설명된 대로, 오직 이와 같이 모두 대문자로 나타날 때에만 해석되어야 합니다.
이 문서의 문법 규칙은 [RFC5234]에 설명된 대로 해석되어야 합니다.
1.2. JSON의 명세
이 문서는 [RFC7159]를 대체합니다. [RFC7159]는 최초로 JSON을 설명하고 미디어 타입 "application/json"을 등록했던 [RFC4627]을 폐기하였습니다.
JSON은 [ECMA-404]에서도 설명되어 있습니다.
앞서 언급한 ECMA-404에 대한 참조는 규범적인 것인데, 구현자가 이 문서를 이해하기 위해 반드시 참조해야 한다는 일반적인 의미가 아니라,
어떤 명세에서도 "JSON text"라는 용어의 정의에 불일치가 없다는 것을 강조하기 위함입니다. 다만, ECMA-404는 상호운용성을 극대화하기 위해 이 명세에서 피할 것을 권장하는 여러 관행을 허용하고 있음을 유의하십시오.
두 문서 간에 문법은 동일하게 유지되는 것이 목적이지만, 다른 방식으로 설명하고 있을 수 있습니다. 차이점이 발견된다면 ECMA와 IETF가 협력하여 두 문서를 모두 수정할 것입니다.
어느 한 문서에서 오류를 발견하면, 다른 문서에도 유사 오류가 있는지 확인해야 하며, 있다면 가능한 한 수정해야 합니다.
두 문서 중 어느 하나가 미래에 변경될 경우, ECMA와 IETF는 두 문서가 변경 후에도 일치하도록 협력할 것입니다.
Bray Standards Track [Page 4]
RFC 8259 JSON December 2017
1.3. 이번 개정판 소개
RFC 4627이 발표된 이후로 수년 동안 JSON은 매우 널리 사용되어 왔습니다. 이러한 경험을 통해, 명세상 허용되지만 상호 운용성 문제를 유발한 특정 패턴들이 드러났습니다.
또한, RFC 4627 관련으로 소수의 정오표가 보고되었고(RFC Errata ID 607 [Err607] 및 3607 [Err3607] 참조), RFC 7159 관련으로도 보고되었습니다(RFC Errata ID 3915 [Err3915], 4264 [Err4264], 4336 [Err4336], 4388 [Err4388] 참조).
이 문서의 목적은 정오표를 반영하고, JSON의 다른 명세와의 불일치를 해소하며, 상호 운용성 문제를 유발할 수 있는 관행을 강조하는 데 있습니다.
2. JSON 문법
JSON 텍스트는 토큰의 시퀀스입니다. 토큰 집합에는 여섯 개의 구조적 문자, 문자열, 숫자, 그리고 세 가지 리터럴 이름이 포함됩니다.
JSON 텍스트는 직렬화된 값입니다. 일부 이전 JSON 명세에서는 JSON 텍스트가 객체 또는 배열로 제한되었습니다.
JSON 텍스트가 필요한 상황에서 객체나 배열만 생성하는 구현체들은 모든 구현체에서 이를 올바른 JSON 텍스트로 인정하기 때문에 상호 운용성에 문제가 없습니다.
JSON-text = ws value ws
다음은 여섯 개의 구조적 문자입니다:
begin-array = ws %x5B ws ; [ 왼쪽 대괄호
begin-object = ws %x7B ws ; { 왼쪽 중괄호
end-array = ws %x5D ws ; ] 오른쪽 대괄호
end-object = ws %x7D ws ; } 오른쪽 중괄호
name-separator = ws %x3A ws ; : 콜론
value-separator = ws %x2C ws ; , 쉼표
Bray Standards Track [Page 5]
RFC 8259 JSON December 2017
여섯 개의 구조적 문자 중 어느 것의 앞이나 뒤에도 의미 없는 공백이 허용됩니다.
ws = *(
%x20 / ; 스페이스(공백)
%x09 / ; 수평 탭
%x0A / ; 줄 바꿈 또는 새 줄
%x0D ) ; 캐리지 리턴
3. 값
JSON 값은 반드시 객체, 배열, 숫자, 문자열, 혹은 다음 세 가지 리터럴 이름 중 하나여야 합니다:
false
null
true
리터럴 이름은 반드시 소문자여야 합니다. 다른 리터럴 이름은 허용되지 않습니다.
value = false / null / true / object / array / number / string
false = %x66.61.6c.73.65 ; false
null = %x6e.75.6c.6c ; null
true = %x74.72.75.65 ; true
4. 객체
객체 구조는 0개 이상의 이름/값 쌍(멤버)을 중괄호 쌍으로 감싸서 표현합니다. 이름은 문자열입니다.
각 이름 뒤에는 콜론이 하나 오며, 이는 이름과 값을 구분합니다. 값과 그 다음 이름은 쉼표 하나로 구분합니다. 객체 내의 이름들은 고유해야 합니다.
object = begin-object [ member *( value-separator member ) ]
end-object
member = string name-separator value
객체의 이름들이 모두 고유할 경우, 모든 소프트웨어 구현체가 해당 객체의 이름-값 매핑에 일관되게 동의하므로 상호운용성이 보장됩니다.
객체 내에 중복된 이름이 있을 경우, 해당 객체를 받은 소프트웨어의 동작은 예측할 수 없습니다. 많은 구현체는 마지막 이름/값 쌍만을 사용합니다.
다른 구현체는 오류를 보고하거나 파싱에 실패할 수 있습니다.
Bray Standards Track [Page 6]
RFC 8259 JSON December 2017
object의 이름/값 쌍에 중복이 있을 경우, 일부 구현체는 모든 이름/값 쌍(중복 포함)을 반환하기도 합니다.
JSON 파싱 라이브러리마다 객체 멤버의 순서를 호출하는 소프트웨어에 노출할지 여부에 차이가 있음이 관찰되었습니다.
멤버 순서에 따라 동작하지 않는 구현체는 이러한 차이점의 영향을 받지 않으므로 상호운용성이 보장됩니다.
5. 배열
배열 구조는 0개 이상의 값(또는 요소)을 대괄호로 감싸어 표현합니다. 요소들은 쉼표로 구분됩니다.
array = begin-array [ value *( value-separator value ) ] end-array
배열 내의 값들이 동일한 타입일 필요는 없습니다.
6. 숫자
숫자의 표기는 대부분의 프로그래밍 언어와 유사합니다. 숫자는 십진수로 표기되며, 정수 부분 앞에 선택적으로 마이너스 기호가 올 수 있고,
그 뒤에 소수 부분이나 지수 부분이 올 수 있습니다. 숫자 앞에 0이 여러 개 올 수는 없습니다.
소수 부분은 소수점 뒤에 하나 이상의 숫자가 따라오는 형태입니다.
지수 부분은 대문자 혹은 소문자 E로 시작하며, 그 뒤에 플러스 또는 마이너스 기호가 있을 수 있습니다. E와 기호 뒤에는 하나 이상의 숫자가 추가됩니다.
아래 문법으로 표현할 수 없는 수치 값(예: Infinity, NaN 등)은 허용되지 않습니다.
number = [ minus ] int [ frac ] [ exp ]
decimal-point = %x2E ; .
digit1-9 = %x31-39 ; 1-9
e = %x65 / %x45 ; e E
exp = e [ minus / plus ] 1*DIGIT
frac = decimal-point 1*DIGIT
Bray Standards Track [Page 7]
RFC 8259 JSON December 2017
int = zero / ( digit1-9 *DIGIT )
minus = %x2D ; -
plus = %x2B ; +
zero = %x30 ; 0
이 명세에서는 구현체가 허용하는 숫자의 범위와 정밀도에 제한을 둘 수 있도록 허용합니다.
IEEE 754 binary64(배정도) 숫자를 구현하는 소프트웨어 [IEEE754]는 일반적으로 널리 사용 가능하므로,
이러한 소프트웨어의 정밀도나 범위를 넘지 않는 구현체는 JSON 숫자를 예상되는 정밀도 내에서 근사하여 처리함으로써 높은 상호운용성을 얻을 수 있습니다.
예를 들어, 1E400이나 3.141592653589793238462643383279와 같은 JSON 숫자는, 이를 생성한 소프트웨어가 수신측 소프트웨어가 흔히 제공하지 않는 더 큰
숫자 크기와 정밀도를 다룰 수 있으리라 기대한다는 점에서 상호운용성 문제를 시사할 수 있습니다.
이와 같은 소프트웨어가 사용될 때, 정수이면서 범위가 [-(2**53)+1, (2**53)-1]에 속하는 숫자는 모든 구현체가 그 수치 값을 정확하게 일치시킨다는 의미에서 상호운용성이 있습니다.
7. 문자열
문자열의 표기는 C 계열 프로그래밍 언어의 관례와 유사합니다. 문자열은 큰따옴표로 시작하고 끝납니다. 큰따옴표, 역슬래시,
제어 문자(U+0000부터 U+001F까지)를 제외한 모든 유니코드 문자를 따옴표 안에 넣을 수 있습니다. 이 문자들은 반드시 이스케이프되어야 합니다.
모든 문자는 이스케이프될 수 있습니다. 문자가 기본 다국어 평면(BMP, U+0000~U+FFFF)에 있으면 6글자 시퀀스로 표현할 수 있습니다: 역슬래시, 소문자 u,
그리고 해당 문자 코드포인트를 나타내는 4자리 16진수입니다. 16진수 문자의 A~F는 대소문자를 구분하지 않습니다.
예를 들어, 역슬래시 하나만 포함된 문자열은 "\u005C"로 표현할 수 있습니다.
그 밖에도, 일부 일반적인 문자에 대해서는 두 글자 시퀀스로 이스케이프하는 방법이 있습니다. 예를 들어,
역슬래시 하나만 포함된 문자열은 "\\"와 같이 더 간단히 표현할 수 있습니다.
Bray Standards Track [Page 8]
RFC 8259 JSON December 2017
기본 다국어 평면(BMP)에 포함되지 않은 확장 문자를 이스케이프하려면, 해당 문자를 UTF-16 서러게이트 쌍으로 인코딩한 12자 시퀀스로 표현해야 합니다.
예를 들어, 트레블 음자리표 문자(U+1D11E)만 포함된 문자열은 "\uD834\uDD1E"로 표현할 수 있습니다.
8. 문자열 및 문자 관련 사항
8.1. 문자 인코딩
폐쇄적 생태계에 속하지 않은 시스템들 간에 교환되는 JSON 텍스트는 반드시 UTF-8 [RFC3629]로 인코딩되어야 합니다.
이전 JSON 명세에서는 JSON 텍스트 전송 시 UTF-8 사용이 필수는 아니었습니다. 그러나 실제로 거의 모든 JSON 기반 소프트웨어 구현에서 UTF-8 인코딩을 사용하였으며,
사실상 유일하게 상호운용이 가능한 인코딩으로 자리잡았습니다.
구현체는 네트워크로 전송되는 JSON 텍스트의 시작에 바이트 순서 표시(BOM, U+FEFF)를 추가해서는 안 됩니다. 상호운용성을 위해,
JSON 텍스트를 파싱하는 구현체는 BOM의 존재를 오류로 처리하기보다는 무시할 수 있습니다.
Bray Standards Track [Page 9]
RFC 8259 JSON December 2017
8.2. 유니코드 문자
JSON 텍스트에 포함된 모든 문자열이 완전히 유니코드 문자 [UNICODE]로만 구성되어 있다면(이스케이프 여부와 관계없이),
해당 JSON 텍스트는 모든 파싱 소프트웨어가 객체와 배열 내의 이름과 문자열 값의 내용을 일치하게 해석하므로 상호운용성이 있습니다.
그러나, 이 명세의 ABNF는 멤버 이름과 문자열 값에 유니코드 문자를 인코딩할 수 없는 비트 시퀀스도 허용합니다.
예를 들어 "\uDEAD"(쌍을 이루지 않는 단일 UTF-16 서러게이트)와 같은 경우입니다. 예시로,
어떤 라이브러리가 UTF-16 문자열을 쌍을 이루는지 확인하지 않고 잘라냈을 때 이런 사례가 관찰된 적이 있습니다.
이러한 값을 포함한 JSON 텍스트를 받는 소프트웨어의 동작은 예측할 수 없습니다. 예를 들어,
구현에 따라 문자열 값의 길이를 다르게 반환하거나 심할 경우 치명적인 런타임 예외가 발생할 수 있습니다.
8.3. 문자열 비교
소프트웨어 구현체는 보통 객체 멤버의 이름이 같은지 비교해야 합니다. 텍스트 표현을 유니코드 코드 유닛의 시퀀스로 변환한 후,
코드 유닛 단위로 수치적으로 비교하는 구현체는 항상 두 문자열의 동일성 여부를 일치하게 판단하므로 상호운용성이 보장됩니다.
예를 들어, 이스케이프된 문자가 변환되지 않은 상태로 문자열을 비교하는 구현체는 "a\\b"와 "a\u005Cb"가 같지 않다고 잘못 판단할 수 있습니다.
9. 파서
JSON 파서는 JSON 텍스트를 다른 표현으로 변환합니다. JSON 파서는 JSON 문법에 맞는 모든 텍스트를 반드시 허용해야 합니다.
또한, JSON 파서는 비표준 JSON 형식이나 확장 형식도 허용할 수 있습니다.
구현체는 허용하는 텍스트의 크기에 제한을 둘 수 있습니다. 최대 중첩 깊이에도 제한을 둘 수 있습니다.
숫자의 범위와 정밀도에 제한을 둘 수 있습니다. 문자열의 길이와 문자 내용에도 제한을 둘 수 있습니다.
10. 생성기
JSON 생성기는 JSON 텍스트를 만듭니다. 생성된 텍스트는 반드시 JSON 문법을 엄격히 따라야 합니다.
Bray Standards Track [Page 10]
RFC 8259 JSON December 2017
11. IANA 고려 사항
JSON 텍스트의 미디어 타입은 application/json입니다.
타입 이름: application
서브타입 이름: json
필수 파라미터: 해당 없음
선택적 파라미터: 해당 없음
인코딩 고려사항: 바이너리
보안 고려사항: RFC 8259, 섹션 12 참조
상호운용성 고려사항: RFC 8259에 설명됨
공식 명세: RFC 8259
이 미디어 타입을 사용하는 애플리케이션:
JSON은 ActionScript, C, C#, Clojure, ColdFusion, Common Lisp, E, Erlang, Go, Java, JavaScript,
Lua, Objective CAML, Perl, PHP, Python, Rebol, Ruby, Scala, Scheme 등 모든 프로그래밍 언어로 작성된
애플리케이션 간 데이터 교환에 사용되고 있습니다.
추가 정보:
매직 번호: 해당 없음
파일 확장자: .json
매킨토시 파일 타입 코드: TEXT
추가 정보 문의처:
IESG
<iesg@ietf.org>
의도된 사용: 일반적(COMMON)
사용 제한: 없음
작성자:
Douglas Crockford
<douglas@crockford.com>
변경 관리기관:
IESG
<iesg@ietf.org>
Bray Standards Track [Page 11]
RFC 8259 JSON December 2017
참고: 이 등록에는 "charset" 매개변수가 정의되어 있지 않습니다.
이를 추가해도 규격을 준수하는 수신자에게는 아무런 효과가 없습니다.
12. 보안 고려사항
일반적으로 스크립트 언어에는 보안 문제가 존재합니다. JSON은 JavaScript의 부분집합이지만, 할당과 호출은 제외됩니다.
JSON의 문법은 JavaScript에서 차용되었으므로, 이 언어의 "eval()" 함수를 사용해 대부분의 JSON 텍스트를 파싱하는 것이 가능합니다
(하지만 모두 그런 것은 아니며, U+2028 LINE SEPARATOR와 U+2029 PARAGRAPH SEPARATOR처럼 JSON에는 허용되지만 JavaScript에는 허용되지 않는 문자가 있습니다).
일반적으로 이것은 허용될 수 없는 보안 위험이 되는데, 텍스트 안에 데이터 선언과 함께 실행 가능한 코드가 포함될 수 있기 때문입니다.
동일한 문제는 JSON 텍스트가 해당 언어의 문법에 일치하는 다른 프로그래밍 언어에서 eval()과 유사한 함수를 사용할 때에도 적용됩니다.
13. 예시
이것은 JSON 객체입니다:
{
"Image": {
"Width": 800,
"Height": 600,
"Title": "View from 15th Floor",
"Thumbnail": {
"Url": "http://www.example.com/image/481989943",
"Height": 125,
"Width": 100
},
"Animated" : false,
"IDs": [116, 943, 234, 38793]
}
}
이 객체의 Image 멤버는 Thumbnail 멤버가 객체이고 IDs 멤버가 숫자 배열인 객체입니다.
Bray Standards Track [Page 12]
RFC 8259 JSON December 2017
이것은 두 개의 객체를 포함하는 JSON 배열입니다:
[
{
"precision": "zip",
"Latitude": 37.7668,
"Longitude": -122.3959,
"Address": "",
"City": "SAN FRANCISCO",
"State": "CA",
"Zip": "94107",
"Country": "US"
},
{
"precision": "zip",
"Latitude": 37.371991,
"Longitude": -122.026020,
"Address": "",
"City": "SUNNYVALE",
"State": "CA",
"Zip": "94085",
"Country": "US"
}
]
다음은 값만 포함된 세 개의 작은 JSON 텍스트입니다:
"Hello world!"
42
true
Bray Standards Track [Page 13]
RFC 8259 JSON December 2017
14. 참고문헌
14.1. 규범적 참고문헌
[ECMA-404] Ecma International, "JSON 데이터 교환 형식",
Standard ECMA-404,
<http://www.ecma-international.org/publications/
standards/Ecma-404.htm>.
[IEEE754] IEEE, "부동소수점 산술 연산을 위한 IEEE 표준",
IEEE 754.
[RFC2119] Bradner, S., "RFC에서 요구 수준을 나타내는 키워드 사용",
BCP 14, RFC 2119,
DOI 10.17487/RFC2119, 1997년 3월,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, ISO 10646의 변환 포맷", STD 63, RFC 3629, DOI 10.17487/RFC3629, 2003년 11월,
<https://www.rfc-editor.org/info/rfc3629>.
[RFC5234] Crocker, D., Ed. 및 P. Overell, "ABNF: 문법 명세를 위한 확장 BNF",
STD 68, RFC 5234,
DOI 10.17487/RFC5234, 2008년 1월,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC8174] Leiba, B., "RFC 2119 키워드의 대소문자 모호성",
BCP 14, RFC 8174, DOI 10.17487/RFC8174,
2017년 5월, <https://www.rfc-editor.org/info/rfc8174>.
[UNICODE] The Unicode Consortium, "유니코드 표준",
<http://www.unicode.org/versions/latest/>.
14.2. 참고용 참고문헌
[ECMA-262] Ecma International, "ECMAScript 언어 명세",
Standard ECMA-262, 3판, 1999년 12월,
<http://www.ecma-international.org/publications/files/
ECMA-ST-ARCH/
ECMA-262,%203rd%20edition,%20December%201999.pdf>.
[Err3607] RFC 정오표, 정오표 ID 3607, RFC 4627,
<https://www.rfc-editor.org/errata/eid3607>.
[Err3915] RFC 정오표, 정오표 ID 3915, RFC 7159,
<https://www.rfc-editor.org/errata/eid3915>.
Bray Standards Track [Page 14]
RFC 8259 JSON December 2017
[Err4264] RFC 정오표, 정오표 ID 4264, RFC 7159,
<https://www.rfc-editor.org/errata/eid4264>.
[Err4336] RFC 정오표, 정오표 ID 4336, RFC 7159,
<https://www.rfc-editor.org/errata/eid4336>.
[Err4388] RFC 정오표, 정오표 ID 4388, RFC 7159,
<https://www.rfc-editor.org/errata/eid4388>.
[Err607] RFC 정오표, 정오표 ID 607, RFC 4627,
<https://www.rfc-editor.org/errata/eid607>.
[RFC4627] Crockford, D., "JavaScript 객체 표기법(JSON)을 위한 application/json 미디어 타입", RFC 4627,
DOI 10.17487/RFC4627, 2006년 7월,
<https://www.rfc-editor.org/info/rfc4627>.
[RFC7159] Bray, T., Ed., "자바스크립트 객체 표기법(JSON) 데이터 교환 형식", RFC 7159, DOI 10.17487/RFC7159, 2014년 3월,
<https://www.rfc-editor.org/info/rfc7159>.
Bray Standards Track [Page 15]
RFC 8259 JSON December 2017
부록 A. RFC 7159과의 변경점
이 절에서는 본 문서와 RFC 7159 본문 간의 변경 사항을 나열합니다.
o 섹션 1.2는 JSON 명세가 ECMA-262에서 제거된 사실을 반영하고, ECMA-404를 규범적 참고문헌으로 설정하며, "규범적"이라는 용어의 특별한 의미를 설명하도록 갱신되었습니다.
o 섹션 1.3은 RFC 4627가 아닌 RFC 7159에 접수된 정오표를 반영하도록 갱신되었습니다.
o 섹션 8.1은 네트워크 상에서 전송될 때 반드시 UTF-8을 사용하도록 변경되었습니다.
o 섹션 12는 ECMAScript "eval()" 함수 사용에 따른 보안 위험에 관한 설명의 정확성을 높이기 위해 갱신되었습니다.
o 섹션 14.1은 ECMA-404를 규범적 참고문헌으로 포함하도록 갱신되었습니다.
o 섹션 14.2는 ECMA-404를 제거하고, ECMA-262 버전을 업데이트하며, 정오표 목록을 최신화하였습니다.
기여자
RFC 4627은 Douglas Crockford가 작성하였습니다. 본 문서는 해당 문서에 비교적 적은 수의 변경만을 가하여 작성된 것이므로, 이곳에 있는 대부분의 본문 역시 그의 작품입니다.
저자 주소
Tim Bray (편집자)
Textuality
이메일: tbray@textuality.com
Bray Standards Track [Page 16]