table_view CSV ↔ JSON 변환기 star

실제로 변환이 이루어지는 방식

CSV와 JSON은 데이터를 서로 다르게 모델링하며, 어느 방향으로 변환하느냐에 따라 얼마나 많은 추측이 필요한지가 달라집니다. CSV → JSON은 거의 기계적입니다: 헤더 행이 키 집합이 되고, 이어지는 각 행은 그 키들을 가진 하나의 객체가 됩니다 — name,age 아래 Ada,36이 있으면 [{"name":"Ada","age":"36"}]이 됩니다. 쉼표를 포함한 따옴표 필드, 이스케이프된 따옴표(""), 여러 줄에 걸친 셀은 RFC 4180 규격에 따라 파싱되며, 구분자(쉼표, 세미콜론, 탭)는 첫 줄에서 자동으로 감지됩니다.

진짜 어려움은 JSON → CSV에 있습니다. CSV는 철저히 평면적입니다 — 한 행, 하나의 레코드, 셀 하나에 값 하나 — 반면 JSON은 본래 중첩을 지원합니다: 객체는 다른 객체나 배열을 필드 값으로 가질 수 있으며, 이를 CSV 셀 하나에 어떻게 욱여넣을지에 대해 모두가 동의하는 방법은 없습니다. {"name":"Ada","address":{"city":"London"}}를 예로 들면 — 열 이름을 address.city로 지어(점 표기법으로 중첩 객체를 추가 열로 평탄화) 해야 할까요, 아니면 address 값 전체를 {"city":"London"}처럼 한 셀에 원시 JSON 문자열로 담아야 할까요? 두 방식 모두 실제로 쓰이고 있으며 어느 쪽도 "유일한" 표준은 아닙니다. 이 도구는 한 단계 중첩까지는 점 표기법을 쓰고, 배열이나 더 깊은 구조에는 JSON 텍스트를 그대로 담는 방식으로 되돌아갑니다 — 단순한 객체는 진짜 스프레드시트에 적합하게 유지하면서도 복잡한 객체에서는 데이터를 조용히 잃지 않기 위해서입니다.

새겨 둘 점이 있습니다: 이것은 도구의 결함이 아니라 데이터 모델 자체의 간극입니다. 어떤 CSV↔JSON 변환기를 시도하더라도 — 이 도구를 포함해서 — 평탄화에 대해 편집상의 판단을 내릴 수밖에 없습니다. 두 형식이 애초에 완벽하게 상호 교환되도록 설계되지 않았기 때문입니다. CSV는 표 형태의 장부를 위해 만들어졌고, JSON은 임의의 형태를 가진 문서를 위해 만들어졌습니다. 이를 미리 알고 있으면, 복잡한 JSON 파일을 CSV로 변환했다가 다시 되돌렸을 때 정확한 원래 구조가 거의 재현되지 않는 이유와, 깊이 중첩된 데이터를 JSON 형태 그대로 유지하는 편이 극복해야 할 제약이 아니라 대체로 올바른 선택인 이유를 이해할 수 있습니다.

알아두면 좋은 점

• CSV에는 데이터 타입이 없습니다. 숫자 변환 옵션을 켜지 않는 한 모든 값은 텍스트로 왕복하며, 이 옵션을 켜면 숫자처럼 보이는 문자열이 실제 JSON 숫자로 바뀝니다(단, "007"처럼 앞자리가 0인 ID는 변환하면 값이 훼손되므로 문자열로 그대로 남습니다).
• 구분자는 추측이 아니라 자동 감지됩니다. 엑셀은 여러 유럽 및 터키 지역 설정에서 세미콜론으로 내보내는데, 그 지역에서는 쉼표가 이미 소수점 구분 기호로 쓰이기 때문입니다 — 파서는 헤더 행을 확인해 올바른 구분자를 고릅니다.
• JSON → CSV는 모든 객체의 키를 합집합으로 모읍니다. 일부 레코드에만 있는 필드가 있으면, 헤더에는 배열 어디에서든 나타난 모든 키가 포함되고, 없는 값은 해당 행에서 빈칸으로 남습니다.
• 아무것도 브라우저 밖으로 나가지 않습니다. 파싱과 변환 모두 JavaScript로 로컬에서 이뤄지므로, 민감한 데이터를 붙여넣어도 어디로도 전송되지 않습니다.
• 행 순서는 양방향 모두 유지됩니다. 첫 번째 데이터 행은 어느 방향으로 변환하든 변환 후에도 첫 번째로 남으며, 스프레드시트나 후속 스크립트가 명시적인 정렬 키가 아니라 위치 순서에 의존할 때 중요합니다.