Skip to content

Commit fabe325

Browse files
JuemurenJuemuren
committed
2026-1-13
1 parent 2bd10bd commit fabe325

5 files changed

Lines changed: 141 additions & 82 deletions

File tree

‎docs/数据处理工具/SQLite.md‎

Lines changed: 46 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -6,12 +6,18 @@ SQLite 是一个轻量级的关系型数据库，适合在作为命令行工具
66

77
## 对比
88

9-
相比于那些 `C-S` 架构的数据库，SQLite 有很多不同的地方
9+
相比于那些 **客户端 - 服务端** 架构的数据库，SQLite 有很多不同的地方
1010

1111
- 单文件存储。整个数据库内容都存储在一个文件中
1212
- 零配置。不需要安装、配置数据库服务器，单个程序/库就可以直接使用
1313
- 访问快。直接访问本地文件，不需要进程间通信/网络通信
1414

15+
`DuckDB` 和 SQLite 有着相同的架构，主要区别是
16+
17+
- SQLite 是 **OLTP（在线事务处理）** 数据库，适合需要高频写入的事务处理场景；而 DuckDB 是 **OLAP（在线分析处理）** 数据库，适合需要数据分析和复杂查询的场景
18+
- SQLite 是 **行式存储**，而 DuckDB 是 **列式存储**
19+
- SQLite 生态成熟，而 DuckDB 生态还比较新
20+
1521
## 安装
1622

1723
SQLite 作为命令行工具，可以通过系统包管理器安装
@@ -198,22 +204,15 @@ CREATE TABLE IF NOT EXISTS chips (
198204

199205
- 游戏内的副本可能掉落两种芯片，并且这两种芯片之间可以互相转换，因此需要分组进行查询
200206
- 游戏中干员精一需要 5 个小芯片，精二需要 8 个大芯片，因此需要筛选出紧缺的芯片
201-
- 输出降序只是为了方便查看
202207

203208
```sql
204-
-- 查询小芯片统计
209+
-- 查询小芯片
205210
SELECT *
206211
FROM chips
207212
WHERE 芯片类型 = '小'
208213
ORDER BY 数量 DESC;
209214

210-
-- 查询大芯片统计
211-
SELECT *
212-
FROM chips
213-
WHERE 芯片类型 = '大'
214-
ORDER BY 数量 DESC;
215-
216-
-- 查询小芯片合并统计
215+
-- 查询合并的小芯片
217216
SELECT
218217
CASE
219218
WHEN 职业 IN ('先锋', '辅助') THEN '先锋 + 辅助'
@@ -228,33 +227,17 @@ WHERE 芯片类型 = '小'
228227
GROUP BY 组合
229228
ORDER BY 总数 DESC;
230229

231-
-- 查询大芯片合并统计
232-
SELECT
233-
CASE
234-
WHEN 职业 IN ('先锋', '辅助') THEN '先锋 + 辅助'
235-
WHEN 职业 IN ('狙击', '术士') THEN '狙击 + 术士'
236-
WHEN 职业 IN ('近卫', '特种') THEN '近卫 + 特种'
237-
WHEN 职业 IN ('重装', '医疗') THEN '重装 + 医疗'
238-
END AS 组合,
239-
芯片类型,
240-
SUM(数量) AS 总数
241-
FROM chips
242-
WHERE 芯片类型 = '大'
243-
GROUP BY 组合
244-
ORDER BY 总数 DESC;
245-
246230
-- 查询紧缺的小芯片
247231
SELECT *
248232
FROM chips
249233
WHERE
250234
芯片类型 = '小' AND 数量 < 5
251235
ORDER BY 数量 DESC;
252236

253-
-- 查询紧缺的大芯片
237+
-- 对大芯片的查询是类似的
254238
SELECT *
255239
FROM chips
256-
WHERE
257-
芯片类型 = '大' AND 数量 < 8
240+
WHERE 芯片类型 = '大'
258241
ORDER BY 数量 DESC;
259242
```
260243

@@ -314,3 +297,38 @@ update job type increment:
314297
sqlite3 "{{DB}}" "UPDATE chips SET 数量 = 数量 {{increment}} WHERE 职业 = '{{job}}' AND 芯片类型 = '{{type}}'"
315298
sqlite3 "{{DB}}" "SELECT * FROM chips WHERE 职业 = '{{job}}' AND 芯片类型 = '{{type}}'"
316299
```
300+
301+
---
302+
303+
不过对于上述场景，使用 DuckDB 可能更合适。毕竟这里没有高频写入，只需要处理复杂查询，而 DuckDB 就是为数据分析设计的。
304+
305+
Duck 可以根据 CSV 文件自动创建表，因此导入和查询 CSV 文件都非常简单
306+
307+
```sql
308+
-- 查询所有芯片
309+
SELECT * FROM chips.csv;
310+
```
311+
312+
写成一行的脚本就是
313+
314+
```sh
315+
duckdb -c "SELECT * FROM chips.csv"
316+
```
317+
318+
或者也可以
319+
320+
```sh
321+
duckdb chips.csv -c "SELECT * FROM file"
322+
```
323+
324+
如果使用后一种方法，那么可以把所有查询逻辑保存在一个 SQL 文件里，然后对不同的 CSV 文件应用相同的查询逻辑
325+
326+
比如一下内容保存为 `small_query.sql`，然后可以使用 `duckdb chips.csv -f small_query.sql` 进行查询
327+
328+
```sql
329+
-- 查询小芯片
330+
SELECT *
331+
FROM file
332+
WHERE 芯片类型 = '小'
333+
ORDER BY 数量 DESC;
334+
```

‎docs/数据处理工具/index.md‎

Lines changed: 20 additions & 24 deletions
Original file line numberDiff line numberDiff line change
@@ -10,54 +10,50 @@
1010

1111
### 嵌套型数据
1212

13-
| 需求 | 适合格式 | 原因 |
14-
| :------------- | :-------- | :---------------- |
15-
| **人工编写** | YAML/TOML | 可读性强/支持注释 |
16-
| **浅层嵌套** | TOML | 使用路径 |
17-
| **深层嵌套** | YAML | 使用缩进 |
18-
| **机器处理** | JSON | 解析快速/广泛支持 |
19-
| **数据传输** | JSON | JavaScript 原生 |
20-
| **文档型数据** | XML | 命名空间/属性信息 |
13+
| 特性 | JSON | YAML | TOML | XML |
14+
| :----------- | :--- | :--- | :--- | :--- |
15+
| **人类读写** | 较难 | 最易 | 较易 | 最难 |
16+
| **解析速度** | 最快 | 最慢 | 较快 | 较慢 |
2117

2218
#### JSON
2319

2420
JSON 全称为 `JavaScript 对象表示法`。顾名思义，JavaScript 就使用这种格式表示对象，因此 JavaScript 序列化和反序列化 JSON 都非常方便。
2521

26-
JSON 是机器友好的，因此解析起来特别快速。但 JSON 不是人类友好的，文件中充斥着 `{}[]()",` 这些符号，非常影响阅读和修改。
22+
JSON 是机器友好的，因此解析起来特别快速。但 JSON 不是人类友好的，文件中充斥着各种定界符和分隔符，非常影响阅读和修改。
2723

2824
JSON 经常会在和 JavaScript 有关的场合被用到，比如通过 HTTP 传输的数据、VSCode 的配置文件等。
2925

3026
#### YAML
3127

32-
YAML 很类似 JSON，但为了便于人类读写而做了很多优化。
28+
YAML 很类似 JSON，但为便于人类读写而进行了许多优化，比如使用缩进取代了定界符。
3329

34-
YAML 是人类友好的，使用缩进和约定消除了 JSON 中的那些冗余符号，且原生支持注释。但这也导致它不是机器友好的，解析起来比 JSON 更慢一点。
30+
YAML 是人类友好的，内容紧凑且有许多实用的语法特性，比如注释。但这也导致它的解析速度比 JSON 慢很多。
3531

36-
YAML 常被用于配置文件，比如 Docker/Kubernetes/GitHub Actions 等都选择了 YAML。
32+
YAML 常被用于配置文件，*Docker*/*Kubernetes*/*GitHub Actions* 等都选择了 YAML。
3733

3834
#### TOML
3935

40-
TOML 算是 INI 的升级版，同样使用键值对并支持分节，不过 TOML 还允许嵌套的组织结构。
36+
TOML 算是 INI 的升级版。TOML 使用键值对，并通过分节和点路径扁平化了树状结构。
4137

42-
TOML 是人类友好的，不过更适用于扁平的结构，那种非常深的嵌套 TOML 写起来要比 JSON/YAML/XML 麻烦许多。
38+
TOML 是人类友好的，不过对于非常深的嵌套，可能不如 JSON/YAML/XML 直观。
4339

44-
TOML 被一些新兴语言用作项目配置文件，比如 Rust 和 Julia。TOML 现在随着新兴工具的流行而越来越常见，Python 社区也逐渐接受了使用 TOML 作为项目配置文件。
40+
TOML 被一些新兴语言用作项目配置文件，比如 Rust 和 Julia，而 Python 社区也逐渐接受了 TOML。
4541

4642
#### XML
4743

48-
XML 全称为 `可拓展标记语言`，使用标签来组织数据和结构，并且标签可以嵌套和附加属性。
44+
XML 全称为 `可拓展标记语言`，使用闭合标签和附加属性构成元素，通过嵌套元素来表示层次结构。
4945

50-
XML 是机器友好的，适合深度嵌套和需要属性信息、命名空间的数据。
46+
XML 不是人类友好的，且由于其特性较多，解析器实现困难，解析速度慢，因此也很难算是机器友好。
5147

52-
XML 早期在 Web 中常用于传输数据，不过目前已几乎被 JSON 取代。另外 XML 还被很多软件选为内部格式，比如 Microsoft Office 的那些文档（包括 docx/xlsx/pptx）解压后其实就是一些包含了 XML 的文件、VLC 的皮肤文件解压后也包含了 XML 文件、SimulIDE 的电路图实际保存为一个 XML 文件。
48+
XML 早期在 Web 中常用于传输数据，不过目前已几乎被 JSON 取代。现在 XML 更常用作软件的内部格式，比如 Microsoft Office 的 DOCX/PPTX/XLSX 格式解压后其实就是一些包含了 XML 的文件。
5349

5450
### 表格型数据
5551

56-
| 特性 | CSV | TSV |
57-
| :----------- | :----------- | :----------- |
58-
| **转义需求** | 经常需要转义 | 很少需要转义 |
59-
| **可读性** | 通常对不齐 | 对得更整齐 |
60-
| **通用性** | 更常见 | 更不常见 |
52+
| 特性 | CSV | TSV |
53+
| :--------- | :----- | :----- |
54+
| **分隔符** | 逗号 | 制表符 |
55+
| **可读性** | 一般 | 更好 |
56+
| **通用性** | 更常见 | 不常见 |
6157

6258
#### CSV
6359

@@ -69,7 +65,7 @@ CSV 在电子表格、数据库导入/导出、数据科学等领域中很常见
6965

7066
TSV 全称为 `制表符分隔值`。顾名思义，TSV 通过制表符隔开每个值。
7167

72-
TSV 相比 CSV 通常解析更快，且制表符相对而言更少需要转义，也更容易在编辑器中对齐，从而易于人工编辑。
68+
TSV 相比 CSV 更易于人工编辑，因为制表符不常出现在数据中，因此很少需要转义，且制表符更容易在编辑器中对齐。
7369

7470
## 工具
7571

‎docs/文档工具/index.md‎

Lines changed: 55 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -8,14 +8,17 @@
88

99
## 格式
1010

11-
### 纯文本
11+
### 文本文档
1212

13-
纯文本指文档将所有内容以文本形式进行存储。这种方式有一些很明显的好处
13+
文本文档指所有内容都以文本形式进行存储的文档。这种方式有一些很明显的好处
1414

1515
- 通用，可以在任何有文本编辑器的设备上对其进行修改和查看
1616
- 版本控制友好，Git 的 diff/merge 等功能都可以正常使用
1717

18-
对于图片、视频、字体等资源，可以通过文件引用的方式将其包含在文档中
18+
文本文档本身可以看作一种语言，它们有不同的类型，比如
19+
20+
- 标记语言。这种语言可以标记文档的结构、内容，以及基本的样式/格式，典型例子是 Markdown/HTML
21+
- 排版语言。这种语言不仅可以标记文档，还可以对其进行排版，甚至有函数、变量等编程特性，典型例子是 LaTeX/Typst
1922

2023
#### Markdown
2124

@@ -32,9 +35,17 @@ Markdown 是一种标记语言，可理解为语法更简单的 **HTML**，因
3235
- 没有统一的标准。Github、Obsidian、Pandoc 等都有自己拓展的 Markdown 语法。如果过度依赖某个专有的特性，那么文档迁移会有点麻烦。
3336
- 排版和样式的功能欠缺。这导致 Markdown 转换为 PDF 会比较麻烦，通常要借助别的格式。
3437

38+
#### HTML
39+
40+
HTML 全称为 `超文本标记语言`。HTML 相比 PDF 更注重内容和样式而不是排版，因此不适合对排版有严格要求的场合。
41+
42+
HTML 使用基于 XML 的语法，并且可以嵌入或引用 CSS/JavaScript。浏览器能够渲染 HTML、解析 CSS、运行 JavaScript。JavaScript 使得 HTML 可以交互，因此 HTML 不仅是一个文档，更是一个应用。
43+
44+
HTML 可以直接用文本编辑器编辑，也可以通过 Markdown 等格式转换而来。HTML 是 Web 应用的核心，有很多框架可以快速制作 Web 应用，可阅读 [Web 开发](../应用开发/Web.md) 章节了解更多。
45+
3546
#### LaTeX
3647

37-
LaTeX 是一个强大的写作排版系统，和 Markdown 一样直接以文本形式存储，但相比 Markdown 有一些显著的区别
48+
LaTeX 是一个强大的写作排版系统，其相比 Markdown 有一些显著的区别
3849

3950
- 语法更复杂。Markdown 使用直观简洁的符号，而 LaTeX 使用冗长的命令，学习曲线很陡峭
4051
- 排版功能更好。Markdown 事实上并没有排版功能，而 LaTeX 则是排版领域的顶点
@@ -76,26 +87,18 @@ Typst 类似 LaTeX，不过针对 LaTeX 的许多问题进行了改进。个人
7687

7788
当然，Typst 也有一些缺点，这些缺点主要是因为 Typst 太年轻。LaTeX 有丰富的模板，无数的宏包，到处都是教程和指南，出版社、期刊等接受度也更高。不过我还是希望 Typst 能够成功，让写作排版多一个选择。
7889

79-
#### HTML
80-
81-
HTML 全称为 `超文本标记语言`。HTML 相比 PDF 更注重内容和样式而不是排版，因此不适合对排版有严格要求的场合。
82-
83-
HTML 使用类似 XML 的标签嵌套语法。HTML 中可以嵌入或引用 CSS/JavaScript，浏览器能够渲染 HTML、解析 CSS、运行 JavaScript。因此 HTML 事实上不仅是文档，更是一个应用。
84-
85-
HTML 可以直接用文本编辑器编辑，也可以通过 Markdown 等格式转换而来。HTML 是 Web 应用的核心，有很多框架可以快速制作 Web 应用，可阅读 [Web 开发](../应用开发/Web.md) 章节了解更多。
86-
87-
### 非纯文本
88-
89-
非纯文本指文档不以纯文本形式存储所有内容。这有几种不同的实现方式
90-
91-
- 压缩打包。文档本质上仍然以文本形式存储，只不过打包并改成了新的后缀格式。这通常被叫做容器文件
92-
- 页面描述。文档使用了一些二进制指令来描述页面的布局、内容等。这种文档通常由一种编程语言演化而来
90+
### 二进制文档
9391

94-
当然了，相对纯文本存储，这样做会有一些缺点
92+
二进制文档指使用二进制格式进行存储的文档。相对于文本文档，这样做会有一些缺点
9593

9694
- 不通用，文件必须使用特定的软件才能编辑和查看
9795
- 版本控制不友好，Git 无法使用 diff/merge 等功能
9896

97+
二进制文档也有不同的实现方式
98+
99+
- 容器格式。这种格式本质上也用文本存储所有内容，只不过进行了打包和压缩，典型例子是 DOCX/PPTX/EPUB
100+
- 平面格式。这种格式使用指令来描述页面如何绘制，并可能对文本、资源进行压缩，典型例子是 PDF
101+
99102
#### DOCX
100103

101104
DOCX 类似 LaTeX，是一个写作排版系统。DOCX 以 *所见即所得* 的方式进行写作排版，因此经常被滥用：很多人将 DOCX 作为最终交付的文档格式，尽管它是为写作而非阅读设计的。
@@ -138,10 +141,42 @@ EPUB 通常要使用别的工具进行编辑，比如 **Sigil** 或 **calibre**
138141

139142
PDF 全称为 `可携带文档格式`。对排版有严格需求的场合（比如书籍出版、论文打印）通常都会使用 PDF 格式。
140143

141-
PDF 内部使用文本和二进制混合的格式，文本部分使用类似 PostScript 的语言定义文档结构，二进制部分主要是压缩后的资源数据和内容，整个文档是自包含和扁平化的。
144+
PDF 内部使用类似 PostScript 的语言来定义页面的内容和样式，并对文本、资源等数据进行了压缩，整个文档是自包含和扁平化的。
142145

143146
虽然有软件可以直接编辑 PDF 文件，但一般不这么做，而是将别的更易编辑的格式转为 PDF 格式。DOCX、LaTeX、Typst 直接就可以将文档转为 PDF 格式，而 Markdown、HTML 等借助工具也可以做到。
144147

148+
### 矢量图
149+
150+
矢量图本质是数学描述，渲染器会根据这些描述绘制出图片。这种设计使其具有以下特性
151+
152+
- 可以无限放大而不变模糊
153+
- 文件大小不因图形尺寸而改变
154+
- 可以编辑图形对象
155+
156+
#### SVG
157+
158+
SVG 是一种流行的矢量图格式，直接用文本进行存储。
159+
160+
SVG 使用基于 XML 的语法，支持编写 CSS 来控制外观，并且可以绘制动画。
161+
162+
SVG 非常适合 Web 应用，由于其直接以文本进行存储，因此可以通过代码控制图形，从而实现非常强大的交互。
163+
164+
### 光栅图
165+
166+
光栅图本质是像素阵列，渲染器会将每个像素放置在一个网格中。这种设计使其具有以下特性
167+
168+
- 放大后会变模糊
169+
- 图形尺寸越大，占用的空间就越大
170+
- 只能进行像素级的编辑
171+
172+
#### PNG
173+
174+
PNG 是一种流行的光栅图格式，存储为复杂的二进制格式。
175+
176+
PNG 可以无损压缩，支持多种颜色模式，支持透明通道。
177+
178+
PNG 适合需要无损压缩或者透明通道的场合，比如有透明背景的图片、需要无损保存细节的图像等。
179+
145180
## 工具
146181

147182
### 文档转换

‎docs/编程语言/index.md‎

Lines changed: 18 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -59,28 +59,38 @@
5959
6060
这里只列出我接触过的编程语言。现存的编程语言非常多，但真正到了需要编程解决问题的时候，其实能选择的语言反而比较少。
6161

62+
编程语言按以下方式进行分类
63+
64+
- 编译型。用编译器将源代码变成一个可执行文件
65+
- 托管型。用编译器将源代码变成字节码，再交给虚拟机执行
66+
- 解释型。用解释器直接执行源代码
67+
6268
> [!Note]- 语言的分类问题
63-
> 如前所述，使用 *编译型* 和 *解释型* 来划分语言是有局限的。
69+
> 如前所述，使用 *编译型*/*托管型*/*解释型* 来划分语言是有局限的
6470
>
65-
> 比如 TypeScript，有明确的编译（更准确的说是转译）过程，但一般不归类为编译型语言，因为 TypeScript 编译的目标是另一种高级语言，而不是中间代码或机器语言；再比如 Python 和 Java 都可以把源代码编译为字节码这种可由虚拟机运行的中间代码，但传统上就认为 Java 是编译型语言，而 Python 是解释型语言。
71+
> - 一个语言可能有多种实现。比如 C++ 既有编译器实现也有解释器实现
72+
> - 一些语言的实现可能并不完全符合上述的类别。比如 TypeScript 通过转译借用了 JavaScript 的实现，比如 Python 也可以将源代码编译为字节码
6673
>
67-
> 因此 *编译型/解释型* 不是一个好的分类方法。但考虑到社区习惯这么说，我就这么进行分类了。
74+
> 因此目前的分类并不完美，我只能比较主观地对那些有争议的语言进行了分类
6875
6976
### 编译型
7077

7178
- [C](Cpp.md) 和 UNIX 生态紧密结合的语言，流行的很大原因是因为 UNIX。属于 **C++** 的子集，因此合并到了 **C++** 章节中。
7279
- [C++](Cpp.md) 古老而强大的语言。但由于历史原因，C++ 有非常多的缺陷，同时也是主流语言里少数没有官方实现的语言。但同样由于历史原因，C++ 有非常多的代码遗产，一时半会没法转移，所以还能苟活很久。
7380
- [CUDA](CUDA.md) 严格地说 CUDA 不是一门语言，而是由 NVIDIA 推出的一个异构编程模型，不过也可以把它当成一个 C++ 方言。CUDA 拓展了 C++ 的语法，可以声明哪些代码应该在 GPU 上运行。
74-
- [C#](CSharp.md) 由 Microsoft 发明并推广的语言，依赖 .NET 运行时。
75-
- Swift 现代版的 Object-C，Apple 钦定的 iOS/macOS 原生开发语言。
76-
- [Java](Java.md) 和 C# 很相似 ~~其实是后者模仿前者~~，依赖 Java 虚拟机。
77-
- Kotlin 现代版的 Java，Google 钦定的 Android 原生开发语言。同样依赖 JVM，尽管可以编译成机器码，但这一特性目前还是实验性的。
7881
- [Rust](Rust.md) 更现代的 C++，有更合理的、更统一的工具链，能够从语法层面保障内存/并发安全，可以在编译期发现大多数错误。尽管语法复杂，学习曲线陡峭，但我仍然认为 Rust 是充满前景的。
7982
- [Go](Go.md) 由 Google 设计并开源的语言，能够简单地编写并发程序，可作为大多数后端项目的首选。很多云原生基础设施也都是用 Go 写的，比如 Docker、Kubernetes。
8083
- Zig 现代版的 C 语言，但还没发布稳定版本。
84+
- Swift 现代版的 Object-C，Apple 钦定的 iOS/macOS 原生开发语言。
8185
- V 语法类似 Go，但编译时将 C 作为自己的后端，和早期的 C++ 一样。目前还没发布稳定版本。
8286
- Haskell 纯函数式语言，相比于工程项目更适合学术研究，可以编译成机器码。
83-
- Erlang 也是函数式语言，但比起 Haskell 注重实用性，依赖 BEAM 虚拟机。
87+
88+
### 托管型
89+
90+
- [C#](CSharp.md) 由 Microsoft 发明并推广的语言，面向对象，依赖 .NET 运行时。C# 的实现和 Java 略有不同：中间代码会嵌入可执行文件，且运行时是个动态链接库。
91+
- [Java](Java.md) 面向对象语言，依赖 Java 虚拟机。
92+
- Kotlin 现代版的 Java，Google 钦定的 Android 原生开发语言。同样依赖 JVM，尽管可以编译成机器码，但这一特性目前还是实验性的。
93+
- Erlang 函数式语言，比起 Haskell 更注重实用性，依赖 BEAM 虚拟机。
8494
- Elixir 现代版的 Erlang，同样依赖 BEAM 虚拟机。
8595

8696
### 解释型

0 commit comments

Comments
 (0)