487

Apa perbedaan antara UTF-8, UTF-16, dan UTF-32?

Saya mengerti bahwa mereka semua akan menyimpan Unicode, dan masing-masing menggunakan jumlah byte yang berbeda untuk mewakili karakter. Apakah ada keuntungan memilih satu dari yang lain?

— Peter Mortensen
sumber

36

Tonton video ini jika Anda tertarik dengan cara kerja Unicode youtube.com/watch?v=MijmeoH9LT4

1

Video ini berfokus pada UTF-8, dan ya itu menjelaskan dengan baik bagaimana pengodean panjang variabel bekerja dan sebagian besar kompatibel dengan komputer yang membaca atau menulis hanya ASCII dengan panjang tetap. Orang-orang Unicode pintar ketika merancang pengkodean UTF-8.

— mnt

1

Saya telah membuat alat online untuk konversi dan perbandingan.

— Amit Kumar Gupta

1

UTF-8 adalah standar de-facto di sebagian besar perangkat lunak modern untuk file yang disimpan . Lebih khusus lagi, ini adalah pengkodean yang paling banyak digunakan untuk HTML dan konfigurasi dan file terjemahan (Minecraft, misalnya, tidak menerima pengkodean lain untuk semua informasi teksnya). UTF-32 cepat untuk representasi memori internal , dan UTF-16 agak usang , saat ini hanya digunakan di Win32 karena alasan historis ( UTF-16 memiliki panjang tetap ketika Windows 95 adalah suatu hal)

— Kotauskas

@VladislavToncharov UTF-16 tidak pernah penyandian panjang tetap. Anda bingung dengan UCS-2.

373

UTF-8 memiliki keunggulan dalam kasus di mana karakter ASCII mewakili mayoritas karakter dalam blok teks, karena UTF-8 mengkodekan ini menjadi 8 bit (seperti ASCII). Juga menguntungkan karena file UTF-8 yang hanya berisi karakter ASCII memiliki penyandian yang sama dengan file ASCII.

UTF-16 lebih baik di mana ASCII tidak dominan, karena menggunakan 2 byte per karakter, terutama. UTF-8 akan mulai menggunakan 3 byte atau lebih untuk karakter tingkat tinggi di mana UTF-16 tetap hanya 2 byte untuk sebagian besar karakter.

UTF-32 akan mencakup semua karakter yang mungkin dalam 4 byte. Ini membuatnya sangat kembung. Saya tidak bisa memikirkan keuntungan apa pun untuk menggunakannya.

— AnthonyWJones
sumber

165

Keuntungan UTF-32: Anda tidak perlu men-decode data yang tersimpan ke titik kode Unicode 32-bit untuk eg karakter dengan penanganan karakter. Titik kode sudah tersedia di sana di array / vektor / string Anda.

— richq

22

Ini juga lebih mudah untuk diurai jika (surga membantu Anda) Anda harus menerapkan kembali roda.

— Paul McMillan

24

Nah, UTF-8 memiliki keunggulan dalam transfer jaringan - tidak perlu khawatir tentang endianness karena Anda mentransfer data satu byte pada suatu waktu (sebagai lawan dari 4).

— Tim Čas

30

@richq Anda tidak dapat melakukan penanganan karakter per karakter dalam UTF-32, karena titik kode tidak selalu sesuai dengan karakter.

— hamstergene

4

Keuntungan UTF-32: manipulasi string mungkin lebih cepat dibandingkan dengan yang setara utf-8

— Wes

332

Pendeknya:

UTF-8: Pengodean lebar variabel, kompatibel dengan ASCII. Karakter ASCII (U + 0000 ke U + 007F) mengambil 1 byte, titik kode U + 0080 ke U + 07FF mengambil 2 byte, titik kode U + 0800 ke U + FFFF mengambil 3 byte, titik kode U + 10000 ke U + 10FFFF ambil 4 byte. Baik untuk teks bahasa Inggris, tidak begitu baik untuk teks Asia.
UTF-16: Pengodean lebar variabel. Poin kode U + 0000 ke U + FFFF mengambil 2 byte, kode poin U + 10000 ke U + 10FFFF mengambil 4 byte. Buruk untuk teks bahasa Inggris, bagus untuk teks Asia.
UTF-32: Pengkodean dengan lebar tetap. Semua poin kode membutuhkan empat byte. Memori babi yang luar biasa, tetapi cepat dioperasikan. Jarang digunakan.

Panjang: lihat Wikipedia: UTF-8 , UTF-16 , dan UTF-32 .

— Adam Rosenfield
sumber

65

@spurrymoses: Saya mengacu pada jumlah ruang yang digunakan oleh byte data. UTF-8 membutuhkan 3 byte per karakter Asia, sedangkan UTF-16 hanya membutuhkan 2 byte per karakter Asia. Ini sebenarnya bukan masalah besar, karena komputer memiliki banyak memori saat ini dibandingkan dengan jumlah rata-rata teks yang disimpan dalam memori program.

— Adam Rosenfield

12

UTF-32 tidak jarang digunakan lagi ... pada osx dan linux wchar_tdefault hingga 4 byte. gcc memiliki opsi -fshort-wcharyang mengurangi ukuran menjadi 2 byte, tetapi memecah kompatibilitas biner dengan std libs.

— vine'th

9

@PandaWood ofcource UTF-8 dapat menyandikan karakter apa pun! Tetapi apakah Anda telah membandingkan persyaratan memori dengan itu untuk UTF-16? Anda sepertinya kehilangan intinya!

— Ustaman Sangat

16

Jika seseorang mengatakan bahwa UTF-8 adalah "tidak begitu baik untuk teks Asia" dalam konteks Semua Format Pengkodean Termasuk Yang Tidak Dapat Meng-encode Unicode, mereka tentu saja akan salah. Tapi itu bukan konteksnya. Konteks persyaratan memori berasal dari fakta bahwa pertanyaan (dan jawaban) membandingkan UTF-8, UTF-16 dan UTF-32, yang semuanya akan menyandikan teks Asia tetapi menggunakan jumlah memori / penyimpanan yang berbeda. Maka kebaikan relatif mereka secara alami akan sepenuhnya dalam konteks persyaratan memori. "Tidak begitu baik"! = "Tidak baik".

— Paul Gregory

5

@ MCGafter: Ya tentu saja ada. Jika Anda ingin dapat dipercaya, langsung ke mulut kuda di The Unicode Consortium . Lihat bab 2.5 untuk deskripsi pengkodean UTF- *. Tetapi untuk memperoleh pemahaman sederhana, tingkat tinggi dari pengkodean, saya menemukan bahwa artikel Wikipedia adalah sumber yang jauh lebih mudah didekati.

— Adam Rosenfield

116

UTF-8 adalah variabel 1 hingga 4 byte.
UTF-16 adalah variabel 2 atau 4 byte.
UTF-32 diperbaiki 4 byte.

Catatan: UTF-8 dapat membutuhkan 1 hingga 6 byte dengan konvensi terbaru: https://lists.gnu.org/archive/html/help-flex/2005-01/msg00030.html

— Quassnoi
sumber

35

UTF8 sebenarnya 1 hingga 6 byte.

— Urkle

6

@Urkle secara teknis benar karena memetakan jangkauan penuh UTF32 / LE / BE termasuk U-00200000 - U-7FFFFFFF meskipun Unicode v6.3 berakhir pada inklusif U-0010FFFF. Berikut ini rincian yang bagus tentang bagaimana meng-enc / dec 5 dan 6 byte utf8: lists.gnu.org/archive/html/help-flex/2005-01/msg00030.html

4

mencadangkan ini dengan bagian referensi yang relevan dan sumbernya?

— n611x007

20

@Urkle Tidak, UTF-8 tidak boleh 5 atau 6 byte. Poin kode Unicode terbatas pada 21 bit, yang membatasi UTF-8 hingga 4 byte. (Anda tentu saja memperluas prinsip UTF-8 untuk mengkodekan bilangan bulat besar sewenang-wenang, tapi itu tidak akan Unicode.) Lihat RFC 3629.

— rdb

11

Mengutip Wikipedia: Pada November 2003, UTF-8 dibatasi oleh RFC 3629 agar sesuai dengan batasan pengkodean karakter UTF-16: secara eksplisit melarang titik kode yang sesuai dengan karakter pengganti tinggi dan rendah yang dihapus lebih dari 3% dari urutan tiga byte tiga byte , dan berakhir pada U + 10FFFF menghapus lebih dari 48% dari urutan empat byte dan semua urutan lima dan enam byte.

— Adam Calvet Bohl

79

Unicode mendefinisikan satu set karakter besar tunggal, menetapkan satu nilai integer unik untuk setiap simbol grafis (yang merupakan penyederhanaan utama, dan sebenarnya tidak benar, tetapi cukup dekat untuk keperluan pertanyaan ini). UTF-8/16/32 hanyalah beberapa cara berbeda untuk menyandikan ini.

Singkatnya, UTF-32 menggunakan nilai 32-bit untuk setiap karakter. Itu memungkinkan mereka untuk menggunakan kode lebar-tetap untuk setiap karakter.

UTF-16 menggunakan 16-bit secara default, tetapi itu hanya memberi Anda 65k kemungkinan karakter, yang mana tidak cukup dekat untuk set Unicode penuh. Jadi beberapa karakter menggunakan pasangan nilai 16-bit.

Dan UTF-8 menggunakan nilai-nilai 8-bit secara default, yang berarti bahwa 127 nilai pertama adalah karakter byte-lebar tetap-bit (bit paling signifikan digunakan untuk menandakan bahwa ini adalah awal dari urutan multi-byte, meninggalkan 7 bit untuk nilai karakter aktual). Semua karakter lain dikodekan sebagai urutan hingga 4 byte (jika ingatanku).

Dan itu membawa kita pada keuntungan. Setiap karakter ASCII secara langsung kompatibel dengan UTF-8, jadi untuk memutakhirkan aplikasi lawas, UTF-8 adalah pilihan umum dan jelas. Dalam hampir semua kasus, itu juga akan menggunakan memori paling sedikit. Di sisi lain, Anda tidak dapat membuat jaminan tentang lebar karakter. Lebar mungkin 1, 2, 3 atau 4 karakter, yang membuat manipulasi string menjadi sulit.

UTF-32 bertolak belakang, ia menggunakan memori terbanyak (masing-masing karakter memiliki lebar 4 byte tetap), tetapi di sisi lain, Anda tahu bahwa setiap karakter memiliki panjang yang tepat ini, sehingga manipulasi string menjadi jauh lebih sederhana. Anda dapat menghitung jumlah karakter dalam string hanya dari panjang dalam byte string. Anda tidak dapat melakukannya dengan UTF-8.

UTF-16 adalah kompromi. Ini memungkinkan sebagian besar karakter masuk ke dalam nilai 16-bit dengan lebar tetap. Jadi selama Anda tidak memiliki simbol Cina, not musik atau lainnya, Anda dapat mengasumsikan bahwa setiap karakter memiliki lebar 16 bit. Ini menggunakan lebih sedikit memori daripada UTF-32. Tetapi dalam beberapa hal "yang terburuk dari kedua dunia". Hampir selalu menggunakan lebih banyak memori daripada UTF-8, dan masih tidak menghindari masalah yang mengganggu UTF-8 (karakter panjang variabel).

Akhirnya, sering kali membantu hanya dengan apa yang didukung platform. Windows menggunakan UTF-16 secara internal, jadi pada Windows, itu adalah pilihan yang jelas.

Linux sedikit berbeda, tetapi mereka umumnya menggunakan UTF-8 untuk semua yang sesuai dengan Unicode.

Jadi jawaban singkat: Ketiga penyandian dapat menyandikan set karakter yang sama, tetapi mereka mewakili setiap karakter sebagai urutan byte yang berbeda.

— jalf
sumber

12

Tidak akurat untuk mengatakan bahwa Unicode memberikan integer unik untuk setiap simbol grafis . Itu menetapkan seperti itu untuk setiap titik kode, tetapi beberapa titik kode adalah karakter kontrol yang tidak terlihat , dan beberapa simbol grafis memerlukan beberapa titik kode untuk diwakili.

— tchrist

15

@tchrist: ya, itu tidak akurat. Masalahnya adalah untuk menjelaskan Unicode secara akurat, Anda perlu menulis ribuan halaman. Saya berharap untuk mendapatkan konsep dasar untuk menjelaskan perbedaan antara pengkodean

— jalf

@jalf lol benar jadi pada dasarnya untuk menjelaskan Unicode Anda harus menulis Spesifikasi Inti Unicode

— Justin Ohms

@tchrist Lebih khusus, Anda dapat membuat simbol Cina dari primitif yang disediakan (tetapi mereka berada di grafik yang sama, sehingga Anda hanya akan berakhir menggunakan jumlah ruang yang tidak nyata - baik disk atau RAM - untuk menyandikannya) daripada menggunakan yang built-in.

— Kotauskas

44

Unicode adalah standar dan tentang UTF-x Anda dapat berpikir sebagai implementasi teknis untuk beberapa tujuan praktis:

UTF-8 - " ukuran dioptimalkan ": paling cocok untuk data berbasis karakter Latin (atau ASCII), hanya dibutuhkan 1 byte per karakter tetapi ukurannya tumbuh sesuai variasi simbol (dan dalam kasus terburuk dapat tumbuh hingga 6 byte per karakter)
UTF-16 - " balance ": dibutuhkan minimal 2 byte per karakter yang cukup untuk set bahasa mainstream yang ada dengan ukuran tetap di atasnya untuk memudahkan penanganan karakter (tetapi ukurannya masih variabel dan dapat tumbuh hingga 4 byte per karakter )
UTF-32 - " performance ": memungkinkan penggunaan algoritma sederhana sebagai hasil dari karakter ukuran tetap (4 byte) tetapi dengan kekurangan memori

— benteng
sumber

«Bahasa arus utama» bukan arus utama di banyak bagian dunia ^^

— tuxayo

2

UTF-16 sebenarnya ukuran yang dioptimalkan untuk karakter non ASCII. Untuk itu sangat tergantung dengan bahasa apa yang akan digunakan.

— tuxayo

@tuxayo sepenuhnya setuju, perlu diperhatikan set karakter Hanzi dan Kanji untuk bagian dunia Asia.

— benteng

Harus menjadi jawaban teratas. Ini terlalu benar untuk dimakamkan di sini.

— Michal Štein

28

Saya mencoba memberikan penjelasan sederhana di blogpost saya .

UTF-32

membutuhkan 32 bit (4 byte) untuk mengkodekan karakter apa pun . Misalnya, untuk mewakili titik kode karakter "A" menggunakan skema ini, Anda harus menulis 65 dalam angka biner 32-bit:

00000000 00000000 00000000 01000001 (Big Endian)

Jika Anda melihat lebih dekat, Anda akan melihat bahwa tujuh bit paling kanan sebenarnya adalah bit yang sama ketika menggunakan skema ASCII. Tetapi karena UTF-32 adalah skema lebar tetap , kita harus melampirkan tiga byte tambahan. Berarti bahwa jika kita memiliki dua file yang hanya berisi karakter "A", satu adalah ASCII-encoded dan yang lainnya adalah UTF-32 encoded, ukurannya akan 1 byte dan 4 byte yang sesuai.

UTF-16

Banyak orang berpikir bahwa UTF-32 menggunakan lebar tetap 32 bit untuk mewakili titik kode, UTF-16 adalah lebar tetap 16 bit. SALAH!

Dalam UTF-16 titik kode mungkin direpresentasikan dalam 16 bit, ATAU 32 bit. Jadi skema ini adalah sistem pengkodean panjang variabel. Apa keuntungan dari UTF-32? Setidaknya untuk ASCII, ukuran file tidak akan 4 kali lipat dari aslinya (tapi masih dua kali), jadi kami masih belum kompatibel dengan ASCII.

Karena 7-bit sudah cukup untuk mewakili karakter "A", kita sekarang dapat menggunakan 2 byte bukannya 4 seperti UTF-32. Ini akan terlihat seperti:

00000000 01000001

UTF-8

Anda menebak dengan benar .. Dalam UTF-8 titik kode mungkin direpresentasikan menggunakan 32, 16, 24 atau 8 bit, dan sebagai sistem UTF-16, yang ini juga merupakan sistem pengkodean panjang variabel.

Akhirnya kita dapat merepresentasikan "A" dengan cara yang sama dengan kita merepresentasikannya menggunakan sistem pengkodean ASCII:

01001101

Contoh kecil di mana UTF-16 sebenarnya lebih baik daripada UTF-8:

Pertimbangkan huruf Mandarin "語" - penyandian UTF-8 adalah:

11101000 10101010 10011110

Sementara pengkodean UTF-16 lebih pendek:

10001010 10011110

Untuk memahami representasi dan bagaimana interpretasinya, kunjungi posting asli.

— Maroun
sumber

19

UTF-8

tidak memiliki konsep byte-order
menggunakan antara 1 dan 4 byte per karakter
ASCII adalah subkode penyandian yang kompatibel
sepenuhnya menyinkronkan diri sendiri misalnya byte yang dijatuhkan dari mana saja dalam aliran akan merusak paling banyak satu karakter
hampir semua bahasa Eropa dikodekan dalam dua byte atau kurang per karakter

UTF-16

harus diuraikan dengan byte-order yang diketahui atau membaca byte-order-mark (BOM)
menggunakan 2 atau 4 byte per karakter

UTF-32

setiap karakter adalah 4 byte
harus diuraikan dengan byte-order yang diketahui atau membaca byte-order-mark (BOM)

UTF-8 akan menjadi yang paling efisien ruang kecuali sebagian besar karakter berasal dari ruang karakter CJK (Cina, Jepang, dan Korea).

UTF-32 adalah yang terbaik untuk akses acak dengan karakter offset ke byte-array.

— Jeff Adamson
sumber

Bagaimana cara "sinkronisasi sendiri" bekerja di UTF-8? Bisakah Anda memberikan contoh untuk karakter 1 byte dan 2 byte?

— Koray Tugay

2

@KorayTugay String byte pendek yang valid tidak pernah digunakan dalam karakter yang lebih panjang. Misalnya, ASCII berada dalam kisaran 0-127, artinya semua karakter satu byte memiliki bentuk 0xxxxxxxdalam biner. Semua karakter dua byte dimulai dengan 110xxxxxbyte kedua 10xxxxxx. Jadi misalkan karakter pertama dari karakter dua byte hilang. Segera setelah Anda melihat 10xxxxxxtanpa pendahuluan 110xxxxxx, Anda dapat menentukan dengan pasti bahwa byte hilang atau rusak, dan membuang karakter itu (atau meminta kembali dari server atau apa pun), dan melanjutkan hingga Anda melihat byte pertama yang valid lagi .

— Chris

1

jika Anda memiliki offset ke karakter, Anda memiliki offset ke karakter itu - utf8, utf16 atau utf32 akan bekerja sama dalam hal itu; yaitu mereka semua sama-sama pandai mengakses acak oleh karakter diimbangi ke dalam array byte. Gagasan bahwa utf32 lebih baik dalam menghitung karakter daripada utf8 juga sepenuhnya salah. Sebuah codepoint (yang tidak sama dengan karakter yang lagi, tidak sama dengan grafem a .. mendesah), adalah 32 bit yang luas di UTF32 dan antara 8 dan 32 bit dalam utf8, tapi karakter dapat span beberapa codepoints, yang menghancurkan keunggulan utama yang orang klaim utf32 memiliki lebih dari utf8.

— jelas

14

Saya membuat beberapa tes untuk membandingkan kinerja database antara UTF-8 dan UTF-16 di MySQL.

Perbarui Kecepatan

UTF-8

Masukkan deskripsi gambar di sini

UTF-16

Masukkan deskripsi gambar di sini

Masukkan Kecepatan

Masukkan deskripsi gambar di sini

Hapus Kecepatan

Masukkan deskripsi gambar di sini

— Farid Movsumov
sumber

14

Dalam UTF-32 semua karakter dikodekan dengan 32 bit. Keuntungannya adalah Anda dapat dengan mudah menghitung panjang string. Kerugiannya adalah bahwa untuk setiap karakter ASCII Anda membuang tiga byte tambahan.

Dalam karakter UTF-8 memiliki panjang variabel, karakter ASCII dikodekan dalam satu byte (delapan bit), sebagian besar karakter khusus barat dikodekan baik dalam dua byte atau tiga byte (misalnya € adalah tiga byte), dan karakter yang lebih eksotis dapat mengambil hingga empat byte. Kerugian yang jelas adalah, bahwa apriori Anda tidak dapat menghitung panjang string. Tapi itu membutuhkan jauh lebih sedikit byte untuk kode teks alfabet Latin (Inggris), dibandingkan dengan UTF-32.

UTF-16 juga panjang variabel. Karakter dikodekan dalam dua byte atau empat byte. Saya benar-benar tidak mengerti intinya. Ini memiliki kelemahan karena panjang variabel, tetapi belum mendapat keuntungan dari menghemat ruang sebanyak UTF-8.

Dari ketiganya, jelas UTF-8 adalah yang paling banyak tersebar.

— vartec
sumber

Mengapa saya ingin menghitung panjang string saat mengembangkan situs web? Apakah ada keuntungan memilih UTF-8 / UTF-16 dalam pengembangan web?

— Morfidon

"Keuntungannya adalah Anda dapat dengan mudah menghitung panjang string" Jika Anda menentukan panjang berdasarkan # dari titik codep, maka ya, Anda bisa membagi panjang byte dengan 4 untuk mendapatkannya dengan UTF-32. Namun, itu bukan definisi yang sangat berguna: itu mungkin tidak berhubungan dengan jumlah karakter. Juga, normalisasi dapat mengubah jumlah codepoint dalam string. Misalnya, kata Prancis "été" dapat dikodekan dalam setidaknya 4 cara berbeda, dengan 3 panjang codepoint yang berbeda.

UTF-16 mungkin lebih cepat dari UTF-8 sementara tidak ada memori yang terbuang seperti halnya UTF-32.

— Michal Štein

6

Bergantung pada lingkungan pengembangan Anda, Anda bahkan mungkin tidak memiliki pilihan pengkodean tipe data string yang akan digunakan secara internal.

Tetapi untuk menyimpan dan bertukar data saya akan selalu menggunakan UTF-8, jika Anda punya pilihan. Jika Anda memiliki sebagian besar data ASCII, ini akan memberi Anda jumlah data terkecil untuk ditransfer, sambil tetap dapat menyandikan semuanya. Mengoptimalkan untuk I / O terkecil adalah cara untuk menggunakan mesin modern.

— mghie
sumber

Bisa dibilang, jauh lebih penting daripada persyaratan ruang adalah fakta, bahwa UTF-8 kebal terhadap endianness. UTF-16 dan UTF-32 pasti akan harus berurusan dengan masalah endianness, di mana UTF-8 hanyalah aliran oktet.

— IInspectable

2

Seperti disebutkan, perbedaan utamanya adalah ukuran variabel yang mendasarinya, yang dalam setiap kasus menjadi lebih besar untuk memungkinkan lebih banyak karakter diwakili.

Namun, font, penyandian, dan hal-hal yang rumit rumit (tidak perlu?), Sehingga tautan besar diperlukan untuk mengisi lebih detail:

http://www.cs.tut.fi/~jkorpela/chars.html#ascii

Jangan berharap untuk memahami semuanya, tetapi jika Anda tidak ingin memiliki masalah di kemudian hari, ada baiknya belajar sebanyak yang Anda bisa, sedini mungkin (atau hanya membuat orang lain menyelesaikannya untuk Anda).

Paul.

— Paul W. Homer
sumber

atau cukup gunakan UTF-8 sebagai default karena telah menjadi standar de-facto, dan cari tahu apakah sistem baru mendukungnya atau tidak. jika tidak, Anda dapat kembali ke pos ini.

— robotik

-2

Singkatnya, satu-satunya alasan untuk menggunakan UTF-16 atau UTF-32 adalah untuk masing-masing mendukung skrip non-Inggris dan kuno.

Saya bertanya-tanya mengapa ada orang yang memilih untuk memiliki pengkodean non-UTF-8 padahal jelas lebih efisien untuk keperluan web / pemrograman.

Kesalahpahaman umum - angka suffix BUKAN indikasi kemampuannya. Mereka semua mendukung Unicode yang lengkap, hanya saja UTF-8 dapat menangani ASCII dengan satu byte, sehingga LEBIH efisien / kurang dapat rusak pada CPU dan melalui internet.

Beberapa bacaan bagus: http://www.personal.psu.edu/ejp10/blogs/gotunicode/2007/10/which_utf_do_i_use.html dan http://utf8everywhere.org

— membunuh kesenangan
sumber

Saya tidak yakin, mengapa Anda menyarankan, bahwa menggunakan UTF-16 atau UTF-32 adalah untuk mendukung teks non-Inggris. UTF-8 dapat menangani itu dengan baik. Dan ada karakter non-ASCII dalam teks bahasa Inggris juga. Seperti non-joiner lebar nol. Atau tanda hubung. Saya khawatir, jawaban ini tidak menambah banyak nilai.

— IInspectable

Pertanyaan ini cenderung downvoting karena UTF-8 masih umum digunakan dalam file HTML bahkan jika sebagian besar karakter adalah karakter 3-byte dalam UTF-8,

— Ṃųỻịgǻňạcểơửṩ

@Ispektif mendukung bukan kata-kata terbaik, mempromosikan atau dukungan yang lebih baik akan lebih akurat

— robotik

Mengirim halaman seperti utf8everywhere.org bukan yang akan saya lakukan dalam jawaban SO.

— Michal Štein