ارسال پاسخ 
 
امتیاز موضوع:
  • 1 رأی - میانگین امتیازات: 5
  • 1
  • 2
  • 3
  • 4
  • 5
ساختار و تاریخچه کامپیوتر و زبانهای برنامه نویسی
02-12-2017, 03:41 AM
ارسال: #1
ساختار و تاریخچه کامپیوتر و زبانهای برنامه نویسی
در اين مقاله من شما را با چيزي كه دقيقاً بعد برنامه نويس بايد بداند آشنا مي كنم. همه چيز در مورد متون وسيع asciiz=تعداد كاراكترها 8 بيت اشتباه است. اين نااميدانه اشتباه است. و اگر شما همچنان از اين راه برنامه مي نويسيد از دكتي كه به ميكروبها اعتقاد ندارد بهتر نيستيد. لطفاً تا اين مقاله را تمام نكرديد خط ديگري كد ننوسيد.
قبل از اينكه شروع كنم من بايد به شما هشدار بدهم كه اگر شما جزء آن دسته افراد نادري كه به مسئله جهاني سازي آگاهي دارند هستيد متوجه مي شويد كه تمام اين بحث يك بيت كوچك خيلي ساده است. من واقعاً سعي كردم كه كمترين مانع را در اينجا بكار گيرم به صورتي كه هر كس متوجه شود كه چه شده است و بتواند كدي را بنويسيد كه اميدوار است با تمامي زبانها به جز زيرمجموعه هاي انگليسي كه فاقد لغت و تلفظ هستند كار كند. و همچنين بايد هشدار دهم كه دستگاري كاركترها فقط يك كار كوچك است از آن چندي كه باعث ايجاد يك نرم افزار كه به صورت ابتدايي كار مي كند. ولي من تنها در مورد يك چند مي توانم در زمان مثل امروز بنويسم و آن دستگاه كاركترهاست.

دورنماي تاريخي
ساده ترين راه براي فهميدن اين موضوع اين است كه براساس زمان حركت كنيم.
شما احتمالاً فكر مي كنيد كه من مي خواهم در مورد دستگاههاي كاركتر خيلي قديمي مانند EBCBIC صحبت كنم. خوب من باختم. EBCDIC مربوط به زندگي شما نيست. ما نمي خواهيم اين قدر به عقب بازگرديم.
به قديم باز مي گرديم. زماني كه unix اختراع شد و زبان برنامه نويسي C به وسيله K&R نوشته شد. همه چيز ساده بود. تنها كاركترهايي مهم بود حروف انگليسي بود كه ما كدي به نام ASCII براي آنها داشتيم كه قادر بود هر كاركتر را به وسيله اعداد بين 32 و 127 جايگزين كند. فاصله 32 بود حرف A65 و.... . اين مي توانست به راحتي در 7 بيت ذخيره شود. در آن زمان اكثر كامپيوترها از بايتهاي 8 بيتي استفاده مي كردند. بنابراين تنها شما مي توانستيد هر كاركتر ASCII ممكن را ذخيره كنيد بله مي توانستيد از يك بيت خالي هم چشم پوشي كنيد تا اگر شما نابكار باشيد براي منظورهاي بيراهه از آنها استفاده كنيد. لامپهاي خاموش wordstaros حقيقتاً بيتهاي بالا را روشن مي كنند تا نشان دهند كه آخرين حرف در كلمه wordstar را تنها محكوم به متون انگليسي مي كند. كدهاي كمتر از 32 كه غيرقابل چاپ ناميده مي شوند فقط براي تمسخر اند. آنها براي كنترل كاركترها استفاده مي شوند. مثلاً 7 كه براي اينكه كامپيوتر شما توليد صدا كند ساخته شده و يا 12 كه باعث مي شود يك صفحه از پرينتر بيرون آيد و يك صفحه جديد جايگزين آن شود.
چون بايتها تا 8 بيت فضاي خالي دارند. اكثر مردم گمان مي كننند كه ما مي توانيم از كدهاي 255-128 استفاده كنيم. اكثر مردم اين عقيده را در يك زمان داشتند و آنها عقيده داشتند كه در فضاي بين 255-128 چه بايد كرد. IBM PC چيزي كه به عنوان دستگاه كاركتر OEM شناخته مي شد را داشت كه اين دستگاه كاركترهايي براي زبانهاي اروپايي و يك دسته از خطوطي كه كاركتر را مي ساختند فراهم مي كرد. بارهاي افقي و بارهاي عمودي و شما مي توانيد از اين كاركترهاي طراحي خط براي ساختن مكعب و خطوط زيبايي بر روي صفحه نمايش اقدام كنيد. كه شما همچنان مي توانيد اجراي آن را بر روي 8088 كامپيوتر مشاهده كنيد. در حقيقت به محض اينكه مردم اقدام به خريد PC از خارج از آمريكا كردند تمام انواع دستگاه هاي كاركتر OEM جعل شد كه همه آنها كاركترهاي بيشتر از 128 را براي مقصد خود استفاده كردند. براي مثال در كاركتر برخي PCها كد 135 را با e نمايش مي دهند. اما در كامپيوترهايي كه در اسرائيل فروخته شد اين كه سومين حرف عربي الفباي يهودي بود. بنابراين زماني كه آمريكايي ها resumes را براي اسرائيلي ها مي فرستادند آنها آن را به صورت دريافت مي كردند. در اكثر موارد مثل روسي تفاوتهاي زيادي عقيده اي براي استفاده از كاركترهاي بيشتر از 128 وجود داشت. بنابراين شما نمي توانيد اسناد روسي را با ضريب اعتماد بالا معاوضه كنيد.
سرانجام اين OEM براساس استاندارد ANSI كدبندي شد. دراستاندارد ANSI همه بر اينكه براي كمتر از 128 چه بايد كرد توافق داشتند كه تاحدي مانند ASCII بود ولي تفاوتهاي زيادي در استفاده از كدهاي 128 به بالا بود. به محل زندگي شما مربوط مي شد. اين تفاوت سيستم ها را code page مي ناميدند. براي مثال در اسرائيل dos از code page 128 استفاده مي كرد و در يونان از 737. آنها در كمتر از 128 مشابه هم عمل مي كردند ولي براي بيشتر از آن تفاوت داشتن و جايي كه تمام حروف جالب در آنجا بودند. نسخه بين المللي MS-DOS دو جين از اين كدها را استفاده مي كرد. همه چيز از انگليسي به ايسلندي تغيير يافت و آنها چند صفحه كند چند مليتي كه مي توانستند در كامپيوترهاي مشابه كار كنند. ولي بگذاريد بگويم ك عربي و يوناني در يك كامپيوتر كاملاً غيرممكن بود مگر اينكه شما برنامه سفارشي خود را بنويسيد كه به وسيله استفاده از گرافيك هاي بيت مپ همه چيز را نمايش دهد چون عربي و يوناني براي اعداد مختلف بالا به code pageهاي مختلف نياز دارند.
ضمناً در آسيا چند ديوانه كننده اي كه بايد در نظر گرفته مي شود اين حقيقت بود كه الفباي آسيا هزاران حرف دارد كه هرگز در 8 بيت جاي نمي گرفت. اين معمولاً به وسيلة يك سيستم شلوغي به نام DBCS حل مي شد. Double byte character set كه بعضي حروف در يك بايت برخي ديگر در 2 بايت ذخيره مي شدند. آسان بود كه در string به جلو حركت كنيم اما غيرممكن بود كه به عقب برگرديم. برنامه نويس ها توصيه مي كردند كه از S-- , S++ براي جلو و عقب رفتن استفاده نشود ولي در عوض از برنامه هايي مانند ديفيوز ansiprev , ansinext استفاده شود. ولي همچنان اكثر مردم وانمود مي كردند كه بايت همان كاركتر بود و كاركتر 8 بيت بود و تا زماني كه شما برنامه را از يك كامپيوتر به كامپيوتر ديگر و يا به بيشتر از يك زبان صحبت مي كرديد ممكن بود هميشه كار كند. ولي البته به محض اينكه اينترنت به وجود آمد بسيار ساده بود كه از يك كامپيوتر به كامپيوتر ديگر رفت خوشبختانه Unicode اختراع شد.

Unicode
Unicode يك تلاش شجاعانه براي ايجاد يك دستگاه كاركتر تنها بود كه شامل تمام سيستمهاي نوشتاري بر روي زمين بود و برخي عقيقده داشتند كه چيزي مانند klingon بود. برخي مردم اين تصور غلط را داشتند كه Unicode يك كد 16 بيتي بود يعني هر كاركتر 16 بيت بود و بنابراين 65.536 كاركتر ممكن وجود داشت. اين دقيقاً صحيح نبود. اين يك تخيل عمومي در مورد Unicode بود. بنابراين اگر شما هم اين چنين فكر مي كنيد ناراحت نباشيد.
در حقيقت Unicode يك راه ديگر براي فكر كردن در مورد كاراكترها انتخاب كرد. و شما بايد راه Unicode براي تفكر در مورد هر چيزي كه احساس مي شود را بفهميد.
تاكنون ما در نظر مي گرفتيم كه حروف بر روي بيتها نقش مي بندند و شما مي توانيد آنها را بر روي ديسك و يا حافظه ذخيره كنيد. 01000001=A
در Unicode حرف بر روي چيزي به نام codepoint نقش مي بندد كه هنوز به عنوان يك فرضيه است. اينكه چگونه codepoint بر روي ديسك يا حافظه ذخيره شود و تمام ماهيت داستان است.
در Unicode حرف A يك ايده آل برنامه ريزي است. كه فقط در آسمان شتاور است.
منطق برنامه نويسي A از B و از a متفاوت است ولي مشابه A , A , A مي باشد. به نظر نمي رسد اينكه A در فونت Time new roman در كاركتر مشابهي با A در فونت Helvetica قرار دارد ولي با a در موارد ديگر تفاوت دارد زياد بحث انگيز باشد. ولي در برخي زبانها اينكه هر حرف چه شكلي بايد داشته باشد ممكن است باعث بحث شود. آيا حرف B آلماني يك حرف حقيقي است و يا تنها راه خيالي نوشتن SS است؟ اگر شكل حرفي در انتهاي كلمه عوض شود آيا حرف متفاوتي است؟ يهودي مي گويد آري و عربي مي گويد نه. به هر حال افراد با هوش در ائتلاف uncode اين را در دهه گذشته كشف كردند و همچنين با مقدار زيادي باحث هاي پارلماني سياسي زياد همراه بود و شما نبايد در اين مورد نگران باشيد. آنها كاملاً اين را كشف كردند. هر حرف در هر الفبا به وسيله اعداد جادويي Unicode نشان داده مي شد و مانند اين بود U+0645. اين اعداد جادويي را code point مي گفتند. U+ به معني Unicode بود و اعدد بر مبناي 16 بودند. و U+FECg حرف عربي 4 است. U+0041 حرف انگليسي A است.شما مي توانيد همة آنها را به وسيله استفاده از برنامه char map در ويندوز 2000/xp مشاهده كنيد و يا به سايت uicode مراجعه كنيد. هيچ محدوديتي در شماره حروفي كه Unicode تعريف كرده بود وجود نداشت و در حقيقت آنها به وسعت 65.536 رسيدند ولي نه به صورتي كه هر حرف Unicode بتواند در دو بايت فشرده شود. ولي اين به هر حال يك رويا بود.
خوب اكنون ما يك string داريم.
Hello
كه در Unicode برابر با اين پنج code point مي باشد:
U+0048 U+0065 U+006C U+006CU+ 006F
فقط يك دسته از code point ها و شماره ها. ما تاكنون نگفتيم كه چگونه مي شود اين را در حافظه ذخيره كرد و يا چگونه در يك email نشانش داد.
Encoding
اين جايي است كه encoding بوجود مي آيد.
جديدترين ايده براي رمزگذاري Unicode كه منجر به يك رويا در مورد 2بايتي ها شد. بياييد اين شماره ها را در دو بايت جدا ذخيره كنيم بنابراين Hello ميشود.
0048 0065 006c 006c 006F
خوب خيلي تند نرويد. همچنين نميتواند اينگونه باشد؟
4800 6500 6C00 6C00 6F00
خوب عملاً چرا من عقيده دارم مي شود و در حقيقت كاربران جديد مي خواهند بتواند كه unicodeهايشان را در دو روش low-endien,high-endion ذخيره كنند. هر كدام از CPU آنها در آن سريع تر است و اينك صبح بود و بعدازظهر بود و دو راه براي ذخيره Unicode ها. بنابراين مردم مجبور شدند كه با يك قرارداد نامه نويس براي ذخيره FEFF در شروع هر برنامه نويسي Unicode مواجه شوند و به آن Unicode byte order mark مي گفتند و اگر شما بايتهاي بالا و پائين را swap كنيد اين مانند FFFE مي داند كه بايد بايتهاي ديگر را نيز swap كند.


==================================================
طراحی وب سایت
پروژه های برنامه نویسی تجاری
دانلود پروژه های ASP.NET وب سایتهای آماده به همراه توضیحات
دانلود پروژه های سی شارپ و پایگاه داده SQL Server همراه توضیحات و مستندات
دانلود پروژه های UML نمودار Usecase نمودار class نمودرا activity نمودار state chart نمودار DFD و . . .
دانلود پروژه های حرفه ای پایگاه داده SQL Server به همراه مستندات و توضیحات
پروژه های حرفه ای پایگاه داده Microsoft access به همراه مستندات و توضیحات
دانلود پروژه های کارآفرینی
دانلود گزارشهای کارآموزی کارورزی تمامی رشته های دانشگاهی
قالب تمپلیت های آماده وب سایت ASP.NET به همراه Master page و دیتابیس
برنامه های ایجاد گالری عکس آنلاین با ASP.NET و JQuery و اسلایدشو به همراه کد و دیتابیس SQL کاملا Open Source واکنشگرا و ساده به همراه پایگاه داده
==================================================
یافتن تمامی ارسال‌های این کاربر
نقل قول این ارسال در یک پاسخ
02-12-2017, 03:41 AM
ارسال: #2
RE: ساختار و تاریخچه کامپیوتر و زبانهای برنامه نویسی
در حالي كه اين به نظر مي رسد خوب باشد و برنامه نويس ها شكايت مي كنند كه به اينهمه نگاه كن تا زماني كه آنها آمريكايي اند و به متون انگليسي نگاه مي كنند كه به ندرت كدهاي بيشتر از U+00FE را استفاده مي كنند. همچنين ليبرالهايي در كاليفرنيا بودند كه مي خواستند نگهداري كنند. اگر آنها در تگزاس بودند نمي توانستند فكر استفاده از هر دوي بايتها و عدد را بكنند به هر حال همه اين مدارك امنيتي وجود داشتند كه از انواع دستگاههاي كاركتر DBCS , ANSI استفاده مي كردند كه مي خواستند آنها را عوض كنند؟ Moi؟ به همين دليل مردم تصميم به حذف Unicode به مدت چند سال گرفتند و در بين راه همه چيز بدتر شد.
بنابراين فكري رخشان UTF-8 را اختراع كرد. UTF-8 سيستم ديگري براي ذخيره سازي كدهاي Unicode بود. آن شماره هاي جادويي U+ در حفاظه 8 بيت را اشغال مي كردند. هر كد از 0-127 در يك بايت ذخيره مي شد فقط كدهاي 128 به بالا 2و3 و در حقيقت تا 6 بايت را استفاده مي كردند.
اين يك تأثير جانبي هم داشت و آن اين بود كه متون انگليسي در UTF=8 دقيقاً شبيه ASCII بوده بنابراين آمريكايي ها هيچ چيز اشتباهي را گزارش نكردند. مخصوصاً Hello كه به صورت U+0048 U+0065 U+006C U+006C U+006F بود به صورت 48656C6C6Fذخيره مي شد. همانطور كه مي بينيد مانند چيزي بود كه در ANSI , ASCII و هر دستگاه كاركتر OEM ذخيره ميب شد. حال اگر شما جسورانه مي خواهيد از حروف صدادار و يا حروف يوناني هستيد شما مجبور به استفاده از بايتهاي مختلفيد ولي آمريكايي ها هرگز توصيه نمي كنند.
من قبلاً سر راه رمزگذاري Unicode را به شما گفتم. روش سنتي كه آن را در دو بايت ذخيره مي كرد را UCS2 (چون 2 بايت داشت) و يا UTF-16 (چون 16 بيت داشت) مي گفتند و شما بايد كشف كنيد كه اين high-endior يا low-endior است و يك استاندارد UTF-8 معروف جديد وجود دارد كه خاصيت زيباي كاري دارد اگر شما تلاقي متون انگليسي و برنامه هاي brained را داشته باشيد كه كاملاً از وجود چيزهاي ديگري به جز ASCII بي اطلاع اند. حقيقتاً راه هاي ديگري براي رمزگذاري Unicode وجود دارد. چيز ديگري به نام UTF-7 وجود دارد كه خيلي شبيه UTF-8 است. ولي تعهد مي دهد كه بيتهاي بالا هميشه صفر هستند پس اگر شما مجبور به گذراندن Unicode از ميان انواع سيستمهاي سخت گيرانه وجود دارد كه هر كدام از code point ها را در 4 بايت ذخيره مي كند كه يك خصوصيت زيبا دارد و آن اينست كه هر code point مي تواند در بايتي كد با شماره خودش يكي است ذخيره شود، ولي هيچ كس آن مقدار حافظه را ندارد.
و در حقيقت حالا كه شما به حروف platonic فكر مي كنيد كه به وسيله كدهاي Unicode جايگزين شده اند. اين كدهاي Unicode همچنين مي توانند در برنامه هاي رمزگذاري قديمي هم رمزگذاري شوند. براي مثال شما مي توانيد استرينگ Unicode براي Hello را در ASCII و يا رمزگذاري OEM يوناني قديم و يا رمزگذاري ANSI يهودي و يا هزاران رمزگذاري كه قبلاً كشف شده انجام دهيد. بعضي از حروف ممكن است نشان داده نشوند. اگر تناسبي بين كدهاي Unicode وجود ندارد شما سعي مي كنيد كه در رمزگذاري كه مي خواهي آن را نمايش دهيد. شما معمولاً يك علامت سوال دريافت مي كند و اگر شما واقعاً خوب هستيد يك جعبه كه دريافت كرديد؟
صدها رمزگذاري سنتي وجود دارد كه فقط مي تواند برخي از كدها را صحيح ذخيره كند و بقيه كدها را به صورت علامت سوال در مي آورد. برخي از رمزگذاري هاي متون انگليسي ويندوز – 1252 و ISO-8859-1 مي باشد. مولي سعي در ذخيره حروف روسي يا يهودي در اين رمزگذاري باعث دريافت مقدار زيادي علامت سوال مي شود. VTF هاي 7و8و16و32 يك خصوصيت زيبا براي ذخيره انواع كدها به صورت صحيح را دارند.
يك حقيقت مهم در مورد رمزگذاري (Encoding)
اگر شما همه چيزهايي كه توضيح دادم را كاملاً فراموش كرديد لطفاً يك موضوع خيلي مهم را به خاطر بياوريد. اين نمي تواند از string استفاده كند بدون آنكه بداند كدام رمزگذاري استفاده شده است.
چيزي به عنوان plain text يا متون وسيع وجود ندارد
اگر شما يك string در حافظة در يك فايل و يا در يك email داريد بايد بدانيد كه در كدام encoding قرار دارند وگرنه نمي توانيد به صورت صحيح آن را نمايش دهيد. اغلب برنامه نويسهاي كند ذهن اين مشكل را دارند كه وب سايت من نامفهوم است و يا وقتي من از حروف صدادار استفاده مي كنم او نمي تواند email من را بخواند و نمي توانند اين موضوع ساده را بفهمند 1252. به سادگي نمي توانيد آن را نمايش دهيد و يا اغلب نمي توانيد پايان آن را بيابيد. صدها رمزگذاري براي كدهاي بالاي 127 وجود دارد.
چگونه مي توانيم مفهميم كه اين اطلاعات از كدام نوع رمزگذاري استفاده كرده اند؟ خوب يك راه استاندارد بر اين منظور وجود دارد. براي email شما مي توانيد انتظار داشته باشيد كه يك string در بالاي صفحه داشته باشيد. براي صفحه وب ايده اصلي اين است كه web server خودش همراه با صفحه وب مشابه http بفرستد، نه در خود HTML بلكه به عنوان يكي از response header هايي كه قبل از صفحه HTML فرستاده مي شود.
اين باعث يك مشكل مي شود در نظر بگيريد كه شما يك داراي يك server بزرگ با تعداد زيادي سايت و صدها صفحه كه بوسيله تعداد زيادي از مردم با زبانهاي مختلف استفاده مي شود. web server نمي تواند بفهمد كه هر چگونه نوشته شده و چگونه رمزگذاري شده است. بنابراين نمي تواند content-type را ارسال كند.
اين كار ممكن بود راحت باشد اگر شما مي توانستيد content-type هر فايل HTML را دقيقاً در خودش قرار دهيد. البته اين كار باعث ديوانه شدن افراد و سواتي مي شود. چه مقدار از فايل HTML را مي توانيد بخوانيد تا بفهميد كه در كدام نوع رمزگذاري قرار دارد؟ خوشبختانه اغلب رمزگذاري ها در استفاده هاي عمومي براي كاركترهاي بين 127-32 از انواع مشابهي استفاده مي كنند. شما مي توانيد آنها را بر روي صفحات HTML پيدا كنيد بدون آنكه funny letter ها استفاده كنيد.
ولي اين دستورات كامپيوتري واقعاً بايد اولين چيز در بخش head باشد چراكه به محض اينكه برنامه هاي جستجوي web اين دستورات را مشاهده مي كنند آنها تجزيه صفحات را متوقف كرده و دوباره بعد از ا ينكه تمام صفحاتي كه از رمزگذاري مخصوص شما استفاده كرده را بررسي مي كنند و آغاز به كار مي كنند.
اگر جستجوگرهاي وب هيچگونه content-type را در هيچ يك از http header ها و يا دستورات كامپيوتري پيدا نكند چه مي كند؟ internet explorer يك كار بسيار جالب انجام مي دهد. اون سعي مي كند كه براساس فركانسهاي انواع بايتها در متن نمونه در نمونه رمزگذاري انواع زبانها حدس بزند كه كدام زبان و رمزگذاري استفاده شده. به دليل انواع قديمي صفحات كد 8 بايتي كه تمايل دارند كه حروف هاي خود را در جاهاي مختلفي بين 255-128 قرار دهند و به خاطر اينكه هر يك از زبانهاي انسانها كاركترهاي متفاوتي براي استفاده از حروف دارند. اين دقيقاً باعث تغيير در كار مي شود. اين كاملاً عجيب است. ولي به نظر مي رسد كه اغلب اوقات به اندازه كافي كار مي كند كه نوييسنده هاي صفجات وب كد نمي دانند نياز دارند كه content-type header ها در صفحاتشان در جستجوگرهاي وب مشاهده شود و به نظر مي رسد در طول يك روز خوب باشد. آنها چيزهايي مي نويسند كه با فركانس حروف مطابقت ندارد و internet explorer تعميم مي گيرد كه اين كره اي است و آن را به اين صورت نمايش مي دهد. من فكر مي كنم اثبات نكته اي كه قوانين postel مي گويد در مورد آنچه حدس مي زنيد محافظه كار باشيد و در مورد چيزهايي كه قبول داريد ليبرال صادقانه بگويم اصول مهندسي خوبي نيست. به هر حال خواننده اين وب سايت كه به زبان بلغاري نوشته شده ولي كره اي به نظر مي رسد چه بايد بكند؟ او از منوي view شاخه encoding استفاده مي كند و از بين انواع رمزگذاري ها يكي را انتخاب مي كند كه صفحه واضح شود. او كاري را انجام مي دهد كه بسياري از مردم نمي توانند.
یافتن تمامی ارسال‌های این کاربر
نقل قول این ارسال در یک پاسخ
ارسال پاسخ 


پرش به انجمن:


کاربرانِ درحال بازدید از این موضوع: 1 مهمان