محتوای آموزشی وبلاگ نت‌آرام
فرم سایت هنگام ذخیره یک متن یا شکلک خطای
Incorrect string value می‌دهد. گاهی متن فارسی ذخیره می‌شود ولی ایموجی نه؛ گاهی یک فایل واردشده با کدگذاری اشتباه مشکل دارد. این خطا معمولاً نشان می‌دهد داده ورودی در یکی از مسیرهای دریافت، اتصال یا ستون مقصد به شکل قابل‌قبول تعبیر نشده است. تغییر نام یک تنظیم در سطح کل دیتابیس الزاماً ستون‌های موجود یا اتصال برنامه را درست نمی‌کند.در MySQL نام تاریخی
utf8 در بسیاری نسخه‌ها به نسخه سه‌بایتی اشاره دارد؛ utf8mb4 امکان ذخیره نویسه‌های یونیکد چهار‌بایتی مانند بسیاری از ایموجی‌ها را فراهم می‌کند. متن فارسی معمولی اغلب در UTF-8 سه‌بایتی هم جا می‌شود؛ پس دیدن خطا با متن فارسی به‌تنهایی ثابت نمی‌کند علت حتماً نبود utf8mb4 است. نسخه MySQL یا MariaDB، ساختار ستون و مسیر ورود داده را جداگانه بررسی کنید.قبل از تغییر: نسخه پشتیبان و محیط آزمایش
از پایگاه داده واقعی و فایل‌های سایت پشتیبان قابل بازیابی بگیرید و یک کپی خصوصی برای آزمایش بسازید. تغییر مجموعه نویسه ممکن است جدول را بازنویسی کند، زمان ببرد یا روی مقایسه متن، ایندکس و برنامه اثر بگذارد. این راهنما برای کسی است که مالک دیتابیس یا مدیر مجاز آن است. رمز دیتابیس و متن حاوی اطلاعات مشتری را در خروجی عمومی قرار ندهید.
۱. از خطا نام جدول و ستون را بردارید
پیام کامل معمولاً نام ستون یا شماره ردیف را نشان می‌دهد. مشخص کنید خطا در فرم سایت، ورود فایل یا یک اسکریپت رخ داده است و با چه متن آزمایشی تکرار می‌شود. اگر فقط یک فایل مشکل دارد، کدگذاری واقعی فایل و تنظیم واردکننده را نیز بررسی کنید؛ عوض‌کردن پسوند فایل، محتوای آن را به UTF-8 تبدیل نمی‌کند.
در phpMyAdmin از ستون سمت چپ دیتابیس درست را انتخاب کنید، وارد تب SQL شوید و به جای نام نمونه، نام جدول آسیب‌دیده را بگذارید:
کد / دستورSHOW FULL COLUMNS FROM sample_table;
ستون
Collation برای ستون‌های متنی، شیوه مقایسه و به‌طور غیرمستقیم مجموعه نویسه مرتبط را نشان می‌دهد. اگر مقدار یک ستون با utf8mb3 یا در نسخه قدیمی با utf8 شروع شود، ممکن است ایموجی چهار‌بایتی در آن جا نشود. اگر از قبل utf8mb4 است، هنوز باید اتصال و ورودی را بررسی کنید؛ اعلام سازگاری ستون همه علت‌ها را رد نمی‌کند.۲. تنظیم اتصال همان برنامه را جداگانه بررسی کنید
در یک نشست SQL، فرمان زیر تنظیمات فعلی همان اتصال را نشان می‌دهد:
کد / دستورSHOW VARIABLES LIKE 'character_set%';
به مقادیر client، connection و results توجه کنید. این خروجی فقط مربوط به همان نشست است؛ تنظیم نشست phpMyAdmin الزاماً برابر با اتصال برنامه وردپرس یا نرم‌افزار دیگر نیست. تنظیم کدگذاری اتصال را در پیکربندی و مستندات همان برنامه یا درایور بررسی کنید. اگر از چارچوبی استفاده می‌کنید، گزینه رسمی اتصال
utf8mb4 را برای آن نسخه پیدا کنید و روی محیط آزمایشی اعمال کنید.برای فهم تفاوت، در یک نشست آزمایشی SQL می‌توان دستور زیر را اجرا کرد:
کد / دستورSET NAMES utf8mb4;
این دستور تنظیم نویسه اتصال همان نشست جاری را تغییر می‌دهد؛ با بستن اتصال از بین می‌رود و پیکربندی دائمی برنامه یا ستون را تغییر نمی‌دهد. اگر برنامه با اتصال دیگری کار می‌کند، باید تنظیم اتصال خودش اصلاح و دوباره آزمایش شود.
۳. اگر خود ستون ظرفیت نویسه لازم را ندارد
در کپی آزمایشی، نوع ستون، طول، NULL یا NOT NULL، مقدار پیش‌فرض، شاخص‌ها و روابط را از ساختار جدول ثبت کنید. سپس یک مهاجرت دقیق برای همان ستون یا جدول با توجه به نسخه دیتابیس و نیاز برنامه طراحی کنید. تبدیل کلی همه جدول‌ها بدون شناخت داده قبلی می‌تواند متن خراب را بدتر کند یا با طول ایندکس نسخه قدیمی ناسازگار باشد.
برای دیدن اصل کار، نمونه زیر فقط برای یک جدول آزمایشی جدید است؛ آن را روی جدول واقعی کپی نکنید:
کد / دستورCREATE TABLE encoding_demo (
id INT PRIMARY KEY,
note VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
);
INSERT INTO encoding_demo (id, note) VALUES (1, 'سلام 😀');
SELECT id, note FROM encoding_demo WHERE id = 1;
این سه فرمان به‌ترتیب جدول نمونه می‌سازند، یک متن آزمایشی ذخیره و همان را بازخوانی می‌کنند. اگر نمونه در اتصال درست موفق است ولی جدول واقعی نه، تعریف ستون واقعی و سازگاری ایندکس را بررسی کنید. اگر نمونه هم شکست خورد، نسخه سرور، پشتیبانی collation، کدگذاری ابزار و اتصال را پیدا کنید. برای حذف نمونه از محیط آزمایشی از روش مدیریت داده خود استفاده کنید؛ جدول واقعی را حذف نکنید.
در جدول واقعی، مدیر دیتابیس باید دستور تغییر متناسب با تعریف کامل همان ستون را بسازد و ابتدا روی کپی آزمایش کند. قبل و بعد از تغییر تعداد ردیف، متن فارسی، شکلک، جست‌وجو و مرتب‌سازی را مقایسه کنید. اگر داده قدیمی پیش‌تر با کدگذاری اشتباه ذخیره شده، تبدیل معمولی همیشه آن را ترمیم نمی‌کند؛ ابتدا نمونه خام و پشتیبان را با متخصص بررسی کنید.
۴. نتیجه را از خود برنامه تأیید کنید
بعد از اصلاح موردی، از همان فرم یا اسکریپت اصلی یک متن آزمایشی بی‌ضرر وارد و دوباره باز کنید. هم نمایش و هم مقدار ذخیره‌شده را کنترل کنید. اگر ورود فایل مشکل داشت، یک فایل کوچک با کدگذاری مشخص و چند سطر نمونه امتحان کنید. سپس تغییر را در زمان مناسب و با برنامه بازگشت روی نسخه اصلی اجرا کنید. در صورت بروز خطای متفاوت، پیام تازه و نام ستون را جداگانه بررسی کنید.
برای جزئیات ارتباط، مستندات رسمی مجموعه نویسه اتصال MySQL را ببینید. اگر برنامه به منابع مستقل و دسترسی مدیریتی نیاز دارد، مشخصات سرور مجازی ایران نت‌آرام را بررسی کنید.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام