จดหมายรักถึงฟอร์แมต CSV

 (github.com/medialab)
4 คะแนน โดย GN⁺ 2025-03-27 | 3 ความคิดเห็น | แชร์ทาง WhatsApp
  • แม้จะมีการแนะนำฟอร์แมตที่ "เหนือกว่า" มาแทน CSV อยู่บ่อยครั้ง แต่ส่วนใหญ่ก็มักอิงจากการเปรียบเทียบที่ลำเอียงและมองข้ามจุดแข็งที่แท้จริงของ CSV
  • บทความนี้ไม่ได้บอกว่า CSV สมบูรณ์แบบ แต่ต้องการฉายให้เห็นข้อดีที่มักถูกประเมินต่ำไป
  • เป็นการทบทวนคุณค่าที่แท้จริงของ CSV ท่ามกลางบรรยากาศที่การเกลียด CSV ดูเหมือนจะเท่กว่า

1. CSV เรียบง่ายอย่างที่สุด

  • คำจำกัดความของ CSV ก็ตรงตามชื่อเลย: "ค่าที่คั่นด้วยเครื่องหมายจุลภาค"
  • แถวถูกคั่นด้วยการขึ้นบรรทัดใหม่ และคอลัมน์ถูกคั่นด้วยเครื่องหมายจุลภาค
  • หากค่ามีเครื่องหมายจุลภาคหรือการขึ้นบรรทัดใหม่ ก็ให้ครอบด้วยเครื่องหมายอัญประกาศ และถ้าต้องการใส่อัญประกาศเองก็ใช้เครื่องหมายอัญประกาศคู่ซ้อน
  • ไม่มีสเปกที่ซับซ้อน ใครก็เข้าใจและใช้งานได้อย่างเป็นธรรมชาติ
  • อย่างไรก็ดี หากต้องการ parse ให้ถูกต้อง ก็ยังควรใช้ CSV parser โดยเฉพาะ

2. CSV เป็นแนวคิดร่วมของส่วนรวม

  • ไม่มีเจ้าของ และไม่ถูกทำให้เป็นกรรมสิทธิ์
  • แม้จะมี RFC 4180 แต่คนส่วนใหญ่มองว่าเป็นเพียงเอกสารอ้างอิง
  • เป็นฟอร์แมตอิสระที่ตั้งอยู่บนกฎร่วมกันแบบไม่เป็นทางการซึ่งนักพัฒนาทั่วโลกเข้าใจตรงกัน

3. CSV เป็นข้อความล้วน

  • เป็นฟอร์แมตข้อความล้วนที่มนุษย์อ่านได้ เช่นเดียวกับ JSON, YAML, XML
  • เปิดได้ด้วย text editor ใดก็ได้ และตรวจดูเนื้อหาได้โดยไม่ต้องมีเครื่องมือเฉพาะ
  • ยังเลือกวิธี encoding ได้อย่างอิสระ

4. CSV เหมาะกับการสตรีมมิงอย่างยิ่ง

  • เพราะอ่านทีละบรรทัด จึงใช้หน่วยความจำน้อยมาก
  • ด้วยโค้ดที่เรียบง่าย ก็สามารถประมวลผลข้อมูลระดับหลายกิกะไบต์ได้ด้วยหน่วยความจำเพียงไม่กี่ KB
  • ฟอร์แมตแบบ column-oriented อย่าง Parquet ทำสตรีมมิงได้ยากกว่า และต้องใช้การบัฟเฟอร์ที่ซับซ้อน
  • ข้อเสียคือแม้อยากดูแค่บางคอลัมน์ ก็ยังต้องอ่านทั้งแถว

5. CSV ต่อท้ายข้อมูลได้ง่าย

  • เปิดไฟล์ด้วยโหมด append(a+) แล้วเพิ่มแถวใหม่ต่อท้ายได้ง่ายมาก
  • ในทางกลับกัน ฟอร์แมตแบบ column-oriented เช่น Parquet นั้นเพิ่มแถวใหม่ได้ไม่มีประสิทธิภาพและซับซ้อนกว่า

6. CSV รองรับ dynamic type

  • ไม่มีชนิดข้อมูลตายตัว จึงตีความข้อมูลได้อย่างยืดหยุ่น
  • ตัวอย่าง: JavaScript แสดงจำนวนเต็ม 64 บิตได้ไม่สมบูรณ์ แต่ CSV ใช้งานได้โดยไม่มีข้อจำกัดแบบนั้น
  • จึงมีข้อดีด้านความเข้ากันได้ข้ามภาษาและความยืดหยุ่น
  • แต่หากตีความผิดก็อาจเกิดข้อผิดพลาดได้ → จึงต้องใช้อย่างระมัดระวัง
  • หากต้องการประสิทธิภาพสูง ก็ยังสามารถประมวลผลระดับไบนารีได้โดยตรงโดยไม่ต้องถอดรหัสข้อความ

7. CSV กระชับ

  • ส่วนหัวมีอยู่แค่ต้นไฟล์ ทำให้แทบไม่มีการทำซ้ำของรูปแบบ
  • JSON และ XML มี overhead สูงจากการทำซ้ำของคีย์
  • การแสดงสตริงก็กระชับอยู่แล้ว และ overhead ของฟอร์แมตเองก็มีน้อยมาก เช่น เครื่องหมายจุลภาคและอัญประกาศ

8. แม้กลับด้าน CSV ก็ยังใช้ได้

  • CSV แม้จะกลับลำดับในระดับไบต์ ก็ยังคงเป็น CSV ที่ถูกต้อง
  • นี่เป็นผลจากวิธี escape เครื่องหมายอัญประกาศคู่ ซึ่งมีลักษณะเป็น palindrome
  • คุณสมบัตินี้ทำให้อ่านส่วนท้ายของไฟล์ CSV ได้อย่างมีประสิทธิภาพมาก
  • ตัวอย่าง: เมื่อต้อง resume process ที่หยุดไป สามารถอ่านเพียงไม่กี่บรรทัดสุดท้ายของไฟล์แล้วเริ่มต่อได้

9. Excel ไม่ชอบ CSV

  • ถ้า Excel รู้สึกว่าฟอร์แมตนี้ใช้งานไม่สะดวก ก็อาจเป็นสัญญาณว่าคุณกำลังเดินมาถูกทาง

บทความที่เกี่ยวข้อง

3 ความคิดเห็น

 
ng0301 2025-03-29

เรียบง่ายดีที่สุด!
 
ethanhur 2025-03-27

แย่กว่านั่นแหละดีกว่า!
 
GN⁺ 2025-03-27
ความคิดเห็นบน Hacker News

  • เหตุผลที่ชอบไฟล์ CSV และ INI คือมันเรียบง่าย เป็นแบบข้อความ และไม่มีชนิดข้อมูลที่ถูกเข้ารหัสไว้ในฟอร์แมต มีแต่สตริงล้วน ๆ

    • แม้จะมีข้อเสียตรงที่ไม่มีมาตรฐานทางการ แต่ก็ทำหน้าที่ของมันได้ดี
    • ได้บุ๊กมาร์กคำวิจารณ์ INI ในมุมมองของ TOML เอาไว้
    • คิดว่าบรรทัดแรกของคำวิจารณ์ TOML ก็ใช้กับ CSV ได้เหมือนกัน: มันคือการรวมตัวของหลากหลายสำเนียง

  • CSV นั้นงดงาม แต่มีข้อบกพร่องร้ายแรงอยู่ข้อหนึ่ง — เครื่องหมายอัญประกาศมีผลแบบ "ไม่เฉพาะที่"

    • ตัวอย่างเช่น เครื่องหมายอัญประกาศเพียงตัวเดียวที่ไบต์ 1 สามารถเปลี่ยนความหมายของเครื่องหมายจุลภาคที่ไบต์ 1000000 ได้
    • สิ่งนี้นำไปสู่ผลลัพธ์ที่น่ารำคาญสองอย่าง
      • ทำให้การประมวลผล CSV แบบขนานทำได้ยาก
      • ความเสียหายของข้อมูลส่งผลกระทบอย่างมากต่อความสามารถในการอ่านของไฟล์ (อัญประกาศที่หายไปหรือเกินมาเพียงตัวเดียวอาจทำให้ทั้งหมดพังได้)
    • เพราะแบบนั้นทุกวันนี้จึงชอบการ escape แบบเรียบง่ายมากกว่า CSV สำหรับการ serialize ข้อมูลตารางง่าย ๆ

  • ข้อดีที่สุดของ CSV คือใคร ๆ ก็เขียน parser ได้ภายใน 30 นาที

    • สามารถนำข้อมูลจากยุคต้นทศวรรษ 90 เข้าสู่เว็บเซอร์วิสสมัยใหม่ได้อย่างง่ายดาย
    • ข้อแย่ที่สุดก็คือใคร ๆ ก็เขียน parser ได้ภายใน 30 นาที
    • จึงเกิด implementation ที่ผิด ข้อมูลที่ผิด และพฤติกรรมประหลาดที่ไม่ได้กำหนดไว้ได้ง่าย
    • JSON และ YAML ก็มีปัญหาคล้ายกัน
    • XML แม้จะดูไม่ค่อยสวย แต่ก็ดูเหมือนจะแข็งแรงทนทานที่สุด

  • คนที่ชอบ CSV คงไม่เคยถูกขอให้จัดการการป้องกัน CSV injection ในสภาพแวดล้อมองค์กร

    • มีทรัพยากรดี ๆ บนเว็บไม่มากนัก
    • แหล่งข้อมูลที่ดีที่สุดคือ <a href="https://georgemauer.net/2017/10/07/csv-injection.html" rel="nofollow">ที่นี่</a>

  • มีหลายเหตุผลที่ชอบ CSV

    • สามารถเขียนโปรแกรมด้วย C แล้วพิมพ์ผลออกเป็น CSV ได้โดยตรงสำหรับหลายอย่าง
    • สามารถเขียนมิดเดิลแวร์ง่าย ๆ ที่แปลงจากฐานข้อมูลเกือบทุกชนิดหรือ "สิ่ง" ทั่วไปให้เป็น CSV ได้อย่างง่ายดาย
    • สามารถเอา CSV เข้า Excel แล้วทำอะไรก็ได้ตามต้องการ
    • ก็ชอบไฟล์ ini เช่นกัน เพราะแก้ไขได้ตรง ๆ ใน Notepad
    • แต่ก็อยากให้มีโครงร่าง/โครงสร้างทั่วไปสักแบบหนึ่ง

  • ช่วงนี้กำลังพัฒนาโซลูชันที่ใช้ Raspberry Pi

    • เวอร์ชันแรกใช้ฐานข้อมูล SQLite แต่เสียหายหลังผ่านวงจรเปิดปิดไฟไปไม่กี่วัน
    • ได้ลองดูไฟล์ Parquet แต่ไม่ค่อยเหมาะกับงานแบบ append-only
    • เลยทำวิธีบันทึกอีเวนต์ลงในไฟล์ IPC และค่อย "flush" เป็นไฟล์ Parquet เป็นระยะ
    • มันใช้งานได้และมีประสิทธิภาพ แต่ไม่ง่ายที่จะทำให้ถูกต้อง
    • สำหรับนักพัฒนาทั่วไป CSV (หรือ JSONL) ก็ยังดีที่สุด

  • สิ่งที่ไม่น่าตื่นเต้นของ CSV คือ parser และ serializer ที่เขียนแบบรีบ ๆ มักทำผิดซ้ำ ๆ เรื่องการจัดการอัญประกาศ

    • เคยระแวง CSV มานาน แต่พอเริ่มเรียน Python และใช้โมดูล csv ใน standard library ที่ยอดเยี่ยม ก็เปลี่ยนมุมมองไป

  • ถ้านี่เป็นจดหมายรักจริง ๆ มันก็คงถูกเขียนมาในรูปแบบ CSV

  • ข้อโต้แย้งต่อ JSON ไม่ค่อยน่าเชื่อเท่าไร

    • ไม่จำเป็นต้องเพิ่มชื่อให้ทุกฟิลด์เสมอไป
    • ถ้าเทียบ CSV กับ JSON, JSON จะใหญ่กว่าเล็กน้อย แต่เครื่องหมายวงเล็บก็แสดงความสามารถในการมีความเรียบง่ายหรือซับซ้อนได้
    • เพราะ CSV เรียบง่าย คนจึงมักไม่ใช้ไลบรารีสำหรับ parsing/encoding
    • parser ของ JSON จะให้ค่าที่คาดหวังเสมอ และภาษาเองก็น่าจะใช้ parser แบบ SIMD ที่มีประสิทธิภาพมาก
    • ยังมีปัญหาเรื่องมาตรฐานด้วย เช่น ไฟล์ CSV ใช้จุลภาค เว้นวรรค เซมิโคลอน ไพป์ ฯลฯ หรือใช้ CR, LF, CRLF และสามารถ escape อัญประกาศได้หรือไม่
    • JSON ไม่มีปัญหาเหล่านี้
    • JSON มีชนิดข้อมูล มี 6 ชนิดย่อมดีกว่าไม่มีเลย
    • JSON ไม่ได้สมบูรณ์แบบ แต่โดยทั่วไปดีกว่า CSV

  • ในฐานะคนที่ชอบฟอร์แมตสมัยใหม่ เวลาไม่แน่ใจจะใช้ CSV หรือ JSONL

    • เพราะส่วนใหญ่เป็นข้อความล้วน จึงค้นหาด้วย grep ได้ง่ายและรองรับการสตรีม
    • ความสามารถส่วนใหญ่ที่ระบุไว้ในบทความนั้น JSONL ก็มีเหมือนกัน
    • บีบอัดด้วย gzip หรือ zstd ได้ดี
    • การบีบอัดอาจลดข้อดีบางส่วนของการเป็นข้อความล้วน แต่ ripgrep ก็ยังค้นหาไฟล์บีบอัดได้
    • ข้อดีอีกอย่างของ JSONL คือสามารถแบ่งเป็นไฟล์ย่อยที่เล็กกว่าได้ง่าย