6 điểm bởi GN⁺ 2026-01-03 | 1 bình luận | Chia sẻ qua WhatsApp
  • Bộ tiện ích định dạng giúp sắp xếp dữ liệu JSON để con người dễ đọc nhưng vẫn giữ được dạng gọn nhẹ
  • Biểu diễn mảng và đối tượng trên một dòng khi có thể, và khi cấu trúc tương tự nhau thì căn chỉnh theo dạng bảng
  • Hỗ trợ bảo toàn chú thích, giữ lại cả các chú thích không có trong chuẩn JSON nhưng thường gặp trong môi trường sử dụng thực tế
  • Có thể dùng trong nhiều môi trường như thư viện .NET, gói JavaScript/TypeScript, tiện ích mở rộng VS Code, trình định dạng trên trình duyệt
  • Công cụ giúp cải thiện giới hạn về khả năng đọc của các trình định dạng JSON hiện có, nâng cao mức độ hiểu trực quan cho nhà phát triển và nhà phân tích dữ liệu

Tổng quan về FracturedJson

  • FracturedJson là bộ tiện ích tạo ra định dạng JSON gọn nhưng vẫn dễ đọc với con người
    • Mảng và đối tượng sẽ được in trên một dòng nếu không quá dài hoặc quá phức tạp
    • Nhiều dòng có cấu trúc tương tự sẽ được căn chỉnh trường theo dạng bảng
    • Các mảng dài sẽ được trải trên nhiều dòng, với nhiều phần tử trên mỗi dòng
  • Có thể kiểm soát định dạng đầu ra bằng nhiều thiết lập khác nhau, và trong đa số trường hợp, chỉ với cấu hình mặc định cũng tạo ra kết quả dễ nhìn
  • Được cung cấp dưới dạng trang trình định dạng trên trình duyệt, thư viện .NET, gói JavaScript/TypeScript và tiện ích mở rộng VS Code
  • Ngoài ra còn có hướng dẫn riêng cho tùy chọn dùng với Python

Động lực

  • Hầu hết thư viện JSON chỉ cung cấp hai kiểu định dạng
    • Minified JSON: hiệu quả nhưng con người khó đọc
    • Beautified/Indented JSON: bị trải quá rộng nên khó nắm bắt nhanh
  • FracturedJson định dạng dữ liệu như cách con người tự viết
    • Giữ container trên một dòng trừ khi quá phức tạp hoặc quá dài
    • Căn chỉnh các mảng hoặc đối tượng tương tự theo dạng bảng

Cách hoạt động (How It Works)

  • FracturedJson sử dụng bốn kiểu định dạng
    1. Inlined: biểu diễn đối tượng hoặc mảng ngắn và đơn giản trên một dòng
      • Dùng thiết lập MaxInlineComplexity để kiểm soát mức lồng nhau được phép
    2. Compact Multiline Array: đặt nhiều phần tử trên một dòng nhưng hiển thị qua nhiều dòng
      • Có thể điều chỉnh mức độ cho phép lồng nhau bằng MaxCompactArrayComplexity, và có thể vô hiệu hóa bằng -1
    3. Table: căn chỉnh các phần tử có cấu trúc tương tự theo dạng cột
      • Nếu container bên trong quá phức tạp thì chỉ một phần sẽ được rút gọn
      • Có thể kiểm soát bằng MaxTableRowComplexityTableCommaPlacement
    4. Expanded: nếu không phù hợp các điều kiện trên, mỗi phần tử sẽ được thụt lề và hiển thị trên nhiều dòng

Xử lý chú thích

  • Chuẩn JSON không cho phép chú thích, nhưng FracturedJson hỗ trợ tính năng bảo toàn chú thích
    • Chú thích được giữ cùng với phần tử liên quan, và có thể xử lý cả chú thích nhiều dòng lẫn chú thích nội tuyến

Discussions

  • Cung cấp không gian GitHub Discussions cho câu hỏi, phản hồi và đề xuất của người dùng
  • Có thể thảo luận về dự án và đề xuất cải tiến liên quan

1 bình luận

 
GN⁺ 2026-01-03
Ý kiến trên Hacker News
  • Hiện tại dự án này có hai implementation đang được duy trì
    một là bản C# (FracturedJson .NET Library), bản còn lại là TypeScript/JavaScript (FracturedJsonJs)
    Trước đây cũng từng có bản Python thuần, nhưng giờ không còn được duy trì nữa và đã được thay bằng Python wrapper bọc mã C# (fractured-json)
    Bản Python này ghi rõ là cần .NET runtime, nên nhược điểm là khó cài chỉ bằng pip install
    Tôi nghĩ đây là cơ hội tốt để tạo một conformance suite độc lập với ngôn ngữ — tức một bộ test dựa trên dữ liệu có thể kiểm chứng xem nhiều implementation có hành xử giống nhau không
    Tham khảo thêm thì bản Python cũ đã dùng dạng test như vậy rồi (dữ liệu test compact-json)

    • Tôi vừa port sang Rust và dự định sẽ tiếp tục bảo trì
      Có lẽ nên thêm vào bình luận gốc
      Xem chi tiết tại GitHub fracturedjson-rsgói trên crates.io
      Bình luận giải thích liên quan ở đây
    • Ý tưởng hay, nhưng tôi nghĩ rất khó đi xa hơn các test case để tiến tới bảo đảm tính tương đương chương trình
    • Cái này gần như là một hàm thuần nên viết test harness sẽ rất dễ
    • Test dựa trên dữ liệu rất hiệu quả trong việc xây dựng niềm tin vào thư viện
      html5lib-tests hay xss-bench do tôi làm cũng là những ví dụ như vậy
  • Tôi đã làm một bản port sang Rust, và có thể dùng CLI để format JSON sang kiểu này
    Có thể cài từ fracturedjson-rsgói trên crates.io (cargo install fracturedjson)
    Nó cung cấp nhiều tùy chọn, cho phép kiểm soát chi tiết như cách xử lý comment, kiểu thụt lề, giới hạn độ rộng dòng v.v.

    • Bản port cũng là tác phẩm phái sinh, nên phải giữ nguyên ghi chú bản quyền của tác giả gốc
  • Dự án này thật sự rất hay
    Tôi thích hướng làm cho JSON dễ đọc hơn với con người
    Còn tôi thì đang phát triển bonjson, đi theo hướng ngược lại là làm JSON thân thiện hơn với máy
    Nó có đúng cùng chức năng và ràng buộc như JSON, nhưng đọc và ghi nhanh hơn 35 lần
    Không có kiểu dữ liệu hay tính năng mới nào, chỉ thực hiện chính xác những gì JSON làm được

    • Tôi nghĩ JSON là một ký pháp đơn giản nên cần một mô hình dữ liệu có cấu trúc
      Ví dụ, nó không chỉ rõ độ rộng bit của số hay phân biệt giữa số nguyên và số thực dấu chấm động
      Nếu có mô hình như vậy thì sẽ có thể ánh xạ 1:1 giữa các biểu diễn
      Tôi đang viết bài này về chủ đề liên quan
    • Khá thú vị, nhưng so với tuyên bố “làm được mọi thứ JSON làm được” thì các giới hạn về bảo mật có phần bất ngờ
      Ví dụ chuỗi như "a\u0000b" là JSON hợp lệ, nên nếu không serialize được nó thì tuyên bố đó không hoàn toàn đúng
    • Tôi tò mò điều gì đã khiến bạn làm ra cái này
      Tôi từng tạo một serializer có thể lưu/tải cả JSON lẫn file nhị phân qua cùng một interface
      Theo kinh nghiệm của tôi, JSON là một định dạng nhiều hạn chế mà ít lợi ích
      Vì thế tôi đổi sang một định dạng lỏng hơn, có thể bỏ dấu phẩy, dấu hai chấm, dấu ngoặc kép, và cho phép chuỗi nhiều dòng cùng comment
      Tôi mong mọi người ngừng giả vờ JSON lúc nào cũng là định dạng “dễ đọc với con người”
      Cần có một lựa chọn tiêu chuẩn thay thế cho các môi trường không lấy JSON làm trung tâm
    • Gợi tôi nhớ tới Lite3 mới được đăng gần đây
    • Tôi tò mò về tỷ lệ nén của nó thế nào
  • Thật bất ngờ
    Tôi cũng từng tự làm tính năng tương tự bằng Python trong khoảng 200 dòng, mà không biết là đã có thư viện như thế này rồi

  • Không rõ có tùy chọn nhận đầu vào qua pipe như jq không

    • Nhìn vào mã CLI C# trong repo thì có thể chỉ định stdin/stdout hoặc file
      Bản JavaScript và Python wrapper cũng cung cấp cùng công cụ CLI đó
    • RCL mặc định sẽ pretty-print
      Với rcl e bạn sẽ thấy định dạng RCL, còn rcl je sẽ xuất JSON
      Nó không có căn bảng như FracturedJson, nhưng dựa trên thuật toán A Prettier Printer của Philip Wadler nên tự động xuống dòng theo độ rộng
    • Cũng có thể dùng thay thế tiến trình <() để tạo file tạm và xử lý
    • Trong đa số trường hợp, nếu đặt tên file đầu vào là - thì có thể đọc từ stdin
  • Tôi có làm một JSON formatter tên là Virtuous, và xem cái này xong tôi gần như muốn bỏ formatter của mình vì nó quá ấn tượng
    Thật sự là một công trình xuất sắc

  • Tôi từng làm một script Groovy tên là “mommyjson”
    Thay vì giữ nguyên format JSON, nó hiển thị quan hệ cha của từng phần tử (chỉ số mảng, tên object, v.v.) trên một dòng, giúp xác định vị trí dữ liệu trực quan hơn
    Xem mã nguồn
    Vì Groovy không phổ biến nên sẽ hay nếu có bản port sang Python

    • Ý tưởng hay đấy! Việc đã có nhiều công cụ kiểu này cho thấy đây rõ ràng là nhu cầu thật sự của mọi người
      Tiêu biểu có gronjstream do tôi làm
      Nếu thêm ví dụ đầu ra khi sử dụng thì sẽ dễ hiểu hơn
    • Tôi tò mò không biết có ví dụ output nào không
  • Tôi nghi ngờ liệu JSON có thật sự là một định dạng cần được cải thiện để con người dễ đọc hơn hay không
    Có nhiều cách tốt hơn để hiển thị dữ liệu cho người dùng, và tôi nghĩ JSON đúng ra nên được dùng để truyền dữ liệu giữa các hệ thống

    • Lý do người ta dùng các công cụ kiểu này thường là khi không có schema rõ ràng hoặc công cụ trực quan hóa
      Nó hữu ích trong các tình huống debug cần nhanh chóng nắm được dữ liệu lồng nhau phức tạp
      Điều này đặc biệt hay xảy ra khi làm code tích hợp với hệ thống bên ngoài
    • Tôi cũng thường dùng jq hoặc python -m json.tool để đọc dữ liệu JSON
      Nếu các công cụ kiểu này hiển thị tốt hơn thì hoàn toàn đáng giá
    • Nếu bỏ đi yếu tố con người đọc được thì JSON là một kiểu mã hóa kém hiệu quả
      Rốt cuộc điểm mạnh của JSON là cả người lẫn máy đều đọc được, nên với mục đích debug nó vẫn có ý nghĩa
  • Tôi rất thích ý tưởng này
    Lý do hiện tại nó được chấp nhận chậm phần lớn là vì thiếu hỗ trợ cho nhiều ngôn ngữ và trình quản lý gói (như homebrew)
    Nếu biên dịch thư viện .NET thành shared library tương thích C thì sẽ dễ dùng hơn từ nhiều ngôn ngữ

  • Cách tiếp cận này khá thú vị
    Giá mà code formatter cũng hoạt động kiểu này thì tốt
    Các formatter hiện nay quá cứng nhắc nên khó nhìn ra cấu trúc

    • Tôi đã làm một C++ formatter chỉ dùng hai loại object là bảng căn theo tabkhối một dòng
      Comment được căn thẳng hàng về bên phải để bố trí gọn gàng
      Nhờ cấu trúc này mà có thể dễ dàng căn theo 2D cho các khối switch-case hay bảng macro
      Lớp cơ bản tôi code xong chỉ trong một giờ, và hiện đang thiết kế để kết hợp LSP với quan sát mã nhằm tự động phát hiện block
    • Trước đây tôi từng tự làm một XML formatter để nó trông như dạng bảng
      Lý tưởng nhất là nên bỏ XML đi, nhưng vì ràng buộc legacy nên không còn cách nào khác