昨天一个TX的手机索爱W910坏了，找手机维修店换排线未果之后找我刷机。
稍微花了一点时间到网上搜集了一些关于W910/W910i的刷机资源和资料，有不少论坛有足够多的资源，但是都是需要这个积分那个积分的，真的很烦人。其实很简单的一件事却要花费他人大量的时间去回帖发帖来完成所谓的提升浏览权限。
简单的刷机流程如下（用到的刷机驱动、刷机工具、港版刷机包、大陆刷机包以及闭合文件可以留言我发给你）：
在Twitter上看到第八季是《24》的最后一季了 蛮喜欢这部剧集的
不少网站页面习惯于在URL中的目录名后不加斜杠“/”，这在在apache下会自动添加一个斜杠从而不会造成什么问题，但是如果URL中的二级目录名后不加斜杠的话在Nginx下就会出现403 Forbidden的问题。在网上找到的比较可靠的原因供以想深究的TX进行参考：
在某些情况下（具体可参考 wiki.nginx.org），Nginx 内部重定向规则会被启动，例如，当 URL 指向一个目录并且在最后没有包含“/”时，Nginx 内部会自动的做一个 301 重定向，这时会有两种情况：
1、 server_name_in_redirect on（默认），URL 重定向为： server_name 中的第一个域名 + 目录名 + /；
2、 server_name_in_redirect off，URL 重定向为： 原 URL 中的域名 + 目录名 + /。
当你有多个 域名要指向同一个虚拟主机，并且你自己写 301 重定向规则把它们合并到某一个域名时，情况就更复杂了：
首先，nginx 检查 URL，如果符合条件，就用该规则（你写的）做第一遍重定向，接着，检查新生成的 URL，如果符合内部自动重定向之条件，就用前面提到的规则再做一次重定向。
至于 PHP 的 $_SERVER["SERVER_NAME"]，在 nginx 中默认是由 nginx 的变量 $server_name 提供，这时它和重定向没有关系，始终是 server_name 设置中的第一个域名，但这是可以被改变的，在你的 nginx 配置中找到 fastcgi_param 部分，修改
fastcgi_param SERVER_NAME $server_name;
为
fastcgi_param SERVER_NAME $host;
但 现在就要注意了，此时的 $_SERVER["SERVER_NAME"] 会受你写的和 nginx 自己的重定向规则所影响而变化。
现 在就清楚了，如果 MediaWiki 是通过 $_SERVER["SERVER_NAME"] 来自己处理 URL 的话，那么在 nginx + php 的默认环境下，它获得的将始终是 server_name 设置中的第一个域名，所以造成了“不管通过什么域名访问 MediaWiki 首页，都会被跳转到其中的一个域名上。”，这不是 nginx 的重定向造成的，虽然默认 server_name_in_redirect 是 on，但这个指令的影响范围仅仅只是 nginx 自己内部的重定向规则。
有不少TX可能因为一些原因（比如说天朝的cn域名不停政策变化等）从cn域名转换到了其他域名，但是原来使用的cn域名可能已经积攒了大量的搜索引擎亲和因子,在各大搜索引擎被收录了上万的页面，冒然的直接启用新域名会显得得不偿失。所以这个时候通过一些方法最大可能地保存原来已经有的一些网页资源是势在必行的事情。
对于Google来说可以通过Google提供的网站管理员工具来加快域名转移的速度和效果，关于Google网站管理员工具的操作这里就不赘述了，相关的介绍非常详细。
在执行完前期的网站程序和数据转移之后就需要对原网站进行301的永久重定向，在Apache 下可以通过.htaccess配置RewriteRule，Nginx则在配置文件中加上跟下面类似的一段配置就行：
- server {
- listen 80;
- server_name holmesian.cn www.holmesian.cn;
- if ($http_host !~ ~S^holmesian\.org$~T) {
- rewrite ^(.*) http://holmesian.org$1 permanent;
- }
- }
这里值得一提的是Nginx的 Rewrite Flags：
redirect – 返回临时重定向的HTTP状态302
permanent – 返回永久重定向的HTTP状态301
测试一下，现在从搜索引擎来的holmesian.cn和www.holmesian.cn都被直接转成holmesian.org，用户几乎没有任何察觉。接下来等待搜索引擎响应了……估计这个会有一个周期。
DeDe CMS是一个由PHP编写功能强大的开源CMS系统，经过了长时间不断磨合，现在已经是一款比较完善开源CMS系统。
最新版的DeDeCMS提供对每篇文章的关键字自动提取功能，但是经过实际使用之后发现UFT-8版的关键字自动提取功能实在是不敢恭维，所以想到用tag替换关键的办法。
具体操作方法：修改相应文章模板文件，找到
- <meta name="keywords" content="{dede:field.keywords/}" />
改成
- <meta name="keywords" content="{dede:tag row='6'}[field:tag /],{/dede:tag}">
上传修改的文件后重新生成页面即可
下载文件这几天360和瑞星之间发生的那些事值得关注一下 事情的大概经过我稍微整理一下放在下面 具体细节请Google之……
1月29日 波兰一家安全组织ntinternals 近日公布：瑞星杀毒软件长期存在两个“本地提权”0day安全漏洞，使木马病毒能轻易获得瑞星用户的系统控制权。国内 安全厂商金山和 360的技术专家均已确认了这两个漏洞的存在，一旦受到黑客攻击，数千万瑞星用户将丧失对木马病毒的防御能力，并将导致国内大批政府与企业内网的信息安全 面临严重威胁。
2月2日 瑞星已经在其官网发布360的漏洞细节及攻击代码，尚未确认其信息及攻击代码的真实性和有效性。理论上ntinternals应该不会把漏洞细节告 知非360人士，我很好奇瑞星是如何得知相关细节及攻击代码的。如果是假的，那就是一个小忽悠，如果是真的，那么这里面故事应该就多了去了。
2月2日 17:19 360公开致谢NT Internals ，并表示已于第一时间修复漏洞
2月2日 据 瑞星安全专家分析，目前360安全卫士最新版本(6.1.5.1009)此漏洞仍然存 在，并未修复。
利 用工具：http://www.friddy.cn/article.asp?id=118
2月2日 360安全中心发表严正声明，瑞星向媒体和用户通发新闻，造谣说360软件有“后门”，恶意诋毁中伤360品牌。免费的360杀毒自去年 10月20日推出以来，市场份额快速上升，短短几个月超越瑞星，成为市场第一，从而招致瑞星打击报复。对瑞星这种公然造谣的行径，360将坚决提起诉讼。
接下来会是什么情况呢？……
瑞 星不会这么简单的完结的，因为已经有用户因为360的漏洞被提权了，而且实际上漏洞的下发有一个时间差，很可能是真的还没补，这些都会被瑞星用作口实， 我觉得一定还有续集。当然，瑞星已经处于下风了，继续看戏，不过不管怎么说，作为安全软件商难免说360和瑞星的激战，也能最终对用户负责起来。
以 前Discuz和PHPWind打来打去的时候，逼得急了，双方的补丁推送机制和效率都大大提高了。连后台拿shell都越来越难了。
