บทความ
การแปลงระหว่าง CSV, XML, JSON และ YAML: คู่มือปฏิบัติ
CSV, JSON, XML และ YAML คือสี่รูปแบบที่นักพัฒนาพบบ่อยที่สุดใน data pipeline, ไฟล์คอนฟิก และ API การแปลงระหว่างกันทำได้ตรงไปตรงมาเมื่อโมเดลข้อมูลตรงกัน และสูญเสียข้อมูลได้มากเมื่อไม่ตรงกัน คู่มือนี้ครอบคลุมสิ่งที่แต่ละรูปแบบสามารถและไม่สามารถแทนได้ ว่าข้อมูลหายไปที่ใดระหว่างการแปลง และข้อผิดพลาดด้านการเข้ารหัสที่ทำให้เกิดความเสียหายแบบเงียบ เครื่องมือ data-converter บนเว็บไซต์นี้รองรับสามในสี่รูปแบบ (CSV, JSON และ YAML) ทั้งหมดในเบราว์เซอร์ ส่วนเนื้อหาเกี่ยวกับ XML ในบทความนี้เป็นข้อมูลพื้นฐานสำหรับเมื่อคุณย้ายข้อมูลด้วยมือหรือใช้เครื่องมืออื่นแยกต่างหาก
สี่รูปแบบและโมเดลข้อมูล
CSV จัดระเบียบข้อมูลเป็นตารางแบน ประกอบด้วยแถวและคอลัมน์ แถวแรกมักเป็นชื่อคอลัมน์ ทุกแถวถัดมาคือหนึ่งระเบียน ไม่มีการซ้อน ไม่มีข้อมูลประเภท และไม่มีมาตรฐานนอกจากข้อความธรรมดาในเซลล์ ทุกค่าเป็นสตริงเว้นแต่แอปพลิเคชันที่ใช้งานจะกำหนดประเภท JSON จำลองข้อมูลเป็นโครงสร้างต้นไม้ของออบเจกต์ (แผนที่คีย์-ค่า) และอาร์เรย์ ค่าอาจเป็นสตริง ตัวเลข บูลีน null ออบเจกต์ซ้อน หรืออาร์เรย์ที่มีความลึกใดก็ได้ ทำให้เอกสาร JSON เดียวสามารถแทนระเบียนลูกค้าที่มีออบเจกต์ที่อยู่ฝังอยู่ อาร์เรย์รายการสินค้า และยอดรวมตัวเลขที่มีประเภทข้อมูล XML จำลองข้อมูลเป็นโครงสร้างต้นไม้ของอีลีเมนต์ แต่ละอีลีเมนต์มีแอตทริบิวต์ที่มีชื่อและมีอีลีเมนต์ลูกหรือเนื้อหาข้อความได้ ไม่มีประเภทตัวเลขหรือบูลีนในตัว ทุกอย่างเป็นข้อความ Schema เช่น XSD สามารถบังคับใช้ประเภทได้ในเวลาตรวจสอบ แต่รูปแบบสายสัญญาณเป็นข้อมูลอักขระเสมอ YAML ใช้การเยื้องเพื่อแสดงโมเดลออบเจกต์และอาร์เรย์เหมือนกับ JSON แต่มีไวยากรณ์ที่อ่านง่ายกว่า YAML เป็น superset ของ JSON: เอกสาร JSON ที่ถูกต้องใดๆ ก็เป็น YAML ที่ถูกต้องด้วย มีสตริงหลายบรรทัด ความคิดเห็น และการอ้างอิง anchor-alias สำหรับบล็อกที่ซ้ำกัน YAML ใช้ทั่วไปในไฟล์คอนฟิก JSON ใช้ทั่วไปในการตอบสนอง API
การแปลงที่สูญเสียข้อมูล: การแบนราบและความคลุมเครือของ XML
การแปลงที่สูญเสียข้อมูลที่พบบ่อยที่สุดคือการแบน JSON หรือ XML ที่ซ้อนกันเป็น CSV ออบเจกต์ JSON ที่มีฟิลด์ที่อยู่ซ้อนอยู่ไม่สามารถแมปกับแถว CSV ได้อย่างสะอาด วิธีแก้ปัญหาทั่วไปคือใช้ชื่อคอลัมน์แบบ dot-notation: customer.address.city กลายเป็นคอลัมน์ของตัวเอง ใช้ได้สำหรับการซ้อนหนึ่งชั้น แต่พังทลายเมื่อมีอาร์เรย์ ลูกค้าที่มีสามเบอร์โทรศัพท์ต้องใช้คอลัมน์แยกสามคอลัมน์ (ฮาร์ดโค้ดจำนวนสูงสุด) แยกเป็นไฟล์ CSV ที่สอง หรือเข้ารหัสอาร์เรย์เป็นสตริงที่คั่นด้วยตัวคั่นภายในเซลล์เดียว ไม่มีตัวเลือกใดที่สามารถย้อนกลับเป็น JSON เดิมได้โดยไม่มีข้อมูลเมตาพิเศษ XML แนะนำความคลุมเครือแยกต่างหาก: ทางเลือกระหว่างแอตทริบิวต์กับอีลีเมนต์ลูก ค่า Paris อาจเก็บเป็นแอตทริบิวต์ (<city name="Paris">) หรืออีลีเมนต์ลูก (<city><name>Paris</name></city>) เมื่อตัวแปลงอ่าน XML และสร้าง JSON จะต้องตัดสินใจว่าจะแมปแอตทริบิวต์อย่างไร แนวทางทั่วไปรวมถึงการเติม @ ไว้หน้าคีย์แอตทริบิวต์หรือวางไว้ใต้คีย์ "_attributes" ทางเลือกไม่ได้มาตรฐาน ซึ่งหมายความว่าตัวแปลงสองตัวที่อ่าน XML เดียวกันอาจสร้าง JSON ที่มีโครงสร้างต่างกัน หากวางแผนจะ round-trip ข้อมูลผ่าน XML และ JSON ให้กำหนดแนวทางก่อนเริ่มต้น
ข้อผิดพลาดของ CSV: ตัวคั่น การอ้างอิง และการเข้ารหัส
CSV ไม่มีมาตรฐานอย่างเป็นทางการเดียว มีเพียง RFC 4180 เป็นข้อมูลอ้างอิงที่อ้างถึงกันอย่างกว้างขวาง ตัวคั่นที่พบบ่อยที่สุดคือเครื่องหมายจุลภาค แต่ในทางปฏิบัติยังพบเครื่องหมายเซมิโคลอน (ใช้ทั่วไปในภาษาท้องถิ่นของยุโรปที่จุลภาคใช้เป็นตัวคั่นทศนิยม) แท็บ (TSV) และเส้นแนวตั้ง ไฟล์ที่มีนามสกุล .csv อาจใช้ตัวคั่นใดก็ได้โดยไม่แจ้งให้ทราบ เมื่อค่าฟิลด์มีตัวคั่นนั้นเอง RFC 4180 กำหนดให้ครอบฟิลด์ด้วยเครื่องหมายคำพูดคู่: "San Francisco, CA" เครื่องหมายคำพูดคู่ภายในฟิลด์ที่ครอบด้วยเครื่องหมายคำพูดต้องหลีกโดยการทำซ้ำ: "He said ""hello""" ฟิลด์ที่มีตัวขึ้นบรรทัดใหม่จริงต้องครอบด้วยเครื่องหมายคำพูดด้วย โปรแกรมแยกวิเคราะห์ที่ข้ามขั้นตอนนี้จะทำให้เกิดข้อผิดพลาดจำนวนแถวที่ตรวจสอบยาก การเข้ารหัสเป็นข้อผิดพลาดแยกต่างหาก ไฟล์ CSV จากเครื่องมือ Windows มักมี UTF-8 BOM (เครื่องหมายลำดับไบต์: สามไบต์ EF BB BF ที่จุดเริ่มต้นของไฟล์) BOM ช่วยให้ Excel ระบุการเข้ารหัส แต่โปรแกรมแยกวิเคราะห์ในภาษาโปรแกรมหลายตัวถือว่า BOM เป็นส่วนหนึ่งของชื่อคอลัมน์แรก ทำให้ชื่อคอลัมน์กลายเป็น "id" แทน "id" สิ่งนี้ทำให้โค้ดปลายทางที่ค้นหาคอลัมน์ตามชื่อใช้งานไม่ได้ เมื่ออ่านไฟล์ CSV ด้วยโปรแกรม ให้ลบ BOM ก่อนแยกวิเคราะห์ หรือใช้ไลบรารีที่จัดการ BOM อย่างชัดเจน
การเลือกรูปแบบ: คอนฟิก การแลกเปลี่ยน และสเปรดชีต
การเลือกรูปแบบมักถูกกำหนดโดยบริบท ไม่ใช่ความชอบ JSON เป็นค่าเริ่มต้นสำหรับ REST API และการแลกเปลี่ยนระหว่างเบราว์เซอร์กับเซิร์ฟเวอร์ กระทัดรัด แยกวิเคราะห์ได้ในทุกภาษาโปรแกรม และรองรับข้อมูลประเภทตัวเลขและบูลีน จุดอ่อนคือไม่รองรับความคิดเห็น ทำให้ไม่เหมาะสำหรับไฟล์ที่นักพัฒนาอ่านและแก้ไขด้วยมือ YAML เป็นที่นิยมสำหรับไฟล์คอนฟิก (Kubernetes manifests, นิยามไปป์ไลน์ CI, Ansible playbooks) เพราะรองรับความคิดเห็นแบบ inline และอ่านง่ายกว่า JSON ที่มีหลายชั้นของการเยื้อง ความเสี่ยงหลักคือข้อผิดพลาดการเยื้องเป็นแบบเงียบ: คีย์ที่เยื้องผิดจะย้ายไปขอบเขตอื่นโดยไม่มีข้อผิดพลาดในการแยกวิเคราะห์ XML ยังคงเป็นมาตรฐานในระบบองค์กรรุ่นเก่า บริการเว็บ SOAP รูปแบบเอกสาร (DOCX, SVG, RSS) และบริบทที่ต้องการการตรวจสอบ schema หรือการแก้ความคลุมเครือของ namespace มีความยืดยาว แต่เครื่องมือ XPath และ XSLT มีความสมบูรณ์ CSV เป็นตัวเลือกที่ถูกต้องเมื่อข้อมูลแบนจริงๆ และผู้รับคือแอปพลิเคชันสเปรดชีตหรือนักวิเคราะห์ข้อมูล ไม่เหมาะสำหรับคอนฟิกหรือการแลกเปลี่ยน API เพราะไม่มีระบบประเภทและไม่รองรับการซ้อน
ทำในเครื่องด้วย data-converter
เครื่องมือ data-converter บนเว็บไซต์นี้แยกวิเคราะห์และแปลงระหว่าง CSV, JSON และ YAML ทั้งหมดในเบราว์เซอร์ โดยไม่รองรับการอ่านหรือเขียน XML ไม่มีข้อมูลถูกส่งไปยังเซิร์ฟเวอร์ใดๆ การแปลงทำงานใน JavaScript runtime ในเครื่องของคุณ และผลลัพธ์พร้อมดาวน์โหลดหรือคัดลอกโดยไม่มีสิ่งใดออกจากอุปกรณ์ของคุณ สิ่งนี้มีความสำคัญสำหรับข้อมูลที่ไม่ใช่ของคุณที่จะแชร์: การตอบสนอง API ที่มีข้อมูลส่วนบุคคล ไฟล์คอนฟิกที่มีชื่อโฮสต์ภายใน หรือการส่งออก CSV จากฐานข้อมูลภายใน การวางข้อมูลนั้นลงในตัวแปลงบนเว็บที่ทำงานบนเซิร์ฟเวอร์หมายความว่าเนื้อหาถูกส่งผ่านเครือข่ายและประมวลผลบนฮาร์ดแวร์ที่คุณไม่ได้ควบคุม ด้วย data-converter แท็บเบราว์เซอร์คือสภาพแวดล้อมการประมวลผล เครื่องมือใช้การอ้างอิงแบบ RFC 4180 เมื่ออ่านหรือเขียน CSV และคาดหวัง flat array ของ object สำหรับการแปลง JSON หรือ YAML เป็น CSV: ค่า object หรือ array ที่ซ้อนอยู่ภายใต้ key จะไม่ถูกแบนราบแบบ dot-notation ให้อัตโนมัติ ดังนั้นให้แบนราบฟิลด์เหล่านั้นด้วยตัวเองก่อนแปลงหากคุณต้องการให้เป็นคอลัมน์แยกกัน หากคุณต้องการย้ายข้อมูลไปหรือมาจาก XML ให้แปลงเป็น JSON หรือ YAML ด้วยเครื่องมือ XML เฉพาะทางก่อน แล้วจึงนำผลลัพธ์มาใช้ที่นี่
เครื่องมือที่กล่าวถึงในบทความนี้
คำถามที่พบบ่อย
ฉันสามารถ round-trip JSON ผ่าน CSV และได้ต้นฉบับกลับมาได้ไหม?
ได้เฉพาะเมื่อ JSON เป็นอาร์เรย์แบนของออบเจกต์ที่ไม่มีฟิลด์ซ้อนและไม่มีอาร์เรย์เป็นค่า ทันทีที่มีออบเจกต์ซ้อนหรือค่าอาร์เรย์ การแทน CSV ต้องตัดสินใจเชิงโครงสร้าง (คอลัมน์ dot-notation, แถวหลายแถว หรือสตริงที่เข้ารหัส) ที่ไม่สามารถย้อนกลับอัตโนมัติได้ หากข้อมูลมีการซ้อน JSON, XML หรือ YAML จะ round-trip ได้สะอาด CSV จะไม่สะอาด
ทำไม CSV ของฉันดูผิดปกติใน Excel หลังจากส่งออกจากแอปพลิเคชันยุโรป?
ภาษาท้องถิ่นของยุโรปมักใช้เครื่องหมายเซมิโคลอนเป็นตัวคั่น CSV เพราะจุลภาคสงวนไว้สำหรับสัญลักษณ์ทศนิยม Excel ในภาษาท้องถิ่นยุโรปคาดหวังเซมิโคลอน หากไฟล์ใช้จุลภาค Excel จะถือว่าทั้งแถวเป็นคอลัมน์เดียว วิธีแก้คือเปลี่ยนตัวคั่นในการตั้งค่าส่งออก หรือใช้วิซาร์ดนำเข้าข้อมูลของ Excel ที่ให้คุณระบุตัวคั่นด้วยตนเอง ปัญหา UTF-8 BOM แยกต่างหาก: หากไม่มี BOM Excel อาจอ่านอักขระที่มีสำเนียงผิดเป็นข้อความเสียหาย
ความแตกต่างระหว่าง YAML และ JSON ในทางปฏิบัติคืออะไร?
ทั้งสองแทนโมเดลข้อมูลพื้นฐานเหมือนกัน: ออบเจกต์ อาร์เรย์ สตริง ตัวเลข บูลีน และ null YAML เพิ่มความคิดเห็น (บรรทัดที่ขึ้นต้นด้วย #) สตริงหลายบรรทัด และการอ้างอิง anchor สำหรับบล็อกที่ซ้ำกัน JSON เป็น subset ที่ถูกต้องของ YAML แต่โปรแกรมแยกวิเคราะห์ JSON ไม่อ่าน YAML กฎปฏิบัติ: ใช้ JSON สำหรับ API payload และการจัดเก็บข้อมูล ใช้ YAML สำหรับไฟล์คอนฟิกที่มนุษย์แก้ไขและได้ประโยชน์จากความคิดเห็นแบบ inline