إصلاح ترميز الحروف العربية في MySQL وphpMyAdmin

يعرض phpMyAdmin أو ملف SQL أو تطبيقك ؟؟؟ أو رموزًا مثل ط§ظ„ط¹ط±ط¨ظٹط© بدل العربية؟ غالبًا لا يتطابق ترميز الجدول والاتصال والاستيراد. يصلح Mojibuster ملفات التصدير داخل متصفحك، ثم تضبط MySQL بشكل صحيح للمستقبل.

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

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

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

إصلاح

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

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

ثلاثة أماكن يحتاج فيها MySQL إلى ترميز

  • العمود أو الجدول: مجموعة المحارف التي تُخزَّن بها البيانات، مثل utf8mb4 أو latin1 أو cp1256.
  • الاتصال: مجموعة المحارف التي يتحدث بها العميل والخادم – تُضبط بـ SET NAMES utf8mb4 أو في إعدادات الاتصال.
  • الملف: الترميز المستخدم لقراءة الاستيراد أو كتابة التصدير – في phpMyAdmin تحت مجموعة محارف الملف (Character set of the file).

إذا لم تتطابق الثلاثة، تتلف الحروف. أشهر حالة: كُتب نص UTF-8 عبر اتصال latin1 في عمود latin1. يبدو التطبيق سليمًا، لكن phpMyAdmin والتصدير يعرضان رموزًا غريبة بدل العربية.

صف من تصدير CSV في phpMyAdmin

قبل

"1","ظ…ط­ظ…ط¯ ط§ظ„ط¹ظ„ظٹ","ط´ط§ط±ط¹ ط§ظ„ظ…ظ„ظƒ ظپظ‡ط¯","ط§ظ„ط±ظٹط§ط¶"

بعد

"1","محمد العلي","شارع الملك فهد","الرياض"

افحص مجموعات المحارف

  • SHOW VARIABLES LIKE 'character_set%'; يعرض إعدادات الخادم والاتصال.
  • SHOW CREATE TABLE customers; يعرض مجموعة محارف الجدول وأعمدته.
  • SELECT name, HEX(name) FROM customers LIMIT 5; يعرض البايتات الفعلية: في عمود utf8mb4 تبدأ الحروف العربية بـ D8 أو D9، أما C398 فتدل على نص تالف سبق ترميزه مرتين.

أصلح ملف تصدير أو نسخة احتياطية

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

لا يغادر التصدير حاسوبك – وهذا مهم لبيانات العملاء. للمزيد عن طبيعة هذه الرموز اقرأ ما هي الرموز الغريبة.

عالج السبب

  • أنشئ الجداول الجديدة بـ DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci.
  • اضبط اتصال تطبيقك على utf8mb4، وفي PHP مثلًا بإضافة charset=utf8mb4 إلى DSN الخاص بـ PDO.
  • إذا كانت بايتات UTF-8 داخل عمود latin1، فلا تحوّله مباشرة بـ CONVERT TO – سيرمّزها مرة ثانية ويتلف النص. الطريقة الآمنة عبر نوع ثنائي: أولًا MODIFY name VARBINARY(255) ثم MODIFY name VARCHAR(255) CHARACTER SET utf8mb4.
  • إذا استبدل MySQL الحروف بـ ? فالعمود أو الاتصال لا يستطيع تمثيلها. وما خُزّن هكذا فُقد نهائيًا – التفاصيل في سؤال «لماذا تظهر علامات استفهام بدل النص العربي؟» في صفحة ما هي الرموز الغريبة.

أسئلة شائعة

لماذا يبدو كل شيء سليمًا في تطبيقي لكن لا يبدو كذلك في phpMyAdmin؟

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

أي collation أختار للعربية؟

utf8mb4_unicode_ci يناسب معظم التطبيقات، وفي MySQL 8 الافتراضي هو utf8mb4_0900_ai_ci. الأهم هو مجموعة المحارف utf8mb4 وليس utf8 التي لا تخزّن الرموز التعبيرية في MySQL.

هل يعمل هذا مع MariaDB؟

نعم. تتعامل MariaDB مع مجموعات المحارف مثل MySQL، والأوامر نفسها.

ما أكبر حجم لملف النسخة الاحتياطية؟

حتى 100 ميغابايت للملف الواحد. صدّر قواعد البيانات الأكبر جدولًا بعد جدول.

أدلة أخرى