بالنسبة لاستجابات HTTP مع أنواع المحتوى التي تشير إلى بيانات الأحرف ، أي Charset يجب أن يفترضه العميل إذا لم يتم تحديد أي منها؟

Question

إذا لم يتم تحديد معلمة charset في رأس نوع المحتوى ، RFC2616 القسم 3.7.1 يبدو أنه يعني ضمنا ISO8859-1 لأنواع الوسائط من النوع الفرعي "النص":

عندما لا يتم توفير معلمة Charset الصريحة ، يتم تعريف الأنواع الفرعية للوسائط من نوع "النص" على قيمة charset الافتراضية لـ "ISO-8859-1" عند استلامها عبر HTTP.

يجب أن تسمى البيانات في مجموعات الأحرف بخلاف "ISO-8859-1" أو مجموعاتها الفرعية بقيمة Charset المناسبة.

ومع ذلك ، أرى بشكل روتيني التطبيقات التي تخدم ملفات javaScript ذات قيم من نوع المحتوى مثل "Application/X-JavaScript" (أي لا يوجد معاملة charset) ، حتى عندما تحتوي هذه البرامج النصية على أحرف UTF-8 كما ISO8859-1.

هذا لا يبدو أنه يشكل مشاكل للعملاء. كيف يعرف العملاء تفسير البايتات على أنها UTF-8؟ هل هناك قاعدة للأنواع الفرعية الأخرى التي تعني أن UTF-8 يجب أن يكون الافتراضي؟ أين هذا موثق؟

Answer 1

جميع المتصفحات الرئيسية التي راجعتها (أي ، FF و Opera) بالكامل تجاهل مواصفات RFC في هذا الجزء.

إذا كنت مهتمًا بخوارزمية الكشف التلقائي عن طريق البيانات ، فابحث موزيلا فايرفوكس حلقة الوصل.

مجرد ملاحظة صغيرة حول أنواع المحتوى: فقط النص يحتوي على مجموعات الأحرف. من المعقول افتراض أن المتصفحات تتعامل مع التطبيق/X-javaScript كما تتعامل مع النص/JavaScript (باستثناء IE6 ، ولكن هذا موضوع آخر).

متصفح الانترنت سوف تستخدم charset الافتراضي (ربما يتم تخزينها في السجل) ، كما لوحظ:

بشكل افتراضي ، يستخدم Internet Explorer مجموعة الأحرف المحددة في نوع محتوى HTTP الذي تم إرجاعه بواسطة الخادم لتحديد هذه الترجمة. إذا لم يتم إعطاء هذه المعلمة ، يستخدم Internet Explorer مجموعة الأحرف المحددة بواسطة عنصر التعريف في المستند. يستخدم تفضيلات المستخدم إذا لم يتم تحديد عنصر التعريف.

مصدر: http://msdn.microsoft.com/en-us/library/ms537500٪28vs.85٪29.aspx

موزيلا فايرفوكس محاولات للكشف عن Charset تلقائيًا ، كما هو موضح هنا:

تعرض هذه الورقة ثلاثة أنواع من طرق الكشف التلقائي لتحديد ترميزات المستندات بدون إعلان شارت الصريح.

مصدر: http://www.mozilla.org/projects/intl/universalcharsetdetection.html

الأوبرا يستخدم الكشف التلقائي أيضًا ، كما هو موثق:

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

مصدر: http://www.opera.com/docs/specs/opera9/

Answer 2

كما هو موضح في RFC 4329, ، ايضا application/javascript يمكن أن يكون charset معامل. والسؤال الآخر هو التعامل مع تطبيقات المتصفح. آسف ، ولكن لم يتم اختباره.

Answer 3

في غياب charset المعلمة ، يمكن تحديد تشفير الأحرف في المحتوى. فيما يلي بعض الأساليب التي تتبعها العديد من أنواع المحتوى:

لغة البرمجة - عبر علامة متغيرة:

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

HTML5 البديل:

<meta charset="utf-8">

XML (XHTML ، KML) - عبر إعلان XML:

<?xml version="1.0" encoding="UTF-8"?>

نص - عبر بايت ترتيب علامة. على سبيل المثال ، ل UTF-8 أول ثلاثة بايتات من ملف في سداسي عشري:

EF BB BF

كما تختلف عن مجموعة الأحرف المرتبطة بالوثيقة ، لاحظ أيضًا أنه يمكن تشفير الأحرف غير ASCII عبر تسلسل أحرف ASCII باستخدام طرق مختلفة:

لغة البرمجة - عبر مراجع الأحرف:

&#nnnn;
&#xhhhh;

XML - عبر مراجع الأحرف:

&
&defined-entity;

جيسون - عبر آلية الهروب:

\u005C
\uD834\uDD1E

الآن ، فيما يتعلق ببروتوكول HTTP 1.1 ، يقول RFC 2616 هذا عن Charset:

يتم استخدام المعلمة "charset" مع بعض أنواع الوسائط لتحديد مجموعة الأحرف (القسم 3.4) من البيانات. عندما لا يتم توفير معلمة Charset الصريحة ، يتم تعريف الأنواع الفرعية للوسائط من نوع "النص" على قيمة charset الافتراضية لـ "ISO-8859-1" عند استلامها عبر HTTP. يجب أن تسمى البيانات في مجموعات الأحرف بخلاف "ISO-8859-1" أو مجموعاتها الفرعية بقيمة Charset المناسبة. انظر القسم 3.4.1 للحصول على مشاكل التوافق.

لذا ، فإن تفسيري لما سبق هو ذلك لا تستطيع افترض مجموعة أحرف افتراضية إلا بالنسبة للوسائط الفرعية من نوع "النص". بالطبع ، نحن نعيش في العالم الحقيقي ولا يتبع المنفذون دائمًا القواعد. كما هو موضح في إجابة مقبولة, ، قام بائعي متصفحي الويب المختلفة بتنفيذ استراتيجياتهم الخاصة لتحديد مجموعة أحرف المستند عندما لا يتم تحديدها بشكل صريح. يمكن للمرء أن يفترض أن بائعي العملاء الآخرين (على سبيل المثال ، Google Earth) ينفذون أيضًا استراتيجياتهم الخاصة.

Answer 4

RFC 4329 يعرّف نوع الوسائط "Application/JavaScript" كبديل لـ "Text/JavaScript" و "Application/X-JavaScript" وأنواع أخرى مماثلة. يحدد القسم 4.2 ترميز الحرف الافتراضي ليكون UTF-8 عندما لا تتوفر معلمة "charset" الصريحة ولا يوجد Unicode BOM في مقدمة البيانات.

Answer 5

إنه أمر مميز بعض الشيء لـ xmlhttprequest ويتم وصفه هنا: http://www.w3.org/tr/xmlhttprequest/

Answer 6

الإشارة إلى ما هو واضح: "التطبيق/X-JavaScript" ليس نوعًا فرعيًا من "النص".

أيضا ، النص في RFC 2616 عفا عليها الزمن. لن تحدد المراجعة التالية لـ HTTP/1.1 افتراضيًا. انظر RFC 6657 لمزيد من المعلومات.