对于 Magic quotes，对于 PHPer 而言是个老生常谈的问题。今天无意间 看到篇文章 ，结合 PHP Manual 以及其回复，在这里做个简单的汇总。

简而言之，Magic quotes 开启后会自动转义输入的数据。其中，所有的单引号（'）、双引号（\"）、反斜线、和 NULL 字符都会被转义（增加个反斜线）， 其实这操作本质上调用的是 addslashes 函数 。

为什么使用 Magic quotes

方便快捷

PHP 的设计者在设计之初的构想就是能够快速方便的编程。例如插入数据库时，Magic quotes 会自动将数据转义，这很方便。

对初学者有利

Magic quotes 可以从一定程度上，让初学者带离脚本的安全风险。例如在没有任何保护措施的代码下，开启了 Magic quotes 后会少很多的风险，例如 注入问题 。当然，单一使用此方法，并不能完全阻止此类安全问题。

「我没有权限去关闭」

很显然你已经可能意识到了这个问题，但是主机空间并非完全由自己控制。

为什么不使用 Magic quotes

可移植性

无论此功能是否开启，它都会影响脚本的可移植性，因为它影响我们后续过滤数据的操作。

性能问题

在获取所有的外部数据之前都会被转义，这无疑会增加运行时的花销（而且并不是所有的数据都需要转义）。

造成困惑

正如上述所言，并非所有的数据都需要被转义。有可能出现的一种情况，就是当你为了获取未被转义的数据，而「疯狂的」使用 stripslashes 函数。

PHP6 已经不支持

PHP 的设计者显然已经意识到了自己的「错误」，所以在 PHP6 中已经将其废弃。

如何禁用 Magic quotes

按照本人观点，使用 php.ini 配置文件全局禁用 Magic quotes 是最靠谱的。参考下面的代码

; Magic quotes
;
; Magic quotes for incoming GET/POST/Cookie data.
magic_quotes_gpc = Off
; Magic quotes for runtime-generated data, e.g. data from SQL, from exec(), etc.
magic_quotes_runtime = Off
; Use Sybase-style magic quotes (escape ' with '' instead of ').
magic_quotes_sybase = Off

然而线上的主机可能无法让你修改 php.ini 文件，那么可以使用 .htaccess 文件禁用，加入下面的代码

php_flag magic_quotes_gpc Off

上述可移植的代码而言，无论是否禁用 magic_quotes，数据必须保持一致。那么下面的代码可以帮助您

周六与朋友一起，相互分享自己的新知。本人较懒，没有做过多的准备，简单的分享了下对前端这个职位的理解（ 下载 PPT ）。

其中主要讲述了前端及其职能、前端的项目开发流程等方面。这些内容 其实 圆心 已经非常详细的解说过了 ，本人也是即学即用。

前端这个职位目前在国内还是比较「新鲜」的，很多人都不了解前端具体是做什么。而可以预见的是，通过 D2 、相互分享等渠道，前端这个职位将会被越来越多的人所知。

最后，获得四个很受用的关键字

激情、执着、开放、谦逊

上述我想不仅仅是前端，也应是所有的开发人员，都值得去努力做到的。

• 原标题：The IE6 Equation
• 原作者： Jeremy Keith
• 原文连接： http://24ways.org/2008/the-ie6-equation 这个 JavaScript 天才同时开发了款名为 IE7 的脚本 。这款不可思议的脚本能够通过 JavaScript 使 Internet Explorer 5、6 的表现得像个标准兼容的浏览器。同时，这款脚本还增强了 IE 的 CSS 支持。脚本仅针对的是 Internet Explorer，因此需要使用上述的条件注释引入它

<!--[if lt IE 7]>
    <script src="http://ie7-js.googlecode.com/svn/version/2.0(beta3)/IE7.js" 
        type="text/javascript"></script>
<![endif]-->

兼容标准的浏览器并不会运行此段脚本（对于他们而言仅仅是注释而已）。如果访问者使用的是 IE6 这糟糕的浏览器，就会额外的下载这段 Javascript 脚本。

那么问题是，什么时候应该编写额外的 IE6 样式，而什么时候应该做的仅仅是引入那段 Dean Edwards 编写的脚本呢？详细的回答这个问题，可能需要花费我和我的同事 Natalie Downe 整个上午的时间。然而回答这个问题之前，您首先需要了解并回答两个问题：「在针对 IE6 上的开发时间有多少？」以及「有多少访问者正在使用的 IE6 ？」。

让我们使用 t 表示总的开发时间、t6 表示花在 IE6 上的时间；所有的访问者数目表示为 a、 a6 则表示正在使用 IE6 的访问者。本人和那伙极具数学细胞的伙伴 Cennydd Bowles 和 Natalie 定义了下面的公式，用于量化的计算有多大的权重去使用上述 Dean Edwards 的 IE7 脚本。

p = 50 [ log ( at6 / ta6 ) + 1 ]

你可以尝试计算下属于你自己的数字。比如你花了大量的时间在 IE6 上，但只有很小部分访问者使用该浏览器，那么你可能会获得个非常高的数字。这意味着你可以使用 IE7 脚本。而反过来，如果使用较少的时间处理 IE6 的问题，或者你的大部分访问者都在使用 IE6 浏览器，那么那个 p 值会很小，这时你应该另外编写针对 IE6 的样式。

当然，实际情况是使用这个方程式显得有点自欺欺人。你可以很容易获得使用 IE6 的访问者占总访问者的比例数，但然而获得精确花费在 IE6 上的开发时间却显得相当的困难 - 或许需要当你完成了总的开发计划以后，才能得出具体所占的时间，而到那时这个方程式已经显得有点「马后炮」了。

替代上述方程式的另个方案，可以尝试下限制花费在 IE6 上的开发时间。具体是首先让你的站点与标准保持兼容，然后计划针对 IE6 上的开发时限。如果不能在这个时限内解决问题，那么替代使用 Dean Edwards 的脚本。

这一具体的占用时间可考虑和访问者使用 IE6 所占的比例进行计算。比如 20% 的访问者仍然在使用 IE6，同时你使用了 5 天开发时间完成了兼容标准的站点，那么就可以限定 1 天时间集中解决 IE6 的问题；但如果有 50% 的访问者仍然在使用着 IE6，那么你可能需要准备 2.5 天时间去解决这些问题。

所有这些针对 IE6 的处理方式的讨论没有绝对唯一的答案，同时也不可能适用于每个人。如何处理 IE6 这个棘手的问题仍然是当前的焦点之一，目前互联网上不少的 Blog、文章甚至站点都在讨论什么时候应该放弃支持 IE6。但他们没有明确的定义他们所谓的 「支持」具体是何意 。当然这不是个简单的「是」或者「非」就能回答的问题。作为替代，下面有个不同层级的支持方案：

• 将所有的 IE6 访问者踢出你的站点
• 完全遵循标准开发，并且没有任何针对 IE6 的测试
• 只使用 Dean Edwards 的脚本让 IE6 支持额外的 CSS
• 编写针对 IE6 的样式解决大部分问题（比如布局等）
• 让站点在 IE6 以及其他浏览器上看起来一摸一样

上述每个条目获得的最终结果可能是非常极端的。本人不赞成开发人员积极的抵制任何一款浏览器，也同时认为使用那些过时的浏览器的访问者获得的体验，与那些使用现代的浏览器的用户获得的不可能完全一致。真正的要点在于，IE6 被我们放在「支持」与「不支持」之间的哪个平衡点之间。

正如我认为标记语言最重要的是语义，上述的观点在 Web 开发中同样的重要。我们尝试获得更好的方式，这总要比那挂在口头的冰冷动词「支持（support）」显得更为的重要。如果你向你的访问者保证你的站点「支持」 IE6，那么你得了解更深一层的含义。相反的，如果你表明将「不支持」 IE6，那么你同样需要花点时间思考为什么需要这样做。

最后，Yahoo 的 Web 开发人员提出的 浏览器分级 概念我很认同。当然有其他的想法，我同样会有兴趣去倾听。如果我们都步调一致的发出自己的心声，那么最终我们会以更好的姿态去击败共同的对手！