我是觉得，当问出这个问题的时候，你内心就有答案了。
想买 rmbp 就买呗，买完就知道会不会后悔了。

不知道微博主是干了什么，是不是经常被打。
我个人比较持怀疑态度的。
因为我目前还是没收到清退通知的

http://ww2.sinaimg.cn/large/62532a0egy1ffwduklch9j205c012web.jpg
http://ww2.sinaimg.cn/large/62532a0egy1ffwdumn7e1j206z01kjr8.jpg

第一是安全。。第二是恩。。你懂得

@haohappy 要在规定之前充一次会员，持续到那天，之后会员过期了就只有 15G 了，但是冲会员就回来了。

微云表示 13T 用的美滋滋，一天 20G 我个人除了第一次上传的时候传了蛮久，之后都巨爽

看 LZ 很早之前就发过了）怪不得我觉得眼熟
技术这么好，不愁找不到实习吧。。

要求换正确的货，就好了。

@onion83 pool.ntp.org

@borischenc
@liusd
@sagaxu

其实 swift 是出现在 kotlin 之后的，咱们都用好久了，Google 才敢拿出放到台面上。

2011 年 7 月，JetBrains 推出 Kotlin 项目，这是一个面向 JVM 的新语言，它已被开发一年之久。
Swift 大约历经 4 年的开发期，2014 年 6 月发表。

kotlin 其实也不算太冷，github 有一些比较新的 Java lib，有一部分都是用 kotlin 写的。

@bianhua 不好意思，你不能正确讨论问题，导致你已经被降权了。不是 @msg7086 我还收不到提示。

@msg7086 所以这种情况已经排除掉了，要是这种可能性算上去，那任何事件都不可能 100%了。硬件还可以受到辐射导致 1+1 != 2 呢。

至于我做好什么工作，那我的确没有做功课，我全程都是一边看 银河护卫队 一边回答你的。但是到后来，中断的次数已经有点让我不开心了。
我的目的是纠正你对 prepare 错误的理解，然而你对我的一直是人身攻击。我也不好说什么了。

另外可能你的语文理解能力也有点问题。
我一直在说的是
你使用了不能 native prepare 的语句
你使用了不能 native prepare 的语句
你使用了不能 native prepare 的语句

从而导致了
pdo 回退为拼接 sql
pdo 回退为拼接 sql
pdo 回退为拼接 sql

够清楚了吧，我不很不懂为什么讨论一个技术问题，要上升到人身攻击上来。
而且我是很不懂为什么我跟你说 A，你要跟我说 B，我说你 B 说的有问题，你又跟我说 C。这样偷梁换柱完全没意思啊。
整天 judge 别人，噢你很正义，你很邪恶，没有什么意思啊。
我也没看出什么最后一根稻草，你说了半天只能佐证你之前的英语不好啊，理解错了而已。

PS: 这位层主上面的理论还是全部错误的，至少关于 MySQL native prepare 是这样。

Are PDO prepared statements sufficient to prevent SQL injection?
https://stackoverflow.com/questions/134099/are-pdo-prepared-statements-sufficient-to-prevent-sql-injection/12202218#12202218
这个帖子的层主引用的是他在

https://stackoverflow.com/questions/5741187/sql-injection-that-gets-around-mysql-real-escape-string/12118602#12118602
SQL injection that gets around mysql_real_escape_string()

的回复。

从这里可以看出，这其实是 mysql_real_escape_string 的一个 bug 吧，PDO boom 的原因，是因为他 fallback 到普通的 sql query 模式了。

我也引用一下这位 stackoverflow 答主的回答吧

Wrapping Up

If you:

Use Modern Versions of MySQL (late 5.1, all 5.5, 5.6, etc) AND PDO's DSN charset parameter (in PHP ≥ 5.3.6)
OR

Don't use a vulnerable character set for connection encoding (you only use utf8 / latin1 / ascii / etc)
OR

Enable NO_BACKSLASH_ESCAPES SQL mode
You're 100% safe.

这个 100% safe 是通常意义上的 100%，是可知论中的 100%。

至此，我再参与与 @bianhua 的任何讨论，被人身攻击我已经很不开心了，我也不能保证再继续讨论，自己是否能理性分析问题，不跑题了。

当然如果我有错误，或者各位有任何问题都可以 @我。

@bianhua
上面我说的：
>> 另外你上面：
>> 如果你非得揪着字眼，我承认我那句话不完善
>> 应该是 在 pdo 起作用的时候，fully functional 的情况下，100%
>>
>> 我能这样看么：prepare 自己没有办法保证 100%不会注入，只有正确配置好一切之后它才能提供安全保证？

你对此说：
> 错误，只要是 MySQL native prepare，就没办法注入。特殊的 0day 之类的素除外。

>>> 没有任何问题啊，prepare 就是指的 MySQL native prepared statement。但是因为你在上面一直搞混 PHP 的 emulate prepared statement 和 MySQL native prepared statement。我特意指出来，我指的是后者。

所以建议你还是多看看书。

算了，我还是顺便贴出来吧

http://ww2.sinaimg.cn/large/62532a0egy1ffs84qv94yj20hu0as47d.jpg

这是普通 sql 执行的情况，也可以说是在 PDO 失效的情况下，fallback 为 php 本地拼接的情况。

http://ww2.sinaimg.cn/large/62532a0egy1ffs85q3gujj20i70d8qdd.jpg

这是 PDO 正常工作的情况下，也就是 MySQL native prepare 工作的情况下。
首先是要分析语句逻辑（ Create prepared statement ），所有数据都以占位符表示，所以只要你的语句本身（模板）没有问题，就不可能被注入。

http://ww2.sinaimg.cn/large/62532a0egy1ffs873o3nhj20i70gngz7.jpg
这是执行语句的情况下，只传输数据，MySQL 会自动进行执行。

其实 prepared statement 是借用的 oop 的思想，可以这么概括
先创建一个语句模板，然后通过分析语句模板，创建出一个 sql 无关的 语句对象
然后调用这个 语句对象 的 execute 方法，再传入数据。因为 语句对象 已经完成分析了，是 sql 无关的，所以你传入任何数据都不会改变语义。

通过这个可以得出 MySQL native prepared statement 的工作流程

1)程序员编写语句模板
2)数据库创建语句对象
3)程序员传入数据，数据库执行 prepared statement

这里不存在什么 init bind exec 的区分。
只要创建了 语句对象， 即使用了 MySQL prepared statement，就已经完成所谓的 init 了。
这个语句逻辑是由程序员决定的，你要是写出这样的代码

> String sql = "select * from user where username =" + username;
> PreparedStatment pstmt = db.prepared(sql);
> pstmt.execute();

那 prepared statement 也救不了你了

）啊啊啊啊英语的大小写好烦啊，不管了

@bianhua

> 好，哪怕你将本地 prepare 模拟理解为“退回了 SQL 拼接”（当然，想想看确实，字符串最后毕竟是组合起来了嘛哈哈哈），但是楼主问题的预设是在 bind 和 exec 阶段，我提示的问题是在 initialization 阶段。
请再仔细看那篇 163 的文章，包括你后面的所谓的 initialization 都是错误的，希望大家也能仔细看一下之前的文章。

具体可以仔细看看 fallback （也就是普通 sql 执行），和 prepared statement create && execute 的区别。

> 我能这样看么：prepare 自己没有办法保证 100%不会注入，只有正确配置好一切之后它才能提供安全保证？
错误，只要是 MySQL native prepare，就没办法注入。特殊的 0day 之类的素除外。

>我不知道你在后面拼命证明我是错的，最后得到了什么结论。
MySQL native prepare 足够安全，就算不是 100%，也是无限接近于 100%

@murmur 啊，刚才没看到，这就不太清楚了。我也没查过相关文档，不过应该会完善点的吧。。

@gdtv 不能，你要在初始化的时候指定 charset，这是错误的方法。
不能使用$pdo->query('SET NAMES gbk');

要么使用刚刚那篇文章作者之前提到的 mysql_set_charset('gbk')
要么在初始化 pdo 的时候指定 charset （推荐这种）
$pdo = new PDO("mysql:host=localhost;dbname=world;charset=utf8", 'my_user', 'my_pass');

详情可以参考下
https://secure.php.net/manual/zh/mysqlinfo.concepts.charset.php
https://secure.php.net/manual/zh/function.mysql-set-charset.php

@bianhua 看来你到现在都没有理解 pdo 的工作原理，就不跟你讨论技术了。
那就希望你可以再花点时间认真看
http://zhangxugg-163-com.iteye.com/blog/1835721

如果你非得揪着字眼，我承认我那句话不完善
应该是 在 pdo 起作用的时候，fully functional 的情况下，100%

另外请不要使用诡辩论，这对问题的解决没有任何的意义。按你的说法，那就是任何东西都是不能回答 100% 的。那这些所有的问题都不用讨论了，反正你的解决方法也不是 100%的，你说是吧。

另外，你的错误我还是要指出来的


>另外，你在 9 楼所说
>> 而你举例的这个问题在于，PHP 没有这么操作，而是因为某种原因，回退到 SQL 语句拼接了，只不过是 PHP 自动拼接的。
>这根本就是错的，原因是进行了本地的 prepare，而不是退回了 SQL 拼接。 -> 这句话是完全错误的，详情请见上面连接的抓包信息。

@ovear 噢，再纠正一点

native prepare 的意思是 原生的 prepare，就是指的是 MySQL 自身的 prepare，这个是不会有任何注入问题的。之前 @我的层主理解有误，忘记说了，不然因为我没指出来，以后误导别人就不好了。
emulate prepare 的意思是 PHP 本地的 prepare 模拟

）还有挺多错别字，原谅我的输入法，在看电影，没怎么仔细看

最后如果我的理解有问题，欢迎指出。

@ovear 噢看漏了，你的那篇文章作者也有说噢

> I said at the very beginning that we could have prevented all of this if we had used mysql_set_charset('gbk') instead of SET NAMES gbk. And that's true provided you are using a MySQL release since 2006.

但为什么你不翻译完？或者我们通过同一个链接看到的版本不是一个？ LOL
>翻译完你给钱？ 还有一种可能，要么是我的语文水平太差，要么是你英语太差

要点是这样的，这是那个 PO 主的 Demo：
$pdo->query('SET NAMES gbk');
$var = "\xbf\x27 OR 1=1 /*";
$query = 'SELECT * FROM test WHERE name = ? LIMIT 1';
$stmt = $pdo->prepare($query);
$stmt->execute(array($var));

注意，他没有用 $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
> 根据 https://secure.php.net/manual/zh/pdo.setattribute.php
> PDO::ATTR_EMULATE_PREPARES 启用或禁用预处理语句的模拟。 有些驱动不支持或有限度地支持本地预处理。使用此设置强制 PDO 总是模拟预处理语句（如果为 TRUE ），或试着使用本地预处理语句（如果为 FALSE ）。如果驱动不能成功预处理当前查询，它将总是回到模拟预处理语句上。 需要 bool 类型。
> 默认情况为 true，存在我翻译的问题

其实到这就不用看了，因为后面肯定会有问题：服务器所认为的链接字符集被设置成了 gbk，本地的未改变，而且 prepare 是在本地。
> 所以你想表达生命，再复述我的内容一遍？

然后那个 PO 主就挑了个 Easy Target，0xbf27 => addslashes() => 0xbf5c27 （ 0x5c == '\'） => 字符串：縗'。

所以自然注入了。

这就是问题。所以这是一种 Charset Attack，利用字符串变形进行攻击。防御的方式也说了：
$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
> However, be aware that PDO will silently fallback to emulating statements that MySQL can't prepare natively

> This will usually result in a true prepared statement (i.e. the data being sent over in a separate packet from the query). However, be aware that PDO will silently fallback to emulating statements that MySQL can't prepare natively: those that it can are listed in the manual, but beware to select the appropriate server version).


下面是废话， 对 beware to select the appropriate server version 理解有问题，这不是解决方案，是让你注意看文档的时候选择正确的文档去看，因为不同版本的 MySQL fallback 的条件不同。

我们再看回答主的第一句话
>> I'm adapting this answer to talk about PDO...
>> adapting this answer
>>The short answer is yes, yes there is a way to get around mysql_real_escape_string().

所以这个问题产生的过程是
1)用了会 fallback 的 sql 语句，PDO 认为不能进行 MySQL native prepare，进行本地摸你
2)PHP 调用 mysql_real_escape_string()
3)mysql_real_escape_string 在某些版本下有 BUG，会导致过滤失败
4)PDO 直接把拼接的 SQL 发过去了
5)被注入了

另外，PHP 官方已经写得很清楚了，设置 charset 的时候，要在初始化的时候进行。你错误的使用了 PDO，导致 PDO 本身失效，能怪谁呢？
> https://secure.php.net/manual/zh/ref.pdo-mysql.connection.php