CSV를 JSON으로 변환기
CSV나 TSV를 브라우저에서 바로 깔끔한 JSON으로 변환하세요. 첫 행이 키가 되고 구분자는 자동으로 감지되며, 각 값을 텍스트 그대로 둘지 숫자와 불리언으로 타입 변환할지 선택할 수 있습니다. 데이터는 어디에도 업로드되지 않습니다.
구분자
출력
값
첫 행이 각 객체의 키가 됩니다.
변환된 JSON이 여기에 표시됩니다.
CSV를 JSON으로 변환기 사용 방법
- 1
CSV 붙여넣기
한 줄에 한 레코드씩 CSV나 TSV 데이터를 붙여넣으세요. 첫 행에 열 이름을 두면 그 이름이 키가 됩니다.
- 2
구분자 선택
자동으로 두면 쉼표, 세미콜론, 탭을 알아서 감지하고, 원하면 데이터에 맞는 구분자를 직접 고를 수도 있습니다.
- 3
출력 형태 선택
‘객체’를 선택하면 각 행이 헤더를 키로 하는 객체가 되고, ‘행’을 선택하면 각 줄이 단순한 배열로 유지됩니다. 값을 ‘타입’으로 바꾸면 숫자와 불리언이 실제 JSON 타입으로 읽힙니다.
- 4
JSON 복사
포맷된 JSON을 복사해 코드나 API 요청, 설정 파일에 바로 붙여넣으세요.
CSV를 JSON으로 파싱하기: 헤더, 타입, 그리고 불규칙성
CSV는 단순해 보이지만 그렇지 않습니다
쉼표로 구분된 파일은 사소해 보입니다. 값, 쉼표, 줄바꿈뿐이니까요. 그러나 그 단순함이 함정입니다. CSV에는 공식적이고 보편적으로 강제되는 표준이 없습니다. RFC 4180이 흔히 쓰이는 관례를 문서화하고 있지만, 내보내기 도구마다 따옴표 처리, 줄 끝 문자, 구분자에 대해 의견이 갈립니다. 어려운 경우들은 정확히 쉼표에서의 어설픈 분할이 틀리게 처리하는 것들입니다. 값 자체가 쉼표를 담은 경우, 값이 따옴표 문자를 담은 경우, 그리고 값이 여러 줄에 걸친 경우입니다.
진짜 파서는 단지 텍스트를 나누는 것이 아니라 따옴표 규칙을 읽어 그것들을 처리합니다. 큰따옴표로 감싸인 필드는 쉼표와 이스케이프된 따옴표(연달아 적은 두 개의 큰따옴표로 씁니다)를 적법하게 담을 수 있으며, 이 도구는 바로 그것을 존중합니다. "Portland, Oregon"을 담은 칸은 두 열이 되는 대신 한 값으로 남고, 필드 안의 겹친 따옴표는 하나의 리터럴 따옴표로 합쳐집니다. 도구가 재구성하지 못하는 단 한 가지 경우는 따옴표 안에 줄바꿈이 든 값인데, 이는 도구가 파일을 먼저 한 줄씩 레코드로 나누기 때문입니다. 그러니 변환하기 전에 각 레코드를 자기 줄에 두거나, 칸 안의 줄바꿈을 제거하세요.
출력 형태: 객체 배열
표의 자연스러운 JSON 형태는 객체 배열이며, 데이터 행 하나당 객체 하나입니다. CSV의 첫 번째 행은 헤더로 다루어지고, 각 헤더 칸은 모든 객체가 공유하는 키가 됩니다. name, role, city 라는 세 열에 이어 두 데이터 행을 붙여넣으면, 그 세 키가 각 행의 값에 대응된 두 객체의 배열을 얻습니다. 이것이 대부분의 API와 가져오기 스크립트가 기대하는 형태입니다.
데이터에 헤더 행이 없으면 그 대응이 키를 끌어올 곳이 없습니다. rows 출력 모드로 바꾸면 각 줄이 대신 그냥 값들의 배열이 되어, 이름을 지어내지 않고 원시 격자를 보존합니다. 출력 모드를 미리 올바르게 고르면 우연히 첫 데이터 행을 키로 삼은 객체가 생기는 일을 피할 수 있습니다.
여러분이 달리 말하기 전까지 모든 것은 문자열입니다
이것은 CSV를 읽을 때 가장 중요한 단 하나의 주의점입니다. 이 형식은 타입 정보를 전혀 담지 않습니다. 모든 칸이 텍스트입니다. 개입하지 않으면 숫자 42 는 문자열 42 가 되고, 단어 true 는 문자열 true 가 되며, 빈 칸은 빈 문자열이 됩니다. 그 필드에서 진짜 숫자나 불리언을 기대하는 코드는 소리 없이 오작동합니다.
타입 있는 값을 켜면 파서는 평범한 숫자 텍스트를 JSON 숫자로, 단어 true 와 false 를 불리언으로, 단어 null 을 진짜 null 로 승격합니다. 타입 추론은 편리하지만 본질적으로 추정에 기대므로 경계를 살피세요. 앞에 0이 붙은 식별자, 전화번호, 우편번호, 버전 같은 문자열은 기술적으로는 숫자처럼 보이지만 보통 텍스트로 남아야 합니다. 그런 필드에 정확함이 중요할 때는 값을 텍스트로 유지하고 여러분의 코드에서 의도적으로 변환하세요.
구분자 감지와 TSV
모든 구분된 값 파일이 쉼표를 쓰는 것은 아닙니다. 많은 유럽 로캘의 스프레드시트는 쉼표가 소수점 표시라서 세미콜론으로 내보내고, 스프레드시트에서 범위를 그대로 복사하면 보통 탭으로 구분된 값이 나옵니다. Auto 모드는 입력의 첫 줄을 살펴 쉼표, 세미콜론, 탭 가운데 거기서 가장 자주 나타나는 것을 고르므로, 쉼표 파일, 세미콜론 파일, TSV가 모두 설정을 바꾸지 않고 변환됩니다.
자동 감지는 깔끔한 데이터에는 믿을 만하지만, 첫 줄이 우연히 진짜 구분자보다 다른 구분자를 더 많이 담은 파일에는 속을 수 있습니다. 열이 잘못 나오면 추측을 무시하고 구분자를 명시적으로 설정하세요. 그러면 한 단계로 모호함이 사라집니다.
인코딩, BOM, 그리고 다른 보이지 않는 말썽꾼들
스프레드시트 소프트웨어에서 내보낸 파일은 흔히 파일의 맨 처음에 있는 보이지 않는 문자인 바이트 순서 표시(BOM)로 시작합니다. 그대로 두면 그것이 첫 헤더 이름에 들러붙어, id 여야 할 키가 소리 없이 약간 다른 문자열이 되고 id 로 하는 조회가 빗나갑니다. 운영체제 간의 일관되지 않은 줄 끝 문자와 끝에 붙은 빈 줄은 유령 행이나 한 칸씩 어긋난 열을 만들어 내는 또 다른 단골 용의자입니다.
이 도구는 모든 헤더와 칸을 다듬으므로, 흔한 말썽꾼들은 대체로 알아서 처리됩니다. Unix와 Windows 줄 끝 문자를 모두 견디고, 맨 앞의 바이트 순서 표시는 다듬을 수 있는 공백으로 간주되므로 키에 들러붙는 대신 첫 헤더에서 자동으로 제거됩니다. 원시 스프레드시트 내보내기를 여기에 붙여넣으면 대개 그냥 작동하는 이유가 바로 이것입니다. 변환된 키가 코드에서 여전히 일치하기를 거부한다면, 다듬기가 제거하지 못하는 끼어든 문자, 예컨대 폭이 0인 공백을 의심하고, 파일을 평범한 UTF-8로 다시 내보내세요.
들쭉날쭉한 행과 빈 칸
실제 스프레드시트는 엉망입니다. 어떤 행은 끝에 빈 칸이 붙어 있고, 어떤 행은 필드가 통째로 빠져 있으며, 끼어든 빈 줄이 끝에 슬그머니 들어옵니다. 한 행에 헤더보다 값이 적을 때, 빠진 필드는 변환을 중단시키는 대신 빈 문자열로 나타나므로, 출력 배열은 직사각형으로 유지되고 모든 객체가 키 전체 집합을 지닙니다.
결과를 신뢰하기 전에, 값이 한 열씩 밀린 듯 보이는 의심스러운 행이 있는지 훑어보세요. 그것은 상류에서 따옴표로 감싸이지 않은 필드 안에 이스케이프되지 않은 구분자가 있다는 신호입니다. 나중에 JSON을 손보려 애쓰는 것보다, 원본 파일을 고치는 것(문제의 값을 따옴표로 감싸는 것)이 훨씬 더 믿을 만합니다.
CSV-to-JSON이 제값을 하는 곳
가장 흔한 쓰임은 누군가 건넨 스프레드시트를 여러분의 프로그램이 소비할 수 있는 데이터로 바꾸는 것입니다. 데이터베이스를 초기 데이터로 채우거나, API 요청의 본문을 만들거나, 설정 파일을 생성하거나, 테스트 픽스처에 공급하는 것이죠. 비개발자는 스프레드시트에서 살고, 개발자는 JSON에서 살며, 이 변환은 매번 일회용 파서를 쓰지 않고 둘을 잇는 다리입니다.
파싱 전체가 여러분의 브라우저에서 실행되므로, 고객 목록, 내부 지표, 재무 행 같은 민감한 내보내기를 제3자 서비스에 아무것도 업로드하지 않고 변환할 수 있습니다. 하류의 안전을 위해 한 가지 규칙을 명심하세요. 각 열을 타입 있게 할지 텍스트로 둘지 의식적으로 정하세요. 소리 없는 타입 강제 변환은 가져온 데이터가 스프레드시트에서 보였던 것과 다르게 동작하는 가장 흔한 이유이기 때문입니다.
자주 묻는 질문
CSV를 JSON으로 어떻게 변환하나요?
첫 행은 반드시 헤더여야 하나요?
쉼표뿐 아니라 탭이나 세미콜론도 읽을 수 있나요?
숫자와 불리언은 어떻게 처리되나요?
제 데이터가 어딘가로 업로드되나요?
관련 도구
이런 편리한 도구도 함께 사용해 보세요