속성-값 쌍으로 구성됩니다. 이는 브라우저와 서버 간의 비동기 통신에 사용되는 가장 일반적인 데이터 형식으로, 주로 XML(AJAX 사용)을 대체합니다.
JSON은 JavaScript에서 파생된 언어 독립적인 데이터 형식입니다. 2017년부터 많은 프로그래밍 언어는 코드를 사용하여 그 안에서만 데이터를 생성하고 분석합니다. JSON 파일 이름은 .json 확장자를 사용합니다.
창조의 역사 JSON 형식은 원래 2000년대 초반 Douglas Crockford가 개발했으며 이후 2013년에 두 가지 경쟁 표준(RFC 7159 및 ECMA-404)에 의해 정의되었습니다. ECMA 표준은 유효한 구문만 설명하는 반면 RFC는 몇 가지 기본적인 보안 및 상호 운용성을 다룹니다.
또한 I-JSON("Internet JSON"의 약어)이라는 제한된 프로필을 정의하는 RFC 7493이라는 표준이 있습니다. 일부 상호 운용성 문제를 극복하려고 합니다. 이러한 각 문서는 유효한 JSON 문서입니다.
이 형식을 생성해야 하는 필요성은 플러그인(예: Flash 또는 Java 애플릿)을 사용하지 않고 실시간으로 수행되는 서버와 브라우저 간의 실제 통신 프로토콜에 대한 필요성에서 비롯되었습니다.
개발 및 적용 이미 언급했듯이 StateSoftware 회사의 창시자인 Douglas Crockford는 JSON 형식을 처음으로 식별하고 대중화했습니다. 이후 공동 창립자들은 표준 브라우저 기능을 사용하고 개발자가 웹 서버에 대한 지속적인 전이중 연결을 통해 애플리케이션을 만들 수 있도록 추상화 계층을 제공하는 시스템을 만드는 데 동의했습니다. 동시에 두 개의 HTTP 연결을 열어두고 데이터가 교환되지 않으면 표준 브라우저 작동 시간까지 이를 처리하는 것이 가능해졌습니다. 공동 창립자들은 원탁 토론을 열고 데이터 형식의 이름을 JSML 또는 JSON으로 지정하고 새로운 개발을 사용할 수 있는 라이센스 유형을 결정하기로 투표했습니다. 형식은 현재 오픈 소스입니다.
실제 사용 JSON.org 웹사이트는 2002년에 출시되었습니다. 2005년 12월, 야후! 이 형식으로 일부 웹 서비스를 제공하기 시작했습니다. Google은 2006년 12월부터 GData 웹 프로토콜에 JSON 피드를 사용하기 시작했습니다.
JSON 파일 형식은 원래 JavaScript 스크립팅 언어(특히 Standard ECMA-262 3rd Edition-December)의 하위 집합과 함께 사용되도록 의도되었으며 일반적으로 사용되었습니다. 그러나 이는 데이터 언어 독립적인 형식입니다. JSON 데이터를 구문 분석하고 생성하는 코드는 다양한 프로그래밍 언어로 제공됩니다. JSON 웹사이트에는 모든 라이브러리가 나열되어 있습니다.
JSON 온라인은 원래 JavaScript 및 ECMAScript의 엄격한 하위 집합으로 승격되었으며 JavaScript 및 ECMAScript 문자열에서 허용되지 않는 문자열에서 이스케이프되지 않은 일부 문자를 주기적으로 허용합니다.
JSON 자체는 2013년 ECMA-404 표준으로 국제 ECMA 표준이 되었으며, 같은 해 RFC 7158에서 참조로 사용되었습니다. 2014년에 RFC 7159는 인터넷(예: MIME 애플리케이션/json)에서 JSON 사용에 대한 기본 참조가 되었습니다.
데이터 유형, 구문 및 예 주요 JSON 데이터 유형은 다음과 같습니다.
- 숫자: 소수 부분을 포함할 수 있고 지수 E 표기법을 사용할 수 있지만 숫자가 아닌 숫자(예: NaN)는 포함할 수 없는 부호 있는 10진수입니다. 형식은 정수와 부동 소수점 숫자를 구분하지 않습니다. JavaScript는 모든 숫자 값에 배정밀도 부동 소수점 형식을 사용하지만 JSON을 구현하는 다른 언어에서는 이를 다르게 인코딩할 수 있습니다.
- 문자열: 0개 또는 큰 유니코드 문자의 시퀀스입니다. 문자열은 큰따옴표로 구분되며 백슬래시 구문을 지원합니다.
- 리터럴: 참 또는 거짓 중 하나입니다.
- 배열: 0개 이상의 값으로 구성된 정렬된 목록으로, 각 값은 모든 유형이 될 수 있습니다. 배열은 쉼표와 함께 대괄호를 사용합니다.
- 객체: 이름(키라고도 함)이 문자열인 이름/값 쌍의 순서가 지정되지 않은 모음입니다. 객체는 연관 배열을 나타내기 위해 만들어졌기 때문에 (필수는 아니지만) 각 키가 그 안에서 고유한 것이 좋습니다. 객체는 중괄호로 구분되며 쉼표를 사용하여 각 쌍을 구분합니다. 각 쌍 내에서는 콜론 문자가 키 또는 이름과 해당 값을 구분합니다.
- Null: null이라는 단어를 사용하는 빈 값입니다.
제한된 공백이 허용되며 구문 요소(값 및 구두점, 문자열 값 내에서는 제외) 주위나 사이에 배치할 수 있습니다. 이를 위해 공백, 탭, 줄 바꿈 및 슬래시 등 4개의 특수 문자만 공백으로 간주됩니다. 특히 바이트 순서 표시는 해당 구현에서 생성될 필요가 없습니다(JSON을 구문 분석할 때 허용될 수 있음). JSON 요청은 주석 구문을 제공하지 않습니다.
RFC 4627에 지정된 것과 같은 초기 버전에서는 유효한 문서가 객체 또는 배열 유형으로만 구성되어야 하며, 그 안에 다른 유형이 포함될 수 있습니다. 레거시 웹 페이지에서 볼 수 있는 예인 이 JSON 형식은 현재 사용되지 않습니다.
데이터 이동성 문제 Douglas Crockford는 원래 JSON이 JavaScript의 엄격한 하위 집합이라고 주장했지만 JSON 사양은 실제로 JavaScript에서 읽을 수 없는 문서를 생성할 수 있도록 허용합니다. 특히 JSON에서는 유니코드 문자열 값 U+2028 LINE SEPARATOR 및 U+2029 PARAGRAPH SEPARATOR가 인용된 줄에 이스케이프되지 않은 상태로 표시되도록 허용하지만 JavaScript는 그렇지 않습니다. 이는 JSON이 "제어 문자"만 허용하지 않기 때문에 발생합니다. 호환성을 최대화하려면 이러한 문자를 백슬래시로 이스케이프해야 합니다. 이 미묘함은 JSONP를 생성할 때 중요합니다.
JSON 형식: 어떻게 열 수 있나요? JSON 문서는 UTF-8, UTF-16 또는 UTF-32로 인코딩될 수 있으며 기본 인코딩은 UTF-8입니다. 이러한 표준은 핵심 다국어 평면 외부의 문자(U+10000 ~ U+10FFFF)를 포함하여 "유니코드" 문자의 전체 세트를 지원합니다. 그러나 이스케이프된 경우 이러한 문자는 UTF-16 서로게이트 쌍을 사용하여 작성되어야 하며 일부 JSON 형식 파서에서는 세부 사항이 누락됩니다. 파일을 여는 방법과 해당 파일을 어떻게 읽습니까?
이 형식의 숫자는 프로그래밍 언어에서의 표현과 관련하여 불가지론적입니다. 정수와 부동 소수점 값 사이에는 차이가 없습니다. 일부 구현에서는 42, 42.0 및 4.2E + 1을 동일한 숫자로 처리할 수 있지만 다른 구현에서는 그렇지 않을 수도 있습니다. 또한 오버플로, 언더플로, 정밀도 손실 또는 반올림과 같은 문제에 관한 요구 사항이 없습니다. 또한 JSON 형식은 0.0이 -0.0이 아닌지 여부에 관계없이 서명된 null 처리에 대해 아무 것도 말하지 않습니다. JavaScript를 포함하여 IEEE 754 부동 소수점 표준을 사용하는 대부분의 구현은 부호 있는 0을 유지하지만 모든 JSON 구현이 그렇게 할 수 있는 것은 아닙니다.
JavaScript에서의 사용법 JSON 형식은 JavaScript에서 파생되었으며 해당 구문은 (대부분) 언어의 하위 집합이므로 JavaScripteval 함수를 사용하여 JSON 데이터를 구문 분석할 수 있습니다. 이전 섹션에서 설명한 유니코드 문자열 종결자를 구문 분석할 때 발생하는 문제로 인해 eval 함수는 교체를 수행해야 합니다.
문자열의 유효성이 제대로 검사되지 않으면 안전하지 않습니다. 대신 JSON을 읽고 쓰려면 JSON 파서 라이브러리나 JavaScript 지원을 사용해야 합니다.
적절하게 구현된 파서는 시스템에 설명된 대로 유효한 JSON 형식만 허용하므로 잠재적인 악성 코드가 의도하지 않게 실행되는 것을 방지합니다.
2010년부터 Firefox 및 Internet Explorer와 같은 웹 브라우저에는 분석 및 JSON 형식으로 내보내기에 대한 지원이 포함되었습니다.
지원되지 않는 기본 데이터 유형 JavaScript 구문은 JSON 표준에 포함되지 않은 여러 가지 기본 데이터 유형(Map, Set, Date, Error, Regular Expression, Function 등)을 정의합니다. 이러한 JavaScript 데이터 유형은 다른 형식으로 표현되어야 하며 두 프로그램 모두 유형 간 변환 방법에 동의해야 합니다. 오늘날 날짜를 문자열로 변환하는 것과 같은 몇 가지 사실상의 표준이 있지만 일반적으로 받아들여지는 표준은 없습니다. 다른 언어에는 이러한 유형의 변환을 처리하기 위해 주의 깊게 직렬화해야 하는 다른 기본 유형 세트가 있을 수 있습니다.
JSON 스키마 스키마는 유효성 검사, 문서화 및 상호 작용 관리를 위한 JSON 데이터 구조를 정의하는 데 사용됩니다. 애플리케이션에서 요구하는 데이터에 대한 일종의 계약과 이를 변경하는 방법을 제공합니다.
스키마는 XSD(XML 스키마)의 개념을 기반으로 하지만 독점적입니다. XSD와 마찬가지로 스키마와 데이터 모두에 동일한 직렬화/역직렬화 기능이 사용됩니다.
Schema는 현재 버전 5(2016년 10월 13일 출시)에 있는 인터넷 프로젝트입니다. 다양한 프로그래밍 언어에 사용할 수 있는 여러 유효성 검사기가 있으며 각각은 서로 다른 준수 수준을 갖습니다. 표준 파일 확장자는 없지만 일부 전문가는 Assert.schema.json을 제안합니다.
MIME 유형 JSON 텍스트의 공식 MIME 유형은 "application/json"입니다. 대부분의 최신 구현에서는 공식 MIME 유형을 채택했지만 많은 애플리케이션은 계속해서 다른 MIME 유형에 대한 레거시 지원을 제공합니다. 많은 서비스 제공자, 브라우저, 서버, 웹 애플리케이션, 라이브러리, 프레임워크 및 API는 콘텐츠가 "text/json" 또는 "text/javascript"로 표시되는 MIME 유형을 사용하거나 예상하거나 인식합니다. 주목할만한 예로는 Google Search API, Yahoo!, Flickr, Facebook API, DojoToolkit 0.4 등이 있습니다.
JSON-RPC JSON-RPC는 JSON을 기반으로 구축된 RPC(원격 프로시저 호출) 프로토콜로, XML-RPC 또는 SOAP를 대체하도록 설계되었습니다. 몇 가지 데이터 유형과 명령만 정의하는 간단한 프로토콜입니다. 이를 통해 시스템은 알림(응답이 필요하지 않은 서버에 대한 정보)과 순서 없이 응답할 수 있는 서버에 대한 여러 호출을 보낼 수 있습니다.
A.J.A.J. 비동기 JavaScript 및 JSON(또는 AJAJ)은 Ajax와 동일한 동적 웹 페이지 방법론을 참조하지만 XML 대신 JSON이 기본 데이터 형식입니다. AJAJ는 웹 페이지가 브라우저에 로드된 후 새로운 데이터를 요청할 수 있도록 하는 웹 개발 기술입니다. 일반적으로 해당 페이지의 사용자 작업에 대한 응답으로 서버에서 표시됩니다. 예를 들어, 사용자가 검색 필드에 입력한 내용은 클라이언트 코드에 의해 서버로 전송되며, 서버는 일치하는 데이터베이스 항목의 드롭다운 목록으로 즉시 응답합니다.
보안 문제들 JSON 형식의 텍스트는 데이터 직렬화 개체로 정의됩니다. 그러나 JavaScript 스크립팅 언어의 느슨한 하위 집합인 이 디자인은 몇 가지 보안 문제를 야기합니다. 그들은 JavaScript 인터프리터를 사용하여 인라인 JavaScript와 같은 JSON 텍스트를 동적으로 실행하는 데 중점을 둡니다. 이로 인해 프로그램이 잘못되었거나 악의적인 스크립트에 노출됩니다. 이는 인터넷에서 검색된 데이터로 작업할 때 심각한 문제입니다.
이 간단하고 대중적이지만 위험한 방법은 JavaScripteval 함수와의 호환성을 사용합니다.
일부 개발자는 JSON 텍스트가 구문적으로 유사한 JavaScript 코드라고 잘못 생각하지만 이는 부분적으로만 사실입니다. 따라서 JavaScript 프로그램이 이 형식의 데이터를 구문 분석하는 간단한 방법은 JavaScript 표현식을 평가하도록 설계된 내장 JavaScripteval 함수를 사용하는 것이라고 믿어집니다. 특정 파서를 사용하는 대신 파서 자체를 사용하여 JSON 데이터를 실행하여 자연스러운 JavaScript 개체를 생성합니다. 그러나 JSON 데이터에 임의의 "JavaScript" 코드가 포함되어 동일한 방식으로 실행될 가능성이 있는 경우 이 방법은 위험합니다. 데이터의 유효성을 검사하는 단계를 먼저 수행하지 않는 한, 데이터와 전체 JavaScript 환경이 신뢰할 수 있는 단일 소스의 제어를 받지 않는 경우 평가 방법은 보안 취약성에 취약합니다.
예를 들어 데이터가 검증되지 않은 경우 악성 자바스크립트 코드의 공격을 받기 쉽습니다. 이러한 위반으로 인해 데이터 도난, 인증 사기, 기타 데이터 및 리소스 오용의 위험이 발생할 수도 있습니다.
따라서 새로운 JSON.parse 함수는 eval보다 안전한 대안으로 설계되었습니다. JavaScript가 아닌 JSON 데이터를 처리하도록 특별히 설계되었습니다. 원래는 ECMAScript 표준 제4판에 포함될 계획이었으나 실현되지 않았습니다. 버전 5에 처음 추가되었으며 현재 주요 브라우저에서 지원됩니다.
) 및 서버 자체 간(HTTP 소프트웨어 인터페이스). JSON 형식은 관계형 데이터베이스나 파일 캐시에 복잡한 동적 구조를 저장하는 데에도 적합합니다.
JSON은 JavaScript 구문의 하위 집합이므로 내장된 eval() 함수를 사용하여 신속하게 역직렬화할 수 있습니다. 또한 완전한 기능을 갖춘 JavaScript 함수를 삽입하는 것도 가능합니다. PHP에서는 버전 5.2.0부터 JSON 지원이 json_decode() 및 json_encode() 함수 형태로 핵심에 포함되어 있으며, 이 함수는 자체적으로 JSON 데이터 유형을 해당 PHP 유형으로 변환하거나 그 반대로 변환합니다.
통사론 JSON은 두 가지 구조로 구축되었습니다.
- 키/값 쌍의 집합입니다. 다양한 언어에서 이는 다음과 같이 구현됩니다. 객체, 레코드 , 구조 , 사전 , 해시 테이블 , 키 목록 또는 연관 배열 . 키는 문자열만 가능하고 값은 모든 형식만 가능합니다.
- 번호가 매겨진 값 집합입니다. 많은 언어에서 이것은 다음과 같이 구현됩니다. 정렬, 벡터, 목록 또는 시퀀스.
이것은 보편적인 데이터 구조입니다. 이론적으로 모든 현대 프로그래밍 언어는 어떤 형태로든 이를 지원합니다. JSON은 서로 다른 프로그래밍 언어 간에 데이터를 교환하는 데 사용되므로 이러한 구조를 기반으로 JSON을 구축하는 것이 합리적입니다.
JSON에서는 다음 형식이 사용됩니다.
- 객체는 중괄호( )로 묶인 이름/값 쌍의 순서가 지정되지 않은 집합입니다. 이름과 값 사이에 기호가 있습니다. ": "
, 이름/값 쌍은 쉼표로 구분됩니다.
- 배열(1차원)은 일련번호(인덱스)를 갖는 값의 집합입니다. 배열은 대괄호로 묶여 있습니다. 값은 쉼표로 구분됩니다.
- 값은 다음과 같습니다. 선큰따옴표 안에, 숫자, 값 진실또는 거짓, 물체, 정렬또는 값 없는. 이러한 구조는 서로 중첩될 수 있습니다.
- 문자열은 백슬래시 이스케이프 시퀀스를 사용하여 큰따옴표로 묶인 0개 이상의 유니코드 문자로 구성된 순서 집합입니다. 문자는 간단한 문자열로 표시됩니다.
- 이름은 문자열입니다.
선언어 및 Java의 문자열과 매우 유사합니다. 숫자또한 10진수 형식만 사용된다는 점을 제외하면 C 또는 Java 숫자와 매우 유사합니다. 두 문자 사이에 공백을 삽입할 수 있습니다.
다음 예에서는 사람을 설명하는 객체의 JSON 표현을 보여줍니다. 객체는 끈이름과 성 필드, 주소를 설명하는 객체, 전화번호 목록이 포함된 배열입니다.
( "firstName" : "Ivan" , "lastName" : "Ivanov" , "address" : ( "streetAddress" : "Moskovskoe sh., 101, apt. 101" , "city" : "Leningrad" , "postalCode" : 101101 ) , "phoneNumbers" : [ "812 123-1234" , "916 123-4567" ] )
XML에서 이러한 구조는 다음과 같습니다.
Ivan Ivanov Moskovskoe sh., 101, 아파트 101 Leningrad 101101 812 123-1234 916 123-4567
812 123-1234
916 123-4567
YAML과의 비교 기능적으로나 구문적으로 JSON은 YAML 언어의 하위 집합입니다. 특히 YAML 1.2 사양에는 "모든 JSON 파일은 유효한 YAML 파일입니다."라고 명시되어 있습니다. 가장 일반적인 YAML 파서는 JSON도 처리할 수 있습니다. 버전 1.2 이전의 YAML 사양은 주로 YAML에서 UTF-32에 대한 기본 지원이 부족하고 쉼표 구분 기호 뒤에 공백이 필요하기 때문에 JSON을 완전히 포함하지 않았습니다. 또한 JSON 사양에는 /* */ 스타일 주석이 포함되었습니다.
YAML의 가장 중요한 차이점은 JSON에 유사점이 없는 구문 확장 세트입니다.
관계형: YAML은 관계형 데이터를 지원합니다. YAML 문서에서는 파일/스트림에서 이전에 발생한 앵커를 참조할 수 있습니다. 재귀구조는 이런 식으로 표현될 수 있다. 확장 가능: YAML은 기본 형식(예: 문자열, 숫자, 부울) 이상의 확장 가능한 데이터 유형을 지원합니다. 블록: YAML에서는 들여쓰기된 블록 구문을 사용할 수 있습니다. 불필요한 기호(모든 종류의 대괄호, 따옴표 등)를 사용하지 않고 구조화된 데이터를 설명할 수 있습니다.
JSON 스키마 JSON 스키마는 JSON 문서의 구조를 기술하는 언어 중 하나입니다. JSON 구문을 사용합니다. XML 스키마, RelaxNG, Kwalify의 개념을 기반으로 합니다. JSON 스키마는 자기 설명적 언어입니다. 사용하면 동일한 직렬화/역직렬화 도구를 사용하여 데이터를 처리하고 유효성을 설명할 수 있습니다.
Ajax에서 JSON 사용하기 다음 예제 Javascript 코드는 브라우저가 XMLHttpRequest를 사용하여 서버에서 JSON 형식 개체를 요청하는 방법을 보여줍니다(프로그램의 서버 측은 생략되었습니다. 요청에 대한 응답으로 데이터를 JSON 문자열로 보내는 코드가 포함되어야 함). URL).
Var the_object; var http_request = new XMLHttpRequest() ; http_request.open("GET", url, true); http_request.send(null); http_request.onreadystatechange = function () ( if ( http_request.readyState == 4 ) ( if ( http_request.status == 200 ) ( the_object = JSON.parse ( http_request.responseText ) ; ) else ( 경고( "다음에 문제가 있습니다. URL." ) ; ) http_request = null ; ) ) ;
XMLHttpRequest를 사용하는 이 예제는 모든 브라우저에 보편적이지 않습니다(Internet Explorer, Opera, Safari 및 Mozilla 기반 브라우저의 경우 코드에 약간의 차이가 있음). XMLHttpRequest의 사용은 동일한 출처 정책으로 인해 제한됩니다. 요청에 대한 응답의 URL은 응답을 요청하는 페이지가 있는 서버와 동일한 DNS 도메인에 있어야 합니다. 대안은 클라이언트와 서버 간에 전달되는 인코딩된 함수 호출을 사용하여 클라이언트가 제3자 도메인에서 JSON 인코딩 데이터를 로드하고 호출자에게 완료를 알릴 수 있도록 하는 JSONP 접근 방식입니다. 추가 서버 요구 사항.
또는 페이지 코드에서 요소를 사용하여 JSON 데이터를 비동기식으로 요청하거나 간단히 . 이러한 접근 방식은 XMLHttpRequest에 대한 광범위한 지원이 제공되기 전에는 일반적이었습니다.
동일한 원본 정책을 사용하여 동적 태그를 사용하여 JSON 데이터를 전송할 수도 있지만 이로 인해 코드가 취약해집니다. 보다 안전한 대안으로 다음을 사용하는 것이 제안되었습니다. JSONRequest.
보안 질문 JSON은 직렬화된 형식으로 데이터를 전송하도록 설계되었지만 구문은 JavaScript 구문을 따르므로 여러 가지 보안 문제가 발생합니다. JSON 형식의 외부 소스로부터 수신된 데이터를 처리하기 위해 사전 검증 없이 eval() 함수가 적용되는 경우가 많습니다.
자바스크립트 평가() JSON은 구문적으로 올바른 JavaScript 코드 조각으로 나타나기 때문에 JavaScript 프로그램에서 JSON 데이터를 구문 분석하는 가장 간단한 방법은 JavaScript 표현식을 실행하도록 설계된 내장 JavaScript eval() 함수를 사용하는 것입니다. 이 접근 방식을 사용하면 추가 파서를 사용할 필요가 없습니다.
eval() 기술은 사용된 JSON 데이터의 소스를 신뢰할 수 없는 경우 시스템을 취약하게 만듭니다( 영어). 이러한 데이터는 코드 주입 공격을 위한 악성 JavaScript 코드일 수 있습니다( 영어). 이 취약점을 이용하면 데이터 탈취, 인증 위조가 가능하다. 그러나 추가적인 데이터 검증 도구를 사용하면 취약점을 제거할 수 있습니다. 예를 들어 eval()을 실행하기 전에 정규식을 사용하여 외부 소스로부터 수신된 데이터의 유효성을 검사할 수 있습니다. JSON을 정의하는 RFC에서는 다음 코드를 사용하여 JSON 형식을 준수하는지 확인하도록 제안합니다.
Var my_JSON_object = ! (/[^,:()\[\]0-9.\-+Eaeflnr-u \n\r\t]/ .test ( text.replace (/"(\\.|[^"\\] )*"/g , "" ) ) ) && eval("(" + text + ")" ) ;
eval()에 대한 보다 안전한 대안으로 JSON 데이터만 처리할 수 있는 새로운 함수인parseJSON()이 제안되었습니다. 이는 ECMAScript 표준 버전 4에 도입되었으며 "JSON: A Low-Fat Alternative to XML" 기사에 설명되어 있습니다. 현재 JavaScript 라이브러리로 사용 가능하며 ECMAScript의 제5판에 포함될 예정입니다.
내장된 JSON 최신 버전의 웹 브라우저에는 JSON에 대한 지원이 내장되어 있으며 설명된 문제로 이어지는 eval() 함수를 호출하지 않고도 JSON을 처리할 수 있습니다. 이 경우 일반적으로 JSON 처리가 더 빠릅니다. 따라서 2009년 6월에 다음 브라우저에는 JSON 지원이 내장되었습니다.
가능한 경우 최소 5개의 인기 있는 JavaScript 라이브러리가 인라인 JSON을 사용합니다.
도메인 간 요청 위조 JSON을 제대로 사용하지 않으면 사이트가 교차 사이트 요청 위조(CSRF 또는 XSRF)에 취약해집니다. 태그를 사용하면 해당 태그를 사용하는 리소스와 동일한 도메인에 속하지 않은 소스를 사용할 수 있으므로 임의의 페이지 컨텍스트에서 JSON 데이터를 가장하여 코드가 실행될 수 있어 비밀번호가 유출되거나 손상될 수 있습니다. 다른 사이트에서 인증된 사용자의 기타 민감한 정보.
이는 JSON 데이터에 제3자에 의해 손상될 수 있는 민감한 정보가 포함되어 있고 서버가 단일 원본 정책( 영어), 외부 요청이 감지되면 데이터에 대한 액세스를 차단합니다. 서버가 요청의 유효성을 확인하고 올바른 경우에만 데이터를 제공하는 경우에는 문제가 되지 않습니다. 이를 확인하는 데 HTTP 쿠키를 사용할 수 없습니다. HTTP 쿠키의 독점적 사용은 교차 사이트 요청 위조에 사용됩니다.
JSONP 및 JSONPP JSONP(JSON Padding) 또는 "JSON with padding"은 콜백 함수 이름을 입력 인수로 지정한 경우 JSON을 확장한 것입니다.
이 기술은 브라우저의 보안 정책에 따라 태그를 사용하여 페이지가 로드된 서버가 아닌 다른 서버에 액세스할 수 있다는 사실에 기반을 두고 있습니다.
JSONP 기술을 사용하지 않으면(즉, JSON 데이터 인코딩만 사용하여) 서버는 데이터만 반환할 수 있습니다. 예를 들면 다음과 같습니다:
("용지": "A4", "개수": 5)
그러나 이는 데이터일 뿐이며 브라우저에 영향을 미칠 수 없습니다.
JSONP 기술을 사용하면 콜백 함수의 이름이 호출 라인(GET)을 통해 타사 서버에 전달됩니다.
여기서 jsonp 매개변수에는 콜백 함수인 parseResponse의 이름이 포함되어 있습니다.
이제 외부 서버 example.com은 다음 코드를 반환할 수 있습니다.
ParseResponse(( "paper" : "A4" , "count" : 5 ) )
이제 코드는 첫 번째 도메인의 javascript 함수를 호출합니다.
이 아이디어는 원래 2005년 MacPython 블로그에서 제안되었으며 현재 Dojo Toolkit 애플리케이션, Google Toolkit 애플리케이션 및 zanox 웹 서비스와 같은 많은 Web 2.0 애플리케이션에서 사용됩니다. S3DB 웹 서비스에 대한 JSONPP 지원과 같은 추가 인수를 포함하기 위해 이 프로토콜에 대한 추가 확장이 제안되었습니다.
JSONP는 스크립트 태그를 사용하기 때문에 호출은 본질적으로 전 세계에 공개됩니다. 이러한 이유로 JSONP는 민감한 데이터를 저장하는 데 부적절할 수 있습니다.
원격 사이트에서 스크립트 태그를 활성화하면 사이트의 모든 콘텐츠를 전송할 수 있습니다. 원격 사이트에 Javascript 삽입을 허용하는 취약점이 있는 경우 원본 사이트도 해당 취약점으로 인해 영향을 받을 수 있습니다.
JSONPP(패딩이 포함된 매개변수화된 JSON) 패딩이 포함된 매개변수화된 JSON - JSONP 아이디어 개발
JSONPP에는 소스 URL, JSON 데이터를 처리할 함수 이름, 데이터 수신 후 평가 라인, 데이터 처리 완료 후 평가 라인이 포함되어 있습니다.
JSON_call(SRC, JSONP, JSONPP, ONLOAD) ;
결국 돌아서다
Ans = JSONP(SRC) ( eval(JSONPP(ans) ) ; eval(ONLOAD) ; )
일반적으로 JSONPP 아이디어 자체에는 매개변수의 개수가 중요하지 않습니다. SRC, JSONP, JSONPP(및 서버 측 처리와 클라이언트 측 처리)는 JSONPP가 되기에 충분합니다.
S3DB 서비스 작업의 예를 살펴보겠습니다.
함수 s3db_jsonpp_call(src, next_eval) ( var call = "call_" + Math .random () .toString () .replace (/\./g, "" ) ; var headID = document.getElementsByTagName ("head" ) [ 0 ] ; var script = document.createElement ("script" ) ; script.id = call script.type = "text/javascript" ; // 패딩되고 매개변수화된 json 사용 src = src+ "&format=json&jsonp=s3db_jsonpp&jsonpp=" + next_eval+ " &onload=remove_element_by_id("" + script.id + "")" ; script.src = src; headID.appendChild (script) ; // 답변 검색 ) function s3db_jsonpp(ans, jsonpp) ( eval(jsonpp) ; return ans ; ) 함수 Remove_element_by_id(id) ( var e = document.getElementById (id) ; e.parentNode .removeChild (e) ; return false ; )
예제에서 s3db_jsonpp_call() 함수는 DOM의 헤드 부분에 스크립트 요소를 생성합니다. 이 요소의 src는 JSONPP 호출에 해당합니다.
서버로부터 응답을 받은 후 s3db_jsonpp()가 호출됩니다. 이는 JSONP 규칙에 따라 호출 매개변수로 전달됩니다.
s3db_jsonpp() 내부에서 eval(jsonpp)이 실행되고 ans 값을 반환합니다.
eval(onload)를 호출하면 헤드에 생성된 스크립트의 ID가 포함된 Remove_element_by_id()가 실행되고 결국 삭제됩니다. 예제의 ID는 스크립트 맨 처음에 무작위로 생성되었기 때문에 어쨌든 사용되지 않기 때문입니다. s3db_jsonpp_call() 함수. 이 호출은 서버 응답에 있습니다.
객체 참조 JSON 표준은 객체 참조를 지원하지 않지만 Dojo Toolkit은 표준 JSON이 추가 규칙을 사용하여 그러한 참조를 지원할 수 있는 방법을 보여줍니다. 특히, dojox.json.ref 모듈은 순환 링크, 다중 링크, 문서 간 링크, 지연 링크를 포함한 여러 형태의 링크에 대한 지원을 제공합니다.
참고 사항도 참조하세요. YAML은 마크업 언어가 아닙니다(YAML™) 버전 1.2(영어) . - 작업 초안 2008-05-11.(접근할 수 없는 링크 - 이야기) 2009년 9월 24일에 확인함.
. RedHanded(2005년 4월 7일). 2012년 9월 25일에 확인함.
JSON.Com JSON 스키마 제안(액세스할 수 없는 링크 - 이야기)
RFC 4627
JSON: XML의 Fat Free 대안. 보관됨
json2.js(영어) . 2012년 2월 12일에 원본 문서에서 보존된 문서. 2009년 9월 24일에 확인함.
내장된 JSON을 사용합니다.
IE8에 JSON을 내장했습니다. 2012년 2월 12일에 원본 문서에서 보존된 문서.
Opera Presto 2.5(영어)(2010년 3월 10일)에서 지원되는 웹 사양입니다. 2012년 2월 12일에 원본 문서에서 보존된 문서. 2010년 3월 29일에 확인함.
JSON 객체의 ES 3.1 구현.
티켓 #4429lang=en . 2012년 2월 12일에 원본 문서에서 보존된 문서.
티켓 #4429(2009년 5월 22일). 2012년 2월 12일에 원본 문서에서 보존된 문서. 2009년 7월 3일에 확인함.
티켓 #8111lang=ko . 2012년 2월 12일에 원본 문서에서 보존된 문서.
MooTools 코어 및 기타 1.3.1. 2012년 2월 12일에 원본 문서에서 보존된 문서.
YUI 2: JSON 유틸리티(2009년 9월 1일). 2012년 2월 12일에 원본 문서에서 보존된 문서. 2009년 10월 22일에 확인함.
JSON 알아보기(2010년 4월 7일) 2012년 2월 12일에 원본 문서에서 보존된 문서. 2010년 4월 7일에 확인함.
제레미 그로스먼 Gmail을 사용하는 웹 애플리케이션에 대한 고급 공격 기술. 화이트햇 보안. 2012년 2월 12일에 원본 문서에서 보존된 문서. 2009년 9월 23일에 확인함.
from __future__ import * » 원격 JSON - JSONP. bob.pythonmac.org. 2012년 2월 12일에 원본 문서에서 보존된 문서. 2008년 9월 8일에 확인함.
알메이다, 요나스(2008년 6월 11일). "JSON, JSONP, JSONPP? "(S3DB). 2009년 4월 26일에 확인함.
RIA스팟 Cross Site XHR용 JSON P.(액세스할 수 없는 링크 - 이야기)
Dojo에서 참조하는 JSON. 2012년 2월 12일에 원본 문서에서 보존된 문서.연결 - 러시아어 공식 형식 홈페이지
- json.js, json2.js는 JavaScript에서 JSON 데이터 작업을 위해 Douglas Crockford가 개발한 라이브러리입니다. toJSONString 메서드를 사용하여 개체를 확장한 후 모든 개체에 존재하고 이를 JSON 형식 문자열로 변환합니다.
- json-rpc.org(영어)
문서 마크업 언어
사무실 문서 | 복합 문서 형식 OOXML(SpreadsheetML, PresentationML, WordprocessingML) |
