WordPress وقواعد البيانات: ط³ظ„ط§ظ… أو ???? بدل النص العربي

بعد نقل الموقع إلى خادم جديد أو التحديث أو تصدير قاعدة البيانات، صارت مقالاتك تعرض ط³ظ„ط§ظ… بدل سلام، أو علامات استفهام؟ البيانات في الغالب ما زالت موجودة، لكنها تُقرأ بترميز خاطئ. يصلح Mojibuster ملف التصدير، ثم تعالج أنت السبب في قاعدة البيانات نفسها.

يعمل مع النصوص وهذه الملفات:

  • CSV
  • TXT
  • JSON
  • XML
  • SRT
  • VTT
  • SMI
  • TSV
  • MD
  • HTML
  • SQL
  • LOG

مثل ملفات Excel المصدّرة ونسخ قواعد البيانات والترجمات وشيفرة المواقع.

إصلاح

  1. اسحب ملفًا أو الصق نصًا
  2. يتم الإصلاح تلقائيًا
  3. انسخ النتيجة أو نزّلها
أو اسحب الملف إلى هنا
  • دون رفع. تُصلح الملفات داخل متصفحك مباشرة ولا تغادر جهازك أبدًا.

  • خوادم في الاتحاد الأوروبي. يعمل Mojibuster على خادم في فنلندا (الاتحاد الأوروبي)، لذلك تسري اللائحة العامة لحماية البيانات (GDPR). نص اللائحة (EUR-Lex، بالإنجليزية)

كيف تبدو المشكلة

سطر من نسخة SQL بعد الانتقال إلى خادم جديد

قبل

INSERT INTO wp_posts (post_title) VALUES ('ظ…ط±ط­ط¨ط§ ط¨ظƒظ…طŒ طھظ… ط´ط­ظ† ط§ظ„ط·ظ„ط¨');

بعد

INSERT INTO wp_posts (post_title) VALUES ('مرحبا بكم، تم شحن الطلب');

من أين تأتي المشكلة

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

  • قيمة DB_CHARSET في wp-config.php هي latin1 أو لا تطابق الجداول.
  • صُدّرت النسخة بترميز latin1 واستُوردت بترميز utf8mb4، أو العكس.
  • حوّلت إضافة أو أداة استيراد نصًا تالفًا أصلًا مرة أخرى. وهكذا ينشأ الترميز المزدوج.

إصلاح ملف التصدير

  1. خذ نسخة احتياطية من قاعدة البيانات قبل تغيير أي شيء.
  2. صدّر الجداول المتضررة إلى ملف .sql، مثلًا عبر phpMyAdmin أو mysqldump --default-character-set=utf8mb4.
  3. اسحب الملف إلى المربع أعلاه. يصلح Mojibuster المواضع التالفة فقط ويعرض لك كل تغيير.
  4. نزّل الملف المصلح واستورده بترميز utf8mb4 إلى قاعدة بيانات تجريبية جديدة.
  5. افحص الموقع. فإذا بدا كل شيء سليمًا فاستورده إلى قاعدة البيانات الفعلية.

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

احذر من البيانات المتسلسلة (serialized)

يحفظ WordPress بعض الإعدادات في wp_options وwp_postmeta على شكل قيم PHP متسلسلة، مثل s:8:"سلام";. الرقم هو الطول بالبايت: في UTF-8 يشغل كل حرف عربي بايتين. وللنص التالف طول مختلف عن النص المصلح، لذلك لا يطابق الرقم بعد الإصلاح ويتجاهل WordPress القيمة. أصلح أولًا جداول المحتوى مثل wp_posts وwp_comments وwp_terms. أما للإعدادات فالأفضل استخدام wp search-replace من WP-CLI لأنه يحدّث الأطوال.

معالجة السبب في MySQL

  • حوّل الجداول والاتصال إلى utf8mb4 واكتب في wp-config.php السطر define('DB_CHARSET', 'utf8mb4');.
  • إذا كان عمود latin1 يحوي بايتات UTF-8 فلا تحوّله مباشرة، وإلا ترمّز النص مرة ثانية. الطريق المعتاد يمر عبر نوع ثنائي: أولًا MODIFY … LONGBLOB ثم MODIFY … LONGTEXT CHARACTER SET utf8mb4.
  • جرّب كل تغيير أولًا على نسخة من قاعدة البيانات.

أسئلة شائعة

هل أستطيع إصلاح قاعدة بيانات WordPress كاملة دفعة واحدة؟

نعم، حتى ملفات SQL الكبيرة. لكن انتبه إلى البيانات المتسلسلة في wp_options وwp_postmeta، فـ WP-CLI يعالجها بشكل أفضل.

هل ستتغير الحروف السليمة في الملف؟

لا. يصلح Mojibuster المتواليات التالفة بوضوح فقط. والنص السليم يبقى كما هو.

ما الفرق بين utf8 وutf8mb4؟

في MySQL يخزن utf8 حروفًا لا تتجاوز ثلاثة بايتات، فتضيع الرموز التعبيرية. أما utf8mb4 فهو UTF-8 الحقيقي وهو الخيار الصحيح لـ WordPress.

هل ينفع هذا مع أنظمة غير WordPress؟

نعم. لدى Joomla وDrupal وMagento وتطبيقك الخاص على MySQL أو MariaDB المشكلة نفسها والحل نفسه.

أدلة أخرى