정신 잃지 않고 스프레드시트에서 데이터 빼내기

누가 Excel 파일을 이메일로 보내. 애플리케이션은 JSON이 필요해. 간단해야 해.

절대 그렇지 않아.

스프레드시트에 병합된 셀이 있어. 또는 날짜가 이상하게 포맷돼 있어. 또는 숫자 필드여야 하는데 누가 "N/A"를 타이핑한 그 컬럼. 모든 변환이 디버깅 세션이 돼.

덜 고통스럽게 만드는 법이야.

CSV: 범용 번역기

거의 모든 스프레드시트 앱이 CSV로 내보내기 해. 거의 모든 시스템이 CSV를 읽을 수 있어. 데이터 포맷의 최소 공통분모야.

CSV는 그냥 텍스트야: 쉼표로 구분된 값, 개행으로 구분된 행.

name,email,age
John,john@example.com,32
Jane,jane@example.com,28

간단해. 그렇지 않을 때까지는.

쉼표 문제. 값에 쉼표가 포함되면? "Smith, John" 같은 이름이 파싱을 망가뜨려. 해결책: 값을 따옴표로 감싸. 좋은 CSV 도구는 자동으로 처리해. 나쁜 건 안 해.

개행 문제. 값에 줄바꿈이 포함되면? 같은 해결책: 따옴표. 같은 경고: 모든 도구가 처리하는 건 아니야.

인코딩 문제. Windows의 Excel은 Mac의 Excel과 다른 문자 인코딩으로 기본 설정돼. 특수 문자가 손상돼. 가능하면 "CSV UTF-8"로 내보내기 해.

JSON: API가 실제로 원하는 것

웹 애플리케이션은 JSON을 선호해:

[
  {"name": "John", "email": "john@example.com", "age": 32},
  {"name": "Jane", "email": "jane@example.com", "age": 28}
]

CSV에서 JSON으로 변환은 보통 간단해. 첫 행이 프로퍼티 이름이 되고, 다음 행들이 객체가 돼.

문제는 다음 때 발생해:

타입이 사라져. CSV는 전부 문자열이야. "32"는 숫자일 수도 텍스트일 수도. JSON 변환이 추측해야 해. 대부분의 도구는 가정해: 숫자처럼 보이면 아마 숫자.

Null이 애매해. 빈 셀 = null? 빈 문자열? 프로퍼티를 완전히 생략? 도구마다 다르게 결정해.

배열이 존재하지 않아. CSV는 평평해. JSON에 중첩된 배열이 필요하면 수동 작업이야.

흔한 워크플로

1. Excel/Sheets에서 CSV로 내보내기
2. 텍스트 에디터에서 열고 명백한 문제 확인
3. JSON으로 변환
4. JSON 구조 검증
5. 몇 개 레코드 스팟 체크

스팟 체크가 중요해. 자동 변환이 조용히 데이터를 손상시킬 수 있어. 날짜가 숫자가 돼. 우편번호가 앞자리 0을 잃어. "O'Brien"이 "O'Brien"이 돼. 신뢰하기 전에 검증해.

이상한 데이터 처리

날짜. Excel은 날짜를 내부적으로 숫자로 저장해. 내보내기가 "2023-01-15" 대신 "44927"을 만들 수 있어. 변환 전에 날짜 포맷을 알아둬.

텍스트로서의 숫자. 우편번호, 전화번호, ID—이건 숫자처럼 보이지만 숫자로 다뤄지면 안 돼. 앞자리 0이 중요해. 명시적으로 문자열로 변환해.

유니코드. 액센트 있는 이름, 비라틴 스크립트의 데이터. 파이프라인이 UTF-8을 끝에서 끝까지 처리하는지 확인해.

반대 방향으로

JSON에서 CSV로는 정보를 잃어. 중첩된 객체가 어색하게 평평해져. 배열은... 정확히 뭐가 돼? 여러 행? 연결된 문자열?

일관된 구조의 평평한 JSON은 변환이 잘 돼. 복잡한 중첩 데이터는 어떻게 평평하게 할지 결정을 내려야 해. 그 결정을 문서화해.

YAML과 XML

YAML은 JSON의 힙스터 사촌이야. 더 읽기 쉽고, 같은 데이터 구조, 사이 변환 쉬워.

XML은 엔터프라이즈 버전. 장황하고, 구형 시스템에서 널리 지원되고, 더 많은 파싱 노력 필요.

둘 다 JSON으로 변환되고 다시 돌아와. 주요 골칫거리는 XML의 속성 vs 요소야—JSON은 그 구분이 없어.

---

데이터 변환은 뭐가 잘못될 수 있는지 알고 그걸 확인하는 거야. 변환을 자동화하고, 결과를 검증하고, "그냥 작동한다"고 절대 믿지 마.