color: #ff0000">前言

在進行 i18n 相關的開發時，經常遇到字符編碼轉換的錯誤。這時如果能把相關字符串用十六進制的形式打印出來，例如，"abc" 輸出成 "//x61//x62//x63" 這對于 i18n 的除錯來說是很有幫助的。Python 里面，只需要使用 repr() 函數就行了?？稍?C++ 中如何做到這點呢？

下面是用 ostream 的格式化功能的一個簡單的實現：

std::string get_raw_string(std::string const& s){ std::ostringstream out; out << '/"'; out << std::hex; for (std::string::const_iterator it = s.begin(); it != s.end(); ++it) { out << "//x" << *it; } out << '/"'; return out.str();}

看上去簡單直接，但很可惜這段代碼不能實現我們的意圖。它還是按字面輸出了每個字符?？晌覀兠髅髦付耸褂?std::hex 來格式化輸出?。?？問題原來是出在 std::hex 只是一個針對整數類型的輸出格式設置，當輸出字符類型時，C++ 流還是按照字面輸出。到 ostream 的文檔去細查才知，原來 C++ 標準輸出流對于格式化輸出的控制很弱，只能提供有限的幾種格式定制，而且大部分都是針對整數和浮點數類型的，對于字符類型完全沒有參數可以控制。有點諷刺的是， ostream 利用了 C++ 的函數重載和強類型機制做到了在表達力不輸于 C 的同時，又杜絕了臭名昭著的 printf 帶來的無窮的麻煩，大大增加了安全。可在這里，強類型安全反而是我們達到目的的障礙：我就是想讓 ostream 把字符當成整數打印?。∵€好，C++ 還有類型強轉這招可以讓我們繞過強類型匹配這道安全閘門：

out << std::hex << "//x" << static_cast<int>(*it);

好了，這下字符都按整數來輸出了，而 std::hex 又指示 ostream 用十六進制表示去輸出整數。問題解決了。且慢，為什么輸出 UTF-8 中文編碼的時候會變成這樣：

"/xffffffe4/xffffffb8/xffffffad" // get_raw_string("中")

這么多的 F word 太影響市容了。能不能把它們去掉？其實原因在于，我們輸出的是強制類型轉換成 int 的整形數值，而 int 是 32 bit 長，所以會多出前面這么多位來。如果要去掉，只要轉成 8 bit 的整數不就行了嗎?？上?C/C++ 中沒有 8 bit 的整數，你唯一能做到的是

typedef char int8_t;

可是用這樣得來的 int8_t 去轉也還是不行，因為在 C++ 中，typedef 并沒有產生一個新的類型，而只是定義了一個原來類型的別名。而這個別名是不參與到函數重載的匹配計算當中的。換言之，ostream 說了，別以為你披上件 int8_t 的馬甲我就不認識你了，我還是把你當 char 來輸出。此路不通！

那我們就放棄利用 ostream 了嗎？且慢，其實 ostream 默認是不會輸出前面的 0 的，那只要把最后 8 bit 之前的位都抹成 0 不就能達到我們的要求了嗎。

好了，下面就是無錯最終版：

std::string get_raw_string(std::string const& s){ std::ostringstream out; out << '/"'; out << std::hex; for (std::string::const_iterator it = s.begin(); it != s.end(); ++it) { // AND 0xFF will remove the leading "ff" in the output, // So that we could get "/xab" instead of "/xffab" out << "//x" << (static_cast<short>(*it) & 0xff); } out << '/"'; return out.str();}

經歷了幾番波折，終于成功利用了 ostream 提供的十六進制輸出的功能實現了打印字符串十六進制的功能。其實細究起來，之所以那么繞，還是因為 ostream 本身在格式化輸出控制方面太弱了。進一步的，C++ 里還有更好的工具做這件事嗎？ boost::format 看起來象是，但它依然不能正確處理我們上面遇到的兩難境地。好在，另一個 boost 庫給出了合適的答案: boost::spirit::karma

Karma 是 boost::spirit 庫的一部分。大家可能比較熟悉的是用 spirit 庫做 parser 來解析字符串。而 spirit 通過 Karma 提供的功能就恰好相反，它是專門用來將 C++ 數據結構格式化為字符流的。

我們恰好就需要它，下面就是用 karma 庫重寫的代碼：

template <typename OutputIterator>bool generate_raw(OutputIterator sink, std::string s){ using boost::spirit::karma::hex; using boost::spirit::karma::generate; return generate(sink, '/"' << *("//x" << hex) << '/"', s);}std::string get_raw_string_k(std::string const& s){ std::string result; if (!generate_raw(std::back_inserter(result), s)) { throw std::runtime_error("parse error"); } return result;}

這里面最主要就是利用了 karma 內置的一個輸出模塊 karam::hex 來幫我們完成工作，而這個 hex 是一個多態的生成器。它不象 ostream 的類型重載，只能針對某些類型輸出 hex 格式，而是針對所有類型都能輸出 hex 格式，包括 char 。還有一個優點，代碼的表達力更強了，輸出的格式完全在一行代碼中體現：

// 輸出格式為 "/x61/x62/x63"，方便直接貼到 python 或 C++ 的代碼中'/"' << *("//x" << hex) << '/"'

如果想要改變輸出格式，只需要改這行代碼即可，例如：

// 輸出格式變為 "0x61 0x62 0x63 "'/"' << *("0x" << hex << " ") << '/"'

那么效率方面有沒有任何性能損失呢？下面是一段測試代碼，分別用兩種算法轉換相同的字符串:

#include "boost/test/unit_test.hpp"#include "boost/../libs/spirit/optimization/measure.hpp"#include "string.hpp" // The function for teststatic std::string const message = "hex output performance test data 中文";struct using_karma : test::base{ void benchmark() { this->val += get_raw_string_c(message).size(); }};struct using_ostream : test::base{ void benchmark() { this->val += get_raw_string(message).size(); }};BOOST_AUTO_TEST_CASE(TestStringPerformance){ BOOST_SPIRIT_TEST_BENCHMARK( 100, (using_karma) (using_ostream) ); BOOST_CHECK_NE(0, live_code);}

下面是運行的結果，分別是兩種算法需要的時間，值越小越好：

可能出乎意料，大致來說 karma 比 ostream 快了一倍。這也與 spirit 官方給出的性能數據差不多。這里的函數返回值是通過 std::string 值拷貝返回的，消耗了不少時間，如果純從格式化輸出來說，猜測 karma 的性能優勢只會更大。另一份測試 表明，karma 應該是 C/C++ 里面你能找到的速度最快的格式化字符流方案了。

對于這么簡單的功能來說，這篇文章已經顯得太長了，慶幸的是，我們最終還是找到了一個表達力強，性能高的十六進制輸出方案。人說好事難雙，可 C++ 這門復雜的語言，卻經常能找執行飛快又高度抽象的代碼方案。只是有些過于復雜了 ...

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作能帶來一定的幫助，如果有疑問大家可以留言交流。