qidao123.com技术社区-IT企服评测·应用市场»论坛 › 数据库 › 分布式数据库 › 办理 PicGo 上传 GitHub图床及Marp中Github图片编译常见 ...

办理 PicGo 上传 GitHub图床及Marp中Github图片编译常见困难指南

[复制链接]
发表于 2025-9-1 11:30:08 | 显示全部楼层 |阅读模式
  1. [目录]
  2. 0.行文概述
  3. 1.PicGo图片上传失败
  4. 2.*关于在Vscode中Marp图片的编译问题*
  5. 3.总结与启示
复制代码
行文概述


写作本文的动机是本人看到了Awesome Marp，发现使用                              Markdown                          \texttt{Markdown}               Markdown做PPT若加持一些                              CSS                      ,                      JavaScript                          \texttt{CSS},\texttt{JavaScript}               CSS,JavaScript，效果也能非常好。然后就发现，按照Awesome Marp的设置教程中，对于没有                              JavaScript                          \texttt{JavaScript}               JavaScript底子者而言，必要设置的东西相对较多。对本人而言，费时间最久的则是PicGo的Github图床设置问题。因该问题相对复杂且具有代表，故整理一篇教程。
作为一款广受接待的图床上传工具，PicGo 以其便捷性和多平台支持赢得了许多用户的青睐，尤其是配合 GitHub 作为免费图床的方案。然而，在设置 PicGo 连接 GitHub 的过程中，一些“拦路虎”常常会让用户头疼不已。本文将通过一个真实的故障排查案例，详细记录如何一步步办理从 SSL 证书验证失败到找不到目的分支等一系列问题，盼望能为遇到类似困境的朋侪提供一份清晰的办理指南。
案例配景： 一位用户 (HorseRunningWild，好吧，也就是本人) 在设置 PicGo (v2.3.1 或相近版本) 使用 GitHub 作为图床时，反复遭遇上传失败。
PicGo图片上传失败

本文主要旨在办理两类问题


  • 第一类

    unable to verify the first certificate
  • 第二类
    同样显示类似上文的"上传失败"，但                                        error                                  \texttt{error}                     error什么也不报。仅显示“{}”。
第一步：初步诊断与通例查抄

面临这类网络相关的错误，我们通常会从几个方面入手：

  • PicGo 日志日志分析：
    首先我们应该打开PiCGo的日志日志：


    可以发现.log文件中有类似内容
    1.   2025-05-14 07:50:31 [PicGo ERROR] {
    2. "method": "PUT",
    3. "url": "https://api.github.com/repos/picture-bed/repo/contents/images/logo.png",
    4. "statusCode": 0,
    5. "message": "unable to verify the first certificate",
    6. "stack": "Error: unable to verify the first certificate\n    at TLSSocket.onConnectSecure (node:_tls_wrap:1530:34)\n    at TLSSocket.emit (node:events:394:28)\n    at TLSSocket._finishInit (node:_tls_wrap:944:8)\n    at TLSWrap.ssl.onhandshakedone (node:_tls_wrap:725:12)",
    7. "response": {
    8.   "status": 0,
    9.   "statusCode": 0,
    10.   "body": ""
    11. }
    复制代码
    unable to verify the first certificate 和 statusCode: 0 是核心线索，表明问题出在网络层，乃至在 HTTP 哀求发出之前。
  • 网络环境切换： 遇到上述问题，可首先尝试更换网络。因为本人原本使用的是学校的网络，考虑到学校的网大概会有一些限定，故从切换到手机热点。但问题依旧。这在一定程度上排除了当地路由器设置或特定 ISP 计谋的干扰，将疑点更多地引向了盘算机本身的设置。
  • PicGo 设置项 rejectUnauthorized： 既然显示的是类似verify certificate的问题，接下来大概的尝试是在 PicGo 设置中（就在打开日志日志文件的上一条）的图床部门添加
    1. {
    2. "picBed": {
    3. "github": {
    4.   "repo": "your/repo",
    5.   "branch": "main",
    6.   "token": "your-token",
    7.   "path": "images/",
    8.   "customUrl": "",
    9.   "rejectUnauthorized": false  // 新添加的代码
    10. }
    复制代码
来尝试绕过 SSL 证书验证。虽然在本案例中用户也尝试过类似设置或默认环境下此选项大概不那么严格，但错误依然顽固。这暗示问题大概比单纯的证书链不完整更深层。
第二步：curl 命令显神威，定位DNS剖析异常

当应用层面的调试陷入僵局时，动用底层网络诊断工具每每能带来突破。我们在这里会用到curl命令(发音同 “curl”)。curl 是一个非常强大的命令行工具和库 (libcurl)，用于通过 URL 与服务器举行数据传输。它支持多种网络协议，包罗HTTP/HTTPS (最常用的，用于网页和 API)等等。在 macOS 和许多 Linux 发行版中，curl 通常是预装的，也就是系统自带的。
在 Windows 10/11 的较新版本中，curl.exe 也已经成为内置命令，可以直接在命令提示符 (CMD) 或 PowerShell 中使用。
curl的基本用法,如获取网页内容 (GET 哀求)：
  1. curl https://www.example.com
复制代码
这会下载https://www.example.com 的 HTML 内容并显示在终端。
而我们必要的则是curl -v
  1. curl -v https://api.github.com
复制代码
-v (verbose) 参数让 curl 输出了详细的连接过程信息。很快，关键问题浮出水面：
  1. * Host api.github.com:443 was resolved.
  2. * IPv6: (none)
  3. * IPv4: 127.0.0.1  <-- 症结所在！
  4. *   Trying 127.0.0.1:443...
  5. * schannel: next InitializeSecurityContext failed: CRYPT_E_NO_REVOCATION_CHECK (0x80092012) - 吊销功能无法检查证书是否吊销。
  6. * closing connection #0
  7. curl: (35) schannel: next InitializeSecurityContext failed: CRYPT_E_NO_REVOCATION_CHECK (0x80092012) - 吊销功能无法检查证书是否吊销。
复制代码
庞大发现！ api.github.com 竟然被剖析到了 127.0.0.1，也就是 localhost（用户自己的电脑）。这意味着 PicGo 和 curl 在尝试连接 GitHub API 时，实际上是在“自己打自己”。当地盘算机天然不大概提供 api.github.com 的有用 SSL 证书，因此“无法验证第一个证书”的报错也就顺理成章了。
第三步：揪出 hosts 文件中的“内鬼”

什么会导致域名被错误地剖析到当地回环地址呢？最常见的首恶就是系统的 hosts 文件。


  • Windows: C:\Windows\System32\drivers\etc\hosts
  • macOS/Linux: /etc/hosts
在windows中，可以以管理员身份运行记事本，找到C:\Windows\System32\drivers\etc\hosts。在本人查抄其 hosts 文件后，原形大白。原来，一款名为 “Steam++” 的 GitHub 加速软件为了实现其加速功能，修改了 hosts 文件，将大量 GitHub 相关域名（包罗我们关心的 api.github.com）指向了 127.0.0.1，计划通过当地代理周转流量。
  1. # Steam++ Start
  2. ...
  3. 127.0.0.1 steamcdn-a.akamaihd.net
  4. ...
  5. 127.0.0.1 api.github.com  <-- 就是你！
  6. 127.0.0.1 gist.github.com
  7. ...
  8. 127.0.0.1 github.com
  9. ...
  10. # Steam++ End
复制代码
当然，在此处显然也不是要苛责该加速器，因为确实，要是没有加速器，就只能挂梯子上Github了…
办理方案：
以管理员权限编辑 hosts 文件，将 127.0.0.1 api.github.com 这一行注释掉（在行首加 #）或直接删除。
  1. # 127.0.0.1 api.github.com
复制代码
修改保存后，务必刷新系统 DNS 缓存：


  • Windows (管理员CMD): ipconfig /flushdns
再次实行 curl -v https://api.github.com
，输出结果令人振奋：
  1. * Host api.github.com:443 was resolved.
  2. * IPv6: (none)
  3. * IPv4: 20.205.243.168  <-- 正确解析到 GitHub 公网 IP！
  4. *   Trying 20.205.243.168:443...
  5. * Connected to api.github.com (20.205.243.168) port 443
  6. ...
  7. < HTTP/1.1 200 OK
  8. ...
复制代码
网络通了！SSL 证书问题迎刃而解。
第四步：新挑战——“找不到 master 分支”

满心欢喜地再次尝试 PicGo 上传，然而，新的错误出现了：
  1. {
  2.   "method": "PUT",
  3.   "url": "https://api.github.com/repos/HorseRunningWild/picturebed/contents/images/logo.png",
  4.   "statusCode": 404, // 注意，不再是 0 了！
  5.   "message": "Request failed with status code 404",
  6.   "response": {
  7.     "body": {
  8.       "message": "Branch master not found", // 关键信息！
  9.       "documentation_url": "https://docs.github.com/rest/repos/contents#create-or-update-file-contents"
  10.     }
  11.   }
  12. }
复制代码
这次的 statusCode: 404 表明 PicGo 已经成功连接并与 GitHub API 服务器举行了通信，但服务器反馈“未找到资源”。具体的错误消息是 Branch master not found。
原因分析：
近年来，出于社区多元化和包容性的考量，GitHub 将新建仓库的默认分支名称从 master 更改为了 main。假如用户的 picturebed 仓库是近期创建的，其默认分支很大概就是 main。而 PicGo 的 GitHub 上传设置中，默认或用户之前设置的分支名大概仍然是 master。但是，停止本文写作期间，PicGo官网的设置手册示例中仍然是 master，容易对新人造成误导。

PicGo 设置中对应的部门：
  1. // PicGo 配置文件中的 githubUploader 部分
  2. "github": {
  3.   "repo": "HorseRunningWild/picturebed",
  4.   "branch": "master", // <-- 这里可能与实际不符，应该改为main
  5.   "token": "ghp_YourTokenHere",
  6.   "path": "images/",
  7.   "customUrl": ""
  8. }
复制代码
办理方案：

  • 确认仓库实际分支名： 前往 https://github.com/HorseRunningWild/picturebed，查看仓库页面的分支选择器，确认主分支名称（大概率是 main）。
  • 修改 PicGo 设置： 将 PicGo 设置文件中 GitHub 上传器的 branch 字段值从 "master" 修改为实际的分支名，如 "main"。
    1. "github": {
    2.   "repo": "HorseRunningWild/picturebed",
    3.   "branch": "main", // 更新为正确的分支名
    4.   // ...
    5. }
    复制代码
  • 保存设置，重启 PicGo (假如必要) 后再次尝试上传。
关于在Vscode中Marp图片的编译问题

因为图床毕竟是放在Github中，所以有时会出现，分明将图片的Markdown代码好好地放在IDE中，却无论如何也无法渲染出来。这种问题一样平常是两种大概：

  • 网络问题。试试挂上VPN，因为国内访问Github的确受限。
    大概，也可以直接尝试能否在欣赏器种访问自己的图片，好比：
    1. https://raw.githubusercontent.com/HorseRunningWild/picturebed/main/images/logo of hrw.jpg
    复制代码
    假如可以的话，显然就是网络问题了。
  • 查抄自己的仓库是否为Public。
  • 别的一些如Vscode中的Markdown插件问题，就不再赘述。
总结与启示


  • 日志是金： 无论是应用程序日志 (PicGo) 照旧工具输出 (curl -v)，详细的日志信息都是定位问题的基石。
  • 底层工具的重要性： 当上层应用报错模糊时，使用如 curl, ping, nslookup 等网络诊断工具可以直接探测网络连通性和服务相应环境。
  • 鉴戒“加速器”的副作用： 各类网络加速或代理工具，尤其是那些会修改系统 hosts 文件的，有时会美意办坏事，干扰特定服务的正常连接。
  • 与时俱进： 关注目的服务（如 GitHub）的默认设置变更，例如默认分支名从 master 到 main 的变化，这大概导致依靠旧设置的工具出现兼容性问题。
  • 系统化排查： 从应用层到网络层，再到系统设置层，逐层排查，由表及里，通常能更有用地找到问题根源。
  • **对于同样盼望使用Awesome-Marp的朋侪的建议：**遇到问题可以多看Github上的issue，以及记得在安装PicGo前必要先安装和设置                                   Node.js                              \texttt{Node.js}                  Node.js，建议先参考Node.js安装及环境设置超详细教程【Windows系统】
盼望这次真实的排查经历能帮助到更多正在或将要设置 PicGo + GitHub 图床的朋侪们。祝各人折腾愉快，上传顺利！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
继续阅读请点击广告

本帖子中包含更多资源

您需要 登录 才可以下载或查看，没有账号？立即注册

×
回复

使用道具 举报

返回列表

雁过留声
+ 我要发帖
×
登录参与点评抽奖，加入IT实名职场社区
去登录
快速回复 返回顶部 返回列表