php 使用字符判断 bool 值 true or false 注意事项
学习 php 的时候有看到过相似的总结归纳,但还是会忘,只有自己在实践中犯错了才能印象深刻。很多时候会把一个字符串、或者一个数组作为判定条件,然后不经意间就犯错了。比如 '0' == false 是 ok 的,但 '0.0' 值为 true。数组里面 array() == false 是 ok 的,但 array(0) 值为 true。== 在判断条件里是会自动转换两边类型的,当直接将字符串或者数
学习 php 的时候有看到过相似的总结归纳,但还是会忘,只有自己在实践中犯错了才能印象深刻。很多时候会把一个字符串、或者一个数组作为判定条件,然后不经意间就犯错了。比如 '0' == false 是 ok 的,但 '0.0' 值为 true。数组里面 array() == false 是 ok 的,但 array(0) 值为 true。== 在判断条件里是会自动转换两边类型的,当直接将字符串或者数
不推荐将数组数据通过 serialize() 存储到 cookie 中,因为:Cookie 名称可以设置成数组名称,PHP 脚本里会是数组, 但用户系统里储存的是单独分开的 Cookie。 可以考虑使用 explode() 为一个 Cookie 设置多个名称和值。 不建议将 serialize() 用于此处,因为它会导致安全漏洞。—— 注释 - setcookie - php.net这边仅作测试使
因为 substr() 针对的是英文字符串,中文字符串需要用 mb_substr()。为什么使用了 mb_substr() 之后依然出现乱码呢?这与 mb_substr("为中华之崛起而读书",0, 6, "utf-8") 中的第一个参数和第四个参数有关。参考 php 判断字符串长度 strlen() 与 mb_strlen() 函数用法与不同环境下的测试,
2021-04-14 更新整理之前的项目,使用 codeigniter 框架。在用户登录之后会更新以下最后登录时间,数据库里使用了 datetime 存储,查看记录发现,数据库写入的日期 2021-04-14 08:29:07 与当前系统显示的时间(当前东八区时间)相差(慢)了 6 个小时。网上查找资料,回顾了以下 php 中获取和设置时区的函数 date_default_timezone_get
经过昨天的 PHP 脚本注入代码分析,在删除了相关注入代码后并保存后,今早官网访问又异常了。页面显示空白,与昨日场景如出一辙,但我查看那个公共文件,并没有发现注入代码,似乎一切都很正常。在彻底卸载相关软件后,依然没有恢复。没办法,只能通过设置输出锚点来确认产生错误的位置。echo 1; exit();查找到产生错误的位置(destoon - b2b 框架):($DT['gzip_enable']
之前经历过一次网站被挂马 网站入口文件被劫持(网站被挂马)事件回顾,因为网站使用了 HTTPS 协议,引入外部 js 脚本会产生跨域错误,引入会失败。所以虽然网站入口文件被篡改了,但其通过“挂马”传播“灰产”网站的目的并没有实现。这一次是后台页面显示不正常,然后线上调试找到了一段 PHP 脚本注入代码:header("Content-Type: text/html;charset=utf
swiper 中的每个 swiper-slide 表示一个滑动的单页,如果每个单页只展示一条数据,这是比较好布局的。但如果每个单页展示多条数据,就需要额外的逻辑处理。<div class="swiper-container"> <div class="swiper-wrapper"> <div class="s
PHP 直接使用 date() 即可:PHP: date - Manual// after php 4.1.0 $w = date('W'); // 当天 $w1 = date('W', strtotime('2020-07-28')); // 某天MySQL 某天WEEK(date_add('2020-07-28',interval 6 day),2);或者当天weekofyear(curdat
概念解释OAuth 就是一种授权机制。数据的所有者告诉系统,同意授权第三方应用进入系统,获取这些数据。系统从而产生一个短期的进入令牌(token),用来代替密码,供第三方应用使用。OAuth 主要解决的就是多个应用需要创建多个账号太过繁琐以及密码登录本身存在的安全问题。注册一个通讯账号,其他的应用获取其授权即可,而不用再去创建多个账号(虽然三方应用程序内部还是去创建了账号,但对于用户来说是透明的,
阅读了阮一峰的 理解 RESTful 架构 和 RESTful API 设计指南,对一些关键的概念做一个简单的备忘。RESTful 概念理解REST,全称 “Representational State Transfer”,阮翻译成 “表现层状态转化”,补全主语就是 “资源表现层状态转化”。主要特性:功能强、性能好、适宜通信。符合这样规范的 API 架构就可以称为 RESTful API。资源是网