개발자 도구 · JSON 포맷터 및 유효성 검사기
JSON 행 파일이 2 행, 1 열에서 검증에 실패하는 이유
· 작동 방식
JSON 개발자 워크플로 검증
.jsonl 파일은 하나가 아닌 많은 JSON 문서이므로 엄격한 유효성 검사기는 두 번째 문서가 시작되는 위치에서 정확하게 중지됩니다. 이 게시물에서는 JSON 줄 및 NDJSON 규칙과 한 번에 하나의 레코드를 검증하는 방법을 설명합니다.
모든 줄에 유효하며 파일로는 유효하지 않습니다.
모든 줄에서 유효하지만 파일로는 유효하지 않습니다. 모든 다운스트림 도구는 행복하게 읽지만 유효성 검사기는 두 번째 줄에서 거부하는 내보내기입니다. 로그 전달자는 각 줄 바꿈을 레코드 경계로 사용할 수 있지만 엄격한 JSON 구문 분석기는 전체 파일을 하나의 입력으로 간주합니다. 첫 번째 개체는 완전한 JSON입니다. 다음 여는 중괄호는 잘못된 두 번째 루트 값입니다.
ToolAcre는 JSON 행이 아닌 하나의 JSON 텍스트를 검증합니다. 스캐너가 첫 번째 루트 값을 완료하면 이후 공백이 아닌 문자는 JSON 값 끝 이후에 예기치 않은 문자로 보고됩니다. 숨겨진 폴백으로 줄당 NDJSON 유효성 검사 또는 변환을 제공하지 않습니다. 이러한 구별은 녹색 결과가 라인 지향 스트림의 모든 레코드가 확인되었음을 암시하는 것을 방지합니다.
하나의 텍스트, 하나의 값 - RFC 8259이 JSON 텍스트로 정의하는 것과 행에 있는 두 개의 최상위 값이 문법 오류인 이유
하나의 텍스트, 하나의 값 — RFC 8259이 JSON 텍스트로 정의하는 내용과 행에 있는 두 개의 최상위 값이 문법 오류인 이유. JSON 텍스트는 직렬화된 값이므로 객체, 배열, 문자열, 숫자, 부울 또는 null이 루트에 있을 수 있습니다. 공백은 해당 값을 둘러쌀 수 있지만 여러 루트를 더 큰 유효한 문서로 분리할 수는 없습니다.
예를 들어 `{"ok":true} {"ok":false}` contains two individually valid objects but is not one JSON text. Parsing the first object consumes a complete value; parsing the entire string must then reject the second `{`. 일반 JSON에서 두 값을 모두 나타내려면 해당 값을 배열 안에 배치하고 배열 요소 사이에 필요한 쉼표를 추가하세요.
JSON 줄 및 NDJSON
JSON 라인 및 NDJSON — 개행으로 구분된 규칙, 스트리밍 및 로그에 존재하는 이유, JSON 배열과의 차이점. 각 실제 줄은 하나의 완전한 JSON 값(일반적으로 개체)을 전달하며 줄 바꿈은 JSON 문법 외부의 프레임 역할을 합니다. 생산자는 레코드를 추가할 수 있고 소비자는 전체 컬렉션을 로드하지 않고도 레코드를 점진적으로 처리할 수 있습니다.
대신 배열에는 하나의 여는 괄호, 쉼표로 구분된 요소 및 하나의 닫는 괄호가 있어 전체 파일을 단일 JSON 값으로 만듭니다. 제한된 컬렉션을 반환하는 API에는 편리하지만 무한정 증가하는 이벤트 스트림에는 어색합니다. 잘린 JSON Lines 파일은 이전의 전체 기록을 모두 보존할 수 있습니다. 잘린 배열은 일반적으로 둘러싸는 값을 완료되지 않은 상태로 둡니다.
오류가 항상 2 행, 1 열에 나타나는 이유
오류가 항상 2 행, 1 열에 있는 이유 — 구문 분석기는 첫 번째 값을 완료하고 입력 끝을 예상하며 두 번째 레코드의 첫 번째 문자를 충족합니다. 개행 자체는 유효한 후행 공백이므로 실패를 유발하지 않습니다. 다음 레코드의 여는 중괄호는 문서 완료 상태와 모순되는 첫 번째 토큰입니다.
해당 위치는 두 번째 개체의 형식이 잘못되었다는 주장이 아니라 진단 증거입니다. 보고서가 유효한 루트 다음에 공백이 아닌 첫 번째 문자를 일관되게 가리키는 경우 구두점을 편집하기 전에 파일 모양을 검사하십시오. 중괄호를 삭제하면 기록이 손상될 수 있습니다. 라인 인식 리더를 선택하거나 레코드를 배열로 변환하면 실제 프레이밍 불일치가 해결됩니다.
작업 예: 세 개의 로그 레코드 유효성 검사
작업 예: 세 개의 로그 레코드 유효성 검사 — 각 줄을 자체적으로 확인하는 것과 쉼표로 배열로 묶는 것 비교. 행에 `{"level":"info"}`, `{"level":"warn"}` 및 `{"level":"error"}`가 포함되어 있다고 가정합니다. 줄 기반 유효성 검사기는 세 가지 개별 입력을 구문 분석하고 누락된 따옴표나 후행 쉼표가 있는 경우 정확한 레코드를 식별할 수 있습니다.
전체 문서를 엄격하게 확인하려면 샘플을 `[{"level":"info"},{"level":"warn"},{"level":"error"}]`로 변환하세요. 대괄호는 하나의 루트를 설정하고 쉼표는 해당 요소를 구분합니다. 개행 문자를 단순히 쉼표로 바꾸지 마십시오. 주변 배열이 추가되지 않는 한 구두점으로 구분된 세 개의 루트가 생성되며 소스 규칙에서 금지하거나 무시할 수 있는 빈 줄을 잘못 처리할 수 있습니다.
두 모양 간 변환
두 모양 간 변환 - 래핑 배열이 적절한 경우와 줄로 구분된 출력 지점을 무효화하는 경우. API 요청, 편집기 또는 엄격한 유효성 검사기를 위한 유한 내보내기는 종종 배열이 될 수 있습니다. 변환은 먼저 모든 레코드를 구문 분석해야 합니다. 텍스트 연결로는 포함된 이스케이프 문자나 유효하지 않은 줄을 안전하게 설명할 수 없기 때문입니다.
레코드가 계속 도착하거나 파일이 추가되거나 소비자에게 제한된 메모리 및 레코드 수준 복구가 필요한 경우 JSON 줄을 유지합니다. 멀티 기가바이트 이벤트 스트림을 하나의 배열로 변환하려면 컨테이너 상태를 유지해야 하며 닫는 대괄호가 도착할 때까지 전체 구문 분석이 지연됩니다. 다른 방향에서는 각 배열 요소를 한 줄에 간결하게 직렬화하고 빈 줄이나 마지막 줄 바꿈이 허용되는지 여부를 정의합니다.
여기서 다루지 않는 내용
여기서 다루지 않는 내용 — 전용 파서가 필요한 개행 및 레코드 구분자 프레이밍(RFC 7464) 없이 JSON을 연결했습니다. 직접적으로 배치된 값은 간단한 선 연산으로는 안전하게 분할할 수 없습니다. 특히 루트가 숫자나 문자열일 수 있는 경우에는 더욱 그렇습니다. RFC 7464는 눈에 보이는 줄 바꿈에만 의존하는 대신 ASCII 레코드 구분 문자를 사용하여 JSON 텍스트 시퀀스의 프레임을 지정합니다.
또한 레코드가 공유하는 응용 프로그램 규칙의 유효성을 검사하지 않습니다. 모든 행을 구문 분석해도 타임스탬프가 순서대로 지정되어 있는지, 식별자가 고유한지 또는 모든 개체가 동일한 스키마를 사용하는지 확인할 수 없습니다. 이러한 검사는 레코드 프레이밍 및 구문 분석 이후에 속합니다. 마찬가지로 문자열 내부에 이스케이프 시퀀스 ` `로 삽입된 개행 문자는 물리적 경계가 아닌 데이터이며 호환 줄 판독기는 해당 구별을 유지해야 합니다.
테이크아웃: 어떤 모양을 들고 있는지 알아보세요.
요점: 어떤 모양을 잡고 있는지 확인하고 유효성 검사기의 위치를 통해 파일이 줄로 구분되어 있음을 즉시 알 수 있습니다. 첫 번째 줄의 전체 값 이후 두 번째 줄의 첫 번째 토큰에서 오류가 발생하면 첫 번째 레코드의 구문이 끊어진 것이 아니라 여러 개의 프레임된 레코드가 있음을 강력하게 나타냅니다. 데이터를 변경하기 전에 확장 프로그램, 생산자 문서 및 예상 소비자를 확인하세요.
줄 바꿈이 의도적인 경우 JSON 행 또는 NDJSON 구문 분석기를 사용하여 레코드를 독립적으로 검증합니다. 대상에 하나의 완전한 JSON 컬렉션이 필요한 경우 배열을 사용하십시오. ToolAcre는 계약이 엄격한 단일 텍스트 유효성 검사이므로 다중 루트 파일을 올바르게 거부합니다. 거부는 개행으로 구분된 JSON가 본질적으로 결함이 있음을 보여주기보다는 해당 계약을 보호합니다. 유효성 검사기를 프레이밍 형식과 일치시킵니다.