هل لا تزال TCHAR ذات صلة؟
https://stackoverflow.com/questions/234365
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
أنا جديد في برمجة Windows وبعد قراءة كتاب Petzold تساءلت:
هل لا يزال استخدام TCHAR اكتب و _T() وظيفة للإعلان عن السلاسل أو إذا كان ينبغي لي فقط استخدام wchar_t و L"" سلاسل في التعليمات البرمجية الجديدة؟
سأستهدف فقط نظام التشغيل Windows 2000 والإصدارات الأحدث وسيكون الكود الخاص بي هو ذلك i18n من البداية.
المحلول
وأود أن الاستمرار في استخدام بناء الجملة TCHAR إذا كنت أفعله مشروع جديد اليوم. ليس هناك فرق عملي كبير بين استخدامه وبناء الجملة WCHAR، وأنا أفضل كود وهو صريح في ما هو نوع الحرف. وبما أن معظم وظائف API وكائنات مساعد تأخذ / استخدام أنواع TCHAR (على سبيل المثال: CString)، فإنه يجعل من مجرد شعور لاستخدامها. بالإضافة إلى أنه يتيح لك المرونة إذا قررت استخدام التعليمات البرمجية في التطبيق ASCII في مرحلة ما، أو إذا تطور ويندوز من أي وقت مضى إلى Unicode32، وما إلى ذلك.
إذا كنت ترغب في أن يسلك الطريق WCHAR، وسأكون صريحا حول هذا الموضوع. وهذا يعني، استخدام CStringW بدلا من CString، والصب وحدات الماكرو عند التحويل إلى TCHAR. (على سبيل المثال: CW2CT)
وهذا هو رأيي، على أي حال.
نصائح أخرى
الجواب القصير: لا.
مثل كل الآخرين الذين كتبوا بالفعل، لا يزال الكثير من المبرمجين يستخدمون TCHARs والوظائف المقابلة لها.برأيي المتواضع كان المفهوم برمته فكرة سيئة. UTF-16 تختلف معالجة السلسلة كثيرًا عن معالجة سلسلة ASCII/MBCS البسيطة.إذا كنت تستخدم نفس الخوارزميات/الوظائف مع كليهما (وهذا هو ما تستند إليه فكرة TCHAR!)، فستحصل على أداء سيئ للغاية في إصدار UTF-16 إذا كنت تفعل أكثر قليلاً من مجرد تسلسل سلسلة بسيط (مثل تحليل الخ).السبب الرئيسي هو البدائل.
مع الاستثناء الوحيد عندما حقًا يتعين عليك تجميع تطبيقك لنظام لا يدعم Unicode. لا أرى أي سبب لاستخدام هذه الأمتعة من الماضي في تطبيق جديد.
يجب أن أتفق مع ساشا.الفرضية الأساسية ل TCHAR / _T() / إلخ.هو أنه يمكنك كتابة تطبيق يستند إلى "ANSI" ومن ثم منحه دعم Unicode بطريقة سحرية عن طريق تحديد ماكرو.لكن هذا يعتمد على عدة افتراضات سيئة:
أن تقوم بشكل نشط بإنشاء إصدارات MBCS وUnicode من برنامجك
وإلا أنت سوف تنزلق واستخدام العادي char* سلاسل في العديد من الأماكن.
عدم استخدام خطوط مائلة عكسية غير ASCII في الأحرف _T("...") الحرفية
ما لم يكن ترميز "ANSI" الخاص بك هو ISO-8859-1، فإن الناتج char* و wchar_t* لن تمثل الأحرف الحرفية نفس الأحرف.
يتم استخدام سلاسل UTF-16 تمامًا مثل سلاسل "ANSI".
هم ليسوا كذلك.يقدم Unicode العديد من المفاهيم غير الموجودة في معظم ترميزات الأحرف القديمة.البدائل.الجمع بين الشخصيات.تطبيع.قواعد الغلاف الشرطية والحساسة للغة.
ولعل الأهم من ذلك هو حقيقة أن UTF-16 نادرًا ما يتم حفظه على القرص أو إرساله عبر الإنترنت:يميل UTF-8 إلى التفضيل للتمثيل الخارجي.
أن تطبيقك لا يستخدم الإنترنت
(الآن، قد يكون هذا افتراضًا صحيحًا لـ لك البرمجيات ولكن...)
يعمل الويب على UTF-8 و عدد كبير من الترميزات النادرة.ال TCHAR المفهوم لا يعترف إلا باثنين:"ANSI" (التي لا أستطيع يكون UTF-8) و"Unicode" (UTF-16).قد يكون من المفيد جعل مكالمات Windows API الخاصة بك متوافقة مع Unicode، ولكن من غير المجدي جعل تطبيقات الويب والبريد الإلكتروني لديك متوافقة مع Unicode.
عدم استخدام مكتبات غير تابعة لشركة Microsoft
لا أحد يستخدم TCHAR. بوكو الاستخدامات std::string وUTF-8. سكليتي يحتوي على إصدارات UTF-8 وUTF-16 من واجهة برمجة التطبيقات الخاصة به، ولكن لا TCHAR. TCHAR ليس حتى في المكتبة القياسية، لذلك لا std::tcout إلا إذا كنت تريد تعريفه بنفسك.
ما أوصي به بدلاً من TCHAR
انسَ وجود ترميزات "ANSI"، إلا عندما تحتاج إلى قراءة ملف غير صالح UTF-8.نسيت ذلك TCHAR أيضاً.قم دائمًا باستدعاء الإصدار "W" من وظائف Windows API. #define _UNICODE فقط للتأكد من عدم استدعاء وظيفة "A" عن طريق الخطأ.
استخدم دائمًا ترميزات UTF للسلاسل:UTF-8 ل char سلاسل وUTF-16 (على نظام التشغيل Windows) أو UTF-32 (على الأنظمة المشابهة لنظام Unix). wchar_t سلاسل. typedef UTF16 و UTF32 أنواع الشخصيات لتجنب اختلافات النظام الأساسي.
إذا كنت تتساءل عما إذا كانت لا تزال قيد التطبيق، فنعم - فهي لا تزال تستخدم قليلاً.لن ينظر أحد إلى الكود الخاص بك بطريقة مضحكة إذا كان يستخدم TCHAR و_T("").المشروع الذي أعمل عليه الآن هو التحويل من ANSI إلى Unicode - ونحن نسير في المسار المحمول (TCHAR).
لكن...
سيكون تصويتي هو نسيان كافة وحدات الماكرو المحمولة ANSI/UNICODE (TCHAR، _T("")، وجميع مكالمات _tXXXXXX، وما إلى ذلك...) وافتراض Unicode في كل مكان.لا أرى حقًا أي فائدة من أن تكون محمولًا إذا لم تكن بحاجة أبدًا إلى إصدار ANSI.سأستخدم جميع وظائف وأنواع الأحرف الواسعة مباشرةً.قم بإعداد جميع القيم الحرفية للسلسلة مسبقًا باستخدام حرف L.
ال مقالة مقدمة عن برمجة الويندوز على MSDN يقول
يجب أن تستدعي التطبيقات الجديدة دائمًا إصدارات Unicode (من واجهة برمجة التطبيقات).
ال نص و تشار أصبحت وحدات الماكرو أقل فائدة اليوم، لأن جميع التطبيقات يجب أن تستخدم Unicode.
أود أن ألتزم به wchar_t و L"".
وأود أن أقترح نهجا مختلفا (أي من اثنين).
لتلخيص، استخدم شار * والأمراض المنقولة جنسيا :: سلسلة، على افتراض ترميز UTF-8، والقيام التحويلات إلى UTF-16 فقط عندما التفاف وظائف API.
ويمكن الاطلاع على مزيد من المعلومات والتبرير لهذا النهج في برامج ويندوز في http://www.utf8everywhere.org .
TCHAR/WCHAR قد يكون كافيا لبعض المشاريع القديمة.ولكن بالنسبة للتطبيقات الجديدة، أود أن أقول لا.
كل هذه TCHAR/WCHAR الأشياء هناك لأسباب تاريخية. TCHAR يوفر طريقة أنيقة (تمويه) للتبديل بين ترميز نص ANSI (MBCS) وترميز نص Unicode (UTF-16).في الماضي، لم يكن لدى الناس فهم لعدد حروف جميع لغات العالم.لقد افترضوا أن 2 بايت كانت كافية لتمثيل جميع الأحرف وبالتالي استخدام نظام ترميز أحرف ثابت الطول WCHAR.ومع ذلك، لم يعد هذا صحيحًا بعد إصدار Unicode 2.0 في 1996.
ذلك بالقول:بغض النظر عن ما تستخدمه فيه CHAR/WCHAR/TCHAR, ، يجب أن يكون جزء معالجة النص في برنامجك قادرًا على التعامل معه أحرف متغيرة الطول للتدويل.
لذلك تحتاج في الواقع إلى القيام بأكثر من مجرد اختيار واحد من بينها CHAR/WCHAR/TCHAR للبرمجة في نظام التشغيل Windows:
- إذا كان طلبك صغيرًا ولا يتضمن معالجة النصوص (أيمجرد تمرير السلسلة النصية كوسائط)، ثم التزم بها
WCHAR.نظرًا لأنه من الأسهل بهذه الطريقة العمل مع WinAPI بدعم Unicode. - بخلاف ذلك، أقترح استخدام UTF-8 كتشفير داخلي وتخزين النصوص في سلاسل char أو std::string.وقم بإخفائها إلى UTF-16 عند الاتصال بـ WinAPI. ترميز UTF-8 هو الآن التشفير السائد وهناك الكثير من المكتبات والأدوات المفيدة لمعالجة سلاسل UTF-8.
تحقق من هذا الموقع الرائع لمزيد من القراءة المتعمقة:http://utf8everywhere.org/
نعم، بالتأكيد. على الأقل للماكرو _T. أنا لست متأكدا من الاشياء حرف واسعة، وإن كان.
ووالسبب هو أفضل ويندوز سي دعم أو غيرها من منصات ويندوز غير القياسية. إذا كنت 100٪ على يقين من أن الشفرة ستبقى على NT، ثم ربما يمكنك فقط استخدام الإعلانات C سلسلة العادية. ومع ذلك، فمن الأفضل أن تميل نحو نهج أكثر مرونة، كما انه من الاسهل بكثير ل# تعريف ذلك الماكرو بعيدا عن منصة غير Windows بالمقارنة مع يمر الآلاف من خطوط رمز واضاف انه في كل مكان في حال كنت بحاجة إلى ميناء بعض المكتبات إلى ويندوز موبايل.
وIMHO، إذا كان هناك TCHARs في التعليمات البرمجية الخاصة بك، كنت تعمل على مستوى الخطأ من التجريد.
استخدم مهما نوع السلسلة هو الأكثر ملاءمة لك عند التعامل مع معالجة النصوص - وهذا يؤمل أن يكون شيئا دعم يونيكود، ولكن هذا متروك لكم. هل تحويل في حدود API OS عند الضرورة.
عند التعامل مع مسارات الملفات، إثارة نوع المخصص الخاص بك بدلا من استخدام السلاسل. هذا سيسمح لك فصل مسار OS-مستقلة، وسوف تعطيك واجهة أسهل إلى رمز ضد من اليدوي سلسلة سلسلة وتقسيم، وسيكون من الأسهل كثيرا على التكيف مع أنظمة تشغيل مختلفة (ANSI، UCS-2، UTF-8، أيا كان) .
والأسباب الوحيدة أرى أن استخدام أي شيء آخر غير WCHAR صريح هي قابلية وكفاءة.
إذا كنت تريد أن تجعل تنفيذ النهائي صغيرة قدر الإمكان شار الاستخدام.
إذا كنت لا تهتم حول استخدام ذاكرة الوصول العشوائي ويريدون تدويل ليكون سهلا كما ترجمة بسيطة، استخدم WCHAR.
إذا كنت تريد أن تجعل التعليمات البرمجية مرونة، استخدم TCHAR.
إذا كنت تخطط فقط على استخدام الحروف اللاتينية، قد تستخدم كذلك في ASCII / MBCS سلاسل بحيث المستخدم الخاص بك لا تحتاج الى الكثير من ذاكرة الوصول العشوائي.
وبالنسبة للأشخاص الذين هم "I18N من بدء"، تنقذ نفسك مساحة شفرة المصدر وببساطة استخدام جميع وظائف يونيكود.
وفقط مشيرا إلى السؤال القديم:
تحليل NO
وانتقل بدء مشروع CLR C ++ جديد في VS2010. ، 'قال nuff مايكروسوفت نفسها استخدام L"Hello World".
