CSV가 틀어지는 세 가지 원인: 쉼표·줄바꿈·수식

쉼표로 무조건 나누면 틀리는 이유

예를 들어 상품명 '노트, 파란색'은 한 셀입니다. 이 값을 따옴표로 감싼 CSV를 단순 split(',')로 나누면 상품명 두 조각과 다른 셀이 섞입니다. 파일의 한 줄이 항상 한 행이라고 가정하는 것도 틀릴 수 있습니다. 따옴표 안의 줄바꿈은 같은 셀에 속하기 때문입니다.

파서는 따옴표 내부와 외부를 구분해야 합니다. 외부의 쉼표에서만 셀을 닫고 외부의 줄바꿈에서만 행을 닫습니다. 문자열 자체에 큰따옴표가 있으면 큰따옴표 두 개로 표현합니다. 이 세 가지를 처리하지 않는 변환기는 평범한 예제에서는 맞아도 실제 업무 설명 자료에서 쉽게 깨집니다.

상품,설명
"노트, 파란색","첫 줄
둘째 줄"
"A""B",일반 설명

재현 가능한 입력과 결과

XNTLAB의 구분 텍스트 파서로 쉼표·셀 안 줄바꿈·따옴표 문자를 포함한 입력을 처리해 결과 배열을 비교했습니다. 아래 결과는 테스트 코드로 확인한 예제 값이며 실제 고객 파일을 처리했다는 뜻은 아닙니다.

첫 행의 두 열 구조가 다음 행에서도 유지되어야 합니다. 셀 안 줄바꿈은 새 데이터 행을 만들지 않고 문자열에 남아야 하며, A 뒤의 따옴표가 중복 문자로 출력되지 않아야 합니다. 오류가 생기면 원본을 손으로 다시 저장하기 전에 닫히지 않은 따옴표와 실제 구분기호부터 확인합니다.

입력: name,note
"A,B","line1
line2"
"Q""R",ok
기대 배열:
[["name","note"],["A,B","line1\nline2"],["Q\"R","ok"]]
실행 검증: 기대 배열과 일치

수식처럼 보이는 텍스트는 별도 문제

CSV가 문법적으로 맞아도 Excel이 =SUM(1,1) 같은 값을 수식으로 읽을 수 있습니다. 외부 사용자가 만든 텍스트를 값으로 전달해야 한다면 앞 공백과 제어문자까지 고려해 =, +, -, @ 같은 시작 문자를 검사합니다. 단순히 셀을 큰따옴표로 감싸는 처리는 수식 해석을 막지 않습니다.

XNTLAB의 텍스트 표 도구는 문자열 내보내기 시 위험 시작 문자 앞에 작은따옴표를 덧붙입니다. 이는 원래 텍스트를 일부 바꾸는 보수적 처리입니다. 숫자 -10처럼 음수가 필요한 데이터라면 스키마상 숫자로 인정할지, 문자열로 보존할지 업무 규칙을 먼저 정해야 합니다. 모든 프로그램에서 같은 처리가 보장되지는 않아 최종 소비 프로그램에서도 확인합니다.

Excel에서 열기 전후 검산

가져오기 화면에서 인코딩과 구분기호를 선택한 뒤 주문번호·우편번호 열은 텍스트 형식으로 지정합니다. UTF-8 BOM이 한글 인식에 도움이 되더라도 코드의 앞자리 0까지 보존해 주지는 않습니다. 00123을 일반 숫자로 읽으면 123이 될 수 있으므로 원문 길이를 확인합니다.

원본 데이터 행 수, 실제 결과 행 수, 주요 열 개수와 식별자 길이를 비교합니다. 값이 없는 셀·쉼표가 있는 이름·한글·긴 설명·수식 시작 문자 예제를 모두 포함하세요. 큰 파일은 메모리 제한 때문에 나눠 처리하고 결과 CSV를 다시 파싱하거나 실제 Excel에서 열어 검수하는 것이 좋습니다.

1. 원본 사본 보존
2. 인코딩·구분기호 확인
3. 텍스트 열 형식 지정
4. 행 수·열 수·식별자 검산
5. 수식 안전 처리 확인