مقالات

WebMatrix توسعه وب را آسان تر می کند

مایکروسافت به تازگی ابزار جدیدی برای توسعه دهندگان وب به نام WebMatrix ارائه کرده است که سفارشی کردن وب اپلیکیشن های موجود یا ساخت یک وب سایت جدید را با امکانات خوب و راه حل های ساده، آسان می کند. این ابزار سبک به افراد کمک می کند تا به راحتی برنامه نویسی با ASP.NET را شروع کنند و خیلی زود در آن پیشرفت کنند. WebMatrix شامل ابزارهای مهم مایکروسافت برای توسعه وب  است. این ابزارها شامل :

  • IIS Developer Express : یک وب سرور سبک و رایگان که با تمام نسخه های ویندوز و نسخه کامل IIS سازگار است.
  • ASP.NET : یک فریم ورک رایگان شامل کلاس های پایه برای توسعه وب.
  • SQL Server Compact : یک نسخه embedded و بسیار سبک و رایگان از SQL Server که بر اساس فایل کار می کند.
  • Razor Syntax : یک View Engine جدید و ساده برای ASP.NET که کدهای سمت سرور سی شارپ یا ویژوال بیسیک را با کدهای HTML ترکیب می کند (مانند  PHP) و یادگیری آن ساده و لذت بخش است.

وب ماتریکس

WebMatrix با استفاده از تکنولوژی های بالا، یک محیط مجتمع ساده و در عین حال قدرتمند برای ساخت وب سایت های داینامیک و مطابق با استاندرادهای جدید به ساده ترین شکل ممکن در اختیار کاربر خود قرار می دهد. شما با وب ماتریکس می توانید یک وب اپلیکیشن اوپن سورس مثل BlogEngine.NET را انتخاب کنید، آن را بر اساس نیاز خود سفارشی کنید و به راحتی آن را بر روی هاست خود پابلیش کنید. پروسه استفاده از وب اپلیکیشن های اوپن سورس در اینترنت با WebMatrix بسیار آسان خواهد بود. شما با وب ماتریکس حتی قادر به انتخاب CMSهای نوشته شده با PHP مثل وردپرس، جوملا و Drupal نیز هستید و حتی می توانید آن ها را با ابزارهای موجود در وب ماتریکس توسعه داده و از همانجا بر روی هاست خود پابلیش کنید.

برای شروع شما می توانید WebMatrix را از اینجا دانلود کنید. اگر دات نت فریم ورک 4.0 را نصب نداشته باشید، کمی حجم دانلود وب ماتریکس بالا خواهد بود، در غیر این صورت با دانلود 15 تا 20 مگابایت WebMatrix را در اختیار خواهید داشت. پس از اجرای آن با یک محیط ساده مواجه خواهید شد که فقط 4 انتخاب را پیش روی شما می گذارد. می توانید یک سایت جدید خالی ایجاد کنید یا از وب اپلیکیشن های موجود در گالری مایکروسافت برای شروع استفاده کنید. هر طور که شروع کنید، وب ماتریکس به شما اجازه مدیریت بر صفحات سایت و تغییر آن ها، مدیریت بر فایل های وب سایت، مدیریت بر دیتابیس سایت و در نهایت پابلیش سایت بر روی سرور را می دهد.

Microsoft Web Gallery

همانطور که اشاره شد، شما در وب ماتریکس می توانید از سینتاکس Razor برای نوشتن کدهای سی شارپ و ویژوال بیسیک در میان کدهای HTML بهر ببرید. یادگیری سینتاکس Razor خیلی آسان است. شما کدهای خود را با یک علامت @ آغاز می کنید و بلاک کد خود را در سی شارپ با { و } محصور می کنید. هر جا که از علامت @ استفاده کنید یعنی می خواهید یک کد سمت سرور را بنویسید. از متغیرها بدون تعیین نوع آن ها استفاده می کنید، سپس ASP.NET خودش بهترین تصمیم را برای تعیین نوع متغیر بر اساس مقداری که درون آن ذخیره می شود خواهد گرفت. صفحاتی که دارای کد Razor هستند دارای پسوندهای مخصوص cshtml یا vbhtml خواهند بود. سینتاکس Razor تمام قدرت ASP.NET را با قواعدی آسان تر در اختیار مبتدیان قرار می دهد، اما حرفه ای ها نیز می توانند به بهترین شکل برای بالا بردن کارایی خود از آن استفاده کنند. یک کد بسیار ساده با سینتاکس Razor را ببینید :


<html>
<head>
<title>Razor Syntax Sample</title>
</head>
<body>

@{
var message = «Hello World.»;
var today = DateTime.Now.ToString();
}

<p>Message : @message</p>
<p>Today is : @today</p>
</body>
</html>

اینطور که پیداست مایکروسافت راه درستی را انتخاب کرده و باید منتظر تکنولوژی های جدیدتر و بهترش در زمینه توسعه وب باشیم. اینکه نظر مایکروسافت در این چند سال اخیر نسبت به نرم افزارهای اوپن سورس تغییرات مثبت زیادی داشته خیلی خوب و سازنده است. مایکروسافت نیز اهمیت استفاده از وب اپلیکیشن های اوپن سورس را در توسعه وب به خوبی می داند و به همین دلیل Microsoft Web Gallery را راه اندازی کرده و توسعه دهندگان را به جای باز تولید اپلیکیشن های تکراری به استفاده و توسعه وب اپلیکیشن های اوپن سورس موجود تشویق می کند. Web Platform Installer و WebMatrix دو ابزار مهم مایکروسافت در زمینه توسعه وب هستند که به صورت توکار از وب اپلیکیشن های اوپن سورس پشتیبانی می کنند و قادرند آن ها را دانلود، تنظیم و پابلیش کنند. تکنولوژی های تحت وب هرچه بازتر باشند بیشتر مورد تایید و مورد اعتماد توسعه دهندگان وب خواهند بود، این را مایکروسافت به خوبی می داند. بدون شک در آینده ای نه چندان دور از WebMatrix و Razor Syntax بیشتر خواهیم شنید.

منابع بیشتر در مورد WebMatrix

ASP.NET، PHP، مقالات

PHP برای برنامه نویسان ASP.NET – قسمت هشتم

قسمت اولقسمت دوم قسمت سوم قسمت چهارم قسمت پنجمقسمت ششم قسمت هفتم

شیء گرایی در PHP

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

class Human
{
private string _name;
public string Name;
public string Family;
public int Height;
public int Weight;
public int Age;

public Human()
{
Console.WriteLine("a Human Created.");
}
}

class Student: Human
{
public long ID { get; set; }
public string Grade;

public Student()
{
Console.WriteLine("a Student Created.");
}

public void DisplayInformations()
{
Console.WriteLine(this.ID.ToString());
Console.WriteLine(this.Name);
Console.WriteLine(this.Family);
Console.WriteLine(this.Age);
Console.WriteLine(this.Grade);
}

~Student()
{
Console.WriteLine("a Student Destroyed.");
}
}

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

<?php
class Human {
private $_name;
public $Name;
public $Family;
public $Height;
public $Weight;
public $Age;

function __construct() {
print "a Human Created.";
}
}

class Student extends Human {
public $ID;
public $Grade;

function __construct() {
parent::__construct();
print "a Student Created.";
}

function DisplayInformations() {
print $this->ID;
print $this->Name;
print $this->Family;
print $this->Age;
print $this->Grade;
}

function __destruct() {
print "a Student Destroyed.";
}
}
?>

همانطور که می بینید سینتاکس PHP برای تعریف یک کلاس شبیه به سی شارپ است. خب به هر حال هر دو از خانواده زبان C هستند! در PHP نیز شما می توانید از private, public و protected برای تعیین چگونگی دسترسی به متغیرها (فیلدها) و توابع استفاده کنید. هنگامی که هیچکدام از این ها را در خط تعریف متغیر یا تابع ذکر نکنید به صورت پیش فرض آن عضو به عنوان public در نظر گرفته خواهد شد. در PHP هر کلاس تشکیل شده از تعدادی متغیر و تابع و در صورت نیاز سازنده و مخرب. سازنده یا Constructor کلاس در سی شارپ متد همنام با خود کلاس است. همانطور که در مثال بالا مشاهده می کنید، هر دو کلاس متدی همنام با خودشان دارند که هنگام ساخته شدن در زمان اجرا صدا زده می شوند. در PHP نسخه های قبل از 5، تعریف سازنده کلاس به همین صورتی که در سی شارپ است، بود. در نسخه 5 شما باید تابعی به نام __construct() برای پیاده سازی سازنده کلاس تعریف کنید.

برای ارث بری از یک کلاس در PHP ازکلمه کلیدی extends به همان صورتی که در مثال مشاهده می کنید، استفاده می کنیم. این یعنی کلاس Student تمام خاصیت ها (در اینجا متغیرها) و توابع کلاس پدر خود یعنی کلاس Human را به علاوه متغیرها و توابعی که در بلاک خودش تعریف شده را دارد. برای اینکه هنگام ساخته شدن کلاس Student تابع سازنده کلاس پدرش Human نیز اجرا شود باید آن را به صورت parent::__construct() صدا بزنید. تابع مخرب در PHP نیز بوسیله نوشتن تابع __destruct() امکان پذیر است.

استفاده از کلاس

برای استفاده از یک کلاس به راحتی همانند سی شارپ ابتدا از آن بوسیله کلمه new نمونه سازی کنید و از توابع مورد نیاز خود استفاده کنید.

<?php
$objStudent = new Student();
$objStudent->Name = "Iman";
$objStudent->Family = "Nemati";
$objStudent->Age = "22";
$objStudent->DisplayInformations();
?>

هنگام new کردن یک کلاس، تابع __construct() آن کلاس اجرا می شود. برای دسترسی به اعضای public یک کلاس در PHP باید از عملگر <- بلافاصله پس از نام متغیر کلاس استفاده کنید.

اعضای Static

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

<?php
class Sample {
public static function StaticMethod() {
//Some Function
}
}

//
Sample::StaticMethod();
?>

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

farasun.wordpress.com

مشترک فید فراسان شوید!

ASP.NET، مقالات

نکات امنیتی برای برنامه نویسان ASP.NET

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

در این مطلب کوتاه با نکاتی آشنا خواهید شد که اگر آن ها را بکار ببرید می توانید تا حدی امنیت وب اپلیکیشن های خود را تامین کنید.

ASP.NET Security Tips

1) داده های ورودی کاربران را اعتبارسنجی کنید

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

2) اطلاعات حساس را کد کنید

قانون دوم : هر اطلاعاتی را که فکر می کنید ممکن است از آن سوء استفاده شود را کد کنید. حتماً Username و Password کاربران را کد کرده و سپس ذخیره کنید. Hash کردن رمز عبور یکی از بهترین و مطمئن ترین راه ها برای تامین امنیت رمزعبور کاربران است. برای این کار در دات نت راه حل های خوبی وجود دارد. اطلاعات حساس دیگر مثل Connection String دیتابیس خود را حتماً Encrypt کنید. در ASP.NET توصیه شده است به جای اینکه رشته اتصال دیتابیس خود را در کدهای خود بنویسید، آن را به صورت جداگانه در فایل Web.config تعریف کنید. از آن جایی که فرمت این فایل XML است و امنیت پایینی دارد، شما باید تمام اطلاعات حساس این فایل از جمله Connection String را کد کرده و سپس ذخیره کنید.

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

3) اطلاعات تکنیکی را از دید کاربران مخفی کنید

در برنامه های ASP.NET هنگامی که خطایی رخ می دهد که توسط برنامه هندل نشده، تمام اطلاعات تکنیکی مربوط به خطای مذکور با ذکر جزئیات و حتی خطی از برنامه که خطا در آن اتفاق افتاده است توسط کاربران قابل مشاهده است. البته این تنظیمات پیش فرض ASP.NET برای زمان توسعه در Localhost و خطایابی مناسب است که هنگام پابلیش وب اپلیکیشن بر روی اینترنت یا اینترانت باید تغییر کند. متاسفانه برخی از برنامه نویسان ناشی هنگام توزیع وب اپلیکیشن خود همان فایل web.config روی لوکال هاست خود را بدون هیچ تغییری بر روی محیط اجرایی قرار می دهند. این گونه پیغام های خطای ASP.NET معمولاً اطلاعات مناسبی در مورد آسیب پذیری های یک وب سایت در اختیار یک هکر قرار می دهد. برای حل این مشکل شما باید تمام خطاهای ممکن را هندل کنید و مقدار ویژگی customErrors در فایل web.config را برابر RemoteOnly قرار دهید.

<customErrors mode=«RemoteOnly«></customErrors>

4) حالت دیباگ را غیرفعال کنید

هنگام توسعه یک وب اپلیکیشن در ASP.NET حالت Debug به صورت پیش فرض true است. شما باید پس از توسعه و هنگام آپلود وب اپلیکشن در یک هاست اینترنتی خاصیت debug در قسمت compilation فایل web.config را برابر false قرار دهید. این کار هم کارایی برنامه تحت وب شما را بالاتر می برد و هم از نشان دادن برخی از خطاها که باعث لو رفتن کدهای شما می شود جلوگیری می کند.

5) مواظب حملات SQL Injection باشید

این نوع حملات در اکثر وب سایت های اطلاعاتی مبتنی بر دیتابیس مرسوم است. به این صورت که کاربر/هکر یک کد SQL را به برنامه شما تزریق می کند و باعث ایجاد خرابکاری می شود. با وجود خطرناک بودن و جدی بودن این نوع حمله باز هم هستند برنامه نویسانی که به این مورد توجهی ندارند. به طور مثال در یک فرم لاگین نا امن که کوئری چک کردن Username و Password شبیه به کد زیر باشد، حمله SQL Injection به راحتی امکان پذیر است.

string query = «SELECT * FROM Users WHERE username='» +
txtUsername.Text + «‹ AND password='» + txtPassword.Text + «‹»;

در این موقعیت یک فرد نسبتاً باهوش با نوشتن رشته x› or username like %x در فیلد password به راحتی می تواند فرم لاگین شما را رد کرده و خود را به عنوان یک کاربر قانونی جا بزند. برای جلوگیری از این مشکل حتماً قانون اول را رعایت کنید و به جای استفاده از مقادیر تکست باکس ها به این صورت، از کلاس SqlParameter برای مقداردهی استفاده کنید. یکی از راه های دیگر برای جلوگیری از این حمله استفاده از ORMهایی مثل LINQ  to SQL است.

6) جلوگیری از حملات Cross-site Scripting

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

7) سیستم لاگین خود را امن بسازید

روش مرسوم برای پیاده سازی سیستم لاگین در وب، روش استفاده از Session است. Session متغیرهایی هستند که بر روی سرور به ازای هر کاربر لاگین شده ساخته می شوند و وب اپلیکیشن با چک کردن متوالی آن در هر صفحه هویت کاربر وارد شده را شناسایی می کند. یک Session معمولاً برای یک مدت زمان محدودی (مثلاً 20 دقیقه) اعتبار دارد و پس از آن کاربر دوباره باید به سیستم لاگین کند. در ASP.NET بهترین و امن ترین راه برای پیاده سازی لاگین استفاده از ویژگی خوب تشخیص هویت خود دات نت است. منظورم همان FormsAuthentication است که شما با آن می توانید یک سیستم لاگین بسیار امن پیاده سازی کنید. به هیچ وجه از کوکی ها برای پیاده سازی یک سیستم لاگین استفاده نکنید! از کوکی ها فقط برای پیاده سازی قابلیت «Remember Me» استفاده کنید آن هم با کلی احتیاط! یک نکته دیگر در مورد لاگین این است که تعداد تلاش های ناموفق یک کاربر برای لاگین را محدود کنید. مثلاً بعد از 5 بار وارد کردن اشتباه رمز عبور به او تا یک مدت اجازه ورود ندهید!

8 ) در مواقع لازم از تصاویر امنیتی استفاده کنید

این نکته را در اکثر وب سایت ها و هنگام ثبت نام دیده اید. مثلاً گوگل در هنگام ثبت نام شما را مجبور می کند که یکسری حروف عجیب و غریب را که در عکس می بینید درون تکست باکس وارد کنید تا بفهمد شما آدم هستید! شما هم سعی کنید در اکثر فرم هایی که نیاز به لاگین کاربر ندارند (مثل فرم ثبت نام یا فرم تماس) از این تصاویر استفاده کنید.

9) امنیت دیتابیس خود را تامین کنید

معمولاً دیتابیس های SQL Server دارای امنیت بسیار خوبی هستند اما اگر از دیتابیس Access برای ذخیره اطلاعات استفاده می کنید حتماً 1- روی فایل آن پسورد بذارید 2- مطمئن شوید که فولدری که فایل دیتابیس در آن قرار دارد توسط کاربران قابل دسترسی نباشد 3- حتماً اطلاعات داخل آن را کدگذاری کنید.

farasun.wordpress.com

مطالب مرتبط :

فناوری، مقالات، وب 2.0

مصائب فلش! یا چرا اپل از فلش استفاده نمی کند؟

فلشFlash نام بزرگی در دنیای اینترنت و PCهاست که این روزها آینده و حیاتش به چالش جدی کشیده شده است. با سر و صدایی که اپل با پشتیبانی نکردن از ادوبی فلش در محصولات خود از جمله iPad و iPhone راه انداخت و با ارائه HTML 5 که امکانات چند رسانه ای فوق العاده خوبی به توسعه دهندگان وب می دهد، تردید بسیار جدی ای در آینده Adobe Flash بوجود آمده است. فلش در زمان پیدایش خود یک پدیده دوست داشتنی و مدرن بود. پدیده ای که به شما اجازه می داد با کمترین دانش و کمترین زحمت انیمیشن های اینتراکتیو بسیازید و از آن ها در وب استفاده کنید. مشکل فلش شاید این بود که مثل تکنولوژی های دیگر زود به زود تغییر نکرد و همان رویه اولیه خود را دنبال کرد تا به امروز که دیگر جوابگوی نیازهای توسعه دهندگان وب و حتی کاربران اینترنت نیست.

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

موتورهای جستجو فلش را دوست ندارند!

یکی از مهمرین دلایل برای عدم استفاده از فلش، ایندکس نشدن محتویات فایل های فلش در موتورهای جستجوست. اطلاعات مخفی شده در فایل های گرافیکی مثل فایل های فلش برای موتورهای جستجو قابل دسترسی نیستند، هرچند موتورهای جستجوی پیشرفته ای مثل گوگل سعی می کنند محتویات فایل های فلش را نیز ایندکس کنند، اما این عمل با محدودیت های بسیار زیادی مواجه است. وب سایت هایی که کاملاً با فلش ساخته شده اند وضع بسیار نامناسبی از نظر SEO دارند. تگ های متا در فایل های HTML از مهمترین عناصر مربوط به SEO هستند که در وب سایت های Full Flash قابل استفاده نیستند. فایل های فلش معمولاً اطلاعات متنی بسیار کمی ارائه می کنند و اکثراً برای تاثیر گذاری بیشتر فایل های عکس و فیلم را به نمایش می گذارند. گوگل چند وقت پیش از بهبود جستجوی text در فایل های فلش خبر داد و ایندکس کردن اطلاعات عکس، فیلم و انیمیشن بکار رفته در یک فایل فلش را منتفی دانست.

فلش استانداردهای Usability وب را رعایت نمی کند

سایت های فلش زیبا و چشم نواز هستند. شاید برای یک کاربر عادی استفاده از یک سایت فلش حتی راحت تر از استفاده از یک وب سایت معمولی ساخته شده با HTML و CSS باشد. اما محدویدت هایی که فلش برای یک کاربر ایجاد می کند استانداردهای قابل استفاده بودن وب را زیر پا می گذارد. به طور مثال در یک وب سایت فول فلش سعی کنید از دکمه Back مرورگر خود استفاده کنید، متاسفانه کار نمی کند. سعی کنید قسمتی از متن را انتخاب و کپی کنید، یا سعی کنید با استفاده از امکانات مرورگر خود اندازه متن را بزرگ و کوچک کنید! متاسفانه هیچکدام از این امکانات کار نمی کنند. اصلاً یک نکته مهم دیگر : در وب سایت های فول فلش شما نمی توانید استایل صفحه را با استفاده از ابزارهایی مثل Stylish بر اساس سلیقه خود تغییر دهید!

کاربرانی که فلش ندارند!

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

دلایل اپل برای استفاده نکردن از فلش

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

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

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

به هر حال با ارائه HTML5 و CSS3 باید منتظر کم رنگ تر شدن هرچه بیشتر نقش Adobe Flash در توسعه وب باشیم. شرکت مایکروسافت نیز همانند گوگل و اپل در مرورگر خود اینترنت اکسپلورر 9 از HTML5 پشتیبانی خواهد کرد و این یعنی آینده وب را تکنولوژی های بازی همچون HTML, CSS و JavaScript خواهند ساخت.

دلایل دیگر برای عدم استفاده از فلش

در وب سایت های فول فلش معمولاً URLهای یکتایی برای هر صفحه وجود ندارد. این مسئله باعث می شود کاربران نتوانند یک صفحه خاص از سایت را بوکمارک کنند و موتورهای جستجو نیز قادر به تفکیک صفحات مختلف از هم نخواهند بود.

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

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