聊聊爬虫背后的技术

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

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

以chrome为例,可以查阅如下资料:

 

那么,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。

JavaScript(JS)、JSON和int64

大家在前后端联合开发时经常会遇到一个问题,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

Go中struct的内存对齐

直接看代码

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)

历史上已实行的闰秒日期
630 1231
1972 +1 +1
1973 0 +1
1974 0 +1
1975 0 +1
1976 0 +1
1977 0 +1
1978 0 +1
1979 0 +1
1980年 0 0
1981 +1 0
1982 +1 0
1983 +1 0
1984年 0 0
1985 +1 0
1986年 0 0
1987 0 +1
1988年 0 0
1989 0 +1
1990 0 +1
1991年 0 0
1992 +1 0
1993 +1 0
1994 +1 0
1995 0 +1
1996年 0 0
1997 +1 0
1998 0 +1
1999年 0 0
2000年 0 0
2001年 0 0
2002年 0 0
2003年 0 0
2004年 0 0
2005 0 +1
2006年 0 0
2007年 0 0
2008 0 +1
2009年 0 0
2010年 0 0
2011年 0 0
2012 +1 0
2013年 0 0
2014年 0 0
2015 +1 0
2016 0 +1
2017年 0 0
2018年 0 0
2019年 0 0
2020年 0 0
2021年 0 0
2022年 0
总计 11 16
27
目前TAIUTC秒差
37

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

TAI (1 January 1999) UTC (31 December 1998 to 1 January 1999) Unix time
1999-01-01T00:00:30.00 1998-12-31T23:59:59.00 915148799.00
1999-01-01T00:00:30.50 1998-12-31T23:59:59.50 915148799.50
1999-01-01T00:00:31.00 1998-12-31T23:59:60.00 915148800.00
1999-01-01T00:00:31.50 1998-12-31T23:59:60.50 915148800.50
1999-01-01T00:00:31.75 1998-12-31T23:59:60.75 915148800.75
1999-01-01T00:00:32.00 1999-01-01T00:00:00.00 915148800.00
1999-01-01T00:00:32.25 1999-01-01T00:00:00.25 915148800.25
1999-01-01T00:00:32.50 1999-01-01T00:00:00.50 915148800.50
1999-01-01T00:00:33.00 1999-01-01T00:00:01.00 915148801.00

可以看到,发生闰秒的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

MySQL的Character Set和collate

常见的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等。

 

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

 

聊聊WebSocket

  • WebSocket介绍

WebSocket是一种网络传输协议,可在单个TCP连接上进行全双工通信,位于OSI模型的应用层。WebSocket协议在2011年由IETF标准化为RFC 6455,后由RFC 7936补充规范。
WebSocket使得客户端和服务器之间的数据交换变得更加简单,允许服务端主动向客户端推送数据。在WebSocket API中,浏览器和服务器只需要完成一次握手,两者之间就可以创建持久性的连接,并进行双向数据传输。

  • HTTP和WebSocket之间的异同点。

WebSocket是一种与HTTP不同的协议。两者都位于OSI模型的应用层,并且都依赖于传输层的TCP协议。 虽然它们不同,但是RFC 6455中规定:it is designed to work over HTTP ports 80 and 443 as well as to support HTTP proxies and intermediaries(WebSocket通过HTTP端口80和443进行工作,并支持HTTP代理和中介)。 为了实现兼容性,WebSocket握手使用HTTP Upgrade头从HTTP协议更改为WebSocket协议。
与HTTP不同,WebSocket提供全双工通信。
WebSockets URI的格式如下:

ws-URI = “ws:” “//” host [ “:” port ] path [ “?” query ]
wss-URI = “wss:” “//” host [ “:” port ] path [ “?” query ]

ws和wss分别对应明文和加密连接(对比HTTP和HTTPS)。

  • WebSocket实战

因为WebSocket被设计为和HTTP/HTTPS一起工作在80/443端口并且支持HTTP代理和网关,所以一个服务端程序同时接收HTTP和WebSocket请求。对,没错,一个Server端程序可以同时接收HTTP请求和WebSocket请求。

Demo如下:

//处理普通的HTTP请求
http.HandleFunc("/hello", func(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte("Hello, world!"))
})
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
    http.ServeFile(w, r, "index.html") 
})
http.HandleFunc("/ws/chat", func(w http.ResponseWriter, r *http.Request) {
    //这里写一个读取cookie的实例是告诉大家,在处理WebSocket的handshake请求时,服务端是可以读到该域名下的cookie的,具体细节和HTTP协议规范一致。 
    cookie, err := r.Cookie("key")
    if err != nil {
        fmt.Println(err)
    } else {
        fmt.Println("cookie:" + cookie.String())
    }
    //使用github.com/gorilla/websocket 
    conn, err := upgrader.Upgrade(w, r, nil)
    if err != nil {
        fmt.Println(err)
        return
    }
    //... 
    //此处conn就是一个websocket连接了,服务端可以通过conn来发送消息给客户端 
})

仔细一想,你就会明白。客户端发起ws请求,第一次握手(handshake)的请求和正常的HTTP请求体的格式是遵循的同一个规范——RFC2616。所以WebSocket的第一次握手请求正好被设计为要求和正常的HTTP请求体一样,这样就解答了为什么在一个普通的HTTP Server程序只监听一个端口的情况下可以同时处理HTTP请求和WebSocket请求了。同时也请注意对客户端而言,是建立了两个连接:一个HTTP连接,一个WebSocket连接。

如果你还是不明白,那么我换另外一种说法:

客户端发起了一个请求,可能是HTTP请求也可能是WebSocket,但是他们的请求体格式是一样的。服务端可以事先和客户端约定,根据path路径区分来源,进而决定哪一个是当HTTP请求处理:返回正常HTTP Response,哪一个当WebSocket请求处理:返回Upgrade,继而持有连接实现双向通信。

摘抄部分RFC内容如下:

The handshake MUST be a valid HTTP request as specified by [RFC2616].
The method of the request MUST be GET, and the HTTP version MUST be at least 1.1.
For example, if the WebSocket URI is “ws://example.com/chat”, the first line sent should be “GET /chat HTTP/1.1”.

 

References:

https://datatracker.ietf.org/doc/rfc6455

https://zh.wikipedia.org/wiki/WebSocket

https://developer.mozilla.org/zh-CN/docs/Web/API/WebSockets_API/Writing_WebSocket_servers

 

无法比较的两个概念:JWT和Session

这两个概念单独解释其实很简单,但是混在一起可能会说不清。正好看到网上有人聊起了这个,我就做个整理,也当知识回顾。

问题:为什么要用 jwt token 来做身份认证,而不是使用session+cookie方式?

那么我们先看概念本身的解释:

JWT ——JSON Web Token

JWE——JSON Web Encryption

JWS——JSON Web Signature

Session,此处可以翻译为会话,指客户端和服务端维持有状态的一种通信机制。根据Session Data的存储位置,可以分为Server Side Session和 Client Side Session。一般说的session & cookie机制是指使用的Server Side Session。

所以JWT和Session不是同一个概念的东西,没法拿来比较。回头再看这个问题就发现有点意思了。我们使用jwt token来做身份认证,我们可以把jwt token(会含有一些用户信息)通过cookie、HTTP头,url参数等多种方式下发给客户端(Client Side Session)从而实现session机制;而传统的服务端session-data + session-id(by cookie)方式,session-id只是一串随机字符串,不用解析,在和服务端交互时直接原样传输就行了。所以原作者问题可能是Server Side Session和Client Side Session的区别!

References:

https://en.wikipedia.org/wiki/JSON_Web_Token

https://blog.by24.cn/archives/about-session.html

https://www.v2ex.com/t/774127

1MB=1024KB? 1000KB?

如题,这个问题第一感觉是1MB肯定等于1024KB,只有在硬盘生产厂商那里才会使用1000进制。事实是如此吗?最近被人补了一课,了解单位换算中的两种标准。

按照国际单位制的标准: 1MB=1000KB (1Megabyte = 1000Kilobyte)
按照IEC 60027-2标准: 1MiB=1024KiB (1Mebibyte = 1024 Kibibyte)

字节的次方单位
十进制前缀
(SI)
名字 缩写 次方
Kilobyte KB 103
Megabyte MB 106
Gigabyte GB 109
Terabyte TB 1012
Petabyte PB 1015
Exabyte EB 1018
Zettabyte ZB 1021
Yottabyte YB 1024
二进制前缀
(IEC 60027-2)
名字 缩写 次方
Kibibyte KiB 210
Mebibyte MiB 220
Gibibyte GiB 230
Tebibyte TiB 240
Pebibyte PiB 250
Exbibyte EiB 260
Zebibyte ZiB 270
Yobibyte YiB 280

所以严格来说如果显示为1MB,则说明使用的是国际单位制标准,等于1000KB。1MiB说明是使用的IEC 60027-2标准,等于1024KiB。

  • 但是注意,Microsoft Windows系统中仍在大量使用公制前缀的二进制写法(比如显示为1MB的文件,按理说应该是使用的SI标准,等于1000KB,但是实际windows却按IEC 60027-2标准来处理的,实际文件大小是1024KB)。
  • Mac OS X自Snow Leopard(v10.6)发行以来,文件大小均是以十进制前缀记录的(比如显示为14KB,87.1MB)。(但是在shell环境里,部分软件使用的M,K等标识符表示1024进制,比如ls;但是df命令使用的是Gi,Mi等SI单位制的符号)

 

References:

https://zh.wikipedia.org/wiki/国际单位制

https://zh.wikipedia.org/wiki/千字节

Go to WebAssembly

什么是WebAssembly?

WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.

让我们用tinygo来写一个WebAssembly的模块,然后用js调用吧。首先下载TINYGO:(https://tinygo.org/,请下载对应版本的二进制文件)。然后将bin/tinygo(or tinygo.exe)加入到PATH路径。

然后先创建一个main.go文件(文件名必须是main.go,因为js里有用到文件名),文件内容如下:

package main

// This calls a JS function from Go.
func main() {
    println("Go: Hello World") // expecting 5
    println("Go: add(2+3):", add(2, 3)) // expecting 5
    println("Go: multiply(2*3):", multiply(2, 3)) // expecting 6
}

// This function is imported from JavaScript, as it doesn't define a body.
// You should define a function named 'main.add' in the WebAssembly 'env'
// module from JavaScript.
func add(x, y int) int

// This function is exported to JavaScript, so can be called using
// exports.multiply() in JavaScript.
//go:export multiply
func multiply(x, y int) int {
    return x * y;
}

然后用tinygo编译这个go文件,生成wasm文件。

目前最新版的tinygo0.12.0,最高只支持golang 1.13(目前最新版本的golang1.14),编译的命令中文件名必须是main.go,不能写”./main.go”

tinygo build -o wasm.wasm -target wasm main.go

Error:  tinygo build -o wasm.wasm -target wasm ./main.go

 

然后用go写一个简单的文件服务器(用于启动http服务器,因为wasm加载必须在http/https的环境下),注意对于wasm文件,要设置Content-Type为application/wasm

package main

import (
    "log"
    "net/http"
    "strings"
)

const dir = "./html"

func main() {
    fs := http.FileServer(http.Dir(dir))
    log.Print("Serving " + dir + " on http://localhost:8080")
    http.ListenAndServe(":8080", http.HandlerFunc(func(resp http.ResponseWriter, req *http.Request) {
        resp.Header().Add("Cache-Control", "no-cache")
        if strings.HasSuffix(req.URL.Path, ".wasm") {
            resp.Header().Set("Content-Type", "application/wasm")
        }
        fs.ServeHTTP(resp, req)
    }))}

然后在服务器目录下创建html目录,目录里新建index.html文件(注意js代码中设置env的代码):

<html>
<head>
    <title>WebAssembly</title>
</head>
<body>
<script src="wasm_exec.js"></script>
<script type="text/javascript">
    const go = new Go(); // Defined in wasm_exec.js
    const WASM_URL = 'wasm.wasm';
    go.importObject.env['main.go.add'] = function (x, y) {
        return x + y
    };
    var wasm;

    console.log("'instantiateStreaming' in WebAssembly => " + ('instantiateStreaming' in WebAssembly ? "Y" : "N"));
    if ('instantiateStreaming' in WebAssembly) {
        WebAssembly.instantiateStreaming(fetch(WASM_URL), go.importObject).then(function (obj) {
            wasm = obj.instance;
            go.run(wasm);
            console.log('JS: multiplied two numbers:', wasm.exports.multiply(5, 3));
        }).catch((err) => {
            console.error(err);
        });
    } else {
        fetch(WASM_URL).then(resp =>
            resp.arrayBuffer()
        ).then(bytes =>
            WebAssembly.instantiate(bytes, go.importObject).then(function (obj) {
                wasm = obj.instance;
                go.run(wasm);
            })
        )
    }

</script>
</body>
</html>

index.html里面引用的wasm_exec.js文件就在tinygo下载包里,wasm.wasm就是我们刚刚编译生成的文件。

浏览器里打开这个网页 http://localhost:8080/index.html,发现控制台就能输出:

23:25:58.955 ‘instantiateStreaming’ in WebAssembly => Y

23:25:58.964 Go: Hello World

23:25:58.964 Go: add(2+3): 5

23:25:58.964 Go: multiply(2*3): 6

23:25:58.964 JS: multiplied two numbers: 15

23:25:58.966 Fetch finished loading: GET “http://localhost:8080/wasm.wasm”.

References:

https://webassembly.org/

https://tinygo.org/

 

一个关于PHP正则匹配汉字的问题

起因是一个网友提了一个问题:

$pattern='/^\w+$/';
$str="人1994";
$ret = preg_match($pattern, $str, $matches);

他想着\w是应该能够匹配到中文字符“人”的,但是实际执行结果却是不能匹配。网友们给了各种解释和解决方案,总结下来有两个可行方案:

  1. 使用/u模式修饰符[1]
  2. 在pattern中使用unicode编码表示两种方案可以解决如上问题。

代码及输出如下:

<?php


$pattern='/^\w+$/';


$str="人1994";


$ret = preg_match($pattern, $str, $matches);


var_dump($ret);


var_dump($matches);





$pattern='/^\w+$/u';


$str="人1994";


$ret = preg_match($pattern, $str, $matches);


var_dump($ret);


var_dump($matches);





//From PHP 7.0


$pattern='/^\w+$/u';


$str="\u{4eba}1994";//人 =>  \u4eba


$ret = preg_match($pattern, $str, $matches);


var_dump($ret);


var_dump($matches);








Output for hhvm-3.18.5 - 3.22.0, 7.1.0 - 7.2.4


int(0)


array(0) {


}





int(1)


array(1) {


[0]=>


string(7) "人1994"


}





int(1)


array(1) {


[0]=>


string(7) "人1994"


}








Output for 5.6.0 - 5.6.30


int(0)


array(0) {


}





int(1)


array(1) {


[0]=>


string(7) "人1994"


}





int(0)


array(0) {


}





注意:第三个例子中的语法从PHP 7.0开始支持。[2] [3]

还有一个网友提出了一个观点[4]

这个不是 PHP 的锅,而是 PCRE 库的配置导致,\w 的匹配官方文档是这么说的 

A “word” character is any letter or digit or the underscore character, that is, any character which can be part of a Perl “word”. The definition of letters and digits is controlled by PCRE’s character tables, and may vary if locale-specific matching is taking place. For example, in the “fr” (French) locale, some character codes greater than 128 are used for accented letters, and these are matched by \w.

也就是说, PCRE 库的 character tables 配置会影响到\w 的匹配

目前没有验证TA所说的是否正确。

 

目前来看最好的方式就在在写pattern时使用模式修饰符/u。

 

References:

[1]https://secure.php.net/manual/zh/reference.pcre.pattern.modifiers.php

 

[2] PHP 7.0 has introduced the “Unicode codepoint escape” syntax.

https://secure.php.net/manual/en/migration70.new-features.php#migration70.new-features.unicode-codepoint-escape-syntax

 

[3] To support large Unicode ranges (ie: [\x{E000}-\x{FFFD}] or \x{10FFFFF}) you must use the modifier ‘/u’ at the end of your expression.

https://secure.php.net/manual/en/function.preg-match.php#90771

 

[4] https://www.v2ex.com/t/262150

https://stackoverflow.com/questions/1330693/validate-username-as-alphanumeric-with-underscores