Tiếng Việt

Công cụ dành cho nhà phát triển · Trình chuyển đổi cú pháp

Tiêu chuẩn còn thiếu của CSV: RFC 4180 bao gồm những gì và những gì nó để ngỏ

· Lý lịch

csv json data-formats

CSV trường có dấu phẩy, dấu ngoặc kép và CRLF bản ghi được phát ra từ JSON hàng
Hình minh họa vector ToolAcre gốc

CSV có trước bất kỳ thông số kỹ thuật nào và thông số RFC mô tả thông số đó mang tính thông tin và thu hẹp có chủ ý. Bài đăng này giải thích những gì RFC 4180 định nghĩa, nó không nói gì về điều đó và tại sao việc chuyển đổi CSV do đó luôn là một cuộc thương lượng.

CSV của ai đúng? — hai bản xuất của cùng một bảng, một bảng có dấu chấm phẩy và một bảng có dấu phẩy, cả hai đều được gọi là CSV

ToolAcre có thể phát ra đầu ra được phân cách bằng dấu phẩy, dấu chấm phẩy hoặc dấu tab từ JSON. Nó không đọc hai bản xuất CSV cạnh tranh hoặc tuyên bố một trong hai đều đúng. CSV chỉ ghi ở đây, vì vậy lựa chọn dấu phân cách là tùy chọn đầu ra rõ ràng chứ không phải là thuật toán phát hiện.

Sự khác biệt đó ngăn ngừa sự trượt thực tế thông thường. Một giao diện có thể viết dấu chấm phẩy chưa chứng minh được nó có thể xác định dấu chấm phẩy trong một tệp không xác định, xử lý số thập phân miền địa phương hoặc giải thích các tiêu đề. Đó là những trách nhiệm đầu vào riêng biệt được loại trừ một cách có chủ ý.

Hai lựa chọn dấu phân cách là các tùy chọn đầu ra, không phải là bằng chứng cho thấy bảng này đọc một trong hai tệp

Kho lưu trữ không chứa nguồn cho bảng tính hoặc lịch sử cơ sở dữ liệu ban đầu, vì vậy bài viết không tạo ra niên đại. Nó bắt đầu với trình soạn thảo hiện tại và các thử nghiệm của nó: bản ghi, trường, dấu phân cách, chấm dứt CRLF và thoát trích dẫn.

Bối cảnh lịch sử có thể được thêm vào sau với các nguồn được xem xét. Việc triển khai trình chuyển đổi là bằng chứng cho những gì sản phẩm viết ngày hôm nay, không phải cho thời điểm quy ước xuất hiện lần đầu tiên hoặc tại sao các nhà cung cấp lại chuyển hướng.

CSV lịch sử trước RFC 4180 là bằng chứng bên ngoài kho lưu trữ

Trường chứa dấu phân cách, dấu ngoặc kép, dấu xuống dòng hoặc nguồn cấp dữ liệu dòng được đặt trong dấu ngoặc kép và mỗi dấu ngoặc kép được nhúng sẽ được nhân đôi. Khoảng trắng đầu hoặc cuối cũng được trích dẫn để ngăn việc cắt xén bảng tính thông thường. Bản ghi kết thúc bằng CRLF và tệp bị chấm dứt.

Những hành vi này tuân theo các quy tắc kiểu RFC 4180 đã được thử nghiệm trong kho lưu trữ. Bài viết tránh tuyên bố tuân thủ phổ quát vì người viết cũng hỗ trợ các dấu phân cách thay thế và bổ sung thêm cách xử lý bảo mật ngoài phạm vi ngữ pháp hẹp.

Người viết sử dụng trích dẫn kiểu RFC 4180 và CRLF mà không tuyên bố tuân thủ đầy đủ tiêu chuẩn

CSV ô không bảo toàn loại JSON. Chuỗi rỗng và chuỗi rỗng đều trở thành ô trống, trong khi boolean và số trở thành biểu diễn văn bản. Nội dung UTF-8 được chuyển qua và BOM tùy chọn có thể được đặt trước cho người tiêu dùng cần nội dung đó.

Giải thích ngôn ngữ không được nhúng. Dấu phân cách bằng dấu chấm phẩy có thể cùng tồn tại với dấu phẩy thập phân, nhưng người viết không định dạng lại số theo ngôn ngữ hoặc mã hóa loại ngày tháng. Ứng dụng nhận vẫn quyết định cách diễn giải từng trường.

Ranh giới mã hóa, loại và ngôn ngữ vẫn rõ ràng trong tác giả này

Các biến thể được triển khai là dấu phẩy, dấu chấm phẩy và tab, cùng với BOM tùy chọn. Văn bản giống công thức bắt đầu bằng `=`, `+`, `-`, `@`, trả về tab hoặc dấu xuống dòng có tiền tố là dấu nháy đơn theo mặc định nên bảng tính coi văn bản đó là văn bản. Người dùng có thể vô hiệu hóa tính năng bảo vệ đó và nhận được cảnh báo.

Không có chế độ thoát `sep=` gợi ý hoặc dấu gạch chéo ngược trong trình soạn thảo này. Đề cập đến những lựa chọn đó như những lựa chọn được vận chuyển sẽ là sai. Các trích dẫn được nhúng sử dụng tính năng nhân đôi, chính xác như các thử nghiệm khẳng định.

Các biến thể của bảng tính được quan sát bị giới hạn ở các tùy chọn và biện pháp bảo vệ được triển khai tại đây

Mọi giả định trong tuyến đường này đều bắt đầu từ JSON được phân tích cú pháp: giá trị nào cung cấp hàng, cách lồng nhau thành các cột chấm và khóa nào trở thành tiêu đề. Không có giả định nào được đưa ra về phương ngữ CSV đến vì CSV đến bị từ chối.

Việc chỉnh sửa này đảo ngược hướng được yêu cầu của sổ làm việc. Luồng công việc CSV-to-JSON phải chọn dấu phân cách, trích dẫn, tiêu đề và loại ô trong một công cụ khác. Lỗi của ToolAcre giải thích việc từ chối đó thay vì lặng lẽ đoán mò.

Giả định chuyển đổi chỉ áp dụng cho JSON-to-CSV vì dữ liệu nhập CSV bị từ chối

Sửa chữa sai định dạng CSV nằm ngoài phạm vi. Dấu ngoặc kép bị hỏng, mã hóa hỗn hợp và dấu phân cách ngẫu nhiên cần có CSV Trình dọn dẹp hoặc trình phân tích cú pháp khác có chẩn đoán rõ ràng. Trình chuyển đổi cú pháp nhận được sự nghiêm ngặt JSON, không bị hư hỏng CSV chữ.

Đầu ra vẫn có thể không phù hợp với mục tiêu khi cây lồng nhau tạo ra các cột chấm không rõ ràng hoặc vượt quá 2,000 cột. Cảnh báo và giới hạn sẽ hiển thị các lỗi hình dạng bảng đó trước khi tải xuống.

Bài học rút ra: CSV là quy ước, không phải định dạng — và cách bảng chuyển đổi Cú pháp biến tệp có định dạng đúng thành JSON mà bạn có thể kiểm tra

Hãy coi CSV như một quy ước mà các lựa chọn của nó phải hiển thị. ToolAcre ghi lại các lựa chọn đầu ra của nó và từ chối đảo ngược được chỉ định dưới mức. Điều đó đáng tin cậy hơn việc sử dụng một nút cho hai công việc cơ bản khác nhau.

Kiểm tra dấu phân cách, dấu ngoặc kép, CRLF, BOM và công thức thoát khỏi hệ thống nhận. Nếu cần phải phân tích cú pháp đầu vào, hãy sử dụng công cụ yêu cầu thay vì chuyển các quy ước của người viết vào một tệp không xác định.

Kiểm tra chấp nhận thực tế sẽ mở tệp được tạo trong ứng dụng khách dự định và cũng kiểm tra các byte hoặc văn bản thô. Chế độ xem của người tiêu dùng nắm bắt các vấn đề về hiển thị và nhập khẩu; chế độ xem thô xác nhận dấu phân cách, dấu ngoặc kép, CRLF và BOM tùy chọn mà không cần diễn giải lại bảng tính. Kiểm tra các chuỗi giống công thức dưới dạng văn bản trơ và số âm dưới dạng số. Những kiểm tra được ghép nối đó xác minh hợp đồng thực tế của người viết mà không tuyên bố rằng mọi chương trình đều triển khai các quy ước CSV giống hệt nhau.