PHPکدام فایلها را نباید انکد کرد؟
یکی از رایجترین اشتباهات، انکد کردن همه فایلهای پروژه است. برخی فایلها نباید انکد شوند چون یا اصلا PHP نیستند، یا باید برای مشتری قابل ویرایش بمانند، یا انکدشان باعث خرابی عملکرد میشود. در این مقاله فهرست دقیق این فایلها و دلیل فنی هرکدام را میبینید تا هم هزینه کمتری بدهید و هم خروجی پایدارتری بگیرید.
این مقاله در یک نگاه
- فایل تنظیمات باید خوانا بماند تا مشتری بتواند پیکربندی کند.
- فایلهای ترجمه و زبان هرگز نباید انکد شوند.
- assets مثل css و js و تصویر اصلا PHP نیستند.
- فایلهای تست و توسعه اصلا نباید در بسته نهایی باشند.
- انکد کمتر یعنی هزینه کمتر و خروجی پایدارتر.
قاعده کلی انتخاب
یک قاعده ساده تقریبا همه تصمیمها را روشن میکند: هر چیزی که منطق است انکد شود و هر چیزی که داده یا دارایی است دستنخورده بماند.
منطق یعنی کدی که ارزش فکری شما در آن است: الگوریتمها، کلاسهای کسب و کار و بهویژه اعتبارسنجی لایسنس. داده و دارایی یعنی چیزهایی که ارزش رقابتی ندارند اما برای کارکرد یا سفارشیسازی لازماند: تنظیمات، ترجمهها، تصاویر و استایلها.
فایلهایی که هرگز نباید انکد شوند
| فایل | دلیل | پیامد انکد اشتباه |
|---|---|---|
| فایل تنظیمات (config) | مشتری باید مقادیر را عوض کند | پیکربندی غیرممکن میشود |
| فایلهای ترجمه (po و mo) | باینری ترجمهاند، نه کد | زبان افزونه از کار میافتد |
| assets شامل css و js | اصلا PHP نیستند | ظاهر سایت خراب میشود |
| تصاویر و فونتها | فایل باینریاند | فایل خراب و غیرقابل نمایش |
| readme و مستندات | باید خوانا باشند | بازارها و وردپرس نمیخوانند |
| فایلهای داده مثل json و xml | دادهاند نه کد | خطای خواندن داده |
فایلهایی که با احتیاط
دستهای از فایلها بسته به پروژه ممکن است انکد شوند یا نه. تصمیم درباره آنها به مدل کسب و کار شما بستگی دارد.
قالبهای نمایشی اگر میخواهید مشتری بتواند ظاهر را سفارشی کند، انکد نکنید. اگر طراحی بخشی از ارزش محصول شماست و نمیخواهید کپی شود، انکد کنید و بپذیرید که پشتیبانی بیشتری لازم دارید.
فایلهای کمکی و helper اگر منطق خاصی ندارند و صرفا توابع عمومیاند، انکدشان ارزش افزودهای ندارد.
فایل نصاب (installer) معمولا بهتر است انکد شود چون گاهی بررسی لایسنس در آن انجام میشود، اما حتما بعد از انکد تست کنید که فرایند نصب کامل کار میکند.
فایلهایی که حتما باید انکد شوند
در مقابل، این فایلها اولویت اول شما هستند چون ارزش واقعی محصول و نقطه حمله در آنهاست.
- کلاس اعتبارسنجی لایسنس مهمترین فایل؛ هدف مستقیم هر کسی که بخواهد محصول را نال کند.
- کلاسهای منطق کسب و کار الگوریتمها و قابلیتهایی که مزیت رقابتی شما هستند.
- فایل اصلی و نقطه ورود جایی که جریان برنامه شروع میشود.
- ماژولهای اختصاصی بخشهایی که سرمایهگذاری فکری روی آنها کردهاید.
راهنمای مخصوص وردپرس با جدول تفصیلی در انکد افزونه وردپرس آمده است.
صرفهجویی در هزینه
چون هزینه انکد به ازای هر فایل محاسبه میشود، انتخاب هوشمندانه فایلها مستقیما روی صورتحساب شما اثر میگذارد. در یک پروژه معمولی، معمولا کمتر از نیمی از فایلهای PHP واقعا نیاز به انکد دارند.
یک تمرین ساده: فهرست فایلهای پروژه را باز کنید و برای هر کدام بپرسید «اگر مشتری این فایل را بخواند، چه چیزی از دست میدهم؟» اگر پاسخ «هیچ» بود، انکدش نکنید. جزئیات قیمتگذاری در صفحه تعرفه و روش عملی انتخاب در آموزش انکد فایل PHP آمده است. مستندات رسمی درباره فایلهای قابل پردازش هم در سایت ionCube موجود است.
سوالات متداول
چرا فایل config را نباید انکد کرد؟
چون مشتری باید بتواند مقادیری مثل اطلاعات دیتابیس و تنظیمات را ویرایش کند. اگر انکد شود، پیکربندی محصول غیرممکن میشود.
انکد فایل ترجمه چه مشکلی میسازد؟
فایلهای po و mo داده باینری ترجمهاند نه کد PHP. انکدشان ساختار زبانی را خراب میکند و چندزبانگی از کار میافتد.
قالبهای نمایشی را انکد کنم؟
بستگی دارد. اگر میخواهید مشتری ظاهر را سفارشی کند، انکد نکنید. اگر طراحی بخشی از ارزش محصول است، انکد کنید و پشتیبانی بیشتری در نظر بگیرید.
انکد کمتر یعنی محافظت کمتر؟
نه لزوما. اگر کلاس لایسنس و منطق اصلی انکد شده باشند، محافظت شما برقرار است. انکد فایلهای بیارزش فقط هزینه اضافه میکند.
فایلهای تست را چه کنم؟
اصلا نباید در بسته نهایی باشند. پیش از آپلود، فایلهای تست و مستندات توسعه را از پروژه حذف کنید.
مطالب مرتبط: آموزش انکد فایل PHP · انکد افزونه وردپرس · انکد کل پروژه