CSV 파일에서 쉼표가 잘못된 레코드 구분 기호 / 구분 기호 인 이유는 무엇입니까?

32

나는 이 기사를 읽고 있었고이 질문에 대한 올바른 대답이 궁금합니다.

내 마음에 오는 유일한 것은 아마도 일부 국가에서는 소수점 구분 기호가 쉼표이며 CSV로 데이터를 공유 할 때 문제가 될 수 있지만 실제로 내 대답은 확실하지 않습니다.

project-management

— 데이비드 가스 케스
소스

6

거의 모든 구분자가 쉼표보다 낫습니다. 그 이유는 쉼표로 구분 된 파일을 일부 데이터 구문 분석 도구로 읽을 때 쉼표와 구두점을 혼동하여 필드 나 열의 "레이아웃"을 방해 할 수 있기 때문입니다.

— Mike Hunter

33

이 기사가 SAS 퍼프 조각이라는 사실에 주목 한 냉소는 아마도 SAS가 쉼표로 CSV 파일을 처리하는 데 문제가 있음을 시사합니다 :-).

— whuber

3

@whuber-SAS (제 경험상)는 CSV 파일과 쉼표가 있는지 여부에 관계없이 SAS가 좋아하지 않는 모든 이상한 일에 대해 엄청난 양의 핸드 코딩이 필요합니다.

— Jeremy Miles

8

파이프, 필로우, 가시 등 점점 더 모호한 구분 기호를 찾는 데 절망이 있습니다 . 표준에 동의하고 따르는 것이 사람들이 구분 된 텍스트 파일로 데이터를 교환 할 수있는 유일한 안전한 방법임을 제안합니다. 그리고 범용 표준은 RFC4180과 같이 텍스트 문자열을 표현할 수 있도록 허용해야하며, 일부는 다른 작업에 필요하지 않을 수 있다는 가정에 의존하지 않습니다.

— Scortchi-Monica Monica 복원

2

(a) .csv 파일을 자주 가져 왔습니다. (b) 데이터에 쉼표가 있으면 .csv를 사용하지 않는 것이 좋습니다. 이들은 서로 모순되지 않습니다. 불행히도 (b) 일부 분기에는 설명이 필요합니다.

— Nick Cox

33

CSV 형식 사양은 RFC 4180에 정의되어 있습니다. 이 사양은

CSV 파일에 대한 다양한 해석을 허용하는 공식 사양이 없습니다.

불행히도, 2005 년 이후 (RFC 게시일) 아무런 변화가 없었습니다. 우리는 여전히 다양한 구현을 가지고 있습니다. RFC 4180에 정의 된 일반적인 방법은 쉼표와 같은 문자가 포함 된 필드를 따옴표로 묶는 것입니다. 그러나이 권장 사항이 항상 다른 소프트웨어에 의해 충족되는 것은 아닙니다.

문제는 다양한 유럽 로케일에서 쉼표 문자가 소수점 역할을하므로 0,005대신 대신 쓰는 것입니다 0.005. 그러나 다른 경우에는 공백 대신 쉼표를 사용하여 숫자 그룹에 신호를 보냅니다 4,000,000.00( 예 : 여기 참조 ). 두 경우 모두 쉼표를 사용하면 소프트웨어가 실제로 0,005, 0,1두 개의 숫자인지 네 개의 다른 숫자 인지 알 수 없기 때문에 csv 파일에서 데이터를 읽는 데 오류가 발생할 수 있습니다 ( 여기의 예제 참조 ).

마지막으로 데이터 파일에 텍스트를 저장하면 세미콜론과 같이 텍스트에서 쉼표가 훨씬 일반적이므로 텍스트를 따옴표로 묶지 않으면 이러한 데이터를 쉽게 읽을 수 있습니다. .

위에서 설명한 문제를 방지하는 RFC 4180과 같은 권장 사항에 따라 CSV 파일을 사용 하는 한 쉼표를 개선하거나 필드 구분 기호 를 악화시키는 것은 없습니다 . 그러나 필드를 따옴표로 묶지 않는 단순화 된 CSV 형식을 사용할 위험이 있거나 권장 사항을 일관되지 않게 사용할 수있는 경우 다른 구분 기호 (예 : 세미콜론)가 더 안전한 접근 방식 인 것 같습니다.

— 팀
소스

6

RFC 4180에 정의 된대로 실제 CSV 표준을 구현하는 모든 소프트웨어는 주어진 문자열을 해석하는 방법을 정확히 알고있을 것입니다. ,드문 구분 기호 대신 사용 하면 데이터를 항상 탈출해야하기 때문에 데이터가 부풀려진 다는 주장 은 사실입니다. 그리고 CSV가 어떻게 작동하는지 알고 있지만 실제로는 그렇지 않다고 생각하는 사람들이 있습니다.

— Voo

2

예 @Voo하지만, 때문에 "CSV"파일이 같은 혼란스러운 방식으로 사용이 쉼표를 사용하는 대신 그들을 예를 들어 세미콜론 다른 구분 기호를 사용하지 않는 것이 안전합니다. 이것이 OP 질문에 대한 답변입니다. 세미콜론 (또는 쉼표가 아닌 다른)에는 쉼표와 비교할 때 "더 나은"것이 없으며, 많은 경우에 단지 더 안전한 선택입니다.

— 팀

2

귀하의 의견에 @Voo +1. 그러나 CSV를 사용하는 사람은 실제로 부풀린 데이터 파일에 신경 쓰지 않습니다!

— whuber

17

기술적으로 쉼표는 구분 기호로 사용되는 다른 문자만큼 좋습니다. 형식의 이름은 값이 쉼표로 구분됨 (쉼표로 구분 된 값)을 직접 나타냅니다.

CSV 형식에 대한 설명은 쉼표를 구분 기호로 사용합니다.

쉼표를 포함하는 모든 필드는 큰 따옴표로 묶어야합니다. 따라서 데이터를 읽는 데 문제가 발생하지 않습니다. 설명 에서 6 점을 참조하십시오 .

줄 바꿈 (CRLF), 큰 따옴표 및 쉼표가 포함 된 필드는 큰 따옴표로 묶어야합니다.

예를 들어 함수 read.csv와 write.csvR의 기본 설정은 쉼표를 구분 기호로 사용하는 것입니다.

— djhurio
소스

4

이것이 values쉼표로 구분되어 있기 때문에 가장 좋은 대답 입니다. 유럽 formatting의 숫자를 암시하는 다른 사람들 은 standard위의 포인트 6을 올바르게 인용 하기 때문에 csv에는 문제가되지 않습니다 . "올바른 사용"의 차이는 모든 데이터 형식에 존재합니다. 요점은-당신의 데이터를 알고있다. 다른 사람들은 언급 tab하거나 ;구분하지만 사용자가 입력 한 데이터를 처리 할 때 쉼표와 동일한 문제가 발생할 수 있습니다 (아마 양식을 통해 데이터베이스에 의해 캡처 됨) 뚱뚱한 손가락을 가졌다 tab... 짜증 난다)

— Adrian Torrie

@djhurio가 제공 한 정보를 포함하도록 Tim의 답변이 편집되었습니다.

— Adrian Torrie

11

숫자로 된 숫자 구분자 일뿐 아니라 많은 국가에서 주소 (예 : 고객 주소 등)의 일부이기도합니다. 일부 국가에는 잘 정의 된 주소가 짧지 만 다른 국가에는 같은 줄에 두 개의 쉼표가 포함 된 긴 주소가 있습니다. 좋은 CSV 파일은 이러한 모든 데이터를 큰 따옴표로 묶습니다. 그러나 지나치게 단순하고 불완전하게 작성된 파서는 읽기와 차별화를 제공하지 않습니다. (그러면시의 인용과 같이 데이터의 일부로 큰 따옴표를 사용하는 데 문제가 있습니다).

— 소용돌이 마음
소스

2

(+1)이 표준은 "Belloc", "Tarantella", "" "하이 피레네 산맥을 괴롭히는 벼룩" "을 다시 두 번 주장하여 데이터의 일부로 큰 따옴표를 사용할 수 있도록합니다." ". 영국에서는 "Chatsworth", Melton Road, Leamington과 같이 집 이름을 따옴표로 묶은 주소 필드를 찾는 것은 드문 일이 아닙니다. (이유는 분명하지 않다 : 파울러는 "의미있는 사람들은 '164 Melton Road'라고 부르는 집에 사는 것이지만 한 바보는 'Chatsworth'라고 부르는 것을 좋아한다"고

— 불평했다

1

@Scortchi 12 살 때 (+/- 에러) 같은시를 배운 것 같습니다. 저 중산층의 습관으로 인해 20 세기 초반 중산층의 불행한 영어 읽기가 당신의 마지막 사례를 모호하게한다고 생각합니다.

— Nick Cox

@NickCox : 12 가지 소리가납니다. 올해시를 읽었 는지 여부를 기억할 수 없다는 것은 재밌 습니다. 파울러의 포인트가 불필요한 인용 부호 (참조의 독자에 미치는 영향에 대해 이었지만 unnecessaryquotes.com을 ), 나는 당신에게 예를 들어 자신의 선택에 속물 근성의 영향을 볼 수있는 좋은 방법입니다 권리를 생각한다. 어쨌든, 나는 당신이 영어 주소를 포함하는 CSV 파일을 보낸다면 조심해야 할 약간의 요점이 내 발화에도 불구하고 모두에게 분명하다는 것을 희망합니다.

— Scortchi-복원 Monica Monica

1

인도에서는 첫 번째 집 (아파트가 아닌)을 짓는 사람들이 종종 고유의 언어 나 산스크리트어 문구로 혁신적인 꽃 이름을 유지하고 "구루 크리 파 (Guru Kripa)"와 같이 큰 따옴표로 묶인 사람들이 일반적입니다. Genelia D' Souza와 Derek O'Brien과 같은 이름도 일반적입니다. 그런 다음 정부 번호가 다시 매겨 지므로 "Old Door No. nnn / New Door No. mm / c"와 같은 주소는 예상치 못한 모서리에 슬래시와 작은 따옴표가있어 주소 저장이 더욱 복잡해집니다.

— Whirl Mind

@WhirlMind : 흥미 롭습니다. 영국에서 스코틀랜드 게 일어와 웨일스 어 집 이름이 많이 있습니다. 아마도 집 이름을 지정할 언어를 고르는 것과 가장 비슷할 것입니다.

— Scortchi-Monica Monica 복원

9

@Tim의 대답은 정확하지만 "csv"에는 일반적인 표준이 없습니다. 특히 이스케이프 규칙이 전혀 정의되어 있지 않으므로 한 프로그램에서 읽을 수 있지만 다른 프로그램에서는 읽을 수없는 "형식"으로 이어집니다. . 이것은 태양 아래의 모든 "프로그래머"가 단지 "oooh csv- 나는 내 자신의 파서를 구축 할 것"이라고 생각한다는 사실에 의해 화려하게된다. 그런 다음 모든 엣지 케이스를 놓칩니다.

또한 csv에는 메타 데이터 또는 열의 데이터 유형을 저장하는 기능이 전혀 없으므로 데이터를 이해하기 위해 읽어야하는 여러 문서가 있습니다.

— 크리스찬 사우어
소스

5

예. 표준 도구 가 있습니다 .ietf.org / html / rfc4180 및 기타 여러 형식은 메타 데이터를 저장하지 않습니다. 메타 데이터를 저장하도록 설계된 것이 아닙니다. .txt 파일도 텍스트 문서에 대한 메타 데이터를 저장하지 않습니다 ...

— Tim

4

Tim, 그 표준은 자주 무시되지 않고 무시되기 때문에 표준이 아닙니다.

— Christian Sauer

8

표준의 장점은 선택할 수있는 것이 너무 많다는 것입니다. (다양한 변형과 결과)

— Nick Cox

4

쉼표 구분 기호를 버리고 탭 문자를 사용하면 훨씬 더 성공할 수 있습니다. .CSV라는 파일을 그대로 둘 수 있으며 대부분의 프로그램으로 가져 오는 것은 일반적으로 문제가되지 않습니다. 파일을 가져올 때 쉼표가 아닌 TAB로 구분하면됩니다. 데이터에 쉼표가 있으면 잘 알고 있듯이 쉼표로 구분하여 지정할 때 문제가 발생합니다.

— 고릴라
소스

5

데이터에 탭이 있으면 대화가 적용됩니다. 적어도 내 경험으로는 그렇지 않을 것입니다.

— Nick Cox

@ Nick and Gorilla : |집에서 만든 csv와 같은 레코드의 텍스트 파일 (책 제목 및 기타 문서 메타 데이터 포함)의 구분 기호로 좋은 결과를 얻었습니다 . |내가 작업하는 데이터에서 절대 발생하지 않으므로 어떤 종류의 따옴표도 확인하지 않고 단순히 분리 / 결합하는 펄 스크립트를 작성할 수 있습니다. 이것은 MS Access 데이터베이스에서 저장된 메타 데이터를 처리하는 일회성 프로젝트를위한 것입니다. 대규모 프로젝트의 경우 또는이 파일 형식으로 데이터를 장기적으로 유지하려는 경우보다 강력한 것을 선택하십시오! 이번 달의 배치가 문제가 발생하면 항상 무언가를 조정할 수 있습니다.

— Peter Cordes

@PeterCordes 나는 당신을 믿습니다. 그러나 명백한 분리기의 비용은 다른 사람들에게 설명 할 필요가있을 수 있으며 어려움없이 이러한 데이터 파일을 가져올 수있는 것이 중요합니다. 특이한 파일 형식에 직면하면 임의의 구분 기호로 문자열을 분할 할 수있는 일부 루틴, 기능 또는 명령에 액세스 할 수 있어야합니다.

— Nick Cox

@PeterCordes splitStata에 대한 명령을 작성할 때 무엇보다도 Perl이 수행 한 것과 수행하지 않은 것을 확인하기 위해 Perl을 살펴 보았습니다. 소스 코드가 아닌 기능 만 제공됩니다.

— Nick Cox 10

1

@NickCox : 많은 펄의 기능은 IMO로 잘 디자인되어 있습니다. 그들은 당신이 awk (종종 좋은) 또는 esp에서 발견하는 것과 같은 많은 특별한 제한없이 작업을 수행합니다. 다른 유닉스 도구를 좋아하는 cut, sort하고 uniq.

— Peter Cordes

4

ASCII는 아래에 ascii (7) * nix 매뉴얼 페이지의 스 니펫에 표시된 것처럼 4 개의 "분리 자"문자를 제공합니다.

   Oct   Dec   Hex   Char
   ----------------------
   034   28    1C    FS  (file separator)
   035   29    1D    GS  (group separator)
   036   30    1E    RS  (record separator)
   037   31    1F    US  (unit separator)

이 답변 은 의도 된 사용법에 대한 적절한 개요를 제공합니다.

물론, 이러한 제어 코드는보다 널리 사용되는 구분 기호의 친숙성 (가독성 및 입력)이 부족하지만 프로그램 간 내부 및 / 또는 임시 데이터 교환을위한 적절한 선택입니다.

— 로널드 스트레이트
소스

2

흥미 롭군 내가 ... 내가이 야생 생각에 사용되는 본 적이 생각하지 않는다

— 매트 크라우스에게

4

문제는 쉼표가 아닙니다. 문제는 인용입니다. 사용하는 레코드 및 필드 구분 기호에 관계없이 컨텐츠에서이를 구분할 수 있도록 준비해야합니다. 따라서 인용 메커니즘이 필요합니다. 그런 다음 인용 문자도 표시 할 방법이 필요합니다.

RFC 4180 표준을 따르면 모든 사람이 모든 것을 간단하게 만들 수 있습니다.

나는 개인적 으로이 문제가 발생한 프로그램의 출력을 수정하기 위해 스크립트를 작성해야 했으므로 약간 무섭습니다. "아마 수정"은 내 데이터에 효과가 있었지만 실패한 상황을 볼 수 있음을 의미합니다. (이 프로그램의 방어에서는 표준보다 먼저 작성되었습니다.)

— 스티 그 헤머
소스