<?xml version="1.0" encoding="gb2312"?>
<rss version="2.0">
<channel>
<title><![CDATA[挥得更高]]></title>
        <image>
        <title>http://hi.baidu.com</title>
        <link>http://hi.baidu.com</link>
        <url>http://img.baidu.com/img/logo-hi.gif</url>
        </image>
<description><![CDATA[在com的世界，deng到顶峰，让你我的双臂挥得更高。]]></description>
<link>http://hi.baidu.com/comdeng</link>
<language>zh-cn</language>
<generator>www.baidu.com</generator>
<ttl>5</ttl>


<item>
        <title><![CDATA[不可忽略的缓存header]]></title>
        <link><![CDATA[http://hi.baidu.com/comdeng/blog/item/4eb07a27bac9760b918f9da2.html]]></link>
        <description><![CDATA[
		
		在一些局域网环境中，如果是用的代理上网，对于一些需要用户权限认证的页面，没有配置相应的缓存控制header，就有可能因为缓存的问题而产生莫名其妙的串门事件。<br>
<br>
比如：a用户和b用户都注册了同一个网站的会员，a用户登录某个页面page.html后，b用户也接着登陆同一个页面，这个时候，代理没有从 page.html的response header里边找到缓存控制项，就会认为可以直接从缓存里边读取这个页面。这样的话，b用户就看到了a用户登录过的page.html，而这个页面的用 户信息都是与a用户有关的，他就会非常奇怪，这是谁呀？我到哪去了？<br>
 <a href="http://hi.baidu.com/comdeng/blog/item/4eb07a27bac9760b918f9da2.html">阅读全文</a>
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/comdeng/blog/category/%C8%D5%BB%FD%D4%C2%C0%DB">日积月累</a>&nbsp;<a href="http://hi.baidu.com/comdeng/blog/item/4eb07a27bac9760b918f9da2.html#comment">查看评论</a>]]></description>
        <pubDate>2009-04-23  10:12</pubDate>
        <category><![CDATA[日积月累]]></category>
        <author><![CDATA[comdeng]]></author>
		<guid>http://hi.baidu.com/comdeng/blog/item/4eb07a27bac9760b918f9da2.html</guid>
</item>

<item>
        <title><![CDATA[nginx配置文件的bug？]]></title>
        <link><![CDATA[http://hi.baidu.com/comdeng/blog/item/7da25390459f0c85a877a42d.html]]></link>
        <description><![CDATA[
		
		有一些动态图片虽然是用php脚本生成的，但是希望可以在客户端缓存，因此在nginx的配置文件里边增加了一个if语句来控制缓存有关的header。<br>
<br>
# 动态图片部分需要使用缓存<br>
location ~ .*\.php$ {<br>
&nbsp;&nbsp;&nbsp;   if ($request_uri !~ ^/dynamicimg/) {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;   add_header&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;   Cache-Control &quot;no-cache, no-store, max-age=0, must-revalidate&quot;;<br>
&nbsp;&nbsp;&nbsp;&nbsp; <a href="http://hi.baidu.com/comdeng/blog/item/7da25390459f0c85a877a42d.html">阅读全文</a>
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/comdeng/blog/category/%BC%BC%CA%F5%D7%B7%B7%E5">技术追峰</a>&nbsp;<a href="http://hi.baidu.com/comdeng/blog/item/7da25390459f0c85a877a42d.html#comment">查看评论</a>]]></description>
        <pubDate>2009-04-22  16:24</pubDate>
        <category><![CDATA[技术追峰]]></category>
        <author><![CDATA[comdeng]]></author>
		<guid>http://hi.baidu.com/comdeng/blog/item/7da25390459f0c85a877a42d.html</guid>
</item>

<item>
        <title><![CDATA[用php替换禁止外链图片地址时使用preg_match的限制]]></title>
        <link><![CDATA[http://hi.baidu.com/comdeng/blog/item/ce727bd9da307c2410df9beb.html]]></link>
        <description><![CDATA[
		
		对于聚合类网站来说，在显示内容中图片的时候，需要解决一个问题：有的网站对图片采取了防盗链的措施，只有当请求头的referer来自指定的host时才会正确显示图片，比如，百度空间的，163空间的。那么，理所当然的，在显示来自这些网站的内容时，需要对图片标签进行一些预处理，使得相应的图片能正确显示出来。<br>
<br>
一般的处理方式，都是利用正则表达式来找到img标签，并对src中的url进行检测，如果是来自这些禁止外链的网站过来的图片，则对src进行一些替换，使得其能正确的显示。比如一个src=&quot;http://hi.baidu.com/aaa.jpg <a href="http://hi.baidu.com/comdeng/blog/item/ce727bd9da307c2410df9beb.html">阅读全文</a>
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/comdeng/blog/category/%BC%BC%CA%F5%D7%B7%B7%E5">技术追峰</a>&nbsp;<a href="http://hi.baidu.com/comdeng/blog/item/ce727bd9da307c2410df9beb.html#comment">查看评论</a>]]></description>
        <pubDate>2009-03-18  13:47</pubDate>
        <category><![CDATA[技术追峰]]></category>
        <author><![CDATA[comdeng]]></author>
		<guid>http://hi.baidu.com/comdeng/blog/item/ce727bd9da307c2410df9beb.html</guid>
</item>

<item>
        <title><![CDATA[img标签src=&#34;&#34;带来的性能问题]]></title>
        <link><![CDATA[http://hi.baidu.com/comdeng/blog/item/4196fcdd579696e777c63857.html]]></link>
        <description><![CDATA[
		
		有一个页面是这样一种情况，当整个页面加载完了，然后会发出一次异步请求，完成列表数据的载入和显示。不过这几天，明显感觉到列表加载的速度太慢了，老是在页面显示完整了以后好几秒才开始进行异步的请求。通过用firebug分析，发现在页面加载完毕后，在异步请求发出之前，竟然又重复发出了三个对当前页面的请求。也就是说，在列表加载之前，竟然重复加载了当前页面三次。那么，这三次额外的请求是从哪来的呢？<br>
<br>
我把页面代码从最后一部分开始逐步网上删除，看看那三次请求是否依然存在。经过若干次的尝试，最后将问题定位了有 <a href="http://hi.baidu.com/comdeng/blog/item/4196fcdd579696e777c63857.html">阅读全文</a>
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/comdeng/blog/category/%C8%D5%BB%FD%D4%C2%C0%DB">日积月累</a>&nbsp;<a href="http://hi.baidu.com/comdeng/blog/item/4196fcdd579696e777c63857.html#comment">查看评论</a>]]></description>
        <pubDate>2009-03-02  13:22</pubDate>
        <category><![CDATA[日积月累]]></category>
        <author><![CDATA[comdeng]]></author>
		<guid>http://hi.baidu.com/comdeng/blog/item/4196fcdd579696e777c63857.html</guid>
</item>

<item>
        <title><![CDATA[用picasa提供的api实现图片数据备份的方案]]></title>
        <link><![CDATA[http://hi.baidu.com/comdeng/blog/item/ec9b063088d55f9ea8018ef9.html]]></link>
        <description><![CDATA[
		
		单硬盘的服务器总是要面临数据备份的问题，前文讨论过单硬盘服务器上《<a href="../../comdeng/blog/item/8f95b5afff9c70cb7cd92a89.html">中小规模mysql数据库备份的gmail解决方案</a>》，这里来讨论图片数据的备份问题。同样，在&ldquo;云计算&rdquo;时代，我们依然可以用google提供的服务&mdash;&mdash;<a href="http://picasaweb.google.com" target="_blank">picasa</a>来解决这个问题。<br>
<br>
<strong>一、flick、yupoo、picasa服务的对比</strong><br>
<br>
不过，之前还是来讨论一下为什么要采用picasa提供的服务，而不是选 <a href="http://hi.baidu.com/comdeng/blog/item/ec9b063088d55f9ea8018ef9.html">阅读全文</a>
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/comdeng/blog/category/%BC%BC%CA%F5%D7%B7%B7%E5">技术追峰</a>&nbsp;<a href="http://hi.baidu.com/comdeng/blog/item/ec9b063088d55f9ea8018ef9.html#comment">查看评论</a>]]></description>
        <pubDate>2009-02-17  01:18</pubDate>
        <category><![CDATA[技术追峰]]></category>
        <author><![CDATA[comdeng]]></author>
		<guid>http://hi.baidu.com/comdeng/blog/item/ec9b063088d55f9ea8018ef9.html</guid>
</item>

<item>
        <title><![CDATA[中小规模mysql数据库备份的gmail解决方案]]></title>
        <link><![CDATA[http://hi.baidu.com/comdeng/blog/item/8f95b5afff9c70cb7cd92a89.html]]></link>
        <description><![CDATA[
		
		假设有一台linux服务器，只有一块硬盘，跑着几个中小规模的mysql数据库，你会考虑怎么来实现数据库的备份呢？在本机备份吗？当然。但是，这样总归是稳定的，因为操作系统总有那么些几率出现崩溃，硬盘也不总是很稳定地工作，也许有一天一些意外就会让它&ldquo;猝死&rdquo;。因此，找一处别的地方来备份数据库中的数据总是有必要的。如果你对google够信任，那么完全可以用它来解决这个问题。<br>
<br>
基本的原理如下：<br>
<br>
1、用mysqldump把相应数据库的数据导入到一个文件，如果文件够小，可以直接以邮件正文的形式发送给gmail。 <a href="http://hi.baidu.com/comdeng/blog/item/8f95b5afff9c70cb7cd92a89.html">阅读全文</a>
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/comdeng/blog/category/%BC%BC%CA%F5%D7%B7%B7%E5">技术追峰</a>&nbsp;<a href="http://hi.baidu.com/comdeng/blog/item/8f95b5afff9c70cb7cd92a89.html#comment">查看评论</a>]]></description>
        <pubDate>2009-02-08  02:50</pubDate>
        <category><![CDATA[技术追峰]]></category>
        <author><![CDATA[comdeng]]></author>
		<guid>http://hi.baidu.com/comdeng/blog/item/8f95b5afff9c70cb7cd92a89.html</guid>
</item>

<item>
        <title><![CDATA[用ImageMagick的mogrify函数压缩图片大小]]></title>
        <link><![CDATA[http://hi.baidu.com/comdeng/blog/item/0c5fdacee89e310493457e6a.html]]></link>
        <description><![CDATA[
		
		这里所说的大小是指图片的容量，而不是图片的尺寸。<br>
<br>
用photoshop和fireworks保存同样一张尺寸的jpg图片，会发现其大小竟然有很大的区别。比如，一张72x72的图片，photoshop一般会有15k左右的大小，而fireworks则可能只有1、2k。造成这样的原因是，photoshop会保存图片的大部分exif信息，另外，还会包含缩略图的相关信息。而fireworks则会将这些额外的信息都去掉。<br>
<br>
而一般web开发用的图片对于这些额外的exif之类的信息是不需要的，用photoshop保存一些不需要exif信息的图片时，最好选择&ldquo;存储为web所用格式 <a href="http://hi.baidu.com/comdeng/blog/item/0c5fdacee89e310493457e6a.html">阅读全文</a>
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/comdeng/blog/category/%C8%D5%BB%FD%D4%C2%C0%DB">日积月累</a>&nbsp;<a href="http://hi.baidu.com/comdeng/blog/item/0c5fdacee89e310493457e6a.html#comment">查看评论</a>]]></description>
        <pubDate>2009-02-05  16:55</pubDate>
        <category><![CDATA[日积月累]]></category>
        <author><![CDATA[comdeng]]></author>
		<guid>http://hi.baidu.com/comdeng/blog/item/0c5fdacee89e310493457e6a.html</guid>
</item>

<item>
        <title><![CDATA[磁盘空间用完导致unterminated string literal问题]]></title>
        <link><![CDATA[http://hi.baidu.com/comdeng/blog/item/7d9b8250ba3d6865843524cf.html]]></link>
        <description><![CDATA[
		
		今天发现有一台服务器上的网站在用ajax调用文章列表完毕后不能显示出来，而且firebug报错：unterminated string literal，报错的位置是javascript用eval方法对XMLHTTP对象返回的responseText内容进行处理的地方。仔细用firebug查看返回的数据，发现内容都是不完整的，只返回了一部分文章数据，后面的数据都丢失了，这样的数据用eval去解释当然会报错的。而另一台服务器同样的地方则工作正常。看来问题在于服务器本身，而不是程序方面。<br>
<br>
用df -lh命令查看了一下，发现放web服务器的磁盘使用率已经达到100%了，删除了一部分日志 <a href="http://hi.baidu.com/comdeng/blog/item/7d9b8250ba3d6865843524cf.html">阅读全文</a>
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/comdeng/blog/category/%C8%D5%BB%FD%D4%C2%C0%DB">日积月累</a>&nbsp;<a href="http://hi.baidu.com/comdeng/blog/item/7d9b8250ba3d6865843524cf.html#comment">查看评论</a>]]></description>
        <pubDate>2009-01-28  22:58</pubDate>
        <category><![CDATA[日积月累]]></category>
        <author><![CDATA[comdeng]]></author>
		<guid>http://hi.baidu.com/comdeng/blog/item/7d9b8250ba3d6865843524cf.html</guid>
</item>

<item>
        <title><![CDATA[右栏固定，左栏自适应宽度且先出现的一种实现方案]]></title>
        <link><![CDATA[http://hi.baidu.com/comdeng/blog/item/3959b651e27e19888d54302f.html]]></link>
        <description><![CDATA[
		
		以前实现某个网站的界面时候，需要实现这样一种界面布局：右栏固定，左栏自适应宽度。这貌似是一个简单的命题，但却内含玄机：<br>
<br>
首先，因为界面显示速度的需要和seo的优化，不会用table去实现。<br>
<br>
其次，要实现右栏固定，左栏自适应宽度的需求其实还不是难事，但是却隐含另一个难以解决的命题。<br>
<br>
可将右栏的position设为absolute，并且设置其right和top值，就可以将其固定在右边同一个地方，而左栏则可以设置其margin-right为适当的数据，就可以使其宽度总是距离右边一定的距离，使右栏显示出来的同时，也满足了 <a href="http://hi.baidu.com/comdeng/blog/item/3959b651e27e19888d54302f.html">阅读全文</a>
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/comdeng/blog/category/%BC%BC%CA%F5%D7%B7%B7%E5">技术追峰</a>&nbsp;<a href="http://hi.baidu.com/comdeng/blog/item/3959b651e27e19888d54302f.html#comment">查看评论</a>]]></description>
        <pubDate>2009-01-19  22:07</pubDate>
        <category><![CDATA[技术追峰]]></category>
        <author><![CDATA[comdeng]]></author>
		<guid>http://hi.baidu.com/comdeng/blog/item/3959b651e27e19888d54302f.html</guid>
</item>

<item>
        <title><![CDATA[用iframe进行表单提交时的若干问题总结]]></title>
        <link><![CDATA[http://hi.baidu.com/comdeng/blog/item/34bc23291e9e71f998250a72.html]]></link>
        <description><![CDATA[
		
		这篇文章主要用来探讨在使用iframe进行表单提交时一系列浏览器兼容性以及iframe本身的一些限制。<br>
<br>
iframe的主要用途一般是运用在无刷新提交数据并做出响应的场景，可以作为ajax方式的有力补充。相对于使用ajax提交数据有一些独特的优势：<br>
1、对浏览器是否支持javascript没有要求，因而有更好的浏览型兼容性。<br>
2、表单提交时和普通的页面提交没有差别，不用通过脚本来包装提交的数据。<br>
3、能很方便地处理enctype=&quot;multipart/form-data&quot;的提交表单，而这是通过ajax所不能做到的。因此在像上传图像而要不刷 <a href="http://hi.baidu.com/comdeng/blog/item/34bc23291e9e71f998250a72.html">阅读全文</a>
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/comdeng/blog/category/%C8%D5%BB%FD%D4%C2%C0%DB">日积月累</a>&nbsp;<a href="http://hi.baidu.com/comdeng/blog/item/34bc23291e9e71f998250a72.html#comment">查看评论</a>]]></description>
        <pubDate>2009-01-06  00:20</pubDate>
        <category><![CDATA[日积月累]]></category>
        <author><![CDATA[comdeng]]></author>
		<guid>http://hi.baidu.com/comdeng/blog/item/34bc23291e9e71f998250a72.html</guid>
</item>

<item>
        <title><![CDATA[zend中用使用url的动态部分作为action]]></title>
        <link><![CDATA[http://hi.baidu.com/comdeng/blog/item/10893134c78b8d3c5bb5f5d8.html]]></link>
        <description><![CDATA[
		
		使用zend框架时常见的url重写模式一般都是由两部分组成，即:controller/:action这种模式。比如说一个博客，其发表文章的地址有可能是article/write，那么最终会调用ArticleController中的writeAction来进行相关的控制。稍微复杂一点，查看一篇文章的地址有可能是article/1111，我们可以利用Controller_Router_Route_Regex写它的路由：<br>
new Zend_Controller_Router_Route_Regex(<br>
&nbsp;&nbsp;&nbsp;    'article/(\w+)',<br>
&nbsp;&nbsp;&nbsp;    array(<br>
&nbsp;&nbsp;&nbsp;    &nbsp;&nbsp;&nbsp;    'controller'=&gt;'a <a href="http://hi.baidu.com/comdeng/blog/item/10893134c78b8d3c5bb5f5d8.html">阅读全文</a>
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/comdeng/blog/category/%BC%BC%CA%F5%D7%B7%B7%E5">技术追峰</a>&nbsp;<a href="http://hi.baidu.com/comdeng/blog/item/10893134c78b8d3c5bb5f5d8.html#comment">查看评论</a>]]></description>
        <pubDate>2009-01-04  11:02</pubDate>
        <category><![CDATA[技术追峰]]></category>
        <author><![CDATA[comdeng]]></author>
		<guid>http://hi.baidu.com/comdeng/blog/item/10893134c78b8d3c5bb5f5d8.html</guid>
</item>

<item>
        <title><![CDATA[强烈欢迎2009年]]></title>
        <link><![CDATA[http://hi.baidu.com/comdeng/blog/item/e3dc872fb95caf3f1e308964.html]]></link>
        <description><![CDATA[
		
		2009年，在大家的翘首相盼下终于来到，在这个寒风凛冽的寒冬，给大家带来了些许的暖意。<br>
<br>
这是2009年了，似乎还从来都没有哪一个年份被大家所一致期盼。过去的2008年，也许被大家从2001年就开始期盼着了。期盼了7年，但等来的却不是风和日丽，而是天寒地冻的春节，5月份的地震天灾，奥运前夕的动荡。奥运完毕，人们刚松口气的时候，经济危机又悄然袭来。似乎没有哪一件事能让我们心头的负担轻松一些，因此，这个新年的到来，被大家寄予了格外多的希望。<br>
<br>
对于我个人来说，也是相当曲折的一年，有刚开始的平静，到后来的 <a href="http://hi.baidu.com/comdeng/blog/item/e3dc872fb95caf3f1e308964.html">阅读全文</a>
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/comdeng/blog/category/%C9%FA%BB%EE%D0%B4%D5%E6">生活写真</a>&nbsp;<a href="http://hi.baidu.com/comdeng/blog/item/e3dc872fb95caf3f1e308964.html#comment">查看评论</a>]]></description>
        <pubDate>2009-01-01  00:15</pubDate>
        <category><![CDATA[生活写真]]></category>
        <author><![CDATA[comdeng]]></author>
		<guid>http://hi.baidu.com/comdeng/blog/item/e3dc872fb95caf3f1e308964.html</guid>
</item>

<item>
        <title><![CDATA[常见浏览器兼容性总结]]></title>
        <link><![CDATA[http://hi.baidu.com/comdeng/blog/item/6d4f93138dba08d7f6039e2d.html]]></link>
        <description><![CDATA[
		
		这篇文章用来记录一些常见的浏览器兼容问题的处理方式。保持更新……<br>
<br>
一、文本框和图像按钮（背景为图片的按钮）的对齐问题<br>
<br>
可以设置按钮的css属性position:absolute;margin-top:1px; 在firefox和ie6中都正常了。<br>
比如：<br>
<br>
//search.html<br>
&lt;input type=&quot;text&quot; name=&quot;keyword&quot; id=&quot;keyword&quot;/&gt;&lt;input type=&quot;submit&quot; id=&quot;search_button&quot; value=&quot;&quot;/&gt;<br>
//css<br>
#keyword {<br>
&nbsp;&nbsp;&nbsp;         background:#528AD <a href="http://hi.baidu.com/comdeng/blog/item/6d4f93138dba08d7f6039e2d.html">阅读全文</a>
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/comdeng/blog/category/%C8%D5%BB%FD%D4%C2%C0%DB">日积月累</a>&nbsp;<a href="http://hi.baidu.com/comdeng/blog/item/6d4f93138dba08d7f6039e2d.html#comment">查看评论</a>]]></description>
        <pubDate>2008-12-18  10:46</pubDate>
        <category><![CDATA[日积月累]]></category>
        <author><![CDATA[comdeng]]></author>
		<guid>http://hi.baidu.com/comdeng/blog/item/6d4f93138dba08d7f6039e2d.html</guid>
</item>

<item>
        <title><![CDATA[mysql中隐藏的匿名用户危机]]></title>
        <link><![CDATA[http://hi.baidu.com/comdeng/blog/item/46a143af6d2b1efcfbed50ab.html]]></link>
        <description><![CDATA[
		
		mysql的权限分配过程中，会用到&ldquo;mysql&ldquo;数据库中的user、host和db这三个重要的权限表。通过user这个表可以知道具有mysql权限的用户到底是哪些。如果我们够仔细地话，往往能够发现user表中竟然存在有一些匿名用户。比如，在我的ubuntu上装的mysql中就有这样的用户：<br>
<br>
mysql&gt; select * from user\G;<br>
*************************** 4. row ***************************<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;   Host: localhost<br>
&nbsp; <a href="http://hi.baidu.com/comdeng/blog/item/46a143af6d2b1efcfbed50ab.html">阅读全文</a>
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/comdeng/blog/category/%BC%BC%CA%F5%D7%B7%B7%E5">技术追峰</a>&nbsp;<a href="http://hi.baidu.com/comdeng/blog/item/46a143af6d2b1efcfbed50ab.html#comment">查看评论</a>]]></description>
        <pubDate>2008-12-08  01:47</pubDate>
        <category><![CDATA[技术追峰]]></category>
        <author><![CDATA[comdeng]]></author>
		<guid>http://hi.baidu.com/comdeng/blog/item/46a143af6d2b1efcfbed50ab.html</guid>
</item>

<item>
        <title><![CDATA[ubuntu上架设svn服务器的过程]]></title>
        <link><![CDATA[http://hi.baidu.com/comdeng/blog/item/34bc23295c99b3f998250a73.html]]></link>
        <description><![CDATA[
		
		一直以来都充当使用svn的角色，这次终于下决心自己动手来架设svn服务器了。之前在windows也有操作过，不过貌似都没有成功。这次在ubuntu上架设svn服务器，也是一波三折，不过还好有惊无险地解决了一切问题，圆满成功了。<br>
<br>
主要参考的文章来自<a target="_blank" href="http://bemike.org/tag/subversion">http://bemike.org/tag/subversion</a>，不过这篇文章介绍的安装svn软件的过程太简洁了，一句&ldquo;sudo apt-get install svn&rdquo;就搞定了。而我还是决定要自己来编译，因此就遇到了很多其他的问题。<br>
<br>
 <a href="http://hi.baidu.com/comdeng/blog/item/34bc23295c99b3f998250a73.html">阅读全文</a>
		
		<br/><b>类别：</b><a href="http://hi.baidu.com/comdeng/blog/category/%C8%D5%BB%FD%D4%C2%C0%DB">日积月累</a>&nbsp;<a href="http://hi.baidu.com/comdeng/blog/item/34bc23295c99b3f998250a73.html#comment">查看评论</a>]]></description>
        <pubDate>2008-12-07  12:08</pubDate>
        <category><![CDATA[日积月累]]></category>
        <author><![CDATA[comdeng]]></author>
		<guid>http://hi.baidu.com/comdeng/blog/item/34bc23295c99b3f998250a73.html</guid>
</item>


</channel>
</rss>