前言

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

下面是用 ostream 的格式化功能的一個(gè)簡(jiǎn)單的實(shí)現(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();
}

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

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

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

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

這么多的 F word 太影響市容了。能不能把它們?nèi)サ?？其?shí)原因在于，我們輸出的是強(qiáng)制類型轉(zhuǎn)換成 int 的整形數(shù)值，而 int 是 32 bit 長(zhǎng)，所以會(huì)多出前面這么多位來(lái)。如果要去掉，只要轉(zhuǎn)成 8 bit 的整數(shù)不就行了嗎。可惜 C/C++ 中沒(méi)有 8 bit 的整數(shù)，你唯一能做到的是

typedef char int8_t;

可是用這樣得來(lái)的 int8_t 去轉(zhuǎn)也還是不行，因?yàn)樵?C++ 中，typedef 并沒(méi)有產(chǎn)生一個(gè)新的類型，而只是定義了一個(gè)原來(lái)類型的別名。而這個(gè)別名是不參與到函數(shù)重載的匹配計(jì)算當(dāng)中的。換言之，ostream 說(shuō)了，別以為你披上件 int8_t 的馬甲我就不認(rèn)識(shí)你了，我還是把你當(dāng) char 來(lái)輸出。此路不通！

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

好了，下面就是無(wú)錯(cuò)最終版：

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 提供的十六進(jìn)制輸出的功能實(shí)現(xiàn)了打印字符串十六進(jìn)制的功能。其實(shí)細(xì)究起來(lái)，之所以那么繞，還是因?yàn)?ostream 本身在格式化輸出控制方面太弱了。進(jìn)一步的，C++ 里還有更好的工具做這件事嗎？ boost::format 看起來(lái)象是，但它依然不能正確處理我們上面遇到的兩難境地。好在，另一個(gè) boost 庫(kù)給出了合適的答案: boost::spirit::karma

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

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

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

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

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

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

那么效率方面有沒(méi)有任何性能損失呢？下面是一段測(cè)試代碼，分別用兩種算法轉(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);
}

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

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

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

總結(jié)

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

最新評(píng)論