std :: wstring VS std :: string

Saya tidak dapat memahami perbedaan antara std::stringdan std::wstring. Saya tahu wstringmendukung karakter lebar seperti karakter Unicode. Saya sudah mendapat pertanyaan berikut:

1. Ketika saya harus menggunakan std::wstringlebih std::string?
2. Bisakah std::stringmemegang seluruh rangkaian karakter ASCII, termasuk karakter khusus?
3. Apakah std::wstringdidukung oleh semua kompiler C ++ yang populer?
4. Apa sebenarnya " karakter lebar "?

string? wstring?

std::stringadalah basic_stringtemplated pada a char, dan std::wstringpada a wchar_t.

char vs. wchar_t

charseharusnya memiliki karakter, biasanya karakter 8-bit.
wchar_tseharusnya memiliki karakter yang luas, dan kemudian, hal menjadi rumit:
Di Linux, a wchar_tadalah 4 byte, sedangkan pada Windows, itu 2 byte.

Bagaimana dengan Unicode ?

Masalahnya adalah tidak satu charpun wchar_tsecara langsung terkait dengan unicode.

Di Linux?

Mari kita mengambil OS Linux: Sistem Ubuntu saya sudah sadar unicode. Ketika saya bekerja dengan string char, itu secara asli dikodekan dalam UTF-8 (yaitu string Unicode karakter). Kode berikut:

#include <cstring>
#include <iostream>

int main(int argc, char* argv[])
{
   const char text[] = "olé" ;


   std::cout << "sizeof(char)    : " << sizeof(char) << std::endl ;
   std::cout << "text            : " << text << std::endl ;
   std::cout << "sizeof(text)    : " << sizeof(text) << std::endl ;
   std::cout << "strlen(text)    : " << strlen(text) << std::endl ;

   std::cout << "text(ordinals)  :" ;

   for(size_t i = 0, iMax = strlen(text); i < iMax; ++i)
   {
      std::cout << " " << static_cast<unsigned int>(
                              static_cast<unsigned char>(text[i])
                          );
   }

   std::cout << std::endl << std::endl ;

   // - - - 

   const wchar_t wtext[] = L"olé" ;

   std::cout << "sizeof(wchar_t) : " << sizeof(wchar_t) << std::endl ;
   //std::cout << "wtext           : " << wtext << std::endl ; <- error
   std::cout << "wtext           : UNABLE TO CONVERT NATIVELY." << std::endl ;
   std::wcout << L"wtext           : " << wtext << std::endl;

   std::cout << "sizeof(wtext)   : " << sizeof(wtext) << std::endl ;
   std::cout << "wcslen(wtext)   : " << wcslen(wtext) << std::endl ;

   std::cout << "wtext(ordinals) :" ;

   for(size_t i = 0, iMax = wcslen(wtext); i < iMax; ++i)
   {
      std::cout << " " << static_cast<unsigned int>(
                              static_cast<unsigned short>(wtext[i])
                              );
   }

   std::cout << std::endl << std::endl ;

   return 0;
}

menampilkan teks berikut:

sizeof(char)    : 1
text            : olé
sizeof(text)    : 5
strlen(text)    : 4
text(ordinals)  : 111 108 195 169

sizeof(wchar_t) : 4
wtext           : UNABLE TO CONVERT NATIVELY.
wtext           : ol�
sizeof(wtext)   : 16
wcslen(wtext)   : 3
wtext(ordinals) : 111 108 233

Anda akan melihat teks "olé" di charbenar-benar dibangun oleh empat karakter: 110, 108, 195 dan 169 (tidak termasuk nol di belakangnya). (Saya akan membiarkan Anda mempelajari wchar_tkode sebagai latihan)

Jadi, ketika bekerja dengan charLinux, Anda biasanya harus menggunakan Unicode tanpa menyadarinya. Dan seperti std::stringbekerja dengan char, jadi std::stringsudah siap-unicode.

Perhatikan bahwa std::string, seperti API string C, akan menganggap string "olé" memiliki 4 karakter, bukan tiga. Jadi Anda harus berhati-hati saat memotong / bermain dengan karakter unicode karena beberapa kombinasi karakter dilarang di UTF-8.

Di Windows?

Di Windows, ini sedikit berbeda. Win32 harus mendukung banyak aplikasi yang bekerja dengan chardan pada berbagai charset / codepages yang diproduksi di seluruh dunia, sebelum munculnya Unicode.

Jadi solusi mereka sangat menarik: Jika sebuah aplikasi bekerja char, maka string char dikodekan / dicetak / ditampilkan pada label GUI menggunakan charset / codepage lokal pada mesin. Misalnya, "olé" akan menjadi "olé" di Windows yang dilokalisasikan di Prancis, tetapi akan menjadi sesuatu yang berbeda pada Windows yang dilokalisasi dengan cyrillic ("olй" jika Anda menggunakan Windows-1251 ). Dengan demikian, "aplikasi historis" biasanya akan tetap bekerja dengan cara lama yang sama.

Untuk aplikasi berbasis Unicode, Windows menggunakan wchar_t, yang lebar 2-byte, dan dikodekan dalam UTF-16 , yang Unicode dikodekan pada karakter 2-byte (atau paling tidak, UCS-2 yang paling kompatibel, yang hampir merupakan hal yang sama IIRC).

Aplikasi yang menggunakan chardikatakan "multibyte" (karena setiap mesin terbang terdiri dari satu atau lebih chars), sedangkan aplikasi yang menggunakan wchar_tdikatakan "widechar" (karena masing-masing mesin terbang terdiri dari satu atau dua wchar_t. Lihat MultiByteToWideChar dan WideCharToMultiByte Win32 API konversi untuk info lebih lanjut.

Jadi, jika Anda bekerja di Windows, Anda sangat ingin menggunakan wchar_t(kecuali jika Anda menggunakan kerangka kerja yang menyembunyikan itu, seperti GTK + atau QT ...). Faktanya adalah bahwa di balik layar, Windows bekerja dengan wchar_tstring, sehingga bahkan aplikasi historis akan memiliki charstring mereka dikonversi wchar_tketika menggunakan API seperti SetWindowText()(fungsi API tingkat rendah untuk mengatur label pada Win32 GUI).

Masalah memori?

UTF-32 adalah 4 byte per karakter, jadi tidak ada banyak yang harus ditambahkan, jika saja teks UTF-8 dan teks UTF-16 akan selalu menggunakan lebih sedikit atau jumlah memori yang sama dari teks UTF-32 (dan biasanya kurang ).

Jika ada masalah memori, maka Anda harus tahu daripada kebanyakan bahasa barat, teks UTF-8 akan menggunakan memori lebih sedikit daripada UTF-16 yang sama.

Namun, untuk bahasa lain (Cina, Jepang, dll.), Memori yang digunakan akan sama, atau sedikit lebih besar untuk UTF-8 daripada untuk UTF-16.

Secara keseluruhan, UTF-16 sebagian besar akan menggunakan 2 dan kadang-kadang 4 byte per karakter (kecuali jika Anda berurusan dengan beberapa jenis mesin terbang bahasa esoterik (Klingon? Peri?), Sedangkan UTF-8 akan menghabiskan 1 hingga 4 byte.

Lihat http://en.wikipedia.org/wiki/UTF-8#Compared_to_UTF-16 untuk info lebih lanjut.

Kesimpulan

1. Kapan saya harus menggunakan std :: wstring over std :: string?

   Di Linux? Hampir tidak pernah (§).
   Di Windows? Hampir selalu (§).
   Pada kode lintas platform? Tergantung pada perangkat Anda ...

   (§): kecuali Anda menggunakan toolkit / kerangka kerja yang mengatakan sebaliknya

2. Bisakah std::stringmemegang semua set karakter ASCII termasuk karakter khusus?

   Perhatikan: A std::stringcocok untuk memegang buffer 'biner', di mana a std::wstringtidak!

   Di Linux? Iya.
   Di Windows? Hanya karakter khusus yang tersedia untuk lokal saat ini dari pengguna Windows.

   Sunting (Setelah komentar dari Johann Gerell ):
   a std::stringakan cukup untuk menangani semua charstring berbasis (masing char- masing berupa angka dari 0 hingga 255). Tapi:

   1. ASCII seharusnya berubah dari 0 menjadi 127. Semakin tinggi charBUKAN ASCII.
   2. a chardari 0 hingga 127 akan disimpan dengan benar
   3. a chardari 128 hingga 255 akan memiliki signifikasi tergantung pada pengkodean Anda (unicode, non-unicode, dll.), tetapi itu akan dapat menampung semua mesin terbang Unicode selama kode tersebut dikodekan dalam UTF-8.

3. Apakah std::wstringdidukung oleh hampir semua kompiler C ++ yang populer?

   Sebagian besar, dengan pengecualian kompiler berbasis GCC yang porting ke Windows.
   Ini bekerja pada g ++ 4.3.2 saya (di Linux), dan saya menggunakan Unicode API di Win32 sejak Visual C ++ 6.

4. Apa sebenarnya karakter yang lebar?

   Pada C / C ++, ini adalah tipe karakter yang ditulis wchar_tyang lebih besar dari chartipe karakter sederhana . Seharusnya digunakan untuk memasukkan karakter di dalam yang indeksnya (seperti mesin terbang Unicode) lebih besar dari 255 (atau 127, tergantung ...).

Saya sarankan menghindari std::wstringpada Windows atau di tempat lain, kecuali bila diperlukan oleh antarmuka, atau di mana saja di dekat panggilan Windows API dan konversi encoding masing-masing sebagai gula sintaksis.

Pandangan saya dirangkum dalam http://utf8everywhere.org di mana saya adalah rekan penulis.

Kecuali jika aplikasi Anda adalah API-call-centric, mis. Terutama aplikasi UI, sarannya adalah untuk menyimpan string Unicode di std :: string dan disandikan dalam UTF-8, melakukan konversi dekat panggilan API. Manfaat yang diuraikan dalam artikel lebih penting daripada gangguan konversi, terutama dalam aplikasi yang kompleks. Ini sangat ganda untuk pengembangan multi-platform dan perpustakaan.

Dan sekarang, menjawab pertanyaan Anda:

1. Beberapa alasan lemah. Itu ada karena alasan historis, di mana widechars diyakini sebagai cara yang tepat untuk mendukung Unicode. Sekarang digunakan untuk antarmuka API yang lebih suka string UTF-16. Saya menggunakannya hanya di sekitar panggilan API semacam itu.
2. Ini tidak ada hubungannya dengan std :: string. Itu bisa menampung pengodean apa pun yang Anda masukkan ke dalamnya. Satu-satunya pertanyaan adalah bagaimana Anda memperlakukan kontennya. Rekomendasi saya adalah UTF-8, sehingga akan dapat menampung semua karakter Unicode dengan benar. Ini adalah praktik umum di Linux, tetapi saya pikir program Windows juga harus melakukannya.
3. Tidak.
4. Karakter lebar adalah nama yang membingungkan. Pada hari-hari awal Unicode, ada kepercayaan bahwa karakter dapat dikodekan dalam dua byte, karenanya namanya. Hari ini, singkatan dari "setiap bagian dari karakter yang panjangnya dua byte". UTF-16 dilihat sebagai urutan pasangan byte tersebut (alias Wide karakter). Karakter dalam UTF-16 membutuhkan satu atau dua pasangan.

Jadi, setiap pembaca di sini sekarang harus memiliki pemahaman yang jelas tentang fakta, situasi. Jika tidak, maka Anda harus membaca jawaban komprehensif luar biasa paercebal [btw: terima kasih!].

Kesimpulan pragmatis saya sangat sederhana: semua yang "+ karakter" pengkodean C ++ (dan STL) pada dasarnya rusak dan tidak berguna. Salahkan pada Microsoft atau tidak, itu tidak akan membantu.

Solusi saya, setelah investigasi mendalam, banyak frustrasi dan pengalaman konsekuensial adalah sebagai berikut:

1. menerima, bahwa Anda harus bertanggung jawab sendiri atas pengodean dan konversi (dan Anda akan melihat bahwa sebagian besar darinya agak sepele)

2. gunakan std :: string untuk string yang dikodekan UTF-8 (hanya a typedef std::string UTF8String)

3. menerima bahwa objek UTF8String seperti itu hanya sebuah wadah bodoh, tapi murah. Jangan pernah mengakses dan / atau memanipulasi karakter di dalamnya secara langsung (tidak ada pencarian, ganti, dan sebagainya). Anda bisa, tetapi Anda benar-benar hanya sangat, benar-benar tidak ingin membuang waktu Anda menulis algoritma manipulasi teks untuk string multi-byte! Bahkan jika orang lain sudah melakukan hal bodoh seperti itu, jangan lakukan itu! Biarlah! (Yah, ada skenario di mana masuk akal ... cukup gunakan perpustakaan ICU untuk itu).

4. gunakan std :: wstring untuk string yang disandikan UCS-2 ( typedef std::wstring UCS2String) - ini adalah kompromi, dan konsesi untuk kekacauan yang diperkenalkan oleh API WIN32). UCS-2 sudah cukup untuk sebagian besar dari kita (lebih lanjut tentang itu nanti ...).

5. gunakan instance UCS2String setiap kali diperlukan akses karakter per karakter (baca, manipulasi, dan sebagainya). Pemrosesan berbasis karakter apa pun harus dilakukan dalam representasi NON-multibyte. Sederhana, cepat, mudah.

6. tambahkan dua fungsi utilitas untuk mengkonversi bolak-balik antara UTF-8 dan UCS-2:

   UCS2String ConvertToUCS2( const UTF8String &str );
   UTF8String ConvertToUTF8( const UCS2String &str );

Konversi ini mudah, google harus membantu di sini ...

Itu dia. Gunakan UTF8String di mana pun memori berharga dan untuk semua I / O UTF-8. Gunakan UCS2String di mana pun string harus diuraikan dan / atau dimanipulasi. Anda dapat mengonversi antara dua representasi tersebut kapan saja.

Alternatif & Perbaikan

• konversi dari & ke pengkodean karakter bita tunggal (misalnya ISO-8859-1) dapat diwujudkan dengan bantuan tabel terjemahan biasa, mis. const wchar_t tt_iso88951[256] = {0,1,2,...};dan kode yang sesuai untuk konversi ke & dari UCS2.

• jika UCS-2 tidak mencukupi, daripada beralih ke UCS-4 ( typedef std::basic_string<uint32_t> UCS2String)

ICU atau perpustakaan unicode lainnya?

Untuk barang-barang canggih.

1. Ketika Anda ingin memiliki karakter lebar disimpan di string Anda. widetergantung pada implementasinya. Visual C ++ default ke 16 bit jika saya ingat dengan benar, sedangkan GCC default tergantung pada target. Panjangnya 32 bit di sini. Harap dicatat wchar_t (tipe karakter lebar) tidak ada hubungannya dengan unicode. Ini hanya dijamin bahwa ia dapat menyimpan semua anggota set karakter terbesar yang didukung oleh implementasi oleh lokalnya, dan setidaknya selama char. Anda dapat menyimpan string unicode dengan baik agar dapat std::stringmenggunakan utf-8enkode. Tapi itu tidak akan mengerti arti dari poin kode unicode. Begitustr.size()tidak akan memberi Anda jumlah karakter logis dalam string Anda, tetapi hanya jumlah elemen char atau wchar_t yang disimpan dalam string / wstring tersebut. Untuk alasan itu, orang-orang wrapper gtk / glib C ++ telah mengembangkan Glib::ustringkelas yang dapat menangani utf-8.

   Jika panjang wchar_t Anda adalah 32 bit, maka Anda dapat menggunakan utf-32sebagai pengkodean unicode, dan Anda dapat menyimpan dan menangani string unicode menggunakan pengkodean tetap (utf-32 adalah panjang tetap). Ini berarti s.size()fungsi wstring Anda kemudian akan mengembalikan jumlah elemen wchar_t dan karakter logis yang tepat.

2. Ya, char selalu setidaknya 8 bit, yang berarti dapat menyimpan semua nilai ASCII.
3. Ya, semua kompiler utama mendukungnya.

Saya sering menggunakan std :: string untuk menampung karakter utf-8 tanpa masalah sama sekali. Saya sungguh-sungguh merekomendasikan melakukan ini ketika berinteraksi dengan API yang menggunakan utf-8 sebagai tipe string asli juga.

Sebagai contoh, saya menggunakan utf-8 ketika menghubungkan kode saya dengan juru bahasa Tcl.

Peringatan utama adalah panjang string std ::, tidak lagi jumlah karakter dalam string.

1. Saat Anda ingin menyimpan karakter 'lebar' (Unicode).
2. Ya: 255 dari mereka (tidak termasuk 0).
3. Iya.
4. Inilah artikel pengantar: http://www.joelonsoftware.com/articles/Unicode.html

1. ketika Anda ingin menggunakan string Unicode dan bukan hanya ascii, membantu untuk internasionalisasi
2. ya, tapi itu tidak cocok dengan 0
3. tidak menyadari ada yang tidak
4. karakter lebar adalah cara khusus kompiler menangani representasi panjang tetap dari karakter unicode, untuk MSVC itu adalah karakter 2 byte, untuk gcc saya mengerti itu adalah 4 byte. dan +1 untuk http://www.joelonsoftware.com/articles/Unicode.html

Aplikasi yang tidak puas dengan hanya 256 karakter berbeda memiliki opsi untuk menggunakan karakter lebar (lebih dari 8 bit) atau pengkodean panjang variabel (pengkodean multibyte dalam terminologi C ++) seperti UTF-8. Karakter lebar umumnya membutuhkan lebih banyak ruang daripada pengodean panjang variabel, tetapi lebih cepat diproses. Aplikasi multi-bahasa yang memproses teks dalam jumlah besar biasanya menggunakan karakter lebar saat memproses teks, tetapi mengubahnya menjadi UTF-8 saat menyimpannya ke disk.

Satu-satunya perbedaan antara a stringdan a wstringadalah tipe data dari karakter yang mereka simpan. Sebuah string menyimpan charukuran yang dijamin setidaknya 8 bit, sehingga Anda dapat menggunakan string untuk memproses misalnya teks ASCII, ISO-8859-15, atau UTF-8. Standar tidak mengatakan apa-apa tentang set karakter atau pengodean.

Praktis setiap kompiler menggunakan set karakter yang 128 karakter pertamanya sesuai dengan ASCII. Ini juga terjadi dengan kompiler yang menggunakan pengkodean UTF-8. Hal penting yang harus diperhatikan ketika menggunakan string dalam UTF-8 atau pengkodean panjang variabel lainnya, adalah bahwa indeks dan panjangnya diukur dalam byte, bukan karakter.

Tipe data wstring adalah wchar_t, yang ukurannya tidak didefinisikan dalam standar, kecuali bahwa itu harus setidaknya sebesar char, biasanya 16 bit atau 32 bit. wstring dapat digunakan untuk memproses teks dalam implementasi pengkodean karakter lebar yang ditentukan. Karena pengkodean tidak didefinisikan dalam standar, tidak mudah untuk mengkonversi antara string dan wstrings. Seseorang tidak dapat menganggap wstrings memiliki pengkodean dengan panjang tetap yang baik.

Jika Anda tidak memerlukan dukungan multi-bahasa, Anda mungkin baik-baik saja dengan menggunakan string biasa. Di sisi lain, jika Anda menulis aplikasi grafis, seringkali API hanya mendukung karakter lebar. Maka Anda mungkin ingin menggunakan karakter lebar yang sama saat memproses teks. Ingatlah bahwa UTF-16 adalah pengodean panjang variabel, artinya Anda tidak dapat berasumsi length()untuk mengembalikan jumlah karakter. Jika API menggunakan penyandian dengan panjang tetap, seperti UCS-2, pemrosesan menjadi mudah. Mengubah antara karakter lebar dan UTF-8 sulit dilakukan dengan cara portabel, tetapi sekali lagi, antarmuka pengguna API Anda mungkin mendukung konversi.

Pertanyaan yang bagus Saya pikir DATA ENCODING (terkadang CHARSET juga terlibat) adalah MECHANISME EKSPRESI MEMORY untuk menyimpan data ke file atau mentransfer data melalui jaringan, jadi saya menjawab pertanyaan ini sebagai:

1. Kapan saya harus menggunakan std :: wstring over std :: string?

Jika platform pemrograman atau fungsi API adalah byte tunggal, dan kami ingin memproses atau mem-parsing beberapa data Unicode, misalnya membaca dari Windows'.REG file atau jaringan aliran 2-byte, kita harus mendeklarasikan variabel std :: wstring agar mudah memprosesnya. misal: wstring ws = L "中国 a" (memori 6 oktet: 0x4E2D 0x56FD 0x0061), kita dapat menggunakan ws [0] untuk mendapatkan karakter '中' dan ws [1] untuk mendapatkan karakter '国' dan ws [2] untuk dapatkan karakter 'a', dll.

2. Bisakah std :: string menampung seluruh rangkaian karakter ASCII, termasuk karakter khusus?

Iya. Tetapi perhatikan: American ASCII, berarti setiap oktet 0x00 ~ 0xFF adalah singkatan dari satu karakter, termasuk teks yang dapat dicetak seperti "123abc & * _ &" dan Anda mengatakan yang spesial, kebanyakan mencetaknya sebagai '.' hindari editor atau terminal yang membingungkan. Dan beberapa negara lain memperluas rangkaian karakter "ASCII" mereka sendiri, misalnya bahasa Cina, menggunakan 2 oktet untuk mewakili satu karakter.

3. Apakah std :: wstring didukung oleh semua kompiler C ++ yang populer?

Mungkin, atau kebanyakan. Saya telah menggunakan: VC ++ 6 dan GCC 3.3, YES

4. Apa yang dimaksud dengan "karakter lebar"?

karakter lebar sebagian besar menunjukkan penggunaan 2 oktet atau 4 oktet untuk menampung semua karakter negara. 2 oktet UCS2 adalah sampel yang representatif, dan selanjutnya mis. Bahasa Inggris 'a', memorinya 2 oktet 0x0061 (vs dalam ASCII 'memori adalah 1 oktet 0x61)

Ada beberapa jawaban yang sangat bagus di sini, tetapi saya pikir ada beberapa hal yang dapat saya tambahkan mengenai Windows / Visual Studio. Ini didasarkan pada pengalaman saya dengan VS2015. Di Linux, pada dasarnya jawabannya adalah menggunakan UTF-8 yang disandikan di std::stringmana-mana. Pada Windows / VS itu menjadi lebih kompleks. Inilah sebabnya. Windows mengharapkan string yang disimpan menggunakan chars untuk dikodekan menggunakan codepage lokal. Ini hampir selalu set karakter ASCII diikuti oleh 128 karakter khusus lainnya tergantung pada lokasi Anda. Biarkan saya hanya menyatakan bahwa ini tidak hanya ketika menggunakan Windows API, ada tiga tempat utama lainnya di mana string ini berinteraksi dengan standar C ++. Ini adalah string literal, output untuk std::coutmenggunakan <<dan meneruskan nama file std::fstream.

Saya akan berada di depan di sini bahwa saya seorang programmer, bukan spesialis bahasa. Saya menghargai bahwa USC2 dan UTF-16 tidak sama, tetapi untuk tujuan saya mereka cukup dekat untuk dipertukarkan dan saya menggunakannya di sini. Saya tidak benar-benar yakin yang menggunakan Windows, tapi saya biasanya tidak perlu tahu juga. Saya telah menyatakan UCS2 dalam jawaban ini, sangat menyesal sebelumnya jika saya mengecewakan siapa pun dengan ketidaktahuan saya tentang masalah ini dan saya senang mengubahnya jika ada kesalahan.

Literal string

Jika Anda memasukkan string literal yang hanya berisi karakter yang dapat direpresentasikan oleh codepage Anda, maka VS menyimpannya dalam file Anda dengan 1 byte per pengkodean karakter berdasarkan codepage Anda. Perhatikan bahwa jika Anda mengubah codepage Anda atau memberikan sumber Anda ke pengembang lain menggunakan halaman kode yang berbeda maka saya pikir (tetapi belum diuji) bahwa karakter akan berakhir berbeda. Jika Anda menjalankan kode di komputer menggunakan halaman kode yang berbeda maka saya tidak yakin apakah karakternya juga akan berubah.

Jika Anda memasukkan string literal yang tidak dapat diwakili oleh codepage Anda maka VS akan meminta Anda untuk menyimpan file sebagai Unicode. File tersebut kemudian akan dikodekan sebagai UTF-8. Ini berarti bahwa semua karakter Non ASCII (termasuk yang ada di codepage Anda) akan diwakili oleh 2 atau lebih byte. Ini berarti jika Anda memberikan sumber Anda kepada orang lain, sumbernya akan terlihat sama. Namun, sebelum meneruskan sumber ke kompiler, VS mengubah teks yang disandikan UTF-8 ke halaman kode teks yang disandikan dan setiap karakter yang hilang dari halaman kode diganti dengan ?.

Satu-satunya cara untuk menjamin dengan benar merepresentasikan string string Unicode dalam VS adalah mendahului string literal dengan Lmembuatnya menjadi string string yang luas. Dalam hal ini VS akan mengubah teks yang disandikan UTF-8 dari file menjadi UCS2. Anda kemudian harus meneruskan string literal ini ke std::wstringkonstruktor atau Anda perlu mengubahnya menjadi utf-8 dan memasukkannya ke dalam std::string. Atau jika mau, Anda dapat menggunakan fungsi Windows API untuk menyandikannya menggunakan halaman kode Anda untuk memasukkannya std::string, tetapi Anda mungkin juga belum menggunakan string string literal.

std :: cout

Saat mengeluarkan ke konsol menggunakan <<Anda hanya dapat menggunakan std::string, tidak std::wstringdan teks harus dikodekan menggunakan codepage lokal Anda. Jika sudah, std::wstringmaka Anda harus mengonversinya menggunakan salah satu fungsi Windows API dan karakter apa pun yang tidak ada di codepage Anda diganti ?(mungkin Anda dapat mengubah karakter, saya tidak ingat).

std :: nama file fstream

OS Windows menggunakan UCS2 / UTF-16 untuk nama file-nya jadi apa pun codepage Anda, Anda dapat memiliki file dengan karakter Unicode apa pun. Tetapi ini berarti bahwa untuk mengakses atau membuat file dengan karakter yang tidak ada pada codepage Anda, Anda harus menggunakannya std::wstring. Tidak ada jalan lain. Ini adalah ekstensi khusus Microsoft untuk std::fstreamjadi mungkin tidak dapat dikompilasi pada sistem lain. Jika Anda menggunakan std :: string maka Anda hanya dapat menggunakan nama file yang hanya menyertakan karakter pada codepage Anda.

Opsi Anda

Jika Anda hanya bekerja di Linux maka Anda mungkin tidak sampai sejauh ini. Cukup gunakan UTF-8 di std::stringmana - mana.

Jika Anda hanya bekerja di Windows, gunakan UCS2 di std::wstringmana-mana. Beberapa puritan mungkin mengatakan menggunakan UTF8 kemudian mengonversi ketika dibutuhkan, tetapi mengapa repot-repot dengan kerumitan.

Jika Anda lintas platform maka itu berantakan untuk terus terang. Jika Anda mencoba menggunakan UTF-8 di mana-mana di Windows maka Anda harus benar-benar berhati-hati dengan string literal Anda dan output ke konsol. Anda dapat dengan mudah merusak string Anda di sana. Jika Anda menggunakan di std::wstringmana-mana di Linux maka Anda mungkin tidak memiliki akses ke versi yang luas std::fstream, jadi Anda harus melakukan konversi, tetapi tidak ada risiko korupsi. Jadi secara pribadi saya pikir ini adalah pilihan yang lebih baik. Banyak yang akan tidak setuju, tapi saya tidak sendirian - itu jalan yang diambil oleh wxWidgets misalnya.

Pilihan lain bisa dengan mengetikkan unicodestringseperti std::stringdi Linux dan std::wstringdi Windows, dan memiliki makro yang disebut UNI () yang awalan L pada Windows dan tidak ada di Linux, maka kode

#include <fstream>
#include <string>
#include <iostream>
#include <Windows.h>

#ifdef _WIN32
typedef std::wstring unicodestring;
#define UNI(text) L ## text
std::string formatForConsole(const unicodestring &str)
{
    std::string result;
    //Call WideCharToMultiByte to do the conversion
    return result;
}
#else
typedef std::string unicodestring;
#define UNI(text) text
std::string formatForConsole(const unicodestring &str)
{
    return str;
}
#endif

int main()
{

    unicodestring fileName(UNI("fileName"));
    std::ofstream fout;
    fout.open(fileName);
    std::cout << formatForConsole(fileName) << std::endl;
    return 0;
}

akan baik-baik saja di kedua platform saya pikir.

Jawaban

Jadi Untuk menjawab pertanyaan Anda

1) Jika Anda memprogram untuk Windows, maka setiap saat, jika lintas platform maka mungkin sepanjang waktu, kecuali jika Anda ingin menangani kemungkinan masalah korupsi pada Windows atau menulis beberapa kode dengan platform khusus #ifdefsuntuk mengatasi perbedaan, jika hanya menggunakan Linux tidak pernah.

2) Ya. Selain itu di Linux Anda dapat menggunakannya untuk semua Unicode juga. Pada Windows Anda hanya dapat menggunakannya untuk semua unicode jika Anda memilih untuk secara manual menyandi menggunakan UTF-8. Tetapi Windows API dan standar C ++ kelas akan mengharapkan std::stringuntuk dikodekan menggunakan codepage lokal. Ini termasuk semua ASCII plus 128 karakter lain yang berubah tergantung pada codepage yang diatur oleh komputer Anda untuk digunakan.

3) Saya percaya begitu, tetapi jika tidak maka itu hanya typedef sederhana dari 'std :: basic_string' menggunakan wchar_tbukanchar

4) Karakter lebar adalah tipe karakter yang lebih besar dari chartipe standar 1 byte . Di Windows 2 byte, di Linux 4 byte.

1) Seperti yang disebutkan oleh Greg, wstring sangat membantu untuk internasionalisasi, saat itulah Anda akan merilis produk Anda dalam bahasa selain bahasa Inggris

4) Periksa ini untuk karakter lebar http://en.wikipedia.org/wiki/Wide_character

Kapan sebaiknya Anda TIDAK menggunakan karakter lebar?

Ketika Anda sedang menulis kode sebelum tahun 1990.

Jelas, saya sedang jungkir balik, tapi sungguh, ini abad ke-21 sekarang. 127 karakter sudah lama tidak lagi mencukupi. Ya, Anda bisa menggunakan UTF8, tapi mengapa repot dengan sakit kepala?