小熏的编程日记

tak的内嵌cue提取非常简单。内嵌的cue位于文件尾部，以utf-8编码存放。只要捕捉到起始点和结束点，拷贝出来即可。 内嵌cue的起始标记是Cuesheet，大小写不敏感，结束标记是之后遇到的第一个连续终止符串（六个终止符以上） 为了不用读取整个tak文件，将文件指针移到最后20K处，将之后的数据拷贝出来，在这20K的数据中搜索。一般的cue也不会有那么长吧 CueString中存放的即是utf-8编码的cue字符串，写入到文件即可。 这自动机模型捕捉Cuesheet写得很优美（擦汗

以前写过一篇博文介绍tinyXml输出utf-8文档。 tinyXml的特点是不对xml节点内容的具体编码处理，这一切都交给用户。因此tinyXml和字符有关的函数都是只接受char*的数据类型。 例如： 上述代码产生的节点，如果用TiXmlDocument的SaveFile函数直接保存，只能是ANSI的本地编码（无论程序是否是unicode），即使TiXmlDeclaration指定为utf-8。一种方法是输出到TiXmlPrinter，将TiXmlPrinter.CStr()转换到utf-8编码的char*后保存。 char*在双字节编码下是一种很奇特的字符串，中文平台下的VC的编译器，char*可以存放GBK汉字，编译能正确识别字符，因为ASCII码的最高位为0，而GBK双字节字符的首字节最高位为1。 在使用utf-8字符串时，必须树立一个观念：utf-8应当只在传输时使用，不适合作为函数过程的处理对象。什么是传输场合？网络传输和文件读写。以文件读写为例，文件以utf-8编码存放，在读入到内存后，应当立刻转换为unicode宽字符串。程序的内部处理过程中只有unicode宽字符串。直到写入文件时，unicode宽字符串才转换为utf-8字符串。 utf-8字符串本身是变长字符串，并没有特定的数据类型。它是以char*形式存放，它的byte的表现不符合任何双字节编码，当成双字节编码处理会立刻出错。事实上，char*只是一个存放空间，用void*、unsigned char*本质上没有区别。（倘若你喜欢，甚至可以拿char*来存放unicode宽字符串，一次memcpy两个byte就是了）。 脱离双字节编码（如GBK）的tinyXml使用方法是存在的。 例如上述代码可以改为： UTF8Str变量名即是内含的char*字符串的起始指针。CW2A函数可以自己写一个代替，并不难实现。此时可以直接调用TiXmlDocument的SaveFile函数保存为无BOM的UTF-8文档。要保存为含BOM的UTF-8文档，仍然需要TiXmlPrinter，但此时不需要对TiXmlPrinter.CStr()进行任何处理。 tinyXml在加载xml文档时有一个标记，TiXmlDocument.LoadFile(TiXmlEncoding encoding); 这个标记没多大作用，无论设为TIXML_ENCODING_UTF8还是TIXML_ENCODING_LEGACY，读入的节点的数据类型一样是char*。 设为TIXML_ENCODING_UTF8标记的唯一作用是tinyXml会自动处理文档的BOM。 对于下面文档，怎样才能正确读取到TemplateStr节点的内容？很简单，在读取时进行转换就行。 UTF8toUnicode函数： strlen取char*的长度等于字节数（不含终止符），不是utf-8字串的真正字符个数。

侧栏的标签云中的tag数量毕竟有限。于是很久前就想自制一个标签云页面。 复制所用主题下的page.php，命名tags.php； 在tags.php头部添加 将tags.php中的<?php the_content(); ?>替换为<?php wp_tag_cloud(‘smallest=12&largest=40&unit=px&number=500′);?> 保存，上传至所用主题下的目录 后台添加新页面，模板选用tags。OVER wp_tag_cloud是wp自身提供的函数，smallest是最小的字号（相关主题数最少），largest是最大的字号（相关主题数最多），unit是单位，number是显示的tag的最大数量 但对于blocks主题，还需要指定新的样式表。默认的content样式tag由于大小不一会重叠。 在style.css添加新样式 将wp_tag_cloud所在的div的class修改为tags-cloud。 余因为关闭了评论，所以同时移除了和评论相关的代码 最终的tags.php

博客的访问统计插件使用的是statpresscn，从一开始使用163的api解析ip地址，就发现写入会出错，当时不以为意，随便改为其他的api（返回的地址一般都是空串）。直到昨天小烈留言，才发现原来用户名为中文字符同样也会出错。于是决心解决它。 WordPress database error: [Incorrect string value: '\xE7\x83\x88\xE4\xB9\x8B...' for column 'user' at row 1] INSERT INTO blog_wp_statpressCN (date, time, ip, urlrequested, statuscode, ptype, pvalue, agent, referrer, search,nation,os,browser,searchengine,spider,feed,user,timestamp) VALUES (‘20100820′,’00:25:24′,’125.46.23.194′,’/index.php/gbook’,”,’page’,’103′,’Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729)’,’http://kuyur.info/blog/index.php/archives/category/ongaku’,”,”,’Windows XP’,’Firefox 3′,”,”,”,’烈之斩’,’1282263924′) 从小烈反馈以及余自测的错误来看，是UTF-8字符要写入数据库时出错。访客在留言后，cookies自动记录用户名，访客再访问页面，statpresscn这时候采集的不再是ip，而是用户名。“\xE7\x83\x88\xE4\xB9\x8B”是“烈之”的UTF-8编码。余的博客是UTF-8编码，表单提交到mysql的字符类型也是UTF-8，但博文写得好好的，没理由是服务器那边的错误。将数据库进行备份，下载回来一看，发现表blog_wp_statpress的CHARSET居然是latin1。错误正是出在这里。（建议statpresscn作者在创建数据表时按照blog设定的编码创建） 修改表的字符集、user字段的CHARACTER SET为UTF-8，用中文用户名留言后的错误消失。将解析ip的api改回163，修改nation字段的CHARACTER SET为UTF-8，博文最开始提到的错误也消失。 以防万一，将tinytext和text类型的字段都改成了UTF-8。 可以将上述sql语句保存sql文件，在mysql中用source命令执行。

先来玩个小把戏（trick） 把这个压缩包test.zip下回来，里面有两个文件，一个是test.txt，另外一个是test.txt.bak，两个文件是一样的，bak只是个备份 用记事本打开test.txt，可以看到里面的内容是这样的： 把“瓧”前面的空格删掉，注意只删一个，表删错了 按下Ctrl+s保存文本，再重新打开，发现变成这样子了 为什么会这么离奇？ 再玩多一个小把戏。打开记事本，输入下面两个字，“涓狽”，注意“狽”是繁体 保存，文件名随意。关闭程序重新打开，发现变成了这样 太离奇了，这难道是Windows的bug？其实不是。先补充一句，以上两个把戏仅在Windows简体中文系统有效。这把戏要多少有多少，繁体系统按道理也可以拼凑出来。 这种神奇现象的原因就在于Windows系统对无BOM文本的编码检测。文本文件在ASCII码时代是没有头（header）的，即使到了各多字节编码混战的时代，仍然没有头。其他文件格式，比如bmp，都是有头的，所以Linux系统不需扩展名从header就可以识别文件格式。进入了Unicode时代，文本文件终于有了BOM标记，BOM算得上是文本文件的头。众所周知，Unicode（UTF-16）以小尾（little-endian）顺序存放的BOM是0xFF、0xFE，以大尾（big-endian）顺序存放的BOM是0xFE、0xFF，这两个字节要先于文本写入。UTF-8文本不存在大小尾问题，但微软为UTF-8文本文件默认加上了0xEF、0xBB、0xBF的BOM。 倘若使用UltraEdit将UTF-8文本的BOM剔除，保存后的文件用记事本打开仍然是正常的。也就是说，Windows支持无BOM的UTF-8文本。上面的两个小把戏中的文本的离奇表现都是因为被识别为无BOM的UTF-8文本。Windows对文本编码识别的优先度是：依据BOM>依据UTF-8字符串检测算法>ANSI。 “涓狽”的GBK编码是0xE4B8 0xAA4E，保存为文件再打开时，E4B8AA是“个”的UTF-8编码，4E是“N”的ASCII码，整个字符串通过了检测函数，自然被认为是UTF-8字符串而不是GBK字符串了。 第一个小把戏中，删除空格前整个字符串没有通过检测函数，因此被当成GBK编码；删除空格后，通过了检测函数，因此被当成UTF-8编码。 那到底你想要的是GBK编码呢还是UTF-8编码呢？如果你想要GBK编码方式，“涓狽”这种情况，很遗憾，无论你怎样保存，系统还是会当成UTF-8。虽然这种概率很低，但并不是不存在。当然你将“涓狽”以UTF-8+BOM方式保存，就绝对不会出错了。 选择有BOM的UTF-8还是无BOM的UTF-8，要看场合。Windows默认有BOM，因此编写程序一定要支持BOM，检查前3个字节就行，非常简单。编写的程序保存UTF-8文本，也应当加上BOM，这不是多余，在一些情况下，UTF-8是能被当作多字节编码理解的。php的include文件，如果是UTF-8编码，不能加BOM。余的wordpress后台一直有问题，登录也不正常，原因在于修改某插件的一些代码加入中文字符后保存为UTF-8编码多了BOM。删掉php文件的BOM后就正常了。

时常看到cnBeta上有银用菊花文回复，比如这里，很是好奇。 下面是一段菊花文： 这҉是҉一҉段菊҉花҉文҉ 这是真相： 很简单， ҉ 是一个Unicode的字符，值是0×0489，大概是规定了不占据一个字符位置，与它的前一个字符重叠在一起 制作菊花文也就很简单了，在正常字符串中逐字插入这个菊花符，可以拷贝粘贴的 菊花文的一个作用是避免敏感词检查，比如cnBeta这种地雷遍布的地方和某些场合 很邪恶的一种文体

调教wordpress随机banner图片成功。 随机图片由php代码产生。策略是返回header信息将自身表现得像一个图片文件，接着是指定目录下的一随机图片的数据流。 headerimages.php，支持图片格式可参考自行添加 对于blocks主题，修改style.css中的样式即可，添加背景图片url为上面php代码保存后的php文件路径，并将高度修改为100px。（因此banner图片的像素是960×100） style.css 就这么简单。将headerimages.php上传到wp-content\themes\blocks目录下，并且新建存放banner的文件夹headerimages。 余同时也修改了blocks主题的header.php，使header右上显示页面、左下显示分类。 随机banner（含30P图片）+header.php打包：blocks-randombanner.zip，仅使用随机banner不需覆盖header.php

今晚将博客的主题风格由arjuna-x更换为blocks，虽然说不上华丽，但果然还是清淡的风格更合余心。更换后全部插件都能正常运行，不需要改动代码，但要改代码的工作还是避免不了。首先是备案号，修改footer.php。接着调整评论表情的布局，修改comments.php。接着为引用块<blockquote></blockquote>添加引号图标，并且调整左页边距，这是修改style.css。但这在arjuna-x主题里都修改过，算不上什么新花样。 于是决定弄好归档(archives)、关于(about)、链接(links)、留言本(gbook)四个页面。以前在网上看到的文章说要自己定义模板文件，一直没时间和机会。发现blocks主题里居然有archives和links的模板，页面内容的产生已经解决，大大减轻调教所耗精力。

原文地址：http://jandy.me/blog/?p=1707 通过FeedBurner把WordPress日志同步到Twitter 作者：Jandy 用Wordpress Twitter Bot这个插件进行同步时，只是把日志标题输出到Twitter上，连个原文链接都没有。后来还是用FeedBurner同步成功了，还不用装插件。步骤如下： 1、到FeedBurner烧制一个feed。 2、在feed管理页面点击“Publicize”标签。 3、在左边栏点击“Socialize”。 4、点击“Add a Twitter account”按钮添加Twitter帐号（需要翻樯）。其他设置不用动，保持默认设置即可。 5、点“Activate”按钮，再点“Save”按钮。 6、在WordPress博客后台“设置——撰写”里加上一个自动ping FeedBurner的xmlrpc地址http://ping.feedburner.com。 （备注：启用远程发布，在更新服务添加FeedBurner的ping地址） 同理，其他提供rss feed的网站也可以使用FeedBurner来发布到Twitter。 —————————— 设置完毕，测试之 bot：http://twitter.com/kuyur_bot