OTRS generated CSV and Unicode issue

It's a while for now that we have problems with OTRS generated CSV files and Unicode. We are conducting an OTRS implementation in a Persian (Farsi) context. OTRS’s Stats (reports) module can generate CSV as output. There is 2 problems here. First, delimiter character used is Semicolon (;) not Comma (,) and second, because of our Unicode environment, CSV file format is UTF8. Following screenshot shows such a CSV file opened directly in MS Excel 2007, all of fields is just located in one column and Persian (Farsi) text are showed incorrectly as some meaningless characters:

 

While searching for the solution in OTRS mailing lists, I found a good and very simple solution. Resolving the issue is possible by importing (not opening directly) the CSV with some considerations. All necessary steps are illustrated in the following.

1. Select “Get External Data, From Text” from Data menu and select desired CSV file:

 

2. A wizard opens. In the first step select “65001 : Unicode (UTF-8)” as “File Origin” and click “Next”:

 

3. In the second step select “Semicolon” instead of “Comma” and click “Next”:

 

4. In the 3^rd step of wizard click “Finish” and in the “Import Data” window click “OK”. After this you will see your correct data in correct cell (each field in a separate column) and correct language (Persian text not garbage one) in MS Excel 2007:

 

Please consider that all of these instructions are applicable in MS Excel 2003 too.

‫قالب فایل CSV و یونیکد

CSV یا همان Comma Seperated Values یک قالب فایل معروف و خیلی قدیمی (از حدود ۴۵ سال پیش!) است که در محیط‌ها و نرم افزارهای بسیار مختلفی مورد استفاده قرار می‌گیرد. در این قالب هر رکورد از اطلاعات در یک سطر فایل ذخیره می‌شود. و در هر سطر هم فیلدها به وسیله کاراکتر کاما «,» از هم جدا می‌شوند.

برای CSV هیچ استاندارد واحدی وجود ندارد. حتی RFC 4180 هم به صورت Informational ارائه شده است یعنی استاندارد واحدی را مشخص نکرده و صرفا قالبی که در بیشتر پیاده‌سازی‌ها مورد استفاده قرار گرفته را معرفی می‌کند. این یعنی اینکه CSV که از اکسل می‌گیرید لزوما با CSV که ممکن است از Gmail Contacts یا MySQL بگیرید یکی نخواهد بود. مثلا در یکی از header استفاده شده و در دیگری نه و یا مقدار فیلدها در یکی با double qution محصور شده و در دیگری نه. بدترین قسمت این ماجرا این است که در بیشتر پیاده سازی هیچ اهمیتی به Enocding داده نشده و فرض همه به ASCII بودن فایل است و بدتر از این از آنجا که به نظر می‌رسد CSV از Byte Order استفاده نمی‌کند (پاراگراف بعدی را ببینید) در نتیجه فایل آن حتما باید تک بایتی باشد مثل ASCII و UTF-8 و باز هم در نتیجه نمی‌توان از قالب‌های ۲ بایتی (یعنی هر کاراکتر در ۲ بایت ذخیره شود) مثل فایل‌های متنی یونیکد ویندوز در آن استفاده کرد. البته در حال تک بایتی هم Encoding را خود استفاده کننده باید بفهمد و نوع Encoding مورد استفاده از هیچ جای یک فایل CSV قابل استخراج نیست. در بعضی جاهای خاص مثل وقتی که قرار است فایل CSV به عنوان یک MIME TYPE به اسم text/csv رد و بدل شود یک header به نام charset هست که می‌توان Encoding را در آن معرفی نمود. فراموش نشود که این header خارج از خود فایل CSV قرار دارد.

در بعضی حالات به نظر می‌رسد که CSV از Byte Order استفاده می‌کند یعنی مثل فایل‌های متنی داخل ویندوز می‌شود یک یا چند بایت خاص را به منظور تعیین Encoding مورد استفاده در ابتدای فایل قرار داد و  سپس هر کاراکتر را با توجه به Encoding انتخابی ۱ یا ۲ بایت در نظر گرفت. البته در یکی دو آزمایش معلوم شد که خیلی برنامه‌ها از جمله Excel 2007 با فایل‌های متنی ۲ بایتی (ذخیره هر کاراکتر در ۲ بایت) مشکل دارند و این روش خیلی قابل اطمینان نیست.

نظر نگارنده این است که هر فایل CSV به صورت یک فایل متنی خالص تک بایتی بدون Byte Order ذخیره شده ولی برای ذخیره مقادیر یونیکد آنها را به قالب UTF-8 در آورده و در جای فیلدها ذخیره شود. برای خواندن این CSV هم همه فیلدها از UTF-8 به متن معمولی decode شود. به جای UTF-8 از هر روش دیگری هم که کاراکترهای یونیکد را به رشته‌ای از کاراکترهای تک بایت تبدیل می‌کنند هم می‌شود استفاده کرد. مثلا مثل این روش در صفحات HTML که کاراکتر «ن» فارسی با کد «#1606;» نمایش داده می‌شود. فقط باید دقت شود که استفاده کننده فایل CSV هم از روش Encoding مورد استفاده ما با خبر باشد.

 

منابع:

• ویکی‌پدیا
• RFC 4180
• ابزارهای برنامه‌نویسی
• CSV و یونیکد
• Binary Viewer
• بحثی راجع به مسائل Encoding

‫کمی درباره GFDL (‫اجازه‌نامه مستندات آزاد گنو)

GNU Free Documentation License یک اجازه‌نامه «کپی‌لفت» مخصوص متون (نه نرم افزار) است. هر نوشته‌ای که با این اجازه‌نامه که به اختصار GFDL نامیده می‌شود منتشر شود تبدیل به یک نوشته «آزاد» می‌شود به این معنی که هر کسی می‌تواند آن را آزادانه تغییر داده یا تکثیر کند به این شرط که نسخه دوباره انتشار یافته (چه با تغییر چه بدون تغییر) دوباره تحت همین مجوز یا دیگر مجوزهای آزاد سازگار با آن منتشر شود که البته شرایط خاصی هم باید رعایت شود.

با این که GFDL را GNU برای کسب اطمینان از انتشار آزاد مستندات و راهنماهای نرم افزارهای آزاد منتشر کرده است ولی از این مجوز می‌توان برای انتشار هر نوع نوشته، متن و کتابی در خارج از زمینه کامپیوتر هم استفاده کرد. Wikipedia از بزرگترین و معروف‌ترین استفاده کننده‌های مجوز GFDL است.

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

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

منابع:

ویکی‌پدیا

متن مجوز GFDL

ترجمه غیر رسمی GFDL به زبان فارسی

OTRS, GD Library and Persian Support

OTRS can generate graphic as output of its reports. For example someone could generate a bar chart from Queues. Ok, but what's wrong about this? My problem with this is Persian (Farsi) text in the image, for example name of queues are showed incorrectly. Consider following pic. that is a part of Bar-Chart report with 4 text phrase, 1 English (tmp_lock) and 3 others in Persian.

Persian words are rendered in a wrong way. Those 2 text below the charts are Persian words "تحویل گرفته شده" and "آزاد". They are incorrectly rendered as some European characters with accents above.

I posted the issue in OTRS mailing lists here and here, but no one could solve this. Some folks suggested to use my fonts instead of OTRS default fonts but I didn't find how to this.

After this unsuccessful tries I decided to trace the OTRS directly to see where the graphics are generated. I examined stats.pm and $graph->set_legend(@YLine); and realized that the root cause may be GD.pm not OTRS. So I tried to generate a sample graphic with GD.pm directly but Persian text was not displayed correctly yet.

I found GD Library (underlying library of GD.pm) is graphic engine of PHP too so tried to find someone that has any experiences with this. The results was a blog post by Robert Robbins and an online graphic generator based on GD Library. But no one could help me.

Additionally there is a related project on PHP, GD Library and Persian problem introduce here and here by Omid Mottaghi, a good book named "Perl Graphics Programming" and a nice .Net open source project named "GD Sharp" that is really an interface to GD Library. I tried all of these but no hope yet!

Note:

1. My friend Masoud has reported this bug to GD project and they say it is known issue and it is not going to be resolved. Instead RTL support will be supported in GD-Pango. Is it possible that OTRS use gd-pango instead of gd to resolve such problems?
2. I've discussed this problem in Persian Computing group too. They suggest to utilize FriBiDi.
3. A friend suggested to use Imagick. It may solve Persian problem.

Does anybody could help me getting rid of this nightmare please?

‫کپی‌لفت (Copyleft) چیست؟

   «کپی‌لفت» یا «سهوتالیف» مفهومی است که برای توضیح رفتار اجازه‌نامه (مجوز، پروانه، License)های دنیای نرم افزارها (و متون) آزاد/کدباز به کار می‌رود. مجوز GNU GPL و GNU FDL دو مثال معروف از اجازه‌نامه‌‌های «کپی‌لفت» هستند.

عبارت کپی‌لفت برای نخستین بار در دهه ۱۹۷۰ میلادی (دهه ۱۳۵۰ شمسی) در تقابل با مفهوم «کپی‌رایت» (حق مولف) به کار برده شد. طرفداران سهو تالیف (کپی‌لفت) می‌خواستند با برعکس کردن حرف انگلیسی «C» در علامت حق مولف «©» و عوض کردن واژه right در Copyright با کلمه left به همه بگویند که با انحصاری شدن نرم افزارها از طریق قانون حق مولف (Copyright) مخالف هستند (در اینجا از right به معنی راست و از left به معنی چپ استفاده شده).

«سهو تالیف» یا کپی‌لفت (Copyleft) به طور دقیق‌تر به آن دسته از اجازه‌نامه (License)هایی اطلاق می‌گردد که استفاده کننده، تغییر دهنده یا برنامه نویس را مجاز به داشتن سورس کد برنامه (یا نسخه «شفاف» منابع متنی در مورد اجازه‌نامه GFDL)، اعمال کردن هر نوع تغییر در آن و انتشار مجدد آن می‌داند به شرطی که نسخه دوباره منتشر شده هم تحت همان اجازه‌نامه یا دیگر اجازه‌نامه‌های آزاد سازگار بااجازه‌نامه اولیه منتشر شود.

این قاعده این اطمینان را به دست می‌دهد که هیچ شخصی یا شرکت واسطی نتواند نرم افزارهای (و متون) آزاد/کدباز را حتی اگر خودش در آن اصلاحاتی انجام داده باشد به صورت انحصاری در آورد. یکی از معروف‌ترین و قدیمی‌ترین مواردی که یک شرکت طی آن به خاطر فقدان اجازه‌نامه‌های کپی‌لفت موفق به انحصاری کردن یک نرم افزار شده بود مورد معروف شرکت Symbolics و ریچارد استالمن است. ریچارد استالمن در دهه ۷۰ یک مفسر LISP را به صورت کدباز برای شرکت Symbolics نوشت. شرکت Symbolics هم از آن استفاده کرد و بعد از مدتی اصلاحاتی در آن اعمال کرد ولی وقتی که استالمن نسخه اصلاح شده نرم افزاری که خود برای آنها نوشته بود را از شرکت Symbolics خواست آنها به سادگی هر چه تمام‌تر از دادن کد منبع نرم افزار به او خودداری کردند! چون اعتقاد داشتند که این سورس از این به بعد متعلق به شرکت Symbolics است.

فرهنگ سهو تالیف (Copyleft) را در فرهنگ خودمان (ایران) می‌توان با فرهنگ «وقف» شبیه دانست. ایرانی‌های قدیم (و جدید) برای آمرزش روح درگذشتگان و کمک به هم نوعان خود، املاک خود یا آنهایی را که به همین منظور می‌ساختند شامل خانه، مسجد، حسینیه، مدرسه، حمام، باغ و… را «وقف» می‌کردند به این معنی که مالکیت آن ملک یا وسیله (وسایل مجالس عزا، عروسی، روضه، مراسمات محرم و عاشورا و…) از مالکیت شخص و ورثه آن خارج شده و به مالکیت عمومی در می‌آمد. در حال حاضر مدیریت و صیانت این «اوقاف» بر عهده اداره اوقاف و در قدیم‌ترها به عهده معتمدین محلی، حاکمین شهرها و روحانیون منطقه قرار داشته و دارد. در مورد وقف همچون اجازه‌نامه‌های سهو تالیف (Copyleft) هیچکس حق ندارد اموال و املاک وقفی که یک بار وقف شده را به تصرف خودش درآورد.

این واقعیت را نباید فراموش کرد که سهو تالیف (Copyleft) از لحاظ حقوقی و قانونی نوعی استفاده خلاقانه از قانون حق تالیف (Copyright) است. سهو تالیف (Copyleft) با استفاده از قانون حق تالیف (Copyright) است که افراد را مجبور به حفظ مجوز سهو تالیف (Copyleft) در نسخه‌های تغییر یافته و نیافته بعدی می‌کند. دقت کنید که سهو تالیف (Copyleft) به معنی نداشتن حق تالیف (Copyright) نیست و این قانون کپی‌رایت است که از کپی‌لفت حفاظت می‌کند!

بیشتر اجازه‌نامه‌های مورد استفاده در نرم افزارهای آزاد/متن‌باز از نوع سهو تالیف (Copyleft) هستند از جمله GNU GPL،Creative Commons، GNU Free Documentation License و GNU LGPL. یکی معروف‌ترین استثنائات این موضوع اجازه‌نامه BSD است که سهو تالیف (کپی‌لفت) نیست و به افراد این اجازه را می‌دهد که کد منبع نرم افزارهای کدباز را بعد از تغییرات (یا شاید هم بدون تغییرات) به مالکیت شخصی خود درآورده یا مجددا با اجازه‌نامه‌های سهو تالیفی (Copyleft) مثل GPL منتشر کنند.

منابع

۱- ویکی‌پدیا

۲- گنو