搜索到
4
篇与
的结果
-
PHP 5.0~5.6 各版本兼容性的 cURL 文件上传 最近在搞一个针对sm.ms 图片站的上传插件，然后就遭遇curl 坑，也不知道是年龄大了，还是PHP 真的越来越麻烦了。转载一篇文章，作为备注吧最近做的一个需求，要通过PHP调用cURL，以multipart/form-data格式上传文件。踩坑若干，够一篇文章了。重要警告没事不要读PHP的官方中文文档！版本跟不上坑死你！不同版本PHP之间cURL的区别PHP的cURL支持通过给CURL_POSTFIELDS传递关联数组（而不是字符串）来生成multipart/form-data的POST请求。传统上，PHP的cURL支持通过在数组数据中，使用“@+文件全路径”的语法附加文件，供cURL读取上传。这与命令行直接调用cURL程序的语法是一致的：curl_setopt(ch, CURLOPT_POSTFIELDS, array( 'file' => '@'.realpath('image.png'), )); equals $ curl -F "file=@/absolute/path/to/image.png" <url> 但PHP从5.5开始引入了新的CURLFile类用来指向文件。CURLFile类也可以详细定义MIME类型、文件名等可能出现在multipart/form-data数据中的附加信息。PHP推荐使用CURLFile替代旧的@语法：curl_setopt(ch, CURLOPT_POSTFIELDS, [ 'file' => new CURLFile(realpath('image.png')), ]); PHP 5.5另外引入了CURL_SAFE_UPLOAD选项，可以强制PHP的cURL模块拒绝旧的@语法，仅接受CURLFile式的文件。5.5的默认值为false，5.6的默认值为true。但是坑的一点在于：@语法在5.5就已经被打了deprecated，在5.6中就直接被删除了（会产生 ErorException: The usage of the @filename API for file uploading is deprecated. Please use the CURLFile class instead）。对于PHP 5.6+而言，手动设置CURL_SAFE_UPLOAD为false是毫无意义的。根本不是字面意义理解的“设置成false，就能开启旧的unsafe的方式”——旧的方式已经作为废弃语法彻底不存在了。PHP 5.6+ == CURLFile only，不要有任何的幻想。我的部署环境是5.4(仅@语法)，但开发环境是5.6(仅CURLFile)。都没有压在5.5这个两者都支持过渡版本上，结果就是必须写出带有环境判断的两套代码。现在问题来了……（挖掘机滚远点！）环境判断：小心魔法数字！我见过这种环境判断的代码：if (version_compare(phpversion(), '5.4.0') >= 0) 我对这种代码的评价只有一个字：屎。这个判断掉入了典型的魔法数字陷阱。版本号莫名其妙的出现在代码之中，不查半天PHP手册和更新历史，很难明白作者被卡在了哪个功能的变更上。代码应该回归本源。我们的实际需求其实是：有CURLFile就优先采用，没有再退化到传统@语法。那么代码就来了：if (class_exists('\CURLFile')) { $field = array('fieldname' => new \CURLFile(realpath($filepath))); } else { $field = array('fieldname' => '@' . realpath($filepath)); } 建议明确指定的退化选项从可靠的角度，推荐指定CURL_SAFE_UPLOAD的值，明确告知php是容忍还是禁止旧的@语法。注意在低版本PHP中CURLOPT_SAFE_UPLOAD常量本身可能不存在，需要判断：if (class_exists('\CURLFile')) { curl_setopt($ch, CURLOPT_SAFE_UPLOAD, true); } else { if (defined('CURLOPT_SAFE_UPLOAD')) { curl_setopt($ch, CURLOPT_SAFE_UPLOAD, false); } } cURL选项设置的顺序不管是curl_setopt()单发还是curl_setopt_array()批量，cURL的选项总是设置一个生效一个，而设置好的选项立刻就会影响cURL在设置后续选项时的行为。例如CURLOPT_SAFE_UPLOAD就和CURLOPT_POSTFIELDS的行为有关。如果先设置CURLOPT_POSTFIELDS再设置CURLOPT_SAFE_UPLOAD，那么后者的约束作用就不会生效。因为设置前者时cURL就已经把数据实际的识读处理完毕了！cURL有那么几个选项存在这种坑，务必小心。还好这种存在“依赖关系”的选项不多，机制也不复杂，简单处理即可。我的方法是先批量设置所有的选项，然后直到curl_exec()的前一刻才用curl_setopt()单发设置CURLOPT_POSTFIELDS。实际上在curl_setopt_array()用的数组中，保证CURLOPT_POSTFIELDS的位置在后边也是可靠的。PHP的关联数组是有顺序保障的，我们也可以假设curl_setopt_array()内部的执行顺序一定是从头到尾按顺序[注A]，所以尽可放心。我的做法只是在代码表现上加个多余的保险，突出强调顺序的重要性防以后手贱。命名空间PHP 5.2或以下的版本没有命名空间。代码中用到了空间分隔符\就会引发解析器错误。要照顾PHP 5.2其实容易想，放弃命名空间即可。要注意的反倒是有命名空间的PHP 5.3+。无论是调用CURLFile还是用class_exists()判断CURLFile的存在性，都推荐写成\CURLFile明确指定顶层空间，防止代码包裹在命名空间内的时候崩掉。 -
-
关于推广链接 事情还得从我得到个阿里云代金券说起，因为得到的多，所以就没用，看到群里有个人在哪里要代金券，顺手就给了，并且发了我的推荐链接。当时自己的想法是想顺便赚个推介费。这事也就过去了晚上看阿里云账户，顺手点开推荐看了下，哎，那个叫校长的家伙竟然没通过我的链接注册，哎，这让我感觉很是失落。自己多少对于自己送代金券的行为感觉傻了。劈开具体的事情，说说。推广链接这东西就是别人通过介绍或者其他方式向你推销，你买到产品，他赚了提成，有点像现在的传销或者是保险。但这种行为本身并不违法，挺正常的商业手段，你不会因为点了推广链接你就损失什么？你只是获得了信息，而别人却能通过推荐链接获得提成。感觉这样的解释挺绕口的还是用现实中的事情来解释吧，就像我是保险推销员，给你推荐保险，你买保险了，我获得了提成。这样的商业行为，貌似也没啥问题。其实自己在看到别人的推广链接的时候，也总是手动去掉尾巴，不想给别人赚推介费。有时也在想自己干嘛要这样，别人提供了信息，自己购买还便宜了，再说别人赚推荐费自己也不用多掏钱，想想是互利的，但为什么就是不愿意点呢，而是费力的去掉推荐链接？？？一直没细细的思考这个问题，直到几天我才正式想了想，我想大概是人性的问题吧，像打麻将，我不糊你也别想胡，看不得人赚钱。更别想利用我赚钱（权当是利用吧）。细想下这个其实多少有点问题，这其实是互惠的行为，你购买了，说明你需要，而我通过向你介绍获得了提成。这种行为并不会损害到哪一方。相反的，如果我推荐了，写了好多说明，还提供了优惠码，代金券，你用我的优惠码、代金券省了不少钱，而我想得到的推介费却没有，那肯定会像我这样失落，感觉自己很傻，出力讨不到好。继续推广开来，好多事情也是这样，同处一地的人，首先想到的是竞争，而不是互助，都是拆台，不想搭台。就是对大家都有利，这个台也不会便宜你。类似事情好多啊，比如你好心告诉别人个消息，别人竟然没搭理你，你好心去扶老太太，却被老太太讹上了…………既然知道缘由了，抱怨是无用的，还是找解决问题的办法，看到的办法有1：放弃不做。这不是解决问题啊。2：曲线救国，制造麻烦，这只能说是次办法，但是挺解决问题，耽误你我的时间。自己想想也没想到什么好办法，只能是这样。弄个短链接，隐藏推荐网址，尽量把推荐引导到网站，增加获取难度。其他的事情也是这样，不采用直接手段，曲里拐弯转着来。哎，想想多可悲，由于人性，效率降低了很多。顺便深深地鄙视下此人，出口恶气：校长 6889412
-
