各种小工具记录

熊猫不是猫2025-06-152025-10-14

小工具集合

网站底部徽标生成

网站：shields.io

使用示例：

emoji表情

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

GetEmoji

完整备份git仓库

使用 git clone –mirror 创建裸仓库备份
这种方式会备份所有分支、标签和引用，是最完整的备份方式。

1	git clone --mirror http://192.168.xxx.xxx:3000/yyyy/zzzz.git

使用 git fetch 更新现有备份
如果已经有一个备份，可以使用fetch来更新而不是重新克隆
1
2
cd zzzz.git --- 进入备份仓库目录
git fetch --all --prune
恢复仓库

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

首先在新Git服务上创建空仓库，获取URL，https://github.com/yourname/new-repo.git

从备份推送到新仓库

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回复：

核心原因：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 位限制同样适用。