Sebuah artikel terperinci yang menjejaki evolusi dari XML kepada JSON kepada CBOR telah mencetuskan perbincangan sengit dalam kalangan pembangun, dengan ramai yang mempersoalkan sama ada CBOR layak mendapat perhatian dan mengkritik pengabaian hubungannya dengan MessagePack. Artikel tersebut, yang meletakkan CBOR sebagai format data penting, telah menarik keraguan daripada komuniti teknikal.
Dakwaan Promosi CBOR Menimbulkan Keraguan
Beberapa pembangun telah menyatakan kebimbangan bahawa artikel tersebut lebih menyerupai bahan pemasaran berbanding analisis teknikal yang objektif. Pengkritik menunjukkan bahawa walaupun XML dan JSON adalah format yang diiktiraf secara universal, memanggil CBOR sebagai penting nampaknya terlalu awal apabila dibandingkan dengan format binari yang lebih mantap seperti Protocol Buffers, Apache Avro, dan Cap'n Proto. Ramai pembangun mengakui mereka tidak pernah menggunakan CBOR dalam amalan, dengan seorang menyatakan pendedahan mereka hanya semasa pembangunan pasport kod QR era COVID.
Masa dan nada artikel tersebut telah menyebabkan sesetengah pihak mempersoalkan motivasi di sebalik mempromosikan format yang masih agak niche. Walau bagaimanapun, penyokong berhujah bahawa peranan CBOR dalam piawaian baru muncul seperti pengesahan WebAuthn dan FIDO2, di mana ia mengendalikan pertukaran passkey, menunjukkan kepentingannya yang semakin meningkat dalam protokol keselamatan.
Kes Penggunaan dan Penerimaan CBOR
- WebAuthn/FIDO2: Digunakan untuk pertukaran pengesahan passkey
- Protokol CoAP: Alternatif HTTP yang ringan untuk peranti IoT
- COSE: CBOR Object Signing and Encryption untuk keselamatan
- Pengurusan Peranti IoT: Protokol OMA-DM/LWM2M
- Perwakilan Sijil: Sijil X.509 padat C509
- Perkhidmatan AWS: Mula menyokong dalam API yang berat data (2025)
Kelebihan Utama:
- Saiz mesej yang lebih kecil daripada JSON tanpa pemampatan
- Format yang menerangkan diri sendiri (tiada skema diperlukan)
- Boleh dikembangkan melalui tag semantik berdaftar IANA
- Dioptimumkan untuk persekitaran terhad/IoT
Hubungan MessagePack yang Hilang Menandakan Bendera Merah
Kritikan penting tertumpu pada kegagalan artikel untuk mengakui hubungan CBOR dengan MessagePack, format binari terdahulu yang berkongsi matlamat dan prinsip reka bentuk yang serupa. Pengabaian ini telah dilabelkan sebagai bendera merah oleh pembangun berpengalaman yang memahami konteks sejarah. Hubungan antara format-format ini adalah penting untuk memahami kedudukan CBOR dalam ekosistem, kerana mereka menangani masalah serupa dengan pendekatan yang setanding.
Sebenarnya, CBOR adalah MessagePack. Carsten Bormann telah memecahkan MessagePack, mengubah beberapa nilai tag, menulis piawaian di sekelilingnya, dan menyerahkannya kepada IETF bertentangan dengan kehendak pencipta MessagePack.
Konteks sejarah ini mendedahkan bahawa CBOR bukanlah sepenuhnya novel tetapi sebaliknya membina atas kerja sedia ada, menjadikan persembahan artikel berpotensi mengelirukan pembaca yang tidak biasa dengan sejarah format binari.
Perbandingan Pemampatan Ketara Tidak Hadir
Satu lagi isu pertikaian melibatkan kekurangan perbandingan antara CBOR dan JSON yang dimampatkan. Walaupun artikel mempromosikan kelebihan saiz CBOR berbanding JSON biasa, ia tidak menangani bagaimana prestasi CBOR berbanding JSON dengan teknik pemampatan standard seperti gzip atau zstd, yang digunakan secara meluas dan telus kepada pengguna. Pengabaian ini nampaknya sangat penting memandangkan pemampatan biasanya digunakan dalam aplikasi web dan boleh mengecilkan jurang saiz yang didakwa CBOR sebagai kelebihan.
Ketiadaan perbandingan ini telah menyebabkan sesetengah pihak mencadangkan ia sengaja dikecualikan untuk mengekalkan naratif yang menguntungkan untuk CBOR, sama seperti bagaimana produk pesaing mengelak daripada menyerlahkan kekuatan pesaing dalam bahan pemasaran mereka.
Perbandingan CBOR vs JSON vs XML
| Ciri | XML | JSON | CBOR |
|---|---|---|---|
| Jenis Format | Bahasa markup untuk dokumen | Format pertukaran data | Format data binari |
| Boleh Dibaca Manusia | Ya | Ya | Tidak |
| Saiz Mesej | Terbesar (tag bertele-tele) | Sederhana | Terkecil (pengekodan binari) |
| Kelajuan Penghuraian | Perlahan (penghuraian kompleks) | Pantas | Terpantas (penyahkodan binari) |
| Sokongan Pelayar Asli | Ya | Ya | Tidak |
| Sokongan Skema | DTD, XSD | JSON Schema | Tag semantik |
| Komen | Ya | Tidak | Tidak |
| Data Binari | Pengekodan Base64 diperlukan | Pengekodan Base64 diperlukan | Sokongan asli |
Pemeriksaan Realiti Penerimaan Format Binari
Walaupun merit teknikal CBOR, perbincangan mendedahkan realiti yang lebih luas mengenai penerimaan format binari. Ramai pembangun kekal selesa dengan kebolehbacaan manusia JSON dan keupayaan penyahpepijatan, terutamanya apabila digabungkan dengan infrastruktur pemampatan sedia ada. Sifat binari CBOR, walaupun cekap, mengorbankan keupayaan untuk memeriksa dan menyahpepijat pertukaran data dengan mudah, yang kekal berharga dalam banyak senario pembangunan.
Sesetengah pembangun menyokong penciptaan format binari tersuai apabila prestasi adalah kritikal, berhujah bahawa faedah kelajuan pengekodan binari adalah cukup besar untuk mewajarkan usaha pembangunan tambahan. Walau bagaimanapun, yang lain lebih suka penyelesaian piawai seperti CBOR untuk kebolehoperasian dan beban pelaksanaan yang berkurangan.
Kesimpulan
Perdebatan mengenai artikel yang memfokuskan CBOR ini menyerlahkan cabaran mempromosikan format data yang lebih baharu dalam ekosistem di mana JSON telah mencapai penerimaan hampir universal. Walaupun CBOR memainkan peranan penting dalam persekitaran terhad dan protokol keselamatan, kedudukannya sebagai pengganti umum kepada JSON nampaknya terlalu awal. Reaksi komuniti menekankan kepentingan konteks sejarah yang jujur dan perbandingan komprehensif apabila menilai format pertukaran data. Seiring dengan terus berkembangnya Internet of Things, CBOR mungkin menemui nichenya, tetapi menggantikan JSON dalam pembangunan web arus perdana kekal tidak mungkin memandangkan kesederhanaan dan sokongan ekosistem yang terakhir.
Rujukan: From XML to JSON to CBOR