의견.png

"CSV"의 두 판 사이의 차이

위키원
이동: 둘러보기, 검색
잔글
2번째 줄: 2번째 줄:
  
 
== 개요 ==
 
== 개요 ==
CSV는 오래 전부터 [[스프레드시트]]나 [[데이터베이스]] 소프트웨어에서 많이 쓰였으나 세부적인 구현은 소프트웨어에 따라 다르다. 그것들을 추가한 형태가 2005년 10월 RFC 4180에서 Informational(IESG의 외부에서 결정된 유용한 정보의 제공)로 사양이 문서화됐다.  
+
CSV는 컴퓨터 용어로, 표 형태의 데이터를 저장하는 파일 형식이다. 주로 쓰이는 확장자는 .csv이며 MIME 형식은 text/csv이다. 한글로 '씨에스브이'라고 읽는다. 한 줄이 한 개의 행에 해당하며, 열 사이에는 쉼표(,)를 넣어 구분한다.<ref name="나무1">〈[https://namu.wiki/w/CSV CSV]〉, 《나무위키》</ref> 오래 전부터 [[스프레드시트]]나 [[데이터베이스]] 소프트웨어에서 많이 쓰였으나 세부적인 구현은 소프트웨어에 따라 다르다. 그것들을 추가한 형태가 2005년 10월 RFC 4180에서 Informational(IESG의 외부에서 결정된 유용한 정보의 제공)로 사양이 문서화됐다.  
 +
비슷한 포맷으로는 탭으로 구분하는 'tab-separated values'(TSV)나, 반각 스페이스로 구분하는 'space-separated values'(SSV) 등이 있으며, 이것들을 합쳐서 character-separated values (CSV), delimiter-separated values라고 부르는 경우가 많다.<ref name="위키1">〈[https://ko.wikipedia.org/wiki/CSV_(%ED%8C%8C%EC%9D%BC_%ED%98%95%EC%8B%9D) CSV (파일 형식)]〉, 《위키백과》</ref>
 +
 
 +
==특징==
 +
줄 바꿈 문자는 라인 피드(LF) 또는 캐리지 리턴-라인 피드(CRLF)를 사용한다.
 +
표의 형태를 직관적으로 나타내는 간단한 형식이라 이해하기 쉬우며, 소프트웨어로 처리하는 것도 쉽다. 텍스트 기반 형식이라 사람이 직접 읽고 수정하는 것도 가능하다. XML과 같은 다른 텍스트 기반 형식에 비해 간결해서 차지하는 용량도 적다. 이런 표현이 익숙하지 않은 사람들을 위해, CSV를 표 기반으로 바꿔서 보여주는 툴도 많은 편이다.
 +
단점은 데이터에 쉼표가 포함된 내용을 취급하기 곤란하다는 것. 예를 들어 천 단위마다 쉼표를 찍어 놓은 금액 데이터를 CSV에 직접 집어넣으면 나중에 해석할 때 서로 다른 열로 취급되므로 문제가 된다. 해결책은 쉼표가 포함된 문자열을 따옴표로 감싸거나, 쉼표 대신 탭 문자(\t)를 구분자로 사용하는 것이다. 후자의 경우 TSV(Tab-Separated Values)라고 부른다.<ref name="위키1">〈[https://ko.wikipedia.org/wiki/CSV_(%ED%8C%8C%EC%9D%BC_%ED%98%95%EC%8B%9D) CSV (파일 형식)]〉, 《위키백과》</ref>
 +
CSV라는 데이터 구조 자체에 무슨 표준이 있는 것은 아니라서 구분자를 뭘로 쓰든 데이터를 주고받는 사이에 약속만 지키면 된다. CSV에서 사용하는 특수 문자는 필드 구분자와 레코드 구분자 둘 뿐이고 인용이나 이스케이프 문자는 선택 사항이다. 일반적으로 데이터 생산자가 CSV데이터의 성격을 보고 필드 안에 들어갈 확률이 가장 적은 문자를 필드 구분자로 정한다. 레코드 구분자 역시 필드에 줄바꿈이 자주 쓰일 경우 라인 피드 대신 널 문자(NULL)를 쓰기도 한다.<ref name="위키1">〈[https://ko.wikipedia.org/wiki/CSV_(%ED%8C%8C%EC%9D%BC_%ED%98%95%EC%8B%9D) CSV (파일 형식)]〉, 《위키백과》</ref>
 +
일반적으로 CSV파일의 무결성을 검증할 때는 한 줄의 콤마 수를 센다. 모든 줄의 콤마 수는 다 같아야 하며 더 적거나 더 많은 줄이 발견되면 오류로 판단해 걸러내는 등의 적절한 처리를 할 필요가 있다. 가장 일반적으로 발견되는 오류는 다음과 같다.<ref name="위키1">〈[https://ko.wikipedia.org/wiki/CSV_(%ED%8C%8C%EC%9D%BC_%ED%98%95%EC%8B%9D) CSV (파일 형식)]〉, 《위키백과》</ref>
 +
 
 +
* 내용에 콤마가 들어가서 한 줄의 콤마 수가 몇 개 늘어나는 경우
 +
* 줄바꿈 문자가 누락돼 한 줄의 콤마 수가 두 배로 늘어나는 경우
 +
* 내용에 줄바꿈 문자가 들어가서 두 줄 이상의 콤마 수가 정상보다 적은 경우
 +
* 줄바꿈 문자의 캐리지 리턴(CR)을 걸러내지 못해 마지막 필드의 데이터가 깨지는 경우
 +
* 따옴표가 정상적으로 닫히지 않아 임의의 필드와 레코드가 한 필드 안에 인용돼 들어간 경우
 +
* 마지막 줄의 라인 피드 누락으로 마지막 줄 데이터를 읽지 못한 경우
 +
* 첫 줄에 헤더 텍스트가 들어간 CSV를 사용할 때 첫 줄을 건너뛰지 않은 경우
 +
 
 +
가장 나쁜 경우는 CSV의 필드 안에 게시판 본문 데이터를 그냥 담는 것이다. 게시글 본문에는 쉼표, 따옴표, 줄바꿈문자가 모두 들어가기 때문에 데이터가 어떻게 손실되었는지, 혹은 데이터가 손실된 레코드인지조차 모를 수도 있다. 게시글 본문 내용 자체가 CSV데이터일 경우 존재하지 않는 게시글이 하나 등록될 수 있다. CSV 인젝션(Injection)의 경우에는 아예 CSV 자체를 쓰지 않는 것이 좋다. 게시판 본문 데이터가 HTML일 경우가 XML을 써도 힘들다.<ref name="위키1">〈[https://ko.wikipedia.org/wiki/CSV_(%ED%8C%8C%EC%9D%BC_%ED%98%95%EC%8B%9D) CSV (파일 형식)]〉, 《위키백과》</ref>
 +
테이블 덤프 등의 이유로 CSV가 꼭 필요하다면 게시판 본문 데이터 전체를 URI Encode하고 무조건 따옴표로 인용하면 데이터 크기가 커지고 편집기로 직접 못 읽지만 어쨌든 문제를 회피할 수 있다. 자바스크립트 사용자라면 encodeURI가 아닌 encodeURIComponent함수를 써야 제대로 이스케이프 처리된다.<ref name="위키1">〈[https://ko.wikipedia.org/wiki/CSV_(%ED%8C%8C%EC%9D%BC_%ED%98%95%EC%8B%9D) CSV (파일 형식)]〉, 《위키백과》</ref>
 +
보다시피 데이터 오염에 대단히 취약한 포맷이다 보니 본격적인 데이터 교환 포맷으로는 XML과 JSON을 쓴다. 둘 중 XML이 상대적으로 데이터 오염에 잘 견딘다. 하지만 CSV는 2017년 현재도 IT 및 산업계에서 널리 사용중인데 가장 결정적인 이유는 데이터의 크기가 작기 때문이다. JSON만 돼도 CSV대비 2배에서 3배 이상 데이터의 크기가 커지는데데 비해 CSV 파서(parser)는 대단히 간단해서 인용 및 이스케이프 처리를 하지 않는 CSV 파서는 대부분의 프로그래밍 언어에서 코드 한 줄로 가능하다. 게다가 파일 일부에 문제가 생겨도 CSV의 오류는 보통 레코드 단위로 재동기화가 가능하다. JSON은 따옴표나 중괄호 같은 게 하나라도 누락되면 전체 JSON파일의 로드에 실패하는 치명적인 문제가 있다. XML의 경우에는 보통 문제가 생긴 엘리먼트의 부모 엘리먼트에까지만 오류가 전파되므로 CSV보다 더 강한 내결함성이 있지만 JSON보다도 데이터의 크기가 커져버린다. 만약 로드하려는 데이터가 기가바이트 단위를 바라본다면 몇 퍼센트의 데이터 오버헤드도 무시할 수 없는 문제가 되는데 이런 분야에서 CSV가 활약하는 것이다. 덤으로 CSV는 압축도 잘 되고 스트림 압축이 가능해서 데이터의 일부만 수신된 상태에서도 데이터 적재 작업을 시작할 수 있다.<ref name="위키1">〈[https://ko.wikipedia.org/wiki/CSV_(%ED%8C%8C%EC%9D%BC_%ED%98%95%EC%8B%9D) CSV (파일 형식)]〉, 《위키백과》</ref>
  
비슷한 포맷으로는 탭으로 구분하는 'tab-separated values'(TSV)나, 반각 스페이스로 구분하는 'space-separated values'(SSV) 등이 있으며, 이것들을 합쳐서 character-separated values (CSV), delimiter-separated values라고 부르는 경우가 많다.<ref name="위키1">〈[https://ko.wikipedia.org/wiki/CSV_(%ED%8C%8C%EC%9D%BC_%ED%98%95%EC%8B%9D) CSV (파일 형식)]〉, 《위키백과》</ref>
 
  
 
{{각주}}
 
{{각주}}
  
 
==참고자료==
 
==참고자료==
 +
*〈[https://namu.wiki/w/CSV CSV]〉, 《나무위키》
 
*〈[https://ko.wikipedia.org/wiki/CSV_(%ED%8C%8C%EC%9D%BC_%ED%98%95%EC%8B%9D) CSV (파일 형식)]〉, 《위키백과》
 
*〈[https://ko.wikipedia.org/wiki/CSV_(%ED%8C%8C%EC%9D%BC_%ED%98%95%EC%8B%9D) CSV (파일 형식)]〉, 《위키백과》
 +
  
 
{{프로그래밍|토막글}}
 
{{프로그래밍|토막글}}

2020년 9월 4일 (금) 10:23 판

CSV(씨에스브이)는 "Comma-Separated Values"의 약자로서, 몇 가지 필드를 쉼표(,)로 구분한 텍스트 데이터 및 텍스트 파일이다. 확장자는 .csv이며 MIME 형식은 text/csv이다. comma-separated variables라고도 한다.

개요

CSV는 컴퓨터 용어로, 표 형태의 데이터를 저장하는 파일 형식이다. 주로 쓰이는 확장자는 .csv이며 MIME 형식은 text/csv이다. 한글로 '씨에스브이'라고 읽는다. 한 줄이 한 개의 행에 해당하며, 열 사이에는 쉼표(,)를 넣어 구분한다.[1] 오래 전부터 스프레드시트데이터베이스 소프트웨어에서 많이 쓰였으나 세부적인 구현은 소프트웨어에 따라 다르다. 그것들을 추가한 형태가 2005년 10월 RFC 4180에서 Informational(IESG의 외부에서 결정된 유용한 정보의 제공)로 사양이 문서화됐다. 비슷한 포맷으로는 탭으로 구분하는 'tab-separated values'(TSV)나, 반각 스페이스로 구분하는 'space-separated values'(SSV) 등이 있으며, 이것들을 합쳐서 character-separated values (CSV), delimiter-separated values라고 부르는 경우가 많다.[2]

특징

줄 바꿈 문자는 라인 피드(LF) 또는 캐리지 리턴-라인 피드(CRLF)를 사용한다. 표의 형태를 직관적으로 나타내는 간단한 형식이라 이해하기 쉬우며, 소프트웨어로 처리하는 것도 쉽다. 텍스트 기반 형식이라 사람이 직접 읽고 수정하는 것도 가능하다. XML과 같은 다른 텍스트 기반 형식에 비해 간결해서 차지하는 용량도 적다. 이런 표현이 익숙하지 않은 사람들을 위해, CSV를 표 기반으로 바꿔서 보여주는 툴도 많은 편이다. 단점은 데이터에 쉼표가 포함된 내용을 취급하기 곤란하다는 것. 예를 들어 천 단위마다 쉼표를 찍어 놓은 금액 데이터를 CSV에 직접 집어넣으면 나중에 해석할 때 서로 다른 열로 취급되므로 문제가 된다. 해결책은 쉼표가 포함된 문자열을 따옴표로 감싸거나, 쉼표 대신 탭 문자(\t)를 구분자로 사용하는 것이다. 후자의 경우 TSV(Tab-Separated Values)라고 부른다.[2] CSV라는 데이터 구조 자체에 무슨 표준이 있는 것은 아니라서 구분자를 뭘로 쓰든 데이터를 주고받는 사이에 약속만 지키면 된다. CSV에서 사용하는 특수 문자는 필드 구분자와 레코드 구분자 둘 뿐이고 인용이나 이스케이프 문자는 선택 사항이다. 일반적으로 데이터 생산자가 CSV데이터의 성격을 보고 필드 안에 들어갈 확률이 가장 적은 문자를 필드 구분자로 정한다. 레코드 구분자 역시 필드에 줄바꿈이 자주 쓰일 경우 라인 피드 대신 널 문자(NULL)를 쓰기도 한다.[2] 일반적으로 CSV파일의 무결성을 검증할 때는 한 줄의 콤마 수를 센다. 모든 줄의 콤마 수는 다 같아야 하며 더 적거나 더 많은 줄이 발견되면 오류로 판단해 걸러내는 등의 적절한 처리를 할 필요가 있다. 가장 일반적으로 발견되는 오류는 다음과 같다.[2]

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

가장 나쁜 경우는 CSV의 필드 안에 게시판 본문 데이터를 그냥 담는 것이다. 게시글 본문에는 쉼표, 따옴표, 줄바꿈문자가 모두 들어가기 때문에 데이터가 어떻게 손실되었는지, 혹은 데이터가 손실된 레코드인지조차 모를 수도 있다. 게시글 본문 내용 자체가 CSV데이터일 경우 존재하지 않는 게시글이 하나 등록될 수 있다. CSV 인젝션(Injection)의 경우에는 아예 CSV 자체를 쓰지 않는 것이 좋다. 게시판 본문 데이터가 HTML일 경우가 XML을 써도 힘들다.[2] 테이블 덤프 등의 이유로 CSV가 꼭 필요하다면 게시판 본문 데이터 전체를 URI Encode하고 무조건 따옴표로 인용하면 데이터 크기가 커지고 편집기로 직접 못 읽지만 어쨌든 문제를 회피할 수 있다. 자바스크립트 사용자라면 encodeURI가 아닌 encodeURIComponent함수를 써야 제대로 이스케이프 처리된다.[2] 보다시피 데이터 오염에 대단히 취약한 포맷이다 보니 본격적인 데이터 교환 포맷으로는 XML과 JSON을 쓴다. 둘 중 XML이 상대적으로 데이터 오염에 잘 견딘다. 하지만 CSV는 2017년 현재도 IT 및 산업계에서 널리 사용중인데 가장 결정적인 이유는 데이터의 크기가 작기 때문이다. JSON만 돼도 CSV대비 2배에서 3배 이상 데이터의 크기가 커지는데데 비해 CSV 파서(parser)는 대단히 간단해서 인용 및 이스케이프 처리를 하지 않는 CSV 파서는 대부분의 프로그래밍 언어에서 코드 한 줄로 가능하다. 게다가 파일 일부에 문제가 생겨도 CSV의 오류는 보통 레코드 단위로 재동기화가 가능하다. JSON은 따옴표나 중괄호 같은 게 하나라도 누락되면 전체 JSON파일의 로드에 실패하는 치명적인 문제가 있다. XML의 경우에는 보통 문제가 생긴 엘리먼트의 부모 엘리먼트에까지만 오류가 전파되므로 CSV보다 더 강한 내결함성이 있지만 JSON보다도 데이터의 크기가 커져버린다. 만약 로드하려는 데이터가 기가바이트 단위를 바라본다면 몇 퍼센트의 데이터 오버헤드도 무시할 수 없는 문제가 되는데 이런 분야에서 CSV가 활약하는 것이다. 덤으로 CSV는 압축도 잘 되고 스트림 압축이 가능해서 데이터의 일부만 수신된 상태에서도 데이터 적재 작업을 시작할 수 있다.[2]


각주

  1. CSV〉, 《나무위키》
  2. 2.0 2.1 2.2 2.3 2.4 2.5 2.6 CSV (파일 형식)〉, 《위키백과》

참고자료


  의견.png 이 CSV 문서는 프로그래밍에 관한 토막글입니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 이 문서의 내용을 채워주세요.