Tại sao dấu phẩy / dấu phân cách bản ghi xấu trong tệp CSV?

32

Tôi đang đọc này bài viết và tôi tò mò cho câu trả lời đúng cho câu hỏi này.

Điều duy nhất xuất hiện trong đầu tôi có lẽ là ở một số quốc gia, dấu tách thập phân là dấu phẩy và có thể có vấn đề khi chia sẻ dữ liệu trong CSV , nhưng tôi không thực sự chắc chắn về câu trả lời của mình.

project-management

— David Gasquez
nguồn

6

Gần như bất kỳ dấu phân cách nào tốt hơn dấu phẩy. Lý do là, khi các tệp được phân tách bằng dấu phẩy đang được đọc trong một số công cụ phân tích dữ liệu, dấu phẩy có thể bị nhầm lẫn với dấu câu, phá vỡ "bố cục" của các trường hoặc cột.

— Mike Hunter

33

Một người hoài nghi, khi lưu ý rằng bài viết này là một mẩu phồng của SAS, có thể gợi ý rằng có lẽ SAS có vấn đề khi xử lý tệp CSV bằng dấu phẩy :-).

— whuber

3

@whuber - SAS (theo kinh nghiệm của tôi) có thể đấu tranh với các tệp CSV, cho dù chúng có dấu phẩy hay không, yêu cầu số lượng lớn mã hóa tay cho mọi điều kỳ lạ mà SAS không thích.

— Jeremy Miles

8

Có một sự tuyệt vọng trong việc tìm kiếm các dấu phân cách ngày càng khó hiểu hơn - ống dẫn, hành hương, gai - cho thấy đồng ý và tuân theo một tiêu chuẩn thực sự là cách an toàn duy nhất để mọi người trao đổi dữ liệu trong các tệp văn bản được phân tách. Và một tiêu chuẩn phổ quát phải cho phép bất kỳ chuỗi văn bản nào được trình bày (cũng như RFC4180), thay vì dựa vào giả định rằng một số sẽ không cần phải & có thể được đưa vào công việc khác.

— Scortchi - Tái lập Monica

2

(a) Tôi thường nhập các tệp .csv thành công. (b) Tôi khuyên mọi người không nên sử dụng .csv nếu họ có dấu phẩy trong dữ liệu của họ. Những điều này không mâu thuẫn với nhau. Thật không may là (b) cần giải thích trong một số quý.

— Nick Cox

33

Đặc tả định dạng CSV được xác định trong RFC 4180 . Thông số kỹ thuật này đã được công bố vì

không có thông số kỹ thuật chính thức nào tồn tại, điều này cho phép giải thích nhiều loại tệp CSV

Thật không may, kể từ năm 2005 (ngày xuất bản RFC), không có gì thay đổi. Chúng tôi vẫn có một loạt các triển khai. Cách tiếp cận chung được định nghĩa trong RFC 4180 là bao gồm các trường có chứa các ký tự như dấu phẩy trong dấu ngoặc kép, tuy nhiên khuyến nghị này không phải lúc nào cũng được đáp ứng bởi các phần mềm khác nhau.

Vấn đề là ở các ký tự dấu phẩy địa phương châu Âu khác nhau đóng vai trò là dấu thập phân, vì vậy bạn viết 0,005thay vì 0.005. Tuy nhiên, trong các trường hợp khác, dấu phẩy được sử dụng thay vì khoảng trắng để báo hiệu các nhóm chữ số, ví dụ 4,000,000.00(xem tại đây ). Trong cả hai trường hợp, việc sử dụng dấu phẩy có thể dẫn đến lỗi đọc dữ liệu từ tệp csv vì phần mềm của bạn không thực sự biết nếu 0,005, 0,1là hai số hoặc bốn số khác nhau (xem ví dụ ở đây ).

Cuối cùng nhưng không kém phần quan trọng, nếu bạn lưu trữ văn bản trong tệp dữ liệu của mình, thì dấu phẩy phổ biến hơn nhiều trong văn bản so với dấu chấm phẩy, vì vậy nếu văn bản của bạn không được đặt trong dấu ngoặc kép, thì dữ liệu đó cũng có thể dễ dàng đọc bị lỗi .

Không có gì làm cho dấu phẩy tốt hơn hoặc phân tách trường tệ hơn khi các tệp CSV được sử dụng theo các khuyến nghị như RFC 4180 bảo vệ khỏi các vấn đề được mô tả ở trên. Tuy nhiên, nếu có rủi ro khi sử dụng định dạng CSV được đơn giản hóa mà không bao gồm các trường trong dấu ngoặc kép hoặc khuyến nghị có thể được sử dụng không nhất quán, thì các dấu tách khác (ví dụ dấu chấm phẩy) dường như là cách tiếp cận an toàn hơn.

— Tim
nguồn

6

Chà, bất kỳ phần mềm nào thực hiện tiêu chuẩn CSV thực tế như được định nghĩa bởi RFC 4180 chắc chắn sẽ biết chính xác cách diễn giải bất kỳ chuỗi nào. Đối số rằng việc sử dụng ,thay vì một dấu tách hiếm hơn sẽ làm hỏng dữ liệu bởi vì bạn phải thoát nó mọi lúc là đúng. Và rõ ràng có tất cả những người nghĩ rằng họ biết CSV hoạt động như thế nào nhưng thực sự thì không.

— Voo

2

@Voo Có, nhưng vì các tệp "csv" được sử dụng theo cách hỗn loạn như vậy nên an toàn hơn là không sử dụng dấu phẩy và thay vào đó để sử dụng các dấu phân cách khác, ví dụ dấu chấm phẩy. Đây là câu trả lời cho câu hỏi OP. Không có gì "tốt hơn" trong dấu chấm phẩy (hoặc các dấu phẩy khác) so với dấu phẩy, chúng chỉ đơn giản là sự lựa chọn an toàn hơn trong nhiều trường hợp.

— Tim

2

@Voo +1 để bình luận của bạn. Tuy nhiên, bất cứ ai đang sử dụng CSV đều không thực sự quan tâm đến các tệp dữ liệu cồng kềnh!

— whuber

17

Về mặt kỹ thuật, dấu phẩy cũng tốt như bất kỳ ký tự nào khác được sử dụng làm dấu phân cách. Tên của định dạng đề cập trực tiếp rằng các giá trị được phân tách bằng dấu phẩy (Giá trị được phân tách bằng dấu phẩy).

Mô tả định dạng CSV đang sử dụng dấu phẩy làm dấu phân cách.

Bất kỳ trường nào chứa dấu phẩy nên được trích dẫn kép. Vì vậy, điều đó không gây ra vấn đề gì khi đọc dữ liệu. Xem điểm 6 từ mô tả :

Các trường có chứa dấu ngắt dòng (CRLF), dấu ngoặc kép và dấu phẩy phải được đặt trong dấu ngoặc kép.

Ví dụ, các hàm read.csvvà write.csvtừ R theo mặc định đang sử dụng dấu phẩy làm dấu phân cách.

— djhurio
nguồn

4

Đây là câu trả lời tốt nhất, vì nó đề cập đến valuesviệc được phân tách bằng dấu phẩy. Những người khác ám chỉ châu Âu formattingvề các con số, đây không phải là vấn đề đối với csv standard, vì bạn đã trích dẫn chính xác điểm 6 ở trên. Sự khác biệt từ "sử dụng đúng" tồn tại với bất kỳ định dạng dữ liệu nào. Vấn đề là - biết dữ liệu của bạn. Những người khác đề cập tabhoặc ;phân định, tuy nhiên những vấn đề này có thể có cùng các vấn đề như dấu phẩy khi bạn xử lý dữ liệu do người dùng nhập vào (có thể thông qua biểu mẫu và được cơ sở dữ liệu nắm bắt - Tôi đã phải vật lộn với các trường nhập văn bản miễn phí mà mọi người có ngón tay mập trong tab... nó hút)

— Adrian Torrie

Câu trả lời của Tim hiện đã được chỉnh sửa để bao gồm thông tin @djhurio được cung cấp.

— Adrian Torrie

11

Ngoài việc là một dấu tách chữ số trong các số, nó cũng là một phần của địa chỉ (chẳng hạn như địa chỉ khách hàng, v.v.) ở nhiều quốc gia. Trong khi một số quốc gia có địa chỉ được xác định rõ ràng ngắn, thì nhiều quốc gia khác có địa chỉ dài ngoằn ngoèo bao gồm, đôi khi hai dấu phẩy trên cùng một dòng. Các tệp CSV tốt bao gồm tất cả các dữ liệu đó trong dấu ngoặc kép. Nhưng các trình phân tích cú pháp viết đơn giản, quá đơn giản không cung cấp cho việc đọc và phân biệt như vậy. (Sau đó, có vấn đề sử dụng dấu ngoặc kép như một phần của dữ liệu, chẳng hạn như trích dẫn từ một bài thơ).

— Tâm trí xoáy
nguồn

2

(+1) Tiêu chuẩn cung cấp cho việc sử dụng dấu ngoặc kép như một phần của dữ liệu bằng cách khăng khăng nhân đôi chúng một lần nữa: "Belloc", "Tarantella", "" "bọ chét trêu chọc ở Pyrenees cao" "". Ở Anh, không có gì lạ khi tìm thấy các trường địa chỉ chứa tên của một ngôi nhà trong ngoặc kép, do đó: "Chatsworth", Melton Road, Leamington. (Không rõ tại sao: Fowler càu nhàu rằng "hàm ý dường như là: sống trong ngôi nhà mà những người nhạy cảm gọi là '164 Melton Road', nhưng một kẻ ngốc thích gọi 'Chatsworth'".)

— Scortchi - Tái lập Monica

1

@Scortchi Có vẻ như chúng tôi đã học những bài thơ tương tự ở tuổi 12 (lỗi +/-). Tôi sợ rằng những gì tôi đọc không may là sự hợm hĩnh tiếng Anh đầu thế kỷ 20 của tầng lớp trung lưu thượng lưu vì thói quen của tầng lớp trung lưu che khuất ví dụ cuối cùng của bạn, sẽ không minh bạch trong một nhóm nhỏ.

— Nick Cox

@NickCox: Mười hai âm thanh về đúng. Thật buồn cười là tôi không thể nhớ liệu tôi đã đọc bất kỳ bài thơ nào trong năm nay chưa, đừng nói đến việc nhớ lại bất kỳ dòng nào từ chúng. Mặc dù quan điểm của Fowler là về tác động đối với người đọc các dấu ngoặc kép không cần thiết (xem không cần thiết.com ), tôi nghĩ rằng bạn có quyền thấy ảnh hưởng của hợm hĩnh trong ví dụ của mình. Ở mức độ nào, tôi hy vọng một điểm khá nhỏ là đó là điều cần chú ý nếu bạn đã từng gửi một tệp CSV có chứa địa chỉ tiếng Anh rõ ràng cho dù chúng tôi có chia sẻ.

— Scortchi - Phục hồi Monica

1

Ở Ấn Độ, thông thường, những người xây dựng ngôi nhà đầu tiên của họ (không phải căn hộ), để giữ một tên hoa sáng tạo, thường bằng ngôn ngữ địa phương hoặc cụm từ tiếng Phạn và những từ này được trích dẫn kép, chẳng hạn như "Đạo sư Kripa". Những cái tên như Genelia D'Souza và Derek O'Brien cũng rất phổ biến. Sau đó, các địa chỉ có nội dung: "Cửa cũ số nnn / Cửa mới số mm / c", do chính phủ đánh số lại việc lưu trữ địa chỉ phức tạp hơn nữa, vì có dấu gạch chéo và dấu ngoặc đơn ở các góc không mong muốn.

— Whirl Mind

@WhirlMind: Điều đó thật thú vị - Tôi đã nhận thấy rất nhiều - tốt, hơn cả tôi mong đợi - tên nhà Gaelic & tiếng Wales của Scotland ở Anh, có lẽ là tương đương gần nhất với việc chọn một ngôn ngữ địa phương để đặt tên cho ngôi nhà của bạn.

— Scortchi - Phục hồi Monica

9

Mặc dù câu trả lời của @Tim là chính xác - tôi muốn thêm rằng "csv" nói chung không có tiêu chuẩn chung - đặc biệt là các quy tắc thoát hoàn toàn không được xác định, dẫn đến "định dạng" có thể đọc được trong một chương trình, nhưng không phải là một định dạng khác . Điều này được giải thích bởi thực tế là mọi "lập trình viên" dưới ánh mặt trời chỉ nghĩ rằng "oooh csv- Tôi sẽ xây dựng trình phân tích cú pháp của riêng mình!" và sau đó bỏ lỡ tất cả các trường hợp cạnh.

Hơn nữa, csv hoàn toàn thiếu khả năng lưu trữ siêu dữ liệu hoặc thậm chí kiểu dữ liệu của một cột - dẫn đến một số tài liệu mà bạn phải đọc để hiểu dữ liệu.

— Christian Sauer
nguồn

5

Có, có các công cụ tiêu chuẩn.ietf.org / html / rfc4180 và nhiều định dạng khác không lưu trữ bất kỳ siêu dữ liệu nào, nó chỉ không được thiết kế để lưu trữ siêu dữ liệu - các tệp .txt cũng không lưu trữ siêu dữ liệu về tài liệu văn bản ...

— Tim

4

Tim, tiêu chuẩn đó được bỏ qua thường xuyên hơn không, làm cho nó trở thành phi tiêu chuẩn ,,,

— Christian Sauer

8

Điều tuyệt vời về tiêu chuẩn là có rất nhiều lựa chọn. (Nhiều đột biến và quy kết.)

— Nick Cox

4

Nếu bạn có thể bỏ dấu phân cách dấu phẩy và sử dụng ký tự tab, bạn sẽ thành công hơn nhiều. Bạn có thể để tệp có tên .CSV và nhập vào hầu hết các chương trình thường không phải là vấn đề. Chỉ cần chỉ định TAB được phân cách thay vì dấu phẩy khi bạn nhập tệp của mình. Nếu có dấu phẩy trong dữ liệu của bạn, bạn S have gặp vấn đề khi chỉ định dấu phẩy được phân cách vì bạn biết rõ.

— Con khỉ đột
nguồn

5

Nếu có các tab trong dữ liệu của bạn, điều ngược lại được áp dụng. Đó chỉ là, ít nhất là theo kinh nghiệm của tôi, ít có khả năng.

— Nick Cox

@Nick và Gorilla: Tôi đã có kết quả tốt với |vai trò là người phân định trong các tệp văn bản giống như csv được ủ tại nhà (với tiêu đề sách và siêu dữ liệu tài liệu khác). |không bao giờ xảy ra trong dữ liệu tôi làm việc cùng, vì vậy tôi chỉ có thể viết các tập lệnh perl mà chỉ cần tách / nối mà không cần kiểm tra trích dẫn dưới bất kỳ hình thức nào. Đây là một dự án một lần duy nhất liên quan đến việc xử lý siêu dữ liệu được lưu từ cơ sở dữ liệu MS Access. Đối với bất kỳ dự án lớn hơn hoặc nếu bạn có kế hoạch giữ dữ liệu ở định dạng tệp này lâu dài, hãy chọn một cái gì đó mạnh mẽ hơn! Tôi luôn có thể điều chỉnh thứ gì đó nếu đợt hàng tháng này bị hỏng.

— Peter Cordes

@PeterCordes Tôi tin bạn, và bất cứ điều gì hoạt động. Nhưng rõ ràng chi phí của các bộ tách idiosyncratic có thể là cần phải giải thích những cái đó cho người khác và điều quan trọng là họ có thể nhập các tệp dữ liệu đó mà không gặp khó khăn. Đối mặt với một định dạng tệp bất thường, cần phải có quyền truy cập vào một số thường trình, hàm hoặc lệnh có thể phân tách các chuỗi trên các dấu tách tùy ý.

— Nick Cox

@PeterCordes Khi tôi viết một splitlệnh cho Stata tôi đã xem xét, trong số những thứ khác, Perl tương đương để xem những gì nó đã làm và không làm. Không phải mã nguồn, chỉ là chức năng được cung cấp.

— Nick Cox

1

@NickCox: Rất nhiều chức năng của perl được thiết kế khá tốt, IMO. Họ hoàn thành công việc mà không có nhiều hạn chế đặc biệt như bạn tìm thấy trong awk (thường là tốt), hoặc đặc biệt. công cụ Unix khác thích cut, sortvà uniq.

— Peter Cordes

4

ASCII cung cấp cho chúng tôi bốn ký tự "dấu phân cách", như được hiển thị bên dưới trong đoạn trích từ trang man ascii (7) * nix:

   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)

Câu trả lời này cung cấp một cái nhìn tổng quan về việc sử dụng dự định của họ.

Tất nhiên, các mã kiểm soát này thiếu tính thân thiện với con người (khả năng đọc và nhập) của các dấu phân cách phổ biến hơn, nhưng là các lựa chọn chấp nhận được để trao đổi dữ liệu nội bộ và / hoặc phù du giữa các chương trình.

— Ronald thẳng
nguồn

2

Hấp dẫn. Tôi không nghĩ rằng tôi đã từng thấy những thứ này được sử dụng trong tự nhiên mặc dù ...

— Matt Krause

4

Vấn đề không phải là dấu phẩy; vấn đề là trích dẫn. Bất kể bạn sử dụng bản ghi và phân cách trường nào, bạn cần chuẩn bị cho việc đáp ứng chúng trong nội dung. Vì vậy, bạn cần một cơ chế trích dẫn. VÀ THÌ bạn cần một cách để (các) ký tự trích dẫn cũng xuất hiện.

Theo tiêu chuẩn RFC 4180 làm cho mọi thứ đơn giản hơn cho mọi người.

Cá nhân tôi đã phải viết một kịch bản để có thể sửa lỗi đầu ra từ một chương trình có lỗi này, vì vậy tôi có một chút chiến lược về nó. "có thể sửa chữa" có nghĩa là nó hoạt động với dữ liệu CỦA TÔI, nhưng tôi có thể thấy các tình huống sẽ thất bại. (Trong phần bảo vệ của chương trình đó, nó được viết trước tiêu chuẩn.)

— Stig Hemmer
nguồn