"Â € ™" tampil di halaman alih-alih "'"


133

’ditampilkan di halaman saya, bukan '.

Saya memiliki Content-Typeset UTF-8di <head>tag dan header HTTP saya:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

masukkan deskripsi gambar di sini

Selain itu, browser saya disetel ke Unicode (UTF-8):

masukkan deskripsi gambar di sini

Jadi apa masalahnya, dan bagaimana saya bisa memperbaikinya?


Jawaban:


55

Pastikan browser dan editor menggunakan pengkodean UTF-8, bukan ISO-8859-1 / Windows-1252.

Atau gunakan &rsquo;.


75
Tidak, itu tidak terpecahkan. Masih ada ketidakkonsistenan dalam pengkodean karakter di aplikasi Anda. Anda akan menghadapi kembali masalah yang sama di masa mendatang untuk karakter non-CP1252 lainnya. Dan ada cukup banyak dari mereka ...
BalusC

12
Contoh karakter yang akan terus Anda temui: i18nqa.com/debug/utf8-debug.html
Zoot

utf-8 encoding +1
Karuhanga

217

Jadi apa masalahnya,

Ini adalah karakter ( RIGHT SINGLE QUOTATION MARK- U + 2019) yang sedang diterjemahkan sebagai CP-1252 bukan UTF-8 . Jika Anda memeriksa tabel penyandian , maka Anda melihat bahwa karakter ini di UTF-8 terdiri dari byte 0xE2, 0x80dan 0x99. Jika Anda memeriksa tata letak halaman kode CP-1252 , maka Anda akan melihat bahwa masing-masing byte tersebut mewakili karakter individu â, dan .


dan bagaimana cara memperbaikinya?

Gunakan UTF-8, bukan CP-1252 untuk membaca, menulis, menyimpan, dan menampilkan karakter.


Saya memiliki Tipe Konten yang disetel ke UTF-8 di <head>tag dan header HTTP saya:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Ini hanya menginstruksikan klien yang encoding yang akan digunakan untuk menafsirkan dan menampilkan karakter. Ini tidak menginstruksikan program Anda sendiri yang menggunakan pengkodean untuk membaca, menulis, menyimpan, dan menampilkan karakter. Jawaban yang tepat tergantung pada platform sisi server / database / bahasa pemrograman yang digunakan. Perhatikan bahwa satu set di header respons HTTP lebih diutamakan daripada tag meta HTML. Tag meta HTML hanya akan digunakan ketika halaman dibuka dari sistem file disk lokal alih-alih dari HTTP.


Selain itu, browser saya disetel ke Unicode (UTF-8):

Ini hanya memaksa klien yang menggunakan pengkodean untuk menafsirkan dan menampilkan karakter. Tetapi masalah sebenarnya adalah bahwa Anda sudah mengirim ’(dikodekan dalam UTF-8) ke klien, bukan . Klien menampilkan dengan benar ’menggunakan pengkodean UTF-8. Jika klien salah kaprah untuk menggunakan, misalnya ISO-8859-1, Anda mungkin akan melihatnya ââ¬â¢.


Saya menggunakan ASP.NET 2.0 dengan database.

Ini kemungkinan besar di mana masalah Anda berada. Anda perlu memverifikasi dengan alat basis data independen seperti apa data itu.

Jika karakter ada di sana, maka Anda tidak terhubung ke database dengan benar. Anda harus memberi tahu konektor basis data untuk menggunakan UTF-8.

Jika basis data Anda berisi ’, maka basis data Andalah yang kacau. Kemungkinan besar tabel tidak dikonfigurasi untuk digunakan UTF-8. Sebagai gantinya, mereka menggunakan pengkodean default database, yang bervariasi tergantung pada konfigurasi. Jika ini adalah masalah Anda, maka biasanya hanya mengubah tabel untuk menggunakan UTF-8 sudah cukup. Jika database Anda tidak mendukung itu, Anda harus membuat ulang tabel. Ini adalah praktik yang baik untuk mengatur penyandian tabel saat Anda membuatnya.

Anda kemungkinan besar menggunakan SQL Server, tetapi di sini ada beberapa kode MySQL (disalin dari artikel ini ):

CREATE DATABASE db_name CHARACTER SET utf8;
CREATE TABLE tbl_name (...) CHARACTER SET utf8;

Namun jika meja Anda sudah UTF-8, maka Anda perlu mengambil langkah mundur. Siapa atau apa yang menaruh data di sana. Di situlah masalahnya. Salah satu contohnya adalah nilai-nilai formulir HTML yang dikirimkan yang salah dikodekan / didekodekan.


Berikut ini beberapa tautan untuk mempelajari lebih lanjut tentang masalahnya:


2
Jika Anda memiliki konten yang rusak seperti ini disimpan di suatu tempat misalnya dalam database mysql, stackoverflow.com/a/9407998/117647 memiliki trik yang Anda butuhkan untuk mengubah karakter menjadi utf-8
Steve

5
TL; DR; Gunakan UTF-8 untuk membaca, menulis, menyimpan, dan menampilkan karakter.
c0degeas

Perhatikan bahwa tabel iso-8859-1 dan Windows-1252 tumpang tindih, sehingga beberapa "kombinasi karakter aneh" adalah umum untuk keduanya (misalnya "Ã ©" untuk "é").
Skippy le Grand Gourou

15

Saya punya beberapa dokumen di mana ditunjukkan sebagai …dan êmenunjukkan sebagai ê. Inilah caranya sampai di sana (kode python):

# Adam edits original file using windows-1252
windows = '\x85\xea' 
# that is HORIZONTAL ELLIPSIS, LATIN SMALL LETTER E WITH CIRCUMFLEX

# Beth reads it correctly as windows-1252 and writes it as utf-8
utf8 = windows.decode("windows-1252").encode("utf-8")
print(utf8)

# Charlie reads it *incorrectly* as windows-1252 writes a twingled utf-8 version
twingled = utf8.decode("windows-1252").encode("utf-8")
print(twingled)

# detwingle by reading as utf-8 and writing as windows-1252 (it's really utf-8)
detwingled = twingled.decode("utf-8").encode("windows-1252")

assert utf8==detwingled

Untuk memperbaiki masalah, saya menggunakan kode python seperti ini:

with open("dirty.html","rb") as f:
    dt = f.read()
ct = dt.decode("utf8").encode("windows-1252")
with open("clean.html","wb") as g:
    g.write(ct)

(Karena seseorang telah memasukkan versi twingled ke dokumen UTF-8 yang benar, saya benar-benar harus mengekstrak hanya bagian twingled, melepaskannya dan memasukkannya kembali. Saya menggunakan BeautifulSoup untuk ini.)

Jauh lebih mungkin bahwa Anda memiliki Charlie dalam pembuatan konten daripada konfigurasi server web yang salah. Anda juga dapat memaksa browser web Anda untuk memutar-mutar halaman dengan memilih pengkodean windows-1252 untuk dokumen utf-8. Peramban web Anda tidak dapat mendeteksi dokumen yang disimpan Charlie.

Catatan : masalah yang sama dapat terjadi dengan halaman kode byte tunggal lainnya (misalnya latin-1), bukan windows-1252.


14

(Unicode codepoint U+2019 RIGHT SINGLE QUOTATION MARK) dikodekan dalam UTF-8 sebagai byte:

0xE2 0x80 0x99.

’(Unicode codepoints U+00E2 U+20AC U+2122) dikodekan dalam UTF-8 sebagai byte:

0xC3 0xA2   0xE2 0x82 0xAC   0xE2 0x84 0xA2.

Ini adalah byte yang sebenarnya diterima oleh browser Anda untuk diproduksi ’saat diproses sebagai UTF-8.

Itu berarti bahwa data sumber Anda mengalami dua konversi charset sebelum dikirim ke browser:

  1. Karakter sumber ( U+2019) pertama kali dikodekan sebagai byte UTF-8:

    0xE2 0x80 0x99

  2. mereka byte individu kemudian menjadi salah ditafsirkan dan diterjemahkan ke codepoints Unicode U+00E2 U+20AC U+2122oleh salah satu Windows 125X charset (1252, 1254, 1256, dan 1258 semua peta 0xE2 0x80 0x99untuk U+00E2 U+20AC U+2122), dan kemudian mereka codepoints sedang dikodekan sebagai UTF-8 byte:

    0xE2-> U+00E2-> 0xC3 0xA2
    0x80-> U+20AC-> 0xE2 0x82 0xAC
    0x99-> U+2122->0xE2 0x84 0xA2

Anda perlu menemukan di mana konversi tambahan pada langkah 2 dilakukan dan menghapusnya.


12

Ini kadang-kadang terjadi ketika string dikonversi dari Windows-1252 ke UTF-8 dua kali .

Kami memiliki ini di aplikasi Zend / PHP / MySQL di mana karakter seperti itu muncul di database, mungkin karena koneksi MySQL tidak menentukan set karakter yang benar. Kita harus:

  1. Pastikan Zend dan PHP berkomunikasi dengan database di UTF-8 ( tidak secara default)

  2. Perbaiki karakter yang rusak dengan beberapa kueri SQL seperti ini ...

    UPDATE MyTable SET 
    MyField1 = CONVERT(CAST(CONVERT(MyField1 USING latin1) AS BINARY) USING utf8),
    MyField2 = CONVERT(CAST(CONVERT(MyField2 USING latin1) AS BINARY) USING utf8);
    

    Lakukan ini untuk tabel / kolom sebanyak yang diperlukan.

Anda juga dapat memperbaiki beberapa string ini di PHP jika perlu. Perhatikan bahwa karena karakter telah dikodekan dua kali , kita sebenarnya perlu melakukan konversi balik dari UTF-8 kembali ke Windows-1252, yang membuat saya bingung pada awalnya.

mb_convert_encoding('’', 'Windows-1252', 'UTF-8');    // returns ’

9

Anda memiliki ketidakcocokan dalam pengkodean karakter Anda; string Anda dikodekan dalam satu pengkodean (UTF-8) dan apa pun yang menafsirkan halaman ini menggunakan yang lain (katakanlah ASCII).

Selalu tentukan enkode Anda di header http Anda dan pastikan ini cocok dengan definisi enkode kerangka kerja Anda.

Contoh tajuk http:

Content-Type    text/html; charset=utf-8

Pengaturan pengodean di asp.net

<configuration>
  <system.web>
    <globalization
      fileEncoding="utf-8"
      requestEncoding="utf-8"
      responseEncoding="utf-8"
      culture="en-US"
      uiCulture="de-DE"
    />
  </system.web>
</configuration>

Pengaturan pengkodean dalam jsp


7

Jika jenis konten Anda sudah UTF8, maka kemungkinan data sudah tiba dalam penyandian yang salah. Jika Anda mendapatkan data dari database, pastikan koneksi database menggunakan UTF-8.

Jika ini adalah data dari file, pastikan file tersebut dikodekan dengan benar sebagai UTF-8. Anda biasanya dapat mengatur ini di Dialog "Simpan sebagai ..." editor pilihan Anda.

Jika data sudah rusak ketika Anda melihatnya di file sumber, kemungkinan itu digunakan untuk menjadi file UTF-8 tetapi disimpan dalam pengkodean yang salah di suatu tempat di sepanjang jalan.


4

Jika seseorang mendapatkan kesalahan ini di situs WordPress, Anda perlu mengubah wp-config db charset:

define('DB_CHARSET', 'utf8mb4_unicode_ci');

dari pada:

define('DB_CHARSET', 'utf8mb4');

0

Di DBeaver (atau editor lain) file skrip yang sedang Anda kerjakan dapat meminta untuk disimpan sebagai UTF8 dan itu akan mengubah karakter:

â € “

ke

–

atau

–

-1

Anda harus memiliki salinan / tempel teks dari Dokumen Word. Dokumen Word menggunakan Kutipan Cerdas. Anda dapat menggantinya dengan Karakter Khusus (& rsquo;) atau cukup ketik editor HTML Anda (').

Saya yakin ini akan menyelesaikan masalah Anda.


-3

Hal yang sama terjadi pada saya dengan karakter '-' (tanda minus panjang).
Saya menggunakan penggantian sederhana ini, jadi atasi:

htmlText = htmlText.Replace('–', '-');

4
Masalah OP adalah mojibake, bukan karakter Unicode yang serupa.
Cole Johnson
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.