FracturedJson

 (github.com/j-brooke)
6 คะแนน โดย GN⁺ 2026-01-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ชุดยูทิลิตีสำหรับจัดรูปแบบ ข้อมูล JSON ให้มนุษย์อ่านได้ง่าย พร้อมคงความกะทัดรัดไว้
  • จัดให้สามารถแสดงอาร์เรย์และอ็อบเจ็กต์เป็น บรรทัดเดียวให้มากที่สุด และเมื่อโครงสร้างคล้ายกันจะ จัดเรียงเป็นรูปแบบตาราง
  • รองรับ การเก็บรักษาคอมเมนต์ แม้ JSON มาตรฐานจะไม่มีคอมเมนต์ แต่สามารถคงไว้ได้ตามการใช้งานจริงที่พบได้บ่อย
  • ใช้งานได้ในหลายสภาพแวดล้อม เช่น ไลบรารี .NET, แพ็กเกจ JavaScript/TypeScript, ส่วนขยาย VS Code และ ตัวฟอร์แมตบนเบราว์เซอร์
  • เป็นเครื่องมือที่ช่วยแก้ข้อจำกัดด้านความอ่านง่ายของ JSON formatter แบบเดิม และ เพิ่มความเข้าใจเชิงภาพให้กับนักพัฒนาและนักวิเคราะห์ข้อมูล

ภาพรวมของ FracturedJson

  • FracturedJson คือชุดยูทิลิตีที่สร้าง รูปแบบ JSON แบบกะทัดรัด แต่ยังอ่านง่ายสำหรับมนุษย์
    • อาร์เรย์และอ็อบเจ็กต์จะถูกแสดงในบรรทัดเดียวหากไม่ยาวหรือซับซ้อนเกินไป
    • หลายบรรทัดที่มีโครงสร้างคล้ายกันจะ จัดแนวฟิลด์ให้แสดงเป็นตาราง
    • อาร์เรย์ที่ยาวจะถูกแบ่งหลายบรรทัด โดยวางหลายรายการไว้ในหนึ่งบรรทัด
  • สามารถควบคุมรูปแบบเอาต์พุตได้ด้วยการตั้งค่าหลากหลาย และในกรณีส่วนใหญ่ค่าเริ่มต้นก็ให้ผลลัพธ์ที่ดูดีอยู่แล้ว
  • มีให้ใช้งานในรูปแบบหน้าฟอร์แมตเตอร์บนเบราว์เซอร์, ไลบรารี .NET, แพ็กเกจ JavaScript/TypeScript และส่วนขยาย VS Code
  • ยังมีการแนะนำตัวเลือกสำหรับ Python แยกต่างหากด้วย

Motivation

  • ไลบรารี JSON ส่วนใหญ่มักมี เพียงสองรูปแบบ
    • Minified JSON: มีประสิทธิภาพแต่คนอ่านได้ยาก
    • Beautified/Indented JSON: กระจายตัวกว้างเกินไป ทำให้มองภาพรวมได้ช้า
  • FracturedJson จัดรูปแบบข้อมูลในลักษณะเหมือนคนเขียนเอง
    • จะ คงคอนเทนเนอร์ไว้ในบรรทัดเดียว ยกเว้นเมื่อยาวหรือซับซ้อนเกินไป
    • อาร์เรย์หรืออ็อบเจ็กต์ที่คล้ายกันจะ จัดเรียงในรูปแบบตาราง

วิธีการทำงาน (How It Works)

  • FracturedJson ใช้รูปแบบการจัดฟอร์แมต 4 ประเภท
    1. Inlined: แสดงอ็อบเจ็กต์หรืออาร์เรย์ที่สั้นและเรียบง่ายในบรรทัดเดียว
      • ใช้การตั้งค่า MaxInlineComplexity เพื่อควบคุมระดับการซ้อนที่ยอมรับได้
    2. Compact Multiline Array: แสดงหลายรายการในหนึ่งบรรทัด แต่แบ่งออกเป็นหลายบรรทัด
      • ปรับระดับการซ้อนที่ยอมรับได้ด้วย MaxCompactArrayComplexity และสามารถปิดได้ด้วย -1
    3. Table: จัดเรียงรายการที่มีโครงสร้างคล้ายกันใน รูปแบบจัดแนวตามคอลัมน์
      • หากคอนเทนเนอร์ภายในซับซ้อนเกินไป อาจย่อเฉพาะบางส่วน
      • ควบคุมได้ด้วย MaxTableRowComplexity และ TableCommaPlacement
    4. Expanded: หากไม่เข้าเงื่อนไขข้างต้น จะแสดงแต่ละรายการหลายบรรทัดพร้อมการเยื้อง

การจัดการคอมเมนต์

  • แม้ JSON มาตรฐานจะไม่อนุญาตให้มีคอมเมนต์ แต่ FracturedJson รองรับ การเก็บรักษาคอมเมนต์
    • คอมเมนต์จะถูกเก็บไว้ร่วมกับองค์ประกอบที่เกี่ยวข้อง และรองรับทั้งคอมเมนต์หลายบรรทัดและคอมเมนต์แบบอินไลน์

Discussions

  • มีพื้นที่ GitHub Discussions สำหรับคำถามจากผู้ใช้ ฟีดแบ็ก และข้อเสนอแนะ
  • ใช้พูดคุยเกี่ยวกับโปรเจกต์และเสนอแนวทางการปรับปรุงได้

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

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

 
GN⁺ 2026-01-03
ความคิดเห็นบน Hacker News

  • ตอนนี้โปรเจกต์นี้มี implementation ที่ยังดูแลอยู่ 2 ตัว
    ตัวหนึ่งคือเวอร์ชัน C# (FracturedJson .NET Library) อีกตัวคือเวอร์ชัน TypeScript/JavaScript (FracturedJsonJs)
    ก่อนหน้านี้เคยมีเวอร์ชัน Python ล้วนด้วย แต่ตอนนี้ไม่ได้ดูแลต่อแล้ว และถูกแทนที่ด้วย Python wrapper ที่ครอบโค้ด C# (fractured-json)
    เวอร์ชัน Python นี้ระบุว่าต้องใช้ .NET runtime จึงมีข้อเสียคือไม่ได้ติดตั้งง่ายด้วยแค่ pip install
    ผมคิดว่านี่เป็นโอกาสที่ดีในการสร้าง conformance suite ที่ไม่ผูกกับภาษา — ชุดทดสอบแบบ data-driven ที่ใช้ตรวจสอบได้ว่าแต่ละ implementation ทำงานเหมือนกันหรือไม่
    อนึ่ง เวอร์ชัน Python เก่าก็ใช้การทดสอบลักษณะนี้อยู่แล้ว (ข้อมูลทดสอบของ compact-json)

    • ผมเพิ่งพอร์ตมันไปเป็น Rust และตั้งใจจะดูแลต่อจากนี้
      น่าจะเพิ่มไว้ในคอมเมนต์ต้นฉบับได้
      ดูรายละเอียดได้ที่ fracturedjson-rs GitHub และ แพ็กเกจบน crates.io
      คอมเมนต์อธิบายที่เกี่ยวข้องอยู่ ที่นี่
    • เป็นไอเดียที่ดี แต่ผมคิดว่ามันยากที่จะไปถึงระดับ การรับประกันความสมมูลของโปรแกรม ที่เกินกว่าชุดทดสอบ
    • อันนี้แทบจะเป็น pure function อยู่แล้ว เลยเขียน test harness ได้ง่ายมาก
    • การทดสอบแบบ data-driven มีประสิทธิภาพมากในการ สร้างความเชื่อมั่น ให้กับไลบรารี
      html5lib-tests หรือ xss-bench ที่ผมทำก็เป็นตัวอย่างแบบนั้น

  • ผมทำเวอร์ชันที่พอร์ตไป Rust ไว้แล้ว และมีเครื่องมือ CLI สำหรับจัดรูปแบบ JSON ให้ออกมาเป็นฟอร์แมตนี้
    ติดตั้งได้จาก fracturedjson-rs และ แพ็กเกจบน crates.io (cargo install fracturedjson)
    มีตัวเลือกหลายแบบ และควบคุมรายละเอียดได้ เช่น วิธีใส่คอมเมนต์, สไตล์การเยื้อง, ข้อจำกัดความกว้างบรรทัด เป็นต้น

    • เวอร์ชันที่พอร์ตมาก็เป็น งานดัดแปลง เช่นกัน จึงควรรักษาการระบุลิขสิทธิ์ของผู้เขียนต้นฉบับไว้

  • โปรเจกต์นี้เจ๋งมาก
    ผมชอบแนวทางที่ทำให้ JSON อ่านโดยมนุษย์ได้ง่ายขึ้น
    ในทางกลับกัน ผมกำลังพัฒนา bonjson ที่ทำให้ JSON เป็นมิตรกับเครื่องมากขึ้น
    มันมีความสามารถและข้อจำกัดเหมือน JSON ทุกประการ แต่สามารถอ่านและเขียนได้เร็วกว่า 35 เท่า
    ไม่มี type หรือฟีเจอร์ใหม่ใด ๆ มีแค่ทำสิ่งที่ JSON ทำได้อย่างตรงไปตรงมา

    • JSON เป็นเพียงรูปแบบสัญลักษณ์ ดังนั้นผมคิดว่าจำเป็นต้องมี โมเดลข้อมูลเชิงรูปแบบ
      ตัวอย่างเช่น มันไม่ได้ระบุ bit width ของตัวเลข หรือแยกว่าเป็นจำนวนเต็ม/ทศนิยมลอยตัว
      ถ้ามีโมเดลแบบนี้ก็จะทำ mapping แบบ 1:1 ระหว่าง representation ได้
      ผมกำลังเขียน บทความนี้ เกี่ยวกับประเด็นดังกล่าว
    • น่าสนใจ แต่เมื่อเทียบกับคำกล่าวที่ว่า “ทำได้ทุกอย่างที่ JSON ทำได้” ข้อจำกัดด้าน ความปลอดภัย ก็ดูชวนแปลกใจอยู่บ้าง
      เช่น สตริงอย่าง "a\u0000b" เป็น JSON ที่ถูกต้อง แต่ถ้ามัน serialize ไม่ได้ คำกล่าวนั้นก็ไม่อาจถือว่าจริงได้เต็มที่
    • อยากรู้ว่าอะไรเป็นแรงบันดาลใจให้คุณทำสิ่งนี้
      ผมเคยทำ serializer ที่บันทึก/โหลดทั้ง JSON และไฟล์ไบนารีผ่านอินเทอร์เฟซเดียวกัน
      จากประสบการณ์ของผม JSON เป็นฟอร์แมตที่ ข้อจำกัดเยอะและข้อดีน้อย
      เลยเปลี่ยนไปใช้ฟอร์แมตที่ผ่อนปรนกว่า ซึ่งละเว้น comma, colon, quote ได้ และรองรับสตริงหลายบรรทัดกับคอมเมนต์
      อยากให้เลิกทำเหมือน JSON เป็นฟอร์แมตที่ “อ่านง่ายสำหรับมนุษย์” ได้แล้ว
      เราควรมีทางเลือกมาตรฐานสำหรับสภาพแวดล้อมที่ไม่ได้ยึด JSON เป็นศูนย์กลาง
    • ทำให้นึกถึง Lite3 ที่เพิ่งโพสต์เมื่อไม่นานนี้
    • อยากรู้ว่า อัตราการบีบอัด เป็นอย่างไร

  • น่าทึ่งมาก
    ผมก็เคยทำอะไรคล้าย ๆ กันด้วย Python ประมาณ 200 บรรทัด แต่ไม่รู้มาก่อนเลยว่ามีไลบรารีแบบนี้อยู่แล้ว

  • อยากรู้ว่ามีตัวเลือกให้รับ pipe input แบบ jq หรือไม่

    • ดูจาก โค้ด C# CLI ใน repository จะเห็นว่าสามารถระบุให้รับจาก standard input/output หรือจากไฟล์ได้
      เวอร์ชัน JavaScript และ Python wrapper ก็มีเครื่องมือ CLI แบบเดียวกัน
    • RCL จะทำ pretty-print เป็นค่าเริ่มต้น
      ใช้ rcl e เพื่อดูฟอร์แมต RCL และ rcl je เพื่อดูผลลัพธ์แบบ JSON
      มันไม่มีการจัดแนวตารางแบบ FracturedJson แต่ใช้ algorithm Philip Wadler's A Prettier Printer เพื่อขึ้นบรรทัดอัตโนมัติตามความกว้าง
    • จะใช้ process substitution แบบ <() เพื่อสร้างไฟล์ชั่วคราวมาประมวลผลก็ได้
    • โดยทั่วไป ถ้าระบุชื่อไฟล์อินพุตเป็น - ก็มักจะหมายถึงให้อ่านจาก stdin

  • ผมสร้าง JSON formatter ชื่อ Virtuous แต่พอเห็นอันนี้แล้วถึงกับรู้สึกว่าอยากเลิกใช้ formatter ของตัวเอง
    เป็น งานที่ยอดเยี่ยม จริง ๆ

  • ผมเคยทำ สคริปต์ Groovy ชื่อ “mommyjson”
    แทนที่จะพยายามรักษาฟอร์แมต JSON มันจะแสดง ความสัมพันธ์กับ parent ของแต่ละองค์ประกอบ (เช่น index ของอาร์เรย์ หรือชื่ออ็อบเจ็กต์) ไว้ในบรรทัดเดียว เพื่อให้มองตำแหน่งของข้อมูลได้อย่างเป็นธรรมชาติ
    ดูโค้ด
    เพราะ Groovy ไม่ค่อยนิยม จึงคงดีถ้ามีคนพอร์ตเป็น Python

    • เป็นไอเดียที่ดี! การที่มีเครื่องมือแนวนี้อยู่หลายตัวก็บ่งบอกว่าผู้คนต้องการมันจริง ๆ
      ตัวอย่างเด่น ๆ คือ gron และ jstream ที่ผมทำ
      ถ้าเพิ่ม ตัวอย่าง output ตอนใช้งาน ก็น่าจะช่วยให้เข้าใจง่ายขึ้น
    • สงสัยว่ามีตัวอย่าง output ให้ดูไหม

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

    • เหตุผลที่มักใช้เครื่องมือแบบนี้ก็คือ ไม่มี schema ที่ชัดเจนหรือไม่มีเครื่องมือ visualization
      มันมีประโยชน์มากในสถานการณ์ดีบักที่ต้องทำความเข้าใจข้อมูลซ้อนลึกที่ซับซ้อนอย่างรวดเร็ว
      โดยเฉพาะเวลาทำงานกับโค้ดเชื่อมต่อระบบภายนอก ซึ่งเจอแบบนี้บ่อย
    • บางครั้งผมก็ใช้ jq หรือ python -m json.tool เพื่ออ่านข้อมูล JSON
      ถ้าเครื่องมือแบบนี้แสดงผลได้ดีกว่า สิ่งนั้นก็มีคุณค่ามากพอแล้ว
    • ถ้าตัดองค์ประกอบที่มนุษย์อ่านได้ออกไป JSON ก็เป็น encoding ที่ไม่มีประสิทธิภาพ
      สุดท้ายข้อดีของ JSON ก็คือ ทั้งคนและเครื่องอ่านได้ ดังนั้นในงานดีบักมันก็ยังมีความหมายอยู่

  • ผมชอบไอเดียนี้มาก
    เหตุผลหลักที่การนำไปใช้ยังช้าคือยังขาดการรองรับในหลายภาษาและจาก package manager (เช่น homebrew)
    ถ้าคอมไพล์ไลบรารี .NET ให้เป็น shared library ที่เข้ากันได้กับ C ก็จะทำให้หลายภาษานำไปใช้ได้ง่ายขึ้น

  • เป็นแนวทางที่น่าสนใจ
    ถ้า code formatter ทำงานแบบนี้ได้ก็คงดี
    ตอนนี้ formatter ต่าง ๆ แข็งทื่อเกินไปจนมองโครงสร้างได้ยาก

    • ผมทำ C++ formatter ตัวหนึ่ง โดยใช้เพียงอ็อบเจ็กต์ 2 แบบคือ ตารางจัดแนวด้วยแท็บ และ บล็อกบรรทัดเดียว
      คอมเมนต์จะจัดให้ชิดขวาอย่างเป็นระเบียบ
      ด้วยโครงสร้างแบบนี้ จึงจัดแนว switch-case block หรือ macro table แบบ 2D ได้ง่าย
      เลเยอร์พื้นฐานผมเขียนเสร็จภายในชั่วโมงเดียว และกำลังออกแบบให้ตรวจจับบล็อกอัตโนมัติด้วยการผสาน LSP กับ code observation
    • ผมเคยทำ XML formatter เองให้มันดูเป็นตาราง
      ตามอุดมคติเราควรเลิกใช้ XML ไปแล้ว แต่เพราะ ข้อจำกัดของระบบ legacy ก็เลยหลีกเลี่ยงไม่ได้