猿来猿往

技术发展真的是日新月异。当我的记忆还停留在PhantomJS时，却发现PhantomJS早已经停止维护了。（因为chrome等浏览器都推出headless模式，2018-05时作者就已经发issue说将要archive这个项目，2023-05-30 archive了此项目。此项目的最后一个版本是2016-01-25发布的2.1.1版本）

目前实现headless浏览的有两种方式：WebDriver 和 DevTools Protocol。

以chrome为例，可以查阅如下资料：

• Chrome DevTools Protocol https://developer.chrome.com/docs/devtools/
• ChromeDriver(WebDriver for Chrome) https://sites.google.com/chromium.org/driver/

那么，DevTools Protocol 和 WebDriver之间的区别是什么呢？

可以参考：https://stackoverflow.com/questions/50939116/what-is-the-difference-between-webdriver-and-devtool-protocol

Main difference between WebDriver protocol and DevTools protocol is that WebDriver protocol needs a middle man like browser-driver (eg: chrome-driver) which is a server that sits between the automation script and browser enabling browser control, but in case of DevTools protocol the automation script can directly talk to browser running in debug mode making headless automation pretty straight forward.

And Chrome driver internally uses DevTools protocol to control browser, so if we are using WebDriver protocol it will in turn use Devtools protocol to control browser.

If cross-browser testing is something important for the new testing tool, DevTools protocol may not be suitable now, as there is no standard yet and it is mostly work in progress. Otherwise DevTools protocol will be a great choice as it gives more control like intercepting request header, simulating network etc and makes headless automation way easier.

其他：

• 涉及无头浏览器操作的具体编码上，建议使用Selenium或者Playwright等工具，它们都提供了多种语言的绑定，支持所有主流的浏览器。
• 至于爬虫框架的话，可以使用scrapy。

大家在前后端联合开发时经常会遇到一个问题，js不能处理服务端返回的JSON中的大整数。处理方法往往是将这个大整数字段设置为string。

为什么js不能处理大整数了？
因为之前js只有number类型来表示数字（整数+浮点数），其遵循IEEE 754规范，是一个双精度 64 位二进制格式值，其整数的最大支持2的53次方-1（2^53-1）：9007199254740992。内置常量Number.MAX_SAFE_INTEGER值为9007199254740991（2^53-1），因为当赋值给Number类型变量大于此值时（比如2^53，2^53+1，……），都会被存储为2^53。顺带提一下，还有一个常量：Number.MAX_VALUE。

后来新增了BitInt这种内置类型，它提供了一种能力来表示大于 2^53 – 1 的整数。而且BigInt 可以表示任意大的整数。
可以用在一个整数字面量后面加 n 的方式定义一个 BigInt ，如：10n，或者调用函数 BigInt()（但不包含 new 运算符）并传递一个整数值或字符串值。

const theBiggestInt = 9007199254740991n;
const alsoHuge = BigInt(9007199254740991);
// 9007199254740991n
const hugeString = BigInt("9007199254740991");
// 9007199254740991n
const hugeHex = BigInt("0x1fffffffffffff");
// 9007199254740991n
const hugeBin = BigInt("0b11111111111111111111111111111111111111111111111111111");
// 9007199254740991n

那么又有新问题了，既然js支持大整数，那么为什么服务端不能返回大整数了？
因为我们服务端返回数据设定Content-Type: application/json时，我们告诉客户端这是一段json，而根据json规范的定义，其只支持js的number类型，而不支持BitInt类型，所以当服务端返回的json包含了一个大于Number.MAX_SAFE_INTEGER的整数时（其实这个时候严格来说服务端没有遵循json规范），客户端不能识别是正常的现象（按照上文提到的，会被转换成2^53），是符合json的规范的行为。那所以web客户端这边没有把服务端返回的大整数转换成BitInt类型是源于遵循JSON规范。既然web客户端不支持大于2^53-1的整数，那么服务端就应该避免返回这些数据，所以如果某个字段是int64类型，那么为了安全，建议将int64转换成string类型返回，服务端接收web客户端参数时也一样。

当然我们期待json规范也能更新（到时出现一个Content-Type: application/json2，哈哈），能够原生支持BitInt类型，然后内置的JSON对象的parse()和stringify()两个方法也升级支持BitInt类型。这样我们开发者就可以安全方便的在前后端之间传输int64类型数据了。

References:

https://zh.wikipedia.org/wiki/雙精度浮點數

https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Number

https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/BigInt

直接看代码

var i int32
var ii int64
var b bool
var s string
fmt.Printf("width:%d\n", unsafe.Sizeof(i))  // width:4
fmt.Printf("width:%d\n", unsafe.Sizeof(ii)) // width:8
fmt.Printf("width:%d\n", unsafe.Sizeof(b))  // width:1
fmt.Printf("width:%d\n", unsafe.Sizeof(s))  // width:16

{
   //空结构体的宽度为 0
   type S struct{}
   var ss S
   fmt.Printf("width:%d\n", unsafe.Sizeof(ss)) // width:0
}

{
   type stringStruct struct {
      str unsafe.Pointer // 8
      len int            // 8
   }
   var ss stringStruct
   fmt.Printf("width:%d\n", unsafe.Sizeof(ss)) // width:16
}

//以下涉及内存对齐
// https://dave.cheney.net/2014/03/25/the-empty-struct#comment-2815
{
   type S struct {
      a uint64 // 8
      b uint32 // 4
   }
   var s S
   fmt.Printf("width:%d\n", unsafe.Sizeof(s)) // width:16, not 12
}

{
   type S struct {
      a uint64    // 8
      b uint32    // 4
      c [3]uint32 // 12
   }
   var s S
   fmt.Printf("width:%d\n", unsafe.Sizeof(s)) // width:24
}

{
   type S struct {
      a uint64 // 8
      b bool   //1
   }
   var s S
   fmt.Printf("width:%d\n", unsafe.Sizeof(s)) // width:16, not 9
}
{

   type S struct {
      a uint64    // 8
      b uint32    // 4
      c bool      //1
      d [3]uint32 // 12
   }
   var s S
   fmt.Printf("width:%d\n", unsafe.Sizeof(s)) // width:32, not 25(8+4+1+12), not 28(8+4+4+12)
}

{
   type S struct {
      a uint64 // 8
      b uint32 // 4
      c bool   //1
      d uint32 // 4
   }
   var s S
   fmt.Printf("width:%d\n", unsafe.Sizeof(s)) // width:24
}

关键要读懂Russ Cox的这段话：

It’s not true that “a value must be aligned in memory to a multiple of its width.” Each type has another property, its alignment. Alignments are always powers of two. The alignment of a basic type is usually equal to its width, but the alignment of a struct is the maximum alignment of any field, and the alignment of an array is the alignment of the array element. The maximum alignment of any value is therefore the maximum alignment of any basic type. Even on 32-bit systems this is often 8 bytes, because atomic operations on 64-bit values typically require 64-bit alignment.

To be concrete, a struct containing 3 int32 fields has alignment 4 but width 12.

It is true that a value’s width is always a multiple of its alignment. One implication is that there is no padding between array elements.

References:

https://dave.cheney.net/2014/03/25/the-empty-struct#comment-2815

https://ijayer.github.io/post/tech/code/golang/20200419_emtpy_struct_in_go

说道闰秒，可能很多人没有听说过，而闰年和闰月应该被很多人熟知。

闰年是指该年有366日，即较平常年份多出一日。闰年是为了弥补因人为历法规定的年度天数365日和平均回归年的大约365.24219日的差距而设立的。不同历法有不同置闰方法。儒略历每4年置1闰日，平均1年是365.25日。格里高利历每400年少3次闰日，平均是365.2425日。多出来的一天为2月29日。（参考：https://zh.m.wikipedia.org/zh-sg/%E9%97%B0%E5%B9%B4）

我们生活里说的闰月通常是指农历（阴阳历）的闰月。闰月没有固定是一年的中的哪一个月，是动态的，总的规则是19年加7个闰月，即“19年7闰法”。（参考：http://www.gov.cn/govweb/fwxx/kp/2009-06/16/content_1341232.htm）

那什么是闰秒呢？

为确定时间，世界上有两种常用的时间计量系统：基于地球自转的世界时（UT）（参考：https://zh.wikipedia.org/zh-sg/%E4%B8%96%E7%95%8C%E6%97%B6
）和基于原子振荡周期的国际原子时（TAI）（参考：https://zh.wikipedia.org/zh-sg/%E5%9C%8B%E9%9A%9B%E5%8E%9F%E5%AD%90%E6%99%82）。由于两种测量方法不同，随着时间推移，两个计时系统结果会出现差异，因此有了协调世界时的概念。
协调世界时以国际原子时秒长为基础，在时刻上尽量接近世界时。1972年的国际计量大会决定，当国际原子时与世界时的时刻相差达到0.9秒时，协调世界时就增加或减少1秒，以尽量接近世界时，这个修正被称作闰秒。
闰秒实际上是为适应地球自转的脚步而对国际原子时的人为增减。依据国际地球自转服务组织对国际原子时与世界时的监测数据，当两者之差达到0.9秒时，该机构就向全世界发布公告，在下一个6月或12月最后一天的最后一分钟，实施正闰秒或负闰秒。
自1972年协调世界时正式使用至今，全球已经实施了27次正闰秒调整，最近一次的闰秒调整是格林尼治时间2016年12月31日。从协调世界时正式使用以来，地球自转一直处于不断减慢的趋势，因此迄今为止的闰秒都是正闰秒，但相关科研发现，自2020年年中以来，地球自转速率呈现加快趋势，这意味着未来也可能会出现负闰秒。（参考：闰秒是什么，将何去何从  http://www.news.cn/tech/2022-11/19/c_1129142173.htm）

之前我有写过关于monotonic clock的内容。当时就提到闰秒，正的闰秒会导致wall clock比较时出现负值，所以我们需要使用monotonic clock来克服这一个问题。那为什么呢？我们来看看目前如何处理正值的闰秒的，1998-12-31日的闰秒为例：

可以看到，发生闰秒的1998-12-31 23:59:59之后不是1999年1月1日00:00:00，而是中间多了一个1998-12-31 23:60:60，这两秒的Unix timestamp是一样的。所以如果在使用毫秒级、微秒级、纳秒级的时间戳时，在这两秒里就可能出现负的时间戳差值，比如：23:59:59.600 ~ 23:60:60.000，差值就是一个负值。

写在最后，使用闰秒这种处理方法已被证明具有破坏性，特别是在二十一世纪，尤其是在依赖精确时间戳或时间关键程序控制的服务中。相关国际标准机构一直在讨论是否继续这种做法。（参考：https://zh.wikipedia.org/zh-sg/%E9%97%B0%E7%A7%92）

常见的charset：

一般常用的charset是utf8、utf8mb4。

如下是MySQL 8的文档描述：

• utf8mb4: A UTF-8 encoding of the Unicode character set using one to four bytes per character.
• utf8mb3: A UTF-8 encoding of the Unicode character set using one to three bytes per character. This character set is deprecated in MySQL 8.0, and you should use utfmb4
• utf8: An alias for utf8mb3. In MySQL 8.0, this alias is deprecated; use utf8mb4utf8 is expected in a future release to become an alias for utf8mb4.

总结来说，utf8mb4字符集支持最多使用4个字节来存储一个字符，这样就支持很多额外的特殊字符，比如emoji符号。可以说utf8mb3是个历史产物，当年MySQL支持UTF-8时，UTF标准里一个字符最多只占用3个字节。而后UFT-8标准更新后最多使用4个字节后，MySQL在5.5版本开始新增utf8mb4以支持4个字节存储一个字符。而到目前为止（2023-01）MySQL的utf8还是utf8mb3的别名，当然将来可能uft8会被指向utf8mb4。

以上都是老生常谈的知识了，大家无脑的使用utf8mb4就可以了。今天要说的其实是collate，collate主要用于排序和字符比较。因为最近遇到一个问题，就是sql查询时，使用 name like ‘%keywords%’时，MySQL是区分大小写匹配的，一看表的collate是utf8mb4_bin，破案了。那么我们来看看MySQL有哪些常用的collate。

utf8mb4_bin： 将字符串每个字符用二进制数据编译存储，区分大小写，而且可以存二进制的内容。

utf8mb4_general_ci：ci即case insensitive，不区分大小写。是一个遗留的校对规则，不支持扩展，它仅能够在字符之间进行逐个比较，没有实现Unicode排序规则，在遇到某些特殊语言或者字符集，排序结果可能不一致。但是，在绝大多数情况下，这些特殊字符的顺序并不需要那么精确。

utf8mb4_unicode_ci：是基于标准的Unicode来排序和比较，能够在各种语言之间精确排序，Unicode排序规则为了能够处理特殊字符的情况，实现了略微复杂的排序算法。

utf8mb4_general_cs：基本同utf8mb4_general_ci，区别是区分大小写。

utf8mb4_unicode_cs：基本同utf8mb4_unicode_ci，区别是区分大小写。

大家可以看到规律了吧：

*_bin: 表示的是binary case sensitive，也就是说是区分大小写的

*_cs: case sensitive，区分大小写

*_ci: case insensitive，不区分大小写

我本地MySQL8 配置文件中字符集相关变量

show variables like '%character%';

Variable_name    Value

character_set_client  utf8mb4

character_set_connection       utf8mb4

character_set_database   utf8mb4

character_set_filesystem  binary

character_set_results utf8mb4

character_set_server utf8mb4

character_set_system       utf8mb3

……


show CHARSET like 'utf%'; -- 查看MySQL的default COLLATE


Charset Description  Default collation Maxlen

utf16     UTF-16 Unicode utf16_general_ci 4

utf16le  UTF-16LE Unicode    utf16le_general_ci     4

utf32     UTF-32 Unicode utf32_general_ci 4

utf8mb3       UTF-8 Unicode   utf8_general_ci   3

utf8mb4       UTF-8 Unicode   utf8mb4_0900_ai_ci  4

这里我们会发现一个特殊的collate：utf8mb4_0900_ai_ci ，那这个0900表示什么了？原来utf8mb4_0900_ai_ci 是MySQL8新增的collate，中间的0900，表示的是Unicode 9.0的规范。对应的之前就有的utf8mb4_unicode_520_ci、utf8mb4_unicode_ci等。

• utf8mb4_0900_ai_ciis based on UCA 9.0.0 weight keys (http://www.unicode.org/Public/UCA/9.0.0/allkeys.txt).
• utf8mb4_unicode_520_ciis based on UCA 5.2.0 weight keys (http://www.unicode.org/Public/UCA/5.2.0/allkeys.txt).
• utf8mb4_unicode_ci(with no version named) is based on UCA 4.0.0 weight keys (http://www.unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt).

References:

1. https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-sets.html
2. https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html
3. https://zh.wikipedia.org/zh-hans/UTF-8
4. https://dev.mysql.com/doc/refman/8.0/en/charset-database.html
5. https://dev.mysql.com/doc/refman/8.0/en/charset-collation-names.html
6. https://www.lifesailor.me/archives/2676.html