关于char有符号和无符号的问题
将格式控制符换为%d时，结果为-1，因为int占32个比特位（00000000 00000000 00000001
1111111），隐式转换为char类型时只取后八个比特位（11111111），变成补码后为10000001，得到其十进制为-1。
但是讲格式控制符转换危%u时，结果为啥是一堆乱码，求解答，非常感谢！
对于unsigned int 类型来说，-1就是这个很大的整数。因为最高位本来是符号位1，但转成无符号后，这个1就是有效数字位了
解释的很全了 https://stackoverflow.com/questions/27547377/format-specifier-for-unsigned-char
-1的二进制表示是11111111 11111111 11111111 11111111
不管是多少bit的数据，永远是最高位是符号位
你把第8位当符号位，前面都补0，是几个意思
- 这篇博客: 七、文件上传漏洞原理以及靶场中的 十二、%00截断绕过 部分也许能够解决你的问题, 你可以仔细阅读以下内容或者直接跳转源博客中阅读:
%00（url编码）截断：告诉别人我的话说完了
使用白名单机制下的文件上传：重点是把文件存放到某个地址。
文件上传->文件会被放入目标服务器的缓存目录->移动到代码规定的目录重命名
move_uploaded_file 把上传的文件移动到新位置，成功返回true，不成功返回false
$temp_file是缓存目录下的地址，$img_path是最后要移动到的地址
in_array() 在一个数组中是否能找到指定值
真实网站测试技巧：
1、上传一个正常图片（确保上传功能有效）
2、上传一个图片马（是否检测内容）
3、上传正常图片，改后缀（是否检测后缀）
可能遇到随机重命名了，所以我们上传的文件名没有作用。
这里注意这串数字，与$img_path=$_GET['save_path']."/".rande(10,99).date("YmdHis").".".$file_ext这行代码有关。
save_path=1
我们可以控制GET传参，如果我们写成1.php%00，则后面的重命名都不在意了
这里我们把url中的save_path 中加上%00。就可以发挥作用了。
%00截断第二个靶场和第一个类似，只是GET传参变成了POST，这里POST传参不接受url编码
%00截断和00截断本质上没有区别。有适用范围（php5.4以下），但是很多时候真实渗透测试时，不清楚内环境。
a是标识符，是61
进入hex把61改成00
如果你已经解决了该问题, 非常希望你能够分享一下解决方案, 写成博客, 将相关链接放在评论区, 以帮助更多的人 ^-^