C++中输出十六进制形式的字符串
前言 在进行 i18n 相关的开发时,经常遇到字符编码转换的错误。这时如果能把相关字符串用十六进制的形式打印出来,例如,"abc" 输出成 "x61x62x63" 这对于 i18n 的除错来说是很有帮助的。Python 里面,只需要使用 下面是用 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 中文编码的时候会变成这样: "xffffffe4xffffffb8xffffffad" // 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++ 里还有更好的工具做这件事吗? Karma 是 我们恰好就需要它,下面就是用 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 内置的一个输出模块 // 输出格式为 "x61x62x63",方便直接贴到 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 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); } 下面是运行的结果,分别是两种算法需要的时间,值越小越好:
可能出乎意料,大致来说 karma 比 ostream 快了一倍。这也与 spirit 官方给出的性能数据差不多。这里的函数返回值是通过 对于这么简单的功能来说,这篇文章已经显得太长了,庆幸的是,我们最终还是找到了一个表达力强,性能高的十六进制输出方案。人说好事难双,可 C++ 这门复杂的语言,却经常能找执行飞快又高度抽象的代码方案。只是有些过于复杂了 ... 总结 以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作能带来一定的帮助,如果有疑问大家可以留言交流。 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
- 基于vSAN的超融合解决方案VxRail上运行Oracle数据库的优势
- 【推荐】手Q开源Hybrid框架VasSonic介绍,极致的页面加载速
- vb.net正则表达式快速入门(3)完
- ruby-on-rails – lib目录下的Rails.root
- ruby-on-rails – Rails Ajax Jquery Delete提交发布后的请
- 字典c#TryGetValue始终返回null
- nosql – Cassandra – 使用主键列的任意子集按主键搜索
- reactjs – 我可以用钩子替换上下文吗?
- reactjs – React dropzone,如何上传图片?
- libxml++移出对glibmm等库的依赖