Masalah yang belum terpecahkan selama pengembangan adalah halaman tersebut menggunakan pengkodean UTF8, dan header dan tail menggunakan metode file penyertaan template. Akibatnya, ada baris kosong tambahan sekitar 10px di head dan tail tanpa ada alasan, dan tidak ada apa-apa.
Alasannya adalah semuanya dikodekan dalam utf8. Saat menyertakan file, aliran biner akhir berisi beberapa tag BOM UTF8. IE tidak dapat mengurai halaman yang berisi beberapa tag BOM UTF8 secara normal dan langsung menggantinya dengan hasil pengangkutan yang sebenarnya ditampilkan, yang menghasilkan pengembalian yang sebenarnya. Baris kosong, tetapi Firefox tidak mengalami masalah ini.
Oleh karena itu, jika templat menggunakan metode penyertaan untuk memuat banyak file utf8 dan perlu disimpan dengan ultraedit, cukup pilih utf8 tanpa format BOM saat menyimpan sebagai fungsi.
Selain itu, jika halaman berbahasa Mandarin menempatkan tag judul di depan <meta http-equiv=”content-type” content=”text/html; charset=UTF-8″ /> di tag head html, halaman tersebut akan menjadi kosong.
Jadi halaman utf8 harus menggunakan urutan standar
<meta http-equiv=”content-type” content=”text/html;
<meta http-equiv=”bahasa-konten” konten=”zh-CN” />
<meta name=”robot” content=”indeks,ikuti” />
<meta name=”kata kunci” content=”” />
<meta nama=”deskripsi” konten=”” />
<meta name=”rating” content=”umum” />
<meta nama=”penulis” konten=”” />
<meta name=”hak cipta” content=”” />
<meta nama=”generator” konten=”” />
<title></title>
BOM header: xEFxBBxBF.PHP4 dan 5 masih mengabaikan BOM, sehingga langsung dikeluarkan sebelum diurai.
Ada penjelasan khusus tentang masalah ini di FAQ standar w3.org:
http://www.w3.org/International/questions/qa-utf8-bom
Detailnya adalah sebagai berikut:
Dalam pengkodean UCS, ada kode disebut karakter "ZERO WIDTH NO" -BREAK SPACE", pengkodeannya adalah FEFF. FFFE adalah karakter yang tidak ada di UCS, jadi seharusnya tidak muncul di transmisi sebenarnya. Spesifikasi UCS merekomendasikan agar kami mengirimkan karakter "ZERO WIDTH NO-BREAK SPACE" sebelum mengirimkan aliran byte. Dengan cara ini, jika penerima menerima FEFF, ini menunjukkan bahwa aliran byte adalah Big-Endian; jika menerima FFFE, ini menunjukkan bahwa aliran byte adalah Little-Endian. Oleh karena itu, karakter "ZERO WIDTH NO-BREAK SPACE" disebut juga BOM.
UTF-8 tidak memerlukan BOM untuk menunjukkan urutan byte, tetapi dapat menggunakan BOM untuk menunjukkan metode pengkodean. Pengkodean UTF-8 untuk karakter "ZERO WIDTH NO-BREAK SPACE" adalah EF BB BF. Jadi jika penerima menerima aliran byte yang dimulai dengan EF BB BF, ia mengetahui bahwa itu dikodekan UTF-8.
Windows adalah sistem operasi yang menggunakan BOM untuk menandai metode pengkodean file teks: WindowsXP Professional, kumpulan karakter default: Cina
1) notepad: dapat secara otomatis mengidentifikasi file format pengkodean UTF-8 tanpa BOM, tetapi tidak dapat mengontrol kapan menyimpan file tambahkan BOM. Jika file disimpan, BOM akan ditambahkan secara seragam.
2)
editplus: tidak dapat secara otomatis mengenali file berformat pengkodean UTF-8 tanpa BOM. Saat menyimpan file, pilih format UTF-8 dan tidak akan menulis header BOM di header file
secara otomatis mengidentifikasi file UTF-8 dengan BOM dan tanpa BOM (dapat dikonfigurasi); saat menyimpan, Anda dapat memilih apakah akan menambahkan BOM melalui konfigurasi
(Catatan khusus adalah saat menyimpan file yang baru dibuat, Anda harus memilih untuk menyimpan sebagai UTF -8 no bom format)
Kemudian saya menemukan bahwa Notepad ++ juga memiliki dukungan yang lebih baik untuk utf-8 bom, dan saya menyarankan semua orang untuk menggunakannya.