تظهر "â €" على الصفحة بدلاً من "" "

StackOverflow https://stackoverflow.com/questions/2477452

  •  21-09-2019
  •  | 
  •  

سؤال

’ تظهر على صفحتي بدلاً من '.

لدي Content-Type ضبط ل UTF-8 في كل من بلدي <head> علامة ورؤوس HTTP الخاصة بي:

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

enter image description here

بالإضافة إلى ذلك ، تم تعيين متصفحي Unicode (UTF-8):

enter image description here

إذن ما هي المشكلة ، وكيف يمكنني إصلاحها؟

هل كانت مفيدة؟

المحلول

تأكد من أن المتصفح والمحرر يستخدمون UTF-8 الترميز بدلاً من ISO-8859-1/Windows-1252.

او استعمل &rsquo;.

نصائح أخرى

إذا ما هي المشكلة،

انه ’ (RIGHT SINGLE QUOTATION MARK - U+2019) الشخصية التي تم ترميزها على أنها CP-1252 بدلاً من UTF-8. إذا قمت بفحص الترميزات الجدول ، ثم ترى أن هذا الحرف في UTF-8 مكون من بايت 0xE2, 0x80 و 0x99. إذا قمت بفحص تخطيط صفحة CP-1252, ، عندها سترى أن كل من تلك البايتات تعود إلى الشخصيات الفردية â, € و ™.

وكيف يمكنني إصلاحه؟

استخدم UTF-8 بدلاً من CP-1252 لقراءة الأحرف والكتابة والتخزين وعرضها.

لدي مجموعة من نوع المحتوى على UTF-8 في كل من بلدي <head> علامة ورؤوس HTTP الخاصة بي:

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

هذا فقط يرشد العميل الذي يشفر لاستخدامه لتفسير وعرض الأحرف. هذا لا يوجه برنامجك الخاص الذي يشفر لاستخدامه لقراءة وأكتب وتخزينها وعرضها. تعتمد الإجابة الدقيقة على لغة النظام / قاعدة البيانات / البرمجة المستخدمة. لاحظ أن المجموعة التي تم تعيينها في رأس استجابة HTTP لها الأسبقية على علامة META HTML. لن يتم استخدام علامة HTML META إلا عند فتح الصفحة من نظام ملفات القرص المحلي بدلاً من HTTP.

بالإضافة إلى ذلك ، تم تعيين متصفحي Unicode (UTF-8):

هذا يفرض فقط العميل الذي يشفر للاستخدام لتفسير الأحرف وعرضها. لكن المشكلة الفعلية هي أنك ترسل بالفعل ’ (مشفر في UTF-8) للعميل بدلاً من ’. يعرض العميل بشكل صحيح ’ باستخدام ترميز UTF-8. إذا تم إساءة استخدام العميل للاستخدام ، على سبيل المثال ISO-8859-1 ، من المحتمل أن ترى ââ¬â¢ في حين أن.

أنا أستخدم ASP.NET 2.0 مع قاعدة بيانات.

هذا على الأرجح حيث تكمن مشكلتك. تحتاج إلى التحقق من خلال أداة قاعدة بيانات مستقلة كيف تبدو البيانات.

إذا ’ الحرف موجود ، فأنت لا تتصل بقاعدة البيانات بشكل صحيح. تحتاج إلى إخبار موصل قاعدة البيانات باستخدام UTF-8.

إذا كانت قاعدة البيانات الخاصة بك تحتوي على ’, ، ثم قاعدة البيانات الخاصة بك هي التي أفسدت. على الأرجح لم يتم تكوين الجداول للاستخدام UTF-8. بدلاً من ذلك ، يستخدمون الترميز الافتراضي لقاعدة البيانات ، والذي يختلف حسب التكوين. إذا كانت هذه هي مشكلتك ، فعادة ما يكون تغيير الجدول لاستخدام UTF-8 يكفي. إذا لم تدعم قاعدة البيانات الخاصة بك ذلك ، فستحتاج إلى إعادة إنشاء الجداول. من الممارسات الجيدة ضبط ترميز الجدول عند إنشائه.

من المرجح أن تستخدم SQL Server ، ولكن إليك بعض رمز MySQL (تم نسخه من هذه المقالة):

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

إذا كان جدولك بالفعل UTF-8 ، فأنت بحاجة إلى التراجع. من أو ماذا او ما ضع البيانات هناك. هذا أين المشكلة. ومن الأمثلة على ذلك أن نموذج HTML يتم تقديمه والتي يتم ترميزها/فك تشفيرها بشكل غير صحيح.

فيما يلي بعض الروابط لمعرفة المزيد حول المشكلة:

لدي بعض المستندات حيث … كان يظهر كما … و ê كان يظهر كما ê. هذه هي الطريقة التي وصلت بها إلى هناك (كود بيثون):

# 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

لإصلاح المشكلة ، استخدمت رمز Python مثل هذا:

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)

(نظرًا لأن شخصًا ما قد أدخل الإصدار twingled في مستند UTF-8 صحيح ، فقد اضطررت فعليًا إلى استخراج الجزء twingled فقط ، وفصله وأدخلته مرة أخرى. لقد استخدمت BeautifulSoup لهذا.)

من الأرجح أن يكون لديك charlie في إنشاء المحتوى من أن تكوين خادم الويب خاطئ. يمكنك أيضًا فرض متصفح الويب الخاص بك على توحيد الصفحة عن طريق تحديد ترميز Windows-1252 لمستند UTF-8. لا يمكن لمستعرض الويب الخاص بك أن ينقذ المستند الذي أنقذه تشارلي.

ملحوظة: يمكن أن تحدث نفس المشكلة مع أي صفحة رمز بايت واحد (مثل Latin-1) بدلاً من Windows-1252.

’ (Unicode CodePoint U+2019 RIGHT SINGLE QUOTATION MARK) مشفرة في UTF-8 كما البايت:

0xE2 0x80 0x99.

’ (Unicode CodePoints U+00E2 U+20AC U+2122) مشفرة في UTF-8 كما البايت:

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

هذه هي البايتات التي يتلقاها متصفحك فعليًا من أجل الإنتاج ’ عند معالجتها كما UTF-8.

هذا يعني أن بيانات المصدر الخاصة بك تمر اثنين تحويلات charset قبل إرسالها إلى المتصفح:

  1. المصدر ’ حرف (U+2019) يتم ترميزها لأول مرة على أنها بايت UTF-8:

    0xE2 0x80 0x99

  2. كانت تلك البايتات الفردية آنذاك سوء التفسير وفك التشفير إلى نقاط الترميز Unicode U+00E2 U+20AC U+2122 بواسطة واحد من Windows-125x charsets (1252 ، 1254 ، 1256 ، و 1258 جميع الخريطة 0xE2 0x80 0x99 إلى U+00E2 U+20AC U+2122) ، ثم يتم تشفير نقاط الترميز هذه على أنها بايت UTF-8:

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

تحتاج إلى العثور على مكان التحويل الإضافي في الخطوة 2 يجري تنفيذه وإزالته.

لديك عدم تطابق في تشفير شخصيتك ؛ يتم ترميز سلسلةك في ترميز واحد (UTF-8) وأي شيء يفسر هذه الصفحة يستخدم آخر (على سبيل المثال ASCII).

حدد دائمًا ترميزك في رؤوس HTTP وتأكد من أن هذا يتطابق مع تعريف إطار العمل الخاص بك للتشفير.

عينة رأس HTTP:

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

إعداد الترميز في ASP.NET 

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

إعداد الترميز في JSP

يحدث هذا أحيانًا عند تحويل السلسلة من Windows-1252 إلى UTF-8 مرتين.

كان لدينا هذا في تطبيق Zend/PHP/MySQL حيث ظهرت أحرف مثل ذلك في قاعدة البيانات ، وربما بسبب اتصال MySQL لا تحدد مجموعة الأحرف الصحيحة. كان يجب علينا:

  1. تأكد من التواصل Zend و PHP مع قاعدة البيانات في UTF-8 (كان ليس بشكل افتراضي)

  2. إصلاح الشخصيات المكسورة مع العديد من استعلامات SQL مثل هذا ...

    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);

    افعل ذلك للعديد من الجداول/الأعمدة حسب الضرورة.

يمكنك أيضًا إصلاح بعض هذه السلاسل في PHP إذا لزم الأمر. لاحظ أنه بسبب تشفير الأحرف مرتين, ، نحتاج في الواقع إلى إجراء تحويل عكسي من UTF-8 العودة إلى Windows-1252 ، والتي أربكتني في البداية.

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

إذا كان نوع المحتوى الخاص بك هو UTF8 بالفعل ، فمن المحتمل أن تصل البيانات بالفعل إلى الترميز الخاطئ. إذا كنت تحصل على البيانات من قاعدة بيانات ، فتأكد من أن اتصال قاعدة البيانات يستخدم UTF-8.

إذا كانت هذه بيانات من ملف ، فتأكد من ترميز الملف بشكل صحيح على أنه UTF-8. يمكنك عادة تعيين هذا في مربع الحوار "حفظ ..." للمحرر الذي تختاره.

إذا تم كسر البيانات بالفعل عند عرضها في الملف المصدر ، فمن المحتمل أن تكون ملف UTF-8 ولكن تم حفظها في الترميز الخاطئ في مكان ما على طول الطريق.

إذا حصل شخص ما على هذا الخطأ على موقع WordPress ، فأنت بحاجة إلى تغيير WP-Config DB Charset: 

define('DB_CHARSET', 'utf8mb4_unicode_ci');

بدلاً من:

define('DB_CHARSET', 'utf8mb4');

يجب أن يكون لديك نص/لصق من مستند Word. مستند Word استخدم اقتباسات ذكية. يمكنك استبداله بحرف خاص (') أو ببساطة اكتب في محرر HTML الخاص بك (').

أنا متأكد من أن هذا سيحل مشكلتك.

حدث نفس الشيء لي مع شخصية " -" (علامة الطول الطويلة).
لقد استخدمت هذا الاستبدال البسيط حتى حله:

htmlText = htmlText.Replace('–', '-');
مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top