Posts

最近开发中，将一个 php 算法，移植到 golang 中，发现 base64 算法生成的字符串不一致，经过排查发现是由于 ASCII 控制字符导致的原因，加下来看代码 <?php $asciiArr =[10, 187, 217, 12, 207, 183, 184, 231, 184, 149, 118, 151]; $str = ''; foreach ($asciiArr as $ascii) { $str .= chr($ascii); } echo base64_encode($str); 上述代码输出： CrvZDM+3uOe4lXaX package main import ( "encoding/base64" "fmt" ) func main() { res := []int{10, 187, 217, 12, 207, 183, 184, 231, 184, 149, 118, 151} var str string var b []byte for _, v := range res { str += string(v) b = append(b, byte(v)) } byteCode := base64.StdEncoding.EncodeToString([]byte(b)) strCode := base64.StdEncoding.EncodeToString([]byte(str)) fmt.Println("byteCode:", byteCode) fmt.Println("stringCode:", strCode) } 上述代码输出： byteCode: CrvZDM+3uOe4lXaX stringCode: CsK7w5kMw4/Ct8K4w6fCuMKVdsKX 由此可以看出，关于 ASCII 控制字符的转码，不可以用 string 转 byte 到 EncodeToString 方法，如果需要一致输出，需要直接用 []byte 接收值传入 EncodeToString 即可

关于 Jenkins 的环境变量，可以分为系统内置环境变量和自定义环境变量。系统内置环境变量是 Jenkins 内部定义的环境变量。自定义环境变量是用户自己定义的环境变量 系统环境变量 jenkins 的内置环境变量的查看方式有两种，一种是通过 web url 地址查看，另一种是通过 shell 命令 printenv 查看 方式一:通过地址访问 直接在浏览器中访问 ${YOUR_JENKINS_HOST}/env-vars.html 页面就可以，比如 http://localhost:8080/env-vars.html ，每个变量的用途写的都很清楚 方式二：printenv 通过 shell 命令printenv 获取 pipeline { agent any stages { stage("Env Variables") { steps { sh "printenv" } } } } 通过执行上述 pipeline 的构建，就可以打印出系统内置的环境变量 自定义环境变量 在内置环境变量的基础上，有事我们也需要定义我们自己的的环境变量来方便开发和部署，自定义环境变量的设置分为三种，分别是：声明式，脚本式，内置函数式，接下来分别讲解一下三种方式各是如何设置的。 声明式 声明式定义结构如下： environment { key = value } 声明式可以在 pipeline 的任意阶段声明，看如下示例 pipeline { agent { label any } environment { //全局环境变量 NAME = "zhangsan" } stages { stage('Build') { environment { // 仅在 Build 阶段下有效的环境变量 NAME = "Andy" } steps { sh 'printenv' } } } } 脚本式 脚本式基本结构如下: ...

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 了 ...