#58 转载:正则表达式历史
开发者 正则表达式 2021-12-19正则表达式在我们日常的软件开发过程中被广泛使用,例如编写 Nginx 配置文件、在 Linux 与 macOS 下查找文件,然而不同软件不同操作系统对于正则的应用有着不一样的行为,主要原因是正则表达式演进过程中,出现 POSIX 与 PCRE 派系之分。
coding in a complicated world
正则表达式在我们日常的软件开发过程中被广泛使用,例如编写 Nginx 配置文件、在 Linux 与 macOS 下查找文件,然而不同软件不同操作系统对于正则的应用有着不一样的行为,主要原因是正则表达式演进过程中,出现 POSIX 与 PCRE 派系之分。
公众号四猿外的文章《这 10 个程序员的好习惯,让我变强了》,很有同感,这里总结一下:
Here is a command I use often while measuring why an HTTP request is taking too long:
curl -L -w "time_namelookup: %{time_namelookup}
time_connect: %{time_connect}
time_appconnect: %{time_appconnect}
time_pretransfer: %{time_pretransfer}
time_redirect: %{time_redirect}
time_starttransfer: %{time_starttransfer}
time_total: %{time_total}
" https://example.com/
Here is the same command written as a one-liner, so that I can copy it easily from this page with a triple-click whenever I need it in future:
curl -L -w "time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_appconnect: %{time_appconnect}\ntime_pretransfer: %{time_pretransfer}\ntime_redirect: %{time_redirect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" https://example.com/
Here is how the output of the above command typically looks:
$ curl -L -w "namelookup: %{time_namelookup}\nconnect: %{time_connect}\nappconnect: %{time_appconnect}\npretransfer: %{time_pretransfer}\nstarttransfer: %{time_starttransfer}\ntotal: %{time_total}\n" https://example.com/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
...
</html>
time_namelookup: 0.001403
time_connect: 0.245464
time_appconnect: 0.757656
time_pretransfer: 0.757823
time_redirect: 0.000000
time_starttransfer: 0.982111
time_total: 0.982326
In the output above, I have omitted most of the HTML output and replaced the omitted part with ellipsis for the sake of brevity.
The list below provides a description of each number in the output above. This information is picked straight from the manual page of curl 7.20.0. Here are the details:
time_namelookup: The time, in seconds, it took from the start until the name resolving was completed.time_connect: The time, in seconds, it took from the start until the TCP connect to the remote host (or proxy) was completed.time_appconnect: The time, in seconds, it took from the start until the SSL/SSH/etc connect/handshake to the remote host was completed. (Added in 7.19.0)time_pretransfer: The time, in seconds, it took from the start until the file transfer was just about to begin. This includes all pre-transfer commands and negotiations that are specific to the particular protocol(s) involved.time_redirect: The time, in seconds, it took for all redirection steps include name lookup, connect, pretransfer and transfer before the final transaction was started. time_redirect shows the complete execution time for multiple redirections. (Added in 7.12.3)time_starttransfer: The time, in seconds, it took from the start until the first byte was just about to be transferred. This includes time_pretransfer and also the time the server needed to calculate the result.time_total: The total time, in seconds, that the full operation lasted. The time will be displayed with millisecond resolution.An important thing worth noting here is that the difference in the numbers for time_appconnect and time_connect time tells us how much time is spent in SSL/TLS handshake. For a cleartext connection without SSL/TLS, this number is reported as zero. Here is an example output that demonstrates this:
$ curl -L -w "time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_appconnect: %{time_appconnect}\ntime_pretransfer: %{time_pretransfer}\ntime_redirect: %{time_redirect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" http://example.com/
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
...
</html>
time_namelookup: 0.001507
time_connect: 0.247032
time_appconnect: 0.000000
time_pretransfer: 0.247122
time_redirect: 0.000000
time_starttransfer: 0.512645
time_total: 0.512853
Also note that time_redirect is zero in both outputs above. That is because no redirection occurs while visiting example.com. Here is another example that shows how the output looks when a redirection occurs:
$ curl -L -w "time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_appconnect: %{time_appconnect}\ntime_pretransfer: %{time_pretransfer}\ntime_redirect: %{time_redirect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" https://susam.in/blog
<!DOCTYPE HTML>
<html>
...
</html>
time_namelookup: 0.001886
time_connect: 0.152445
time_appconnect: 0.465326
time_pretransfer: 0.465413
time_redirect: 0.614289
time_starttransfer: 0.763997
time_total: 0.765413
When faced with a potential latency issue in web services, this is often one of the first commands I run several times from multiple clients because the results form this command help to get a quick sense of the layer that might be responsible for the latency issue.
语言指包括语言的字符集以及有关的货币符号,日期格式等。为了区分不通的语言,人们设计了一些语言代码相关的标准来。
作为开发,只要涉及多语言,都一定会接触到语言代码。在各种不通的技术、语言框架中,这些代码并没有非常统一,比如简体中文,我见过 zh, zh_CN, zh-Hans, chs, zh_chs 几种不同的表示。
我没有做过移动端开发,我突然想到,如果我们要给手机端推送消息,会有些什么办法。
想来想去只有短信是最容易实现的,而且效果可以接受。
sudo apt install -y sqlitebrowser最近两周开发了一个功能,其实质就是做个数据统计,没啥好说的。
我是在没有产品设计的前提下开始工作,产品的设计反倒有一点依赖我所能提供的数据。
而且,和以往自己写功能逻辑不通的是,我这次只管提供数据和方案,业务逻辑的实现由别人来做。
工作过程中遇到了一些问题,这里做个总结(复盘)。

我的主力开发环境是大概 14 年 4 月在 DELL 官方 (dell.com) 买的一台 Inspiron 14R (5437) 笔记本。
PS: 这台笔记本原本是我老婆办公用, 用了将近五年之后, 于 2019 年 1 月在换了一台 小米 Air 13.3, 然后我就有笔记本了...到现在我也用了两年多了。
https://www.microsoft.com/zh-cn/windows/windows-11-specifications
其他:
CPU (1GHz,双核),内存 (4G),磁盘 (64G)
CPU, 内存, 磁盘方面的要求,主流的配置应该都能满足。
UEFI 安全启动
MS 官方工具只能给出一个是否的答复,太弱了(正在开发新的监测工具)。
社区有提供一个检测工具:WhyNotWin11.exe (GitHub 下载)
第一次检测:

除了 CPU 之外,其他几项都可以在 BIOS 中设置。
TPM:如果是 Intel 就找一下 Platform Trust Technology, AMD 可能是 fTPM。

我的 CPU 是六代 i5,这就真的没办法了,i5 的话,最低要求是八代 (完整的 CPU 要求清单:Windows 11 supported Intel processors。
抛弃才发布六年(2015/09)的六代 CPU 绝壁是一个愚蠢的决定,希望微软耗子喂汁!
根据微信公众号高效程序员文章《Win11 极限精简版发布:2G内存就能流畅运行!》中的信息,有人基于 Windows 11 Pro 22H2 打造了 Tiny11,不需要 TPM 和安全启动。

织梦官网放出上面这张公告:除了 “个人非盈利” 网站,其他没有拿到正式授权的织梦网站需要交 5800 授权费。
他们可能已经把清单列好了,律师团队也准备好了,正磨刀霍霍向着小站长们。
这可能就是中国特色开源协议的正确使用方式。
PS: 虽然我觉得 织梦CMS 是个垃圾,但我也不知道为啥,据说很多小站都是用的这个系统。