Các tệp CSV UTF-8 có nên chứa BOM (dấu thứ tự byte) không?


37

Phần mềm kinh doanh trực tuyến của chúng tôi cho phép người dùng lưu một số dữ liệu nhất định dưới dạng CSV . Vì có rất nhiều định dạng khác nhau (tất cả được gọi là "CSV") được sử dụng ngoài tự nhiên, chúng tôi buộc phải quyết định "định dạng mặc định" sẽ trông như thế nào.

  • Về phân cách dòng / trường và thoát, có một tiêu chuẩn chúng ta có thể sử dụng: RFC 4180 .

  • Về mã hóa văn bản, UTF-8 dường như đã nổi lên trong thập kỷ qua là "định dạng tệp văn bản mặc định", vì vậy chúng tôi sẽ sử dụng điều đó.

Một câu hỏi còn bỏ ngỏ là: Chúng ta có nên thêm BOM khi bắt đầu hay không? Tôi đã đọc nhiều ý kiến ​​và ưu / nhược điểm về việc sử dụng BOM nói chung, nhưng liệu có khuyến nghị "chính thức" hoặc ít nhất là một số loại đồng thuận cộng đồng về việc sử dụng BOM trong các tệp CSV không?


7
Nếu nó có BOM thì đó không phải là UTF-8. Nhưng định dạng nào làm chương trình muốn. Nếu họ cần BOM (chủ yếu là micro-sloth) thì bạn cần thêm một, nhưng UTF-8 + BOM UTF-8.
ctrl-alt-delor

3
Mặc dù CSV rõ ràng dễ tạo hơn, nhưng có rất nhiều vấn đề tương thích, đặc biệt là nếu bạn đi ra khỏi ASCII 7 bit thuần túy, tôi rất khuyến nghị bạn nên tạo XLSX thực tế nếu mục tiêu là cho người dùng mở nó trong Excel (thay vì nhập lại nó trong một số phần mềm khác, trong trường hợp đó bạn sẽ phải cung cấp các tùy chọn cho dấu tách, mã hóa, v.v.). Có những thư viện cho hầu hết các ngôn ngữ ngoài kia, và bạn sẽ tiết kiệm cho bạn và người dùng của bạn rất nhiều thời gian.
jcaron

2
Nếu bạn thực hiện tuyến đường CSV, hãy kiểm tra xem điều gì sẽ xảy ra khi bạn mở tệp trên cả Mac và PC, lý tưởng nhất là với một số phiên bản Excel. Ngoài ra, hãy lưu ý rằng một số phiên bản Excel không hoạt động giống nhau khi bạn nhấp đúp vào tệp để mở hoặc mở tệp qua menu.
jcaron

2
Tại sao nó lại quan trọng nếu nó mở đúng trong Excel? Không có gì trong câu hỏi cho biết Excel cần có khả năng phân tích tệp được tạo ...
rubenvb

Câu trả lời:


55

Không phải cho UTF-8 , nhưng hãy xem các cảnh báo khác nhau trong các bình luận.

Không cần thiết (UTF-8 không có thứ tự byte) không giống như UTF-16/32 và không được khuyến nghị trong tiêu chuẩn Unicode . Cũng khá hiếm khi thấy UTF-8 với BOM "trong tự nhiên", vì vậy trừ khi bạn có lý do hợp lệ (ví dụ như đã nhận xét, bạn sẽ làm việc với phần mềm mong đợi BOM) Tôi khuyên bạn nên sử dụng phương pháp không có BOM .

Wikipedia đề cập đến một số phần mềm chủ yếu của Microsoft buộc và mong đợi BOM, nhưng trừ khi bạn làm việc với họ, đừng sử dụng nó.


28
Ngoài ra còn có phần mềm phổ biến yêu cầu BOM: Excel cần BOM để xác định chính xác tệp CSV là UTF-8 thay vì "ANSI", tức là ngôn ngữ tương thích cục bộ. (Nhưng Excel cũng thực hiện những điều kỳ lạ khi lưu tệp như vậy, vì vậy chúng tôi khuyên người dùng nên sử dụng xuất Excel "thực" của chúng tôi thay vì xuất CSV nếu họ muốn mở tệp bằng Excel.)
Heinzi

21
@Heinzi Tôi đã học được từ lâu rằng bạn không thể thực sự chiến thắng khi làm việc với CSV và Excel. Nó chỉ đơn giản là một trình đọc CSV tệ hại. Quá tệ, đó là những gì người dùng bình thường mong đợi.
đường ống

9
@Voo: Yêu cầu BOM cho UTF-8 chắc chắn vi phạm tiêu chuẩn, coi đó là " không bắt buộc cũng không được khuyến nghị ".
Ded repeatator

12
@Ded repeatator: Các hệ thống MS-DOS và Windows có một lượng lớn các tệp văn bản cũ trong các bảng mã khác với UTF-8. Các ứng dụng chất lượng cho phép người dùng chỉ định cách mã hóa tệp văn bản khi mở tệp, nhưng thường bao gồm tùy chọn "tự động". Nếu người dùng chọn "UTF-8", tệp UTF-8 sẽ được mở chính xác có hoặc không có BOM. Nếu người dùng chọn "tự động", một số tệp UTF-8 không có BOM có thể bị xác định nhầm là sử dụng một số mã hóa khác. Tôi không chắc chắn những gì người ta mong đợi một ứng dụng sẽ làm khác đi, vì các tệp được "xác định sai" có thể giống hệt nhau một chút với ...
supercat

7
@Voo: Điều đó mâu thuẫn với nhiều yêu cầu định dạng cụ thể khác trong đó BOM là bất hợp pháp. Ví dụ: tập lệnh shell có BOM trước #!không hợp lệ. Tốt nhất là BOM trong UTF-8 là "được phép, khi không có yêu cầu cụ thể về định dạng / ứng dụng nào loại trừ nó", không được "cho phép" và vì vậy không nên sử dụng. Các tiêu chuẩn thực sự rõ ràng về NÊN.
R ..

8

Vẫn chưa có quy ước rộng rãi AFAIK, mặc dù chắc chắn UTF-8 hiện được chấp nhận rộng rãi.

BOM là một tạo tác khủng khiếp:

Nó là vô hình (không gian có chiều rộng bằng không).

Một số phần mềm có thể phá vỡ tên cột đầu tiên không chỉ chứa các chữ cái mà là BOM lạ đó ở phía trước.

Dòng tiêu đề có thể được sao chép cho các dòng giá trị làm hỏng giá trị đầu tiên.

Một số phần mềm Windows chỉ cần phân biệt giữa một trong các mã hóa ANSI được sử dụng bởi máy Windows cục bộ đó và UTF-8. Notepad, Excel.

Vì vậy, điều đáng buồn là một người nên hỗ trợ BOM. Có thể tùy chọn.

Sử dụng sơ đồ đặt tên cho các tệp (...- utf8.txt, ...- utf8bom.txt).


Trong nhiều trường hợp, chúng tôi có thể sử dụng HTML thay thế xuất khẩu. Điều này cho phép thiết lập mã hóa trong tệp. Một tính năng bổ sung là màu nền / tiền cảnh của các hàng và ô. Mà nâng cao chất lượng xuất khẩu.


15
Việc định dạng "nâng cao chất lượng xuất khẩu" hay không phụ thuộc rất nhiều vào mục đích sử dụng của tệp. CSV thường được sử dụng như một định dạng có thể đọc được bằng máy đơn giản và thay vào đó, làm cho người nhận phân tích cú pháp HTML sẽ là một bất lợi lớn trong trường hợp đó.
IMSoP

5
Nếu bạn đang chọn một kế hoạch đặt tên, hãy ghi nhớ đối tượng. -utf8-windows.csvtốt hơn. Hầu như mọi người đều biết Windows là gì, trong bối cảnh của máy tính, nhưng có rất ít người dùng biết Byte Order Mark là gì.
MSalters

2
@Davislor có nếu đó là một tiêu chuẩn được biết đến rộng rãi. Nếu không, các báo cáo lỗi sẽ xuất hiện trong việc tschüßlà rác trong khi đáng tschüßlẽ phải được viết. Trên StackOverflow nhiều lỗi CNTT là về mã hóa. Người dùng cuối cũng sẽ gặp vấn đề.
Eggen

3
@JoopEggen "Tiêu chuẩn được truyền đạt rộng rãi" trong cộng đồng chính xác là gì? Tôi đã thực hiện phát triển phần mềm được gần 10 năm và tôi chưa bao giờ thấy điều đó - ngay cả trên windows và chắc chắn không phải trên Linux hay OSX, nơi bạn hầu như luôn luôn đối phó với utf-8.
Khối

1
@JustinTime có kể từ một số năm, nhưng không phải trước đó. Các nhà phát triển MS không tệ lắm (tuân thủ Posix, hiện hỗ trợ UTF-8).
Eggen
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.