#64 数据序列化格式

开发者 2022-04-14

文本类型

最常见的文本类型数据序列化格式要数 JSON 和 XML 了。

早年间，知名的 RPC 规范 SOAP，XML-RPC 就是定义在 XML 的基础之上。
后来，随着 Web 的流行，JSON 使用得越来越多，基于 JSON 的 RPC 也开始出现。
但是最后 RPC 整体衰弱下来，终究没有抵过 HTTP API 的趋势。大部分 HTTP API 都是基于 JSON，少部分基于 XML。

苹果公司的 plist (Property list) 格式也是基于 XML。

除了 JSON 和 XML 之外，其他常见的文本类型数据序列化格式还有：CSV，YAML。

二进制类型

  1. ASN.1 参考 2020/01/31, ASN.1。

  2. D-BUS

  3. 三种语言相关的序列化格式：

  4. Java Object Serialization

  5. Python Pickle

  6. PHP serialization format

  7. Mongo 引入的 BSON，二进制 JSON。类似的格式（JSON 二进制化）还有：

  8. Binn

  9. CBOR (rfc8949)
  10. Amazon Ion
  11. msgpack
  12. Smile

  13. ubjson。

  14. 也有一些 XML 二进制化的格式(Binary XML)，比如：

  15. W3C 推荐的 Efficient XML Interchange (EXI)

  16. ISO 标准 Fast Infoset。

  17. Apache 基金会的 Avro 和 Parquet。

  18. 近些年，随着微服务的流行，RPC 重新席卷而来。一般都是采用二进制的数据格式。
    二进制的编码效率更高，可视化（转换成文本）的问题可以通过网关来提供。

Google 公司的 Protocol Buffers (protobuf) 和 FlatBuffers
Apache Thrift 也有自己独创的序列化格式（同名）。

#63 ABNF 语法

开发者 2022-04-07

BNF，Backus-Naur Form，或者 Backus Normal Form，巴科斯范式
用来准确地描述一种计算机语言的语法规则，所以可以理解成是 “语言的语言”。

约翰·巴科斯（美国）首次在 ALGOL 58 中实现巴科斯范式。彼得·诺尔（丹麦）在 ALGOL 60 之中，进一步发展它的概念并将它的符号加以简化，称其为巴科斯范式（Backus Normal Form）。但高德纳主张应称为巴科斯-诺尔范式（Backus–Naur Form），因为它不算是一种正规形式（Normal Form）。

BNF 有两种常见变体：

  • ABNF，扩充巴科斯范式
  • EBNF，扩展巴科斯范式

不用深究 BNF，EBNF，ABNF，或者什么 xBNF 之间到底有什么区别，在需要开发语法解析器之前，只用知道这些是现在最主流的语法语言就行了。

这篇文章讨论的就是 Internet 领域常用的 ABNF。

（ABNF）它是由第68号互联网标准定义的，也就是RFC 5234，经常用于互联网工程任务组（IETF）通信协议的定义语言。

规则

ABNF 语法描述就是一组规则，每个规则分成规则名称、规则说明两部分。
PS：规则说明可以引用其他的规则。

拿 RFC#822 Internet Message Format 中的例子：

date-time       =       [ day-of-week "," ] date FWS time [CFWS]

day-of-week     =       ([FWS] day-name) / obs-day-of-week

day-name        =       "Mon" / "Tue" / "Wed" / "Thu" /
                        "Fri" / "Sat" / "Sun"

date            =       day month year

PS：这里只是截取的部分，没有列出来的规则在别处声明。

参考资料与拓展阅读

#62 解释解释什么叫 “包容性命名”

开发者 英语 2022-04-02

开发者想必都有耳闻，过去一两年间，因为一些美国政治风波的影响，各大社区都被政治正确问题所困扰，然后有一些相关改名的操作。
PS: 连黑人牙膏（高露洁旗下）都改名 “好来牙膏” 了。

最著名的可能就是 GitHub 中的默认主干分支从 master 改成 main，然后很多项目宣布将主从表述由 master/slave 改成 primary/replica，黑名单 Blacklist 改叫 Denylist 或者 Blocklist。

我最近听说有个叫包容性命名促进会的组织（Inclusive Naming Initiative）。
https://inclusivenaming.org/

他们列了一个清单，将开发过程中常用的一些有冒犯性的词，按照冒犯级别分三类，然后还给出来一些他们建议的替换词。

#61 2022 BUG

开发者 千年虫 2022-01-28

前些天应该都看过微软 Exchange Server 开发者跨年改 BUG 的新闻了吧 (相关链接)。

Exchange Server 的邮件过滤器采用了 yymmddHHMM 格式的时间，存储在 long 类型字段中。
PS: 微软的 C++ Compiler 会将 long 当做 32 位 int。

32 位有符号整形能够表达的范围：[$-2^{31}$, $2^{31} - 1$]，也就是 [-2147483648, 2147483647]。

到了 2022 年，就会超出范围，比如 2022-01-01 12:00:00, 会被存储为 2201011200，会超出 signed int 的表达范围。

2147483647
2201011200 # 超出

可能有一些系统采用 int 类型存储 yymmdd + 4 位数字做编号的方式，比如 2101011234。
相同的原因，到了 2022 年，就行不通了。

2147483647
2201011234 # 超出

最好的办法是改成 long long, 或者 unsigned int。

PS: Linux 下的 C/C++ 编译器——GCC、CLang/LLVM 都是将 long 当做是 64 位。

参考资料与拓展阅读

#60 西安一码通的“优化”

开发者 二维码 COVID19 西安 2022-01-07

西安一码通半个月内两次宕机，值此西安疫情突发之时，可是严重的安全故障。相关负责人（西安大数据资源管理局局长）已经停职检查。

为确保系统运行更高效，他们将一张图片从1MB压缩到500KB，再从500KB优化到100KB。这样的工作看似简单，却蕴含着高技术含量，他们连续两天两夜守在电脑前，终于攻下难关。

#59 对个人职业生涯的一点展望

个人 开发者 2022-01-02

维持之前的设定，走技术专家的路线。

  1. 能处理工作中的难点问题，需要对业务有全局性的认识
  2. 对技术有深刻的理解，尤其是基础技术一定要扎实
  3. 方案设计能力：1. 对产品更多思考 2. 架构能力 3. 编码规范 4. 了解产品测试和运维
  4. 良好的沟通能力，培养个人影响力

第一点，今年会得到改进。
第二点，需要更长时间周期的投入才能见效。
第三点，比较泛，需要更多思考。
第四点，可能是最难的。我不知道该怎么做。

#58 转载：免费的编程书籍

阅读 开发者 2021-12-30

语言无关

版本控制

编程艺术

编辑器

编译原理

操作系统

程序员杂谈

大数据

分布式系统

管理和监控

函数式概念

计算机图形学

其它

软件开发方法

设计模式

数据库

项目相关

在线教育

正则表达式

智能系统

IDE

Web

WEB 服务器

语言相关

Android

Assembly

AWK

C

C Sharp

C++

CoffeeScript

Dart

Elasticsearch

Elixir

Erlang

Fortran

Golang

Groovy

Haskell

HTML / CSS

iOS

Java

JavaScript

AngularJS

:information_source: See also … Angular

Backbone.js

D3.js

Electron.js

ExtJS

impress.js

jQuery

Node.js

React.js

Vue.js

Zepto.js

LaTeX

LISP

Lua

Markdown

MySQL

NoSQL

Perl

PHP

Laravel

Symfony

PostgreSQL

Python

Django

R

reStructuredText

Ruby

Rust

Scala

Scheme

Scratch

Shell

Swift

TypeScript

Angular

:information_source: See also … AngularJS

Deno

VBA (Microsoft Visual Basic Applications)

Vim

Visual Prolog

#57 转载：正则表达式历史

开发者 正则表达式 2021-12-19

正则表达式在我们日常的软件开发过程中被广泛使用，例如编写 Nginx 配置文件、在 Linux 与 macOS 下查找文件，然而不同软件不同操作系统对于正则的应用有着不一样的行为，主要原因是正则表达式演进过程中，出现 POSIX 与 PCRE 派系之分。

#56 程序员的 10 个习惯

开发者 2021-12-08

公众号四猿外的文章《这 10 个程序员的好习惯，让我变强了》，很有同感，这里总结一下：

  1. 要看官方文档，网上的资料鱼龙混杂
  2. 开发者的可靠性：自测没有问题了再交付
  3. 日志设计合理，保证调试时，有恰当的信息来定位问题
  4. 精通 Git
  5. 优先功能实现，别急着优化
    过早优化是魔鬼，应该根据实际运行的情况来优化
  6. 先做明确的需求，不确定或者模糊的需求先往后放
  7. 积极主动：发现问题，提出方案，解决问题
  8. 开发时间评估，保证有冗余时间，以处理可能的意外
  9. 学习编程主要靠上手写代码，不要光看文档
  10. 英语。不需要很好，能看懂英文文档就行

#55 Susam Pal：Curl 计时

开发者 Curl 2021-11-28

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.