對於跨平台程式的開發來說，字串處理是乙個麻煩事。不但要熟悉不同os平台的字元編碼集，還要尋找統一的方式來處理字串。
1，支援unicode
要想程式支援多語言，unicode是必須的，你一定不想看到你的程式在中文windows系統上開啟乙個韓文名字的檔案時卻無法載入。unicode是乙個字符集的概念，也就是說在unicode標準中，全球所有語言的字元幾乎都定義了對應的值。於是又有了unicode集的實現問題，unicode要表示完整需要32位的數值，而常用的字元用16位的數值就能表示。於是有了utf8，utf16，utf32等字元編碼實現方法，其中utf8編碼相容ascii集，且沒有位元組序問題，使得utf8成為平台間字元交換的標準編碼（如網路傳輸）。
對於windows系統來說，核心採用了utf16實現unicode，而mac和幾乎所有linux均採用utf8。也就是說，windows常見的窄字元api底層要轉化到寬字元api呼叫。
2，char和wchar_t
c++為我們提供了兩種字元型別，但卻沒有定義兩種型別的長度，更沒有定義這兩種型別的字元代表的編碼。對於windows系統，wchar_t是16位，編碼是ucs2-be（對應utf16）；mac和linux為32位，編碼是ucs4-be（對應utf32）。
char則更加複雜。由於utf8是變長編碼（1-4個位元組表示乙個字元），可以用char來表示。windows平台則可以用char來表示native string，其編碼又與locale有關。
locale是c++提供的乙個本地化策略集，locale幫助系統按不同的標準理解作業系統中的資源，比如字串的編碼。我們還可以通過facet來為locale指定具體的策略。locale對於字串編碼的用處在於：它告訴作業系統怎麼理解char型別的字串，比如char與wchat_t之間轉換時。
3，跨平台策略
通過以上繁雜的概念，字串跨平台處理的難度可想而知。對於mac和linux系統，規則總結起來倒很簡單：utf8。mac和幾乎所有的linux系統（posix）核心編碼均為utf8，本身就是unicode，我們用char就足夠了，可以不涉及wchar_t，而且對於網路傳輸等應用來說也完全能夠勝任，utf8很完美。
對於windows，如果涉及到char（native string）和wchar_t（utf16）的轉換就很麻煩（需要根據locale支援不同的轉換方法），因此最好用wchar_t，避免native string。涉及到網路或平台字串交換，就轉換為utf8字串。考慮到和mac，linux相容，如果是網路程式（字串交換），可以考慮用utf8表示字串，涉及到作業系統api或io的地方，再轉換為wchar_t型別字串。
4，boost::filesystem
字串的跨平台很多時候是為了相容檔案系統操作，boost為我們提供了filesystem庫，使用起來非常方便。具體可以參考：boost filesystem library。根據boost官方文件的描述，boost::filesystem::path路徑對於字元編碼的規則如下：
path內部採用imbued locale對不同平台的字串路徑做解析並進行必要的編碼轉換，locale可以通過codecvt設定的facet修改；
對於mac os x，path::value_type應該是char，預設的locale採用utf8編碼（可以推廣到所有bsd系統）；
對於windows（包括mingw），path::value_type是wchar_t，預設utf16編碼。
程式中的字串編碼處理
gb2312是簡體中文系統的標準編碼 用 區 跟 位 的概念表示 稱之為區位碼 區指代大的範圍 位相當於偏移量。每個漢字佔兩個位元組 高位位元組 的範圍是0xb0 0xf7，低位位元組 的範圍是0xa1 0xfe。它的規律好像是按拼音a到z的順序排列的 啊 字是gb2312之中的第乙個漢字，它的區位...
PHP程式字串處理函式
php內建字串函式實現 字串長度 function strlen str else return count 擷取子串 function substr str,start,length null if length 0 if length 0 return substr 字串翻轉 function ...
字串處理 字串反轉
請原諒博主今天很閒，於是乎博主又開始更新微博了。這次要更新的問題是 編寫乙個函式，反轉乙個單詞的順序。例如 do or do not,there is no try.就要反轉成 try.no is there not,do or do 大家要認真看看這道題，這道題和大家想象的貌似有點不同。首先字串反...