[RFC 홈] [텍스트|PDF|HTML] [추적기] [IPR] [정오표] [정보 페이지]
인터넷
표준
정오표 있음
인터넷 엔지니어링 태스크 포스(IETF) T. Bray, 편집자
의견 요청: 8259 Textuality
폐기 대상: 7159 2017년 12월
범주: 표준 트랙
ISSN: 2070-1721
JavaScript 객체 표기법(JSON) 데이터 교환 형식
초록
JavaScript 객체 표기법(JSON)은 경량의 텍스트 기반이며
언어에 독립적인 데이터 교환 형식입니다. 이는
ECMAScript 프로그래밍 언어 표준에서 파생되었습니다. JSON은 구조화된
데이터를 이식 가능하게 표현하기 위한 소규모의 형식 지정 규칙 집합을 정의합니다.
이 문서는 JSON에 관한 다른 명세와의 불일치를 제거하고,
명세의 오류를 수정하며, 경험에 기반한
상호 운용성 지침을 제공합니다.
이 메모의 상태
이 문서는 인터넷 표준 트랙 문서입니다.
이 문서는 인터넷 엔지니어링 태스크 포스
(IETF)의 산출물입니다. 이는 IETF 커뮤니티의 합의를 나타냅니다. 이 문서는
공개 검토를 거쳤으며 인터넷 엔지니어링 운영 그룹(IESG)의
발행 승인을 받았습니다. 인터넷 표준에 대한 자세한 정보는
RFC 7841의 섹션 2에서 확인할 수 있습니다.
이 문서의 현재 상태, 정오표,
그리고 이에 대한 피드백을 제공하는 방법에 관한 정보는
https://www.rfc-editor.org/info/rfc8259에서 확인할 수 있습니다.
Bray 표준 트랙 [1페이지]
RFC 8259 JSON 2017년 12월
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 표준 트랙 [2페이지]
RFC 8259 JSON 2017년 12월
목차
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 표준 트랙 [3페이지]
RFC 8259 JSON 2017년 12월
"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
명세에서 "JSON text"라는 용어의 정의에
불일치가 없음을 강조하기 위한 것입니다. 다만 ECMA-404는
최대의 상호 운용성을 위해 이 명세에서 피할 것을 권고하는
여러 관행을 허용한다는 점에 유의하십시오.
의도는 서로 다른 설명을 사용하더라도 두 문서의 문법이
동일하도록 하는 것입니다. 두 문서 사이에 차이가
발견되면 ECMA와 IETF는 두 문서를 모두 갱신하기 위해
협력할 것입니다.
어느 한 문서에서 오류가 발견되면 다른 문서에도
유사한 오류가 있는지 확인해야 하며, 그러한 오류가 있다면
가능한 경우 수정해야 합니다.
향후 어느 한 문서가 변경될 경우 ECMA와 IETF는
변경 과정에서 두 문서가 서로 일치하도록
협력할 것입니다.
Bray 표준 트랙 [4페이지]
RFC 8259 JSON 2017년 12월
1.3. 이 개정판 소개
RFC 4627이 발행된 이후 수년 동안 JSON은 매우
널리 사용되었습니다. 이러한 경험을 통해 명세에서는 허용되지만
상호 운용성 문제를 일으킨 특정 패턴이 드러났습니다.
또한 RFC 4627에 관해 소수의 정오표가 보고되었고
(RFC 정오표 ID 607 [Err607] 및 3607 [Err3607] 참조),
RFC 7159에 관해서도 보고되었습니다(RFC 정오표 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 표준 트랙 [5페이지]
RFC 8259 JSON 2017년 12월
중요하지 않은 공백 문자는 여섯 개의
구조 문자 앞이나 뒤에 허용됩니다.
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 표준 트랙 [6페이지]
RFC 8259 JSON 2017년 12월
일부 구현은 중복을 포함하여 모든 이름/값 쌍을
보고합니다.
JSON 파싱 라이브러리는 객체 멤버의 순서를 호출하는
소프트웨어에 노출하는지 여부에서 차이가 있는 것으로
관찰되었습니다. 동작이 멤버
순서에 의존하지 않는 구현은 이러한 차이의 영향을
받지 않는다는 의미에서 상호 운용 가능합니다.
5. 배열
배열 구조는 0개 이상의 값(또는 요소)을 둘러싸는
대괄호로 표현됩니다. 요소는 쉼표로 구분됩니다.
array = begin-array [ value *( value-separator value ) ] end-array
배열 안의 값이 동일한
유형이어야 한다는 요구 사항은 없습니다.
6. 숫자
숫자의 표현은 대부분의
프로그래밍 언어에서 사용하는 방식과 유사합니다. 숫자는
십진 숫자를 사용하여 10진법으로 표현됩니다. 숫자에는 정수 부분이 있으며,
그 앞에는 선택적으로 빼기 기호가 올 수 있고, 뒤에는
소수 부분 및/또는 지수 부분이 올 수 있습니다. 선행 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 표준 트랙 [7페이지]
RFC 8259 JSON 2017년 12월
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)를 제외한 모든 유니코드 문자를 따옴표 안에 넣을 수 있습니다.
모든 문자는 이스케이프할 수 있습니다. 문자가 기본
다국어 평면(U+0000부터 U+FFFF)에 있는 경우
6문자 시퀀스로 표현할 수 있습니다. 즉 역슬래시, 소문자
u, 그리고 해당 문자의 코드 포인트를
인코딩하는 네 개의 16진수가 이어집니다. 16진 문자 A부터
F까지는 대문자 또는 소문자로 사용할 수 있습니다. 예를 들어
하나의 역슬래시 문자만 포함하는 문자열은
"\u005C"로 표현할 수 있습니다.
또는 자주 사용되는 일부 문자는 2문자 시퀀스의
이스케이프 표현을 사용할 수 있습니다. 따라서 예를 들어
하나의 역슬래시 문자만 포함하는 문자열은
더 간결하게 "\\"로 표현할 수 있습니다.
Bray 표준 트랙 [8페이지]
RFC 8259 JSON 2017년 12월
기본 다국어 평면에 없는 확장 문자를
이스케이프하려면 해당 문자를 UTF-16 서로게이트 쌍을 인코딩하는
12문자 시퀀스로 표현합니다. 예를 들어
G 음자리표 문자(U+1D11E)만 포함하는 문자열은
"\uD834\uDD1E"로 표현할 수 있습니다.
string = quotation-mark *char quotation-mark
char = unescaped /
escape (
%x22 / ; " 따옴표 U+0022
%x5C / ; \ 역슬래시 U+005C
%x2F / ; / 슬래시 U+002F
%x62 / ; b 백스페이스 U+0008
%x66 / ; f 폼 피드 U+000C
%x6E / ; n 줄 바꿈 U+000A
%x72 / ; r 캐리지 리턴 U+000D
%x74 / ; t 탭 U+0009
%x75 4HEXDIG ) ; uXXXX U+XXXX
escape = %x5C ; \
quotation-mark = %x22 ; "
unescaped = %x20-21 / %x23-5B / %x5D-10FFFF
8. 문자열 및 문자 관련 문제
8.1. 문자 인코딩
폐쇄형 생태계의 일부가 아닌 시스템 간에 교환되는
JSON 텍스트는 반드시 UTF-8 [RFC3629]을 사용하여 인코딩해야 합니다.
이전 JSON 명세에서는 JSON 텍스트를
전송할 때 UTF-8 사용을 요구하지 않았습니다. 그러나 대다수의
JSON 기반 소프트웨어 구현은 UTF-8 인코딩을 사용하기로
선택했으며, 이제 이는 상호 운용성을 달성하는
유일한 인코딩이라고 할 수 있습니다.
구현은 네트워크로 전송되는 JSON 텍스트의
시작 부분에 바이트 순서 표시(U+FEFF)를 추가해서는 안 됩니다.
상호 운용성을 위해 JSON 텍스트를 파싱하는 구현은
바이트 순서 표시의 존재를 오류로 처리하는 대신
무시할 수 있습니다.
Bray 표준 트랙 [9페이지]
RFC 8259 JSON 2017년 12월
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 표준 트랙 [10페이지]
RFC 8259 JSON 2017년 12월
11. IANA 고려 사항
JSON 텍스트의 미디어 유형은 application/json입니다.
유형 이름: application
하위 유형 이름: json
필수 매개변수: 해당 없음
선택적 매개변수: 해당 없음
인코딩 고려 사항: binary
보안 고려 사항: 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
Macintosh 파일 유형 코드: TEXT
추가 정보를 문의할 사람 및 이메일 주소:
IESG
<iesg@ietf.org>
용도: COMMON
사용 제한: 없음
저자:
Douglas Crockford
<douglas@crockford.com>
변경 관리 기관:
IESG
<iesg@ietf.org>
Bray 표준 트랙 [11페이지]
RFC 8259 JSON 2017년 12월
참고: 이 등록에는 "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 표준 트랙 [12페이지]
RFC 8259 JSON 2017년 12월
다음은 두 개의 객체를 포함하는 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 표준 트랙 [13페이지]
RFC 8259 JSON 2017년 12월
14. 참고 문헌
14.1. 규범적 참고 문헌
[ECMA-404] Ecma International, "JSON 데이터 교환 형식",
표준 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., "ISO 10646의 변환 형식인 UTF-8",
STD 63, RFC 3629, DOI 10.17487/RFC3629, 2003년 11월,
<https://www.rfc-editor.org/info/rfc3629>.
[RFC5234] Crocker, D., 편집자 및 P. Overell, "구문
명세를 위한 확장 BNF: ABNF", 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 언어 명세",
표준 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 표준 트랙 [14페이지]
RFC 8259 JSON 2017년 12월
[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., 편집자, "JavaScript 객체 표기법(JSON) 데이터
교환 형식", RFC 7159, DOI 10.17487/RFC7159, 2014년 3월,
<https://www.rfc-editor.org/info/rfc7159>.
Bray 표준 트랙 [15페이지]
RFC 8259 JSON 2017년 12월
부록 A. RFC 7159에서의 변경 사항
이 절에서는 이 문서와
RFC 7159 텍스트 사이의 변경 사항을 나열합니다.
o 섹션 1.2는 ECMA-262에서 JSON 명세가 제거된 것을
반영하고, 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 표준 트랙 [16페이지]