Sunucu PHP5 ve HTML charset latin1 olan (iso-8859-1). (-) Örneğin normal form POST istekleri ile, em dash gibi "özel" karakterleri ile herhangi bir problem yoktur. Ben emin bilmiyorum rağmen, çalışır. Karakter kodu 150 tarayıcı için bir Temsil karakter orada var muhtemelen çünkü (ben değişmez bir tire için sunucuda PHP görmek ne olduğu ord).
Şimdi bizim uygulama da ajax önizleme tür mekanizma sağlar: metin sunucuya gönderilir ve bir önizleme için tam bir HTML geri gönderilir. Ancak, sıradan bir karakter kodu 150 tire karakteri ajax (GET ve POST ile test) ile gönderilen sırasında daha fazla bir şey haline dönüşüyor: %E2%80%93. Ben apache günlüğüne zaten görüyoruz.
Çeşitli kaynaklara göre buldum, örneğin http://www.tachyonsoft.com/uc0020.htm, bu em tire UTF8 bayt temsilidir ve benim geçerli bilgi JavaScript Unicode her şeyi yönetir olmasıdır.
Ancak benim app içinde, ben latin1 her şeyi gerekiyor. Basitçe şöyle dedi: düzenli bir POST isteği em gibi karakter kodu 150 karalamak bana verirdi gibi, ben de tercüme UTF8 gösterimi için bu gerekir.
Bu sunucu üzerinde PHP ile ben de utf8_decode(...) veya iconv('UTF-8', 'iso-8859-1', ...) ile deşifre çalıştığınızda, ancak her iki durumda da ben normal bir {olsun çünkü vardı, ben başarısız oluyorum bulunuyor [(2)] } Bu karakteri temsil eden (ve iconv da bana bir haber atıyor: girdi dizesinde geçersiz bir karakter Tespit).
Amacım otomatikleştirilmiş bir çözüm bulmak için, ama belki bu durumda überclever olmaya çalışıyorum?
Ben sadece önceden tanımlanmış bir giriş / çıkış seti ile değiştirme kılavuzu yapan diğer insanları buldum; ama bu her zaman bana karakterleri gevşek olabilir hissi verecek.
Dikkatli bir okuyucu Unicode hakkında şeyleri ve karakter dönüşümü ile tam darbe / karmaşıklığını anlamak arkasında ve ben kesinlikle sadece manuel haritalama sonra bir bütün olarak şeyi anlamak için tercih unutmayın olacaktır.
Update based on Delands question about single-byte character necessity:
Hakikat eğer need bunu bilmiyorum, olduğunu. Şu anda, sunucuya veri aktarmak ve geri almak için iki yolu var:
client latin1 -> normal bir post isteği -> latin1 sunucu üzerinde, ok karakterler, latin1 geri tam sayfa gönderir
client latin1 -> ajax isteği (almak veya sonrası) -> latin1 utf8 dönüştürülür alır -> inline görüntülenecek müşteriye latin1 HTML parçasını göndermek - -> i geri latin1 için utf8 dönüştürmeye çalıştığınızda> özel karakterler başarısız
Utf8_decode/icon ile yukarıda tarif edildiği gibi utf8-> arasındaki dönüşüm latin1 çalışmaz, çünkü ikinci yolu başarısız olur.
Benim nihai hedefi kullanıcı girdi verilerin önizlemesini sunmak için basitçe. Ben yapılmalıdır olan HTML render ve diğer verileri değerlendirme için sunucu yuvarlak yolculuk gerektirir.
The solution
Alans cevap çözümdür: latin1 arka windows-1252 olarak tedavi ve bu Word (en azından benim 2007 burada) ne zaman kopyalama ve yapıştırma şeyler onun arasında ve kullanımı görünüyor ne de olur tarayıcı.
(Alans wikipedia makalesinden) başka ilginç bağlantı için HTML 5 Syntax:
8.2.2.2: Kullanıcı arayüzlerinin minimum destek ile UTF-8 ve Windows-1252 kodlamaları, ancak daha fazla destekleyebilir gerekir.
...
Bir kullanıcı aracısı aksi Unicode karakter içeriği dönüştürmek veya bayt Unicode karakterleri dönüştürmek için ya aşağıdaki tablonun birinci sütununda verilen bir kodlama kullanmak, bunun yerine, aynı satır ikinci sütundaki hücreye verilen kodlama kullanmanız gerekir . Bayt bayt veya sırası nedeniyle bu kodlama aliasing için farklı tedavi edildiğinde, bu uyumluluk için yanlış olduğu söyleniyor.
...
Girdi kodlaması: ISO-8859-1 -> Yedek kodlama: windows-1252
