Posts

location 优先级介绍 location 匹配方式有以下几种 location = /path/a/exact.png {}: 精确匹配 location ^~ /path/a/ {}: 优先前缀匹配（符合最长匹配原则） location ~ /Path?/ {} ： 区分大小写正则匹配（首次匹配原则） location ~* /path?/ {} : 不区分大小写正则匹配（首次匹配原则） location /path/a/test.png {} : 前缀匹配（符合最长匹配原则） location 优先级匹配与配置的先后顺序无关，优先级排列顺序如下 精确匹配 > 优先前缀匹配 > 区分大小写正则匹配=不区分大小写正则匹配 > 前缀匹配 实例说明 location = /path/a/exact.png { [ configuration A ] } location ~ /Path?/ { [ configuration B ] } location ~* /path?/ { [ configuration C ] } 如果理解了优先级，将很容易得出如下结论: www.web.com/path/a/exact.png => 匹配 configuration A www.web.com/Path/a => 匹配 configuration B www.web.com/path/a => 匹配 configuration C 当我们发现能够很好的猜测各种 URL 所匹配各个 location 是否心中有些许窃喜，对 location 优先级的理解已经不再话下了？事实并非如此，关于 location 优先级，还有一件事你需要知道。 ...

问题 在同一 server 中同时设置了， a.com, b.com.c.com 三个域名，若三个域名都需要 https 访问，应当如何配置呢？ 示例配置如下： server { listen 443 ssl; server_name a.com b.com c.com; ssl_certificate a.crt; ssl_certificate_key a.key; ... } 问题分析：如果在 ssl_certificate 与 ssl_certificate_key 的配置项中可以增加变量，此问题就可以迎刃而解。 变量 ssl_server_name 经过 goole 发现 nginx 在 1.15.10 及以后的版本支持 ssl_server_name 变量，此变量输出的便是所访问 URL 的 host 部分(不包含端口及后面的 path 部分). URL ssl_server_name https://a.com/test a.com https://b.com:83/test b.com https://c.com/test c.com 有了 ssl_server_name 就可以很好的解决我们在文章开头描述的问题参考配置如下: server { listen 443 ssl; server_name a.com b.com c.com; ssl_certificate /crtPath/$ssl_server_name.crt; ssl_certificate_key /keyPath/$ssl_server_name.key; ... } 配置完成重启服务后，就可以用 https 访问对应的 server_name 了 ...

Composer 是 PHP 的软件包管理系统，它提供用于管理 PHP 软件和依赖库关系的标准格式。作为日常开发，Composer 能够满足我们的日常需求，但有些情况下，我们有些公司内部的扩展，不希望被检索或者放在共有库中，就需要搭建私有库来解决问题。 在讨论搭建私有仓库前，我们先了解一下 Composer 是如何安装扩展的 Composer 安装扩展流程 通过上图我们不难发现，如果要构建私有仓库，我们需要构建一个类似 Packagist 的网站，来告诉 Composer 该从哪里下载扩展代码，这就需要用到 Satis 工具 Satis 介绍 Satis 是一个开源的静态 Composer 仓库生成器，有了它我们可以轻松的构建出一个类似 Packagist 的索引网站，来告诉 Composer 通过我们自己的私有仓库下载扩展。 安装 命令行安装 // 安装 composer create-project composer/satis:dev-main // 构建索引仓库 php bin/satis build <configuration-file> <output-directory> docker 安装 下载镜像： docker pull composer/satis 运行镜像: docker run --rm --init -it \ --user $(id -u):$(id -g) \ --volume $(pwd):/build \ --volume "${COMPOSER_HOME:-$HOME/.composer}:/composer" \ composer/satis build <configuration-file> <output-directory> 配置 创建一个名为：satis.json 的配置文件。 内容如下: ...

随着 nodejs 的兴起，前端开发也进入了 新的时代，webpack 的诞生，更是让其如虎添翼，构建出欣欣向荣的前端生态. 然而事物的发展总是在：发现问题->解决问题->引入新问题中往复。 webpack 给前端带来了一个新的高频操作就是打包，高频的打包会带来如下问题： 阻塞前端工作：前端必须等到打包完成，才能 进入后续工作,如果打包时间过长，这中间就会阻塞就会更加明显。 影响团队协作：当功能点开发完成后，未避免频繁打包，会将多个功能点合并在 一起打包，这样就会导致测试没有办法提前介入测试，如果测试出问题的功能点是在几天前开发的，对于代码已经有所遗忘，还需要阅读代码帮助找回记忆gg。 打断专注时间：如果前端正在专注的解决一个复杂问题,此时出现紧急问题需要打包，使得前端不得不从当前工作中抽身出来进行打包，打包完成后将需要一段时间的预热才可以像之前一样 专注的处理未完成的问题。 对于上述 问题完全可以通过工具构建出一套 CI/CD 方案交由计算机来解决，让前端工程师从打包解放出来。 工具 jenkens: 是一款由 JAVA 编写的开源的持续集成工具. gogs: 轻量级代码仓库 jenkins 与 gogs 的通讯是通过 Gogs plugin 通过 webhook 来通讯的。 方案 方案设计大致如下： 方案执行步骤： 前端工程师往代码仓库 push 代码 gogs 会调用 jenkins 的 webhook 地址触发 jenkins 工作流 jenkins 会将前端代码从代码仓库中拉取最新的代码，并执行构建流程 将构建好的代码上传到 dist 仓库(如果存在 CDN 则清除 CDN 缓存) push dist 仓库到 gogs 远程仓库 gogs 触发 dist 仓库的 webhook,将服务器代码更新到最新的打包文件 完成部署 测试人员执行测试用例（如果由缺陷，将缺陷反馈给前端开发人员） 好处 完成上述方案，前端工程师只需要将前端代码 push 到远程仓库，服务器会自动构建响应的包，并部署到测试服务器上供测试测试,前端可以缩小提交粒度并更快的将功能交付测试，也可以将问题尽早暴露尽早解决。 ...

Base64是一种基于64个可打印字符来表示二进制数据的表示方法。由于2的6次方等于64，所以每6个比特为一个单元，对应某个可打印字符。三个字节有24个比特，对应于4个Base64单元，即3个字节可表示4个可打印字符。它可用来作为电子邮件的传输编码。在Base64中的可打印字符包括字母A-Z、a-z、数字0-9，这样共有62个字符，此外两个可打印符号在不同的系统中而不同。一些如uuencode的其他编码方法，和之后binhex的版本使用不同的64字符集来代表6个二进制数字，但是它们不叫Base64。 起因 计算机以二进制形式（0和1）进行通信，但是人们通常希望与更丰富的表单数据（例如文本或图像）进行通信。 为了在计算机之间传输此数据，首先必须将其编码为0和1，然后发送，然后再次解码。 以文本为例-有许多不同的方法可以执行此编码。 如果我们都可以同意一个编码，那就简单得多了，但不幸的是事实并非如此。 最初创建了许多不同的编码（例如Baudot码），每个字符使用不同数量的位，直到最终ASCII成为每个字符7位的标准。 但是，大多数计算机将二进制数据存储在每个字节由8位组成的字节中，因此ASCII不适合传输此类数据。 有些系统甚至会擦除最高位。 此外，跨系统的行尾编码的差异意味着有时还会修改ASCII字符10和13。 为了解决这些问题，引入了Base64编码。 这样，您就可以将框架字节编码为已知可以安全发送而不损坏的字节（ASCII字母数字字符和几个符号）。 缺点是使用Base64编码消息会增加其长度-每3个字节的数据会编码为4个ASCII字符。 为了可靠地发送文本，您可以首先使用所选的文本编码（例如UTF-8）将其编码为字节，然后再对Base64进行编码，将生成的二进制数据编码为可安全发送为ASCII的文本字符串。 接收者将不得不逆转此过程以恢复原始消息。 当然，这要求接收者知道使用了哪种编码，并且该信息通常需要单独发送。 从历史上看，它已用于对电子邮件中的二进制数据进行编码，其中电子邮件服务器可能会修改行尾。 一个更现代的示例是使用Base64编码将图像数据直接嵌入HTML源代码中。 在这里，有必要对数据进行编码，以避免像“ <”和“>”这样的字符被解释为标签。 原理 base64 加密原理，是将待转换字符串转换为二进制并以三个字为一组（数据不足用 0 补足），每 6 位为一个索引组转换为十进制索引，通过索引在 base64 索引表中找到对应的字符作为编码后的字符（若原数据长度不是 3 的倍数时则对 3 取余余数为 1，则在编码结果后加2个=；若余数为 2，则在编码结果后加 1 个 =。）。 base64 转换实例 以 helloworld 为例转换过程如下： 经过上述步骤转后字符串为：aGVsbG93d29ybGQ=，到此一个完整的转码例子便完成了。 应用 base64 在需要网络通讯的场景下，有着非常广泛的应用场景，比如邮件的附件和图象传输，html img 标签的 src 属性也可以是 base64 编码的图片，还有我们常用的各类证书(支付证书，ssl 证书)的公钥和私钥.. Summary base64 是一个很优秀的编码方式，他很好的解决了复杂文件在传输中的问题，也因此被广泛的应用在各种场景之中。关于 base64 的使用，你还需要知道如下几点： base64 转码后的长度会有所变化，会比源数据的长度多出大约 1/3 base64 不具有加密特性，因此他不适用于加密的场景 由于 base64 字符中会有 +,/ 等字符，因此如果需要 url 传参的时候注意需要使用 URL 编码一下，否则有可能会导致接受到的数据无法正常解密的情况 References 维基百科 Why do we use Base64? What is base 64 encoding used for? ...