前言

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

下面是用 ostream 的格式化功能的一個簡單的實現(xiàn)：

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();
}

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

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

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

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

這么多的 F word 太影響市容了。能不能把它們?nèi)サ簦科鋵嵲蛟谟?，我們輸出的是強制類型轉(zhuǎn)換成 int 的整形數(shù)值，而 int 是 32 bit 長，所以會多出前面這么多位來。如果要去掉，只要轉(zhuǎn)成 8 bit 的整數(shù)不就行了嗎。可惜 C/C++ 中沒有 8 bit 的整數(shù)，你唯一能做到的是

typedef char int8_t;

可是用這樣得來的 int8_t 去轉(zhuǎn)也還是不行，因為在 C++ 中，typedef 并沒有產(chǎn)生一個新的類型，而只是定義了一個原來類型的別名。而這個別名是不參與到函數(shù)重載的匹配計算當中的。換言之，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();
}

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

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

我們恰好就需要它，下面就是用 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 內(nèi)置的一個輸出模塊 karam::hex 來幫我們完成工作，而這個 hex 是一個多態(tài)的生成器。它不象 ostream 的類型重載，只能針對某些類型輸出 hex 格式，而是針對所有類型都能輸出 hex 格式，包括 char 。還有一個優(yōu)點，代碼的表達力更強了，輸出的格式完全在一行代碼中體現(xiàn)：

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

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

// 輸出格式變?yōu)?"0x61 0x62 0x63 "
'\"' << *("0x" << hex << " ") << '\"'

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

#include "boost/test/unit_test.hpp"
#include "boost/../libs/spirit/optimization/measure.hpp"
#include "string.hpp" // The function for test

static 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);
}

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

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

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

總結(jié)

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

最新評論