- JSON không cho phép sử dụng chú thích gốc; giải pháp thay thế bao gồm khóa tùy chỉnh hoặc bộ xử lý trước.
- Việc sử dụng các bình luận không chuẩn có thể gây ra rủi ro về khả năng tương thích hoặc mất thông tin.
- Tài liệu bên ngoài hoặc chỉ sử dụng JSONC trong quá trình phát triển là những giải pháp thay thế an toàn hơn.

Làm việc với các tệp JSON là một nhu cầu thiết yếu hàng ngày đối với các nhà phát triển phần mềm, người tạo ứng dụng web và những người quản lý cấu hình hiện đại. Tuy nhiên, một việc tưởng chừng đơn giản như thêm chú thích giải thích vào trong tệp lại có thể trở thành một cơn ác mộng thực sự, vì định dạng JSON, về bản chất, không chính thức cho phép chú thích . Nhiều người tự hỏi làm thế nào có thể ghi lại cấu trúc hoặc làm rõ các phần cụ thể của dữ liệu mà không gây ra lỗi phân tích hoặc thực hiện các thao tác không tốt.
Trong bài viết này, bạn sẽ tìm hiểu lý do tại sao JSON không cho phép bình luận , các giải pháp thay thế tốt nhất hiện nay — bởi vì, tất nhiên, các nhà phát triển luôn tìm cách vượt qua những hạn chế — và những hệ quả của mỗi phương pháp. Bạn cũng sẽ khám phá cách tránh các vấn đề tương thích và các giải pháp thông minh nhất nếu bạn cần chú thích các tệp JSON để làm việc nhóm hoặc để dự đoán những thay đổi trong tương lai.
Tại sao JSON không hỗ trợ bình luận?
Trước khi đi sâu vào các thủ thuật và giải pháp thay thế, điều quan trọng là phải hiểu được gốc rễ của vấn đề. JSON (JavaScript Object Notation) được tạo ra như một định dạng đơn giản và hiệu quả để trao đổi dữ liệu giữa các hệ thống. Điểm mạnh chính của nó chính là sự đơn giản đó: nó chỉ hỗ trợ các cấu trúc dữ liệu như đối tượng, mảng, chuỗi, số, boolean và giá trị null. Không có không gian dành riêng cho siêu dữ liệu hoặc các chú thích giải thích hữu ích trong các ngôn ngữ lập trình khác.
Hạn chế này không phải là sự sơ suất, mà là một quyết định thiết kế có chủ đích của Douglas Crockford, người sáng tạo và là động lực chính đằng sau định dạng này. Như ông giải thích, ông đã loại bỏ các chú thích khỏi đặc tả vì nhiều người đang sử dụng chúng để đưa ra các chỉ thị phân tích cú pháp mà cuối cùng có thể dẫn đến sự không tương thích giữa các ứng dụng khác nhau hoặc cản trở quá trình xử lý tự động. Ý tưởng là để JSON trở nên phổ quát và dễ dự đoán nhất có thể , hy sinh một số khía cạnh như tài liệu nội bộ để đổi lấy khả năng tương tác.
Nếu bạn đã từng thử sử dụng các bình luận thông thường // comentario, /* comentario */ hoặc thậm chí # comentario theo kiểu Python hoặc Bash trong tệp JSON, bạn có thể gặp lỗi “Bình luận không được phép trong JSON”Thậm chí không thể vượt qua hạn chế này bằng một số thủ thuật hack đơn giản: trình phân tích cú pháp tiêu chuẩn sẽ từ chối đọc các tệp có nội dung không hoàn toàn tuân thủ định dạng.
Việc không có chú thích trong JSON gây ra những vấn đề gì?
Việc không thể thêm bình luận sẽ gây ra những hậu quả thực tế có thể ảnh hưởng đến mọi thứ, từ các dự án cá nhân đến sự phát triển của các ứng dụng doanh nghiệp lớn:
- Tài liệu trong tệp JSON không tồn tạiĐiều này gây khó khăn cho việc hiểu chức năng của từng phím hoặc lý do cho một số giá trị nhất định, đặc biệt là khi thời gian trôi qua hoặc nhiều người làm việc với cùng một tệp.
- Sửa đổi, mở rộng hoặc sửa đổi Chúng phải được thực hiện mà không thể giải thích trực tiếp những thay đổi trong tệp, điều này có thể dẫn đến nhầm lẫn trong các dự án cộng tác.
- Lỗi do quên hoặc diễn giải có nhiều khả năng xảy ra hơn, vì không ai có thể giải thích trực tuyến chức năng của từng bộ phận hoặc logic đằng sau một cấu trúc phức tạp là gì.
Vì không có cách chính thức nào để chèn bình luận, cộng đồng đã phát triển nhiều chiến lược và thủ thuật khác nhau để ghi lại, dù là gián tiếp, nội dung của các tệp JSON.
Giải pháp thay thế: Cách đưa bình luận vào tệp JSON
Mặc dù đặc tả kỹ thuật cấm sử dụng kiểu chú thích truyền thống , nhưng có nhiều cách để ghi chú tài liệu cho các tệp JSON. Mỗi cách đều có ưu điểm, hạn chế và rủi ro riêng, vì vậy điều quan trọng là phải hiểu rõ chúng trước khi quyết định sử dụng cách nào cho dự án của bạn.
1. Thêm các phím đặc biệt cho bình luận (giải pháp phổ biến nhất)
Không nghi ngờ gì, Kỹ thuật phổ biến và đơn giản nhất là thêm các cặp khóa-giá trị có mục đích hoạt động như một bình luận. Những tên mã không chắc chắn thường được sử dụng, chẳng hạn như _comentario o __nota__, không xung đột với bất kỳ khóa nào của dữ liệu “thực”.
Ví dụ cơ bản:
{ "_comment": "Đây là tệp cấu hình cho ứng dụng X", "user": "JohnDoe", "permissions": , "active": true }
Mục tiêu là để các ứng dụng sử dụng JSON bỏ qua các khóa này , hoặc để các nhà phát triển nhận ra ngay lập tức chúng là các chú thích chứ không phải là thông tin liên quan đến hoạt động.
Lợi ích:
- Cho phép bạn thêm lời giải thích vào trong tệp, bên cạnh mỗi trường yêu cầu.
- Tương thích với bất kỳ công cụ nào tuân thủ chuẩn JSON (miễn là nó bỏ qua các khóa mà nó không nhận ra).
Nhược điểm:
- Những "bình luận" này trở thành một phần của dữ liệu. Nếu tệp được sử dụng trong API công khai hoặc trong môi trường sản xuất nơi kích thước quan trọng, phương pháp này có thể tăng trọng lượng của tải một cách không cần thiết.
- Là một hội nghị không chính thức, Có thể xảy ra vấn đề nếu trong tương lai lược đồ JSON thực sự cần một khóa có cùng tên..
- Bất kỳ trình phân tích nào chỉ mong đợi một số khóa nhất định đều có thể không thành công nếu những đầu vào không mong muốn này xuất hiện.
2. Các biến thể không chính thức của JSON: JSONC
Một lựa chọn khác đã trở nên phổ biến trong số các nhà phát triển là sử dụng JSONC (JSON có bình luận), một định dạng không chính thức cho phép đưa bình luận vào bằng cách sử dụng // y /*...*/. Tuy nhiên, Các tệp JSONC này yêu cầu một bộ xử lý trước: một công cụ xóa các chú thích trước khi chuyển tệp tới bất kỳ trình phân tích cú pháp chuẩn nào.
Ví dụ về JSONC:
{ // Người dùng quản trị ứng dụng "user": "admin", /* Cài đặt quyền nâng cao */ "permissions": }
Để làm việc với JSONC, bạn có thể tìm các công cụ trực tuyến, gói Node.js hoặc tiện ích mở rộng trình soạn thảo như Visual Studio Code hỗ trợ định dạng này trong quá trình phát triển. Khi tệp của bạn đã sẵn sàng để triển khai lên môi trường sản xuất, trình tiền xử lý sẽ loại bỏ các chú thích và tạo ra JSON hợp lệ.
Ưu điểm: Giúp đơn giản hóa việc lập tài liệu trong quá trình phát triển mà không làm ảnh hưởng đến dữ liệu cuối cùng.
Nhược điểm: Phương pháp này chỉ hợp lệ trong giai đoạn phát triển. Nếu bạn quên xử lý tệp trước khi sử dụng, các công cụ phân tích sẽ báo lỗi.
3. Tài liệu bên ngoài: lựa chọn an toàn nhất
Đối với các dự án yêu cầu tuân thủ nghiêm ngặt tiêu chuẩn JSON, cách an toàn nhất là tách biệt tài liệu khỏi tệp JSON . Bạn có thể thực hiện điều này bằng cách tạo một tệp Markdown hoặc văn bản thuần túy giải thích cấu trúc, mục đích của từng trường và bất kỳ chi tiết liên quan nào khác. Ngoài ra, việc sử dụng tài liệu trong wiki của dự án hoặc các công cụ như Swagger/OpenAPI nếu bạn đang định nghĩa API cũng khá phổ biến.
Lợi ích:
- Không có cách nào để phá vỡ khả năng tương thích của trình phân tích cú pháp hoặc tăng kích thước dữ liệu.
- Tránh xung đột tên và giữ cho tệp JSON của bạn sạch sẽ và tập trung vào dữ liệu.
Nhược điểm:
- Tài liệu được tách biệt. Nếu ai đó chỉnh sửa JSON mà không cập nhật tài liệu bên ngoài, điều này có thể dẫn đến thiếu sự phối hợp.
- Phương pháp này không thực tế đối với các dự án nhỏ hoặc những người muốn tìm tất cả thông tin ở một nơi.
4. Bộ tiền xử lý và công cụ xây dựng
Mở rộng chiến lược của JSONC, các dự án lớn thường sử dụng các bộ tiền xử lý tùy chỉnh cho phép thêm nhận xét hoặc chỉ thị đặc biệt vào các tệp cấu hình. Các công cụ này, được tích hợp vào quy trình xây dựng ứng dụng, sẽ xử lý việc loại bỏ tất cả các nhận xét trước khi triển khai sản phẩm lên môi trường sản xuất.
Phương pháp này kết hợp sự tiện lợi của việc lập tài liệu nội bộ với tính bảo mật của việc tuân thủ tiêu chuẩn , nhưng đòi hỏi quy trình làm việc phức tạp hơn và sự chú ý để tránh vô tình tải lên các tệp thô.
Ví dụ nâng cao: Bình luận trong cấu trúc JSON phức tạp
Các nghiên cứu điển hình cho thấy cách sử dụng các quy ước để ghi lại tài liệu cho các tệp JSON, ngay cả khi có các đối tượng hoặc mảng lồng nhau.
Ví dụ với một số bình luận khác nhau:
{ "_comment1": "Thông tin cá nhân cơ bản", "tên": "Ana", "tuổi": 28, "thành phố": "Madrid", "_comment2": "Thông tin việc làm", "công ty": "InnovaSoft", "vị trí": "Lập trình viên", "kinh nghiệm": 5 }
Nếu bạn cần thêm chú thích bên trong các đối tượng lồng nhau:
{ "name": "Luis", "_comment": "Thông tin bổ sung", "additionaldata": { "email": "[email được bảo vệ]", "_comment": "Email này phải được người dùng xác minh" } }
Ghi nhớ: JSON không cho phép lặp lại các khóa ở cùng một cấp đối tượng, vì vậy nếu bạn cần đưa nhiều bình luận, bạn sẽ phải đặt cho chúng những tên duy nhất như _comentario1, _comentario2, Vv
Ý nghĩa và cân nhắc khi ghi lại tài liệu tệp JSON
Việc sử dụng bất kỳ phương pháp nào nêu trên đều có những tác dụng phụ cần cân nhắc kỹ trước khi đưa ra quyết định cuối cùng:
- Khóa chú thích chiếm dung lượng và di chuyển đến phần phụ trợ, API hoặc bất kỳ hệ thống nào sử dụng JSON.Nếu hiệu quả là yếu tố quan trọng thì tốt nhất nên tránh quá tải.
- Một số chương trình, chẳng hạn như hợp đồng API công khai, có thể từ chối các tệp có khóa không mong muốn.Luôn tham khảo tài liệu chính thức của dịch vụ trước khi thêm bình luận kiểu này.
- Nếu dự án phát triển và một ngày nào đó bạn cần sử dụng khóa mà bạn đã dùng làm bình luận, sự không tương thích có thể phát sinh.. Cố gắng chọn những cái tên lạ để giảm thiểu rủi ro.
- Một số trình phân tích cú pháp JSON cho phép tồn tại các khóa không xác định, một số khác thì không. Tính di động có thể bị ảnh hưởng tùy thuộc vào ngôn ngữ hoặc thư viện bạn sử dụng..
Sự khác biệt với các định dạng dữ liệu khác: YAML và XML
Có thể bạn đang thắc mắc tại sao các định dạng được sử dụng rộng rãi như YAML hoặc XML cho phép chú thích, trong khi JSON thì không. Câu trả lời nằm ở cách tiếp cận của mỗi định dạng.
YAML Nó nổi bật vì khả năng đọc được và cho phép các bình luận được đưa ra trước # bất cứ nơi nào trong tệp. Mặt khác, XML sử dụng các thẻ để chèn các giải thích sẽ bị trình phân tích bỏ qua.
Như chúng ta đã thấy, JSON ưu tiên tính phổ quát và độ phức tạp tối thiểu, loại bỏ bất kỳ thành phần nào không phải là một phần của dữ liệu; do đó, nó phổ biến trong các API, cấu hình và môi trường mà hiệu quả, tốc độ và khả năng tương thích là rất quan trọng.
Sử dụng phương pháp không chuẩn có thể gây ra những rủi ro gì?
Việc triển khai các giải pháp thay thế không phải là không có rủi ro . Những rủi ro quan trọng nhất là:
- Mất dữ liệu- Nếu bản phát hành trong tương lai chuẩn hóa bất kỳ phím chú thích nào, bạn có thể mất thông tin hoặc tạo ra xung đột trong ứng dụng của mình.
- Sự nhầm lẫn và hiểu lầm:Các nhà phát triển khác có thể không quen thuộc với quy ước của bạn và nghĩ rằng khóa chú thích là dữ liệu thực.
- Lỗi trong phân tích- Nếu JSON của bạn đến một hệ thống yêu cầu lược đồ cứng nhắc, bao gồm các trường không được hỗ trợ, có thể dẫn đến việc tệp bị từ chối hoặc lỗi âm thầm.
Những câu hỏi chính về chú thích JSON
- Có cách chính thức nào để thêm chú thích vào JSON không? Không, thông số kỹ thuật không cho phép điều đó.
- Tại sao không có hỗ trợ chính thức? Để giữ cho JSON đơn giản, nhanh chóng và tương thích nhất có thể.
- Tôi có giải pháp thay thế nào? Thêm khóa tùy chỉnh cho bình luận, sử dụng bộ xử lý trước trong quá trình phát triển hoặc duy trì tài liệu trong các tệp bên ngoài.
- Có rủi ro gì khi thêm bình luận theo cách không chuẩn không? Có, đặc biệt là về khả năng tương thích, dữ liệu bị nhầm lẫn và khả năng mất thông tin.
- Tôi có thể sử dụng JSONC trong sản xuất không? Không khuyến khích. Chỉ nên sử dụng trong môi trường phát triển kết hợp với bộ xử lý trước để dọn dẹp các bình luận trước khi triển khai.
- Điều gì xảy ra nếu tệp JSON được chú thích của tôi đến API bên ngoài? Rất có thể bạn sẽ nhận được lỗi và tệp sẽ bị từ chối.
Khuyến nghị và thực hành tốt nhất để ghi lại các tệp JSON
Tùy thuộc vào môi trường và yêu cầu của dự án, bạn có thể chọn phương án phù hợp nhất với nhu cầu của mình . Một số hướng dẫn hữu ích:
- Trong quá trình phát triển, hãy sử dụng các phím bình luận hoặc JSONC nếu nó giúp ích cho bạnNhưng đừng quên dọn dẹp các tập tin của bạn trước khi phát hành chúng để sản xuất.
- Đối với các dự án dài hạn hoặc hợp tác, hãy lựa chọn tài liệu bên ngoài.:Đây là giải pháp an toàn nhất, có khả năng mở rộng và phổ biến nhất.
- Nếu bạn phải đưa bình luận vào tệp, hãy sử dụng các quy ước rõ ràng và tên khóa không thể bị xung đột.Như
__nota_privada_dev__hoặc tương tự. - Luôn kiểm tra khả năng tương thích với các công cụ, API hoặc hệ thống bên ngoài sẽ sử dụng tệp JSON của bạn..
Về cơ bản, làm việc với JSON có nghĩa là chấp nhận các quy tắc của nó: không có chú thích chính thức, nhưng luôn có chỗ cho sự sáng tạo . Nếu bạn cần ghi chú cho bản thân hoặc đồng nghiệp, hãy chọn tùy chọn ít gây ảnh hưởng nhất, ghi chép lại các quy ước của bạn một cách cẩn thận và luôn chú ý đến khả năng tương thích trong tương lai. Mặc dù việc không thể làm rõ vấn đề ngay trong tệp tin có vẻ khó chịu, nhưng đó chính là thách thức và giá trị của thiết kế tối giản của JSON.