HTTP 协议中的Content-Encoding 最近在做拟态开发过程中，遇到lua脚本响应PHP返回接口的数据乱码问题，通过postman调试发现响应头部Content-Encoding算法为gzip，而其他接口如python则没有这个设置。首先来了解下什么是Content-Encoding？Accept-Encoding 和Content-Encoding是HTTP中用来对采用哪种编码格式传输正文进行协定的一对头部字段。工作原理如下:首先浏览器（也就是客户端）发送请求时，通过Accept-Encoding带上自己支持的内容编码格式列表；服务端在接收到请求后，从中挑选出一种用来对响应信息进行编码，并通过Content-Encoding来说明服务端选定的编码信息浏览器在拿到响应正文后，依据Content-Encoding进行解压。服务端也可以返回未压缩的正文，但这种情况不允许返回Content-Encoding内容编码的目的是优化传输内容的大小，通俗的讲就是尽心压缩。一般经过gzip压缩过的文本响应，只有原始大小的1/4（这个数据我现在还不确定）。对于文本类响应是否开启了内容压缩，是我们做性能优化时首先要检查的重要项目；而对于JPG/PNG这类本身已经高度压缩过的二进制文件，不推介开启内容压缩，效果几乎微乎其微，还浪费cpu内容的编码针对的只是传输正文。在HTTP/1中，头部始终是以ASCII文本传输，没有经过任何压缩。不过这个问题在HTTP/2中已经解决，详见HTTP/2 头部压缩技术介绍内容编码使用特别广泛，理解起来也特别简单，但是要注意的是不要把它与HTPP中的另外一个概念：传输编码Transfer-Encoding搞混即可。内容编码格式gzip 和deflate开始之前，先来介绍三种数据压缩格式：DEFLATE，是一种使用 Lempel-Ziv 压缩算法（LZ77）和哈夫曼编码的数据压缩格式。定义于 RFC 1951 : DEFLATE Compressed Data Format Specification；ZLIB，是一种使用 DEFLATE 的数据压缩格式。定义于 RFC 1950 : ZLIB Compressed Data Format Specification；GZIP，是一种使用 DEFLATE 的文件格式。定义于 RFC 1952 : GZIP file format specification；这三个名词有太多的含义，很容易让人晕菜。所以本文有如下约定：DEFLATE、ZLIB、GZIP 这种大写字符，表示数据压缩格式；deflate、gzip 这种小写字符，表示 HTTP 中 Content-Encoding 的取值；Gzip 特指 GUN zip 文件压缩程序，Zlib 特指 Zlib 库；在 HTTP/1.1 的初始规范 RFC 2616 的「3.5 Content Codings」这一节中，这样定义了 Content-Encoding 中的 gzip 和 deflate：gzip，一种由文件压缩程序「Gzip，GUN zip」产生的编码格式，描述于 RFC 1952。这种编码格式是一种具有 32 位 CRC 的 Lempel-Ziv 编码（LZ77）；deflate，由定义于 RFC 1950 的「ZLIB」编码格式与 RFC 1951 中描述的「DEFLATE」压缩机制组合而成的产物；nginx中如何设置gzip在nginx.conf文件中 找到gzip 默认是on开启状态，改为off表示关闭然后重启nginx服务/usr/local/nginx/sbin/nginx -s stop /usr/local/nginx/sbin/nginx发现Content-Encoding没有返回，OK，这样不同接口之间就是原样输出，方便lua脚本输出内容！

虚拟机LINUX的root密码忘记如何重置 重启虚拟机进入到该页面之后，选中第一个（高亮显示即为选中）选项，然后按下键盘的“E”键进入到初始化脚本编辑页面，该脚本有两页，用下键向下拉，直到最后两行光标拉到最后两行需要加入一些文字后面加入下面这一行文字LANG=\zh_CN.UTF-8（我安装的是中文版的，也有可能你的是\en_US.utf-8）后面加下面这一行文字 init=/bin/sh5.加好之后按ctrl+x退出6.进入到这个页面之后（一开始只有上面那一行），表示初始化成功，然后依次输入mount -o remount,rw / #注意在rw后有空格passwd root输入两次新的密码（密码不会直接显示出来）touch /.autorelabelexec /sbin/init7.最后重启重新登录就可以了exec /sbin/reboot

Laravel底层原理（四） —— 控制反转（IOC） 什么是 IoC 控制反转（Inversion of Control，缩写为 IoC），是面向对象编程中的一种设计原则，可以用来减低计算机代码之间的耦合度。其中最常见的方式叫做依赖注入（Dependency Injection，简称 DI），还有一种方式叫 “依赖查找”（Dependency Lookup）。通过控制反转，对象在被创建的时候，由一个调控系统内所有对象的外界实体，将其所依赖的对象的引用传递给它。 — 维基百科 简单说来，就是一个类把自己的的控制权交给另外一个对象，类间的依赖由这个对象去解决。依赖注入属于依赖的显示申明，而依赖查找则是通过查找来解决依赖。Laravel 中的使用 注入一个类：App::bind('foo', function($app) { return new FooBar; });这个例子的意思是创建一个别名为 foo 的类，使用时实际实例化的是 FooBar。使用这个类的方法是：$value = App::make('foo');$value 实际上是 FooBar 对象。如果希望使用单例模式来实例化类，那么使用：App::singleton('foo', function() { return new FooBar; });这样的话每次实例化后的都是同一个对象。实现「控制反转」，有两种方式：Dependency Injection (DI) - 依赖注入Dependency Lookup - 依赖查找哪些方面的「控制」被「反转」了？ 依赖对象的「获得」被反转了。Class A 中用到了 Class B 的对象 b，一般情况下，需要在 A 的代码中显式的 new 一个 B 的对象。采用依赖注入技术之后，A 的代码只需要定义一个私有的 B 对象，不需要直接 new 来获得这个对象，而是通过相关的 容器控制程序 来将 B 对象在外部 new 出来并注入到 A 类里的引用中。而具体获取的方法、对象被获取时的状态由 容器 来指定。假设我有一个 iPhone，我的 iPhone 依赖充电器才能充电。class iPhone { // 电量 private $power; // 充电 public function charge() { } }我还有个苹果原装充电器：class AppleCharger { public function charge() { return 100; } }在以前，iPhone 内部「控制」着只能用哪一款充电器：class iPhone { // 电量 private $power; // 充电，只能用原装的充电器 public function charge() { $charger = new AppleCharger; $this->power = $charger->charge(); } }// 充电 $iphone = new iPhone; $iphone->charge();使用依赖注入之后，我来决定给 iPhone 用哪一款充电器：class iPhone { private $power; private $charger; // 依赖注入充电器，╮(╯▽╰)╭哎算了只要是充电器就行 public function __construct(Charger $charger) { $this->charger = $charger; } // 充电 public function charge() { $this->power = $this->charger->charge(); } }interface Charger { public function charge(); }// Laravel 容器 use Illuminate\Container\Container; $container = Container::getInstance(); // 给它一个原装充电器： $container->bind(Charger::class, AppleCharger::class); // 或者给它其它充电器 $container->bind(Charger::class, OtherCharger::class); // 充电 $iphone = $container->make(iPhone::class); $iphone->charger();可见，使用依赖注入之后，控制权「反转」了，由外部来决定给它什么充电器 (依赖对象)。Laravel 管这个 容器控制程序 叫 Service Container (服务容器)，它来控制着各种依赖的获取方法

Laravel底层原理（三） —— 依赖注入（DI） 概念依赖倒置原则 (Dependence Inversion Principle , 缩写为 DIP), 一种软件设计原则，是一个抽象的概念控制反转 (Inversion of Control , 缩写为 IoC),DIP 的一种具体实现方式.依赖注入 (Dependency injection , 缩写为 DI),IOC 的具体实现方式.依赖注入一词是由 Martin Fowler 提出的术语，它是将组件注入到应用程序中的一种行为。就像 Ward Cunningham 说的:依赖注入是敏捷架构中关键元素。什么是依赖 打个比方，就好比每个人都需要穿衣服才能进行正常的社会活动，这就是说是个人都需要依赖衣服才能正常社会活动。相应的，就是一个类需要另一个类才能完成工作，这就是依赖下面是person类依赖了衣服类class Person{ protected $clothes; public function __construct() { $this->clothes = new Clothes(); } }看上面的代码就知道 人依赖了衣服，什么是依赖注入呢，我们改造下上面的代码class Person { protected $clothes; public function __construct(Clothes $clothes) { $this->clothes = $clothes; } } $person = new Person(new Clothes()); 这里的Person 依赖注入了clothes类什么是控制反转（IOC）某人想开车，于是自己去造车，此时可以理解为控制正转，我想要车多大我就造多大，想要车是什么颜色就涂什么颜色.最后发现造车太难，于是选择去经销商买一辆车，可以理解为控制反转，经销商只提供蓝色的车，我就只能买蓝色的车，我被 经销商控制了，我依赖经销商给我注入车结论就是，造车难，买车容易，在写程序的时候使用依赖注入可以更好的解耦先看自己造车代码<?php class Car { //汽车可以跑,定义一个方法 run() public function run(){ return '滴滴滴,车开了'; } } class Person { private $car = null;//保存某人的车,暂时还没车 public function drive(){ $this->car = new Car();//要开车先造车,造了一辆车保存在某人的 $car 里 return $this->car->run();//调用车的 run() 方法 } } $xiaoming = new Person(); echo $xiaoming->drive();//输出 滴滴滴,车开了通过经销商依赖注入<?php class Car { //汽车可以跑,定义一个方法 run() public function run() { return '滴滴滴,车开了'; } } class Person { private $car = null;//保存某人的车,暂时还没车 //new 某人的时候,就给他注入一辆车,通过 $a 传入构造方法,并保存在 $car 里 public function __construct($a) { $this->car = $a; } public function drive() { return $this->car->run();//调用车的 run() 方法 } } $car = new Car();//买一辆车 $xiaoming = new Person($car);//new 小明的时候,把刚才买的车注入 echo $xiaoming->drive();//输出 滴滴滴,车开了万一 new 小明的时候，给他买了一架飞机，并注入，小明不会开飞机怎么办，通过类型限定解决这个问题class Person { . . . public function __construct(Car $a)// <----这里做类型限定,保证不会注入飞机,也不会注入火箭 { $this->car = $a; } . . .IOC容器 在上例中，我们是手动的去 new 一辆车并注入给某人，现在用一个容器统一的去管理这些需要注入的类。<?php class Car { //汽车可以跑,定义一个方法 run() public function run() { return '滴滴滴,车开了'; } } class Person { private $car = null;//保存某人的车,暂时还没车 //new 某人的时候,就给他注入一辆车,通过 $a 传入构造方法 public function __construct(Car $a)// <----这里做了类型限定 { $this->car = $a; } public function drive() { return $this->car->run();//调用车的 run() 方法 } } //写一个简单的 IoC 容器类 class Container{ private static $objArr = [];//定义一个静态的空数组 public static function set($flag, Callable $func){ self::$objArr[$flag] = $func;//存入键值对,键是一个字符串,作为标识符,值是一个匿名函数 } public static function get($flag){ $tmp = self::$objArr[$flag];//取出标识符对应的匿名函数,用$tmp临时保存一下 return $tmp();//在$tmp后名加上括号,表示执行这个函数,并返回 } } //下面这条语句执行完毕后,会在 $objArr 里存入一个键值对,键是 car ,值是这个匿名函数,该匿名函数返回的是创建 Car 对象的语句 Container::set('Car', function(){ return new Car(); }); //下面这条语句执行完毕后,会在 $objArr 里存入一个键值对,键是 person ,值是这个匿名函数,该匿名函数返回的是创建 Person 对象的语句 Container::set('Person', function(){ return new Person(Container::get('Car'));//直接去容器中取一辆车出来,并作为参数传给 Person 类的构造函数 }); $xiaomin = Container::get('Person');//直接去容器中取一个人出来,取名叫小明 echo $xiaomin->drive();//输出 滴滴滴,车开了IOC 是什么呢，看明白了依赖注入 (DI) 后就很容易理解了通过 DI 我们可以看到，一个类所需要的依赖类是由我们主动实例化后传入类中的。控制反转的意思就是说将依赖类的控制权交出去，由主动变被动。依赖注入的方式上面的例子都是通过构造方式的形式依赖注入进去，那还能通过其他方式么？Setter 方法注入#class UserProvider{ protected $connection; public function __construct(){ ... } public function setConnection( Connection $con ){ $this->connection = $con; } ...接口注入#interface ConnectionInjector{ public function injectConnection( Connection $con ); } class UserProvider implements ConnectionInjector{ protected $connection; public function __construct(){ ... } public function injectConnection( Connection $con ){ $this->connection = $con; } }所以，简单讲只要不是由内部生产（比如初始化、构造函数 __construct 中通过工厂方法、自行手动 new 的），而是由外部以参数或其他形式注入的，都属于依赖注入（DI） 。是不是豁然开朗？事实上，就是这么简单。

Laravel底层原理（二） —— 契约（Contracts） 概述 Contract，翻译过来叫契约、协议等。在 Laravel-china 的翻译中，是一个不翻词，这里也使用 Contract 来代替。Contract 就是接口 Interface，用来规范某些服务的功能结构的，在 Laravel 中称之为契约。以缓存操作为例，我们直接使用 Cache::get() 和 Cache::put() 即可完成缓存的获取和设置，语法很简单。此时问题来了：缓存的实现有很多种，例如文件缓存，Memcache 缓存，Redis 缓存等，要保证任何一种缓存的操作都具备 get 和 put 方法，如何保证？就是需要每种缓存服务的实现，都实现 Cache 契约，契约就是接口，就可以保证每种缓存的实现都具有一致的结构了。缓存服务实现与 Cache 契约结构说明 我们以 Cache 契约和一系列 Cache 服务实现为例，说一下这个结构：缓存的相关实现，都位于：Illuminate\Cache\ 下：Laravel8.77.1 预设了：Apc, Array, File, Database, Memcached, Null, Redis, Taggable 多种缓存的具体实现方案，以常用的 Redis 为例，Illuminate\Cache\RedisStore 就是 redis 缓存服务实现，查看其源代码：<?php namespace Illuminate\Cache; use Illuminate\Contracts\Cache\LockProvider; use Illuminate\Contracts\Redis\Factory as Redis; use Illuminate\Redis\Connections\PhpRedisConnection; class RedisStore extends TaggableStore implements LockProvider { }可见，该 Redis 缓存功能类，需要实现一个 Store 的接口，这个接口就是 Illuminate\Contracts\Cache\LockProvider ，在 Laravel 中称之为契约，看该 Cache 契约的实现：<?php namespace Illuminate\Contracts\Cache; interface LockProvider { /** * Get a lock instance. * * @param string $name * @param int $seconds * @param string|null $owner * @return \Illuminate\Contracts\Cache\Lock */ public function lock($name, $seconds = 0, $owner = null); /** * Restore a lock instance using the owner identifier. * * @param string $name * @param string $owner * @return \Illuminate\Contracts\Cache\Lock */ public function restoreLock($name, $owner); } 接口契约中定义了关于缓存应该具备的方法，这样在缓存操作时，无论文件，Redis 或者 Apc 缓存，都具有了统一的接口，不用担心使用上的语法差异了。说了这么多，其实就是操作上的抽象层，将需要的操作提取，保证所有驱动实现具有统一的结构。这就是接口的常规目的，Laravel 中叫成了契约而已，没有特殊功能。官方文档概要 在契约这篇官方文档中，主要说明契约的优势。内容如下：使用契约原因，可以使得代码低耦合，保证代码的简洁性。内置契约参考列表文档中，有一个章节是比较 Facade 和 Contract。放在一起比较的原因，应该是在 Laraval 中，通常每个 Contract 都有对应的 Facade。就像我们 Cache，就有 Cache 的 Facace 和 Cache 的 Contract。当使用 Cache 时，会导致我们确定不了当前时契约 Contract 还是门面 Facade。这就是放在一起比较的原因吧，语法类似。但除此之外，Contract 与 Facade 功能完全不同，作用也不同，其实没有什么可比性。Facade，简化服务的调用语法的功能。Contract，定义一组服务的通用操作接口。一组相关的服务，既需要通用的接口，也需要简化调用的操作。就是需要 Contract 也需要 Facade，两者作用完全不同，其实不用混淆，不用放在一起比较的！