طراحی های بد در ساختار زبان PHP

[SZsXsZS]

من اظهار میدارم که کیفیات زیر برای پربار ساختن یک زبان مهم هستند، و PHP به شکل بی پروایی از آنها تخلف میکند. اگر شما نمیتوانید با من موافق باشید که این چیزها مهم هستند، خب پس من نمیتوانم تصور کنم که ما هیچوقت روی چیز زیادی توافق داشته باشیم:

- یک زبان باید قابل پیشبینی باشد. آن وسیله ای برای بیان ایده های انسان و اجرا شدن آن ها توسط کامپیوتر است، بنابراین حیاتی است که درک انسان از یک برنامه عملا صحیح باشد.

- یک زبان باید سازگاری داشته باشد. چیزهای مشابه باید مشابه بنظر برسند، چیزهای متفاوت باید متفاوت بنظر برسند. دانستن بخشی از زبان باید در یادگیری و فهم بقیهء آن کمک کند.

- یک زبان باید موجز باشد. زبانهای جدید برای کاهش جزییات جانبی در زبانهای قدیمی بوجود آمده اند (ما همه میتوانستیم کد اسمبلی بنویسیم). یک زبان بنابراین باید تلاش کند از معرفی جزییات جانبی جدید توسط خودش اجتناب کند.

- یک زبان باید قابل اتکا باشد. زبانها ابزارهایی برای حل کردن مسائل هستند؛ آنها باید مسائل جدیدی را که خودشان ایجاد میکنند به حداقل برسانند. هر چیز غیرمنتظره، یک سردرگمی بزرگ است.

- یک زبان باید قابل دیباگ باشد. وقتی چیزی اشتباه پیش میرود، برنامه نویس باید آن را درست کند، و ما به تمام کمکی که میتوانیم بگیریم نیاز داریم.

من بسیار در جریان استدلالهای طرفداران PHP بوده ام. من یک عالمه استدلالهای مخالف عمومی میشنوم که برای آن طراحی شده اند تا فورا به مباحثه خاتمه دهند:

- به من نگویید که «برنامه نویس خوب میتواند با هر زبانی برنامهء خوب بنویسید»، یا «برنامه نویس بد در هر زبانی برنامهء بد مینویسید». آن هیچ معنایی ندارد. یک نجار خوب میتواند یک میخ را با یک سنگ یا چکش بکوبد، اما شما چه تعدادی نجار دیده اید که چیزها را با سنگ میکوبند؟ بخشی از آنچه یک توسعه دهندهء خوب را شکل میدهد، توانایی انتخاب ابزارهاییست که بهتر کار میکنند.

- به من نگوییید «آن وظیفهء برنامه نویس است که هزار استثنای عجیب و غریب و رفتارهای غیرمنتظره را بخاطر بسپارد». بله، این در هر سیستمی لازم است، چون کامپیوترها ابله هستند. اما آن به معنای این نیست که هیچ حداکثری برای میزان بلاهت در یک سیستم وجود ندارد. PHP چیزی نیست جز استثناء ها، و اینکه کشتی گرفتن با زبان تلاش بیشتری از اینکه عملا برنامهء خودتان را بنویسید صرف کند، چیز خوبی نیست. ابزارهای من نباید برای من اینقدر کار اضافه تولید کنند.

- به من نگویید «فیسبوک و ویکیپدیا با PHP درست شده اند». من مطلع هستم! آنها میتوانستند همچنین با زبان Brain**** نوشته شوند، اما تا زمانیکه افراد بقدر کافی باهوشی وجود دارند که میتوانند چیزها را ردیف کنند، آنها میتوانند بر مشکلات پلتفرم غلبه یابند.

فلسفه:

PHP ابتدا صراحتا برای غیربرنامه نویسان (و غیربرنامه ها) طراحی شد. آن هنوز نتوانسته است از ریشه های خودش فرار کند. یک نقل قول متخب از مستندات رسمی PHP2 بعنوان سند این ادعا:
«... بخصوص برای چیزی مثل PHP که بیشتر اسکریپت ها نسبتا ساده خواهند بود و در بیشتر موارد توسط غیربرنامه نویسانی که زبانی با یک سینتاکس پایه که یادگیری آن بیش از حد دشوار و طولانی نباشد میخواهند»

PHP برای کار کردن در هر شرایطی به هر قیمتی ساخته شده است. وقتی PHP با این انتخاب روبرو میشود که عملی بی معنی انجام دهد یا با یک خطا برنامه را متوقف کند، آن کار بی معنی را انجام میدهد. از نظر PHP، هرچیزی بهتر از هیچ چیز است!

Weak typing در PHP (تبدیل خودکار بین رشته ها/اعداد، و غیره) آنقدر پیچیده است که هرچقدر تلاشهای کوچکی از برنامه نویس را کاهش میدهند، ارزشش را ندارد.

PHP یک اجتماع از آماتورهاست. تعداد خیلی کمی از افرادی که آن را طراحی میکنند، روی آن کار میکنند، یا در آن برنامه نویسی میکنند، بنظر میرسد که میدانند دارند چکار میکنند (اوه خوانندهء عزیز، شما البته یک استثنای کمیاب هستید!). آنهاییکه در این زمینه رشد میکنند، تمایل دارند تا به طرف پلتفرم های دیگر بروند، و بنابراین متوسط صلاحیت کل این مجموعه را کاهش میدهند. این بزرگترین مشکل با PHP است: کوری عصاکش کور دیگر!

عملگر == در PHP بلااستفاده است:

این دو مقایسه هر دو درست ارزیابی میشوند:


"foo" == TRUE


"foo" == 0

اما مسلما حتی در PHP، صفر با true برابر نیست.

این عبارت درست ارزیابی میشود:


123 == "123foo"

اما این عبارت غلط ارزیابی میشود:


"123" == "123foo"

این مقایسه ها درست ارزیابی میشوند:


"6" == " 6"


"4.2" == "4.20"


"133" == "0133"

اما این نه:


133 == 0133

این ها درست ارزیابی میشوند:


"0x10" == "16"


"1e3" == "1000"

هر دوی اینها درست ارزیابی میشوند:


NULL < -1


NULL == 0

===========================================

منبع: بخشهایی از http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

[SZsXsZS]

البته من با تمام نظرات و استدلال های این طرف موافق نیستم. بخاطر همین فقط موارد و بخشهایی رو که بنظرم واضحا با اطمینان زیادی درست هستن انتخاب کردم.
بعضی مواردی که طرف بعنوان ضعف های PHP بیان کرده بنظر من میتونن حتی مزیت و نقطهء قوت باشن.

[hamedarian2009]

اشپیلن ورودت رو به انجمن تبریک میگم :چشمک:

[مهرداد سیف زاده]

منم مقاله رو دیدم فهمیدم این همون اشپلین دوست داشتنی هست
اگر خودشون باشن اول تبریک بسیار میگم و خوش آمدید و بعد حیف که مدیر قبلی نیست. منم صرفا برای رفع مشکل دوستان به اینجا سر میزنم و حوصله چالش رو ندارم
ولی به نظرم شما با فلسفه اسکریپتی مشکل دارید. php بر اساس فلسفه اسکریپت ساخته شده تا بر نوع داده حساس نباشه.
به هر حال لینک زیر رو هم نگاهی بندازید
http://www.killersites.com/blog/2005/scripting-vs-programming-is-there-a-difference/
https://en.wikipedia.org/wiki/Scripting_language


Scripting languages may be designed for use by end users of a program – end-user development (https://en.wikipedia.org/wiki/End-user_development) – or may be only for internal use by developers, so they can write portions of the program in the scripting language. Scripting languages typically use abstraction (https://en.wikipedia.org/wiki/Abstraction_(computer_science)), a form of information hiding (https://en.wikipedia.org/wiki/Information_hiding), to spare users the details of internal variable types, data storage, andmemory management (https://en.wikipedia.org/wiki/Memory_management).

[SZsXsZS]

نخیر دوست عزیز من با زبانهای اسکریپتی مشکلی ندارم.
زبانهای اسکریپتی دیگر غیر از PHP فراوان هستن. پایتون و جاوااسکریپت روشن ترین نمونه هاش نزد عموم برنامه نویسان است، ولی تعداد زیاد دیگری هم وجود دارن.
اما هیچکدام از این زبانهای اسکریپتی دیگر اینقدر که PHP در رفتارهای سرخود و خطرآفرین افراط کرده افراط نکردن.
تازه همون حد هم که در زبانهای اسکریپتی دیگر هست بازم بعضیاش محل مناقشه هست و مخالفت ها و استدلال های مخالفی داره.

[SZsXsZS]

به نظرم شما با فلسفه اسکریپتی مشکل دارید. php بر اساس فلسفه اسکریپت ساخته شده تا بر نوع داده حساس نباشه.
نخیر دوست عزیز من با زبانهای اسکریپتی مشکلی ندارم.
زبانهای اسکریپتی دیگر غیر از PHP فراوان هستن. پایتون و جاوااسکریپت روشن ترین نمونه هاش نزد عموم برنامه نویسان است، ولی تعداد زیاد دیگری هم وجود دارن.
اما هیچکدام از این زبانهای اسکریپتی دیگر اینقدر که PHP در رفتارهای سرخود و خطرآفرین افراط کرده افراط نکردن.
تازه همون حد هم که در زبانهای اسکریپتی دیگر هست بازم بعضیاش محل مناقشه هست و مخالفت ها و استدلال های مخالفی داره.

من خودم استفاده از عملگر == رو تقریبا بطور کامل کنار گذاشتم بجاش از === استفاده میکنم.
حتی پروژهء سیستم رجیستر و لاگین خودم رو که قبلا نوشته بودم برداشتم توی اون همه کد تقریبا تمام == ها رو به === تبدیل کردم، مگر یک مواردی که تغییرش به این سادگی نبود و کدهای دیگری هم باید بررسی و تغییر پیدا میکردن و مشکل جدی هم توش ندیدم.
ضمنا دقیقا یک مورد SQL Injection هم در برنامم شناسایی کردم که بخاطر همین عملگر بوجود آمده بود.
اصولا شما نمیتونید توی برنامه های جدی که خیلی ساده و کم حجم نباشن بصورت پیشفرض از عملگر == برای مقایسه هاتون استفاده کنید! چرا؟ چون استفاده از عملگر == میتونه به سادگی منجر به باگها و حفره های امنیتی در برنامتون بشه که پیشبینی و کنترل اینها از قبل تقریبا غیرممکنه! بخاطر اینکه رفتار عملگر == بیش از حد متنوع و پیچیده است و برنامه نویس باید برای هر مورد در ذهنش ده ها حالت رو بررسی و دقت بکنه در این باب، و این عمل در هنگام برنامه نویس سخت و زمانبر و کاملا مستعد خطاست. صرفه با اینه که از === بجای == استفاده کنیم تا نیازی به این همه دقت و صرف انرژی و متفرق شدن تمرکز برنامه نویس نباشه و در باب امنیت و باگهای برنامه ریسک نکنیم.
همونطور که این مقاله گفته، عملگر == عملا بلااستفاده شده!
انعطاف زبان برنامه نویسی و هوشمندبازی تا یه جایی یه حدی که عاقلانه باشه سودش در کل از ضررش بیشتر باشه، نه اینکه دیگه به اینجا برسه که مثل بمب هر لحظه امکان ترکوندن برنامه رو داشته باشه!!
گفتم زبانهای اسکریپتی دیگر زیاد هستن، ولی شما در هیچکدام این حد از سرخود عمل کردن و افرط رو مشاهده نمیکنید. خواستید میتونیم این نمونه ها رو در زبانهای اسکریپتی دیگری که در دسترس داریم عملا بررسی و تست کنیم تا ببینید که رفتارشون در کل معقول تر و امن تر از PHP است.

ضمنا بنده بعنوان یک متخصص در امور امنیت، دارم این نظر رو بصورت رسمی ابراز میکنم!
اگر به امنیت و کاهش باگهای برنامه هاتون علاقمند هستید، از عملگر == (و همچنین ‎!=‎) تا میتونید دیگه استفاده نکنید!

[SZsXsZS]

به نظر من تمام اینایی که گفتین نه تنها ضعف php رو نشون نمیده بلکه حتی برای php نقطه قوت محسوب میشه.

تمام؟!
یعنی جدا مثلا دوتا شرط که با هم متناقض هستن هر دو true ارزیابی میشن، بنظر شما معقوله؟
مثلا: "foo" == TRUE و "foo" == 0. چطور چیزی میتونه هم برابر true باشه و هم برابر صفر؟!
یا این: NULL < -1 و NULL == 0. چطور صفر کوچکتر از -1 میشه؟!

فکر نمیکنم توی هیچ زبان دیگه ای چنین چیزی دیده شده باشه!




عملگر == مخصوص مقادیر عددی هست و استفاده ازش برای مقایسه رشته هایی مثل "356" و "524" نمیتونه منطقی باشه و باید با تابع strcmp این رشته ها مقایسه بشن.

شما دیگه برگشتی به عصر حجر!
بابا strcmp که مال زمان زبان سی بوده!
توی زبانهای سطح بالا و بخصوص اسکریپتی و شاید بخصوص وب، من فکر نمیکنم مقایسه رشته ها با == هیچ اشکالی داشته باشه، بلکه خیلی هم طبیعی و مفیده. در پایتون و جاوااسکریپت هم همینطوره. به خودی خودش مشکلی نداره، بلکه باید اینطور باشه. ولی در تفسیر و تبدیل های خودکار نباید افراط و سرخودکاری زیادی بشه.



ممکنه جایی نیاز بشه بین اعداد 12 و 12.0 تفاوتی وجود نداشته باشه، اون موقع باید از عملگر == استفاده کرد.

بطور کلی بنظر من تبدیل خودکار رشته ها به عدد درست نیست. یعنی دارم البته اینجا درموردی صحبت میکنم که دو طرف هر دو به شکل رشته باشن. حالا اینکه یک طرف رشته باشه یک طرف عدد، بحث و تحلیل جداگانه میطلبه بنظرم.
ببینید، حالا اگر دوتا رشته هر دو محتوی عدد بودن و نه چیز دیگر، باز جای بحث و شک داره، ولی یه موردی مثل "123" == "123foo" بنظر بنده قطعا غلط و غیرقابل قبوله! هیچ شکی نیست که چنین کاری نباید انجام بشه. بعید میدونم توی هیچ زبان دیگری هم چنین چیزی دیده شده باشه. شما خودتون فکر کنید این چیزها چرا توی زبانهای دیگه دیده نشده تاحالا؟ یعنی به فکرشون نرسیده مثلا؟! البته شاید بگید خب چون PHP مخصوص برنامه نویسی وب است، ولی بازم من فکر نمیکنم حتی اینم بتونه عذر کافی باشه برای اینقدر بالا بردن احتمال باگ و حفره های امنیتی برنامه.

[SZsXsZS]

لینکی که گذاشتین رو خوندم. خیلی از بخشهاش جالب و نسبتاً هم درست بود ولی خوشبختانه توی PHP7 خیلی از این مشکلات برطرف شدن. دقت کنید که PHP مال زمانی هست که اصلاً شئ گرایی وجود نداشت و بعداً بهش اضافه شد و خیلی از امکانات رو به مرور بهش اضافه کردن و باید توی این مسیر، کاربران قبلی رو هم حفظ میکردن. خیلی از قواعد نامگذاری توی این مدت عوض شدن ولی نمیشد توابع قبلی رو هم تغییر نام داد چون دیگه کدهای قبلی روی نسخه PHP جدید کار نمیکرد. PHP مثل #C نیست چون #C دقیقاً زمانی متولد شد که شئ گرایی به اوج بلوغ خودش رسیده بود و از اول با همون استانداردها تولید شد. توی نسخه 7 خیلی از این ایرادها رفع شده ولی هنوز هم برخی جاها تناقضها و ناسازگاریهایی وجود داره که اگه میخوایم از امکانات و مزایای زیادی که PHP داره و با بی انصافی کامل توی اون مقاله ازش اسمی برده نشده بهره ببریم، ناچاریم باهاشون کنار بیایم و ازشون اطلاع پیدا کنیم که البته تمام این موارد هم توی مستندات سایت رسمی PHP بهشون اشاره شده و اینطور نیست که منبعی برای اینکه بدونیم رفتار فلان عملگر ممکنه عجیب و غریب باشه وجود نداشته باشه.

ازطرفی اومدن و گفتن ساختمانهایی که با اون جعبه ابزار ساخته شده سروته و عجیب و غریبه و در میزنی، از جا در میاد و از این حرفها. کدوم سایتی توی PHP این مدلی بوده؟ سایتهای بزرگ دنیا که با PHP ساخته شدن، واقعاً عجیب و غریبن؟ خیلی از سایتها که روزانه چندین میلیون بازدید دارن (مثل سایت رسمی کاخ سفید و امثال اون) با PHP ساخته شدن و اگه کسی اهل فن نباشه، متوجه هم نمیشه که با PHP ساخته شدن چون مشابه خیلی از سایتهای دیگه دارن بدون مشکل کار میکنن. کجای این نمونه ها، شبیه اون حرفیه که توی مقاله گفته شده؟

البته منم گفتم که با همهء نظرات طرف موافق نیستم. بنظر من همین مواردی که جدا کردم موارد کاملا روشن و جدی هستن. بقیه ایرادهایی که گرفته اونقدر مهم نیستن، مبهم و محل تردید هستن، یا حتی بعضی موارد بنظر من برعکس چیزهای خوبی هستن!
مثلا طرف به آرایه های PHP هم ایراد گرفته ظاهرا گفته مثلا نمیشه میزان حافظه ای رو که مصرف میکنن برآورد کرد بخاطر انعطاف و پیچیدگی زیادی که دارن. ولی بنظر من این ایراد مسخره ایه و انصافا آرایه های PHP بین تمام زبانهایی که تاحالا دیدم منعطف ترین ساختار رو دارن و بنوعی شاهکار هستن که توی برنامه نویسی کار آدم رو خیلی راحت میکنن آدم واقعا لذت میبره. ولی از اون طرف مثلا برآورد حافظه حالا توی این زبانهای سطح بالای اسکریپتی مگه چقدر مسئلهء ضروری و مهمی هست که طرف بهش گیر داده! بنظر من چنین حرفی یخورده مسخره میاد!! حالا اگر از 1000 نفر یکی هم نیاز به این کار داشت، بنظرم از طرق دیگری میتونه میزان حافظه رو برآورد کنه.

[us1234]

وقت اینکه متن های تایپ شده بخونم ندارم و نمیدونم چی گفتید ، فقط کدها را نگاه کردم دیدم با == مشکل دارید :

در php وقتی از == استفاده میکنید اول 2 طرف cast میشود و بعد شرط بررسی میشود .

وقتی یک رشته را با عدد 0 بررسی میکنید هر 2 از نظر کستینگ برابر است چون مقدار رشته تبدیل به int میشود که همان 0 در نظر گرفته میشود .
این مورد برای مقدارهای Boolean هم صدق میکنه

برای اینکه عمل کستینگ انجام نشود باید از === استفاده کنید یا اینکه قبل از چک کردن خودتان 2 طرف را هم نوع کنید مثلا برای int با استفاده از تابع intval()

لینک منبع
http://php.net/manual/en/language.types.type-juggling.php

[SZsXsZS]

تبدیل نوع خودکار منحصر به PHP نیست و در زبانهای دیگر هم وجود داره. بخصوص زبانهای اسکریپتی.
ولی این تبدیلات اینطور نیست همینطور هر جور دلشون بخواد باشه. اصول داره.

مثلا این مثال در جاوااسکریپت:
<script>
alert(3=="3");
</script>
نتیجه true است.
ولی این مثال:
<script>
alert(3=="3foo");
</script>
نتیجه false است.

چرا اینطوره؟
چون رشتهء اول فقط متشکل از رقم است، اما رشتهء دوم حاوی کاراکترهای غیر رقمی است و وجود رقم در ابتداش میتونه کاملا تصادفی بوده باشه.

چرا این قاعده رو پیاده کردن؟ خب چون مثل PHP اینقدر بی پروا و سرخود نبودن و فکر اینو کردن که بعیده برنامه نویس بخواد چنین چیزهایی رو با هم بصورت عددی مقایسه کنه، و اگر چنین شرایطی رخ میده، به احتمال بیشتر تصادفیه و بنابراین منطق صحیح که موجب باگ در برنامه نشه اینه که این عمل تبدیل خودکار به چنین صورتی صورت نگیره.

این فقط یه نمونه بود که خواستم درک کنید منظور چیه معیار چیه. وگرنه مثال های بیشتر هست از زبانهای مختلف، که نشون میده همه از PHP محتاط تر و معقول تر عمل میکنن.

ضمنا جاوااسکریپت هم عملگر === داره.
الان در این مثال:
<script>
alert(3==="3");
</script>
نتیجه false است.

یعنی متوجه میشیم که جاوااسکریپت و PHP از این نظر خیلی به هم نزدیک هستن. تنها فرق اینه که عملگر == در PHP هیچ محدودیتی قائل نیست و به زور هم که شده میخواد هرچی رو که دو طرف هستن تبدیل و مقایسه کنه؛ حالا کاری نداره این رفتار آیا اصلا معقول هست و به دردی میخوره، آیا در کل بیشتر سودمنده یا مضر و باعث ایجاد باگ در برنامه ها!

بنظر من این طراحی ها واقعا احمقانه هستن. چون به برنامه نویسی در کل بیشتر از اونچه که بتونن کمک کنن، آسیب میرسونن.

حال در جاوااسکریپت ما اگر بصورت صریح خودمون درخواست کنیم که رشته به عدد تبدیل بشه، مثلا با این کد:
<script>
alert(parseInt("3foo"));
</script>
نتیجه و خروجی این کد عدد 3 است.

اما نتیجهء این کد:
<script>
alert(parseInt("foo"));
</script>
NaN میباشد. یعنی میگه این رشته قابل تبدیل به عدد نیست.

این مثال نشون میده که واقعا حساب و قاعده ای این وسط وجود داره مسائلی رو در نظر گرفتن که در PHP در نظر گرفته نشدن.
اون قاعده چیه؟ در مثال اول، چون برنامه نویس خودش صریحا درخواست کرده رشته به عدد تبدیل بشه، بنابراین زبان میتونه تلاش کنه تا رشته رو به هر صورت ممکن و معناداری به عدد تبدیل کنه، و میتونه اطمینان بیشتری داشته باشه که با اینکه کاراکترهای غیررقمی هم بعد از کاراکتر رقمی وجود دارن اما برنامه نویس از این مسئله مطلع بوده و بخاطر همین از این تابع استفاده کرده.
اما جاوااسکریپت عاقل است، و در مقایسه ها (عملگر ==) اینطور مطمئن عمل نمیکنه و مثلا 3foo رو به 3 تبدیل نمیکنه، چون در اونجا درخواست صریحی از جانب برنامه نویس وجود نداره و وجود 3 در ابتدای چنین رشته ای به احتمال بیشتر تصادفی است تا اینکه واقعا معنادار باشه.
و اما در مثال دوم، مشاهده میکنیم که جاوااسکریپت حتی یک درجه از این هم محتاط تر هست و رشته ای رو که حاوی هیچ کاراکتر رقمی نیست به صفر تبدیل نمیکنه. و شما اگر فکر کنید هم، خب احتمال بیشتر اینه که برنامه نویس هم قصدش این نبوده یه همچین رشته ای به عدد صفر تبدیل بشه! این رشته رو از کجا آورده و چرا میخواد تبدیل به عدد صفر بشه؟ بهرحال هم اگر هدف برنامه نویس واقعا این بوده باشه که رشته های کاملا غیرعددی به صفر تبدیل بشن، میتونه خودش برای مقدار NaN چک کنه و اگر مقدار برگشتی NaN بود، مقدار صفر رو به متغییر بده. اینطوری عمل بصورت آگاهانه توسط خود برنامه نویس انجام میشه و ریسک رفتار غیرمنتظره و ایجاد باگ در برنامه وجود نداره.

[SZsXsZS]

وقتی یک رشته را با عدد 0 بررسی میکنید هر 2 از نظر کستینگ برابر است چون مقدار رشته تبدیل به int میشود که همان 0 در نظر گرفته میشود.
خب چرا عدد رو به رشته تبدیل نمیکنه و دو طرف رو بصورت رشته ای مقایسه کنه؟
یعنی همینطوری رندوم تصمیم گرفتن که هرجا یک طرف رشته بود و یک طرف عدد، رشته رو به عدد تبدیل کنن و دو طرف رو بصورت عددی مقایسه کنن؟
بنظر من اگر تبدیل به رشته میکرد، خیلی امن تر میبود، چون اونوقت دیگه 3foo با 3 برابر نمیشد.

[SZsXsZS]

این پست حذف شد.

[yeganemehr]

هرچیزی قیمتی داره!
قیمت راحتی کار با php، رفتار غیر معمول php هست.
شما نمیتونید زبانی رو ایجاد کنید که برای تولید متغییر ها نوع(dataType) تعریف نکنید و بعد انتظار داشته باشید تا اجرای دستورات شرطی و تغییر نوع متغیر ها همانند زبان های کلاسیک انجام بشه.

در واقع هر کس تجربه کار با "زبان برنامه نویسی" دیگری رو در کنار "زبان اسکریپت نویسی" php رو داره این واقع رو قبول داره که php حداقل جهان وب رو 10 سال به جلو پرتاب کرد.
نه به دلیل اینکه امکانات و انعطاف پذیری فوق العاده ای داره بلکه به دلیل اینکه PHP باعث شد تا استعداد های بالقوه به استعداد های بالفعل تبدیل بشه،خیلی از ما ها از جمله بنده حقیر با شوق کار با PHP وارد دنیای برنامه نویسی حرفه ای شدیم!چه بسا اگر از ابتدای کار با زبان هایی نظر c و c++ مواجه میشدیم بسیاری از ادامه مسیر پشیمون میشدیم!

فراموش نکنیم php بسیار عالی هست اما با در نظر گرفتن مسائل مختلف
php رو بهر کاری ساختند!
php مخصوص کار های چند میلیون دلاری نیست، اما میشه پروژه های چند میلیون دلاری هم باهاش اجرا کرد
php مخصوص پردازش عکس، فیلم، موزیک، پردازش اطلاعات سنگین، محاسبات طولانی ریاضی نیست، اما میشه عکس رو با gd ویرایش کرد،فیلم رو با mpeg، موسیقی رو با با چند خط کد، محسبات چند صد رقمی ریاضی رو با BC و...
PHP مخصوص طراحی برنامه های دسکتاپ نیست، ولی میشه با php-QT انجامش داد.
php مخصوص پردازش های موازی نیست ولی pthread به شما در این زمینه کمک میکنه!

PHP رو بذارید برای مواقعی که دلتون برای برنامه نویسی تنگ شده، یا وقت یا هزینه اجرای پروژه های اساسی رو ندارید


PHP مخصوص آزمایش و خطاست برای ما برنامه نویس ها و شرکت های جوان!

[SZsXsZS]

دوست عزیز اینا که گفتی هیچ ربط خاصی به موضوع مطرح شده نداشت!
درست در کل PHP زبان خوبیه بخصوص برای برنامه نویسی وب سطح کوچک تا متوسط، ولی بدون عیب هم نیست.
این مواردی که من مطرح کردم مواردی هستن که بنظر من هیچ ربطی به مزایا و فواید PHP ندارن، بلکه تازه اون رو زیر سوال میبرن، امنیت برنامه ها رو خدشه دار میکنن، و PHP اگر در آینده اینا رو اصلاح نکنه و رویهء دیگری در پیش نگیره، شاید از بابت این قضیه ضربه بخوره. خیلی از آدمهای حرفه ای بخاطر این چیزا از این زبان سویچ میکنن یا از اول طرفش نمیرن، و این چیز خوبی نیست، آدمهای حرفه ای ارزش دارن اعتبار و صلاحیت دارن باید بهشون بها داد به نصایح و تجربه هاشون توجه کرد.
اینکه شما یه شرط بذاری که 3foo رو برابر با 3 ارزیابی کنه، در برنامه نویسی چیزی نیست که نیاز بشه، و اگرم نیاز بشه خیلی کم پیش میاد، و بنابراین بیشتر از اونکه سودمند باشه باعث سردرگمی و ایجاد باگ در برنامه ها میشه. یعنی مثلا 5 امتیاز به زبان PHP کمک کنه، 15 تا جاش خرابکاری میکنه!
مثل اینکه شما فکر کن یه اتومبیل خوبی ساخته باشن در کل ماشین خوبی باشه ولی چندجاش چندتا اشکال نسبتا گنده داشته باشه. با این حال هنوزم ماشین ارزشمندیه قابل استفادس، ولی اگر طراحانش اون چندتا اشکال رو هم برطرف کنن، به نفع همه منجمله خودشون خواهد بود.
منم نمیخوام لزوما زبان PHP رو تخریب کنم، بلکه در درجهء اول میخوام اصلاح و بهتر بشه، چون خودم این زبان رو بلدم و کار میکنم و ازش لذت میبرم برام یه ابزار واقعا ارزشمنده. اگر عیب هاش رو نگیم و تعصب داشته باشیم، به هیچ جا نمیرسیم و ممکنه در آینده بازم از این خرابکاری ها بشه. چرا باید چیزی رو که خودم بیشتر از هر زبان دیگری باهاش کار کردم و توانایی دارم درش، صرفا تخریب کنم؟ من میخوام اصلاح و بهتر بشه یجور نباشه در آینده از روی اجبار و اکراه مجبور باشم با این زبان کار کنم فقط بخاطر اینکه روی بیشتر هاستها PHP هست و نه زبان دیگری!
من دقت کردم توی همین منابعی که این چند وقته از توش این مطالب رو درآوردم، بعضی ایرادهایی که گرفتن ظاهرا در نسخه های جدید PHP برطرف شده، بعضی مثالها رو تست کردم کار نکردن. خب این مگه چیز بدیه؟ خیلی هم خوبه اتفاقا. پس دست این افراد درد نکنه اینقدر جرات و صداقت داشتن از یه زبانی که اینقدر طرفدار داره ایراد بگیرن، چون اینطوری اون زبان رو از انحراف و بدتر شدن حفظ کردن و باعث بهبودش در آینده شدن.
یه نفر یجا گفت ظاهرا در PHP7 تقریبا تمام این اشکالات برطرف شدن. حالا جزییات و صحت و سقمش رو نمیدونم دیگه چون تحقیق نکردم.

بهرحال اگر طراحان PHP سرخودی و غرور بخرج بدن و این نصایح رو گوش نکنن درس نگیرن و به رویهء سابق خودشون ادامه بدن، من ترجیح میدم محبوبیت و آمار این زبان کاهش پیدا کنه تا جای کافی برای زبانهای اصولی تری باز بشه و فردا مجبور نباشم با اکراه و زور از زبانی که میدونم طراحی ناشیانه ای داره و کار کردن اصولی باهاش دردسره، فقط بخاطر اینکه روی بیشتر هاستها فقط این زبان وجود داره و تعداد برنامه نویسانش از هر زبان دیگری بیشتره، استفاده کنم!
البته همین حالا هم میشه به زبانهای دیگری مثل جاوا یا پایتون سویچ کرد، گرچه دست آدم مقداری بسته میشه حیطهء کارش محدود میشه دچار محدودیت هایی میشه بخاطر آمار کمتر پشتیبانی این زبانها.
ولی ترجیح میدم بجای این کار، ضعفهای PHP برطرف بشه. چون اینطوری برای همه منجمله خودم راحت تر و به صرفه تره.

[us1234]

خب چرا عدد رو به رشته تبدیل نمیکنه و دو طرف رو بصورت رشته ای مقایسه کنه؟
یعنی همینطوری رندوم تصمیم گرفتن که هرجا یک طرف رشته بود و یک طرف عدد، رشته رو به عدد تبدیل کنن و دو طرف رو بصورت عددی مقایسه کنن؟
بنظر من اگر تبدیل به رشته میکرد، خیلی امن تر میبود، چون اونوقت دیگه 3foo با 3 برابر نمیشد.

در یک کلام : باید از سازنده زبان php سوال کنید .

رفتار php نامعقول نیست ، نخواندن داکیومنت و دست به کد شدن افراد نامعقول است .

یک شخص ( سازمان ، گروه یا ... ) یک زبان را توسعه داده است و در این زبان قوانین و دستورالعمل هایی مشخص کرده است ، برنامه نویس باید تک تک و ریز به ریز این قوانین را بخواند و قبول کند و بعد شروع به کار بکند ، اگر از این قوانین خوشش نیومد برود سراغ یک زبان دیگه !
اینکه بگید چرا اینجا اینجوریه دقیقا مصداق این است که من از شما سوال کنم چرا روزی 3 وعده غذا میخورید ! ...

بحث های بیهوده و کشتن زمان هم برای یک برنامه نویس معنا نداره ، مگر اینکه ...

[SZsXsZS]

آدمهایی که بقدر کافی حرفه ای، با تجربه، توانمند، نشده باشن معمولا روی زبانهایی که زیاد استفاده میکنن و دوست دارن تعصب نشون میدن. و این آدما برای پیشرفت و بهبود و اصلاح اون زبان عملا مفید نیستن.
اما این حرفه ایها و آدمهای با سواد، که معمولا زبانهای بیشتری هم بلدن و قادر هستن در صورت لزوم نسبتا براحتی بجای این زبان از زبان دیگری هم استفاده کنن کارشون رو راه بندازن یا کلا سویچ کنن هستن که از زبانی که خودشون دوستش دارن، براشون ارزشمنده، و ازش زیاد استفاده میکنن ایراد میگیرن.
واقعا ایراد گرفتن این آدما این وقتا بطور معمول از تعریف و تمجید و دفاع کورکورانه و تعصب آدمهای غیرحرفه ای فاقد صلاحیت کافی خیلی مفیدتره، حتی برای آیندهء کاری همون غیرحرفه ایها و متعصبان.
PHP هم تاحالا خودش رو به مرور اصلاح کرده. شک نکنید اگر کله شق بازی زیادی درمیاورد، آیندهء خودش در خطر بود شاید الان آمار استفاده ازش به میزان قابل توجهی کمتر بود.
خوشبختانه PHP از خودش یک مقدار حداقلی از اصلاح و پذیرش اشتباهات رو هم که شده نشون داده تاحالا. این قضیه قدمت زیادی هم داره. مثلا اونایی که قدیما با PHP کار کرده باشن باید داستان چیزی بنام register globals یادشون باشه، که یک ویژگی مهم و پر استفاده در زبان PHP محسوب میشد که عدهء زیادی طرفدارش بودن، ولی در نهایت تصمیم به حذفش گرفته شد و الان دیگه در PHP وجود نداره. این برای PHP تصمیم سختی بود که این ویژگی رو دور بندازن، اما این کار رو کردن! چرا؟ اگر واقعا این ویژگی طراحی عاقلانه ای بود و در کل سودش از ضررش بیشتر بود، قاعدتا نباید این کار رو میکردن. این نشون میده که امکان اشتباه در طراحی همیشه وجود داره و قبلا نمونش رخ داده.

[SZsXsZS]

در یک کلام : باید از سازنده زبان php سوال کنید .

رفتار php نامعقول نیست ، نخواندن داکیومنت و دست به کد شدن افراد نامعقول است .

یک شخص ( سازمان ، گروه یا ... ) یک زبان را توسعه داده است و در این زبان قوانین و دستورالعمل هایی مشخص کرده است ، برنامه نویس باید تک تک و ریز به ریز این قوانین را بخواند و قبول کند و بعد شروع به کار بکند ، اگر از این قوانین خوشش نیومد برود سراغ یک زبان دیگه !
اینکه بگید چرا اینجا اینجوریه دقیقا مصداق این است که من از شما سوال کنم چرا روزی 3 وعده غذا میخورید ! ...

بحث های بیهوده و کشتن زمان هم برای یک برنامه نویس معنا نداره ، مگر اینکه ...

متاسفانه شما خیلی عجولانه و بدون خوندن کامل و دقیق و درک استدلال ها و شواهد، فقط میاید یکسری حرف نامربوط میزنید!
اینهایی که میگید کاملا نامربوط و بی معنی هستن. چون در این تاپیک استدلال ها و شواهد کافی ارائه شده که داستان چیز دیگری هست و مبنای کافی داره. تمام پست ها رو از اول دقیق بخونید؛ حرف من تنها هم که نیست، بلکه خیلی منابع و اشخاص دیگر پشتش هستن.
اگر دقت کنید همین پست آخر من به تنهایی پاسخ کافی برای شماست!
شما میگی اشتباهی وجود نداره و فقط بحث داکیومنت خوندن و خوش اومدن یا نیامدن هست، ولی تغییرات انجام شده در طول زمان روی خود زبان PHP توسط طراحانش خلاف اینو ثابت میکنن! اگر اشتباهی نبود که تغییر و حذف ویژگیهای موجود هم نباید رخ میداد و فقط چیزهای جدید اضافه میشدن.
نه دوست عزیز، بروز اشتباهات در طراحی هر چیزی، منجمله در زبانهای برنامه نویسی، همیشه امکانش هست. هیچکس نمیتونه اینو انکار کنه. ربطی هم به داکیومنت داشتن و خوندن داکیومنت ها نداره! یه ویژگی که حاصل طراحی اشتباه هست داکیومنت هم داره و میخونیم، ولی بهرحال طراحی از اساس اشتباه بوده!
گاهی هم البته طراحی خیلی هم اشتباه نیست، میشه گفت میتونست بهتر باشه، ولی اول اون بهترین طراحی به ذهنشون نمیرسه و به مرور با تجربه و پیشرفت و خبره شدن بهش میرسن. بعضی وقتا هم البته بخاطر پرهیز از کندی و پیچیدگی طراحی و پیاده سازی زبان هست که ساختارهایی رو که لزوما بهترین حالت از نظر فنی نیستن انتخاب میکنن.

[SZsXsZS]

من یک بار یک مصاحبه ای با خالق زبان سی++ رو میخوندم.
ازش پرسیده بودن اگر الان از اول میخواستی زبان سی++ رو طراحی کنی آیا همینطور درستش میکردی؟
ایشون جواب داده بود این چه حرفیه، اون زمان تجربیات الان وجود نداشتن و من میتونستم این زبان رو بهتر طراحی کنم اگر تجربیات و آگاهی الان رو داشتم، ...
حالا کامل و دقیق یادم نیست، ولی مضمون کلیش همین بود.

بعد حالا شما اومدی همینطور نه میخونی نه فکر میکنی و فقط کورکورانه یه مشت حرفای کلیشه ای و دفاعیات سطحی و مغلطه وار تحویل میدی! انگار که بروز اشتباه در طراحی زبان برنامه نویسی غیرممکنه یا هیچکس حق نداره درموردشون حرفی بزنه، یا باید همونطور که هست قبول و استفاده کنه یا بره دنبال زبان دیگه!!

آخه اینم شد حرف و منطق که شما داری؟
واقعا که خجالت آوره.
اینطور فکر کردن و رفتار و حرف زدن سطحی و متعصبانه از آدمهای باسواد و اهل علم و منطق نباید دیده بشه.

[Unique]

دوست عزیز من نمیدونم اصلا چرا بحث میکنی ! یعنی اصلا قبول که PHP چنین مشکلاتی داره. راستش شاید مثلا خود بنده تا حالا درگیر این بی منطقی PHP مخصوصا این مشکلات امنیتی که میگین نشدم یا اینکه بر اساس تجربه ورودی ها را خوب فیلتر کردم و حواسم بوده دارم چیکار میکنم. اما اگه از روی دلسوری و علاقه به زبان PHP و بهتر شدنش داری این بحث ها را میکنی به نظر من جاش اینجا نیست.

اینجا مشکلات دوستان توی Syntax و عدم آگاهی از قابلیتهای PHP بیشتر خلاصه میشه و اینی که شما میگی زیاد جنبه آموزشی نداره ، یعنی توی کتاب های معتبر و اسناد خود سایت php.net هم در مورد این رفتار های PHP کامل توضیح داده شده. حالا اگه قصد خیر داری و فکر میکنی این ها Bug هستند یا باید در نسخه های بعدی اصلاح بشن توی این بخش از سایت php.net میتونی پیگیری کنی (https://bugs.php.net/).

اگه قصد منصرف کردن کاربران این تالار از یادگیری و استفاده از PHP را دارین خوب من بحثی ندارم و واگذار میکنم به مدیر تالار.

[SZsXsZS]

دوست عزیز من نمیدونم اصلا چرا بحث میکنی !
بحث چی؟
من یکسری اطلاعات دادم، دیگرانم میان ایراد میگیرن و حرفهای نامربوط و مغلطه میندازن، منم جواب میدم.


یعنی اصلا قبول که PHP چنین مشکلاتی داره.
مسلم بدونید که داره.


راستش شاید مثلا خود بنده تا حالا درگیر این بی منطقی PHP مخصوصا این مشکلات امنیتی که میگین نشدم یا اینکه بر اساس تجربه ورودی ها را خوب فیلتر کردم و حواسم بوده دارم چیکار میکنم.
زیاد مطمئن نباشید. خیلی موارد رو آدم خودش به این راحتی ها متوجه نمیشه. با فیلتر کردن هم همهء مشکلات حل نمیشن. شما متوجه ذات مسئله و ابعاد ممکن اون نیستید.
دیگه از من که متخصص امنیت هستم، نه به ادعای خودم، بلکه خیلی ها اذعان دارن، بینش و مهارت بیشتری دارید در امور امنیتی؟ من خودم بعد از این همه سال و تخصص در امنیت تازه متوجه یکسری از این موارد شدم (البته قبلا شنیده بودم ولی دقت و توجه کافی نداشتم) و مثلا توی پروژهء سیستم رجیستر و لاگینم بصورت پیشفرض همه جا از == استفاده کرده بودم، که بعدا که دقت کردم روی این مسئله متوجه شدم اشتباهه و تقریبا همهء == ها رو با === جایگزین کردم. ضمنا بگم دقیقا یک مورد SQL Injection رو هم در برنامم شناسایی کردم که بخاطر استفاده از عملگر == بوجود اومده بود.
یکسری باگها هست وقتی با آگاهی و توجه قبلی بری بخصوص کد منبع برنامه رو بخونی متوجه میشی. همینطوری عادی و در جریان کدنویسی و تست مشخص نمیشن. ممکنه برنامتون هم هیچوقت هک نشه کسی متوجه این موارد نشه یا کسی که دانش و مهارت کافی داره نیاد سراغ هک کردن برنامهء شما، ولی این ضعف ها بهرحال وجود دارن.


اما اگه از روی دلسوری و علاقه به زبان PHP و بهتر شدنش داری این بحث ها را میکنی به نظر من جاش اینجا نیست.
پس کجاست؟
البته احتمالا تالار امنیت بهتر باشه. ولی این قضیه فقط به امنیت مربوط نمیشه و میتونه باگهای غیرامنیتی هم در برنامه ایجاد کنه.
چیزی که من دارم میگم اینه که اگر میخواید برنامه هاتون باگ های پنهان پیدا نکنه، از عملگر == تا میتونید استفاده نکنید و بجاش از === استفاده کنید. بقیهء مطالب هم استدلال و نمونه کد و شواهد و دلایل برای علت این مسئله هستن.


اینجا مشکلات دوستان توی Syntax و عدم آگاهی از قابلیتهای PHP بیشتر خلاصه میشه و اینی که شما میگی زیاد جنبه آموزشی نداره ، یعنی توی کتاب های معتبر و اسناد خود سایت php.net هم در مورد این رفتار های PHP کامل توضیح داده شده.
توضیح داده، ولی اکثریت افراد رفرنس زبان PHP رو کامل نمیخونن. شما خودت تمامش رو خوندی یعنی؟ ضمنا من خودم یه زمانی رفرنس PHP رو که چند هزار صفحه بود کامل خونده بودم، ولی یا به این موارد اشارهء صریحی نشده بود یا من دقیقا متوجه ابعادش نشدم بهرحال و غفلت کردم. از اون طرف فکر نمیکنم در جایی از سایت PHP شما این توصیه رو بصورت صریح پیدا کنید که گفته باشه «از عملگر == تا میتونید استفاده نکنید و بجاش از === استفاده کنید.»، بلکه فقط توضیح داده رفتار هر عملگر چطوریه. مسلما اکثریت افراد به این سادگی ها متوجه تبعات این رفتارها نیستن، چون مقداری پیچیده و ظریف است مطلب.


حالا اگه قصد خیر داری و فکر میکنی این ها Bug هستند یا باید در نسخه های بعدی اصلاح بشن توی این بخش از سایت php.net میتونی پیگیری کنی (https://bugs.php.net/).
دوست عزیز، قبلا گفتم بازم میگم، باگ با طراحی بد تفاوت میکنه. باگ یعنی چیزی غیرعمدی و چیزی که موقع ایجادش ازش خبر ندارن، ولی طراحی بد چیزی از ابتدا دانسته است و میشه گفت یک تصمیم و ذهنیت از ابتدا اشتباه هست که بعدا معلوم میشه ذهنیت و تصمیم اشتباهی بوده. البته بهرحال باگ و طراحی بد هر دو حاصل ضعف و خطای انسانی هستن و از این نظر به هم شباهت دارن.


اگه قصد منصرف کردن کاربران این تالار از یادگیری و استفاده از PHP را دارین خوب من بحثی ندارم و واگذار میکنم به مدیر تالار.
والا ما جز مطالبی مستند و مستدل و مهم چیزی ندادیم! حالا چون یه عده تعصب دارن یا اصلا نمیخونن درک نمیکنن و با عجله و عصبانیت میان یه مشت حرفهای کلیشه ای سطحی و نامربوط و مغلطه میندازن وسط و بحث میشه، مطالب من کسی رو منحرف میکنه؟ این دیگران هستن که از ابتدا خودشون منحرف هستن!

ضمنا قضاوت و تصمیم رو بذارید به عهدهء خوانندگان! مسلما خیلی ها، بخصوص مبتدی ها، آگاه و متوجه نسبت به ابعاد و جدیت این موارد نیستن. پس افرادی مثل من بهشون آگاهی میدن، شاید طرف تصمیم بگیره به زبان دیگری سویچ کنه اصلا! کار خلافیه بنظر شما؟ من قبلا گفتم بازم میگم اگر طراحان PHP بیش از حد سرخود عمل کنن و گند بزنن به اصول حرفه ای این رشته، پس باید رسواشون کنیم و بر علیه اونا عمل کنیم تا جلوشون گرفته بشه. این در کل و طولانی مدت به نفع جامعهء برنامه نویسی و اصلا تمام جهان است، چون بهرحال این زبانی هست که بخش عمده ای از سرویسها و سایت های دنیا رو داره اجرا میکنه. ما حق داریم، هر حرفه ای و متخصص و آدم با تجربه ای حق داره، حتی یک مبتدی هم حق داره در این باب حرفش رو بزنه. طراحان PHP که خدا و وحی منزل نیستن. اونا هم آدم هستن و ضعف و نقصها و اشتباهات خودشون رو دارن. ضمنا نمیشه مطلقا به حسن نیت هیچکس اعتماد کرد؛ شاید دلایل دیگری هم در پشت پرده باشن.

[Unique]

نمیدونم چرا جملات من را جدا میکنی در صورتی که کلا یک مفهوم کلی بیشتر نداشت.

چیزی که شما میگین کاملا درسته ، یعنی اگه میخواین هیچ اشتباهی در زمان بررسی تساوی دو مقدار پیش نیاد نباید از == استفاده کنید چون php میاد و type conversation انجام میده و نتایجی داره که شاید در زمان کدنویسی اصلا محسوس نباشه و توی برنامه شما Bug یا حفره امنیتی ایجاد کنه.

اینکه PHP توی Type Conversation یا همون Type Casting جاهایی خیلی عجیب و غریب رفتار میکنه کاملا درسته ، البته این چیزی نیست که پنهون باشه و خیلی توی نت در موردش بحث شده :

یک سوال و جواب خیلی خوب در این زمینه (http://stackoverflow.com/questions/80646/how-do-the-php-equality-double-equals-and-identity-triple-equals-comp)
یک توضیح خوب دیگه (http://stackoverflow.com/questions/12892847/comparing-int-to-string-causes-weird-results-in-php)
توضیحات خیلی خوب سایت php.net در مورد type casting و type juggling (http://php.net/manual/en/language.types.type-juggling.php)
جدول مقایسه تبدیل ها در php (http://php.net/manual/en/types.comparisons.php)
مطالعه Coparision Operator هم از اوجب واجبات هست (http://au.php.net/manual/en/language.operators.comparison.php)

دفاع مطلق از جاوا اسکریپت هم در این زمینه جای حرف داره ، اینجا یک سوال و جواب خیلی خوب با Reference های عالی (http://stackoverflow.com/questions/359494/does-it-matter-which-equals-operator-vs-i-use-in-javascript-comparisons)

نتیجه اینکه اگه میخواین از این Type Conversation ها دور بمونید باید از === استفاده کنید. البته اولش کمی گیج میخورین چون خیلی از مواردی که == درست بود الان درست نیست و باید خودتون اگه لازمه Type Conversation انجام بدین.

کل صحبت من با دوست عزیز این هست که وقتی واقعیتی را بیان میکنیم نباید به شکلی استدلال کنیم که کل یک زبان را زیر سولا ببره ، اینکه روش استفاده ما از Syntax به شکلی بوده که ما را دجار حفره امنیتی یا Bug کرده دلیل نیست همه با این مشکل روبرو میشن ،‌مثلا من توی کتم نمیره == اینطور که شما میگین مشکل SQL Injection ایجاد کنه ،‌ اگه چنین مشکل ایجاد کرده به این خاطر بوده که شما یا به درستی فیلتر نکردین ، Escape نکردین یا بهتر از اون از Prepared Statement ها استفاده نکردین ولی دارین تقصیر را گردن == میندازین !

[charcharkh]

حالا نمیدونم چرا اینقدر با تمام قوا نقد زبان php رو میکنید !!!! ما که متوجه نشدیم هدف اصلی شما چیه ؟:افسرده: ولی اگر بدنبال رفع باگ هستید خوب اون جای خودشو داره همانطور که
Unique (http://barnamenevis.org/member.php?11933-Unique) گفت اگر هم بدنبال مسله دیگری هستید که هیچ .

[SZsXsZS]

چیزی که شما میگین کاملا درسته ، یعنی اگه میخواین هیچ اشتباهی در زمان بررسی تساوی دو مقدار پیش نیاد نباید از == استفاده کنید چون php میاد و type conversation انجام میده و نتایجی داره که شاید در زمان کدنویسی اصلا محسوس نباشه و توی برنامه شما Bug یا حفره امنیتی ایجاد کنه.
الحمداله که بالاخره یه حرف حساب زدی.


اینکه PHP توی Type Conversation یا همون Type Casting جاهایی خیلی عجیب و غریب رفتار میکنه کاملا درسته
پس شما قبول داری که رفتارش عجیب و غریب و غیرمنتظره است برای اکثریت برنامه نویسان!
حرف هم همینه که این رفتار عجیب و غریب و غیرمنتظره عملا چه سودی داره آیا مجبور بودن بذارن و به چه دلیلی؟ آیا سودش در کل از ضررش بیشتره؟
چون ما در هیچ زبان دیگری مشاهده نمیکنم که در این مسئله اینقدر افراط شده باشه و تا این حد موارد مشکل و رفتارهای غیرمنتظره و در نتیجه ایجاد باگهای پنهان در برنامه یا مشکلات موقع برنامه نویسی، زیاد باشه.


البته این چیزی نیست که پنهون باشه و خیلی توی نت در موردش بحث شده :

یک سوال و جواب خیلی خوب در این زمینه (http://stackoverflow.com/questions/80646/how-do-the-php-equality-double-equals-and-identity-triple-equals-comp)
یک توضیح خوب دیگه (http://stackoverflow.com/questions/12892847/comparing-int-to-string-causes-weird-results-in-php)
توضیحات خیلی خوب سایت php.net در مورد type casting و type juggling (http://php.net/manual/en/language.types.type-juggling.php)
جدول مقایسه تبدیل ها در php (http://php.net/manual/en/types.comparisons.php)
مطالعه Coparision Operator هم از اوجب واجبات هست (http://au.php.net/manual/en/language.operators.comparison.php)

اینا که گذاشتی همه منابع انگلیسی هستن و تاجاییکه دیدم اکثرشون فقط رفتار این عملگرها رو توضیح دادن.
اولا بنظر شما چند درصد از کاربران همین تالار، بخصوص مبتدی ها، میتونن این منابع رو بخونن؟ دوما حتی اگر بخونن، چند درصدشون اینقدر دقت و بینش و تجربه دارن که به این راحتی ها متوجه تمام تبعات این مسئله بشن؟ توی هیچکدام از این منابع ندیدم توصیهء من رو گفته باشه، یعنی نگفته بصورت پیشفرض همه جا سعی کنید از عملگر === استفاده کنید. این نکتهء مهمیه! چرا؟ چون شما با استفادهء پیشفرض از عملگر == همیشه شانس زیادی وجود داره که بالاخره یک جایی در برنامون باگ و حفره ای ایجاد بشه بدون اینکه خودتون متوجه بشید؛ حتی برای افراد آگاه و با تجربه و با دقت در این امر هم این مسئله همیشه احتمال زیادی داره، چون واقعا سخته این همه حالت و استثناء و رفتارهای غیرمنتظره رو همیشه موقع کدنویسی حضور ذهن داشته باشی و برای هر مورد بررسی کنی ببینی آیا توی متغییرها و کد شما پیش میاد یا نه. این کار اصولا تمرکز برنامه نویس رو از بین میبره، و وقت و انرژیش رو هدر میده، و تازه با این حال بازم نمیتونه تضمین خیلی زیادی بده که چیزی این وسط از زیر دست در نره! موقع برنامه نویسی شما نباید اینقدر حواستون به یک مشت استثناء و چیزهای عجیب و غیرمنتظره و عملا بی فایده باشه، بلکه باید روی مسائل مهمتر و سودمندتر و اصل منطق و برنامهء خودتون تمرکز کنید.


دفاع مطلق از جاوا اسکریپت هم در این زمینه جای حرف داره ، اینجا یک سوال و جواب خیلی خوب با Reference های عالی (http://stackoverflow.com/questions/359494/does-it-matter-which-equals-operator-vs-i-use-in-javascript-comparisons)
من دفاع مطلق از جاوااسکریپت نکردم، بلکه اون رو بعنوان مثالی آوردم که زبان های دیگر در این باب محتاط تر عمل میکنن و در نتیجه میزان رفتارهای غیرمنتظره خطرناک در اونا خیلی کمتره. حالا چرا PHP اینقدر اصرار داشته در این وادی اینقدر افراط کنه، من نمیدونم، شما بگید، و چرا هیچ زبان دیگری این کار رو نکرده، آیا طراحی اونا همینطور دلبخواه و سلیقه ای یا رندوم بوده؟ این وسط PHP بین تمام زبانهای دیگری که من دیدم یک استثناء است، و من دلیل این استثناء رو متوجه نمیشم! فقط بحث جاوااسکریپت نیست، بلکه شما برو هر زبان درست و حسابی دیگری رو که سراغ داری بررسی کن ببین. ولی من جاوااسکریپت رو بخاطر دم دست بودن و راحت بودن و شناخته شدنش انتخاب کردم، و ضمنا میشه گفت یجورایی از این نظرها تاحد زیادی به PHP شباهت داره، ضمنا حیطهء کارش هم بهرحال در وب هست (هرچند سمت کلاینت) و شاید این شباهت به همین دلیل باشه.

ضمنا در این منبع که گذاشتید، همه رو کامل و با دقت نخوندم، ولی ظاهرا بحث صرفا درمورد پرفرومنس هست میگه سرعت === از == بیشتره در جاوااسکریپت (طبیعی هم هست چون === عمل تبدیلات نوع رو انجام نمیده). حالا این چطوری چه ربطی به بحث ما داره؟
انتظار میره در تمام زبانهایی که این دو عملگر یا مشابه اونا رو دارن، سرعت === بیشتر باشه (منجمله در PHP). پس طبیعیه که وقتی شما نیازی به تبدیلات خودکار == ندارید میتونید بجاش از === استفاده کنید تا سرعت کد افزایش پیدا کنه (هرچند من فکر میکنم این افزایش سرعت نسبتا جزییه و بنابراین توی اکثر برنامه ها عملا مهم نیست).


کل صحبت من با دوست عزیز این هست که وقتی واقعیتی را بیان میکنیم نباید به شکلی استدلال کنیم که کل یک زبان را زیر سولا ببره
من بخشی از طراحی یک زبان رو زیر سوال بردم.
کل زبان رو فکر نمیکنم زیر سوال ببره، کما اینکه من خودم گفتم فقط مواردی رو که درست میدونستم انتخاب کردم و یکسری موارد دیگر رو نه، و مثلا از آرایه های PHP تعریف و تمجید هم کردم (برخلاف اون منبع که زیر سوال برده بود). در کل هم میگم هنوزم زبان PHP زبان خوب و مفیدیه و شخصا ابزار دم دست و مورد علاقه ای برای منه. ولی من میگم یکسری تصمیمات طراحی واقعا عجیب و ناشیانه هم درش دیده میشه که هنوز درمورد علتشون مطمئن نیستن! چطور کسانی که چنین زبان خوب و موفقی رو طراحی میکنن، چنین طراحی های ناشیانه ای رو مرتکب میشن؟ این مسئله برای من به شخصه عجیبه و محل سوال و شک.
بهرحال ما باید این موارد رو بشناسیم و مطرح کنیم و بگوش برسانیم، نه اینکه انکار و ماست مالی کنیم و تعصب به خرج بدیم! این کار در کل و در نهایت به نفع هیچکس نخواهد بود.


اینکه روش استفاده ما از Syntax به شکلی بوده که ما را دجار حفره امنیتی یا Bug کرده دلیل نیست همه با این مشکل روبرو میشن
چرا Syntax باید طوری باشه که عجیب و غیرمنتظره باشه و نیاز به یادگیری و دقت بیشتری داشته باشه (نسبت به زبانهای دیگر)، و اینقدر احتمال خطای انسانی رو بالا ببره؟ این بقول شما Syntax، واقعا شما بگو به چه علتی چه ضرورتی چه سودی داشته که از این همه هزینه و نتایج منفیش بیشتره؟
بله بقول طرف گفته شما با زبان Brainf*uck (https://en.wikipedia.org/wiki/Brain****) هم میتونی برنامه بنویسی. ولی نیاز به زحمت و دقت خیلی زیادی داره. و زبان Brainf*uck رو مسلما برای استفاده های واقعی و جدی درست نکردن! دلیلی نداره یک زبان رو بیخود سخت کنیم و بعد بگیم خب برنامه نویس باید آگاه باشه و دقت کنه و رفرنس رو بخونه تا بتونه توش برنامه های بدون مشکل بنویسه.

در طراحی زبان همینطور دلبخواه و سلیقه ای نیست که هرچیزی رو هرجور خواستن بی دلیل و توجیه درست کنن. بلکه ساختاری که طراحی میکنن رفتاری که دارن باید توجیه داشته باشه باید همهء پارامترها رو حساب کنن سبک و سنگین کنن و بحساب بیارن، این ساختار چقدر نیاز به یادگیری داره چقدر استثناء و رفتار غیرمنتظره (gotcha (https://en.wikipedia.org/wiki/Gotcha_%28programming%29)) داره، چقدر یادگیری اون سخته چقدر زمان میبره هزینه داره، و در مقابل اینها در کل چه مزیت بیشتر چه هدفی داره که باید اینطور باشه چه ضرورتی داره چطوری توجیه میشه، چرا از یک ساختار و رفتار راحتتر برای یادگیری و راحت تر و امن تر در موقع کدنویسی استفاده نکنیم بجاش؟

این نیست که شما هرجور میخوای درست کنی و جواب قانع کننده ای هم برای این سوالات نداشته باشی، بعد رفرنس و داکیومنت درست کنی بگی همینه که هست خب رفرنس رو بخونید و دقت کنید!
یک زمانی هم هست طراحان فکر میکنن یه چیزی توجیه کافی داره، دلایل خودشون رو میارن واسش، ولی بعدا در عمل ثابت میشه که اشتباه کردن و اون طراحی در عمل بیشتر از اونکه سود داشته باشه هزینه و خسارت ببار میاره. این مسئله ای بود که به وضوح درمورد register globals دیده شد و بخاطر همین از نسخه های بعدی PHP به مرور حذفش کردن. طراحان PHP برای register globals هم توجیه و دلایل خوشون رو میاوردن و دفاع میکردن ازش، و همچنین این ویژگی حتی طرفداران زیادی هم بین برنامه نویسان داشت، ولی من شخصا از همون اول از طراحی چنین ویژگی ای شگفت زده و میشه گفت عصبانی شدم و بد و بیراه گفتم بهشون، چون میفهمیدم توی برنامه نویسی چه مشکلات و هزینه های زیادی ایجا میکنه در ازای یک مزایای سطحی و کوچکی که میده.
مسئلهء عجیب و شک برانگیز برای من اینه که اشتباهات ناشیانه در طراحی زبان PHP، فقط یک بار رخ ندادن، بلکه از ابتدا دیده و تجربه شدن، ولی با این حال بازم اشتباهات ناشیانهء دیگری رو مرتکب شدن! واقعا چه کس یا کسانی چطوری این تصمیمات طراحی رو میگیرن، مسئلهء جالبیه! گاهی فکر میکنم شاید یک نفر خاص نفوذ زیادی داره و یجورایی تاثیر دیکتاتور مابانه ای در طراحی PHP داره و نظرش در نهایت اعمال میشه، و اون شخص ولی نمیدونم چرا اینقدر در این موارد ناشیانه عمل میکنه! آیا تخصص و سواد و بینش کافی نداره، آیا خل و چله، احمقه، آیا قصد و عمدی به دلایل دیگری در کاره؟!!

البته بهرحال در این مقاله هم اون منبع اشاره کرده و حتی از مستندات رسمی خود پی اچ پی نسخهء 2 نقل قول و سند آورده که پی اچ پی حداقل در ابتدا برای نوشتن برنامه های ساده و مختصر و کم اهمیت توسط افرادی که در برنامه نویسی تخصص ندارن و حرفه ای نیستن طراحی شده! شاید نکته همین باشه. البته الان پی چی پی رو دیگه نمیشه گفت زبانی برای غیرمتخصص ها و کارهای کوچک و ساده و کم اهمیت، ولی بهرحال اون هدف و ریشهء اولیه شاید در یکسری اشکالات الانش هم بی تاثیر نباشه.

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


مثلا من توی کتم نمیره == اینطور که شما میگین مشکل SQL Injection ایجاد کنه ،‌ اگه چنین مشکل ایجاد کرده به این خاطر بوده که شما یا به درستی فیلتر نکردین ، Escape نکردین یا بهتر از اون از Prepared Statement ها استفاده نکردین ولی دارین تقصیر را گردن == میندازین !
خب در این مورد حق با شماست که نمونه کد و سند بخواید. چون به ذهنتون نمیرسه که چطور میتونه اینطور بشه.
من باید سرفرصت بگردم اون کیس رو پیدا کنم و براتون بذارم و روش قضاوت کنیم ببینیم آیا واقعا تقصیر من بوده یا نه.
ولی غیر از این موارد متعدد برای دیگران هم پیش آمده (البته نه SQL Injection)که == باعث باگ و حفره های غیرمنتظره در برنامه هاشون شده. درمورد اونا چی میشه گفت؟

[SZsXsZS]

من توی کتم نمیره == اینطور که شما میگین مشکل SQL Injection ایجاد کنه ،‌ اگه چنین مشکل ایجاد کرده به این خاطر بوده که شما یا به درستی فیلتر نکردین ، Escape نکردین یا بهتر از اون از Prepared Statement ها استفاده نکردین ولی دارین تقصیر را گردن == میندازین !
ببین من یه مثال میارم برات (مورد خودم که بهش اشاره کرده بودم نیست چون پیدا کردنش سخته، اما اینم بنظرم مثال خوبیه):

<?php

error_reporting(E_ALL);
ini_set('display_errors', '1');

$sort_cols=array(1, 3, 6);

$_GET['sort_col']='3 sql injection...';

if(in_array($_GET['sort_col'], $sort_cols)) $sort_col=$_GET['sort_col'];
else $sort_col='nothing';

echo "sort_col: $sort_col";

?>
الان این کد ساده و مختصر کارش چیه؟ یک پارامتر URL رو میگیره، که این پارامتر در اصل قراره شماره ستونی باشه که نتایج یک کوئری select بر اساس اون مرتب میشن.
خب حتما میدونی که white list (لیست سفید) دیگه امن ترین روش ولیدیت کردن وردیهای کاربره. یعنی شما یکسری مقدار فیکس شده رو مشخص میکنی میگی اگر ورودی کاربر یکی از اینها بود قابل قبوله، والا غیرقابل قبوله. در هر منبع امنیت هم بخونی اینو گفته که لیست سفید امن ترین روش ولیدیت کردنه.
پس اینجا برنامه نویس از امن ترین روش ولیدیت ورودی کاربر استفاده کرد و منطقا دیگه نیازی به هیچ کار دیگه ای مثلا Escape کردن ورودیها نداره.
ما شماره ستون های مجاز برای مرتب کردن نتایج کوئری رو توی لیست سفید خودمون (sort_cols) قرار دادیم.
اما شما اگر این کد رو اجرا کنی میبینی که رشتهء ‎3 sql injection...‎ رو بعنوان قابل قبول میپذیره.
جالب اینکه برنامه نویس هیچ جای کد از == هم استفاده نکرده! یعنی عمرا به این سادگی ها فکرش به سمت این قضیهء == و === نمیره.
ولی پس چرا اینطور شد؟ مشکل در کجا بود؟
مشکل در اونجا بود که تابع in_array بصورت پیشفرض از == برای مقایسهء مقدارها استفاده میکنه. و طبیعتا این چیزیه که به این سادگی به ذهن برنامه نویس نمیرسه و نسبت بهش حضور ذهن نداره.
البته میتونیم بگیم اشتباه از برنامه نویس بوده که شماره ستون ها رو بصورت عددی مشخص کرده، و باید اونا رو بصورت رشته توی کوتیشن میذاشت، ولی خب بنظر من سخته بگیم این اشتباه واضحیه و همهء تقصیر گردن برنامه نویسه، چون اینا بهرحال شماره ستون هستن (یعنی عددن) و حتی توی کوئری هم شما همونطور بدون کوتیشین اونا رو درج میکنی بطور معمول (و کسی هم از این بابت به شما ایرادی نمیگیره)، و از اون طرف مشابه این کد توی هر زبان دیگه ای اگر بود چنین مشکلی پیش نمیامد و مشابه همین کد در زبانهای دیگر بدون مشکل بحساب میاد و فکر نمیکنم کسی بهش ایرادی بگیره! اصلا فلسفهء تبدیل نوع خودکار و عملگر == در اینطور زبانهای سطح بالا و بخصوص اسکریپتی هم همینه که کار برنامه نویس کم بشه و مدام نیاز به cast کردن بصورت دستی یا کوتیشین گذاشتن در جاهایی که ضرورت نداره نداشته باشه. ولی در PHP این تبدیلات خودکار اونقدر بی پروا و خطرناک هستن که عملا سودمندی استفاده از این امکانات رو از بین بردن، چون شما بهتره ازشون استفاده نکنی تا اینکه ریسک ایجاد باگ و حفره های مختلف براحتی رو به جون بخری! عقل و تجربهء من یکی که اینو میگه، شما رو نمیدونم.
بخاطر همین من کلا استفاده از این عملگر رو کنار گذاشتم (https://github.com/ferchang/reg8log/commit/1c05b5d28de2d7b12dea8920d6624896a80b059f) تا دیگه نخواد اینقدر وقت و انرژی و دقت و تمرکزم روی این مسائل و خطرات صرف بشه و با این وجود هیچوقت هم نتونم اطمینان زیادی داشته باشم که چیزی از زیر دستم در نرفته باشه.
البته دروغ نگم من هنوزم جاهایی از این عملگر ممکنه استفاده کنم، ولی فقط موارد خاص و وقتی که اطمینان بالایی داشته باشم که خطری پیش نمیاد و وقتی مزیت استفاده ازش زیاد باشه. مثلا در یکسری مواردی که با ورودیهای کاربر سر و کار نداریم و یکسری مقادیری هست که توی برنامهء خودمون و دست خودمونه و همیشه مقدارهای مشخص و محدودی دارن. در اینطور موارد خب آدم همون کوتیشین اینها رو هم نخواد تایپ کنه یا نخواد یه جاهایی cast دستی بکنه خودش یه مزیته.

[SZsXsZS]

اصلا این PHP یه رفتارهایی پیاده کرده که آدم مخش سوت میکشه نمیفهمه چرا یعنی چی از کجا آورده به چه دردی میخوره!
یکی اینا رو واسه من روشن کنه!!
توی زبانهای دیگه تبدیل نوع خودکار هست، ولی معقول تر و محتاطانه تر. اینه که هیچوقت یه چیزی مثل ‎3 sql injection برابر با 3 شمرده نمیشه.
چیز دیگه ای که به همین نسبت یا حتی بیشتر عجیبه، اینه که حتی وقتی ما دو طرف دو تا رشته داریم، یعنی نیاز به هیچگونه تبدیل خودکار نیست بطور معمول، بازم PHP میاد و در این دخل و تصرف میکنه نگاه میکنه اگر توی رشته ها چیزی شبیه عدد بود (با فرمتهای مختلف اعم از هگز و اوکتال و نماد علمی) اونا رو تبدیل به عدد و بعد مقایسه میکنه! اصلا چنین چیزی من توی هیچ زبانی ندیدم. اینا چطور استدلال کردن چرا بنظرشون همچنین چیزی زیاد نیاز میشده و مفید بوده من نمیدونم!
دقیقا به همین دلیل در همون مثال قبلی که زدم، حتی اگر مقدار عدد ستون ها رو توی کوتیشن بذاریم، هنوزم در برنامه مشکل وجود داره و کاربر میتونه اون رو به درجه ای دستکاری کنه. گرچه مشکل به اندازهء مثال قبلی حاد نخواهد بود، اما بهرحال هنوزم مشکل داره و کاربر میتونه عملی انجام بده فراتر از چیزی که ما در برنامه حد و حدود تعیین کردیم.
جالب اینکه در این موارد حتی Escape هم جواب نمیده و جلوی تمام حالات رو نمیگیره! خواستید با کد و مثال نشون میدم که چرا.

بنابراین تنها حالتی که میشه این کد رو کاملا امن کرد اینه که مقدارها رو توی کوتیشن بذاریم، و به پارامتر strict تابع in_array هم مقدار true بدیم.
اینو گفتم که بدونید من خودم میدونم in_array یک پارامتر مخصوص همین داره. من هم نگفتم نمیشه این کد رو به هیچ وجه امن کرد، منظور چیز دیگس و اینکه چیزهایی که بطور معمول در هیچ زبان دیگری مشکل محسوب نمیشن و موجب باگ و حفره ای در برنامه نمیشن و طبق انتظار عمل میکنن، در PHP کاملا غیرمنتظره عمل میکنن و موجب باگ و حفره میشن. و دلیل این رفتار غیرمنتظره و مزیت بزرگش مشخص نیست! چرا؟ بخاطر یکسری توجیهات سطحی و مسخره اومدن این کارها رو کردن، درحالیکه تمام زبانهای دیگر تشخیص دیگری داشتن.

البته راه دیگر هم همونطور که اشاره کردید استفاده از Prepared Statement و این حرفهاست، ولی اون رو من تست نکردم، گرچه فکر میکنم بدون مشکل باشه.
بهرحال در نظر بگیرید که اینطور مثالها فقط به SQL و دیتابیس مربوط نمیشن، بلکه میتونن در موارد دیگری هم صدق کنن. لزوما ورودی ای که ما از کاربر میگیریم کاربردش فقط این نیست که توی یک کوئری بکار بره. برای خیلی کارها و بخشهای دیگر ممکنه ما به شکلی از ورودیهای کاربر استفاده کنیم.

[charcharkh]

خودمونیم با تمام قوا اومدی php رو از پا بندازیا . حالا این همه تلاش شما برای چیست ؟ بعضی ایرادات شما درست هست ولی این دلیل نمیشه کل زبان php رو زیر سوال ببری. توی هر زبانی باگ پیدا میشه و رفعش میکنند. در ضمن برای اینکه خیال شما راحت بشه متغیر از چه نوع هست خیلی کارها میتونی انجام بدی مثل این :



$var = (int)$var2;
$var = (string)$var2;
$var = (float)$var2;

[SZsXsZS]

خودمونیم با تمام قوا اومدی php رو از پا بندازیا.
به خیال آدمهای کم سواد و متعصب شاید اینطور باشه، ولی واقعیت اینطور نیست.
شما نمیتونید تفکر و رفتار آدمی مثل منو درک کنید، چون در سطح من نیستید.
من از مرحلهء تعصب گذشته ام و در مرحلهء واقعیت گرایی و عملگرایی کامل هستم.
ضمنا گسترهء دانش و بینش من خیلی بیشتر از دیگرانه. دلیل و شواهد هم داره. چون هیچکس قدر من زحمت نکشیده در مدتی طولانی.


حالا این همه تلاش شما برای چیست ؟
چالش ها و نبردهای فکری منو قوی تر میکن. در کنار اینکه میزان دانش و بینش و قدرت خودم رو محک میزنم و دنیای اطرافم رو بهتر میشناسم و درک میکنم. باید بدونم دیگران در چه سطحی هستن چجور آدمهایی هستن، و همینطور دیگران هم در جامعه باید متوجه واقعیت مسائل و افراد خاصی مثل من و جایگاه و ماهیت خودشون بشن. این به نفع همه است.
بهرحال من از نبرد هراسی ندارم. در نبرد و چالش است که افراد برتر شناخته میشن.
افراد برتر هر رشته ای، باید از سلامت اون رشته محافظت کنن. چون این به نفع همه منجمله خودشونه.
میخواید گوش کنید میخواید نکنید، من کار خودم رو میکنم و از کسی هم نمیترسم.


بعضی ایرادات شما درست هست ولی این دلیل نمیشه کل زبان php رو زیر سوال ببری.
PHP خودش خودش رو زیر سوال برده. من چنین قصدی نداشتم، اما شواهد و دلایل و رفتار خودش هست که باعث میشه زیر سوال بره.


توی هر زبانی باگ پیدا میشه و رفعش میکنند.
بازم تکرار میکنم، اینها باگ نیستن، بلکه طراحی بد هستن.
دوما بله در هر زبانی باگ و همچنین طراحی بد پیدا میشه. من حتی میتونم از پایتون ایراد بگیرم، از جاوا ایراد بگیرم، ...، ولی یکسری اشتباهات واضحا بیش از حد قابل تحمل ناشیانه و بزرگ هستن و اعتراض آدم رو درمیارن آدم رو عصبانی میکنن با درجهء نادانی و ناشی گری خودشون! اشتباهاتی که از آدم بالغ و عاقل و باسواد انتظار نمیرن.


در ضمن برای اینکه خیال شما راحت بشه متغیر از چه نوع هست خیلی کارها میتونی انجام بدی مثل این :


$var = (int)$var2;
$var = (string)$var2;
$var = (float)$var2;

خب که چی؟
عملیاتی که میتونست ساده تر، کوتاهتر، روشن تر از این ها باشه، اینقدر پیچیدش کردن برای چی؟
این همه زبان دیگر بودن که میتونستن الگوی PHP باشن، ولی PHP رفت و یک چیزی مزخرفی رو از خودش درآورد! که چی، من نمیفهمم!

عملگر == در پی اچ پی الان تقریبا به دردی نمیخوره. فکر کنم واسه قشنگی و بعنوان اسباب بازی گذاشتنش! برخلاف تمام زبانهای دیگر!

اگر میخواید توصیه هایی رو از یک متخصص امنیت بشنوید:

بصورت پیشفرض بجای عملگر == از === استفاده کنید.

بصورت پیشفرض بجای != از !== استفاده کنید.

موقع استفاده از توابعی مثل in_array حواستون باشه حالت strict رو فعال کنید.

حالا تازه اینا مواردی بود که تاحالا بهشون برخورد و بررسی کافی کردم، ممکنه در جاهای دیگری هم مشکل باشه. مثلا عملگرهای عدم تساوی هم ظاهرا مشکلاتی دارن، ولی بهرحال فکر میکنم اکثریت قریب به اتفاق موارد و اهمیت به همین عملگرهای بررسی شده تا اینجا مربوط میشه.

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

[SZsXsZS]

بقول طرف میگه تو مو بینی و من پیچش مو!

همین دوست عزیز، Unique (http://barnamenevis.org/member.php?11933-Unique)، مگه نگفت «اینطور که شما میگین مشکل SQL Injection ایجاد کنه ،‌ اگه چنین مشکل ایجاد کرده به این خاطر بوده که شما یا به درستی فیلتر نکردین ، Escape نکردین یا بهتر از اون از Prepared Statement ها استفاده نکردین ولی دارین تقصیر را گردن == میندازین!» ولی من براتون مثال و نمونه کد آوردم که چطور رفتارهای غیرمنتظره PHP باعث این مسئله میشه. نگید اینا همش تقصیر برنامه نویسه! این حرفا تکراری شدن قبلا جوابشون رو دادم. چطور توی زبانهای دیگه اینطور نمیشه و فقط توی PHP اینطور میشه؟ بهش فکر کنید!
مثالی هم که آوردم یه مثال واقعیه کسی نمیتونه بگه همچین کدی نمیتونیم داشته باشیم کسی چنین کدی چنین روشی نمینویسه یا نباید بنویسه.

تازه من همینطور تست نکرده و برخورد نکرده چندتا مسئلهء دیگر رو هم در این جریان پیشبینی کردم که بهشون اشاره کردم ولی شما شاید حتی به اونا دقت نکردید متوجه نشدید کنجکاوی نکردید نخواستید جوابش رو بدونید. چرا؟ چون سطحش رو ندارید، دنبال فهمیدن و یاد گرفتن و پیشرفت واقعی و اصولی نیستید هنوز. فعلا در مرحلهء تعصب و کل کل و غرور و عصبانیت و لجبازی هستید.

فرق آدمی که بینش و تخصص داره با آدمهایی که تخصص و بینش ندارن همینه. من میتونم حالاتی رو پیشبینی کنم بدون اینکه بهشون برخورد کرده باشم بدون اینکه نیاز باشه حتما تجربه و تست کنم، و دیگران نمیتونن. چرا؟ خب بخاطر اینکه زحمت کشیدم هرچی رو که لازم بوده بصورت اصولی یاد گرفتم، وقتی صد برابر دیگران زمان گذاشتم زحمت کشیدم مطالعه کردم بالاخره یه توانی بیشتر از اونا کسب میکنم یا نه؟ آیا این مسئلهء عجیبیه؟
خیلی وقتا میفهمم فلان چیز میتونه مشکل ایجاد کنه، حدس میزنم، بنوعی حس میکنم، ولی هنوز بطور دقیق حتی خودم هم نمیدونم چطوری و کجا، و خودم هم شک دارم، ده بار و صد بار تاحالا اینطوری شده، و آخرش فهمیدم که حس و حدسی که داشتم درست بوده! البته هم که این معجزه نیست، بلکه حس ناخودآگاهی در مغزه که از علم و بصیرت و تجربه حاصل میشه، از ورزیدگی و آمادگی ذهنی و اینکه بقدر کافی قبلا مطالعه داشتی و الگوهای مشابهش رو دیدی در ناخودآگاه مغزت متوجه ارتباطها و شباهت هایی میشه همون موقع.

براحتی میتونم بگم هیچکس در اینجا حداقل در فیلد امنیت، در حد و اندازهء من نیست.
من اصلا در این وادی تخصص های خاصی دارم که شاید در کل ایران نمونش نباشه یا اگر باشه تعداد انگشت شماری هستن.
مثلا در علم رمزنگاری تخصص و دانشی دارم که حتی میتونم بنوعی بگم نظیرش رو تاحالا بین ملت خودمون ندیدم.
این علوم پیشرفته در ایران تقریبا ناشناخته هستن، و شاید بشه گفت کاربرد آنچنانی هم بنابراین ندارن (در بازار و برای کسب درآمد)، ولی خب من علاقه داشتم همتش رو هم داشتم و رفتم دنبالش از منابع خارج استفاده کردم برای یادگیریش. کوچکترین منبع فارسی هم نبود و هنوزم چیز دندان گیری در این زمینه به فارسی وجود نداره (جز برخی مطالب مختصر و گزیده ای که خودم دادم تاحالا).
من هیچوقت نمیخواستم به ملت و شرایط کشور خودمون خودم رو محدود کنم. ولی دیگران اهداف سطحی و محدودی دارن و اکثرا هم فقط به پول کافی برسون راضی میشن. یه کلاس و شهرت و مقام ظاهری هم کنارش باشه که دیگه هیچی نمیخوان براشون علم اصلا اهمیتی نداره!

میتونم سر همین حرفهایی که اینجا زدم نکاتی که مطرح کردم شما رو به چالش بکشم ببینم میتونید مسائلی رو که مطرح میکنم حل کنید یا نه! تازه اینا یه موارد زیاد پیچیده و سختی هم نیست و بنوعی راهنمایی های هم در باب مسئله کردم.

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

حالا فرض کنید اصلا قصدم کوبیدن PHP باشه!
بهرحال حرف حساب هم توش هست مطالب جالب و آموزنده هم توش هست چیزهای کمیاب و نو هم توی مطالبم پیدا میشه، بهتره از اونا استفاده کنید.

سطح علمی واقعا پایینه.
برنامه نویسی هم شده بچه بازی هر بچه کم سوادی میشه برنامه نویس!
البته که کارهایی که همه میتونن بکنن میتونن بفهمن هر بچه و آدم کم سوادی هم میتونه بکنه، هنری نیست چیز شاق و خاصی نیست.

[Unique]

eshpilen خیلی حوصله داری ، با این نوع نوشتنت فکر کنم اهل وبلاگ نویسی هم باشی ، اگه هستی برام خصوصی بگذار یا همینجا بگو دوست دارم دنبالت کنم.

شرمنده دیر جواب میدم و شما برای خودت بریدی و دوختی اما :
توی مثالی که زدی و بهش گیر میدی اصل اولیه جلوگیری از SQL Injection و دیگر حفره ها در نظر گرفته نشده.

اصل اول : هر ورودی را از کاربر میگیری باید مطمئن باشی نوعش درسته یا تبدیلش کنی در واقع فیلتر کنی اضافه ها را:
شما باید قبل از in_array بیای و sort_col توی GET را با ctype_digit معلوم کنی عددی هست یا نه و اگه نبود بیای Intval بگیری اگه میخوای cast درستی کنی یا مقدار پیش فرض بدی.

دوست عزیز ، من هیچ حرفی در مورد رفتار های عجیب PHP در زمان Type Casting ندارم چون PHP سعی میکنه هر جور شده دو طرف را از یک نوع و معادل کنه ! PHP ذاتش اینطوریه و اگه کسی با این ذات مشکل داره بهتره زبان های دیگه را انتخاب کنه. برنامه نویس خوب برنامه نویسیه که همه چیز را به تقدیر و PHP نسپاره ! باید بدونه داره چیکار میکنه. البته این تجربه به راحتی کسب نمیشه و من هم خودم توی کد هام مشکلات امنیتی داشتم و دارم و خواهم داشت اما همینکه متوجه میشم رفعش میکنم.

متاسفانه من نمیتونم براتون شرح بدم چرا PHP اینطوریه یا چرا به قول شما عجیب و غریبه اما میتونی با این دوستمون هم ذات پندرای کنی (http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/) و از PHP بد بگین. (یه لحظه فکر کردم با خودتی یا همین پست وبلاگ را خوندی !)

هنوز منتظرم ببینم چطور == به صورت مستقیم و بدون اشتباه شما در فیلتر کردن و escape کردن باعث Sql Injection شده !؟

[رضا قربانی]

SZsXsZS (http://barnamenevis.org/member.php?374132-SZsXsZS) چطوری پسرم :لبخند::لبخند::لبخند:
--------------
تو باید بونگاه ماشین کار میکردی . میلیاردر میشدی . :بامزه:

کم نوشتم تا حداقل بتونی سه خط نقل قول کنی :گیج:

[charcharkh]

سلام


به خیال آدمهای کم سواد و متعصب شاید اینطور باشه، ولی واقعیت اینطور نیست.
شما نمیتونید تفکر و رفتار آدمی مثل منو درک کنید، چون در سطح من نیستید.

بنده به هیچ وجه تکرار میکنم به هیچ وجه دوست ندارم در سطح اخلاقی و گفتاری شما باشم . چون اگر واقعا حرفه ای بودی (البته با دوتا ایراد گرفتن از یه چیز آدم نمیتونه خودشو حرفه ای تلقی کنه این لاقل دیگاه خود بنده است) و زحمت کشیده بودی برای معلوماتتون و بقول قدیمیا دود چراغ خورده بودی میدونستی که لاقل عفت کلام داشته باشی . درخت هرچه بارش بیشتر افتادگیشم بیشتر میشه .:لبخندساده:
لازم بذکر هست بنده هیچ تعصبی نسبت به هیچ ربان برنامه نویسی ندارم هر زبانی در جای خودش کارا و مفید هست.



چالش ها و نبردهای فکری منو قوی تر میکن.

خب چالش تو همه چیز آدمی رو قویتر میکنه . چه از لحاظ فکری چه از لحاظ جسمی و ...



در کنار اینکه میزان دانش و بینش و قدرت خودم رو محک میزنم و دنیای اطرافم رو بهتر میشناسم و درک میکنم.

دانش خودتون رو با مطالعه میتونید بیشتر کنید و البته تمرین ولی بینش یه چیز دیگه هم نیاز داره که اونم اسمش نگرش صحیح هست . شما بد نیست روی جهان بینیت یه کم فقط یه کم بیشتر فکر نمایید. (البته این فقط یه پیشنهاد هست).



. باید بدونم دیگران در چه سطحی هستن چجور آدمهایی هستن، و همینطور دیگران هم در جامعه باید متوجه واقعیت مسائل و افراد خاصی مثل من و جایگاه و ماهیت خودشون بشن. این به نفع همه است


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



موقع استفاده از توابعی مثل in_array حواستون باشه حالت strict رو فعال کنید.


جالب هست خودتون داری میگید که آپشن strict رو فعال کنید یعنی سازنده زبان به نوعی شاید میدونسته که بعضی بررسی ها باید دقیق تر انجام بشه حتی حروف کوچک و بزرگ و حتی type اونها رو مورد بررسی قرار میده. اینجا رو (http://php.net/manual/en/function.in-array.php)یه نگاه بیندازید.



البته در طول تاریخ همیشه آدمهای ممتاز و متفاوت مورد مخالفت و دشمنی اکثریت واقع شدن، به دلایلی منجمله نادانی، ترس و حسادت.

اینجا خدایی نکرده نه کسی حسود هست و نه بخیل و نه نادان یا هر چیز دیگه ای که شما اسمشو بزعم خودتون بذارید. خود بنده قبل از همه این جارو جنجالها در پست #24 از شما بابت مطلبتون تشکر کرده بودم.



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


تا وقتی که از کسی چیزی داریم یاد میگیریم و طرف هم برخوردش مناسب باشه حرفی نیست . تا پست شماره 18 شما همه چیز خیلی خوب داره دنبال میشه و استفاده میکنیم ولی از حدود پست 19 و 20 به بعد اصلا انگار قضیه یه طور دیگه ای میشه.


حالا فرض کنید اصلا قصدم کوبیدن PHP باشه!
بهرحال حرف حساب هم توش هست مطالب جالب و آموزنده هم توش هست چیزهای کمیاب و نو هم توی مطالبم پیدا میشه، بهتره از اونا استفاده کنید.

حرف حساب و مطالب آموزنده خوبه ولی بد زبانی نه . حرف حساب جواب نداره .



برنامه نویسی هم شده بچه بازی هر بچه کم سوادی میشه برنامه نویس!
البته که کارهایی که همه میتونن بکنن میتونن بفهمن هر بچه و آدم کم سوادی هم میتونه بکنه، هنری نیست چیز شاق و خاصی نیست.


بالاخره که باید از یه جایی شروع کرد خود شما باصطلاح خودتون از اول با همین سطح دانش بوده اید ؟!!

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

شما تا وقتی که دانش خود را نشر دهید البته اونم بی منت میتونید پیشرفت کنید و گرنه که هیچ . خدا رو شکر دنیا هم آنقدر امکانات و سایتها و فایلهای ویدئو زبان اصلی هست که بشه با کمترین هزینه چیزهای خیلی خوب رو فرا گرفت.
آرزو موفقیت براتون میکنم . در پناه خدا.

[Unique]

جناب charcharkh دلخور نشین ، ایشون از کاربران قدیمی تالار هستن و با نام های کاربری گوناگونی حضور داشتن ، پسر خوب و با مطالعه ای هستن و شخصا از ایشون خیلی چیز یاد گرفتم. یکمی زبونشون تیز و تنده که بهتره اصلاح بشه.

[SZsXsZS]

eshpilen خیلی حوصله داری ، با این نوع نوشتنت فکر کنم اهل وبلاگ نویسی هم باشی ، اگه هستی برام خصوصی بگذار یا همینجا بگو دوست دارم دنبالت کنم.
http://hamidreza-mz.tk/


اصل اول : هر ورودی را از کاربر میگیری باید مطمئن باشی نوعش درسته یا تبدیلش کنی
در واقع فیلتر کنی اضافه ها را:
شما باید قبل از in_array بیای و sort_col توی GET را با ctype_digit معلوم کنی عددی هست یا نه و اگه نبود بیای Intval بگیری اگه میخوای cast درستی کنی یا مقدار پیش فرض بدی.

وقتی ما از white list استفاده میکنیم، نوع دیگه زیاد مفهومی نداره، چون white list یعنی عین مقداری که میتونه باشه. همه چیز هم از سمت کلاینت با نوع رشته دریافت میشه. کافیه شما در white list رشته ای بنویسی که عینا برابر رشته های مجاز باشه. تبدیل نوع دیگه نیازی نیست. تنها ایرادی که به نمونه کدی که من گذاشتم میشه گرفت اینه که برنامه نویس باید عددهایی رو که تعیین کرده بود توی کوتیشن میذاشت. باید بگم تاحدی میشه این ایراد رو وارد دونست، اما بهرحال نظیر این کد در هیچ زبانی غیر از PHP مشکل امنیتی ایجاد نمیکنه. اصلا این تبدیل نوع خودکار که در زبانهای دیگر هم هست یک مزیت و کاربردش همینه که نیازی نباشه مدام در فکر و کار نوع مقادیر و تبدیلات بین اونا باشی.

خب الان شما این کد رو نگاه کن:


<?php

error_reporting(E_ALL);
ini_set('display_errors', '1');

$sort_cols=array('1', '3', '6');

$_GET['sort_col']='3 sql injection...';

if(in_array($_GET['sort_col'], $sort_cols)) $sort_col=$_GET['sort_col'];
else $sort_col='nothing';

echo "sort_col: $sort_col";

?>

آیا بنظرت مشکلی داره و چرا؟
باوجودی که ما عین مقادیر رو مشخص کردیم، و نوع ورودی ها هم که همون نوعی هست که مقادیر رو میخوایم (رشته)، چرا باید به نوع دیگری تبدیل کنیم؟ نیازی به تبدیل نوع هست؟ یعنی شما میگی حتما باید مقادیر رو بصورت عددی مشخص کنیم و ورودی کاربر رو تبدیل به عدد کنیم؟ چرا؟


PHP سعی میکنه هر جور شده دو طرف را از یک نوع و معادل کنه!
خب چرا؟
هدف از این طراحی چی بوده مزیت و کاربردهای زیادش که جوابگوی این هزینه ها و بالا بردن احتمال باگ در برنامه ها باشه چیه؟
مشکل همینه که PHP توجیه معقولی برای این کار نداره. همینطوری رندوم و سلیقه ای که نمیشه. بهتون گفتم قاعده داره منطق داره!


PHP ذاتش اینطوریه و اگه کسی با این ذات مشکل داره بهتره زبان های دیگه را انتخاب کنه.
آفرین منم دارم نشون میدم که PHP ذاتش در اینطور موارد غیرمنطقی و ابلهانه است!
البته من شخصا PHP رو دوست دارم در کل زبان خوبی میدونم. بنابراین یکسری نکات و روشهایی رو که بشه تاحد زیادی از نتایج منفی این رفتارهای غیرمنطقی در امان موند مطرح کردم که خودمم استفاده میکنم. اما بنظر من اگر PHP این موارد رو اصلاح کنه، بسیار بهتر خواهد بود.


متاسفانه من نمیتونم براتون شرح بدم چرا PHP اینطوریه یا چرا به قول شما عجیب و غریبه اما میتونی با این دوستمون هم ذات پندرای کنی (http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/) و از PHP بد بگین. (یه لحظه فکر کردم با خودتی یا همین پست وبلاگ را خوندی !)

خب منکه موارد پست اول رو از همین منبع گلچین کردم و لینک منبع رو هم گذاشتم!
شما که پست طرف رو کامل و دقیق نمیخونید بعد میاید همینطور بحث و جدل میکنید؟! بنظرتون این رفتار عاقلانه ایه؟
بنظر من یه چیزی توی زندگیتون یاد نگرفتید و اون اینه که همه چیز رو نمیشه خیلی مختصر و سریع کرد. ولی شما ظاهرا عادت کردید فقط مثل کدنویسیتون با حداکثر سرعت و راحتی قطعه کدهایی رو پیدا یا پیاده سازی کنید و کار رو راه بندازید. این توی کدنویسی و برنامه های عادی شما شاید کفایت کنه، ولی توی خیلی چیزا واقعا به این سادگی و مختصری و سرعت نمیشه.


هنوز منتظرم ببینم چطور == به صورت مستقیم و بدون اشتباه شما در فیلتر کردن و escape کردن باعث Sql Injection شده !؟
نمونه کدی رو که در این پست گذاشتم بررسی کن ببین بنظرت بدون مشکله؟

[SZsXsZS]

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


حتی حروف کوچک و بزرگ
شوخی میکنی؟
خب رشته ها رو وقتی داریم مقایسه میکنیم که حتما باید حروف بزرگ و کوچک متفاوت محسوب بشن، مگر اینکه خلافش رو صریحا درخواست کرده باشیم (مثلا با استفاده از توابعی که مخصوص مقایسه بدون توجه به کیس حروف هستن). مثلا فکر کنید مقایسه رشته ها بصورت پیشفرض بدون توجه به کوچکی و بزرگی حروف باشه، اونوقت پسوردهایی که کاملا متفاوت هستن یکسان شمرده میشن!! همینطور در مورد خیلی موارد دیگه که بزرگی و کوچکی اهمیت داره.
قاعدهء روشن و منطقی در تمام زبانها اینه که مقایسهء رشته ها حساس به بزرگی و کوچکی حروف است، و اگر برنامه نویس میخواد که به بزرگی و کوچکی حروف حساس نباشه بصورت صریح میاد از توابع یا سویچ هایی که استفاده میکنه که اینطور عمل میکنن.
تنها مواردی که مقایسه ها بصورت پیشفرض case-insensitive هستن در موارد خاص هست که در استانداردهاش اینطوریه و بزرگی و کوچکی حروف هیچ اهمیتی نداره. مثلا یه تابعی هست که اسم یک HTTP header رو میگیره و مقدارش رو برمیگردونه، خب چون در استاندارد HTTP بزرگی و کوچکی حروف در اسم هدرها تاثیری نداره و دو هدر که فقط در کوچکی و بزرگی حروف تفاوت میکنن یکسان شمرده میشن، پس تابعی که مقدار هدر رو برمیگردونه هم میتونه کوچکی و بزرگی حروف رو بحساب نیاره.


و حتی type اونها رو مورد بررسی قرار میده. اینجا رو (http://php.net/manual/en/function.in-array.php)یه نگاه بیندازید.
حالا بحث سر این نبود که حالت strict بصورت پیشفرض فعال باشه، ولی احتمالا اگر اینطور میبود بهتر بود.
و منشاء اصلی مشکلاتی نظیر اونچه بنده مطرح کردم درواقع این نیست، بلکه خود رفتار عملگر == است. وگرنه مثلا فرض کنید رفتار عملگر == در زبان PHP هم مثل زبانهای دیگه بقدر کافی معقول و محتاط بود، هیچ مشکلی رخ نمیداد و در چنین مواردی نیازی به حالت strict نداشتیم. حالت strict برای موارد دیگری معمولا نیاز هست موقعی که به دلیل مشخصی در برنامه میخوایم نوع رو هم چک کنیم.

[charcharkh]

سلام خود سایت php میدونه برای اینکار نیاز به پارامتر سومی هم هست اینجا رو ببنید.
http://php.net/manual/en/function.in-array.php

فکر کنم خیلی ابهامات حل بشه.

[SZsXsZS]

سلام خود سایت php میدونه برای اینکار نیاز به پارامتر سومی هم هست اینجا رو ببنید.
http://php.net/manual/en/function.in-array.php

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

بحث اینه که اگر رفتار تبدیل انواع در PHP، رفتار ==، اینطور عجیب و غیرمنطقی و دردسرساز نبود، مثل خیلی زبانهای دیگر که معقول تر و محتاط تر عمل میکنن، اصلا این مسائل پیش نمی آمد که الان ما بخوایم سرش بحث کنیم و به مبتدی ها آگاهی بدیم که چطوری کد امن بنویسن، و تازه با این حال بازم خود من شخصا مطمئن نیستم جای دیگری مشکل دیگری از نظر دور نمونده باشه. یک چیزهایی اینقدر پایه رو اگر شما بد طراحی کنید، بعدا مستقیم و غیرمستقیم و به شکلهای پیچیده و پنهانی میتونه خیلی جاها تاثیر منفی بذاره.

بحث اینه که کدها و روشهایی که در PHP موجب باگ و حفره میشن در هیچ زبان دیگری مشکلی ندارن. چرا اینطوره؟ چرا PHP اینطور طراحی شده؟ مرض داشتن؟ یا سواد نداشتن؟ شاید بچه و احمق و بی تجربه بودن اون زمانی که این چیزا رو طراحی میکردن، که البته بعید هم نیست!

[us1234]

سلام خود سایت php میدونه برای اینکار نیاز به پارامتر سومی هم هست اینجا رو ببنید.
http://php.net/manual/en/function.in-array.php

فکر کنم خیلی ابهامات حل بشه.

من به استاتر کاری ندارم ولی تمام موضوعاتی که بیان میکند موارد عادی است و اگر برنامه نویس یکم دقت در کار داشته باشد هیچ مشکلی نیست .
صحبت های استاتر مصداق این است که من یک نمونه sql injection را ذکر کنم و کلی آسمان ریسمان ببافم که بدترین طراحی در زبان SQL وجود داره چون میشه انجکشن زد ...
این ها باگ نیست ، کم توجهی برنامه نویس است .

دوباره میخواهم روی این جمله تاکید کنم هرچند کسی اصلا توجهی نداره !

داکیومنت ، سایت php.net ریز به ریز این موارد را با مثال توضیح داده پس اگر کسی با این روش ها هک شد دقیقا مثل هک شدن با انجکشن است و کسی php را مقصر نمیدونه و انگشت اتحام سمت برنامه نویس است نه زبان .

من چند اصل را ذکر میکنم اگر استارتر یا کس دیگه مثال نقض برای این اصل ها آورد من هم قبول میکنم که طراحی php مذخرف است !

1- هرگاه یک طرف == رشته ( string ) بود و طرف دیگه int ، رشته تبدیل به int میشود . ( دقیقا مثل اینکه string از تابع intval عبور کرده باشد )
2- هرگاه یک طرف == رشته ( string ) بود و طرف دیگه float، رشته تبدیل به floatمیشود .( دقیقا مثل اینکه string از تابع floatval عبور کرده باشد )
3- هرگاه یک طرف == رشته ( string ) بود و طرف دیگه boolval ، رشته تبدیل به boolval میشود .( دقیقا مثل اینکه string از تابع boolval عبور کرده باشد )
4- هرگاه یک طرف == رشته ( string ) بود و طرف دیگه double، رشته تبدیل به doubleمیشود .( دقیقا مثل اینکه string از تابع doubleval عبور کرده باشد )
5-

1 === '1'
برابر نیست

6- GET و POST و REQUEST همیشه string هست مگر آنکه داخل کد نوع آنها تغییر کند .

[SZsXsZS]

داکیومنت ، سایت php.net ریز به ریز این موارد را با مثال توضیح داده پس اگر کسی با این روش ها هک شد دقیقا مثل هک شدن با انجکشن است و کسی php را مقصر نمیدونه و انگشت اتحام سمت برنامه نویس است نه زبان. سایت PHP طراحی رو توضیح داده، نه علتش رو. مثل اینکه من یه اتومبیل طراحی کنم که یه دکمه روی فرمانش باشه که اگر بزنید ماشین چپ میکنه، و در داکیومنت ها توضیح بدم که این دکمه کارش اینه پس مواظب باشید دستتون بهش نخوره یوقت! موضوع اینه اصلا این دکمهء دردسرساز رو واسه چی گذاشتن فایدش چیه که این ریسک و خطر همیشه وجود داشته باشه و باید همیشه مواظب باشیم دقت اضافه داشته باشیم بابت این قضیه. بله البته من که آگاه هستم داکیومنت ها رو خوندم میتونم چسب قطره ای بزنم به دکمه هه که خیالم راحت بشم (هرچند هنوزم یه ریسکه مثلا ممکنه چسبش کنده بشه)، و دقیقا همین کار رو من میگم در PHP کردم و به دیگران هم توصیه میکنم، میگم که از عملگر == و != استفاده نکنید کلا، مگر جایی که به هر دلیل روشن و کافی مجبور باشید.
1- هرگاه یک طرف == رشته ( string ) بود و طرف دیگه int ، رشته تبدیل به int میشود . ( دقیقا مثل اینکه string از تابع intval عبور کرده باشد ) خب اینکه گفتی در زبانهای دیگر هم هست، ولی تبدیل رشته به عدد در اونها با قواعد محتاطانه تر و معقول تری صورت میگیره. هیچوقت در زبان دیگه شما نمیبینی که 3 == '3foo' درست ارزیابی بشه. ضمنا یک رفتار غیرمنطقی دیگر که شما در هیچ زبان دیگری مشاهده نمیکنید اینه که حتی وقتی دو طرف رشته هستن، بازم PHP میاد و از خودش تفسیر و دخل و تصرف میکنه و اگر ببینه فرمت دو طرف شبیه عدد است، اونا رو تبدیل به عدد و بعد مقایسه میکنه. بطور مثال:
'0x3e8'=='1e3' درست ارزیابی میشه.
'0x3e8'=='1000' درست ارزیابی میشه.
حالا اینم باز در برنامه نویسی میتونه منجر به باگها و همچنین حفره های امنیتی پنهان بشه. ولی فقط در زبان PHP اینطوره!
سوال اینه: چرا؟
چیزی که خیلی بیشتر از اونچه که واقعا مورد نیاز و انتظار برنامه نویسان باشه و به دردشون بخوره، غیرمنتظره و نامطلوب است و موجب دردسر میشه، چرا گذاشتن، چرا اینطور طراحی کردن؟

[0xEHSAN]

ممنون از SZsXsZS (http://barnamenevis.org/member.php?374132-SZsXsZS) عزیز بحث خیلی جالبی باز کردین ممنون میشم شما و یا سایر اساتید عزیز کامل ترش کنید و اگه امکان داره تمام مورادی که رفتار ابهام دارن رو ذکر کنید زبان php یک زبان محبوب با مزیتهای بیشماره و نمیشه ازش گذشت با تشکر

[SZsXsZS]

حالا جالب اینکه ظاهرا PHP خودش داره به مرور این موارد رو اصلاح میکنه. چون من چندتا نمونه کدهایی تاحالا دیدم و تست کردم دیدم کار نمیکنن و رفتار PHP ظاهرا در نسخه های جدیدتر عوض شده و به مرور داره این موارد دردسرساز رو حذف میکنه.
همین الان هم مثلا یه نمونه کدی که توی خونه تست کرده بودم زدم دیدم محل کارم کار نمیکنه که فکر کنم بخاطر تفاوت نسخه های PHP خونه و محل کارم باشه.
یعنی میخوام بگم چیزی که از شواهد برمیاد خود طراحان PHP هم متوجه شدن که در این موارد حق با منتقدین است و دارن تغییر میدن.
ولی حالا بعضیا اصرار دارن میخوان بگن نه PHP هیچ عیب و ایرادی نداره و اینا خطاهای طراحی نیستن با من بحث میکنن حرفهای بی ربط میزنن مثلا میگن خب داکیومنت داره یا فلان روش دیگه رو استفاده کن!
اگر اینا طراحی های بد نیست پس چرا خود PHP داره به مرور کنار میذاره؟
طراحی بد هم یک خطای انسانیه. همونطور که توی برنامه های حتی حرفه ای باگ و حفره درمیاد، در طراحی هم انسانها ممکنه اشتباه کنن. من قبلا گفتم میتونم حتی از پایتون و جاوا هم انتقاد کنم بگم فلان جاش رو باید طور دیگه طراحی میکردن. ولی خب چیزی که من میگم اینه که این طراحی های PHP که موارد متعدد بودن تاحالا و موارد پایه و بزرگی هم محسوب میشن، واضحا بیش از حد بزرگ و ناشیانه هستن.
حالا ما کار نداریم اینا رو میذاریم پای گذشته و بی تجربگی و اهداف اولیهء زبان PHP. بهرحال در کل PHP زبان مفیدیه منم دوستش دارم ازش زیاد هم استفاده میکنم حتی توی کارهایی که میشه با زبانهای دیگری هم بنویسم اغلب PHP رو بخاطر راحت تر بودنش ترجیح میدم (البته راحتیش بخاطر این رفتارهای عجیب عملگرهاش نیستا). حالا اگر زبان PHP همهء این ضعف ها رو برطرف کرد که چه بهتر منم خوشحال میشم. چیزی به ضرر من نمیشه بلکه به نفعم هم هست. بهرحال در حال حاضر هنوز یکسری مواردی وجود دارن که باید نسبت بهشون آگاه باشیم و ازشون اجتناب کنیم تا برنامه هامون از اثرات منفی این موارد در امان باشن.

[charcharkh]

دوست عزیز شما اصلا نمیفهمید من چی میگم.


ببین یکم فقط یکم روی طرز صحبت ولحن کلامتون لطفا کار کنید بد نیست. ضرر نمیکنید.:لبخندساده:



من به استاتر کاری ندارم ولی تمام موضوعاتی که بیان میکند موارد عادی است و اگر برنامه نویس یکم دقت در کار داشته باشد هیچ مشکلی نیست .
صحبت های استاتر مصداق این است که من یک نمونه sql injection را ذکر کنم و کلی آسمان ریسمان ببافم که بدترین طراحی در زبان SQL وجود داره چون میشه انجکشن زد ...
این ها باگ نیست ، کم توجهی برنامه نویس است .

دوباره میخواهم روی این جمله تاکید کنم هرچند کسی اصلا توجهی نداره !

داکیومنت ، سایت php.net ریز به ریز این موارد را با مثال توضیح داده پس اگر کسی با این روش ها هک شد دقیقا مثل هک شدن با انجکشن است و کسی php را مقصر نمیدونه و انگشت اتحام سمت برنامه نویس است نه زبان .

من چند اصل را ذکر میکنم اگر استارتر یا کس دیگه مثال نقض برای این اصل ها آورد من هم قبول میکنم که طراحی php مذخرف است !

1- هرگاه یک طرف == رشته ( string ) بود و طرف دیگه int ، رشته تبدیل به int میشود . ( دقیقا مثل اینکه string از تابع intval عبور کرده باشد )
2- هرگاه یک طرف == رشته ( string ) بود و طرف دیگه float، رشته تبدیل به floatمیشود .( دقیقا مثل اینکه string از تابع floatval عبور کرده باشد )
3- هرگاه یک طرف == رشته ( string ) بود و طرف دیگه boolval ، رشته تبدیل به boolval میشود .( دقیقا مثل اینکه string از تابع boolval عبور کرده باشد )
4- هرگاه یک طرف == رشته ( string ) بود و طرف دیگه double، رشته تبدیل به doubleمیشود .( دقیقا مثل اینکه string از تابع doubleval عبور کرده باشد )
5-



1

1 === '1'







برابر نیست

6- GET و POST و REQUEST همیشه string هست مگر آنکه داخل کد نوع آنها تغییر کند .

بله درست هست همینه دیگه. ممنون

[0xEHSAN]

دوست عزیز حتما خیری دیده که اینجوری طراحی کرده و گرنه معایبش رو تو داکیومنت ها اشاره نمیکرد:)

[SZsXsZS]

دوست عزیز حتما خیری دیده که اینجوری طراحی کرده و گرنه معایبش رو تو داکیومنت ها اشاره نمیکرد:)
خیری به خیال خودشون دیدن، ولی در واقعیت و عمل شرش از خیرش خیلی بیشتره.
بی تجربه بودن اشتباه کردن دیگه. تخصص و بینش کافی در امر طراحی زبان نداشتن. بنظر شما غیرممکنه؟
ضمنا در مستندات رسمی خود PHP اشاره شده که این زبان رو برای افراد غیرمتخصص در برنامه نویسی طراحی کردن، و برای برنامه های ساده و کم اهمیت. پس اینکه در طراحیش زیاد به مسائل امنیتی و تخصصی توجه نکرده باشن زیادم عجیب نیست. البته میگم که مرور PHP داره بهتر و بهتر میشه و نباید اون رو بخاطر تاریخ و هدف اولیه اش برای همیشه محکوم به این سرنوشت دونست! ولی میشه گفت هنوزم ریشه هایی از اون گذشته و تفکر و هدف اولیه درش باقی مونده.
بعد شما بفرمایید مثلا در register globals هم لابد خیری دیده بودن که گذاشتن، پس چرا بعدا برداشتنش؟ بالاخره طراحی درست بود خیرش از شرش بیشتر بود، یا برعکس؟
دست آخر هم باید بگم در داکیومنت ها به معایبش اشاره نکردن، بلکه صرفا رفتارش رو توضیح دادن. تشخیص اینکه این رفتارها چطوری و کجاها باعث دردسر میشن، به عهدهء خود افراد هست و طبیعتا برای مبتدی ها میتونه دشوار و غیرمنتظره باشه، کما اینکه برای من حرفه ای هم تازه بعد از سالها بعضی از ابعاد اون روشن میشه.
هیچ کجای داکیومنت ها هم نگفتن بصورت پیشفرض از == و != استفاده نکنید. بقول معروف میگن هیچ بقالی نمیگه ماست من ترشه!

[SZsXsZS]

1- هرگاه یک طرف == رشته ( string ) بود و طرف دیگه int ، رشته تبدیل به int میشود . (دقیقا مثل اینکه string از تابع intval عبور کرده باشد )
دقیقا ذهنیت های غلط طراحان PHP در همین جمله مشخص میشه.
اینا فکر کردن چون یه تابع هست بنام intval که رشته رو به عدد تبدیل میکنه، پس حالا برای تبدیل رشته و عدد با عملگر == هم باید دقیقا از رفتار همین تابع استفاده کنن تا این دوتا به خیال خودشون با هم سازگار باشن.
شاید فکر کردن اینطور شاهکار هم میکنن زدن روی دست زبانهای دیگه!!

مشکل اونجاست که از دید برنامه نویس و برنامه نویسی مقایسه با عملگر == یه چیزه و استفاده از یک تابع صریح برای تبدیل رشته به عدد چیز دیگه! اتفاقا رفتار این دوتا باید با هم تفاوت داشته باشن. چون معلومه وقتی برنامه نویس میاد یه رشته رو به چنین تابعی میده میگه به عدد تبدیلش کن، پس احتمال زیاد اون رشته یه مقدار مشکل داره و تبدیلش همینطوری به عدد به این راحتی نیست و برنامه نویس باید از یک تابع مخصوص کمک بگیره براش. وگرنه که خب اصلا بطور معمول نیازی نیست از چنین توابعی استفاده بشه چون خود زبان در جاهای مختلف تبدیلات لازم رو انجام میده. بهرحال هم که برنامه نویس خودش صریح داره میگه تبدیل به عدد کن، پس زبان میتونه مطمئن باشه که منظور و هدف و اولویت برنامه نویس اینه که یک عدد از رشته بدست بیاد یا بنوعی که بقدر کافی معقول و محتمل باشه استخراج بشه. پس اگر این تابع با رشته ای برخورد کنه که توش کاراکترهای دیگری غیر از رقم هم هست، براش جای تعجبی نداره و نیاز به احتیاط وسواسی نیست که بگه شاید این رشته در اصل قرار نبوده عدد باشه و به هر شکل ممکن به عدد تبدیل بشه.

من قبلا از جاوااسکریپت براتون مثال زدم و توضیح دادم، ولی باز هم طبق معمول شما نخونده و دقت نکرده و درک نکرده فقط اومدید دفاع متعصبانه از PHP بکنید.
یک بار دیگر مثال جاواسکریپت رو براتون میارم تا متوجه این نکته بشید که در زبانهای دیگر در نظر گرفته شده:

<script>
alert(parseInt("3foo"));

</script>



نتیجه عدد 3 است.
اما در عین حال مقایسه های معمولی با عملگر == مثل این:
<script>

alert(3=="3foo");

</script>



نتیجه false میده.

چرا این تفاوت وجود داره؟
به همون علت که گفتم. بهرحال توی همون مایه ها حالا کمی اینور و اونور!

شاید شک کنید بگید از کجا معلوم اصلا جاوااسکریپت در مقایسه با == وقتی یک طرف عدد باشه و طرف دیگر رشته میاد و رشته رو به عدد تبدیل میکنه و شاید بجای عدد رو به رشته تبدیل میکنه. من این سوال به ذهنم رسید، ولی با این تست متوجه شدم که رشته رو به عدد تبدیل میکنه (علی الظاهر تاجاییکه شواهد نشون میدن تا اینجا):
<script>
alert(3=='0x3');
</script>
نتیجه true است.
این نشون میده رشته تبدیل به عدد شده، چون اگر عدد تبدیل به رشته شده بود طبیعتا جواب false میشد.

میگم تو مو بینی و من پیچش مو، بخاطر همین چیزهاست که شما دقت نمیکنید درک نمیکنید فکر نمیکنید حتما علتی داره چرا اینطوره.
آیا زبانهای دیگر به فکرشون نمیرسیده یا نمیتونستن این قضیه رو پیاده کنن؟
از هر طراح زبان های معروفی هم اگر گیر آوردید برید بپرسید ببینید نظرشون راجع به این رفتار و طراحی در PHP چیه. موضوع اینه راحت گیر نمیاد در دسترس نیست، وگرنه من خودم تاحالا باهاشون مکاتبه کرده بودم نتایج رو براتون میذاشتم.

[0xEHSAN]

دیگه فعلا شده الان php جای خودشو تو برنامه نویسی های حرفه ای و برنامه ها و سایت های بزرگ پیدا کرده البته اینو هم نباید چشم پوشی کرد که همین عیب های کوچک خسارات بزرگ برای صاحبان سایت ها وارد کرده البته هر چی ساخته میشه بی عیب نمیشه برای مثال روز معرفی ویندوز توسط شرکت مایکروسافت تو همایشش جلو همه ویندوز هک شد یا سیستم عامل غیر قابل هک گوگل تو 10 دقیقه هک شد و کلی از این دست موارد

[SZsXsZS]

این پست ویرایش شد.

دلیل: فک کنم یخورده زیاده روی کردم :لبخند:

[SZsXsZS]

دیگه فعلا شده الان php جای خودشو تو برنامه نویسی های حرفه ای و برنامه ها و سایت های بزرگ پیدا کرده البته اینو هم نباید چشم پوشی کرد که همین عیب های کوچک خسارات بزرگ برای صاحبان سایت ها وارد کرده البته هر چی ساخته میشه بی عیب نمیشه برای مثال روز معرفی ویندوز توسط شرکت مایکروسافت تو همایشش جلو همه ویندوز هک شد یا سیستم عامل غیر قابل هک گوگل تو 10 دقیقه هک شد و کلی از این دست موارد
بله منکه گفتم خطای انسانی قابل قبوله و حتی توی حرفه ای ترین افراد و برنامه ها هم پیش میاد.
ولی یکسری موارد واضحا بیش از حد قابل اغماض بزرگ و ناشیانه هستن که نشون میدن طرفها برای کاری که انجام میدادن یا فرض میشه که اونقدر اهمیت داره، تخصص و صلاحیتشون بیش از حد پایین بوده.
یک بار و یک مورد هم که نبوده. بلکه چندین بار چندین مورد بوده.
در اینطور موارد آدم حق داره و باید هم صداش دربیاد!
میگن برو زبان دیگه کار کن، باید بگم خب وقتی php اینقدر آمار رو گرفته برای من انتخاب زبان دیگر هم محدودیت زا میشه، بنابراین حق دارم اشکالات این زبان رو مطرح کنم که یا اصلاح بشه یا حداقل آمار استفادش کمتر بشه که در نتیجه زبانهای دیگر هم سهم بیشتری بگیرن. این کار هیچ مشکلی نداره خیلی هم طبیعی و مفیده. اصلا لازمه. مثل امر به معروف و نهی از منکر که میگن! چرا میگن امر به معروف نهی از منکر کن؟ آیا این یک حق نیست؟ حتی فراتر از حق، میگن وظیفه هم هست (البته اگر شرایط و امکانش به شکل مناسبی باشه، نه توی جامعهء ما اونوقتا که سودی نداره یا حتی باعث ضرر میشه با چاقو طرف رو میزنن).

[0xEHSAN]

دلم خونه یکبار هم همینجوری تو جاوا آچمز شدم دوتا روشته یکسان رو مقایسه میکردم اما نتیجه فالس بود مخم هنگ کرد مجبور شدم بصورت بایت در بیارم و بررسی رو روی بایت ها انجام بدم بله یک چیز کوچولو بود که همه مشکلات از اون بود متنی که من مقایسه میکردم utf-8 بود با utf-8 bom تنها با تفاوت یک بایت اول که تو ظاهر رشته مشخص نبود جواب شرط فالس در میومد

[0xEHSAN]

بله منکه گفتم خطای انسانی قابل قبوله و حتی توی حرفه ای ترین افراد و برنامه ها هم پیش میاد.
ولی یکسری موارد واضحا بیش از حد قابل اغماض بزرگ و ناشیانه هستن که نشون میدن طرفها برای کاری که انجام میدادن یا فرض میشه که اونقدر اهمیت داره، تخصص و صلاحیتشون بیش از حد پایین بوده.
یک بار و یک مورد هم که نبوده. بلکه چندین بار چندین مورد بوده.
در اینطور موارد آدم حق داره و باید هم صداش دربیاد!
میگن برو زبان دیگه کار کن، باید بگم خب وقتی php اینقدر آمار رو گرفته برای من انتخاب زبان دیگر هم محدودیت زا میشه، بنابراین حق دارم اشکالات این زبان رو مطرح کنم که یا اصلاح بشه یا حداقل آمار استفادش کمتر بشه که در نتیجه زبانهای دیگر هم سهم بیشتری بگیرن. این کار هیچ مشکلی نداره خیلی هم طبیعی و مفیده. اصلا لازمه. مثل امر به معروف و نهی از منکر که میگن! چرا میگن امر به معروف نهی از منکر کن؟ آیا این یک حق نیست؟ حتی فراتر از حق، میگن وظیفه هم هست (البته اگر شرایط و امکانش به شکل مناسبی باشه، نه توی جامعهء ما اونوقتا که سودی نداره یا حتی باعث ضرر میشه با چاقو طرف رو میزنن).

من اینا رو برام پیش نیومده بود و دقت نکردم تا اینکه شما بحث رو باز کردید و تازه متوجه این موارد شدم

[Unique]

یعنی شما میگی حتما باید مقادیر رو بصورت عددی مشخص کنیم و ورودی کاربر رو تبدیل به عدد کنیم؟ چرا؟

بله باید چک کنیم عدد باشه چون مقدار مورد بررسی عدد هست ! اگه بخوام بهش فکر نکنم ممکنه PHP همون تبدیل های مورد نظرت را انجام بده ! یعنی وقتی بحث عدد میاد وسط باید ورودی اعتبار سنجی بشه ! چرا و این حرفا نداره ! میتونه خیلی مشکلات به وجود بیاره !


خب منکه موارد پست اول رو از همین منبع گلچین کردم و لینک منبع رو هم گذاشتم!
ندیدم توی پست اولت ! داشتم وبگردی میکردم بهش خوردم ! (مرد مومن حداقل جمله بندی ها را عوض میکردی ! یه جورایی ترجمه کردیش)


مونه کدی رو که در این پست گذاشتم بررسی کن ببین بنظرت بدون مشکله؟
توی نمونه ای که گذاشتی استدلالت به نظر من درست نیست !‌چون باید ورودی کاربر را بر اساس اون چیزی که فکر میکنی باید باشه اعتبار سنجی کنی که اگه نکنی از این مشکلات پیش میاد !


من به استاتر کاری ندارم ولی تمام موضوعاتی که بیان میکند موارد عادی است و اگر برنامه نویس یکم دقت در کار داشته باشد هیچ مشکلی نیست .
صحبت های استاتر مصداق این است که من یک نمونه sql injection را ذکر کنم و کلی آسمان ریسمان ببافم که بدترین طراحی در زبان SQL وجود داره چون میشه انجکشن زد ...
این ها باگ نیست ، کم توجهی برنامه نویس است .

کل بحث استاتر اینه که Type Conversation توی == در PHP متفاوت تر از زبان های اسکریپتی معادل هست و این تبدیل های زورکی باعث میشه گاهی اوقات برات دردسر ساز بشه و ایشون این را یک طراحی بد میدونن. راستش اصل حرفش اشتباه نیست اما کاربران با تجربه بیشتر ، عموما انقدر اعتبار سنجی و فیلتر انجام میدن که توی این مرحله به مشکل نمیخورن.

[مهرداد سیف زاده]

ممنون از SZsXsZS (http://barnamenevis.org/member.php?374132-SZsXsZS) عزیز بحث خیلی جالبی باز کردین ممنون میشم شما و یا سایر اساتید عزیز کامل ترش کنید و اگه امکان داره تمام مورادی که رفتار ابهام دارن رو ذکر کنید زبان php یک زبان محبوب با مزیتهای بیشماره و نمیشه ازش گذشت با تشکر

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