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

همه کسانی که در نوشتن نرم‌افزارهای دبیرخانه دخیل بوده‌اند با مشکلی به اسم به هم ریختگی شماره نامه آشنا هستند. شماره نامه معمولاً ترکیبی از اعداد، علائم، حروف فارسی و گاهاً انگلیسی هستند. از آنجا که ما در یک محیط دو جهته زندگی می‌کنیم هنوز در نحوه چینش صحیح این حروف در کنار یکدیگر ابهاماتی وجود دارد و مردم بسیاری از قواعد موجود را هم یا نمی‌شناسند یا اصلاً به کار نمی‌برند. در نتیجه چیزی که کاربر با هزار دردسر به عنوان شماره نامه وارد می‌کند به هنگام نمایش مجدد دچار به هم ریختگی می‌شود. مثلاً جای حروف و علائم عوض شده یا علامتی مثل خط تیره به جای آن که در سمت راست یک کاراکتر نمایش یابد به سمت چپ آن منتقل می‌شود. این قضیه وقتی تشدید می‌شود که شماره نامه ذخیره شده را بخواهیم در محیط‌های متنوعی مثل 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) می‌باشد.

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

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

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

‫پروتکل ECE و نرم افزارهای دبیرخانه

  ‫پروتکل ECE

پروتکل ECE یا پروتکل تبادل الکترونیکی مکاتبات (Electronic Correspondence Exchange) پروتکلی ایرانی است برای استاندارد کردن ارتباط مکانیزه نرم افزارهای دبیرخانه و اتوماسیون. ایده اولیه این پروتکل توسط کمیته نرم افزار انجمن شرکت‌های انفورماتیکی (زیر گروه همگن اتوماسیون اداری) در تابستان ۸۲ مطرح و در پاییز و زمستان ۸۳ عملیاتی گردید. در حال حاضر به دلیل انحلال انجمن شرکت‌های انفورماتیکی، سازمان نظام صنفی رایانه‌ای متولی امورات آن است.

تا قبل از ابداع این پروتکل خیلی از شرکت‌های نرم افزاری تولید کننده نرم افزار دبیرخانه و اتوماسیون برای برقراری ارتباط بین نسخه‌های مختلف نرم افزار خود که در مکان‌های جغرافیایی مختلفی نصب شده بودند روش‌های ارتباطی خاصی ابداع کرده بودند. این روش‌ها عمدتا مبتنی بر ارسال/دریافت نامه به کمک فایل‌های مختلفی مثل xml و روش‌های ارتباطی مثل ایمیل بودند. در ادارات و سازمان‌های بزرگ که هر کدام از شعب آن از یک نرم افزار دبیرخانه متفاوت استفاده می‌کردند برقراری ارتباط بین دبیرخانه‌های مختلف میسر نبود چون هر کدام از شرکت‌های تولید کننده نرم افزار از روش خاص خودش استفاده کرده بود. در اینجا بود که ایده پروتکل ECE مطرح شد. این پروتکل همه را ملزم می‌کرد تا از یک روش ارتباطی و قالب فایل یکسان استفاده کنند.

پروتکل ECE از یک فایل xml خاص با قالب کاملا مشخص به عنوان قالب ارسال/دریافت اطلاعات دبیرخانه‌ای و ایمیل به عنوان بستر ارتباطی استفاده می‌کند. کلیه مستندات پروتکل در سایت رسمی آن یعنی http://ecep.ir/ موجود است. در حال حاضر (بهار ۸۸) خیلی از شرکت‌های نرم افزاری در حال پشتیبانی از این پروتکل بوده یا درصدد افزودن آن به دبیرخانه‌هایشان هستند. ما هم امیدواریم این حرکت به ایجاد یک استاندارد واقعی و فراگیر تبدیل شود.

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

کلیه مطالب وبلاگ جاری که راجع به پروتکل ECE هستند
نوشته ناصر حاجلو راجع به پروتکل ECE
سایت رسمی پروتکل ECE
سازمان نظام صنفی رایانه‌ای کشور – متولی رسمی پروتکل ECE
وبلاگ قبلی: معرفی وبلاگ
وبلاگ قبلی: جستجو در گوگل به دنبال ECE
وبلاگ قبلی: سیستم دبیرخانه بدون کاغذ، نیاز یا اجبار
وبلاگ قبلی: معیارهای انتخاب نرم افزار دبیرخانه (اتوماسیون)
وبلاگ قبلی: فرق بین دبیرخانه و اتوماسیون
وبلاگ قبلی: شرکت‌هایی که تفکیک دبیرخانه و اتوماسیون را به خوبی رعایت کرده‌اند
وبلاگ قبلی: یک سایت خوب برای آشنایی با سیستم‌های دبیرخانه
وبلاگ قبلی: مشکل در ارسال ایمیل
وبلاگ قبلی: Certify
وبلاگ قبلی: ویرایش جدید پروتکل تبادل الکترونیکی اطلاعات اداری ECE
وبلاگ قبلی: فعال شدن مجدد پروژه ECE

‫پروتکل ECE

‫راهی برای اضافه کردن دستی header به ایمیل‌ها

header بخشی از اطلاعات موجود در یک ایمیل است که با کمک آن می‌تواند قابلیت‌های زیادی به یک ایمیل بخشید. مثلا با اضافه کردن هدر خاصی به یک ایمیل می‌توان آن را به عنوان یک ایمیل ECE معتبر شناساند. خواندن هدر ایمیل‌های وارده تقریبا از همه برنامه‌های ارسال/دریافت ایمیل و کلاس‌های کار با ایمیل در دات نت امکان پذیر است. اما اضافه کردن هدر از طریق برنامه‌های ارسال/دریافت یا سرویس دهنده‌های ایمیل مثل جی میل و یاهو کار چندان ساده‌ای نیست. بعد از مدت‌ها گشت و گذار و تست کردن‌های مختلف فهمیدم که می‌توان با Customize کردن Thunderbird این کار را کرد. روش این کار در اینجا گفته شده است. من با کمک یک اکانت جی میل و Mozilla Thunderbird موفق شدم بدون هیچ مشکلی هدر مورد نظر خودم را به ایمیلم الصاق و آن را ارسال کنم. البته حتما می‌دانید که هدف از این کار تست دستی دبیرخانه‌هایی است که در دریافت ایمیل‌های دارای هدر ECE مشکل دارند.

اضافه کردن هدرهای دلخواه از طریق «مرغ طوفان»‏

این هم سورس تولیدی:

Message-ID: <48E8B367.9090709@gmail.com>
Date: Sun, 05 Oct 2008 16:00:31 +0330
From: ECE Tester <ece.tester@gmail.com>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: afshar.mohebbi@gmail.com
Subject: testing ece
X-ECE_SEND: 1.01


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

‫تست پروتکل ارتباطی بین دبیرخانه ما و دبیرخانه شرکت «پ»‏

بالاخره فرایند تست پروتکل ECE بین دبیرخانه شرکت ما و شرکت «پ» شروع شد. این فرایند تا اینجا حدود ۴ هفته طول کشیده و برقراری هر تماس بین ما، شرکت «پ» و کارفرمای مشترک ما هم به طور میانگین ۲ روز طول کشیده!!
متاسفانه همکاری ما با برنامه نویسان شرکت «پ» هم از نوع ناقص آن می‌باشد. چون اولا «هر چی ما نوشته‌ایم درست است و حتما مال شماست که خراب است» و ثانیا «این شما هستید که باید خودتان را با ما تطبیق دهید نه ما، چون ما از شما قدیمی‌تر هستیم و مبنا زور ماست نه استانداردی که پروتکل ECE تعیین کرده!»‏
به قسمت دوم این را هم بیفزایید که آنها نمی‌توانند به ما بگویند از چه روش یا Componentی برای خواندن سورس ایمیل استفاده می‌کنند (اسرار کاری) و ما مجبور هستیم خودمان روش آنها را کشف کرده و منطبق با آن عمل کنیم!
این را هم اضافه کنم که مشکل ما به علت ارتباطات ایمیلی است و نه تولید یا خواندن فایل XML.

پ. ن.: این مطلب در ادامه مطالب وبلاگ سابق http://iranece.blogspot.com در اینجا درج شده است.