ساخت نام کاربری و نشانی لاتین از متن فارسی در محصول

برای ساختن نام کاربری یا نشانی لاتین از متن فارسی، تبدیل خودکار فقط یک پیشنهاد اولیه می‌دهد؛ یکتا بودن، پاک‌سازی و ذخیره‌کردن نتیجه با شماست. اگر این سه را حل نکنید، ماه دوم دو کاربر با نام یکسان دارید و یک نشانی که بعد از ویرایش عنوان تغییر می‌کند.

این مقاله برای تیمی است که می‌خواهد سرویس تبدیل فارسی به فینگلیش را در ساخت شناسه، نشانی صفحه یا نام فایل به کار ببرد. درباره چرایی اختلاف املای اسم‌ها جدا نوشته‌ایم؛ اینجا سؤال مهندسی است: چه چیزی را کجا ذخیره کنم.

سه کاربرد، سه قاعدهٔ متفاوت

«تبدیل به لاتین» در محصول سه کار متفاوت می‌کند و هرکدام نیاز دیگری دارد.

ردیف آخر جزو این مقاله نیست و در راهنمای املای اسم‌ها آمده. سه ردیف اول یک مشکل مشترک دارند: خروجی تبدیل برای دو ورودی متفاوت می‌تواند یکی شود (مثلاً دو اسم که در لاتین یکسان نوشته می‌شوند). پس خروجی کافی نیست؛ لازم است یکتایی هم تضمین کنید.

الگوی پیشنهادی: تبدیل، پاک‌سازی، یکتاسازی

سه گام مجزا کنید و هرکدام را در کد خودتان نگه دارید.

۱. نرمال‌سازی ورودی. پیش از فرستادن، متن را در سمت خودتان یکدست کنید: یای عربی (U+064A) را به ی فارسی (U+06CC) و کاف عربی (U+0643) را به ک فارسی (U+06A9) برگردانید، فاصلهٔ اضافه را بگیرید، نیم‌فاصله را یکنواخت کنید. ما نمی‌دانیم سرویس این یکدست‌سازی را بی‌صدا انجام می‌دهد یا نه، پس فرض نکنید انجام می‌شود. با چند اسم دارای «ی» و «ک» آزمونش کنید و به نتیجه اعتماد کنید، نه به حدس.

۲. پاک‌سازی خروجی. نتیجه را فقط با حروف و ارقام لاتین و خط تیره نگه دارید. فاصله را به - یا _ ببرید، کاراکتر غیرمجاز را بیندازید، طول را محدود کنید:

js function toSlug(finglish) { return finglish .toLowerCase() .replace(/[^a-z0-9]+/g, '-') .replace(/^-+|-+$/g, '') .slice(0, 40); }

۳. یکتاسازی. اگر ali-ahmadi قبلاً هست، یک پسوند عددی اضافه کنید: ali-ahmadi-2. این را در پایگاه‌داده با قید یکتا (unique) تضمین کنید، نه با «اول بپرس بعد بنویس»؛ وگرنه دو درخواست هم‌زمان هر دو موفق می‌شوند.

نتیجه را ذخیره کنید، دوباره نسازید

قاعدهٔ اصلی این مقاله همین است: شناسه‌ای که یک بار ساخته شد، ذخیره شود و بعداً از روی متن فارسی دوباره ساخته نشود.

دلیلش دو چیز است. اول، متن فارسی عوض می‌شود: کاربر اسمش را اصلاح می‌کند یا عنوان مقاله ویرایش می‌شود، و اگر شناسه از روی آن بازتولید شود، نشانی‌های قدیمی می‌شکنند. دوم، خروجی تبدیل ممکن است بین دو زمان یکسان نباشد. مثلاً اگر روزی قاعدهٔ تبدیل بهتر شود، همان متن می‌تواند رشتهٔ دیگری برگرداند. ما قول نمی‌دهیم خروجی تا ابد ثابت بماند، پس قاعده‌اش را از ثابت‌بودن خروجی در نیاورید.

عملاً:

• ستونی جدا برای slug یا username در جدول بگذارید.
• در لحظهٔ ساخت پر شود و بعد از آن فقط با عمل صریح (مثلاً «تغییر نشانی صفحه» با ریدایرکت) عوض شود.
• برای نام کاربری، اجازهٔ ویرایش به کاربر بدهید و تبدیل را فقط پیشنهاد بدانید.

اگر همین رشته را بارها تبدیل می‌کنید (مثلاً هنگام وارد‌کردن انبوه محصول)، در جدول خودتان نگهش دارید تا فراخوان تکراری نزنید؛ فراخوان تکراری برای یک متن هزینه دارد و چیز جدیدی نمی‌آورد.

درخواست و خطاها

همه سرویس‌ها فقط POST و با کلید در هدر هستند؛ کلید را هرگز در سمت مرورگر نگذارید و درخواست را از سرور بزنید:

bash curl -X POST 'https://<دامنه-ما>/api/v1/persian-to-finglish/' \ -H 'Authorization: Bearer melli_live_…' \ -H 'Content-Type: application/json' \ -d '{"persianText":"کتاب‌های تازه"}'

ورودی بین دو تا ۲۰۰ نویسه است. بیشتر یا کمتر یا خالی invalid_input می‌گیرد، که هزینه ندارد. در مستندات فهرست کامل کدها آمده. برای متن بلندتر، آن را قطعه‌قطعه نکنید؛ به‌جایش برای شناسه فقط عنوان یا اسم را بفرستید، نه تمام متن.

آنچه این روش نمی‌کند

مطمئن نمی‌شود دو اسم متفاوت دو شناسهٔ متفاوت دارند؛ یکتاسازی با شماست. جهت برعکس (لاتین به فارسی) را ندارد. ترجمه هم نمی‌کند: «کتاب» می‌شود شکلی از ketab، نه book. اگر نشانی صفحهٔ شما باید معنی داشته باشد، یا عنوان لاتین را دستی بنویسید یا از آن تبدیل فقط به‌عنوان پیش‌نویس استفاده کنید.

و املای نهایی اسمی که باید با گذرنامه بخواند را هم تعیین نمی‌کند؛ آنجا کاربر باید بتواند اصلاح کند.

یک مثال فرضی از ریسک بازتولید

تصور کنید یک مجله اینترنتی عنوان مقاله را به لاتین می‌برد و نشانی را از آن می‌سازد. نویسنده دو روز بعد عنوان را کمی تغییر می‌دهد و سامانه نشانی را دوباره می‌سازد. لینک‌هایی که در شبکه‌های اجتماعی منتشر شده‌اند یک‌باره ۴۰۴ می‌دهند. اگر شناسهٔ اول ذخیره شده بود، هیچ‌کدام نمی‌شکست.

برای این مرحله از سرویس تبدیل فارسی به فینگلیش فقط یک بار، هنگام انتشار، استفاده کنید و حاصل را به‌عنوان مقدار ثابت بنویسید. تغییر بعدی عنوان باید نشانی را عوض نکند، مگر اینکه ویراستار آگاهانه آن را عوض کند.

آزمونی که پیش از انتشار بنویسید

یک فایل آزمون با بیست تا سی ورودی واقعی بسازید: اسم‌های کوتاه و بلند، اسم با «ی» و «ک»، عنوان با عدد، عنوان با نیم‌فاصله، عنوان با علامت نگارشی، و رشته‌ای که پس از پاک‌سازی تهی می‌شود (مثلاً فقط علامت‌ها). برای هر ورودی، خروجی نهایی toSlug را در یک جدول بنویسید و با چشم بخوانید.

دو مورد معمولاً شما را غافلگیر می‌کند. اول، رشته‌ای که پس از پاک‌سازی خالی می‌شود؛ باید جایگزینی داشته باشید (مثلاً یک شناسه عددی). دوم، دو ورودی متفاوت که یک خروجی می‌دهند؛ همین است که یکتاسازی را لازم می‌کند. هر دو را در آزمون بنویسید تا بعد از هر تغییر قاعده، دوباره اجرا شود.

خلاصه برای مرور بعدی

ورودی را نرمال کنید، خروجی را پاک کنید، یکتا کنید و نتیجه را ذخیره کنید. بازتولید شناسه از روی متن فارسی بعد از ساخت، ریسکی است که ارزشش را ندارد. اگر جای شما بودم، قبل از ساخت نسخهٔ اصلی چند صد عنوان یا اسم واقعی محصولم را در جدول آزمایشی می‌ریختم و تعداد برخوردها و رشته‌های عجیب را می‌شمردم.