محتوای آموزشی وبلاگ نت‌آرام
سایت را به هاست جدید منتقل کرده‌اید و به‌جای متن فارسی، علامت سؤال یا حروف نامفهوم می‌بینید. وسوسه نشوید فوراً یک دستور تبدیل روی کل پایگاه داده اجرا کنید: ابتدا باید بفهمیم متن در فایل پشتیبان سالم است، در پایگاه داده درست ذخیره شده و فقط بد نمایش داده می‌شود، یا در یکی از مراحل واقعاً آسیب دیده است.
تفاوت این حالت‌ها مهم است. اگر حروف اصلی واقعاً به علامت سؤال تبدیل و ذخیره شده باشند، تغییر نام یک تنظیم معمولاً حروف ازدست‌رفته را بازنمی‌گرداند. در ادامه با یک نمونه کوچک و محیط جداگانه محل مشکل را پیدا می‌کنیم.
قبل از تغییر، داده فعلی و فایل اصلی را حفظ کنید
فایل اصلی SQL یا بکاپ را بدون دست‌کاری نگه دارید و یک کپی برای آزمایش بسازید. از وضعیت فعلی سایت مقصد هم نسخه پشتیبان قابل بازیابی بگیرید. اگر بعد از انتقال سفارش، دیدگاه یا نوشته جدید ثبت شده، بازگرداندن کل دیتابیس قدیمی روی سایت فعال می‌تواند آن داده‌ها را از بین ببرد.
بازیابی را ابتدا در یک پایگاه داده و نسخه آزمایشی جدا انجام دهید. دسترسی آن را محدود کنید تا داده مشتری عمومی نشود. رمز دیتابیس، فایل بکاپ و متن حاوی اطلاعات شخصی را در ابزار آنلاین ناشناس یا گفت‌وگوی عمومی قرار ندهید.
قدم اول: نوع خرابی را با یک نمونه مشخص کنید
یک عنوان کوتاه فارسی را انتخاب کنید که پیش از انتقال سالم بوده است. همان عنوان را در سه جا مقایسه کنید: سایت اصلی یا خروجی سالم قبلی، فایل بکاپ بازشده با ابزار متنی مطمئن و سایت مقصد. اگر از اول به بکاپ متنی دسترسی ندارید، از مدیر سایت یا پشتیبانی درباره روش تهیه و نگهداری آن سؤال کنید.
دو شکل رایج را جدا ببینید:
- حروف نامفهوم اما همچنان چند کاراکتر دارند: ممکن است داده با رمزگذاری متفاوت خوانده یا تبدیل شده باشد. قابل‌بازیابی‌بودن آن نیاز به بررسی داده اصلی دارد.
- به‌جای هر حرف علامت
?ذخیره شده است: ممکن است اطلاعات اصلی در تبدیل قبلی از دست رفته باشد. اگر واقعاً بایت‌های ذخیره‌شده به?تبدیل شده‌اند، تغییر تنظیم نمایش نمی‌تواند حدس بزند هر علامت قبلاً کدام حرف بوده است؛ نسخه سالم لازم است.
نحوه بازکردن فایل در برنامه متنی هم مهم است. نمایش اشتباه در یک ویرایشگر، به‌تنهایی ثابت نمی‌کند فایل SQL خراب است. فایل را روی کپی، با تنظیم UTF-8 و ابزار دیگری که به آن اعتماد دارید مقایسه کنید. از ذخیره‌کردن دوباره روی فایل اصلی با یک رمزگذاری نامعلوم بپرهیزید.
قدم دوم: بررسی کنید مشکل فقط نمایش صفحه است یا داده
اگر پیشخوان یا phpMyAdmin همان عنوان را درست نشان می‌دهد ولی صفحه عمومی نه، پاسخ HTML، قالب و افزونه‌هایی را که محتوا را تغییر می‌دهند بررسی کنید. مرورگر باید رمزگذاری صفحه را درست تشخیص دهد؛ در HTML، اعلان UTF-8 یکی از بخش‌های این مسیر است. اما صرف اضافه‌کردن یک تگ به قالب، داده خراب ذخیره‌شده را بازیابی نمی‌کند.
اگر هم phpMyAdmin و هم سایت متن خراب نشان می‌دهند، ممکن است ذخیره، اتصال یا روش نمایش هر دو مشکل داشته باشد. پیش از تغییر، یک ردیف شناخته‌شده را در محیط آزمایشی و با مجوز لازم بررسی کنید. نام واقعی پایگاه داده، جدول، پیشوند وردپرس و شناسه ردیف در سایت شما با مثال فرق دارد.
قدم سوم: نوع کاراکتر و بایت نمونه را بخوانید
مدیر مجاز می‌تواند در phpMyAdmin پایگاه داده آزمایشی را انتخاب و در زبانه SQL اطلاعات جدول را بخواند. برای نمونه اگر جدول واقعاً
کد / دستورwp_posts نام دارد:SHOW CREATE TABLE wp_posts;
خروجی ساختار جدول و تنظیم‌های کاراکتر و collation را نشان می‌دهد. پیشوند وردپرس ممکن است
wp_ نباشد؛ ابتدا نام صحیح را از ابزار مدیریت همان سایت پیدا کنید. utf8mb4 نام مجموعه کاراکتر Unicode در MySQL است، در حالی که collation بر قواعد مقایسه و مرتب‌سازی اثر دارد. داشتن نام collation مناسب به‌تنهایی اثبات نمی‌کند بایت‌های تک‌تک ردیف‌ها سالم‌اند.برای دیدن بایت‌های یک عنوان آزمایشی با شناسه واقعی و مجاز، نمونه زیر فقط همان ردیف را می‌خواند:
کد / دستورSELECT ID, HEX(post_title) FROM wp_posts WHERE ID = 123;
عدد ۱۲۳ و نام جدول نمونه‌اند. خروجی HEX ممکن است اطلاعات متن را به شکل دیگری افشا کند؛ آن را عمومی نکنید. برای درک مثال، کلمه «سلام» در UTF-8 معمولاً با بایت‌های
D8B3D984D8A7D985 نمایش داده می‌شود. اگر داده واقعاً فقط از بایت 3F تشکیل شده باشد، این بایت نشانه علامت سؤال است و خودِ آن اطلاعات حروف قبلی را ندارد. این مقایسه نیاز به شناخت ردیف و مسیر ورود دارد و یک دستور کلی تبدیل برای کل دیتابیس نیست.مدیر فنی می‌تواند تنظیم کاراکتر اتصال را نیز در همان نشست ببیند:
کد / دستورSHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';
این مقادیر برای اتصال و سرور سرنخ‌اند، اما ممکن است اتصال phpMyAdmin با اتصال برنامه سایت فرق کند. آن‌ها را همراه تنظیم برنامه و ساختار ستون‌ها تفسیر کنید. مستند MySQL درباره مجموعه کاراکتر و collation لایه‌های مختلف را توضیح می‌دهد.
قدم چهارم: اگر فایل اصلی سالم است، بازیابی را در محیط جدا امتحان کنید
در پنل هاست، یک دیتابیس آزمایشی خالی و کاربر مجاز مطابق امکانات سرویس بسازید. نسخه آزمایشی سایت را به همان دیتابیس متصل کنید؛ اطلاعات اتصال سایت اصلی را رونویسی نکنید. در phpMyAdmin، دیتابیس آزمایشی را انتخاب و فایل کپی پشتیبان را از بخش Import وارد کنید. گزینه مجموعه کاراکتر فایل را طبق رمزگذاری واقعی فایل و راهنمای نسخه ابزار انتخاب کنید؛ برای فایل UTF-8 سالم، انتخاب UTF-8 معمولاً مناسب است، اما باید با خود فایل تأیید شود.
پس از ورود، همان عنوان و چند متن دیگر را در دیتابیس آزمایشی و سایت آزمایشی ببینید. اگر آنجا درست است ولی مقصد اصلی خراب بود، مسیر تهیه فایل، انتخاب رمزگذاری یا اتصال قبلی را با مدیر فنی مقایسه کنید. اگر فایل هم خراب است، نسخه قدیمی‌تر یا منبع سالم را پیدا کنید؛ ورود مجدد همان داده خراب آن را ترمیم نمی‌کند.
در وردپرس، مقدارهای اتصال دیتابیس در فایل تنظیمات و رفتار درایور به نسخه و مهاجرت بستگی دارند. تغییر تصادفی
DB_CHARSET یا اجرای SET NAMES برای همه برنامه‌ها می‌تواند مشکل را بیشتر کند. ابتدا منشأ و تنظیم سازگار را در محیط آزمایشی با مستند برنامه مشخص کنید.اگر فقط فایل مقصد خراب شده، چطور سایت را بازگردانیم؟
بعد از اثبات بازیابی سالم در محیط آزمایشی، برنامه انتقال داده‌های تازه را با مسئول سایت تنظیم کنید. در فروشگاه، سفارش‌ها و مشتریان پس از زمان بکاپ باید جداگانه در نظر گرفته شوند. جایگزین‌کردن کل دیتابیس اصلی بدون این تطبیق می‌تواند داده جدید را پاک کند؛ یک دستور تبدیل یا import سریع جای برنامه بازیابی را نمی‌گیرد.
اگر فقط تعداد محدودی نوشته آسیب دیده و منبع سالم دارید، بازیابی همان محتوا پس از مقایسه و با مجوز ممکن است مناسب‌تر باشد. پیش از ذخیره، پیوندها، نویسه‌های فارسی، اعداد و متن‌های ترکیبی را امتحان کنید. عملیات تغییر ساختار یا تبدیل انبوه را فقط با نسخه پشتیبان، شناخت نوع داده و آزمون بازیابی انجام دهید.
در پایان، چند صفحه و عنوان متفاوت را در مرورگر، پیشخوان و در صورت نیاز خروجی داده بررسی کنید. برای خطای متفاوتِ Unknown collation هنگام انتقال به MariaDB، راهنمای اختصاصی نسخه و سازگاری آن خطا مناسب‌تر است. مشخصات هاست وردپرس نت‌آرام نیز در صفحه سرویس آمده است؛ سلامت متن به فایل، اتصال و تنظیم واقعی دیتابیس وابسته است.
مقاله قبلی
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام