استفاده از utf8to ansi

[naeemeh]

دوستان سلام:
میشه منو راهنمایی کنین که چطور می تونم از تابع utf8toansi استفاده کنم.چون موقع استفاده بدون اینکه خطایی بگیره خالی بر می گردونه.

[taha]

سلام
عبارتی که می خواهی به Ansi تبدیل کنی به هر دلیلی Incomplete هست(خیلی خلاصه Utf نیست).

[naeemeh]

ممنون دوست عزیز از راهنماییتون،این کدرو میشه یه بررسی بکنین.
من تو خود دلفی مقداردهی می کنم متغیرم رو.

if (combobox1.text='ØáæÚí') and (edit1.text='123456') then begin
form1.Label5.Caption:=combobox1.text;

بعد تو dbf که می خوام ذخیره کنم error نمیده اما هیچ چیزی هم تو بانکم نشون نمیده.

datamodule5.Tablef2.FieldByName('etla').AsString:= Utf8toansi(Label5.Caption);

[vcldeveloper]

datamodule5.Tablef2.FieldByName('etla').AsString:= Utf8toansi(Label5.Caption);

Label.Caption از نوع string هست، یعنی ANSI هست، پس UTF8ToAnsi براش معنی نداره. دارید Ansi را به Ansi تبدیل می کنید.

[naeemeh]

اقای کشاورز میشه بیشتر راهنمایی کنید.با این کد insert میشه تو بانک اماباید چکار کنم که تو فاکس پرو با سپند درست نمایش داده بشه.

datamodule5.Tablef2.FieldByName('etla').AsString:= utf8toansi(ansitoutf8(Label5.Caption));

[taha]

Label.Caption از نوع string هست، یعنی ANSI هست، پس UTF8ToAnsi براش معنی نداره. دارید Ansi را به Ansi تبدیل می کنید.

وقتی شما می گویی:" Label.Caption از نوع string هست، یعنی ANSI هست"، به این معنا نیست که نمی تواند مقدار Utf بگیرد، بلکه به این معناست که نمی تواند درست نمایش دهد.

مثلا شما دستور زیر را اجرا کنید:

Edit1.Text:= Utf8ToAnsi('ط³ظ„ط§ظ…');

خواهید دید که درست اجرا میشه.

اما شما naeemeh:
همانطور که گفتم رشته شما Incomplete هستش (Utf نیست) که از ظاهرش هم معلومه. حالا واقعا باید ببینید چه کارکترستی هست.

[vcldeveloper]

وقتی شما می گویی:" Label.Caption از نوع string هست، یعنی ANSI هست"، به این معنا نیست که نمی تواند مقدار Utf بگیرد، بلکه به این معناست که نمی تواند درست نمایش دهد.

string دلفی نمیتونه UTF بگیره، یعنی شما اگه بهش UTF بدید، بایت دومش از بین میره. String چیزی رو نمایش نمیده، بلکه نگه داری میکنه. در یک string برای هر کارکتر یک بایت در نظر گرفته میشه، اما برای UTF نیاز هست که برای هر کارکتر 2 بایت استفاده بشه.
در نسخه بعدی دلفی string داده ها را بصورت UTF-16 نگهداری خواهد کرد. در حال حاضر، می تونید از مجموعه کامپوننت TNT برای کار با داده ها بصورت یونیکد استفاده کنید. برای نگه داری مقادیر هم می تونید از WideString استفاده کنید. دقت کنید که هیچ کجا WideString حاوی داده های یونیکد را به String تبدیل نکنید، چون داده های یونیکد شما از بین میره.

[taha]

string دلفی نمیتونه UTF بگیره

راهنمای دلفی:

UTF8String = type string;

String چیزی رو نمایش نمیده، بلکه نگه داری میکنه

فاعل "نمی تواند درست نمایش" Label.Caption است نه String!

[vcldeveloper]

UTF8String = type string;

با این UTF8String نمی تونید کارکترهای یونیکد فارسی ذخیره کنید. فقط بدرد کارکترهای لاتین میخوره.

[taha]

با این UTF8String نمی تونید کارکترهای یونیکد فارسی ذخیره کنید. فقط بدرد کارکترهای لاتین میخوره.

راهنمای دلفی:

function AnsiToUtf8(const S: string): UTF8String;



Description

AnsiToUtf8 converts the string specified by S, which uses the  ANSI encoding system, to UTF-8. 

خب UTF-8 رو هم که می دونیم چیه؟

[naeemeh]

دوستان اول از همه تشکر می کنم ازتون.من یک مسئله رو فراموش کرده بودم که مطرح کنم.قبل از اینکه برنامم کامل بشه یکبار insert شد تو بانکم .بعد این تیکه برنامم رو بلاک کردم تا بقیه قسمتهارو درست کنم.اما بعد از اینکه از بلاک درآوردم دیگه کار نکرد.حتی هنوز هم تو بانکم دارم این فیلد رو که به نام خودم یعنی 'کشاورز' پر شده و فارسی هم نشون میده.حالا با این تفاصیل به نظرتون مشکل چیه؟؟؟؟

[vcldeveloper]

خب UTF-8 رو هم که می دونیم چیه؟

عزیز جان، UTF-8 برای کارکترهای اسکی Backward compatibility داره، یعنی شما کارکتر اسکی بهش بدی، بدون مشکل با اون کار میکنه، چون برای کارکترهای اسکی از همون یک بایت استفاده میکنه، ولی برای سایر کارکترها به بایت های بیشتری نیاز داره، پس اون UTF8String ایی که شما نوشتید، با اون تعریفی که ازش شده، اگر برای کار با کارکترهای فارسی استفاده بشه، بایت های اضافه کارکتر رو حذف میکنه، در نتیجه رشته از بین میره (یعنی بهم میریزه).

[taha]

برای کارکترهای اسکی Backward compatibility داره

راهنمای دلفی:

function Utf8ToAnsi(const S: UTF8String): string;

Description

    Call Utf8ToAnsi to convert a UTF-8 string to Ansi. S is a  string encoded in UTF-8. Utf8ToAnsi returns the corresponding string that uses  the Ansi character set.

پس اون UTF8String ایی که شما نوشتید، با اون تعریفی که ازش شده، اگر برای کار با کارکترهای فارسی استفاده بشه، بایت های اضافه کارکتر رو حذف میکنه، در نتیجه رشته از بین میره (یعنی بهم میریزه)

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

2- با فرض صحت صحبت شما

procedure TForm1.Button1Click(Sender: TObject);

var

  AnsiString: string;

begin

  AnsiString:= Edit1.Text;

  AnsiString:= Utf8ToAnsi(AnsiToUtf8(AnsiString));

  Edit1.Text:= AnsiString;

end;

نباید درست کار کنه (رشته از بین بره و بهم بریزه)، که اگه امتحان کنید، می بینید برای هر مقداری خروجی مشکلی نداره.

3- عزیز دل برادر، با نگاهی به مقدار متغیر AStringLength برای مقادیر مختلف EditBox در زیر

procedure TForm1.Button2Click(Sender: TObject);

var

  AStringLength: Integer;

begin

  AStringLength:= Length(AnsiToUtf8(Edit1.Text));

  ShowMessage(IntToStr(AStringLength));

end;

می بینید، برای مقادیر لاتین مقدار همان طول رشته است
برای مقادیر غیر لاتین دو برابر تعداد کاراکترهاست
برای مقادیر لاتین و غیر لاتین = تعداد کاراکترهای لاتین + دو برابر تعداد کاراکترهای غیر لاتین

که این در واقع مشکل اون یه بایت را حل میکنه.

[vcldeveloper]

3- عزیز دل برادر، با نگاهی به مقدار متغیر AStringLength برای مقادیر مختلف EditBox در زیر...
می بینید، برای مقادیر لاتین مقدار همان طول رشته است
برای مقادیر غیر لاتین دو برابر تعداد کاراکترهاست
برای مقادیر لاتین و غیر لاتین = تعداد کاراکترهای لاتین + دو برابر تعداد کاراکترهای غیر لاتین

کافیه از UTF8String بصورت عملی استفاده کنید تا متوجه بی استفاده بودن آن در متون فارسی بشید. البته دقت کنید که متن فارسی که شما در ویندوز و دلفی تایپ می کنید، UTF8 نیست، بلکه Windows-1252 هست.
برای داشتن متن UTF-8 می تونید در ویندوز یک فایل TXT با NotePad درست کنید و درش فارسی تایپ کنید و فایل رو ذخیره کنید (خودش بهتون میگه باید بصورت یونیکد ذخیره بشه چون توی XP و نسخه های بالاتر ویندوز NotePad یونیکد شده). حالا می تونید این فایل رو در یکی از کامپوننت های TNT که با یونیکد سازگار هست (چون از WideString استفاده می کنند) لود کنید، مثلا در یک TntMemo، بعد همین متن لود شده رو با UTF8ToAnsi به string تبدیل کنید و در Memo لود کنید، متوجه میشید که اصلا متنی لود نشده. اگر متن مورد نظر در TntMemo رو با Copy\Paste هم به Memo منتقل کنید، بصورت ? نمایش داده میشه.
حالا عکس این کار رو انجام میدیم، شما یک متن مخلوط فارسی و انگلیسی رو در Memo تایپ کنید و اون رو با AnsiToUTF8 به UTF8String تبدیل کنید، بعد همین رشته رو در TntMemo لود کنید، می بینید که یک سری کارکتر بی معنی تحویلتون میده، طولش هم بیشتر از طول متن در Memo شده. همین کار رو با یک متن تمام انگلیسی انجام بدید، می بینید که TntMemo هم اونو درست نمایش میده و طول متن با طول متن در Memo برابر هست.

نتیجه؛ UTF-8 با ASCII سازگار هست، برای همین هم با کارکترهای لاتین مشکلی نداره، اما وقتی از کارکترهای غیرلاتین استفاده بشه، UTF-8 به بایت های بیشتری نیاز داره که با string یا UTF8String امکان ذخیره آنها نیست. برای رسیدن به این نتیجه لازم نبود اینقدر راه طی بشه، مراجعه به تعریف UTF-8 در یک دایره المعارف عمومی مثل Wikipedia هم مشکل رو حل می کرد!

[taha]

کافیه از UTF8String بصورت عملی استفاده کنید تا متوجه بی استفاده بودن آن در متون فارسی بشی

از هر چیزی باید اول بصورت تئوری دقیق آگاهی داشت تا بعد بصورت عملی بتونیم خوب ازش استفاده کنیم تا اشتباها یه چیزی رو نگیم بی استفاده است!

پس لازمه یه مختصری از تاریخچه Character Sets رو مرور کنیم:

برمی گردیم به اولین روزهایی که K&R کتاب The C Programming Language را نوشتند. تنها کاراکترهایی که وجود داشتند کاراکترهای لاتین بودند که اونها را ASCII نامیدند که مخفف American Standard Code for Information Interchange ، که قادر بود هر کارکتری را که کدی بین 32 و 127 بود را نمایش بده. که مثلا کد 32 فاصله (Space) بود، یا حرف A کد 65 و ...
و کدهای زیر 32 شدند کاراکترهای کنترلی مثلا کد 7 برای صدای Beep و امثال آن.
اینها می تونستن براحتی در 7 بیت نگهداری بشن، که البته اون روزها اغلب کامپیوترها از بایت های 8 بیتی استفاده می کردند، که قادر بود تمام کاراکتر های ACCII را براحتی نگهداری کنند.
حالا 1 بیت بود که خالی موند که اگر شما هم بودید از اون برای مقاصد خاص خود استفاده می کردید. همه چیز خوب بود ولی فقط برای انگلیسی زبانها!
برای همین مردم بفکر افتادند که: "می تونیم از کدهای 128-255 برای مقاصد خودمون استفاده کنیم". البته مشکل هم از اینجا آغاز شد که همه این فکر رو همزمان با هم کردند که اون چیزی که مدنظرشونه را در کدهای 128-255 قرار دهند. یکی از اونها IBM-PC بود که یه چیزی که ما اونو OEM character میشناسیم برای PC هاش داد بیرون که شامل کاراکترهای ASCII، بعضی کاراکترهای تشدید دار (Accented) جهت زبانهای اروپایی و کاراکترهای رسم خطوط افقی، عمودی و ...
به محض اینکه مردم شروع به خرید کامپیوتر خارج از کشور آمریکا کردند انواع متفاوتی از OEM Character Set با مقاصد گوناگون ارائه شد. که سرانجام این OEM در استانداردی بنام ANSI مدون شد. در استاندارد ANSI همه توافق کردند با کدهای زیر 128 چکار کنند (شد همان کدهای ASCII) اما راه برای پر کردن کدها ی 128 به بالا با توجه به اینکه شما کجا زندگی می کنید باز گذاشته شد، که این تفاوت در سیستم Code Pages نامیده شد. مثلا سیستم Dos در کشور یونان از کدپیجی استفاده میشد که 737 نامیده می شد و امثال آن و حتی مثلا یکی از نسخه های MS DOS انواع مختلفی از این کدپیجها را داشت که بنوعی multilingual بود!
ولی فراهم کردن زبانهایی مثل یونانی با عربی با هم در یک کامپیوتر غیرممکن بود. حتی بدتر از اون زبانهایی در آسیا بودند که تعداد کاراکترهای آنها در همون 8 بیت (128-255) هم جا نمیشد، که خوشبختانه Unicode ارائه شد.

[vcldeveloper]

از هر چیزی باید اول بصورت تئوری دقیق آگاهی داشت تا بعد بصورت عملی بتونیم خوب ازش استفاده کنیم تا اشتباها یه چیزی رو نگیم بی استفاده است!

پس لازمه یه مختصری از تاریخچه Character Sets رو مرور کنیم

خب، اینایی که تا اینجا شرح دادید چه ربطی به موضوع پشتیبانی دلفی از یونیکد و بطور خاص نوع داده UTF8String داشت؟ از طرف دیگه، چه منافاتی با پست های من داشت؟!
صرفا جهت اطلاع رسانی بود؟

[taha]

Unicode
Unicode یک تلاش موفق برای ساخت یک کاراکترست واحد جهت دربرداشتن هر نوع سیستم نوشتاری منطقی است.
خیلی از ما در یک تصور غلط بسر می بریم که Unicode فقط دارای 16 بیت هست که در مجموع می تونه 65536 کاراکتر رو در خود جا بده، که این کاملا درست نیست، ولی بد هم نیست!
به هر کاراکتر یک عدد نسبت داده شد (شبیه U+0639 ) که این عدد Code Point نامیده می شود. U+ بمعنای "Unicode" و اعداد هگزادسیمال می باشد. مثلا U+0639 حرف "ع" می باشد و یا U+0041 حرف "A" است که بقیه کدها را می تونید در برنامه Charmap در Windows2000/XP ببینید. بطور مثال متاظر یونیکد عبارت Hello بصورت U+0048 U+0065 U+006C U+006C U+006F می باشد.
اما در این بین چند مشکل وجود داشت:
1- این همه 0 که باعث نارضایتی برنامه نویسان انگلیسی می شد! که قبل از آن بندرت از کدهای بالای U+00FF استفاده می کردند.
2- وجود این تفکر که استفاده از این سیستم باعث دو برابر شدن بایت ها می شود.
3- تبدیل یک حجم بسیار زیاد از اطلاعات موجود!
که باعث شد یونیکد برای چند سالی محجور قرار بگیره.
تا اینکه مفهوم طلایی UTF-8 ارائه شد. UTF-8 سیستم متفاوتی جهت نگهداری رشته های یونیکد می باشد. در UTF-8 هر کدپوینت از 0 تا 127 بجای دو بایت تنها در یک بایت ذخیره می گردد. تنها کدپوینت های 128 به بالا در دو، سه، تا شش بایت ذخیره می شوند. این امر باعث شد متون لاتین در UTF-8 عینا (از لحاظ کدپوینت) مانند ASCII باشد، در واقع Hello که مقدار U+0048 U+0065 U+006C U+006C U+006F را داشت بصورت 48 65 6C 6C 6F ذخیره می گردد که برابر همان مقداریه که در ASCII، ANSI و هر OEM Character Set دیگر در دنیا ذخیره می شد! یعنی هر عبارتی از یونیکد می تواند به ASCII تبدیل (Encode) شود که اگر حرف متناظر موجود نداشته باشد علامت "؟" بجای آن قرار می گیرد.

[taha]

صرفا جهت اطلاع رسانی بود؟

نه فقط!

ببخشید دیر شد(مشکلاته دیگه).

[naeemeh]

دوستان واقعا ممنونم از راهنماییهاتون،من مشکلم حل شد.از تابع unicodetoiransystem استفاده کردم.چون نوشته های داخل بانک با سپند فارسی شده بود و از کدهای ایران سیستم استفاده می کنه.واسه همین وقتی این تابع رو نوشتم مشکلم حل شد.ممنون از همفکری شما.موفق باشید.

[taha]

خب، اینایی که تا اینجا شرح دادید چه ربطی به موضوع پشتیبانی دلفی از یونیکد و بطور خاص نوع داده UTF8String داشت؟

طبق خلاصه بسیار مختصری که در بالا آمد، مثالی که شما بیان کرده بودید برای Unicode (ذخیره بصورت 00 48 00 65 00 6C 00 6C 00 6F) بود نه UTF-8!
شما اگر در همان مثالی که بیان کردید (متن داخل NotePad) بجای بکاربردن یونیکد، از UTF-8، جهت ذخیره کردن استفاده کنید، خواهید دید در خواندن فایل با استفاده از تابع UTF8ToAnsi هیچ مشکلی ندارید و هیچ نیازی به کامپوننت های TNT نمی باشد.

نوع داده UTF8String جهت پشتیبانی از UTF-8 هست و توابع UTF8ToAnsi و AnsiToUtf8 جهت تبدیل بین این دو تایپ.

[vcldeveloper]

شما اگر در همان مثالی که بیان کردید (متن داخل NotePad) بجای بکاربردن یونیکد، از UTF-8، جهت ذخیره کردن استفاده کنید، خواهید دید در خواندن فایل با استفاده از تابع UTF8ToAnsi هیچ مشکلی ندارید و هیچ نیازی به کامپوننت های TNT نمی باشد.

برخلاف تصور شما، من دقیقا از UTF-8 برای ذخیره متن در NotePad استفاده کردم. نه تنها NotePad، بلکه می تونید با ++NotePad یا با مرورگر وب خودتون هم اونو آزمایش کنید.
در ضمن؛ توجه داشته باشید که تکه متن هایی که در چند پست اخیر قرار دادید، چیزی که صحبت من رو نقض بکنه نداشت، بلکه همون صحبت ها رو تایید کرد. لزومی نداره روی یک نظر غیر علمی بیش از حد پافشاری بکنید. شما هر وقت تونستید یک متن فارسی UTF-8 (نه Windows-1252) را در نوع داده UTF8String بدرستی ذخیره کنید، کد خودتون رو اینجا قرار بدید که ما هم استفاده کنیم.

[taha]

لزومی نداره روی یک نظر غیر علمی بیش از حد پافشاری بکنی

...!!!!!!!!

کد خودتون رو اینجا قرار بدید که ما هم استفاده کنیم

امیدوارم مفید واقع بشه.

[vcldeveloper]

امیدوارم مفید واقع بشه.

نمی دونم چرا اصرار دارید که یک بحث ساده دو دوتا چهارتا رو پیچیده کنید:
مستندات دلفی میگه که نوع داده string فعلا برابر با AnsiString هست. از طرفی در سورسی که همراه دلفی ارائه شده، نوع داده UTF8String بصورت UTF8String = type of String معرفی شده، از اینجا میشه یک نتیجه منطقی گرفت که:
UTF8String = AnsiString

با توجه به توضیحاتی که درباره UTF-8 دادم، و لینک هایی که مطرح شد، و مطالب مختصری هم که خود شما درباره اش نوشتید، مشخص شد که UTF-8 با ASCII سازگار هست. از اونجایی که ASCII فقط برای کارکترهای لاتین تعریف شده، میشه نتیجه گرفت که UTF-8 فقط با کارکترهای لاتینی که یونی کد نباشند سازگار هست و اگر کارکترهای غیرلاتین استفاده بشند، باید از بایت های بیشتری برای ذخیره اونها استفاده بشه که ASCII و ANSI همچین قابلیتی ندارند. البته میشه با استفاده از Code Page یک زبان خاص، بعضی کارکترهای اسکی (کد 127 به بالا) را با کارکترهای یک زبان خاص جایگزین کرد که با مفهوم یونی کد و UTF-8 فرق میکنه.
این تئوری ماجرا بود.

یک توضیحی در پست قبلی خودم درباره آزمایش این مسئله هم زدم، اما شما برای اثبات ادعای خود که UTF8String قادر به ذخیره کارکترهای غیرلاتین یونی کد هم هست، نمونه سورس کدی آماده کردید. ظاهرا این نمونه سورس درست عمل میکنه و میشه از UTF8String برای کارکترهای فارسی هم استفاده کرد. اما، ظاهرا نقش سیستم عامل را فراموش کردید:
وقتی در ویندوز XP (در Vista نمی دونم کجا ست) در Regional and Language Settings در تب Advanced زبان Farsi را برای برنامه های non-unicode (یعنی همین برنامه هایی که الان با دلفی ایجاد می کنید) انتخاب می کنید، ویندوز خودش تبدیلات لازم را برای برنامه شما انجام میده، در نتیجه شما می بینید نوع داده AnsiString که قابلیت نگه داری کارکترهای یونی کد فارسی را نداره، متن UTF-8 را بدرستی نگه داری میکنه؛ یعنی، ویندوز کارکترهای UTF-8 را با توجه به Code Page ایی که انتخاب کردید، برای شما تبدیل میکنه. برای اثبات این مسئله، کافی هست که تنظیم فوق را بر روی زبانی غیر از فارسی (مثلا English) قرار بدید و سیستم را یک بار Reset کنید، اون وقت متوجه میشید که نوع داده UTF8String شما قادر به نگه داری کارکترهای فارسی موجود در فایل متن UTF-8 نیست.

اگر نوع داده AnsiString همچین قابلیتی را داشت، اینقدر بحث بر سر پشتیبانی دلفی و VCL از یونی کد در نمی گرفت، نوع داده WideString بوجود نمی آمد، و کامپوننت هایی مثل مجموعه TNT ساخته نمی شدند.

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

تمایلی به ادامه این بحث ندارم، چون همونطور که قبلا هم گفتم، بحث به سمت غیرعلمی شدن و به نوعی کل کل تبدیل شده. اون چیزی که باید گفته می شد، گفته شده.