JSON Escape / Batalkan Escape

Cara kerjanya

1. Tempel string Anda: masukkan teks untuk di-escape, bisa berupa teks polos yang berisi tanda kutip, jeda baris, backslash, atau karakter khusus lainnya.
2. Pilih escape atau unescape: pilih apakah Anda ingin meng-escape teks untuk disematkan dalam JSON, atau meng-unescape string JSON menjadi teks yang dapat dibaca.
3. Salin hasilnya: keluaran yang di-escape atau di-unescape muncul seketika. Salin untuk digunakan dalam kode atau data Anda.

Mengapa menggunakan escape JSON?

String JSON memiliki aturan escape yang ketat, tanda kutip ganda harus menjadi \", jeda baris menjadi \n, backslash menjadi \\, dan tab menjadi \t. Tidak meng-escape karakter ini dengan benar menyebabkan kesalahan parsing JSON yang merusak API, file konfigurasi, dan pipeline data. Alat ini menangani semua escape dan unescape secara otomatis, menghilangkan find-replace manual dan menghindari bug halus akibat urutan escape yang terlewat.

Fitur

• Cakupan escape lengkap: menangani tanda kutip, backslash, jeda baris, tab, carriage return, dan urutan escape Unicode.
• Dua arah: baik escape (teks → string JSON) dan unescape (string JSON → teks) dalam satu alat.
• Hasil seketika: keluaran diperbarui saat Anda mengetik, tanpa penundaan.
• Salin ke clipboard: salinan satu klik dari hasil yang di-escape atau di-unescape.
• Privasi yang utama: semua pemrosesan dilakukan secara lokal, string sensitif tidak pernah meninggalkan perangkat Anda.

Pertanyaan umum

Karakter apa yang ditangani escape JSON?

JSON memerlukan escape untuk: tanda kutip ganda ("), backslash (\), garis miring (/), jeda baris (\n), carriage return (\r), tab (\t), form feed (\f), backspace (\b), dan karakter Unicode di atas U+FFFF. Alat ini menangani semuanya.

Mengapa kesalahan parsing JSON saya disebabkan oleh escape?

Penyebab umum termasuk tanda kutip ganda yang tidak di-escape di dalam nilai string, jeda baris literal dalam string (harus \n), dan backslash yang tidak di-escape. Tempel string yang rusak di sini untuk meng-escape-nya dengan benar.

Apakah ini menyertakan tanda kutip pembungkus?

Secara default, alat meng-escape konten tanpa membungkus dengan tanda kutip, sehingga Anda dapat menempel hasilnya ke dalam string JSON Anda. Aktifkan opsi "Sertakan tanda kutip" jika Anda ingin keluaran dikelilingi tanda kutip ganda.

Spesifikasi JSON String, dalam satu tabel

RFC 8259 (Desember 2017, oleh Tim Bray) adalah standar JSON saat ini, menggantikan RFC 7159 dan RFC 4627 asli. Bagian 7 dari spesifikasi mencantumkan dengan tepat karakter mana yang HARUS di-escape di dalam literal string:

Aturan setara ada di ECMA-404 (edisi ke-2, Desember 2017), dijaga sinkron dengan spec IETF. JSON tidak memiliki escape oktal (\012) atau heksadesimal (\x41), itu hanya untuk JavaScript; JSON hanya mendukung delapan escape bernama di atas plus \uXXXX.

Escape \uXXXX dan jebakan pasangan pengganti

Urutan \uXXXX JSON mengkode unit kode UTF-16, bukan code point Unicode. Itu penting untuk emoji dan karakter plane tambahan. Satu emoji seperti 😀 (U+1F600) tidak di-escape sebagai \u1F600 (itu bahkan bukan bentuk hex 4 digit yang legal), tetapi sebagai pasangan pengganti: \uD83D\uDE00, dua escape berturut-turut yang mengkode pengganti tinggi dan rendah. Rentang pengganti tinggi adalah U+D800–U+DBFF; yang rendah adalah U+DC00–U+DFFF; bersama-sama mereka mencakup U+10000 hingga U+10FFFF (plane tambahan).

Ini adalah sumber bug escape emoji yang paling umum. RFC 8259 Bagian 7 secara eksplisit mengatakan: «Untuk meng-escape karakter yang diperluas yang tidak berada di Basic Multilingual Plane, karakter tersebut direpresentasikan sebagai urutan 12 karakter, mengkode pasangan pengganti UTF-16.» Emoji keluarga empat seperti 👨‍👩‍👧‍👦, yang secara teknis adalah empat emoji dasar plus tiga zero-width joiner, di-escape sebagai 30+ karakter dalam string JSON. Jumlah byte membengkak sesuai: 25 byte UTF-8 mentah, ~58 byte setelah escape JSON.

JSON di dalam HTML, URL, SQL, dan CSV

Escape JSON saja tidak cukup ketika JSON disematkan dalam format lain. Setiap konteks menambahkan lapisannya sendiri.

JSON di dalam HTML. Jebakan klasik adalah <script>const data = {{ payload | json }};</script> ketika payload berisi substring literal </script>. Parser HTML menutup tag script di tengah string dan sisa JSON dirender sebagai teks yang terlihat di halaman. Perbaikannya adalah escape opsional \/: <\/script> valid JSON dan aman HTML. Cheat sheet cross-site scripting OWASP merekomendasikan selalu meng-escape <, >, &, dan ' dalam JSON yang dimaksudkan untuk embedding HTML.

JSON di dalam string query URL. Dua lapisan: pertama escape JSON, lalu percent-encoding. {"name":"Bob"} menjadi %7B%22name%22%3A%22Bob%22%7D. Melupakan percent-encoding adalah penyebab nomor 1 bug JSON-in-URL yang salah bentuk.

JSON di dalam SQL. Disimpan dalam kolom PostgreSQL jsonb nilai diparsing secara native, tidak perlu escape lebih lanjut. Tetapi JSON yang disematkan dalam literal string SQL (INSERT INTO t (data) VALUES ('{"key":"value"}')) membutuhkan escape string SQL di atas JSON: tanda kutip tunggal digandakan (''), atau lebih baik, gunakan query terparameter.

JSON di dalam sel CSV. Kutipan CSV berbeda dari JSON (CSV menggunakan kutipan digandakan "", bukan urutan backslash). Menyematkan JSON di sel CSV membutuhkan kedua lapisan: escape JSON string, lalu escape CSV hasilnya (bungkus dalam "...", gandakan setiap " internal).

API Runtime di seluruh bahasa

Dari mana JSON berasal, dan apa yang Crockford tinggalkan

JSON pertama kali diformalkan oleh Douglas Crockford pada tahun 2001 di State Software, awalnya untuk menserialkan objek JavaScript untuk pertukaran data asinkron. Penyebutan publik pertama ada di situs JSON.org pada tahun 2003. Crockford menentukannya secara formal sebagai RFC 4627 pada Juli 2006, sebagian untuk melawan upaya paten yang bersaing sekitar waktu yang sama. Standar pindah ke status STD 90 dengan RFC 8259 pada Desember 2017.

Keputusan desain terbesar JSON adalah menjadikannya subset dari JavaScript, sehingga dokumen JSON apa pun dapat di-eval'd di interpreter JS dan menghasilkan nilai yang benar. Ini membuat adopsi browser tanpa hambatan tetapi mengunci beberapa keanehan JS secara permanen: tidak ada tipe integer (semua angka adalah IEEE 754 double), tidak ada tipe tanggal, tidak ada NaN atau Infinity. Integer besar di atas 2⁵³−1 perlu serialisasi string ("id": "9007199254740993") untuk menghindari kehilangan presisi yang hening.

Crockford dengan sengaja meninggalkan hal-hal yang mungkin Anda rindukan: komentar («Saya menghapus komentar dari JSON karena saya melihat orang menggunakannya untuk menyimpan direktif parsing, praktik yang akan menghancurkan interoperabilitas», Mei 2012), koma akhir, dan bahasa skema (ditambahkan kemudian sebagai JSON Schema, dipertahankan terpisah, draf saat ini 2020-12). Varian komunitas JSON5 memulihkan komentar dan koma akhir tetapi tidak sesuai RFC; digunakan terutama dalam file konfigurasi (.babelrc, .swcrc) yang diedit oleh manusia.

Kasus penggunaan umum

• Menyematkan data dalam atribut HTML, tempelkan string dengan ", <, >, dapatkan bentuk aman untuk atribut data-* atau tag script inline.
• Menyusun body permintaan API secara manual, saat melakukan curl ke endpoint dan payload berisi kutipan atau baris baru.
• Membangun payload baris log di mana pesan harus bertahan dari kutipan shell plus parsing JSON di sisi lain.
• Memigrasi data lama dari CSV / XML / TSV ke JSON, lewatan escape kutipan manual.
• Debugging respons server di mana nilai berisi urutan \u, unescape untuk melihat sebenarnya apa.
• Menulis tes, tempelkan output JSON yang diharapkan dan escape untuk disertakan dalam asersi tes.
• Mesin templating (Jinja2, Nunjucks, Liquid, ERB) yang menyematkan JSON dalam JavaScript atau HTML.

Kesalahan umum

1. Menggunakan escape JavaScript yang tidak valid JSON. \x41 untuk «A» dan \012 untuk baris baru valid dalam literal string JS tetapi tidak valid dalam JSON. JSON hanya mengizinkan delapan escape bernama plus \uXXXX.
2. Menggunakan tanda kutip tunggal untuk string JSON. 'hello' bekerja di JavaScript tetapi JSON tidak valid. String JSON HARUS menggunakan tanda kutip ganda.
3. Kunci objek tanpa kutipan. {name: "Bob"} bekerja di JavaScript tetapi JSON tidak valid. Kunci HARUS literal string dalam tanda kutip ganda.
4. Koma akhir. [1,2,3,] bekerja di JS tetapi JSON tidak valid. RFC 8259 secara eksplisit melarangnya.
5. Komentar inline. // foo dan /* foo */ tidak valid dalam JSON standar. Gunakan JSON5 jika Anda memerlukan komentar; harapkan bahwa tidak setiap parser akan menerimanya.
6. Meng-escape emoji secara manual sebagai satu \uXXXX. Emoji di atas U+FFFF membutuhkan pasangan pengganti UTF-16, dua \uXXXX berurutan.

Lebih banyak pertanyaan yang sering diajukan

Haruskah saya selalu meng-escape garis miring /?

Tidak, garis miring / diizinkan tanpa escape dalam JSON; escape \/ opsional. Pengecualian adalah ketika JSON disematkan di dalam tag HTML <script>: meng-escape / sebagai \/ mencegah substring literal </script> menutup tag sebelum waktunya. Beberapa encoder (JSON_HEX_TAG di PHP, penggantian JS kustom) melakukan ini; sebagian besar tidak.

Mengapa JSON.stringify meng-escape karakter non-ASCII saya?

Tidak, secara default. JSON.stringify("café") di JavaScript menghasilkan "café" dengan é literal. Yang mungkin Anda lihat adalah pustaka berbeda: json.dumps Python default ke ensure_ascii=True dan meng-escape semua di luar ASCII sebagai \uXXXX; json_encode PHP berperilaku serupa kecuali Anda lewatkan JSON_UNESCAPED_UNICODE. Kedua perilaku adalah JSON valid, tetapi ukuran file dan keterbacaan berbeda.

Bisakah JSON menyimpan data biner?

Tidak secara langsung. String JSON adalah urutan karakter Unicode, bukan byte. Cara penyelesaian standar adalah pertama meng-encode Base64 biner, lalu menyimpan string ASCII yang dihasilkan sebagai nilai JSON normal. Data yang dikodekan ~33% lebih besar dari byte mentah. Untuk biner yang sangat besar, gunakan format biner seperti BSON, MessagePack, atau CBOR, atau simpan byte secara terpisah dan referensikan melalui URL.

Mengapa beberapa alat menampilkan \u00e9 alih-alih é?

Keduanya adalah JSON valid untuk karakter yang sama. "caf\u00e9" dan "café" didekode ke string yang identik. Beberapa encoder meng-escape non-ASCII untuk keamanan cross-encoding maksimum (output adalah ASCII murni sehingga encoding konsumen tidak masalah), lainnya mempertahankan UTF-8 asli untuk keterbacaan. Pilih berdasarkan apa yang mengkonsumsi JSON Anda.

Apakah teks saya diunggah ke mana pun?

Tidak. Alat menggunakan API native JSON.stringify dan JSON.parse browser sepenuhnya di sisi klien. Tidak ada panggilan jaringan, tidak ada analitik, tidak ada logging. Aman untuk meng-escape token API, data internal, atau apa pun yang tidak akan Anda tempel ke alat escape sisi server.