JSON을 TOML로 바꾸면 null과 날짜는 어떻게 되나요?

사용할 도구

• 도구 열기: JSON ⇔ TOML 변환

작은 기준 설정으로 시작하기

{"name":"demo","enabled":true,"retries":3,"ports":[8000,8001]}

변환 후 name은 문자열, enabled는 불리언, retries는 숫자, ports는 배열인지 확인하고 결과를 다시 JSON으로 바꿉니다. 공백이나 키 표시 순서는 달라도 값과 자료형은 같아야 합니다. demo, 3, 8000/8001을 독립적인 예상값으로 먼저 적어 두세요.

첫 문자가 { 또는 [이면 JSON으로 판단합니다. 따라서 테이블 헤더로 시작하는 TOML은 자동 판별과 충돌합니다. 이 글의 TOML 예제는 키·값 행으로 시작합니다. 판별 실패는 변환 성공이 아니라 도구의 지원 한계로 다루세요.

null을 바꾸기 전에 의미 정하기

{"name":"demo","timeout":null}

TOML에는 null 값이 없어 변환을 거부합니다. 오류를 없애려고 0이나 빈 문자열로 바꾸지 마세요. 0은 대기 없음, 무제한 또는 잘못된 입력일 수 있고 키 생략은 기본값을 뜻할 수 있습니다. 변환기는 앱의 의미를 결정할 수 없습니다.

timeout:null을 생략해 수신 측 기본값을 쓴다는 식으로 의미 변경을 명시하세요. 배열의 null을 지우면 뒤 원소의 위치가 바뀌므로 객체 속성을 삭제하는 것과 영향이 다릅니다.

날짜 문자열과 날짜 값을 왕복하기

name = "demo"
created = 2026-01-02T03:04:05Z
label = "2026-01-02T03:04:05Z"

기본값에서는 날짜 변환을 거부합니다. TOML 날짜를 문자열로 변환하는 옵션을 선택한 뒤 실행하세요. created는 TOML 날짜·시간이고 label은 문자열입니다. JSON에서는 둘 다 날짜 문자열처럼 보여도 다시 바꿀 때 created의 원래 자료형이 복원된다고 보장할 수 없습니다. 같은 모양뿐 아니라 앱이 받는 자료형을 확인해야 합니다.

정규화로 소수초나 오프셋 표기가 달라질 수 있습니다. 같은 시점이어도 로그나 서명에 쓰는 원문은 중요할 수 있습니다. 지역 없는 날짜, 오프셋 시각, 표시용 라벨을 구별하고 시간대를 추측하지 말고 문자열로 유지할 필드를 정하세요.

주석과 실행 값을 따로 검토하기

retries = 3 # temporary limit for the test environment
name = "demo"

주석은 JSON 값으로 옮겨지지 않습니다. retries가 3이어도 왜 3인지에 대한 운영 이유는 사라질 수 있습니다. 숫자 변화는 아니지만 유지보수에 중요하므로 문서로 옮길지 원본과 보관할지 정하세요.

공백과 키 순서도 달라질 수 있습니다. 겉모습 차이와 값 차이를 나누고 필요하면 JSON 구조 비교를 쓰세요. 이것도 주석이나 TOML 고유 자료형의 동등성을 보장하지 않으므로 범위가 분명한 여러 검사를 조합합니다.

큰 정수는 변환기의 한계도 확인하기

{"id":9007199254740993}

JSON 정리에서 보존되는 숫자라도 이 TOML 변환이 모두 지원하지는 않습니다. 이 값은 정확한 변환 범위를 넘어 거부됩니다. 형식의 정수 범위와 구현의 변환 범위는 다릅니다. ID를 반올림해 통과시키지 말고 문자열을 허용하는 계약인지 확인하세요.

숫자, 불리언, 배열, null, 날짜, 주석을 따로 점검하세요. 예제 하나의 성공이 이관 완료는 아니므로 실제 자료형마다 시험합니다. 변환기의 한계를 이유로 계약을 임의로 바꾸지 말고 필요한 정보가 사라진다면 방법이나 형식을 다시 선택하세요.

참고 자료

• TOML v1.0.0 — types (새 탭에서 열립니다)
• @iarna/toml — implementation (새 탭에서 열립니다)

사용할 도구

• JSON ⇔ TOML 변환