JSON 검증기
입력한 텍스트가 표준 JSON 문법을 따르는지 확인하고 오류 원인을 이해합니다.
데이터를 사용하기 전에 JSON 확인
따옴표, 쉼표 또는 괄호 하나가 빠지면 API, 설정 파일 또는 build step 이 중단될 수 있습니다. 이 validator 는 source text 를 JSON 으로 parse 하여 문법 오류와 이후 application validation 을 구분하도록 돕습니다.
여기서 validation 은 입력 text 를 하나의 JSON value 로 parse 할 수 있는지 확인하는 뜻입니다. parse 성공은 구조가 JSON 으로 받아들여졌다는 의미일 뿐 required field, business rule, JSON Schema 가 맞다는 뜻은 아닙니다.
payload 가 여러 service 사이를 이동할 때 먼저 syntax 를 확인하면 debugging 범위를 줄일 수 있습니다. quote, comma, escape, nesting 을 확인한 뒤 project 고유의 schema 와 domain check 를 실행하세요.
request body, fixture, export 된 설정, configuration snippet 을 확인할 때 사용할 수 있습니다. test copy 에서 token, password, 개인정보를 제거하고 조직의 privacy policy 에 따라 입력을 다루세요.
문법과 데이터 의미는 다릅니다
표준 JSON 은 object, array, string, number, true, false, null 을 포함합니다. property name 과 string 은 double quote 로 감싸고 member 는 comma 로 나누며 bracket 은 올바른 순서로 닫아야 합니다. comment 와 trailing comma 는 표준 JSON grammar 에 포함되지 않습니다.
validator 가 답하는 질문은 source 를 하나의 JSON value 로 parse 할 수 있는가입니다. source 를 자동 수정하거나 code 를 실행하고 API 를 호출하거나 application 에 유용한지 판단하지 않습니다. schema 와 domain 검사는 별도로 수행하세요.
whitespace 는 가독성을 위해 보통 허용되지만 string 안의 character 는 데이터입니다. production consumer 와 동일한 parser 규칙으로 escape sequence, newline, Unicode, encoding 을 확인하세요.
JSON document 가 valid 라고 해서 transport 도 valid 인 것은 아닙니다. HTTP header, content type, authentication, compression, size limit 은 별도 계층입니다.
JSON 을 확인하는 방법
- source field 에 완전한 JSON value 하나를 붙여 넣습니다. comment, code fence, programming language wrapper 는 test copy 에서 제거하세요.
- validator 를 실행하고 status 와 diagnostic 을 읽습니다. marker 위치의 character 뿐 아니라 앞뒤 token 도 확인하세요. 실제 오류는 조금 앞에 있을 수 있습니다.
- 거부되면 quote, comma, bracket, escape, nesting 을 확인합니다. 큰 document 는 작은 부분으로 나누어 failing section 을 찾은 뒤 수정본을 다시 검사합니다.
- syntax 가 통과한 후 project 의 schema, type, required property, range, permission, business rule 을 검사합니다. 이 결과를 syntax result 와 같은 의미로 기록하지 마세요.
- original payload 와 redacted copy 를 분리해 보관합니다. secret 을 public example, screenshot, URL 에 넣지 마세요.
- 마지막으로 실제 consumer 와 같은 parser 와 encoding 으로 integration test 를 실행합니다. 언어와 library 에 따라 duplicate key 와 number precision 처리 방식이 달라질 수 있습니다.
검사 방법
- grammar 읽기
validator 는 token, quote, delimiter, nesting 규칙을 사용하여 전체 source 를 하나의 JSON value 로 parse 합니다.
- 결과 표시
Valid 는 parsing 이 완료되었다는 뜻입니다. Failure 는 source 가 도구가 이해하는 syntax 와 일치하지 않는다는 뜻입니다.
- 후속 검사 분리
schema, range, permission, domain 은 semantic check 입니다. 별도의 규칙과 evidence 가 필요합니다.
도구가 exact line number 또는 error message 를 기록하지 않는다면 추측해서 작성하지 마세요. 필요할 때 실제 runtime 에서 다시 확인하세요.
결과 읽기
Valid 는 text 가 JSON syntax 로 받아들여졌다는 뜻입니다. 다음으로 value 를 확인하고 schema 와 application validation 을 실행하세요.
Invalid 는 parsing 이 중단됐다는 뜻입니다. 지정된 위치 앞뒤의 character 를 확인하고 marker 하나만 수정하지 마세요.
syntax 가 valid 인데 request 가 실패하면 content type, endpoint, authentication, schema, business rule 을 확인합니다. syntax success 와 network success 는 다릅니다.
message 가 일반적이면 input 을 줄여 failing section 을 찾습니다. property 하나를 추가하거나 제거한 뒤 결과가 변하는 것은 조사 단서이지 모든 parser 의 공통 policy 는 아닙니다.
자주 하는 실수
single quote, comment, trailing comma 가 있는 JavaScript 를 그대로 붙여 넣는 것이 흔한 실수입니다. 표준 JSON 으로 변환하세요.
valid result 를 schema validation 으로 생각하면 안 됩니다. required field, range, permission 은 별도로 확인하세요.
error marker 근처만 고쳐도 해결되지 않을 수 있습니다. 앞부분의 quote 또는 comma 누락이 원인일 수 있습니다.
JSON 을 Python dictionary, YAML, JavaScript object 와 같다고 생각하지 마세요. documented JSON grammar 를 사용하세요.
clipboard 는 smart quote 또는 숨은 control character 를 가져올 수 있습니다. 결과가 다르면 plain text editor 에서 source 를 확인하세요.
제한 사항
문서화된 input 은 하나의 JSON text field 입니다. JSON Schema, business rule, file processing 또는 모든 parser edge case 를 지원한다는 증거는 아닙니다.
duplicate key, 매우 큰 number, document size, encoding 은 필요하면 별도로 test 하세요. library 에 따라 policy 가 다를 수 있습니다.
checker 가 악성 payload 를 안전하게 만들지는 않습니다. server 에는 size limit, nesting limit, resource limit, security review 가 필요합니다.
production runtime, library version, error policy 를 따로 기록하세요. 이 페이지의 일반 결과가 그 evidence 를 대신하지 않습니다.
Examples
간단한 object 허용
이 기본 object 는 valid JSON 인가요?
전체 object 를 보냅니다.
double quote 로 된 name, string, boolean 이 valid object structure 를 만듭니다.
따옴표 없는 이름 거부
unquoted property name 은 왜 invalid 인가요?
source 를 보내 failure 를 확인합니다.
표준 JSON 의 member name 은 double quote 로 감싼 string 이어야 합니다.
중첩 데이터 허용
object 안에 object array 를 넣을 수 있나요?
nested value 를 하나의 document 로 보냅니다.
array, object, number, comma, bracket 이 valid JSON structure 를 만듭니다.
trailing comma 거부
마지막 member 뒤의 comma 는 어떻게 되나요?
trailing comma 가 있는 object 를 보냅니다.
표준 JSON 은 trailing comma 를 허용하지 않습니다. 제거한 뒤 다시 확인하세요.
null 사용
null 은 valid JSON value 인가요?
object 를 보내 status 를 읽습니다.
null 은 표준 JSON value 입니다. application 에서의 의미는 contract 가 정합니다.
bracket 누락 거부
opening bracket 을 닫아야 하는 이유는 무엇인가요?
균형이 맞지 않는 structure 를 보냅니다.
array 는 [ 로 열었지만 ] 로 닫지 않았습니다. data 를 사용하기 전에 nesting 을 수정하세요.
Frequently asked questions
valid JSON 이 application data valid 를 의미하나요?
아니요. text 를 parse 할 수 있다는 뜻뿐입니다. required field, type, range, status, business rule 은 별도로 검사해야 합니다.
validator 가 source 를 자동으로 고치나요?
checker 로 사용하세요. source 를 직접 수정하고 diff 를 저장한 뒤 확인된 copy 를 다시 보냅니다.
comment 를 사용할 수 있나요?
표준 JSON 에서는 사용할 수 없습니다. comment 가 필요하면 다른 source format 에 보관하고 build step 에서 strict JSON 을 생성해 검사하세요.
single quote 가 거부되는 이유는 무엇인가요?
표준 JSON 의 name 과 string 은 double quote 를 사용합니다. JavaScript object 는 수동 치환보다 JSON serializer 로 변환하세요.
이 도구가 JSON Schema 를 검사하나요?
검사하지 않습니다. 올바른 schema 와 draft version 을 사용하는 schema validator 를 별도로 실행하고 syntax result 와 구분해 기록하세요.
top-level value 를 array 로 만들 수 있나요?
JSON 은 array 를 top-level value 로 허용합니다. 하지만 endpoint 가 object 를 요구할 수 있으므로 endpoint contract 를 따로 test 하세요.
duplicate key 는 항상 거부되나요?
공통 policy 는 없습니다. parser 가 첫 값이나 마지막 값을 남기거나 error 를 낼 수 있습니다. duplicate name 을 피하고 실제 consumer 에서 확인하세요.
validation 통과 후 무엇을 하나요?
schema, permission, range, integration test 를 실행하세요. content type, encoding, size, timeout, logging 을 확인하고 redacted payload 를 staging 에서 시험하세요.