Byte Penghitung

Cara Kerjanya

1. Masukkan atau tempel teks: Ketik atau tempel teks apa pun ke dalam kolom input.
2. Lihat jumlah byte: Alat ini langsung menampilkan jumlah byte dalam UTF-8, UTF-16, ASCII, dan penyandian lainnya secara berdampingan.
3. Periksa batas: Bandingkan jumlah byte dengan batas umum (SMS: 160 karakter, header HTTP: 8 KB, kolom database, dll.) untuk melihat apakah konten Anda sesuai.

Mengapa Menggunakan Penghitung Byte?

Jumlah karakter dan jumlah byte tidak sama. Satu emoji bisa berukuran 4 byte dalam UTF-8. Karakter Tionghoa dan Arab memakan 2-3 byte masing-masing. Banyak sistem menerapkan batas byte, bukan batas karakter, termasuk kolom VARCHAR MySQL, nilai Redis, header HTTP, pesan SMS, dan nama objek penyimpanan cloud. Penghitung Byte mengungkapkan ukuran byte sebenarnya dari teks Anda di setiap penyandian sehingga Anda dapat tetap dalam batasan sistem.

Fitur

• Beberapa ukuran penyandian: Menampilkan jumlah byte untuk UTF-8, UTF-16 LE/BE, UTF-32, dan Latin-1.
• Rincian karakter: Menghitung total karakter, titik kode Unicode, dan karakter multi-byte secara terpisah.
• Prasetel batas umum: Bandingkan dengan SMS (160), tweet (280), meta description (160), batas VARCHAR MySQL, dan lainnya.
• Pembaruan langsung: Jumlah byte diperbarui secara real-time saat Anda mengetik.
• Perbandingan penyandian: Lihat penyandian mana yang paling kompak untuk teks spesifik Anda.

Pertanyaan yang Sering Diajukan

Mengapa jumlah byte saya lebih besar dari jumlah karakter saya?

Banyak karakter memakan lebih dari 1 byte dalam UTF-8. Karakter ASCII (A-Z, 0-9, tanda baca) adalah 1 byte masing-masing. Karakter Latin-extended (huruf beraksen) adalah 2 byte. Karakter Tionghoa, Jepang, Korea, dan Arab biasanya 3 byte. Emoji biasanya 4 byte.

Penyandian apa yang digunakan sebagian besar sistem web?

UTF-8 adalah penyandian dominan untuk konten web, APIs, JSON, dan database. MySQL dan PostgreSQL menggunakan UTF-8 secara default. Saat memeriksa batas byte, gunakan kolom UTF-8 kecuali sistem Anda menentukan lain.

Mengapa pesan SMS memiliki batas 160 karakter?

SMS tradisional menggunakan penyandian GSM 7-bit, yang memungkinkan 160 karakter per segmen. Saat Anda menyertakan karakter non-GSM apa pun (seperti kutipan cerdas, emoji, atau huruf non-Latin), pesan beralih ke penyandian UCS-2, yang menurunkan batas menjadi 70 karakter per segmen.

Apa itu byte, sebenarnya?

Satu byte adalah 8 bit, yang dapat menampung 256 nilai berbeda. Dalam teks, 256 nilai itu dipetakan ke karakter melalui pengkodean, sebuah buku aturan yang mengatakan «urutan byte ini setara dengan karakter ini». Untaian byte yang sama dapat berarti teks yang sangat berbeda di bawah pengkodean yang berbeda: byte 0xE9 adalah «é» dalam Latin-1, awal urutan 3-byte dalam UTF-8, atau bagian dari unit kode UTF-16. Pengkodean adalah seluruh ceritanya.

Ketika Anda menyimpan teks ke disk, mengirimnya melalui jaringan, atau menyimpannya di basis data, yang sebenarnya disimpan adalah byte, bukan karakter. Jumlah karakter yang Anda lihat di editor teks dihitung pada waktu tampil, setelah byte didekode. Salah pengkodean di salah satu sisi dan Anda mendapatkan mojibake: teks yang didekode dengan pengkodean yang salah muncul sebagai omong kosong (klasik é alih-alih é ketika byte Windows-1252 dibaca sebagai UTF-8).

Penghitungan byte adalah apa yang diukur oleh batas kolom basis data, buffer header HTTP, payload SMS, dan kunci objek penyimpanan cloud, terlepas dari bagaimana teks «terlihat». Penghitung ini melaporkan ukuran byte dalam empat pengkodean yang paling mungkin Anda pedulikan: UTF-8 (default modern), UTF-16 (format internal Windows / Java / JavaScript), ASCII (hanya valid untuk teks Latin Inggris), dan Latin-1 (cadangan warisan satu-byte). Jumlah karakter di samping diberikan sebagai referensi.

UTF-8: ceritanya

UTF-8 disketsa oleh Ken Thompson dan Rob Pike di Bell Labs pada malam 2 September 1992, dilaporkan di atas placemat di sebuah diner di New Jersey, setelah tim Plan 9 membutuhkan pengkodean panjang-variabel yang kompatibel dengan ASCII untuk Unicode. Desain membawa tiga properti yang hampir tidak ada lainnya yang dimilikinya sekaligus: teks ASCII juga UTF-8 yang valid (1 byte per karakter, byte identik), pengkodean adalah self-sinkronisasi (bit tinggi dari byte mana pun memberi tahu Anda apakah ia memulai karakter baru atau melanjutkan yang sudah ada), dan tidak ada ambiguitas urutan byte. Tiga properti itu bersama-sama menjelaskan mengapa UTF-8 menggusur setiap pengkodean pesaing di web.

Ini pertama kali distandarisasi sebagai RFC 2044 pada Oktober 1996, direvisi sebagai RFC 2279 pada Januari 1998, dan digantikan oleh RFC 3629 (November 2003) saat ini, yang membatasi UTF-8 menjadi 4 byte per karakter agar sesuai dengan plafon titik kode akhir Unicode di U+10FFFF. W3Techs telah melacak penggunaan pengkodean di web publik secara terus-menerus sejak 2010; UTF-8 naik dari 56% situs web pada 2011 menjadi sekitar 98% pada 2026. Spesifikasi HTML5 mewajibkan UTF-8 untuk konten baru; HTTP/2 dan HTTP/3 mengirim header dalam UTF-8 melalui HPACK / QPACK; RFC 8259 mewajibkan UTF-8 untuk pertukaran JSON antar sistem. Jika Anda harus memilih satu pengkodean untuk semuanya, jawaban selama 15 tahun terakhir adalah UTF-8 dan jawabannya untuk 15 tahun ke depan akan sama.

UTF-8 adalah panjang-variabel, 1 hingga 4 byte per karakter:

Konsekuensi praktis: teks Inggris dalam UTF-8 rata-rata ~1 byte per karakter; Cina ~3 byte; pesan yang banyak emoji dapat mencapai 4 byte per karakter terlihat, dan emoji gabungan (urutan ZWJ keluarga) dengan mudah mencapai 20-30 byte untuk yang terlihat seperti satu karakter.

UTF-16 dan jebakan surrogate

UTF-16 adalah pengkodean pilihan untuk Windows NT (1993), Java 1.0 (1996), JavaScript (1995), .NET, dan Mac OS X Cocoa NSString. Ini menggunakan 2 byte untuk setiap karakter dalam Basic Multilingual Plane (U+0000 – U+FFFF), dan pasangan surrogate untuk apa pun di luarnya: surrogate tinggi (D800–DBFF) ditambah surrogate rendah (DC00–DFFF), total 4 byte. UTF-16 memerlukan tanda urutan byte (BOM) di disk untuk membedakan big-endian (UTF-16BE, FE FF) dari little-endian (UTF-16LE, FF FE); Windows default ke little-endian.

Jebakan: dalam JavaScript, "😀".length === 2. MDN menyatakannya langsung: properti length «berisi panjang string dalam unit kode UTF-16». Itulah mengapa satu emoji seperti 😄 melaporkan panjang 2 (ia berada di plane tambahan dan membutuhkan pasangan surrogate), dan urutan ZWJ keluarga 👨‍👩‍👧‍👦 melaporkan panjang 11 (empat emoji 2-unit-kode ditambah tiga zero-width joiner). Emoji keluarga satu-karakter yang sama dihitung sebagai 11 dalam JavaScript, 5 dalam Python 3, dan 1 dalam Swift, tergantung pada model string setiap bahasa. Untuk hitungan karakter terlihat yang benar dalam JavaScript, gunakan Intl.Segmenter dengan granularitas grapheme (setiap browser evergreen sejak 2021).

ASCII, Latin-1, dan kekacauan pra-Unicode

ASCII (American Standard Code for Information Interchange) distandarisasi sebagai ASA X3.4-1963, direvisi sebagai X3.4-1968 dan lagi sebagai ANSI X3.4-1986. Sebuah kode 7-bit, 128 karakter: 95 dapat dicetak plus 33 kontrol. 33 karakter kontrol termasuk warisan teletype seperti BEL, BS, CR, LF, DEL, dan beberapa yang bertahan dalam protokol modern (NUL, TAB, LF, CR, ESC). ASCII masih bekerja sebagai subset ketat dari UTF-8, itulah mengapa «teks ASCII murni» juga UTF-8 yang valid dan mengapa migrasi ke UTF-8 tidak menyakitkan untuk sistem hanya-Inggris.

Latin-1 / ISO-8859-1 (1987) adalah ekstensi 256-karakter satu-byte yang menambahkan huruf beraksen Eropa Barat, simbol mata uang, dan tanda baca umum. Ini adalah pengkodean de-facto untuk konten web Barat dari 1995 hingga UTF-8 menggusurnya sekitar 2008. Windows-1252 adalah superset Microsoft dari Latin-1, menambahkan «smart quotes», em-dashes, dan simbol euro dalam rentang kontrol C1 (0x80-0x9F); ketika file CSV dikirim melalui email antara Mac dan Windows, ini adalah sumber mojibake klasik é ketika satu sisi membaca byte Windows-1252 sebagai UTF-8.

Jebakan «utf8» MySQL

MySQL memiliki cacat set-karakter yang terkenal sejak versi 4.1: alias set-karakter utf8 sebenarnya bukan UTF-8. Ini adalah subset maksimum 3-byte yang tidak dapat merepresentasikan karakter di atas U+FFFF, yang berarti ia tidak dapat menyimpan emoji atau karakter plane tambahan. Menyisipkan «🎉» ke dalam kolom utf8 menghasilkan «?» atau kesalahan tergantung pada sql_mode. Perbaikannya adalah utf8mb4, ditambahkan dalam MySQL 5.5.3 (Maret 2010); MySQL 8.0 (April 2018) menjadikan utf8mb4 default baru. Tapi skema yang dibuat sebelum 8.0 sering masih menggunakan versi 3-byte secara default. Jika Anda melihat emoji menghilang diam-diam dari input pengguna, ini hampir selalu penyebabnya. PostgreSQL tidak memiliki jebakan setara, ia menerima UTF-8 yang sebenarnya secara native.

SMS, GSM-7, dan payload 160 byte

Batas 160-karakter SMS berasal dari perhitungan oleh Friedhelm Hillebrand pada 1985, seorang insinyur di Kelompok Kerja GSM yang dilaporkan duduk di mesin tiknya, mengetik kalimat acak, dan menghitung bahwa «sebagian besar pesan dapat diekspresikan dalam 160 karakter atau kurang». 160 kemudian diturunkan ke belakang untuk muat dalam payload 140 byte menggunakan alfabet 7-bit (140 × 8 ÷ 7 = 160). Detail pengkodean diformalkan dalam 3GPP TS 23.038 (awalnya GSM 03.38), dan masih mengatur penagihan SMS hari ini.

Dalam byte: satu SMS adalah 140 byte di kawat. Dengan GSM-7 itu 160 karakter; dengan UCS-2 (pengkodean lebar tetap 2-byte yang digunakan untuk apa pun di luar alfabet GSM-7) itu 70. Pesan multi-bagian kehilangan 7 karakter GSM-7 atau 3 karakter UCS-2 per segmen untuk User Data Header yang digunakan untuk perakitan ulang, jadi pesan panjang dibatasi pada 153 karakter GSM-7 per segmen atau 67 karakter UCS-2 per segmen. Satu smart quote, em-dash, atau emoji menurunkan seluruh pesan ke UCS-2 dan memotong setengah batas per-segmen. «Smart Encoding» Twilio secara otomatis mengganti kutipan keriting dengan yang lurus untuk menjaga kampanye pemasaran dalam pengkodean yang lebih murah.

Di mana batas byte benar-benar menggigit

Tiga kategori di mana batas byte (bukan karakter) akan menangkap Anda:

Header permintaan HTTP. Tidak ada maksimum spesifikasi formal, setiap server memberlakukan satu. LimitRequestFieldSize Apache default 8 KB per header; large_client_header_buffers Nginx default 4 × 8 KB; IIS default 16 KB; AWS Application Load Balancer menerima 16 KB per header dan 60 KB total; Cloudflare mengizinkan 32 KB. JWT dengan set klaim yang membengkak rutin melebihi default 8 KB Apache, yang merupakan mode kegagalan produksi paling umum untuk autentikasi berbasis token.

Kunci penyimpanan objek cloud. S3 dan GCS keduanya membatasi kunci objek pada 1024 byte UTF-8. Azure Blob Storage membatasi nama blob pada 1024 karakter (UTF-16 internal). Untuk S3, nama file yang banyak CJK (3 byte per karakter) mencapai puncak pada ~341 karakter; yang banyak emoji (4 byte per karakter) pada ~256, jauh sebelum yang diharapkan pengembang.

Batas baris dan indeks basis data. MySQL InnoDB memiliki ukuran baris 65.535 byte dan batas prefiks kunci indeks 3072 byte pada format baris DYNAMIC (767 pada COMPACT yang lebih lama). Kolom VARCHAR(255) utf8mb4 membutuhkan 1020 byte (255 × 4) ruang indeks, oke pada DYNAMIC, rusak pada COMPACT. Dokumen BSON MongoDB dibatasi 16 MB. Item DynamoDB dibatasi 400 KB (termasuk nama atribut). Nilai Redis dibatasi 512 MB.

Kasus penggunaan umum

• Validasi bidang basis data, konfirmasikan bahwa nama yang dikirim pengguna akan cocok sebelum INSERT, terutama ketika kolomnya VARCHAR(255) utf8mb4 dan inputnya CJK.
• Copy pemasaran SMS, konfirmasikan bahwa pesan tetap di GSM-7 (~1 byte per karakter terlihat dalam payload) alih-alih jatuh secara tidak sengaja ke UCS-2 karena kutipan keriting.
• Penganggaran payload API, konfirmasikan bahwa body JSON cocok di bawah batas yang diketahui (DynamoDB 400 KB, payload AWS Lambda 6 MB sinkron, 256 KB asinkron).
• Kunci objek cloud, konfirmasikan bahwa kunci S3 / GCS tetap di bawah 1024 byte setelah transkripsi non-ASCII.
• Pengungkapan emoji, lihat persis berapa banyak «bobot» yang ditambahkan emoji atau urutan ZWJ keluarga ke sebuah string.
• Pemilihan pengkodean, bandingkan ukuran byte UTF-8 vs UTF-16; untuk konten yang didominasi CJK, UTF-16 mungkin lebih kompak (2 byte per karakter CJK vs 3 dalam UTF-8).

Kesalahan umum

1. Mempercayai .length JavaScript untuk ukuran byte. .length mengembalikan unit kode UTF-16, bukan byte dan bukan karakter. Untuk byte UTF-8, gunakan new TextEncoder().encode(text).length; untuk karakter terlihat, gunakan Intl.Segmenter.
2. Mengasumsikan MySQL utf8 sebenarnya UTF-8. Ini adalah subset 3-byte yang diam-diam menjatuhkan emoji. Selalu gunakan utf8mb4 (dan utf8mb4_unicode_ci untuk kolasinya) pada kolom apa pun yang menyentuh teks yang dikirim pengguna.
3. Mengasumsikan satu emoji sama dengan satu byte. Satu emoji adalah 4 byte dalam UTF-8, 4 byte dalam UTF-16 (pasangan surrogate). Urutan ZWJ keluarga dapat melebihi 30 byte untuk yang terlihat seperti satu karakter.
4. Menghitung BOM UTF-8 sebagai konten. BOM UTF-8 tiga-byte EF BB BF di awal file adalah metadata, bukan teks. Sebagian besar alat CLI (awk, head, sed) memperlakukannya sebagai bagian dari field pertama, yang merupakan sumber dari banyak bug «mengapa nama kolom pertama saya memiliki karakter aneh».
5. Melaporkan hitungan «byte ASCII» untuk teks non-ASCII. ASCII tidak dapat merepresentasikan karakter di atas U+007F. Penghitung ini memperingatkan ketika input mengandung non-ASCII sehingga Anda tahu kolom ASCII tidak bermakna.

Pertanyaan yang sering diajukan lainnya

Mengapa satu emoji 4 byte ketika karakter teks hanya 1?

UTF-8 menggunakan 1 byte untuk ASCII (U+0000 hingga U+007F), 2 byte untuk Latin diperluas / Yunani / Sirilik / Arab / Ibrani (U+0080 hingga U+07FF), 3 byte untuk sebagian besar aksara CJK dan India (U+0800 hingga U+FFFF), dan 4 byte untuk emoji dan karakter plane tambahan (U+10000 hingga U+10FFFF). Emoji tipikal seperti 😀 (U+1F600) berada di plane tambahan dan biayanya 4 byte. Emoji gabungan (misalnya keluarga 👨‍👩‍👧‍👦) dibangun dari beberapa emoji dasar yang direkatkan bersama dengan zero-width joiner; setiap emoji dasar adalah 4 byte, setiap joiner adalah 3 byte, jadi keluarga 4 mengambil 4×4 + 3×3 = 25 byte untuk yang terlihat seperti satu karakter.

Apa sebenarnya arti MySQL utf8?

Di MySQL, alias set-karakter utf8 adalah subset maksimum 3-byte dari UTF-8 sebenarnya. Ia dapat mengkodekan setiap karakter dalam Basic Multilingual Plane Unicode tetapi tidak dapat menyimpan emoji atau karakter apa pun di atas U+FFFF. UTF-8 4-byte sebenarnya di MySQL adalah utf8mb4, tersedia sejak MySQL 5.5.3 (Maret 2010), default sejak MySQL 8.0 (April 2018). Jika Anda dapat mengubah skema, selalu gunakan utf8mb4 dengan kolasi utf8mb4_0900_ai_ci (atau utf8mb4_unicode_ci di server yang lebih lama).

Apakah penghitung ini termasuk tanda urutan byte UTF-8?

Tidak. Tanda urutan byte UTF-8 adalah tiga byte EF BB BF yang dibutuhkan Excel di Windows di awal file untuk mendeteksi UTF-8. Penghitung mengukur byte teks yang Anda tempel; jika teks Anda kebetulan dimulai dengan BOM, ketiga byte itu dihitung sebagai konten. Jika Anda ingin tahu apakah byte file Anda akan mencapai batas, tempelkan saja body file, bukan BOM.

Mengapa teks Cina saya menunjukkan 3 byte per karakter dalam UTF-8?

Hampir semua ideogram CJK berada dalam rentang Unicode U+4E00 hingga U+9FFF (blok CJK Unified Ideographs), yang dikode UTF-8 sebagai masing-masing 3 byte. Kalimat Cina 100-karakter karenanya 300 byte UTF-8. Dalam UTF-16 teks yang sama adalah 200 byte (2 byte per karakter), jadi UTF-16 lebih kompak untuk konten yang didominasi CJK. UTF-8 menang untuk konten campuran Latin-dan-CJK karena karakter Latin biayanya 1 byte masing-masing alih-alih 2.

Apakah teks saya diunggah ke mana pun?

Tidak. Penghitung byte berjalan sepenuhnya di browser Anda. Hitungan byte UTF-8 berasal dari API standar TextEncoder (setiap browser modern mendukungnya), hitungan UTF-16 dan Latin-1 berasal dari loop sederhana. Tidak ada permintaan jaringan, tidak ada panggilan server, tidak ada pencatatan. Setelah halaman dimuat, alat berfungsi offline. Aman untuk memeriksa token API, data internal, atau apa pun yang tidak akan Anda tempel ke penghitung teks pihak ketiga.