CTF记录里的phrackCTF段子，你知道多少？

在程序员网站上经常看到一个段子（满满的都是泪啊）

紧紧握着两把锟斤拷，嘴巴里急切地呼喊着烫烫烫，稳稳地脚踏着千朵屯屯屯，满脸笑意地看着万物锘锘锘 。

解释一下为什么会是这两个东西不是别的= =：

棍斤拷乱码：

问题出在源于GBK字符集，有着和字符集之间的转换情况。在与老编码体系的转化进程里，必然存在一些字，该用是没办法进行表示的，官方运用了一个占位符去表示这些文字，而这个占位符便是：U+FFFD 。如此一来，U+FFFD的UTF-8编码呈现出来，恰巧就是 '\xef\xbf\xbd'。倘若这个'\xef\xbf\xbd'，进行多次重复，比如说 '\xef\xbf\xbd\xef\xbf\xbd'，接着将其置于GBK／CP936／／的环境里予以显示，鉴于一个汉字是两个字节这样的情况，最终所呈现的结果便是：锟斤拷——锟（），斤（），拷（）。

烫烫烫乱码：

在平台之下，ms的编译器，也就是所谓vc所带的那个编译器，于Debug模式之时，会将未被初始化的栈内存，全部填充成为0xcc，要是用字符串来进行查看的话，呈现出来的便是"烫烫烫烫烫烫烫" 的字样，而未初始化的堆内存，则会全部填成0xcd，从字符串方面看去，就是“屯屯屯屯屯屯屯屯” 的样子。这意味着当出现了烫烫烫这种情况的时候，就需要赶快去检查初始化的相关情况了。。。

锘锘锘原理

Byte Order Mark的缩写是BOM，它是UTF编码方案里用于标识编码的标准标记，在UTF-16里，它本来是FF FE，变成UTF-8后就成了EF BB BF，这个标记是可选的，因为UTF8字节没有顺序，所以它可被用来检测一个字节流是否对该字节流进行了UTF-8编码。

锘EFBB

匡BFEF

豢BBBF

烫烫烫屯屯屯

处于Debug模式当中时，要是声明了一个变量，然而却没有进行初始化设置，微软会将未初始化的内存复制成0xCC。给未初始化的内存赋予0xCC是存在缘由的，因为0xCC实际上乃是INT3中断指令，所以要是在Debug模式下尝试去执行这块未初始化的内存，那么就会导致程序中断。

但是，VS之中调试器设定的默认字符集是MBCS，然而，在MBCS里恰好就是在中文当中所说的“烫”，因而，显示出来的结果全部都是“烫”……

要是采用分配堆的内存，会被初始化为0xCD，于MBCS字符集中呈现的就是屯……，。

涉及字符集转换这件事，在与老编码体系进行转化期间，必然存在一部分字难以用其表示出来，官方选用占位符去呈现这些文字，此即：U+FFFD 。那个U+FFFD的UTF-8编码是怎样的呢，要是重复多次就会形成：这样 。

如果是在GBK/CP936//的那种环境当中去进行显示，这里说都是中国标准导致出现这情况，那么一个汉字会占用2个字节，最终所呈现的结果便是：锟斤拷——锟（），斤（），拷（）……