JSON 데이터가 들어있는 파일의 공식 파일 확장자는 .json입니다. 그러나 잠시 동안 MongoDB를 사용 후, 나는 인식이 확장 실제로 JSON 형식의 두 가지 유형에 사용됩니다 :JSON 가져 오기/내보내기 형식의 파일 확장자
는 예를 들어, mongoexport 매뉴얼은 JSON의 많은 라인을 가진 파일을 생성하기 위해 많은 예에서 output.json를 사용합니다. 그러나 첫 번째 형식을 가정하는 파서는이 파일을 질식시킵니다.
두 시나리오를 구별하기 위해 기존 대체 파일 확장명이 있습니까?
여러 JSON 개체가 분명히 유효한 JSON이 아님에 동의합니다. 사양은 JSON-text = ws value ws 및 value = false/null/true/object/array/number/string이며 다중 개체를 허용하지 않는다는 것을 의미합니다.
NDJSON이라는 자체 포맷을 만들기위한 노력이 있습니다. 현재 스펙의 첫 번째 버전은 https://github.com/ndjson/ndjson-spec입니다.
ndjson은 종종 .json으로 잘못 분류되기 때문에이 표준에 대해 더 많은 홍보가 필요합니다.
내가 알고있는 것은 아니며, 그럴만한 이유가 있습니다.
JSON은 낮은 오버 헤드로 데이터 교환 형식으로 인식되었습니다. 공백은 따옴표가 붙지 않는 한, 필자가 알고있는 파서 (Java, Perl, Python, JavaScript)에서 무시됩니다.
공백은 RFC7159: The JavaScript Object Notation (JSON) Data Interchange Format에 명시 적으로 언급되어 있지만, 문법에서는 공백이 의미 적 의미를 갖고 있다고 명시하지 않습니다. 문법 섹션의 상태는 공백이 중요하지 않으며 파서 섹션에서 모든 적합한 파서가 문법을 따라야한다는 것입니다. 그러므로 공백이 있는지 여부에 관계없이 JSON 문법의 다른 요구 사항이 충족되는 한 유효한 JSON 문서입니다.
이것은 기본적으로 모든 파서가 객체 생성을 시작하기 전에 인용되지 않은 공백을 먼저 제거하거나 무시한다는 사실을 의미합니다.
따라서 파서가 위에서 언급 한 두 형식 중 하나를 구문 분석하는 데 문제가있는 경우 이는 안전하게 간주 될 수 있습니다.
편집 : 하나의 문서에서 여러 개체가 잘못된 JSON 문서를 형성한다는 가정을 보지 못했습니다. 내가 이해하는 한 RFC는 토큰의 수에 제한을 두지 않고 JSON 텍스트가 여러 객체를 포함하는 것을 명시 적으로 금지하지 않으므로 암시 적으로 여러 객체를 가질 수 있습니다. 그러나 JSON을 구문 분석하는 모든 응용 프로그램은 정확히 하나가 아닌 정의되지 않은 수의 객체를 가져와야한다는 것을 의미합니다.
두 가지를 구별 할 수있는 유일한 방법은 min.json 일 수 있지만 결국에는 잘못 이해할 수 없습니다. –