CSV

1. Comma Separated Values
2. 경영학 용어
3. 전자담배의 한 종류

1. Comma Separated Values

컴퓨터 용어로, 표 형태의 데이터를 저장하는 파일 형식이다. 주로 쓰이는 확장자는 .csv이며 MIME 형식은 text/csv이다. 한글로 '씨에스브이'라고 읽는다.

한 줄이 한 개의 행에 해당하며, 열 사이에는 쉼표(,)를 넣어 구분한다.

예를 들어 학생기록부에 아래와 같은 데이터가 있다고 하자.

이름

생년

국어 점수

영어 점수

수학 점수

홍길동

1992년

7월

17일

100점

90점

70점

희동이

1992년

4월

3일

90점

100점

100점

위의 데이터를 CSV 형식으로 저장하면 아래와 같은 형태가 된다.

이름,생년,월,일,국어 점수,영어 점수,수학 점수
홍길동,1992,7,17,100,90,70
희동이,1992,4,3,90,100,100

줄 바꿈 문자는 라인 피드(LF) 또는 캐리지 리턴-라인 피드(CRLF)를 사용한다.

표의 형태를 직관적으로 나타내는 간단한 형식이라 이해하기 쉬우며, 소프트웨어로 처리하는 것도 쉽다. 텍스트 기반 형식이라 사람이 직접 읽고 수정하는 것도 가능하다. XML과 같은 다른 텍스트 기반 형식에 비해 간결해서 차지하는 용량도 적다.

단점은 데이터에 쉼표가 포함된 내용을 취급하기 곤란하다는 것. 예를 들어 천 단위마다 쉼표를 찍어 놓은 금액 데이터(100,000)를 CSV에 직접 집어넣으면 나중에 해석할 때 서로 다른 열로 취급되므로 문제가 된다. 해결책은 쉼표가 포함된 문자열을 따옴표로 감싸거나, 쉼표 대신 탭 문자(\\t)를 구분자로 사용하는 것이다. 후자의 경우 Tab-Separated Values(TSV)라고 부른다.

사실 CSV라는 데이터 구조 자체에 무슨 표준이 있는 것은 아니라서 구분자를 뭘로 쓰든 데이터를 주고받는 사이에 약속만 지키면 된다. CSV에서 사용하는 특수 문자는 필드 구분자와 레코드 구분자 둘 뿐이고 인용이나 이스케이프 문자는 선택 사양이다. 일반적으로 데이터 생산자가 CSV데이터의 성격을 보고 필드 안에 들어갈 확률이 가장 적은 문자를 필드 구분자로 정한다. 레코드 구분자 역시 필드에 줄바꿈이 자주 쓰일 경우 라인 피드 대신 널 문자(NULL)를 쓰기도 한다.[1]

일반적으로 CSV파일의 무결성을 검증할 때는 한 줄의 콤마 수를 센다. 모든 줄의 콤마 수는 다 같아야 하며 더 적거나 더 많은 줄이 발견되면 오류로 판단해 걸러내는 등의 적절한 처리를 할 필요가 있다. 가장 일반적으로 발견되는 오류는 다음과 같다.

- 내용에 콤마가 들어가서 한 줄의 콤마 수가 몇 개 늘어나는 경우- 줄바꿈 문자가 누락돼 한 줄의 콤마 수가 두 배로 늘어나는 경우- 내용에 줄바꿈 문자가 들어가서 두 줄 이상의 콤마 수가 정상보다 적은 경우- 줄바꿈 문자의 캐리지 리턴(CR)을 걸러내지 못해 마지막 필드의 데이터가 깨지는 경우- 따옴표가 정상적으로 닫히지 않아 임의의 필드와 레코드가 한 필드 안에 인용돼 들어간 경우- 마지막 줄의 라인 피드 누락으로 마지막 줄 데이터를 읽지 못한 경우- 첫 줄에 헤더 텍스트가 들어간 CSV를 사용할 때 첫 줄을 건너뛰지 않은 경우

최악은 CSV의 필드 안에 게시판 본문 데이터를 그냥 담는 것이다. 게시글 본문에는 쉼표, 따옴표, 줄바꿈문자가 모두 들어가기 때문에 데이터가 어떻게 깨졌는지, 심지어는 이게 깨진 레코드인지조차 모를 수도 있다. 예를 들어 게시글 본문 내용 자체가 CSV데이터일 경우 존재하지도 않는 유령 게시글이 하나 등록될 수 있다. CSV Injection 이 경우에는 아예 CSV 자체를 안 쓰는 게 정신건강에 좋다. 참고로 게시판 본문 데이터가 HTML일 경우가 끝판왕으로 XML을 써도 힘들다.[2][3]

테이블 덤프 등의 이유로 무조건 CSV를 써야 한다면 아예 게시판 본문 데이터 전체를 URI Encode하고 무조건 따옴표로 인용하면 데이터 크기가 커지고 편집기로 직접 못 읽지만 어쨌든 문제를 회피할 수 있다. 자바스크립트 사용자라면 encodeURI가 아닌 encodeURIComponent함수를 써야 제대로 이스케이프 처리된다.

보다시피 데이터 오염에 대단히 취약한 포맷이다 보니 본격적인 데이터 교환 포맷으로는 XMLJSON을 쓴다. 둘 중 XML이 상대적으로 데이터 오염에 더 잘 견딘다. 하지만 CSV는 2017년 현재도 IT 및 산업계에서 널리 사용중인데 가장 결정적인 이유는 데이터의 크기가 작기 때문이다. JSON만 돼도 CSV대비 2배에서 3배 이상 데이터의 크기가 커지기 일쑤인데다 CSV 파서(parser)는 대단히 간단해서 인용 및 이스케이프 처리를 하지 않는 CSV 파서는 대부분의 프로그래밍 언어에서 코드 한 줄로 가능하다. 게다가 파일 일부에 문제가 생겨도 CSV의 오류는 보통 레코드 단위로 재동기화가 가능하다. JSON은 따옴표나 중괄호 같은 게 하나라도 누락되면 전체 JSON파일의 로드에 실패하는 치명적인 문제가 있다. XML의 경우에는 보통 문제가 생긴 엘리먼트의 부모 엘리먼트에까지만 오류가 전파되므로 CSV보다 더 강한 내결함성이 있지만 JSON보다도 더 데이터의 크기가 커져버린다. 만약 로드하려는 데이터가 기가바이트 단위를 바라본다면 몇 퍼센트의 데이터 오버헤드도 무시할 수 없는 문제가 되는데 이런 분야에서 CSV가 활약하는 것이다. 덤으로 CSV는 압축도 잘 되고 스트림 압축이 가능해서 데이터의 일부만 수신된 상태에서도 데이터 적재 작업을 시작할 수 있다.[4]

2. 경영학 용어

Creating Shared Values

3. 전자담배의 한 종류

Closed System Vaporizor 참조.


  1. [1] 하지만 레코드 구분자에 손대면 표준 텍스트 에디터로 내용 확인이 거의 불가능해지기 때문에 필드에 줄바꿈 문자가 자주 등장할 경우 CSV말고 다른 포맷을 고려한다.
  2. [2] CDATA로 이스케이핑한다. 본문 내에 CDATA를 쓴 경우에는 필터로 날려버리거나 HTML엔티티로 이스케이프하고 저장한다.
  3. [3] 모든 텍스트 기반 자료구조를 다룰 때는 해당 자료구조의 필드에 '자기 자신의 데이터'를 담는 경우를 염두에 둬야 한다. 아예 처음부터 입력을 막거나 또는 이스케이프 방법을 제공해야만 한다. 바이너리 기반 자료구조는 보통 데이터 필드의 정확한 길이를 해당 필드를 읽기 전에 알 수 있도록 배려하기 때문에 이런 문제가 덜하다.
  4. [4] XML도 SAX 파서 사용시 스트림 전송이 가능하다