ฉันเพิ่งเริ่มเขียนโปรแกรม Windows และหลังจากอ่านหนังสือ Petzold ฉันสงสัยว่า:

ยังคงเป็นแนวทางปฏิบัติที่ดีในการใช้TCHARtype และ_T()function เพื่อประกาศสตริงหรือว่าฉันควรใช้wchar_tand L""strings ในโค้ดใหม่หรือไม่

ฉันจะกำหนดเป้าหมายเฉพาะ Windows 2000 ขึ้นไปและรหัสของฉันจะเป็นi18nตั้งแต่เริ่มต้น

ฉันจะยังคงใช้ไวยากรณ์ TCHAR หากฉันกำลังทำโปรเจ็กต์ใหม่ในวันนี้ ไม่มีความแตกต่างในทางปฏิบัติมากนักระหว่างการใช้มันกับไวยากรณ์ของ WCHAR และฉันชอบรหัสที่ชัดเจนในประเภทอักขระ เนื่องจากฟังก์ชัน API และอ็อบเจ็กต์ตัวช่วยส่วนใหญ่ใช้ / ใช้ประเภท TCHAR (เช่น CString) จึงเหมาะสมที่จะใช้ นอกจากนี้ยังช่วยให้คุณมีความยืดหยุ่นหากคุณตัดสินใจที่จะใช้รหัสในแอป ASCII ในบางจุดหรือหาก Windows เคยพัฒนาเป็น Unicode32 เป็นต้น

หากคุณตัดสินใจที่จะไปเส้นทาง WCHAR ฉันจะอธิบายอย่างชัดเจนเกี่ยวกับเส้นทางนี้ นั่นคือใช้ CStringW แทน CString และการแคสต์มาโครเมื่อแปลงเป็น TCHAR (เช่น: CW2CT)

นั่นคือความคิดของฉันอย่างไรก็ตาม

คำตอบสั้น ๆ : NO

เช่นเดียวกับคนอื่น ๆ ที่เขียนไว้แล้วโปรแกรมเมอร์จำนวนมากยังคงใช้ TCHAR และฟังก์ชันที่เกี่ยวข้อง ในความต่ำต้อยของฉันแนวคิดทั้งหมดเป็นความคิดที่ไม่ดี การประมวลผลสตริงUTF-16แตกต่างจากการประมวลผลสตริง ASCII / MBCS แบบธรรมดามาก หากคุณใช้อัลกอริทึม / ฟังก์ชั่นเดียวกันกับทั้งสองอย่าง (นี่คือความคิดของ TCHAR!) คุณจะได้รับประสิทธิภาพที่แย่มากในเวอร์ชัน UTF-16 หากคุณใช้การต่อสตริงแบบธรรมดามากกว่าเล็กน้อย (เช่น การแยกวิเคราะห์ ฯลฯ ) เหตุผลหลักคือSurrogates

ยกเว้นอย่างเดียวกับเมื่อคุณจริงๆต้องรวบรวมแอพลิเคชันของคุณสำหรับระบบที่ไม่สนับสนุน Unicode ฉันเห็นเหตุผลที่จะใช้สัมภาระนี้จากที่ผ่านมาในการประยุกต์ใช้ใหม่ไม่มี

ฉันต้องเห็นด้วยกับ Sascha หลักฐานพื้นฐานของTCHAR/ _T()/ etc. คือคุณสามารถเขียนแอปพลิเคชันที่อิง "ANSI" จากนั้นให้การสนับสนุน Unicode ได้อย่างน่าอัศจรรย์โดยการกำหนดมาโคร แต่นี่เป็นไปตามสมมติฐานที่ไม่ดีหลายประการ:

ที่คุณสร้างซอฟต์แวร์ทั้งเวอร์ชัน MBCS และ Unicode อย่างแข็งขัน

มิฉะนั้นคุณจะเพลี่ยงพล้ำและใช้char*สตริงธรรมดาในหลาย ๆ ที่

ที่คุณไม่ใช้แบ็กสแลชที่ไม่ใช่ ASCII Escape ในตัวอักษร _T ("... ")

เว้นแต่การเข้ารหัส "ANSI" ของคุณจะเป็น ISO-8859-1 ผลลัพธ์char*และwchar_t*ตัวอักษรจะไม่แสดงอักขระเดียวกัน

สตริง UTF-16 นั้นใช้เหมือนกับสตริง "ANSI"

พวกเขาไม่. Unicode แนะนำแนวคิดหลายประการที่ไม่มีอยู่ในการเข้ารหัสอักขระแบบเดิมส่วนใหญ่ ตัวแทน การรวมอักขระ Normalization กฎการวางเงื่อนไขที่คำนึงถึงภาษา

และที่สำคัญที่สุดคือความจริงที่ว่า UTF-16 แทบจะไม่ถูกบันทึกลงในดิสก์หรือส่งทางอินเทอร์เน็ต: UTF-8 มีแนวโน้มที่จะเป็นที่ต้องการสำหรับการแสดงภายนอก

แอปพลิเคชันของคุณไม่ได้ใช้อินเทอร์เน็ต

(ตอนนี้นี่อาจเป็นข้อสันนิษฐานที่ถูกต้องสำหรับซอฟต์แวร์ของคุณแต่ ... )

เว็บวิ่งบน UTF-8และมากมายเหลือเฟือของการเข้ารหัสยาก TCHARแนวคิดเพียงตระหนักที่สอง: "ANSI" (ซึ่งไม่สามารถเป็น UTF-8 ) และ "Unicode" (UTF-16) อาจเป็นประโยชน์สำหรับการทำให้ Windows API ของคุณเรียก Unicode-Aware แต่มันก็ไร้ประโยชน์สำหรับการสร้างเว็บและแอปอีเมล Unicode-alert

ว่าคุณไม่ใช้ไลบรารีที่ไม่ใช่ของ Microsoft

TCHARไม่มีใครใช้อื่น Pocoใช้std::stringและ UTF-8 SQLiteมี UTF-8 และ UTF-16 รุ่นของ API ของ TCHARแต่ไม่ TCHARไม่ได้อยู่ในไลบรารีมาตรฐานดังนั้นอย่าเลยstd::tcoutเว้นแต่คุณต้องการกำหนดด้วยตัวเอง

สิ่งที่ฉันแนะนำแทน TCHAR

อย่าลืมว่ามีการเข้ารหัส "ANSI" ยกเว้นเมื่อคุณต้องการอ่านไฟล์ที่ไม่ใช่ UTF-8 ที่ถูกต้อง ลืมTCHARเหมือนกัน. เรียกฟังก์ชัน Windows API เวอร์ชัน "W" เสมอ #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

บทความIntroduction to Windows Programmingเกี่ยวกับ MSDN กล่าว

แอปพลิเคชันใหม่ควรเรียกเวอร์ชัน Unicode (ของ API) เสมอ

TEXTและTCHARแมโครมีประโยชน์น้อยในวันนี้เพราะทุกการใช้งานควรใช้ Unicode

ฉันจะติดและwchar_tL""

ฉันต้องการแนะนำวิธีการที่แตกต่างกัน (ไม่ใช่ทั้งสองอย่าง)

ในการสรุปให้ใช้ char * และ std :: string โดยสมมติว่ามีการเข้ารหัส UTF-8 และทำการแปลงเป็น UTF-16 เมื่อตัดฟังก์ชัน API เท่านั้น

ข้อมูลเพิ่มเติมและเหตุผลสำหรับวิธีการนี้ในโปรแกรม Windows สามารถพบได้ใน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:

1. หากใบสมัครของคุณมีขนาดเล็กและไม่เกี่ยวข้องกับการประมวลผลข้อความ (เช่นเพียงแค่ผ่านรอบสตริงข้อความที่เป็นข้อโต้แย้ง) WCHARแล้วติดกับ เนื่องจากวิธีนี้ง่ายกว่าในการทำงานกับ WinAPI พร้อมการสนับสนุน Unicode
2. มิฉะนั้นฉันขอแนะนำให้ใช้ UTF-8 เป็นการเข้ารหัสภายในและจัดเก็บข้อความในสตริง char หรือ std :: string และแอบแฝงเป็น UTF-16 เมื่อเรียกใช้ WinAPI UTF-8เป็นการเข้ารหัสที่โดดเด่นและมีไลบรารีและเครื่องมือที่มีประโยชน์มากมายในการประมวลผลสตริง UTF-8

ตรวจสอบเว็บไซต์ที่ยอดเยี่ยมนี้เพื่ออ่านข้อมูลเชิงลึกเพิ่มเติม: http://utf8everywhere.org/

ใช่แน่นอน; อย่างน้อยสำหรับมาโคร _T ฉันไม่ค่อยแน่ใจเกี่ยวกับเนื้อหาแบบ Wide-character

เหตุผลก็คือการสนับสนุน WinCE หรือแพลตฟอร์ม Windows อื่น ๆ ที่ไม่ได้มาตรฐานให้ดีขึ้น หากคุณมั่นใจ 100% ว่ารหัสของคุณจะยังคงอยู่ใน NT คุณอาจใช้การประกาศ C-string ปกติได้ อย่างไรก็ตามควรมีแนวโน้มที่จะใช้แนวทางที่ยืดหยุ่นมากขึ้นเนื่องจากการ # กำหนดมาโครนั้นบนแพลตฟอร์มที่ไม่ใช่หน้าต่างนั้นง่ายกว่ามากเมื่อเทียบกับการใช้โค้ดหลายพันบรรทัดและเพิ่มเข้าไปทุกที่ในกรณีที่คุณต้องพอร์ตไลบรารีบางส่วน ไปยัง windows mobile

IMHO หากมี TCHAR อยู่ในโค้ดของคุณแสดงว่าคุณกำลังทำงานในระดับนามธรรมที่ไม่ถูกต้อง

ใช้สตริงประเภทใดก็ได้ที่สะดวกที่สุดสำหรับคุณเมื่อจัดการกับการประมวลผลข้อความหวังว่าจะเป็นสิ่งที่รองรับ Unicode แต่ขึ้นอยู่กับคุณ ทำการแปลงที่ขอบเขต OS API ตามความจำเป็น

เมื่อจัดการกับเส้นทางไฟล์ให้เพิ่มประเภทที่กำหนดเองของคุณแทนการใช้สตริง สิ่งนี้จะช่วยให้คุณใช้ตัวคั่นพา ธ ที่เป็นอิสระจากระบบปฏิบัติการซึ่งจะทำให้คุณมีอินเทอร์เฟซที่ง่ายกว่าในการเข้ารหัสมากกว่าการต่อและการแยกสตริงด้วยตนเองและจะปรับให้เข้ากับระบบปฏิบัติการต่างๆได้ง่ายขึ้นมาก (ansi, ucs-2, utf-8 อะไรก็ได้) .

เหตุผลเดียวที่ฉันเห็นว่าควรใช้สิ่งอื่นนอกเหนือจาก WCHAR ที่ชัดเจนคือความสามารถในการพกพาและประสิทธิภาพ

หากคุณต้องการทำให้ไฟล์ปฏิบัติการสุดท้ายของคุณมีขนาดเล็กที่สุดให้ใช้ถ่าน

หากคุณไม่สนใจเกี่ยวกับการใช้ RAM และต้องการให้ความเป็นสากลเป็นเรื่องง่ายเหมือนการแปลง่ายๆให้ใช้ WCHAR

หากคุณต้องการทำให้โค้ดของคุณมีความยืดหยุ่นให้ใช้ TCHAR

หากคุณวางแผนที่จะใช้เฉพาะอักขระละตินคุณอาจใช้สตริง ASCII / MBCS เพื่อให้ผู้ใช้ของคุณไม่ต้องการ RAM มากนัก

สำหรับผู้ที่ "i18n ตั้งแต่เริ่มต้นใช้งาน" ให้ประหยัดพื้นที่ซอร์สโค้ดและใช้ฟังก์ชัน Unicode ทั้งหมด

เพียงแค่เพิ่มคำถามเก่า:

ไม่

เริ่มโปรเจ็กต์ CLR C ++ ใหม่ใน VS2010 Microsoft เองก็ใช้L"Hello World"'nuff กล่าว

TCHARมีความหมายใหม่กับพอร์ตจากไปWCHARCHAR

https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page

Windows 10รุ่นล่าสุดได้ใช้หน้ารหัส ANSI และ -A APIs เป็นเครื่องมือในการแนะนำการสนับสนุน UTF-8 สำหรับแอป หากกำหนดค่าโค้ดเพจ ANSI สำหรับ UTF-8, -A APIs จะทำงานใน UTF-8