Konverter Teks ke Hex UTF-8

é adalah C3 A9: berapa byte yang dipakai sebuah karakter di UTF-8

Konversi heksadesimal UTF-8 mengubah karakter menjadi byte UTF-8 yang benar-benar disimpan komputer, lalu menulis tiap byte sebagai dua digit heksadesimal 00 sampai FF. Huruf é pada kata café punya titik kode (nomor karakter di Unicode) U+00E9 dan di UTF-8 menjadi dua byte, C3 A9. Huruf A hanya satu byte, 41, sedangkan emoji 😀 empat byte, F0 9F 98 80. Sebaliknya, jika Anda memasukkan C3 A9 yang Anda terima dari log atau program, hasilnya kembali menjadi é.

Konverter di atas bisa diedit dari kolom teks maupun kolom heksadesimal. Sisi yang terakhir Anda ubah menjadi acuan, dan jalur di tengah menempelkan byte setiap karakter di bawah karakternya seperti teks terjemahan film. Warna di bawah kotak byte menunjukkan 1, 2, 3, atau 4 byte, dan jika Anda menekan sebuah karakter, kaca pembesar bit menggambar posisi bit titik kodenya di dalam byte UTF-8. Heksadesimal bisa ditulis dengan spasi, disambung, larik 0x, escape \x, atau percent-encoding, dan saat menempel, kelima bentuk itu semuanya dibaca.

Saat Anda perlu melihat byte UTF-8 secara langsung

• Teks tampil rusak seperti café atau “: Teks UTF-8 yang dibaca sebagai Windows-1252 menghasilkan pola khas, misalnya é menjadi é. Masukkan byte aslinya ke kolom heksadesimal, dan konverter menunjukkan apakah byte itu terbaca sebagai UTF-8 dan, jika tidak, apa isinya bila dibaca sebagai Windows-1252.
• Log menampilkan nilai seperti caf\xc3\xa9: Python menulis byte non-ASCII dalam bentuk escape \x ketika menampilkan nilai bytes, misalnya b'caf\xc3\xa9'. Tempel nilai itu apa adanya ke kolom heksadesimal. Pembungkus b'…' dan huruf yang ditulis langsung seperti caf ikut dibaca, sehingga teks aslinya kembali.
• Penyimpanan ke basis data gagal karena jumlah byte: utf8mb3 di MySQL (dulu bernama utf8) hanya memuat maksimal 3 byte per karakter, sehingga emoji 4 byte tidak bisa disimpan. Pesan galat 1366 menulis nilai bermasalahnya sebagai byte, seperti Incorrect string value: '\xF0\x9F\x98\x80'. Jika bagian ini dimasukkan ke konverter, langsung terlihat bahwa 😀 adalah satu karakter 4 byte.
• Dua teks tampak sama, tetapi perbandingan atau pencarian meleset: Spasi tanpa pemisah baris (C2 A0), spasi tanpa lebar (E2 80 8B), dan BOM di awal berkas (EF BB BF) tidak terlihat di layar, tetapi byte-nya berbeda. Di jalur, semuanya diberi label seperti NBSP, ZWSP, dan BOM.
• Nama berkas dengan aksen terpisah: Volume HFS Plus (Mac OS Extended) di Mac menyimpan nama berkas dalam varian NFD, yaitu huruf dasar dan tanda aksen terpisah. Karena itu café.txt dengan é yang terpisah (e + U+0301) berukuran 10 byte, bukan 9 byte. Konverter juga memberi tahu berapa byte hasilnya jika digabung ke NFC.
• Membaca %C3%A9 di dalam alamat: Karakter non-ASCII di URL lebih dulu diubah ke UTF-8, lalu setiap byte ditulis sebagai % dan dua digit heksadesimal. Jika Anda menyalin %63%61%66%C3%A9 dari bilah alamat, hasilnya adalah café.
• Memasukkan string ke dalam larik byte pada kode: Perangkat tertanam dan spesifikasi komunikasi sering membutuhkan larik seperti 0xC3, 0xA9. Pilih format larik 0x, dan hasilnya ditulis dalam bentuk yang siap ditempel.

Cara memakai

1. Ketik teks di kolom teks atau tempel byte di kolom heksadesimal. Tampilan awal sudah berisi contoh teks, emoji, dan café. Tombol 'Contoh' di atas bisa memasukkan karakter tersembunyi, aksen terpisah (NFD), byte \x dari log, dan byte rusak.
2. Panah di tengah menunjukkan arah konversi. Mengubah kolom teks berarti ke bawah (enkode), dan mengubah kolom heksadesimal berarti ke atas (dekode).
3. Pilih format heksadesimal dan huruf kapital atau kecil. Jika Anda mengganti format saat heksadesimal sudah terisi, byte yang sama ditulis ulang dalam format baru.
4. Tekan sebuah karakter di jalur, atau geser kursor di kolom, dan kaca pembesar bit menampilkan titik kode, byte UTF-8, UTF-16, dan Windows-1252 karakter itu beserta posisi bytenya.
5. Ambil hasilnya dengan 'Salin heksadesimal' atau 'Salin teks'. Di kanan bawah, jumlah byte teks yang sama jika disimpan sebagai UTF-16 dan Windows-1252 dibandingkan.

Aturan UTF-8 membagi karakter menjadi byte

UTF-8 menulis karakter pada rentang Unicode U+0000 sampai 10FFFF dengan 1 sampai 4 byte (RFC 3629). Bit-bit awal byte pertama menunjukkan panjang karakter, dan semua byte lanjutan diawali 10. Dengan begitu, satu byte saja sudah cukup untuk mengetahui apakah ia awal atau bagian tengah sebuah karakter.

Mari membagi € sendiri. U+20AC dalam biner adalah 0010 0000 1010 1100, total 16 bit. Kerangka 3 byte punya tempat 4 + 6 + 6 bit, sehingga bitnya dibagi menjadi 0010 / 000010 / 101100 dan dimasukkan ke 11100010, 10000010, 10101100. Ketiga byte ini dalam heksadesimal adalah E2, 82, AC. U+0000 sampai 007F tetap satu byte, jadi teks yang hanya berisi huruf, angka, dan tanda baca dasar memiliki byte yang persis sama dengan ASCII.

Karena itu, kata seperti 'selamat' memakai 7 byte di UTF-8, sedangkan satu huruf beraksen seperti é memakai 2 byte. Simbol seperti © (2 byte) dan € (3 byte) juga lebih panjang dari huruf biasa, dan emoji di luar BMP selalu 4 byte.

Byte UTF-8, UTF-16, dan Windows-1252 per karakter

Perhatikan €, –, “, dan ”: byte Windows-1252-nya adalah 80, 96, 93, dan 94, yaitu byte di rentang 80 sampai 9F. Di tabel windows-1252 yang dipakai peramban, rentang itu berisi tanda baca dan simbol seperti ini. Menurut WHATWG Encoding, label latin1 dan iso-8859-1 pun dipetakan ke windows-1252. Di UTF-8, byte tunggal 80 atau 96 tidak sah, sehingga teks Windows-1252 yang memuat tanda ini mudah terdeteksi saat dibaca sebagai UTF-8.

Teks yang sama, jumlah byte berbeda menurut enkoding

Windows-1252 selalu satu byte per karakter, tetapi hanya memuat karakter di tabelnya. Teks Latin dengan sedikit aksen dan simbol lebih pendek di sana, sementara 日 atau 😀 tidak bisa disimpan sama sekali. Karena web harus memuat banyak bahasa dan emoji, UTF-8 yang dipakai. Perhatikan juga dua baris café.txt: bentuk NFC (é satu titik kode) 8 karakter dan 9 byte di UTF-8, sedangkan bentuk NFD (e + U+0301) berukuran 10 byte dengan 9 titik kode, padahal tampilannya sama. Emoji keluarga tampak sebagai satu karakter, tetapi sebenarnya tiga emoji orang (4 byte × 3) yang disambung dua ZWJ (3 byte × 2), sehingga totalnya 18 byte.

Lima cara menulis heksadesimal

Saat menempel, Anda tidak perlu memilih format. Spasi, tab, baris baru, koma, titik dua, dan tanda hubung dibaca sebagai pemisah, sehingga 63-61-66-C3-A9 dari BitConverter.ToString di .NET juga langsung masuk. Pada format \x dan %, huruf dan angka yang ditulis apa adanya di antaranya ikut dibaca sebagai byte, dan pembungkus b'…', "…", serta […] dilepas. RFC 3986 menyarankan huruf kapital pada percent-encoding, tetapi huruf kapital dan kecil adalah byte yang sama.

// JavaScript: teks → heksadesimal UTF-8
[...new TextEncoder().encode('café')].map(b => b.toString(16).padStart(2, '0')).join(' ');  // '63 61 66 c3 a9'

# Python 3.8 ke atas: teks ↔ heksadesimal
'café'.encode('utf-8').hex(' ')                  # '63 61 66 c3 a9'
bytes.fromhex('63 61 66 C3 A9').decode('utf-8')  # 'café' (spasi diabaikan)

Byte yang tidak bisa dibaca sebagai UTF-8

Tidak semua urutan byte adalah UTF-8. Byte lanjutan yang muncul tanpa byte awal, karakter yang terputus di tengah, atau karakter pendek yang sengaja ditulis panjang semuanya tidak sah. RFC 3629 melarang penulisan wilayah surogat (U+D800 sampai DFFF) di UTF-8 dan memperingatkan bahwa dekoder tidak boleh menerima bentuk panjang (overlong) seperti C0 80. Peramban memasukkan satu karakter pengganti � (U+FFFD) untuk setiap bagian yang tidak sah, dan konverter ini memotongnya dengan aturan yang sama, lalu menampilkan byte yang salah beserta alasannya di jalur.

Karakter yang terputus, seperti dua baris terakhir, diganti satu � untuk seluruh byte benar yang sudah masuk. Unicode menyebutnya penggantian 'maximal subpart', dan jika byte yang sama dimasukkan, jumlah � di peramban dan di konverter ini sama. Saat Anda masih mengetik di kolom heksadesimal, karakter terakhir yang belum lengkap tidak dianggap galat, melainkan konverter memberi tahu berapa byte yang masih kurang. Setelah Anda keluar dari kolom, barulah dinilai sebagai galat.

Menebak enkoding asli dari teks yang rusak

Penyebab teks rusak yang paling umum adalah byte yang disimpan dengan satu enkoding dibaca dengan enkoding lain. Pola rusaknya khas, sehingga dari bentuknya Anda bisa menebak arah salah baca.

Jika huruf seperti Ã, Â, dan â muncul berpasangan dengan simbol aneh (é, “), kemungkinan besar teks UTF-8 dibaca sebagai Windows-1252: byte awal C3 dan E2 menjadi à dan â, dan byte lanjutan di belakangnya menjadi simbol aneh. Sebaliknya, jika teks Windows-1252 dibaca sebagai UTF-8, byte tunggal seperti E9 atau 96 berubah menjadi �. Masukkan byte aslinya ke kolom heksadesimal, dan konverter membacanya sebagai UTF-8 lebih dulu. Jika gagal, hasil pembacaan sebagai Windows-1252 ditampilkan di bawahnya. Tombol contoh 'Byte rusak' memperlihatkan bahwa A9 20 32 30 32 36 20 96 20 80 35 adalah '© 2026 – €5' dalam Windows-1252.

Kesalahan yang sering terjadi

• Mengira ini perhitungan mengubah angka ke heksadesimal: Jika 255 dimasukkan ke kolom teks, hasilnya bukan FF, melainkan byte 32 35 35 untuk karakter angka '2', '5', '5'. Untuk mengubah basis bilangan, gunakan konverter basis bilangan.
• Mencampur titik kode dengan byte UTF-8: U+00E9 adalah nomor é, sedangkan C3 A9 adalah byte hasil menyimpan nomor itu dalam UTF-8. Jika U+00E9 atau é dimasukkan ke kolom heksadesimal, muncul keterangan bahwa itu bukan byte.
• Menganggap konversi heksadesimal sebagai enkripsi: Heksadesimal hanyalah cara menulis byte, dan siapa pun bisa mengembalikannya ke teks asli. Jangan memakainya untuk menyembunyikan kata sandi atau data pribadi.
• Ragu apakah EF BB BF di awal berkas harus dihapus: EF BB BF adalah BOM UTF-8 (U+FEFF), dan di awal berkas ia hanya berfungsi sebagai tanda pengenal 'berkas UTF-8'. Unicode FAQ menyarankan menghindari BOM pada protokol berbasis byte yang mengharapkan karakter ASCII di awal berkas, tetapi juga menjelaskan bahwa ada kasus yang memintanya, misalnya konvensi berkas .txt Microsoft. Periksa bagaimana penerima memperlakukan BOM, lalu putuskan untuk mempertahankan atau menghapusnya.
• Mengharapkan baris baru Windows 0D 0A: Kolom isian di peramban menyimpan baris baru sebagai LF (0A). Baris baru yang Anda ketik di kolom teks menjadi 0A. Untuk memeriksa byte dengan CR (0D), masukkan 0D 0A di kolom heksadesimal.
• Menyamakan jumlah karakter dengan jumlah byte: Di kolom yang batas panjangnya dihitung dalam byte, '© 2026 – €5' yang tampak 11 karakter dihitung 16 byte di UTF-8. Lihat ketiga angka 'karakter · titik kode · byte' di atas jalur.

Batasan

• Konversi hanya berjalan di dalam peramban. Teks dan byte yang dimasukkan tidak dikirim ke server dan tidak disimpan di alamat atau penyimpanan.
• Teks dikonversi hingga 100.000 posisi UTF-16 sekali jalan, dan heksadesimal hingga 1.200.000 posisi termasuk pemisah. Jalur hanya menggambar 1.500 karakter atau byte galat pertama, dan sisanya hanya ikut dikonversi dan disalin.
• Keluaran heksadesimal hanya berupa byte UTF-8. UTF-16 dan Windows-1252 hanya ditampilkan sebagai perbandingan jumlah byte dan nilai per karakter di kaca pembesar.
• Nilai Windows-1252 mengikuti tabel WHATWG Encoding di peramban, sehingga sebagian karakter bisa berbeda dari tabel yang dipakai program lama.
• Teks asli tidak dinormalisasi otomatis. Teks dengan aksen terpisah (NFD) hanya diberi pemberitahuan, dan baru diubah saat Anda menekan 'Gabung ke NFC'.
• Berkas biner sembarang, seperti gambar atau arsip, tidak ditangani. Untuk mengubah berkas menjadi teks, gunakan alat Base64.
• Saat membaca percent-encoding, tanda + tetap dibaca sebagai tanda plus (2B), bukan spasi. Untuk data formulir yang memakai + sebagai spasi, gunakan encoder/decoder URL.

Sumber

Acuan: aturan UTF-8 mengikuti RFC 3629 dan bab 3 Unicode 18.0 Core Specification; enkode, dekode, dan tabel windows-1252 peramban mengikuti WHATWG Encoding Standard; format lain dan pesan galat mengikuti dokumen masing-masing, dicek pada 21 Oktober 2026. Aturan byte UTF-8 tidak berubah sejak RFC 3629.

• 01RFC 3629 — UTF-8, a transformation format of ISO 10646U+0000 sampai 10FFFF dalam 1 sampai 4 byte, surogat dilarang, peringatan bentuk panjang C0 80, BOM adalah EF BB BF
• 02The Unicode Standard 18.0 — Bab 3 ConformanceTabel 3-7 urutan byte UTF-8 yang sah, 3.9.6 penggantian maximal subpart dengan U+FFFD
• 03WHATWG — Encoding StandardDekoder UTF-8, TextDecoder fatal dan ignoreBOM, label windows-1252 mencakup latin1 dan iso-8859-1
• 04Unicode — UTF-8, UTF-16, UTF-32 & BOM FAQBOM di awal adalah tanda pengenal; hindari pada protokol berbasis byte yang mengharapkan ASCII, tetapi ada konvensi yang memintanya
• 05RFC 3986 — URI Generic Syntax2.1 percent-encoding disarankan huruf kapital, 2.5 ubah ke UTF-8 lalu percent-encoding
• 06MySQL 8.4 — The utf8mb3 Character SetMaksimal 3 byte per karakter, hanya karakter BMP (karakter suplemen tidak didukung), utf8 adalah alias yang tidak lagi disarankan
• 07MySQL 8.4 — Server Error Message ReferenceGalat 1366 ER_TRUNCATED_WRONG_VALUE_FOR_FIELD: Incorrect %s value: '%s' for column
• 08Python 3 — Built-in Types: bytesbytes.fromhex mengabaikan spasi ASCII, bytes.hex(sep) sejak 3.8, byte non-ASCII ditulis dengan escape \x
• 09Microsoft Learn — BitConverter.ToStringPasangan heksadesimal dipisah tanda hubung, misalnya "7F-2C-4A-00"
• 10MDN — TextEncoderSelalu mengenkode string JavaScript ke UTF-8
• 11Unicode Technical Standard #51 — Unicode EmojiRevisi 31 (Emoji 18.0), urutan emoji yang disambung ZWJ
• 12Unicode Standard Annex #15 — Normalization FormsRevisi 58, NFD adalah dekomposisi kanonis, NFC adalah dekomposisi kanonis lalu komposisi kanonis
• 13Apple Technical Q&A QA1173 — Text Encodings in VFSHFS Plus (Mac OS Extended) memakai varian NFD untuk nama berkas

Pertanyaan yang sering diajukan

Alat yang dipakai bersama