وسم Meta Charset
ما يفعله وسم meta charset، ولماذا يجب وضعه في أول 1024 بايت، وكيف تمنع مشكلة mojibake الناتجة عن تعارض ترميز HTML أو تسبّبها.
اللغات
دليل واحد في هذه الصفحة
- أداة مباشرة ذات صلةHTTP Header Checker
يعلن وسم meta charset — <meta charset="utf-8"> — ترميز أحرف صفحتك لكي تحوّل المتصفحات وبرامج الزحف البايتات الخام إلى الأحرف الصحيحة. تشترط مواصفة HTML وقوع التصريح ضمن أول 1024 بايت من المستند، وأفضل ممارسة أن يكون أول عنصر فعلي داخل <head>. إذا كان التصريح غائبًا أو متأخرًا أو متعارضًا ظهر mojibake: أحرف ذات علامات نبرية وعلامات اقتباس منحنية وشرطات طويلة وكتابات غير لاتينية ورموز تعبيرية مشوهة، وقد يفسد ذلك ما يُعرض ويُفهرس. وهو ليس عامل ترتيب مباشرًا؛ فإرشاد Google الوحيد هو استخدام Unicode/UTF-8 حيثما أمكن. يُعد UTF-8 الترميز شبه العالمي والمطلوب في HTML5 اليوم. ويتقدم charset المرسل في رأس Content-Type من الخادم على وسم الصفحة، وهو سبب شائع لأخطاء الترحيل. وهذا أحد الوسوم التي يقرأها المتصفح ضمن مجموعة الوسوم الوصفية.
Evidence for this claim For HTML documents, the charset declaration must identify UTF-8. Scope: Modern HTML conformance requirements. Confidence: high · Verified: WHATWG HTML: Character encoding declaration Evidence for this claim The complete character-encoding declaration must occur within the first 1024 bytes of the document. Scope: HTML serialization requirement intended to make encoding available early to parsers. Confidence: high · Verified: WHATWG HTML: Specifying the document's character encodingالخلاصة — وسم meta charset هو سطر واحد من HTML —
<meta charset="utf-8">— يخبر المتصفح بكيفية قراءة نص صفحتك. استخدمه بصورة خاطئة أو احذفه، وقد تتحول الأحرف الخاصة (اللكنات وعلامات الاقتباس المنحنية والرموز التعبيرية) إلى نص مشوه. وهو لا يساعدك في الترتيب، لكن النص ذي المظهر المكسور سيئ للجميع، بما في ذلك Google. ضعه أولًا داخل<head>واستخدمutf-8. انتهى.
ما الذي يفعله الوسم
تُخزّن كل صفحة ويب على هيئة بايتات خام. ولا تتحول تلك البايتات إلى الحروف التي تقرؤها إلا عندما يحدد شيء ما الحرف الذي تمثله كل بايت (أو مجموعة بايتات). وسم meta charset هو الطريقة التي تخبر بها صفحتك المتصفح — وبرامج زحف محركات البحث — بالنظام الذي ينبغي استخدامه:
<meta charset="utf-8">utf-8 هو الترميز الذي تريده في كل الحالات تقريبًا. فهو يمثل أساسًا كل حرف ونظام كتابة مستخدم اليوم، إضافة إلى الرموز التعبيرية، ضمن نظام واحد.
ما الذي يحدث بدونه
إذا لم تعلن عن ترميز، فعلى المتصفح أن يخمن. وعندما يخطئ التخمين، تحصل على mojibake — نص مشوه تتحول فيه علامة اقتباس منحنية إلى شيء مثل ’، أو تظهر café بصيغة café. وتكون الحروف ذات العلامات النبرية والشرطات الطويلة وعلامات الاقتباس “الذكية” والكتابات غير اللاتينية (العربية والسيريلية والصينية واليابانية) والرموز التعبيرية أكثر المتضررين. وقد يبدو النص الإنجليزي العادي الخالي من العلامات النبرية صحيحًا حتى عندما يكون الترميز خاطئًا، وهذا بالضبط ما يسمح للخلل بالتسلل.
أين تضعه
قاعدتان بسيطتان:
- ضع
<meta charset="utf-8">أولًا داخل<head>، قبل العنوان أو أي شيء آخر. - استخدم
utf-8، لا ترميزًا أقدم.
هذا كل شيء. تنفذ معظم قوالب المواقع وأنظمة CMS ذلك أصلًا — وإذا لم يفعل قالبك، فأضفه.
هل يؤثر في SEO؟
ليس بصورة مباشرة. وسم charset ليس عامل ترتيب. لكن إذا شوّه ترميز خاطئ نصك، فإن ذلك المحتوى المكسور هو ما يراه المستخدمون وما قد ينتهي الأمر بـGoogle إلى فهرسته وعرضه — لذلك يجدر ضبطه حتى لو لم يرفعك في النتائج بحد ذاته.
هل تريد تفاصيل المواصفة — قاعدة “أول 1024 بايت”، ولماذا لا تزال الصياغة القديمة موجودة، وكيف يمكن لرأس خادم أن تكون له الأولوية على وسمك من دون أن تنتبه؟ انتقل إلى تبويب Advanced.
افحص الترميز المعلن من سطر الأوامر
استبدل عنوان URL، ثم قارن رأس الاستجابة بالوسم القريب من بداية HTML. ويكون charset الموجود في رأس HTTP Content-Type له الأولوية على التصريح الموجود داخل المستند.
url="https://example.com/"
curl -sSI "$url" | grep -i '^content-type:'
curl -sS "$url" | head -c 1024 | grep -oiE '<meta[^>]+charset[^>]*>'في وحدة تحكم المتصفح، يعرض هذا الترميز الذي فُسّر، والوسم المعلن، وما إذا كان ذلك الوسم هو العنصر الأول في <head>:
const charset = document.querySelector('meta[charset]');
console.table({
documentCharacterSet: document.characterSet,
declaredCharset: charset?.getAttribute('charset') ?? 'missing',
firstHeadElement: document.head.firstElementChild?.outerHTML ?? 'missing',
charsetIsFirst: document.head.firstElementChild === charset,
});تعكس وحدة التحكم المستند الذي فسّره المتصفح. استخدم فحص curl أيضًا عندما تحتاج إلى إثبات ما أرسله الخادم فعلًا.
افحص الاستجابة قبل تصحيح الترميز
استخدم مدقق رؤوس HTTP لفحص رأس الاستجابة Content-Type المباشر. إذا أعلن عن charset، فقارن قيمته مع <meta charset="utf-8">؛ إذ يمكن أن يفسر التعارض مشكلة mojibake حتى عندما يبدو وسم HTML صحيحًا.
أما الموضع، فاستخدم View Source بدل الاكتفاء بلوحة Elements. تأكد من أن تصريح charset هو الابن الأول لـ<head> وأنه يظهر ضمن أول 1024 بايت من المستند.
تحقق من إصلاح charset
الاختبار 1 — الرأس والوسم متوافقان
- الفرضية: تعلن الاستجابة المباشرة وHTML عن UTF-8.
- الطريقة: افحص رأس الاستجابة
Content-Type، ثم افحص View Source بحثًا عن<meta charset="utf-8">. - شرط النجاح: لا يوجد charset معلن من الخادم يتعارض معه.
- شرط الفشل: يعلن الرأس ترميزًا آخر أو يكون الوسم غائبًا.
- الإجراء التالي: أصلح رأس الخادم أولًا، ثم أعد اختبار الاستجابة المباشرة.
الاختبار 2 — التصريح مبكر بما يكفي
- الفرضية: يرى المتصفح الوسم قبل أن يضطر إلى تخمين ترميز.
- الطريقة: اجلب أول 1024 بايت وافحص بداية
<head>. - شرط النجاح: يكون وسم charset كاملًا داخل تلك البايتات، ويكون العنصر الأول في
<head>. - شرط الفشل: تدفع التعليقات أو البرامج المحقونة أو ترميزات أخرى الوسم إلى موضع لاحق.
- الإجراء التالي: انقل الوسم قبل كل ترميز غير أساسي في الرأس.
الاختبار 3 — تُعرض الأحرف الحقيقية بصورة صحيحة
- الفرضية: يزيل الإصلاح mojibake من النص الظاهر للمستخدم والقابل للفهرسة.
- الطريقة: افحص عشوائيًا حرفًا ذا لكنة، وعلامة اقتباس منحنية، وشرطة طويلة، ونصًا غير لاتيني، ورمزًا تعبيريًا في الصفحة المباشرة وView Source.
- شرط النجاح: يظهر كل حرف كما كُتب بعد تحديث قسري.
- شرط الفشل: تبقى رموز الاستبدال أو تسلسلات البايت المشوهة.
- الإجراء التالي: تراجع عن تغيير الترميز إذا أدخل فسادًا، ثم تتبع ملف المصدر والقالب وقاعدة البيانات ورأس الاستجابة كلًا على حدة.
Evidence for this claim For HTML documents, the charset declaration must identify UTF-8. Scope: Modern HTML conformance requirements. Confidence: high · Verified: WHATWG HTML: Character encoding declaration Evidence for this claim The complete character-encoding declaration must occur within the first 1024 bytes of the document. Scope: HTML serialization requirement intended to make encoding available early to parsers. Confidence: high · Verified: WHATWG HTML: Specifying the document's character encodingالخلاصة — يعلن
<meta charset="utf-8">ترميز أحرف المستند. وتتطلب مواصفة HTML في WHATWG أن يُسلسل التصريح كاملًا ضمن أول 1024 بايت من المستند، وأن تطابق القيمةutf-8في HTML5؛ وأفضل ممارسة هي وضعه كأول عنصر فعلي داخل<head>. ينتج عن الترميز الغائب أو المتأخر أو غير المتطابق mojibake — أحرف ذات علامات نبرية مشوهة وعلامات اقتباس منحنية وكتابات غير لاتينية ورموز تعبيرية تالفة — وهي مشكلة في صحة العرض والفهرسة، وليست إشارة ترتيب. والعبارة العلنية الوحيدة من Google هي “use Unicode/UTF-8 where possible.” (ترجمة) «استخدم Unicode/UTF-8 حيثما أمكن». ولرأس charset المرسل من الخادم فيContent-Typeالأولوية على الوسم الموجود داخل المستند، وهو سبب شائع لمشكلة mojibake بعد الترحيل. لا يُسمح إلا بعنصر meta charset واحد لكل مستند، ولا أثر له في XML. وإذا وُجدت علامة ترتيب بايتات UTF-8 (BOM)، فلها الأولوية على كل شيء؛ وإلا فلرأس HTTP الأولوية على وسم الصفحة — وترتيب الأولوية الكامل أدناه.
ما هو الوسم
يخبر تصريح charset المحلل بالترميز الذي يستخدمه عندما يحول بايتات المستند إلى نص. وتوضح مواصفة HTML الحية لدى WHATWG الأمر: “The charset attribute specifies the character encoding used by the document. This is a character encoding declaration.” (ترجمة) «تنص المواصفة على أن سمة charset تعرّف الترميز المستخدم لقراءة المستند». أما صياغة MDN العملية فهي: “This attribute declares the document’s character encoding.” (ترجمة) «تعلن هذه السمة ترميز أحرف المستند».
الصياغة الحديثة هي الشكل المختصر:
<meta charset="utf-8">هناك أيضًا صياغة قديمة قبل HTML5 لا تزال تراها في القوالب الأقدم:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">كلتاهما تعلنان الشيء نفسه. في مستند HTML5 حديث لا تحتاج إلا إلى <meta charset="utf-8"> المختصر — فاستخدام الصياغتين زائد لا ضار، وتسمح المواصفة بعنصر meta واحد فقط يعلن charset لكل مستند على أي حال. (من الأفضل النظر إلى صيغة http-equiv على أنها قديمة بدل إضافتها حديثًا؛ وإذا كنت تدقق صفحة تحتوي عليها، فهي ليست معطلة، بل قديمة فحسب.)
متطلبات المواصفة التي تحتاج فعلًا إلى معرفتها
UTF-8 إلزامي عمليًا في HTML5. توضح MDN الأمر مباشرة: يجب أن “value must be an ASCII case-insensitive match for the string utf-8, because UTF-8 is the only valid encoding for HTML5 documents.” (ترجمة) «يجب أن تطابق القيمة السلسلة utf-8 من دون حساسية لحالة أحرف ASCII، لأن UTF-8 هو الترميز الصالح الوحيد لمستندات HTML5». وتذهب مواصفة WHATWG أبعد من ذلك، فتتطلب أن يكون ترميز المستند الفعلي UTF-8 مهما كان المعلن. يغطي UTF-8 أساسًا كل نظام كتابة إضافة إلى الرموز التعبيرية، ولذلك انتهى عصر ترميزات كل منطقة على حدة مثل ISO-8859-1 وWindows-1252 وShift-JIS في الأعمال الجديدة — وما بقي منها حالات توافق قديمة فقط.
يجب أن يقع ضمن أول 1024 بايت من المستند. هذا متطلب صريح في المواصفة، وليس اقتراحًا مرنًا. تقول MDN: “<meta> elements which declare a character encoding must be located entirely within the first 1024 bytes of the document.” (ترجمة) «يجب أن تقع عناصر <meta> التي تعلن ترميز الأحرف بالكامل ضمن أول 1024 بايت من المستند». والسبب ميكانيكي — يفحص المحلل تيار البايتات بحثًا عن ترميز قبل أن يستطيع تفسير بقية المستند بأمان. وإذا ظهر تصريحك متأخرًا فقد يكون المحلل قد التزم بترميز مخمن أو يضطر إلى البدء من جديد، بما يكلف أداءً. انتبه إلى الصياغة: المقصود أول 1024 بايت من المستند كله، لا <head> فقط.
أفضل ممارسة تتجاوز الحد الأدنى للمواصفة: اجعله الابن الأول لـ<head>. لا تكتفِ بكونه “في مكان ما ضمن أول 1024 بايت” — ضع <meta charset="utf-8"> قبل <title> و<link> و<script> و<style> وكل وسم آخر. هذا هو الموضع الذي تفحصه الأدوات الحديثة. توجد مشكلة Lighthouse (#10023) مفتوحة تقترح تدقيقًا يتحقق تحديدًا من مساواة <meta charset> بـdocument.head.firstElementChild — أي يضع علامة على الوسم عندما لا يكون العنصر الأول الحرفي في الرأس، لا لمجرد غيابه. يتجه مسار الأدوات إلى فحص الموضع، لا الحضور فقط.
عنصر meta charset واحد فقط لكل مستند، ولا أثر لسمة charset في مستندات XML/XHTML (يُسمح بها هناك فقط لتسهيل الانتقال من XML وإليه). وهذه ملاحظة تستحق الانتباه إذا كنت تعمل على محتوى يخدمه XHTML أو قوالب قريبة من RSS/Atom.
BOM ورأس HTTP ووسم meta — ترتيب الأولوية
لا تقرأ المتصفحات وسم meta بمعزل؛ إذ تفحص خوارزمية استنتاج الترميز ثلاثة مصادر بترتيب ثابت، وتعتمد أول مصدر يقدم إجابة:
- علامة ترتيب بايتات UTF-8 (BOM) — بضعة بايتات في بداية الملف. إذا اكتشف المتصفح BOM، فهي تحدد الترميز بيقين ولا يُستشار أي شيء آخر.
- charset في رأس HTTP
Content-Type، إذا أرسله الخادم ولم توجد BOM. ولهذا الرأس الأولوية على تصريح meta الموجود داخل المستند. - تصريح
<meta charset>داخل المستند (أوhttp-equivالقديم)، ولا يُفحص إلا إذا لم يقدم المصدران السابقان ترميزًا.
عمليًا، نادرًا ما تظهر BOM في HTML المكتوب يدويًا (وهي أكثر شيوعًا كأثر من محررات نصية معينة أو أدوات تصدير الملفات)، لذلك فإن تعارض الرأس والوسم هو الأكثر إزعاجًا: قد تظل صفحة تعلن <meta charset="utf-8"> بصورة صحيحة تعرض نصًا مشوهًا إذا أرسل CDN أو وكيل عكسي أو خادم مهيأ خطأً charset مختلفًا في الرأس. وهذه علامة كلاسيكية بعد ترحيل خادم أو CDN — لم تتغير HTML، لكن الرأس تغير، وأصبح يحارب الوسم. وعندما تدقق في mojibake، افحص BOM وcharset في رأس الاستجابة، لا مصدر الصفحة فقط.
هل meta charset عامل ترتيب في SEO؟
لا — ومن الجدير أن نكون صريحين لأن نصوص أدوات التدقيق المبنية على الخوف توحي أحيانًا بغير ذلك. هذا شرط سابق لصحة العرض والفهرسة، وليس إشارة ترتيب.
إرشادات Google هنا قليلة وغير مباشرة مقارنة بالوسوم التي تناقشها باستمرار (العنوان والوصف التعريفي وrobots وcanonical). لا توجد صفحة مخصصة في Google Search Central عن ترميز الأحرف — بل هو إدخال داخل مرجع وسوم meta التي تدعمها Google، تحت “Content-Type and charset”. والعبارة المسجلة الوحيدة من Google توصية لا ادعاء ترتيب: “We recommend using Unicode/UTF-8 where possible.” (ترجمة) «نوصي باستخدام Unicode/UTF-8 حيثما أمكن». ولم يظهر في الصحافة المتخصصة أو أرشيفات Search Off the Record تصريح حرفي من Mueller أو Illyes أو Splitt أو Canel يسمي “meta charset” أو “mojibake” تحديدًا — إذ يُعامل charset على أنه نظافة أساسية لمعايير الويب، مثل الترميز الصحيح، لا موضوعًا يستحق تعليق SEO.
لا تملك Bing أيضًا موقفًا عامًا مميزًا من الوسم على الصفحة؛ فوثائقها تشير إلى UTF-8 فقط في صيغ API/feed الخاصة بها (ملفات مفاتيح IndexNow ورؤوس طلب Webmaster API)، لا بوصفه إرشادًا عن <meta charset> في صفحاتك. وبما أن Bingbot محلل HTML قياسي، فالنتيجة العملية نفسها: اتبع قاعدة UTF-8/1024 بايت في مواصفة HTML.
فأين يمكن أن يضرك؟ بصورة غير مباشرة، وفقط عندما يكون الترميز معطوبًا فعلًا: النص المشوه مشكلة جودة محتوى وتجربة مستخدم، وقد يفسد ما يظهر في المقتطفات، كما قد يبدو الناتج شديد الفساد مكسورًا لأنظمة فهرسة Google أيضًا. ويضع إجماع المجال، كما يشرح دليل Ahrefs عن وسوم meta (بقلم Joshua Hardwick)، الأمر هكذا: “unless your page is severely broken as a result of charset issues (which is unlikely), the impact is going to be quite minimal.” (ترجمة) «ما لم تكن صفحتك معطلة بشدة بسبب مشكلات charset — وهو أمر غير مرجح — فسيكون الأثر محدودًا جدًا». أصلحه لأن النص المكسور سيئ، لا لأنك تتوقع دفعة في الترتيب.
كيفية فحصه وإصلاحه
مسار تشخيص سريع عندما تشك في مشكلة ترميز:
- View Source / DevTools. تأكد من وجود
<meta charset="utf-8">وأنه الابن الأول لـ<head>. وفي DevTools، افحص رأس استجابةContent-Typeبحثًا عن قيمة charset — فإذا خالف الوسم، فالرأس هو الفائز وعلى الأرجح سبب المشكلة. واستبعد BOM أيضًا: فهي أندر، لكنها إن وجدت تتغلب على الرأس والوسم معًا. - تضع أدوات التحقق وبرامج الزحف علامة عليه. سيشير مدقق W3C والمدققات القائمة على القواعد (مثل قاعدة «ظهور charset بعد أول 1024 بايت» في Rocket Validator) إلى التصريح المتأخر أو الغائب. كما تعرض عمليات تدقيق المواقع في Ahrefs Site Audit وScreaming Frog مشكلات charset عبر موقع كامل.
- أصلح الطبقة الصحيحة. إذا كان الموضع خاطئًا، فانقل الوسم إلى أعلى الرأس. وإذا كان الترميز خاطئًا (البايتات نفسها ليست UTF-8 أو يرسل الرأس charset متعارضًا)، فلن يفيد إصلاح وسم meta وحده — يجب إعادة ترميز الملف إلى UTF-8 و/أو تصحيح رأس
Content-Typeفي الخادم كي يتوافق الرأس والوسم.
يكون الإصلاح غالبًا بسيطًا جدًا بعد تحديد الطبقة المسببة. فهذا جزء مستقر ومحسوم منذ زمن من مواصفة HTML — لا يوجد إيقاف حديث أو تغير في سلوك منصة يجب تتبعه؛ والتفصيل الوحيد المتطور هو أن الأدوات تتحقق أكثر فأكثر من الموضع، لا الحضور فقط.
موضع هذا الوسم ضمن المنظومة
وسم charset من عناصر الرأس الموجهة إلى المتصفح — مثل وسم viewport، فهو يتعلق بالعرض لا الترتيب، ولذلك يقع في فئة مختلفة عن الوسوم الفعالة في SEO ضمن مجموعة meta-tags (عنصر العنوان والوصف التعريفي وعائلة robots). وهو مجاور للعمل الدولي الذي أخصص له وقتًا كبيرًا: الترميز طبقة تأسيسية تسبق hreflang والمحتوى متعدد أنظمة الكتابة — يخبر hreflang Google بأي نسخة لغة/منطقة تقدم، لكن إذا كان الترميز خاطئًا فسيكون نص تلك النسخة مشوهًا مهما كان الأمر. ولخريطة عناصر الرأس الكاملة مجمعة حسب وظيفتها، راجع بوابة وسوم meta.
ملخص الذكاء الاصطناعي
خلاصة مكثفة للنسخة المتقدمة:
- ما هو:
<meta charset="utf-8">يعلن ترميز أحرف المستند كي يربط المتصفح وبرامج الزحف البايتات الخام بالحروف الصحيحة. - قواعد المواصفة: يجب أن يقع التصريح ضمن أول 1024 بايت من المستند كله؛ ويتطلب HTML5 أن تكون القيمة
utf-8(وأن يكون الترميز الفعلي UTF-8 أيضًا). أفضل ممارسة: الابن الأول الحرفي لـ<head>. عنصر meta charset واحد فقط لكل مستند؛ ولا أثر له في XML/XHTML. - الصياغة القديمة:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">هي الصيغة الأقدم قبل HTML5 — زائدة في الصفحات الحديثة؛ استخدم الصيغة المختصرة. لا تحتاج إلى كلتيهما. - ترتيب الأولوية: تفوز BOM لـUTF-8 إن وجدت بكل شيء؛ وإلا فإن charset في رأس
Content-Typeالمرسل من الخادم يتغلب على وسم الصفحة — وهو خلل mojibake كلاسيكي بعد الترحيل. دقق الرأس (وافحص BOM)، لا المصدر فقط. - لماذا يهم: يسبب الترميز الغائب/المتأخر/غير المتطابق mojibake (لكنات وعلامات اقتباس منحنية وكتابات غير لاتينية ورموز تعبيرية مشوهة) — مشكلة صحة العرض والفهرسة، وليست عامل ترتيب.
- ما تقوله Google: عبارة غير مباشرة فقط — “We recommend using Unicode/UTF-8 where possible.” لا توجد وثيقة مخصصة ولا اقتباس ممثل عن charset/mojibake. ولا تملك Bing موقفًا مميزًا على الصفحة. وتأطير المجال (Ahrefs): الأثر ضئيل ما لم تكن الصفحة “severely broken.”
- التشخيص: استخدم View Source/DevTools للوسم وcharset في رأس الاستجابة؛ وتضع أدوات التحقق (W3C وRocket Validator) وتدقيقات المواقع (Ahrefs وScreaming Frog) علامة على التصريحات المتأخرة أو الغائبة. أصلح الطبقة الصحيحة — الموضع مقابل الترميز/الرأس الفعلي.
الوثائق الرسمية
وثائق المصادر الأولية والمواصفات.
المعايير (WHATWG / MDN)
- HTML Standard (WHATWG) — تحديد ترميز أحرف المستند — القواعد المعيارية: تصريح charset ومتطلب أول 1024 بايت وUTF-8 وحد واحد لكل مستند واستثناء XML.
- HTML Standard (WHATWG) — تحديد ترميز الأحرف — خوارزمية استنتاج الترميز: اكتشاف BOM أولًا، ثم charset في
Content-Typeعلى مستوى HTTP، ثم تصريح meta داخل المستند. - MDN —
<meta>: عنصر البيانات الوصفية — مرجع بلغة واضحة:utf-8فقط في HTML5، وقاعدة 1024 بايت، وصيغةhttp-equivالقديمة.
- وسوم meta وسمات HTML التي تدعمها Google — الإرشاد الوحيد من Google الذي يتناول charset، تحت “Content-Type and charset”: الصيغتان المقبولتان
http-equivوcharset، وتوصية “use Unicode/UTF-8 where possible”. (ترجمة) «استخدم Unicode/UTF-8 حيثما أمكن».
Bing / Microsoft
- البدء مع IndexNow — تشير Bing إلى UTF-8 فقط لصيغ API/ملفات المفاتيح الخاصة بها، لا كإرشاد HTML على الصفحة. ولا توجد وثيقة مخصصة من Bing عن وسم
<meta charset>.
الأدوات
- مشكلة Lighthouse #10023 — التحذير من
<meta charset>المتأخر أو الغائب — التدقيق المقترح للتحقق من كون وسم charset هوdocument.head.firstElementChild.
اقتباسات من المصدر
تصريحات مسجلة من مواصفة HTML وMDN وGoogle. كل رابط هو رابط عميق يقفز إلى المقطع المقتبس حيث يدعم المصدر ذلك.
مواصفة WHATWG HTML — ما هو الوسم
- “The
charsetattribute specifies the character encoding used by the document. This is a character encoding declaration.” (ترجمة) «تحدد سمةcharsetترميز الأحرف الذي يستخدمه المستند. وهذا تصريح بترميز الأحرف». — مواصفة HTML الحية (WHATWG). المصدر
MDN — قواعد الترميز والموضع
- “This attribute declares the document’s character encoding. If the attribute is present, its value must be an ASCII case-insensitive match for the string
utf-8, because UTF-8 is the only valid encoding for HTML5 documents.<meta>elements which declare a character encoding must be located entirely within the first 1024 bytes of the document.” (ترجمة) «تعلن هذه السمة ترميز أحرف المستند. وإذا كانت موجودة، فيجب أن تطابق قيمتها السلسلةutf-8من دون حساسية لحالة أحرف ASCII، لأن UTF-8 هو الترميز الصالح الوحيد لمستندات HTML5. ويجب أن تقع عناصر<meta>التي تعلن ترميز الأحرف بالكامل ضمن أول 1024 بايت من المستند». — وثائق MDN للويب، «<meta>: عنصر البيانات الوصفية». الانتقال إلى الاقتباس
Google — الموقف الرسمي (المحدود)
- “These tags define the page’s content type and character set respectively. Make sure that you surround the value of the
contentattribute in thehttp-equivmetatag with quotes—otherwise thecharsetattribute may be interpreted incorrectly. We recommend using Unicode/UTF-8 where possible.” (ترجمة) «تحدد هذه الوسوم نوع محتوى الصفحة ومجموعة أحرفها على الترتيب. احرص على إحاطة قيمة سمةcontentفي وسمmetaذيhttp-equivبعلامات اقتباس، وإلا فقد تُفسر سمةcharsetبصورة غير صحيحة. نوصي باستخدام Unicode/UTF-8 حيثما أمكن». — Google Search Central، “Meta tags and attributes that Google supports.” (ترجمة) «وسوم meta وسمات HTML التي تدعمها Google». الانتقال إلى الاقتباس
المجال — التأطير الصادق لأثر SEO
- “Unless your page is severely broken as a result of charset issues (which is unlikely), the impact is going to be quite minimal.” (ترجمة) «ما لم تكن صفحتك معطلة بشدة بسبب مشكلات charset — وهو أمر غير مرجح — فسيكون الأثر محدودًا جدًا». — مدونة Ahrefs، «وسوم Meta لتحسين محركات البحث: دليل مبسط للمبتدئين» (Joshua Hardwick). المصدر
قائمة فحص تدقيق meta charset
مرور سريع للتأكد من أن صفحاتك تعلن الترميز وتعرضه بصورة صحيحة:
- تحتوي كل صفحة على
<meta charset="utf-8">داخل<head>. - وسم charset هو الابن الأول لـ
<head>— قبل<title>و<link>و<script>و<style>وأي<meta>آخر. - يقع التصريح ضمن أول 1024 بايت من المستند (وسيحدث ذلك إذا كان الابن الأول للرأس).
- القيمة هي
utf-8— وليست ISO-8859-1 أو Windows-1252 أو صفحة رموز خاصة بمنطقة. - الملف نفسه محفوظ/مقدم كـUTF-8 فعلًا (يجب أن يتوافق التصريح وترميز البايت الحقيقي).
- يوجد عنصر meta charset واحد فقط لكل صفحة.
- يتوافق charset في رأس استجابة
Content-Typeالخاص بالخادم مع الوسم (يتغلب الرأس على الوسم عند التعارض) — تحقق في DevTools، خصوصًا بعد أي ترحيل CDN أو خادم. - لا توجد BOM لترتيب بايتات UTF-8 شاردة في بداية الملف — وهي نادرة، لكنها إن وجدت تتغلب على الرأس والوسم معًا.
- افحص عشوائيًا صفحات ذات محتوى غير ASCII (لكنات وعلامات اقتباس منحنية وكتابات غير لاتينية ورموز تعبيرية) — قد يبدو الإنجليزي العادي صحيحًا حتى عند فساد الترميز.
- مرّر الصفحة عبر مدقق W3C أو برنامج زحف (Ahrefs Site Audit أو Screaming Frog) لاكتشاف التصريحات المتأخرة أو الغائبة على نطاق واسع.
- لا تضف صيغة
http-equiv="Content-Type"القديمة من جديد — فالصيغة المختصرة<meta charset="utf-8">كافية.
ورقة غش meta charset
الصياغتان
| الصيغة | البنية | هل تستخدمها؟ |
|---|---|---|
| الحديثة (HTML5) | <meta charset="utf-8"> | نعم — هذه ما تريده |
| القديمة (قبل HTML5) | <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> | ليست للعمل الجديد؛ زائدة، وتحتاج إلى واحدة فقط |
القواعد المهمة
| القاعدة | التفاصيل |
|---|---|
| القيمة | يجب أن تكون utf-8 في HTML5 (وتتطلب المواصفة أن يكون الترميز الفعلي UTF-8 أيضًا) |
| الموضع (حد المواصفة الأدنى) | ضمن أول 1024 بايت من المستند |
| الموضع (أفضل ممارسة) | الابن الأول الحرفي لـ<head> |
| العدد | عنصر meta charset واحد لكل مستند — لا أكثر |
| XML/XHTML | لا أثر لسمة charset في مستندات XML |
| الأولوية | تفوز BOM لـUTF-8 بكل شيء؛ وإلا فإن charset في رأس Content-Type الخادم يتغلب على وسم الصفحة |
حقائق سريعة
- الترميز الخاطئ/الغائب/المتأخر → mojibake (لكنات وعلامات اقتباس منحنية وكتابات غير لاتينية ورموز تعبيرية مشوهة). قد يبدو إنجليزي ASCII العادي صحيحًا — فالخلل يختبئ.
- ليس عامل ترتيب. عبارة Google الوحيدة: “use Unicode/UTF-8 where possible.” (ترجمة) «استخدم Unicode/UTF-8 حيثما أمكن».
- الأثر ضئيل ما لم تكن الصفحة شديدة الفساد (Ahrefs) — لكن النص المكسور لا يزال يستحق الإصلاح للمستخدمين والفهرسة.
- تدقق في mojibake؟ افحص BOM أولًا، ثم charset في رأس الاستجابة، لا View Source فقط — فـBOM تتغلب على الرأس، والرأس يتغلب على الوسم.
- تتجه الأدوات إلى فحص الموضع (الابن الأول للرأس)، لا الحضور فقط (راجع Lighthouse #10023).
اختبر نفسك: وسم Meta Charset
خمسة أسئلة سريعة عن ترميز الأحرف ووسم charset. اختر إجابة لكل سؤال ثم تحقق منها.
سجل التغييرات
تم التحديث في 22 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 13 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 10 أغسطس 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.
تم التحديث في 18 يوليو 2026.
ملخص تحريري وتفاصيل التغيير المسجلة.تفاصيل التغيير
-
تفاصيل التغيير متاحة حاليًا باللغة الإنجليزية.
المقارنة الكاملة غير متاحة — لم تُؤرشف لقطة سابقة لهذه المراجعة.