各种小工具记录

小工具集合

网站底部徽标生成

网站：shields.io

使用示例：

emoji表情

提供了非常多的emoji表情，可以自己选择，复制粘贴到文章中即可使用。

GetEmoji

完整备份git仓库

  1. 使用 git clone –mirror 创建裸仓库备份
    这种方式会备份所有分支、标签和引用，是最完整的备份方式。
1
git clone --mirror http://192.168.xxx.xxx:3000/yyyy/zzzz.git
  1. 使用 git fetch 更新现有备份
    如果已经有一个备份，可以使用fetch来更新而不是重新克隆
1
2
cd zzzz.git    --- 进入备份仓库目录
git fetch --all --prune
  1. 恢复仓库

如果我使用git clone –mirror完整备份了仓库，也执行git fetch进行更新。某天源仓库硬盘挂了，我如何快速恢复出来一个仓库进行使用。

1
2
cd zzzz.git    --- 进入备份仓库目录
git push --mirror https://github.com/yourname/new-repo.git
  • 这个仓库就可以正常使用了

nexus代理pypi源

分别创建多个pypi(proxy)仓库：
腾讯源：https://mirrors.cloud.tencent.com/pypi/
中科大：https://mirrors.ustc.edu.cn/pypi/
163：https://mirrors.163.com/pypi/
阿里云：https://mirrors.aliyun.com/pypi/
清华：https://pypi.tuna.tsinghua.edu.cn/

记得这里不能加 /simple 路径。

然后创建一个对外出口仓库pypi(group)，将所有proxy仓库加入其中。
最终使用的方式：pip install flask -i http://192.168.5.75:10099/nexus/repository/pypi/simple –trusted-host 192.168.5.75
记得一定要加 /simple

package.json\package-lock.json的作用

首次执行 npm install 时，npm 会根据 package.json 的版本范围拉取依赖，安装完成后生成 package-lock.json；
后续再次执行 npm install 时，npm 会 优先读取 package-lock.json，直接安装锁定的精确版本，忽略 package.json 的范围描述（除非手动修改 package.json 的依赖版本，或执行 npm update）；
该文件是 自动生成的，不应手动修改（手动修改可能导致依赖树混乱）。

Android打包aab签名超过2G报错问题

以下是deepseek回复：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
核心原因：JAR 签名与 ZIP 格式的 32 位限制
Android 的 APK 签名方案 v1（即传统的 JAR 签名）是基于 ZIP 文件格式的。而 ZIP 文件格式在设计之初，其“中央目录”记录的“文件偏移量”字段使用的是 32 位有符号整数。

32 位有符号整数的范围：

它能表示的最大值是 2^31 - 1，也就是 2,147,483,647 字节。

换算成 GB 就是 2,147,483,647 / 1024 / 1024 / 1024 ≈ 2.0 GB。

签名过程与文件偏移量：

在 v1 签名过程中，apksigner 会为 APK 中的每个文件计算哈希值，并将这些哈希值连同其他信息一起写入到 META-INF/MANIFEST.MF 等文件中。

当 APK 文件本身（特别是其中的某个文件，或者所有文件数据的总和）的大小超过 2GB 时，文件在 ZIP 包内的偏移量就有可能超过那个 32 位最大限制。

一旦超过，apksigner（以及底层的 Java ZIP 处理库）就无法正确地定位和描述文件的位置，从而导致签名过程失败。

为什么默认会使用 v1 签名？
即使你指定了更新的 v2/v3/v4 签名方案，出于兼容性考虑，apksigner 默认会同时保留 v1 (JAR) 签名。除非你显式地使用 --v1-signing-enabled false 参数来禁用它。

所以，当你的 APK 超过 2GB 时，即使你打算只用 v2/v3 签名，工具仍然会尝试生成 v1 签名，从而触发了上述的 ZIP 格式限制，导致整个签名过程失败。

解决方案
既然知道了问题的根源，解决方案就清晰了：禁用会触发 ZIP 32 位限制的 v1 签名。

#### 方法一：使用 apksigner 命令禁用 v1 签名

在签名时，明确指定只使用 v2 或更新版本的签名方案。

apksigner sign \
  --ks my-release-key.jks \
  --v1-signing-enabled false \  # 关键：禁用 v1 签名
  --v2-signing-enabled true \   # 启用 v2 签名（默认true，可省略）
  --v3-signing-enabled true \   # 启用 v3 签名（如果需要）
  --out my-app-signed.apk \
  my-app-unsigned.apk

方法二：在 Android Gradle 插件中配置

如果你使用的是 Android Studio 和 Gradle 构建，可以在 `app/build.gradle` 文件中进行配置：

android {
    signingConfigs {
        release {
            storeFile file("my-release-key.jks")
            storePassword "your_password"
            keyAlias "your_key_alias"
            keyPassword "your_key_password"
            // 禁用 v1 签名
            v1SigningEnabled false
            // 启用 v2 签名
            v2SigningEnabled true
            // 启用 v3 签名
            v3SigningEnabled true
        }
    }
    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

AAB 签名失败的根本原因与 APK 相同，但触发机制略有不同。这是因为 apksigner 工具在内部将 AAB 文件视为一种特殊的 ZIP 文件进行处理，而 ZIP 格式的 32 位限制同样适用。

禁用v1签名可以解决此问题，但是会导致Android7.0以下的系统版本不能安装应用，得不偿失。所以限制apk/aab大小才是正途。

uv add加速

uv add django-simpleui==2025.6.24 –default-index https://pypi.tuna.tsinghua.edu.cn/simple

参考：https://zhuanlan.zhihu.com/p/1930714592423703026

全链域名证书判断

我用最简单、不绕弯、开发也能听懂的话，给你讲明白：
全链证书（fullchain） 和普通证书到底是什么、有啥区别。

  1. 先给结论（一句话）

你运维说的：

  • 不是全链证书 = 只有「你自己域名的证书」，缺了中间证书
  • 全链证书（fullchain） = 你的域名证书 + 中间证书，一整套完整链条

Uptime Kuma、curl、后端程序、小程序、APP 都要求必须是完整链，不然就报：
unable to verify the first certificate

  1. 证书链条到底是什么？

SSL 证书不是一张，而是一条链：

  1. 根证书（系统自带，全世界公认）
  2. 中间证书（CA 机构发的，用来信任下一级）
  3. 你的域名证书（你网站用的）

你之前的证书：只有【3】

只有你自己域名那一段。

  • 浏览器很聪明，会自动去网上下载中间证书，所以浏览器打开是绿锁、正常。
  • 但 Node.js、Java、curl、Uptime Kuma、APP、小程序 不会自动下载，它们只认你服务器给的内容。
    → 链断了 → 验证失败。

现在换成 fullchain（全链）：包含【2+3】

服务器直接一次性返回：
中间证书 + 你的域名证书

任何客户端拿到，直接就能从头验证到尾，不会报错。

  1. 最直白的区别
文件 内容 浏览器 Uptime Kuma / curl / APP
cert.pem（单证书） 只有你的域名 ✅正常 ❌报错：无法验证
fullchain.pem（全链） 中间证书 + 你的域名 ✅正常 ✅正常
  1. 为什么运维之前没发现？

因为浏览器会自动补全中间证书，
运维平时用浏览器看是好的，就以为证书没问题。
但后端、监控、接口调用、小程序全是严格校验链条的。

  1. 你以后记住这一句就够了

Nginx、Apache 配置 SSL，永远用 fullchain.pem，永远不要只用单个 cert.pem。