فردیس

«فردیس» یک پروژه‌ی Open Source خیلی کوچک است که برای کار با یونیکد ایجاد شده است. «فردیس» در یک دوره‌ی زمانی که به شدت نیاز به این داشتیم که بفهمیم فلان کلید صفحه کلید یا فلان کاراکتر دقیقاً کدام نویسه‌ی یونیکد است، کد آن چیست، نام رسمی آن در یونیکد چیست و در فونت‌های مختلف چطور نمایش می‌یابد متولد شد.

بعدها در کنار رفع این نیازها به فکر افتادم که «فردیس» فقط به صورت یک برنامه exe نباشد بلکه همه‌ی امکانات آن به علاوه دیگر امکاناتی که ممکن بود برنامه‌نویسان دیگر در ارتباط با فارسی و یونیکد به آن نیاز پیدا کنند هم به صورت یک library هم موجود باشد.

بخشی از آنچه که در مورد برنامه‌ی «فردیس» در ذهنم بوده هم اکنون پیاده‌سازی شده و بقیه‌ی آنها در Issue List پروژه موجود است. امیدوارم بتوانم به مرور زمان و بر اساس نیازمندی‌های خودم و بقیه این فهرست را تکمیل‌تر کنم.

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

لینک‌های مفید:
home page پروژه
Download پروژه
Discussions List پروژه
Issue Tracker پروژه
Source Code پروژه

Fardis

Fardis is a tiny open source project regarding Unicode and Persian/Arabic. Once a time I was in need to know more info about characters. Specially I needed to know what’s Unicode name and code of a specific character. So I created “Farids” as an .Net/C# and Windows desktop application/library.

Along with time I decided “Fardis” being a library too. So created an issue list and implemented some of them. I will implement more of them if I found them useful for myself or other users/programmers.

This task has been done with help of Nasser Hadjloo in both test and logo design.

Project links:
Home Page
Downloads
Discussions
Issue Tracker
Source Code

‫استفاده از کدام Encoding برای ذخیره فایل‌ها بهتر است؟

خیلی قدیم‌ها فایل‌های متنی صرفا در قالب اسکی (ANSI) ذخیره می‌شدند. در این قالب به ازای هر نویسه یا کاراکتر دقیقاً یک بایت وجود داشت. علاوه بر این از هیچ (مجموعه) کاراکتری در ابتدای فایل به عنوان header استفاده نمی‌شد. اما حالا با وجود code pageها و یونیکد اوضاع فرق کرده است. حالا باید برای استفاده از هر فایلی، نوع قالب آن مشخص شود تا بتوان با آن کار کرد.

یکی از مشکلاتی که معمولاً برنامه‌نویس‌ها به آن برمی‌خورند این است که اطلاعات یک فایل به فارسی ذخیره شده ولی موقع استفاده به صورت علامت سوال یا دیگر نویسه‌های نامربوط در می‌آید. برای غلبه به این مشکل و دیگر مشکلات مرتبط دانستن بعضی نکات ضروری است. من هر بار که به این طور مشکلات برخورد کرده‌ام سعی کرده‌ام آنها را در جایی یادداشت کنم تا بعداً بتوانم از آنها استفاده کنم. فهرست زیر همان مجموعه یادداشت‌های من راجع به مشکلات Encoding به خصوص در رابطه با برنامه‌نویسی و Visual Studio است.

۱- اگر در Visual Source Safe انکودینگ فایلی عوض شود دیگر قادر به انجام عملیات «مقایسه» نخواهید بود.

۲- کدپیج ۱۲۵۶ ویندوز که عربی است از حروف «ی» و «ک» فارسی پشتیبانی نمی‌کند. و اگر در Visual Studio بخواهید فایلی را که در آن از این حروف استفاده می‌کند ذخیره کنید موفق نمی‌شوید. بلکه مجبور هستید از کدپیج‌های یونیکدی مثل ۶۵۰۰۱ و ۱۲۰۰ و ۱۲۰۱ استفاده کنید.

۳- فایل‌های utf-8 را که notepad ذخیره می‌کند با امضای سه بایتی ذخیره می‌کند و حجم فایل را سه بایت افزایش می‌دهد. ولی در Visual Studio اجازه دارید utf-8 را هم با این امضا و هم بدون آن ذخیره کنید. اگر بدون امضا ذخیره کنید این سه بایت اضافه نمی‌شود.

۴- نمی‌دانم Visual Studio در حالتی که از utf-8 بدون امضا استفاده شده، از کجا می‌فهمد که فایل ما با چه انکودینگی ذخیره شده و چطور باید آن را نشان دهد.

۵- اگر فایلی را با notepad به صورت unicode ذخیره کنید دو بایت به حجم آن اضافه می‌شود. احتمالا این دو بایت به اول فایل به صورت امضا اضافه می‌شود. VS هم دقیقا به همین روش عمل می‌کند.

۶- Unicode و Big Endian Unicode مثل هم هستند به جز یک فرق: ترتیب ذخیره بایت‌ها در آنها فرق دارد. در یکی بایت پر ارزش‌تر در بایت اول و در دیگری در بایت دوم ذخیره می‌شود.

۷- utf-8 یکی از کدپیج‌های رایج است که هر کاراکتر را بسته به شرایط در ۱ الی ۶ بایت نگهداری می‌کند. کاراکترهای معمولی که همان حروف کوچک و بزرگ انگلیسی به علاوه بعضی نشانه‌ها و علامات هستند (همان ASCII معروف) به خاطر سازگاری با برنامه‌های قدیمی و به خاطر کاهش حجم فایل‌های فقط «اسکی» در یک بایت نگهداری می‌شوند. کاراکترهای زبان‌های رایج و معمولی دنیا از جمله عربی و فارسی در ۲ بایت ذخیره می‌شود. کاراکترهای دیگر زبان‌ها از جمله ژاپنی و چینی در ۳ بایت ذخیره می‌شوند و الی آخر. به این ترتیب اگر فایلی فقط حاوی حروف انگلیسی باشد به اندازه تعداد کاراکترهایش حجم دارد و اگر فقط شامل حروف عربی و فارسی باشد دو برابر تعداد کاراکترها حجم خواهد داشت. نام دیگر این استاندارد code-page 65001 است.

۸- نام دیگر یونیکد، کد پیج ۱۲۰۰ و نام دیگر یونیکد (Big-Endian)، کدپیج ۱۲۰۱ است.

۹- یونیکد آن طور که همه تصور می‌کنند که دو بایت است و حداکثر ۶۵۵۳۶ کاراکتر را نگهداری می‌کند نیست بلکه می‌تواند حدود یک میلیون و صد هزار (۱۱۱۴۱۱۲) کاراکتر را ذخیره کند و من قضیه آن را خوب نمی‌فهمم.

۱۰- برای کاربردهای ما همان utf-8 کفایت می‌کند و نیازی نیست به مسائل دیگر فکر کنیم جز این که از signature در ابتدای فایل‌ها استفاده کنیم یا نه. توجه شود که در بیشر محیط‌های لینوکسی از فایل‌ها utf-8 بدون signature استفاده می‌شود و در محیط‌های ویندوزی به طور برعکس عمل می‌شود.

۱۱- اسکی یا ASCII از ۷ بیت و درنتیجه ۱۲۸ کاراکتر تشکیل شده و در محیط‌های متنی کاربرد دارد.

۱۲- امضای سه بایتی اختیاری در ابتدای فایل‌های utf-8: این امضا یک کاراکتر یونیکد به نام Byte Order Mark یا همان BOM است که وقتی به utf-8 تبدیل می‌شود سه کاراکتر جا می‌گیرد. این سه کاراکتر عبارتند از 0xEF,0xBB,0xBF. این کاراکتر را عمدتا برنامه‌های ویندوزی برای تشخیص فایل‌های utf-8 در ابتدای آنها می‌گذارند. شکل نمایشی این سه کاراکتر به شکل  است. نام اصلی آن: )U+FEFF (zero-width no-break space

۱۳- امضای دو بایتی اجباری در ابتدای فایل‌های یونیکد: احتمالا همان امضای کاراکتر BOM است که در utf-8 به صورت ۳ کاراکتر و در یونیکد به صورت ۲ کاراکتر ذخیره می‌شود.

۱۴- نتیجه گیری کلی: چون ما از کاراکترهای غیر انگلیسی و گاها غیر عربی (مثل «ی» فارسی) استفاده می‌کنیم بهتر است از یکی از فرم‌های یونیکد استفاده کنیم. استفاده از utf-8 به خاطر حجم کمتر و سازگاری خوب با کاراکترهای انگلیسی بهتر است. با این که مدل امضا دار با بعضی محیط‌ها و برنامه‌های دیگر خصوصا انواع غیر ویندوزی ناسازگار است ولی اگر سر و کار ما فقط با ویندوز است، بهتر است از مدل امضا دار استفاده کنیم. در غیر این صورت اگر با لینوکس هم سر و کار داریم بهتر است از utf-8 بدون signature استفاده کنیم.

۱۵- یک منبع خوب برای فهمیدن کد یونیکد کاراکترها: fileformat.info

۱۶- یک منبع خوب برای فارسی و یونیکد: فارسی وب

۱۷- نوشته‌های قبلی خودم راجع به یونیکد: پیوند ۱، پیوند ۲.

آدم‌ها و سازمان‌های مرتبط با پروژه‌های فارسی سازی

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

۱- شرکت فارسی وب شریف: شرکت فارسی‌وب شریف، سهامی خاص در سال ۱۳۸۲ بر پایه گروهی به نام پروژه فارسی‌وب در مرکز محاسبات دانشگاه صنعتی شریف تأسیس شد. فعالیت‌های اصلی این شرکت توزیع و پشتیبانی لینوکس شریف، مشاوره فنی و حقوقی در مورد نرم‌افزارهای آزاد و متن‌باز، و استاندارد کردن مسائل ویژه زبان فارسی در کامپیوتر و فن‌آوری اطلاعات است.

۲- مرکز محاسبات دانشگاه شریف

۳- شورای عالی انفورماتیک: ناشر نسخه نهایی استاندارد یونیکد

۴- شورای عالی اطلاع رسانی

۵- پروژه فارسی وب: پروژه فارسی‌وب یک پروژه تحقیق و توسعه در شرکت فارسی‌وب شریف (و قبل از آن در مرکز محاسبات دانشگاه صنعتی شریف) است. این پروژه نماینده ایران در کنسرسیوم یونی‌کد است و در تعداد زیادی از فعالیت‌های استانداردسازی و توسعه نرم‌افزارهای آزاد فعالیت می‌کند.

۶- مرکز تحقیقات صنایع انفورماتیک: لازم به ذکر است که سابقاً پروژه‌ای برای اضافه کردن امکانات درست مرتب‌سازی فارسی به MySQL از طرف شورای عالی انفورماتیک کشور به مرکز تحقیقات صنایع انفورماتیک سپرده شده بود که متأسفانه شکست خورد.

۷- بهداد اسفهبد: نسخه نهایی استاندارد یونیکد، همکار در شرکت فارسی وب

۸- روزبه پورنادر: نسخه نهایی استاندارد یونیکد

۹- موسسه استاندارد و تحقیقات صنعتی ایران

۱۰- استاندارد یونیکد: استاندارد فناوری اطلاعات – تبادل و شیوه‌ی نمایش اطلاعات فارسی بر اساس یونیکد، کار مشترک شورای عالی انفورماتیک – موسسه استاندارد و تحقیقات صنعتی – تیم دانشگاه شریف در سال ۸۱ منتشر شده است. نام دیگر آن ISIR-6219 است. لینک ۱، لینک ۲، لینک ۳، لینک ۴

۱۱- گروه فارسی در شبکه مرکز محاسبات دانشگاه شریف: نتایج پروژه‌های این گروه (۱۳۷۷ تا ۱۳۸۱) در تهیه استاندارد یونیکد استفاده شده است

۱۲- نظام صنفی رایانه‌ای

۱۳- سازمان مدیریت و برنامه ریزی کشور

۱۴- انجمن شرکت‌های انفورماتیک: منحل شد و به جای آن نظام صنفی رایانه‌ای آمد. ابداع کننده پروتکل ECE هم بود.

۱۵- ISIR-3342: یک کد گذاری قدیمی حروف فارسی

۱۶- بهنام اسفهبد: همکار در شرکت فارسی وب و برخی استانداردهای سازمان استاندارد – استاندارد صفحه کلید ۹۱۴۷

۱۷- بهنام پورنادر: شرکت فارسی وب شریف – همکار در استاندارد ۹۱۴۷ – مهندس صنایع

۱۸- روزبه پورنادر: شرکت فارسی وب شریف – همکار در استاندارد ۹۱۴۷ – عضو فرهنگستان ادب و فارسی، لینک

۱۹- دستور خط فارسی مصوب فرهنگستان زبان و ادب فارسی: استاندارد ۹۱۴۷ با توجه به آن نوشته شده است.

۲۰- استاندارد ۶۲۱۹: همان استاندارد یونیکد است.

۲۱- استاندارد ۹۱۴۷: استاندارد صفحه کلید منتشره در سال ۱۳۸۶، لینک ۱، لینک ۲

۲۲- دکتر یحیی تابش: تاثیرات غیر مستقیم بر پروژه‌های فارسی سازی – عضو فرهنگستان ادب و فارسی، لینک

۲۳- استاندارد ۲۹۰۱: استاندارد صفحه کلید که توسط ۹۱۴۷ باطل اعلام شد.

۲۴- پروژه‌های متن باز فارسی وب: لینک

۲۵- اصل استاندارد فارسی (عربی) در آخرین نسخه یونیکد: لینک

۲۶- سازمان استاندارد: لینک

۲۷- شرکت PIC: لینک

۲۸- احسان اخگری: این آقا مشکل شیف اسپیس صفحه کلید Persian Experimental Keyboard را برطرف کرده و حتی به فارسی وب هم گزارش داده است. لینک

۲۹- فارسی نویسی در ویکی‌پدیا: لینک

۳۰- متنی بسیار خوب درباره مشکل زبان فارسی: لینک

۳۱- اگر شکل ممیز فارسی و ممیز عربی مثل شکل ی عربی و ی فارسی با هم متفاوت چرا مثل حرف «ی» دو کاراکتر جدا در یونیکد برای آنها در نظر گرفته نشده است؟ این قضیه در مورد جدا کننده‌های هزارتایی هم صادق است.

۳۲- تابلوترین مشکل ممیز فارسی در محیط وب (پست ۳): لینک

۳۳- تست زبان فارسی در کامپیوترتان: لینک

۳۴- مشکل نمایش ممیز انگلیسی و اعداد فارسی مثل تاریخ‌ها در IE: مرجع تست زبان فارسی

۳۵- صفحه کلید فارسی: لینک

۳۶- چرا استاندارد معرفی شده در ویستا و در لینوکس با صفحه کلیدهای رایج در کشور یکسان نیست. به مشکل حرف«پ» و«ژ» دقت کنید.

۳۷- این صفحه را در IE و FF ببینید تا متوجه مشکل نمایش ممیز فارسی در IE بشوید: لینک

۳۸- مرکز تحقیقات صنایع انفورماتیک: لینک

۳۹- مناقصات فارسی سازی لینوکس: لینک

۴۰- قبلی: لینک

۴۱- صفحه کلید استاندارد ویندوز که مشکلات برنامه فارسی وب و برنامه احسان اخگری را ندارد: لینک

۴۲- فارسی کننده فایر فاکس: لینک

مشکل اعداد فارسی و استانداردهای ۶۲۱۹ و ۹۱۴۷

یکی از مشکلات پیش روی استانداردهای ماتصا ۶۲۱۹ و ماتصا ۹۱۴۷ عدم پشتیبانی تعداد زیادی از نرم‌افزارهای موجود از اعداد فارسی است. این دسته از نرم‌افزارها به خصوص آنها که قرار است روی این اعداد پردازشی انجام دهند، یا به طور کلی از پذیرش اعداد فارسی سر باز زده یا دچار خطا شده و رفتارهای عجیبی از خود نشان می‌دهند. به طور مثال:

۱- اکسل ۲۰۰۳ اعداد فارسی را به صورت رشته در نظر می‌گیرد و نمی‌تواند عملیات ریاضی مثل جمع و تفریق را بر روی آنها انجام دهد.
۲- در Windows Live Writer اگر به هنگام ایجاد جدول جدید، طول و عرض جدول با اعداد فارسی وارد شود پیغام خطا داده و بسته می‌شود.
۳- صفحه ورود به اینترنت بانک بانک اقتصاد نوین با هر بار وارد کردن اعداد فارسی هشدار می‌دهد که استفاده از این نویسه‌ها غیر مجاز است.
۴- خیلی از نرم‌افزارهای مالی اداری تولید شرکت‌های داخلی با استفاده از MaskEdit به طور کلی مانع از ورود اعداد فارسی در فیلدهای عددی می‌شوند.
۵- …

ماتصا ۹۱۴۷ این مشکل را پیش‌بینی کرده و به همین دلیل اعداد واقع در NumPad را به همان صورت انگلیسی مورد استفاده قرار می‌دهد. اما با عادات کاربران چه کار کنیم؟ آنهایی که عادت دارند برای ورود اعداد از ردیف بالایی صفحه کلید (ردیف زیر کلیدهای F1 تا F12) استفاده کنند را چه کنیم؟ علاوه بر این مشکلاتی هم با ماتصا ۶۲۱۹ موجود است. به عنوان مثال خود ما در بخشی از نرم‌افزار مالی-اداری‌مان که اطلاعات را به قالب‌هایی مثل اکسل export می‌کند دچار مشکل شدیم. ما در این نرم‌افزار استاندارد ماتصا ۶۲۱۹ را رعایت کرده و اعداد را به صورت فارسی نمایش می‌دهیم نه انگلیسی. حال وقتی که این اطلاعات به اکسل Export می‌شوند اکسل قادر نیست بر روی آن‌ها هیچ گونه عملیات ریاضی مثل جمع و میانگین بر روی آنها انجام دهد. علت آن هم این است که اکسل با اعداد فارسی به صورت رشته برخورد می‌کند نه عدد! البته خوشبختانه این مشکل در اکسل ۲۰۰۷ بر طرف شده.

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

همان طور که پیش‌تر اشاره شد اکسل ۲۰۰۳ اعداد فارسی تولید شده توسط نرم‌افزار سازگار با ماتصا ۶۲۱۹ ما را نمی‌فهمید. با این که اکسل ۲۰۰۷ این مشکل را حل کرده ولی چون کارمندان شرکت مشتری ما حاضر نیستند از اکسل ۲۰۰۷ استفاده کنند ما مجبور شدیم یک راه ابتکاری پیدا کرده و با استفاده از ماکروی زیر اعداد فارسی را در خود اکسل به اعداد انگلیسی تبدیل کنیم:

Attribute VB_Name = “Module1”
Sub fa_support()
Attribute fa_support.VB_Description = “Macro recorded 2009/01/20 by mohebbi”
Attribute fa_support.VB_ProcData.VB_Invoke_Func = ” n14″

‘ Macro1 Macro
‘ Macro recorded 2009/01/20 by mohebbi

Cells.Replace What:=ChrW(1776), Replacement:=”0″, LookAt:=xlPart, SearchOrder _
:=xlByRows, MatchCase:=False, SearchFormat:=False, ReplaceFormat:=False
Cells.Replace What:=ChrW(1777), Replacement:=”1″, LookAt:=xlPart, SearchOrder _
:=xlByRows, MatchCase:=False, SearchFormat:=False, ReplaceFormat:=False
Cells.Replace What:=ChrW(1778), Replacement:=”2″, LookAt:=xlPart, SearchOrder _
:=xlByRows, MatchCase:=False, SearchFormat:=False, ReplaceFormat:=False
Cells.Replace What:=ChrW(1779), Replacement:=”3″, LookAt:=xlPart, SearchOrder _
:=xlByRows, MatchCase:=False, SearchFormat:=False, ReplaceFormat:=False
Cells.Replace What:=ChrW(1780), Replacement:=”4″, LookAt:=xlPart, SearchOrder _
:=xlByRows, MatchCase:=False, SearchFormat:=False, ReplaceFormat:=False
Cells.Replace What:=ChrW(1781), Replacement:=”5″, LookAt:=xlPart, SearchOrder _
:=xlByRows, MatchCase:=False, SearchFormat:=False, ReplaceFormat:=False
Cells.Replace What:=ChrW(1782), Replacement:=”6″, LookAt:=xlPart, SearchOrder _
:=xlByRows, MatchCase:=False, SearchFormat:=False, ReplaceFormat:=False
Cells.Replace What:=ChrW(1783), Replacement:=”7″, LookAt:=xlPart, SearchOrder _
:=xlByRows, MatchCase:=False, SearchFormat:=False, ReplaceFormat:=False
Cells.Replace What:=ChrW(1784), Replacement:=”8″, LookAt:=xlPart, SearchOrder _
:=xlByRows, MatchCase:=False, SearchFormat:=False, ReplaceFormat:=False
Cells.Replace What:=ChrW(1785), Replacement:=”9″, LookAt:=xlPart, SearchOrder _
:=xlByRows, MatchCase:=False, SearchFormat:=False, ReplaceFormat:=False
Cells.Replace What:=ChrW(1644), Replacement:=”,”, LookAt:=xlPart, SearchOrder _
:=xlByRows, MatchCase:=False, SearchFormat:=False, ReplaceFormat:=False
Cells.Replace What:=ChrW(1643), Replacement:=”.”, LookAt:=xlPart, SearchOrder _
:=xlByRows, MatchCase:=False, SearchFormat:=False, ReplaceFormat:=False
End Sub

مطالعه این مطالب نیز توصیه می‌شود:

۱- معرفی استاندارد ماتصا ۶۲۱۹ – ISIRI 6219
۲- معرفی استاندارد ۹۱۴۷ – ISIRI 9147

سندرم شماره نامه به هم ریخته

همه کسانی که در نوشتن نرم‌افزارهای دبیرخانه دخیل بوده‌اند با مشکلی به اسم به هم ریختگی شماره نامه آشنا هستند. شماره نامه معمولاً ترکیبی از اعداد، علائم، حروف فارسی و گاهاً انگلیسی هستند. از آنجا که ما در یک محیط دو جهته زندگی می‌کنیم هنوز در نحوه چینش صحیح این حروف در کنار یکدیگر ابهاماتی وجود دارد و مردم بسیاری از قواعد موجود را هم یا نمی‌شناسند یا اصلاً به کار نمی‌برند. در نتیجه چیزی که کاربر با هزار دردسر به عنوان شماره نامه وارد می‌کند به هنگام نمایش مجدد دچار به هم ریختگی می‌شود. مثلاً جای حروف و علائم عوض شده یا علامتی مثل خط تیره به جای آن که در سمت راست یک کاراکتر نمایش یابد به سمت چپ آن منتقل می‌شود. این قضیه وقتی تشدید می‌شود که شماره نامه ذخیره شده را بخواهیم در محیط‌های متنوعی مثل reportها، برنامه‌های ویندوزی، وب (IE و فایرفاکس)، xmlهای مربوط به پروتکل ECE و محیط‌های خام مثل SQL Server Management Studio نمایش دهیم. به عنوان نمونه به تصاویر زیر که یک شماره نامه واحد را آن طور که در محیط‌های مختلف دیده می‌شود دقت کنید:

افراد مختلف راه حل‌های مختلفی را برای غلبه بر این مشکل پیدا کرده‌ند. بعضی‌ها یک MaskEdit برای ورود شماره در نظر گرفته‌اند. بعضی‌ها شماره نامه وارده شده را به صورت یک عکس render کرده و نمایش می‌دهند. بعضی‌ها برای نمایش صحیح در صفحات وب یک ActiveX ایجاد کرده‌اند. بعضی‌ها هم قالب شماره نامه را طوری تعریف کرده‌اند که دچار مشکل کمتری شوند و این قالب را به کارفرما تحمیل کرده‌اند.


اما راه حلی که من مورد استفاده قرار داده‌ام استفاده از نویسه یونیکد LEFT-TO-RIGHT OVERRIDE است. وجود این نویسه در هر رشته‌ای باعث می‌شود کلیه نویسه‌هایی که بعد از آن وارد می‌شوند به صورت اکیداً چپ به راست نمایش نمایش یابند. یعنی انگار نه انگار محیط کار، راست به چپ است. به عنوان مثل فرض کنید می‌خواهیم جمله «پاییز زیبا است» را یک بار به صورت عادی و یک بار دیگر هم با وارد کردن این کاراکتر بین کلمات «پاییز» و «زیبا» نمایش دهیم. عکس زیر هر دو حالت را نمایش می‌دهد.

حال روش من برای استفاده از این کاراکتر این است که در رویداد OnKeyPress (یا هر رویداد مشابه دیگری) بعد از ورود هر کاراکتر توسط کاربر، این کاراکتر نیز به قبل از آن اضافه شده سپس نمایش یابد. نهایتاً به هنگام ذخیره متن وارد شده بایستی به جز کاراکتر ابتدای متن، بقیه کاراکترهای LEFT-TO-RIGHT OVERRIDE را از متن پاک کرد. چون وجود بیش از یک مورد آن غیر ضروری است. برای درک بهتر موضوع به کد جاوا اسکریپت زیر که این روش را در صفحات وب پیاده سازی می‌کند دقت کنید. بدیهی است که برای WinForm و WPF هم می‌توان این روش را به کار برد:

function ltr_override(e)
{
//‫از این تابع در onkeypress هر textBox که استفاده شود باعث می‌شود که
//کاراکترهای تایپ شده توسط کاربر به طور مطلق از چپ به راست نمایش داده
//شود. حتی اگر کاربر یک متن فارسی را وارد کند. کاربرد فعلی این تابع
//در شماره نامه است که همیشه از چپ به راست خوانده می‌شود

//‫دقت شود که رشته تولید شده توسط این تابع پر از کاراکتر یونیکد 0x202d است و
//قبل از ذخیره در بانک اطلاعاتی یا انجام هر پردازش دیگری باید از رشته مورد نظر پاک شود

var key;
var obj;
if (window.event) {
e = window.event;
obj = e.srcElement;
key = e.keyCode;
} else {
obj = e.target;
key = e.charCode;
}
//0x202d: LEFT-TO-RIGHT OVERRIDE
obj.value = String.fromCharCode(0x202d)+obj.value;
return true;
}

پ. ن. ۱: کاراکتر LEFT-TO-RIGHT OVERRIDE یکی از کاراکترهای ویژه معرفی شده در الگوریتم شماره ۹ یونیکد (الگوریتم دو جهته) و جزیی از استاندارد ماتصا ۶۲۱۹ (ISIRI 6219) می‌باشد.

پ. ن. ۲: برای مطالعه بیشتر اینجا و اینجا را بخوانید.

پ. ن. ۳: استفاده از ابزارک «فردیس» شاید بتواند در کار با نویسه‌های ویژه یونیکد کمک کند.

پ. ن. ۴: من ایده اصلی این کار را از این کتابخانه که برای شبیه سازی صفحه کلید ۲۹۰۱ در محیط‌های غیر فارسی نوشته شده بود و با نگاهی به اینجا و اینجا گرفتم.

موضوعات نرم‌افزاری که وقت نکردم روی آنها کار کنم

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

۱- مشکلات وب‌سایت‌ها و Mail Serverها با Certificate: لینک ۱، لینک ۲، لینک ۳، لینک ۴، لینک ۵
۲- نام گذاری صحیح فیلدها و متغیرها: استفاده از اسامی درست انگلیسی برای مفاهیم مالی و اداری مثل استهلاک و…
۳- googlegroup چیست و از چه پروتکلی استفاده می‌کند؟ آیا این اطلاعات در جای دیگری هم نگهداری می‌شوند یا خیر؟
۴- کار با ابزارهای فوروم مثل vBultein و CommunityServer و googlegroup و یادگیری آنها
۵- حالت recent mode در جی‌میل و ظرایف آن: اگر خواسته باشید در دات‌نت از یک حساب gmail برای ارسال/دریافت ایمیل استفاده کرده باشید حتما درگیر این ظرایف شده‌اید.
۶- معرفی Iranzilla که در Thundebird برای شمسی کردن تاریخ استفاده می‌شود.
۷- مشکلات زبان فارسی در Reporting Services:
استفاده از تگ برای نمایش اعداد به صورت فارسی، اعداد فارسی عربی،
چند زبانه کردن گزارشات rdlc، RS و چند زبانگی (لینک ۱، لینک ۲Native Mode و SharePoint Model در نصب RS، Localizing Reports، locale for RS،
ضمیمه شماره ۹ یونیکد، FriBiDi پیاده سازی ضمیمه شماره ۹ یونیکد،
توضیح propertyها
۸- از بین بردن صفحه کلید فارسی ویندوز برای همیشه: بعد از نصب صفحه کلید استاندارد ۹۱۴۷ صفحه کلید قبلی همچنان ماندگار است و کاربران جدید مجبور هستند به طور پیش فرض با آن کار کنند و این برای ما خیلی خیلی بد است…
۹- لینک‌هایی که موقع کار روی مشکلات زبان فارسی پیدا کردم: تاریخچه شرکت فارسی وب، صفحه کلید فارسی شرکت فناوری اطلاعات!!، اشتباه عمده در يونی کد يا اشتباه در پياده سازی مايکروسافت؟، روزبه پورنادر،بهنام پورنادر (لینک ۱، لینک ۲گزارش اقدامات دبیرخانه شورای عالی انفورماتیك درباره استاندارد زبان فارسی در محیط های رایانه ای، صفحه کلید فارسی برای ویندوز به پیشنهاد «بهرام شهر» (لینک ۱، لینک ۲)
۱۰- تاریخچه فایل kbdfa.dll که هنوز هم که هنوزه خیلی‌های برای فارسی کردن ویندوزشان از آن استفاده می‌کنند: لینک ۱، لینک ۲، لینک ۳

۱۱- Regional Settings ویندوز، دشمن زبان فارسی! باعث می‌شود اعداد به طور واقعی انگلیسی باشند ولی فارسی نشان داده شوند! یعنی به جای استفاده از یونیکد از یک روش غیر استاندارد استفاده شده است. همچنین به کاراکترهای غیر یونیکد و کدپیج عربی ۱۲۵۶ اجازه زنده بودن می‌دهد!

۱۲- تحقیقی راجع به صفحه کلیدهای رایج فارسی
۱۳- ساخت یک IME برای ویندوز ایکس پی و ویستا، البته با وجود صفحه کلید ۹۱۴۷ دیگر نیازی به این کار نیست.
۱۴- ارائه راهکار برای رسیدن به جهانی عاری از «ي» عربی!
۱۵- جستجوی هم ارز در گوگل، نگاه یکسان گوگل به انواع «ی» و یا به انواع «ک»
۱۶- رعایت دیدگاه پوکایوکه در نرم‌افزارهای ایرانی، لینک

۱۷- رعایت 5S در شرکت‌های نرم‌افزاری، «فایو اس» یکی از اصول با ارزش مهندسین صنایع در اداره کارخانه‌هاست.
۱۸- کنفرانس‌های کامپیوتری – مدیریت خدمات فناوری اطلاعات، انجمن انفورماتیک ایران، سمینارهای شبکه علمی، شبکه علمی غرب آسیا، دولت الکترونیک و ارتقا نظام اداری

۱۹- تست ۱۲ گانه جوئل و شرکت‌های نرم افزاری ایرانی

آشنایی با نویسه‌های ویژه یونی‌کد برای متون راست به چپ

farsi در ضمیمه شماره ۹ استاندارد یونی‌کد که در آن الگوریتم دو جهته (مخصوص متون راست به چپ) معرفی شده ۷ نویسه مخصوص کار با متون راست‌نویس مثل فارسی و عربی معرفی شده است. این نویسه‌ها نقش بسیار مهمی در نمایش صحیح متون راست به چپ دارند. در واقع بدون وجود آنها نمی‌توان متون راست به چپ را به طور کاملاً صحیح نمایش داد. متون و نویسه‌ها در استاندارد یونی‌کد بر اساس ترتیب معنایی (منطقی) ذخیره می‌شوند. ترتیب منطقی یعنی همان ترتیبی که حروف از ذهن خواننده یا نویسنده متن می‌گذرد. حال هر گاه بخواهیم متون ذخیره شده را در صفحه نمایش یا چاپگر نمایش دهیم باید ترتیب منطقی را با یک روش مناسب به ترتیب دیداری تبدیل کنیم. این روش همان چیزی است که در الگوریتم دوجهته یونی‌کد یعنی الگوریتم دوجهته توضیح داده شده است.
در بعضی شرایط خاص نمی‌توان ترتیب دیداری درستی از ترتیب منطقی (معنایی) به دست آورد. به همین علت الگوریتم دوجهته از تعدادی نویسه ویژه یونی‌کد برای رفع این مشکل استفاده می‌کند. این نویسه‌ها فقط در تصحیح شیوه نمایش کلمات استفاده می‌شوند و هیچ تاثیری روی مرتب‌سازی، جستجو یا دیگر پردازش‌های متنی نباید داشته باشد. در واقع پیوست الف استاندارد ماتصا ۶۲۱۹ که با توجه به الگوریتم دوجهته ضمیمه شماره ۹ نوشته شده تاکید می‌کند که کاربردها باید این نویسه‌ها را در هر پردازشی غیر از استخراج نحوه صحیح نمایش در نظر نگرفته و به آن توجهی نکنند. ضمیمه شماره ۹ و این نویسه‌ها رسماً بخشی از استاندارد ملی ایران یعنی ماتصا ۶۲۱۹ (ISIRI 6219) را تشکیل می‌دهند. علاوه بر این استاندارد ماتصا ۹۱۴۷ (ISIRI 9147) هم ۷ کلید را به تحریر این نویسه‌ها اختصاص داده که همگی با ترکیب کلید ALT راست تحریر می‌شوند. دقت شود که کاربرد اصلی این نویسه‌ها و الگوریتم دو جهته در متون راست به چپ مثل فارسی و عربی و متون ترکیبی فارسی-انگلیسی است به خصوص در مواردی که پای اعداد و علائم هم به وسط می‌آید. این نویسه‌ها در متون صرفاً چپ به راست مثل انگلیسی هیچ کاربردی ندارند.
جالب است بدانید طراح اصلی این الگوریتم شخصی است به نام مارک دیویس (Mark Davis) که هم اکنون در گوگل کار می‌کند. این شخص نه فارسی بلد است، نه عربی، نه عبری و نه هیچ زبان راست به چپ دیگری! قصه طراحی الگوریتم دوجهته ضمیمه شماره ۹ توسط مارک دیویس مرا به یاد داستان تصحیح مثنوی معنوی توسط رینولد نیکلسون و تصحیح شاهنامه فردوسی در مسکو (و علی القاعده توسط روس‌ها) می‌اندازد!

و اما خود نویسه‌ها:

نام به کار رفته در ماتصا ۶۲۱۹ نام مخفف استفاده شده در الگوریتم دوجهته کد یونی‌کد
زیرمتن چپ به راست LRE U+202A
زیرمتن راست به چپ RLE U+202B
پایان زیر متن PDF U+202C
زیرمتن اکیداً چپ به راست LRO U+202D
زیرمتن اکیداً راست به چپ RLO U+202E
نشانه‌ی چپ به راست LRM U+200E
نشانه‌ی راست به چپ RLM U+200F

 

مطالعه بیشتر:
الگوریتم دوجهته (ضمیمه شماره ۹ استاندارد یونیکد)
استاندارد ماتصا ۶۲۱۹
استاندارد ماتصا ۹۱۴۷
نوشته حاجلو راجع به به هم ریختگی متون فارسی-انگلیسی

پ. ن.: در این نوشته از اصطلاحات و واژگان استاندارد ماتصا ۶۲۱۹ استفاده شده است.

ماتصا ۹۱۴۷ استانداردی برای صفحه کلید

isiriماتصا ۹۱۴۷ یا همان ISIRI 9147 جدیدترین استانداردی است که موسسه استاندارد و تحقیقات صنعتی ایران برای چیدمان حروف و علائم خط فارسی بر روی صفحه کلید کامپیوتر منتشر کرده است. این استاندارد در سال ۱۳۸۶ انتشار یافته است. و در حال حاضر (مرداد ۱۳۸۸) آخرین و جدیدترین استاندارد در این زمینه محسوب می‌شود. ماتصا ۹۱۴۷ جایگزین استاندارد قدیمی‌تر ماتصا ۲۹۰۱ (ISIRI 2901) شده و آن را باطل اعلام کرده است. البته استاندارد ۹۱۴۷ فرق خیلی زیادی با استاندارد ۲۹۰۱ نداشته و به اصطلاح Backward Compatible است. کسانی که دستشان به ۲۹۰۱ عادت کرده می‌توانند امیدوار باشند که خیلی زود به ۹۱۴۷ هم عادت می‌کنند.
متاسفانه این استاندارد برخلاف استاندارد ۶۲۱۹ هنوز در بین کاربران، خصوصاً کاربران ویندوز رواج خیلی زیادی پیدا نکرده است. علت این امر تنبلی کاربران و بی‌توجهی مدیران IT کشور در همه سطوح است. متاسفانه بیشتر کاربران فکر می‌کننده آنچه که در ویندوز برایشان مهیاست همان استاندارد واقعی است. در نتیجه فکر می‌کنند ماتصا ۹۱۴۷ صرفاً یک ابداع جدید است که نباید آن را زیاد جدی گرفت. تعدادی از کاربران هم چون این صفحه کلید، صفحه کلید پیش‌فرض ویندوزهای ویستا، ایکس‌پی یا ۹۸ نیست و یا این که چون به لحاظ فنی با نصب درایور آن مشکل دارند، از آن استفاده نمی‌کنند.
ماتصا ۹۱۴۷ با توجه به استاندارد ماتصا ۶۲۱۹ یعنی استاندارد «فناوری اطلاعات – تبادل و شیوه‌ی نمایش اطلاعات فارسی بر اساس یونی‌کد» است. در صورت استفاده از چیدمان‌های غیر استاندارد، کاراکترهای غیر استاندارد (خارج از استاندارد ۶۲۱۹) هم تولید می‌شود. حضور تعداد زیادی «ي» دو نقطه عربی و «ك» عربی گواه بر استفاده از صفحه کلیدهای غیر استاندارد رایج در ویندوز است.
ماتصا ۹۱۴۷ علاوه بر این که جای هر کدام از کاراکترهای مجاز را بر روی صفحه کلید به وضوح مشخص و استاندارد کرده، چند کار مهم دیگر را هم انجام داده است:
۱- حروف صرفاً عربی و غیر مجاز در استاندارد ۶۲۱۹ هم در چیدمان ۹۱۴۷ حضور دارند. این حروف در کار با متون غیر استاندارد و ناسازگار با ماتصا ۶۲۱۹ و تبدیل و جستجو در متون غیر استاندارد و همچنین تحریر متون عربی کاربرد فراوانی دارند.
۲- علائم پرکاربرد غیر فارسی مثل «@»، سمی‌کالن، دابل کوتیشن و… هم در آرایش صفحه کلید موجود هستند، بدون وجود این کاراکترها در استاندارد برای ورود آنها باید یک بار صفحه کلید به انگلیسی عوض و دوباره به فارسی برگردانده می‌شد.
۳- اعداد موجود در ردیف بالایی صفحه کلید اعداد فارسی واقعی (و نه انگلیسی و نه عربی) را وارد می‌کنند و کلیدهای عددی ماشین حسابی هم همان اعداد انگلیسی همیشگی را وارد می‌کنند. ممکن است خیلی از ویندوزها اعداد فارسی و انگلیسی را به ظاهر به یک شکل و آن هم به شکل فارسی نمایش دهند. این قضیه فقط ظاهری است و اصل اطلاعات به همان صورت نادرست انگلیسی ذخیره می‌شود. علت این رفتار ویندوز، وجود Regional Settings است.
۴- کاراکترهای ویژه کار با متون دو جهته که در الگوریتم شماره ۹ یونیکد معرفی شده است در این چیدمان موجود بوده و به خوبی پشتیبانی می‌شوند. این کاراکترها در صورتی که کاربران با نقش آنها آشنا باشند کاربرد فراوانی در حل مشکلات راست به چپ نویسی متون فارسی در محیط کامپیوتر و اینترنت دارند. مثلاً با کمک این سری کاراکترهای می‌توان در صفحات مطلقاً چپ به راست (انگلیسی)، به راحتی متون ترکیبی فارسی-انگلیسی را بدون هر گونه مشکل و درهم‌ریختگی وارد کرد.

خوشبختانه ماتصا ۹۱۴۷ در بیشتر لینوکس‌ها رعایت و پشتیبانی می‌شود. برای استفاده از این استاندارد در لینوکس به راهنماهای موجود مراجعه فرمایید. برای استفاده از این استاندارد در ویندوزهای مختلف از جمله ایکس‌پی، ویستا و ویندوز ۷ از درایور مخصوصی که از این آدرس قابل دریافت است استفاده نمایید.

مطالعه بیشتر:
۱- چیدمان استاندارد ۹۱۴۷ (عکس)
۲- ماتصا ۶۲۱۹ (سایت سازمان استاندارد)
۳- ماتصا ۶۲۱۹ (وبلاگ خودم)
۴- صفحه فارسی‌وب درباره استانداردهای دوقلوی ۶۲۱۹ و ۹۱۴۷
۵- درایور ۹۱۴۷ قابل نصب در همه ویندوزها از ایکس‌پی تا ویندوز ۷
۶- ابزارک فردیس که می‌تواند در تشخیص کد یونیکد کاراکترها مفید باشد
۷- بخش «استاندارد فارسی» در سایت iDevCenter

‫‫استاندارد ماتصا ۶۲۱۹ (ISIRI 6219)

isiri این استاندارد توسط موسسه استاندارد و تحقیقات صنعتی ایران (ماتصا) برای تعریف و یکسان‌سازی استفاده از حروف و الفبای فارسی در محیط کامپیوتر در اردیبهشت ۱۳۸۱ تدوین شده است. این استاندارد در حال حاضر (تیر ۱۳۸۸) جدیدترین استاندارد در این زمینه و جایگزین کلیه استانداردهای قدیمی‌تر ماتصا ۳۳۴۲، ماتصا ۲۹۰۰ و استانداردهای غیر رسمی ویندوز ۱۲۵۶، ایران سیستم، پانیذ و سایه است. ماتصا ۶۲۱۹ کاملا بر اساس یونیکد بوده و توسط گروهی از افراد متخصص و مسلط در این زمینه نگاشته شده است. مسائل مطرح شده در ماتصا ۶۲۱۹ از روز تدوین آن تاکنون مقبولیت روزافزونی داشته و روز به روز در نرم‌افزارهای بیشتری رعایت شده است. مثلا ً راحت‌تر شدن جستجو و مقایسه اطلاعات فارسی که توسط منابع مختلف ثبت شده، رفع مشکل انواع «ی» در فونت‌های مایکروسافت و بقیه، تمایز قطعی بین انواع «ی»ها و انواع «ک»ها، رواج گسترده زبان فارسی در محیط لینوکس و… همگی از ثمرات این استاندارد است.

به علت آن که در استاندارد یونیکد به ازای خیلی از حروف مثل «ی»، «ک»، «الف» و خیلی از اعداد و خیلی از نشانه‌ها و لیگاتورها تعداد زیادی کاراکتر یونیکد شبیه به هم وجود دارد، خیلی از افراد و کاربردها در استفاده از آنها دچار ابهام می‌شوند. مثلاً مطابق توضیحات بلوک عربی یونیکد حدود ده «ی» مختلف وجود دارد که استفاده از هر کدام فقط در استاندارد یک یا چند کشور مجاز است. مهم‌ترین موضوعی که ماتصا ۶۲۱۹ به آن پرداخته، مشخص کردن کاراکترهای مجاز و غیر مجاز برای خط/زبان فارسی در ایران است. مثلاً این استاندارد فقط حرف «ی» فارسی با کد U+06CC و «ئ» همزه‌دار با کد U+0626 را برای خط/زبان فارسی مجاز اعلام کرده است. موضوع مهم بعدی که ماتصا ۶۲۱۹ به آن می‌پردازد نحوه نمایش حروف و کلمات فارسی از دیدگاه چپ و راست چینی (و نه شکل قلم) است. این قواعد مشکلات مرتبط با به هم ریختگی حروف و کلمات فارسی به خصوص به هنگام استفاده همزمان با حروف و کلمات لاتین را حل می‌کند. ماتصا ۶۲۱۹، الگوریتم شماره ۹ یونیکد که به الگوریتم دو جهته معروف است را به عنوان مرجع و بخشی از خود معرفی کرده است.

با رعایت صحیح استاندارد ماتصا ۶۲۱۹:
۱- حرف «ى» بی‌نقطه نچسب عربی با کد U+0649 که متون فارسی را کاملاً به هم می‌ریزد از متون فارسی حذف می‌شود. از به هم ریختگی‌های خیلی آزار دهنده ایجاد شده توسط این نوع «ى» می‌توان به تیکه تیکه شدن کلمات حاوی «ی» در خیلی از موبایل‌های امروزی و خیلی از نرم‌افزارهای قدیمی ویندوز نام برد.
۲- به جای اعداد لاتین و یا حتی اعداد عربی، از اعداد فارسی استفاده می‌شود. این اعداد در ویندوزهایی که Regional Settings آنها تغییر پیدا کرده به صورت ظاهراً فارسی نمایش داده می‌شوند، ولی وقتی که به PDF تبدیل می‌شوند یا در محیط‌های دیگری از طریق وب دیده می‌شوند به همان صورت غلط لاتین دیده می‌شوند.
۳- جلوگیری از درهم‌ریختگی متون ترکیبی فارسی و انگلیسی در اکثر نرم‌افزارها و محیط‌های (Platform) امروزی. به عنوان مثال نمایش برعکس پرانتزها، جابجایی حروف نشانه‌ای مثل سمی‌کالن، نقطه و… حتی وقتی که کلمات کاملاً انگلیسی هستند و صرفاً در یک محیط دو زبانه (دو جهته یا Bidirectional) نمایش داده می‌شوند. ماتصا ۶۲۱۹ این کار را با استفاده از کاراکترهای ویژه الگوریتم شماره ۹ مثل RIGHT-TO-LEFT EMBEDDING انجام می‌دهد.
۴- یکسان سازی استفاده از علائم در خط و زبان فارسی. مثلاً در این استاندارد استفاده از دابل کوتیشن و تک کوتیشن رایج در متون انگلیسی ممنوع و به جای آنها، کاراکترهای «» که شبیه دو علامت کوچکتر یا بزرگتر به هم چسبیده هستند به عنوان «گیومه فارسی» معرفی شده است. در این استاندارد کاراکترهای مشخصی هم برای ممیز فارسی، جداکننده هزارگان فارسی و… در نظر گرفته شده است.

دریافت استاندارد

پ.ن.۱: حروف فارسی معرفی شده در یونیکد همگی بر اساس بلوک عربی هستند. دلیل آن هم این است که ما هیچ بلوک یا بخش واحدی در یونیکد برای خط فارسی یا دیگر خط/زبان‌های مبتنی بر عربی مثل اردو و کردی نداریم.
پ.ن.۲: برای انجام بعضی امور اولیه کار با متون یونیکد و استاندارد ماتصا ۶۲۱۹ ابزار کوچکی به نام «فردیس» وجود دارد که استفاده از آن در بعضی مواقع می‌تواند مفید باشد. این ابزار توسط بنده ایجاد شده است.
پ.ن.۳: استاندارد ماتصا ۶۲۱۹ کاری به چیدمان حروف فارسی در صفحه کلید ندارد. ولی خود استاندارد ماتصا ۹۱۴۷ که چیدمان حروف و علایم فارسی بر روی صفحه کلید کامپیوتر را معین می‌کند، بر اساس همین استاندارد ماتصا ۶۲۱۹ طراحی شده است.
پ.ن.۴: ماتصا ۶۲۱۹ مستقل از شکل نمایشی (Glyph) حروف است. مثلا نمی‌گوید آخر حرف «ف» چقدر باید به بالا کشیده شده باشد.