export NODE_OPTIONS=--openssl-legacy-provider
对于这样的数据：
"video": {
"serviceProvider": "vimeo",
"videoId": "968618271"
}下载器应该输出这样的链接：https://player.vimeo.com/video/968618271
之前输出的链接是错误的，因为网址前缀不正确。现在修复此问题。
“价格范围”现在可以设置为等于（=）指定价格了。以前只能设置为大于等于（>=）。
在用户主页抓取时（也就是说在文章列表页面时），用的 API 是 /post.listCreator?creatorId=usotukiya&limit=300 这样。之前文章列表数据保存在 data.body.items 里，现在直接是 data.body 了。
之前返回的数据结构：
body: {
items: PostListItem[]
nextUrl: null | string
}现在只有：
body: PostListItem[]
PostListItem[] 直接提升到 body 里，另外取消了 nextUrl。
之前的 nextUrl 是用于获取下一批作品数据的 URL，但现在没有了。那怎么请求后续文章呢？其实看下官方怎么做的就知道了，有个分页 API /post.paginateCreator?creatorId=creatorId 会返回一个网址列表，里面就是用于获取每一个列表页数据的 URL（每次显示 10 个）。
之前下载器没有使用这个 API，因为获取文章列表数据时，有前面说的 nextUrl 可以用。而且之前一页可以获取 300 条文章数据。300 是最大数字，超出的话 API 会报错。
考虑到极端情况，假设某个作者有 1000 篇文章，那么下载器现在只能请求到第一批的 300 个（因为没有 nextUrl 了），会漏掉后续的文章。
现在我有 2 个解决思路：
- 使用官方的分页 API 获取每一个列表页的 URL，但是它每个 URL 里只有 10 篇文章，需要对列表页发起 100 次请求。
- 先使用官方的分页 API，然后我自行修改一下，实现每 300 页发起一次请求。
用 2 的方式比较好，现在采用了 2 的方式。
注意： 并非所有的请求列表数据的 API 都发生了变化。只有在用户主页抓取文章列表出现了变化。
在 fanbox 主页“抓取赞助的所有用户的投稿”的数据没有变化。
在文章 tag 列表页抓取的数据也没有变化。
例如：
跳过 66 HINA 因为：价格限制 1000
现在文章标题“66 HINA”会添加文章的超链接，可以点击它打开文章页面。
目前只有跳过文章会显示日志；跳过文章内的文件时不会显示日志。
现在你可以通过文件名来过滤文件了。
此处的文件指作者上传的附件，通常是压缩包、视频、音频，它们会在网页上显示文件名。
Fanbox 的文章根据撰写前选择的类型，有如下分类：
其中压缩包、视频等作者自行上传的附件只在两种类型里有，就是“文章”和“文件”，作品类型分别为 article 和 file。
之前下载器的日志里没有显示具体价格，现在会显示，例如：
跳过 xxxx 因为：价格限制 1000
现在换行的效果可以保持与原文一致。
这个文章的封面图是 500 错误：
https://www.fanbox.cc/@chisamell/posts/4368124
SERVER_FAILED 错误是 500 服务器内部错误。下载器会尝试进行重试，但是有些文件没有缩略图，无法重试，会无限循环。
现在下载器优化了提示，并且当文件没有缩略图时，跳过下载它。
fanbox 现在把一些网盘外链转换成 html.card 类型，这是新出现的一个类型，导致下载器提取不到其 URL，现在修复。
具体可以查看 docs\保存网盘链接的问题.md。
当预览内容太多（大于 5000 条）时，下载器会把输出内容保存到一个 txt 文件里，但是里面却依然是 html 代码。
现在把 txt 的内容改为纯文本。
之前的 ttk 机场网址不能用了，已经 20 天了，我现在才想起来把它换掉。
现在你可以为图片文件和非图片文件设置独立的命名规则。
另外，非图片文件的默认名字改为它们的原文件名，而不是序号。
也就是压缩包等文件的默认名字从 {index} 变成 {name}。
之前 Pixiv 下载器因为有些用户名是 con.fundo_ 这样的，含有 con.，这可能会造成无效的文件名。
但是 Fanbox 的创作者 ID 可使用小写的半角英文数字与连字符，输入 . 是非法的，所以不会有这个问题。
昨天有个用户反馈问题：
昨天發現當下載大檔案時(200MB 約十分鐘)，下載完成後下載器不會繼續下載下一個檔案，狀態則停留在"正在下載"。
按下暫停下載後再按下開始下載，會將同個檔案重複再下載一次。
如果是像圖片的小檔案則下載器運作正常。
这个大文件下载了大约 10 分钟，而本下载器的文件下载是由浏览器去下载的（而非下载器下载完成之后交给浏览器），所以问题的原因可能是在浏览器下载期间，Services Worker 被回收导致 dlData 变量被清空，导致文件下载完成后，后台找不到对应的数据，也就不会告诉前台下载已完成。
现在我把 dlData 做了持久化存储，以期解决此问题。不过我没有大文件和很低网速的情况来进行测试。理论上是没问题的。
以前下载器需要给发出的请求设置 origin 和 referer 标头，所以需要修改网络请求的权限。
现在我试了下不需要修改请求也能正常使用了，所以移除了 declarativeNetRequest 权限。
{create_id} 画师的创作者 ID（英文名或罗马字）。
其实就是 URL 里显示的用户的英文名，如 https://www.fanbox.cc/@tsubasachyan 里的 tsubasachyan。
{postid}改为{post_id}{uid}改为{user_id}
这样修改是为了显得更加合理，之前的标记名字有些太随意了。
不过旧的标记依旧可以使用，所以用户不必去修改自己以前使用的命名规则。
默认的命名规则改为 {user}/{date}-{title}/{index}。
默认的时间格式现在只有年月日，不带小时和分钟。如果有需要，可以在“日期和时间格式”里进行修改。
如果用户手动取消了下载（错误代码 USER_CANCELED），下载器不会再重试下载这个文件。
下载 fanbox 的文件需要 cookie（封面图除外），所以直接把文件 URL 复制到 IDM 是无法下载的（403）。
但是当在浏览器里下载完一个文件时，或者下载时转发到 IDM，则 IDM 可以下载这个文件。原理尚不清楚。
- 投稿标题不能含有关键字
- 投稿标题必须含有关键字
用户可以根据投稿标题来筛选要抓取的投稿了。
以前如果一个投稿遇到了价格限制，下载器不会抓取它的封面图。现在可以了。
修复了“ID 范围”设置不显示的问题。
这样在下载时，文件的下载顺序就是按照投稿发表时间下载的。
当某个投稿因为价格限制无法抓取时，下载器会在日志显示此提示。
当抓取完成后，下载器会显示遇到价格限制的投稿的总数。
下载器默认会把网址改成用户名在后的形式，然而当用户未登录时，fanbox 会强制把网址改为用户名在前的形式，这造成了冲突。
现在下载器会判断用户是否登录，未登录时不会修改网址。
Fanbox 下载器是从我的 Pixiv 下载器修改而来的，但是 Pixiv 下载器的代码不断优化，而 Fanbox 下载器的代码依然停留在两年多之前的时候。这导致 Fanbox 下载器的代码修改和维护起来很麻烦，添加新功能也不方便。所以现在我决定参考 Pixiv 下载器现在的代码对其进行重构。
新增了如下设置：
- 恢复未完成的下载任务
- 在序号前面填充 0
- 下载完成后显示通知
- 不下载重复文件
- 高亮显示关键字
- 背景图片
- Language
- 管理设置
- 显示高级设置
- 统一网址格式
之前不同用户页面里的设置可能是不通用的。现在可以通用了。
Fanbox 有两套网址形式：
上面同一个用户的两个网址，但由于子域名不同，所以浏览器认为是不同的网站。
受此影响，这两种网址里的下载记录数据和背景图片是不通用的。
如果启用“统一网址格式”，下载器总是会使用第二种网址，这样数据就可以通用了。
感谢 KOZ39 添加的韩语翻译！
修复了 urlEmbedMap 类型的外链会无视“保存投稿中的外部链接”设置，始终保存的问题。
https://www.fanbox.cc/@singlecask/posts/4012918
这篇文章里的 urlEmbedMap 字段类型之前没见过，导致了抓取出错，现在修复。
目前对于 "type": "fanbox.post" 的内容不进行处理和保存。
文章类型投稿不知何时增加了 urlEmbedMap 字段，它可以把插入的 url 地址直接转换成卡片或者内嵌的 html 代码。
现在下载器支持提取此类链接。
Chrome 浏览器下载一个文件时，如果返回了错误代码 SERVER_BAD_CONTENT 就说明是 404 错误，文件不存在。
之前下载器没有检测这个错误，会一直重试下载。现在对于 404 错误不会再重试下载。
上个版本修复的方式不彻底，某些情况下仍会出问题，例如：
https://nekoworks.fanbox.cc/posts/935
里面有个图片的代码是这样的：
<a href="https://downloads.fanbox.cc/images/post/935/2s2e082blxescogs0wo4g4oo.png"><img class="image-large" src="https://downloads.fanbox.cc/images/post/935/w/1200/2s2e082blxescogs0wo4g4oo.jpeg" width="790" height="510"></a>问题在于图片后缀是 jpeg，但是超链接后缀是 png。这个情况很少见。
之前下载器取 entry 类型投稿时提取的是图片 src，但是在这种情况中就会出错。
现在改为提取 a 标签的 href，解决此类错误。
在早期的一些 entry 类型的投稿里，图片的网址是缩略图，不是原图，现在对此进行了修复。
PS：现在似乎没有 entry 类型了。
如果用户启用了“保存投稿中的文字”的功能，之前下载器可能会保存空的 txt 文件。
这是因为有的投稿里的空字符串也被保存了。现在修复了这个问题。
测试投稿：https://xuejianxianzun.fanbox.cc/posts/2993061
因为 Fanbox API 的变化，在画师主页抓取时，返回的数据变了，没有 type 字段，也缺少了文章里的附件、多媒体资源，导致抓取出错。
现在修复了，先获取作品 id 列表，然后逐个作品进行抓取。但是这样抓取花的时间比以前要多很多。
相关 issues: #23
Fanbox 中有些图片无法以原图打开，图片会回传一个 status 500 的 response 而内容是 failed to thumbnailing。
现在下载文件失败时，如果 Chrome 返回的错误代码是 SERVER_FAILED，则把这个文件的 URL 从 originalUrl 改为 thumbnailUrl 进行重试。
出现此问题的页面网址： https://takuya-yoshimura.fanbox.cc/posts/1237796
Fanbox 官方对此问题的回复：
谢谢你的兴趣。
我们是pixivFANBOX办公室。
请注意，pixivFANBOX不允许上传高度和宽度都大于16,000px的图片。
就你发给我们的网页而言，你所提交的图片有可能超过上述尺寸。
如果你想查看更大的尺寸，请联系创作者。
据此推测，可能无法下载的几张图片是宽高都太大了。如果改为上传文件的方式或许就好了。
当下载卡住时，主要有两种可能的原因：
- 网络错误
NETWORK_FAILED - 用户取消
USER_CANCELED
这些错误可以被下载器捕获到，下载器会重试下载。只需要等待下载器自动重试即可，不需要手动暂停，然后再开始。
之前版本在重试时存在问题，导致重试机制失效，现在已经修复了，可以正常重试下载。
之前导致重试失效的原因：后台脚本会保存要下载的文件的数据，包括 id。当下载失败之后，下载器向后台脚本发送重试请求，但是因为这个文件的 id 已经保存过，后台脚本不会再下载它。现在去掉了对重复 id 的检测，所以可以进行重试了。
这个选项默认未开启。
开启之后，如果投稿里有封面图片，就会下载。
封面图片的序号 {index} 总是 0。
主要是投稿类型为 image 的文章，可能正文文本是个空字符串。以前没有判断这里，导致可能会下载到空的 txt 文件。现在修复。
以前下载器下载时，即使网络没有发生异常，也可能会卡住。
现在优化了一些，网络正常的话应该不会卡住了。
但是因为网络出现异常导致下载中断的情况，还是会卡住。
以前导致异常的原因推测是：一些文件在下载时使用的 id 可能会重复。现在修复了此问题。
以前如果暂停或者停止下载，然后点“开始下载”，有些文件会提示下载失败。失败的都是下载器生成的 txt 文件。
现在进行了优化，不会出现这个错误了。
原因是下载器自己生成的 txt 是 blob url，下载一次之后释放了了 blob url。现在不再释放，就可以重复下载了。
其他文件都是 fanbox 的 url，直接交给浏览器预去下载的。
background.ts 里修改网络请求头的时候，进行了优化，只对 api.fanbox.cc 网址的请求修改其请求头，不会再出现下面的报错信息了：
Invalid header specification '{"name":"Origin"}'.
同名文件指的是处于一个文件夹里并且完全同名的文件，如 user 文件夹里有两个 a.jpg，它们就是同名文件。处于不同文件夹里，或者文件后缀名不同的，不是同名文件。
现在，浏览器在下载到同名文件时，会自动在后面加序号，而不是覆盖。
有的用户可能希望覆盖同名文件，主要场景是：以前对一个用户进行了抓取，现在再次抓取，把以前下载过的文件又下载了一遍，被重复下载的文件可能是同名文件。同名文件的后面加上了序号，需要搜索出来进行删除。如果用新文件覆盖掉旧文件，就比较方便。
经过我和一些群友的讨论，发现有些时候不能使用覆盖的方式，否则会导致意料之外的情况。所以现在下载器依然保持着让浏览器添加序号的方式。
不能使用覆盖的场景如：
- fanbox 允许一个文章里有同名文件，例如画师可以在一篇投稿里上传 2 个名为
a.zip的附件。如果覆盖就可能会导致只有一个文件被保存，这是错误的。 - 某个画师发布的两篇投稿，它们的标题、投稿时间、附件名字完全一致。在大多数情况下，这将产生同名文件。如果覆盖就会导致最后只保存了一篇投稿里的文件。
以上情况都有实例。用户并不能预知何时会产生同名文件，下载器也不能预知。（下载器虽然可以检查本次下载的文件名，但是并不能检查硬盘上的文件，所以不能妥善处理同名文件的情况）。下载器为了能处理上面的特殊情况，目前只能让浏览器自动给同名文件加序号。
以前文件名重复时，下载器会在重复文件的后面添加一串随机字符。这种处理方式不太好，现在进行了优化。
现在不会给重名的文件添加特殊符号，而是由浏览器处理，如果有重复的文件，浏览器会自动在后面添加序号。
Fanbox 文章的嵌入来源里有个 Google Froms，但由于没有见到画师使用，所以之前对它是有一些猜测的成分的，导致不能正确提取它的链接。现在进行修复。
附一个 Google Froms：
https://docs.google.com/forms/d/e/1FAIpQLSe6yLe2XKQnVH221WLffUeRJUpx1NALNGqkdcddWsh4tSMesw/viewform
之前日期设置只能输入一个日期，然后设置大于、小于。
现在改为设置日期范围。
可以实现和之前相同的功能，还能设置一段时间范围。
如果命名规则里使用了 {name}，但是 {name} 产生了重复，那么下载器会在 {name} 后面添加一些随机字符。
之前这个随机字符的长度并不固定，所以现在将其调整到固定为 8 个字符。
本次任务抓取完成时的时间。例如：2020-10-21
增加了日期和时间格式的设置项。
感谢 VHlqg 提交的繁体中文优化，以及 readme。
以前最大只能有 3 个同时下载线程，现在允许最大到 10 个。
之所以之前的限制只有 3 个，是因为同时下载多个大文件的话，可能一些文件下载完但是进度条没有变化，下载就卡住了。现在应一些用户的要求加大了下载线程，但是出现这个情况的几率也会增加，希望他们不要来找我问为什么。
热心群友（滑稽）报告了一些抓取出错的情况，经过排查，是投稿数据里 body 里的资源数量和资源 map 里的数量不一致导致的。比如 https://sakichisuzu.fanbox.cc/posts/1123079 body 里显示应该有3个图片，但实际上 imageMap 里只有2个图片，导致出错。另外其他画师的投稿还有 file 对不上的类似情况。现在做了判断，进行修复。
issues 3 报告早期一些作品抓取出错，一看确实，早期有种投稿类型是“entry”，它的所有内容都保存在一整段 html 里，存放在 body.html 字段。现在对这个问题进行了修复。
保存投稿中的文字
如果启用这个选项，那么文章的正文会和文章里的 url 保存到同一个 txt 文件里下载。
psd 和 clip 都归属于“源文件”了。
鼠标放到文件类型上，会显示包含的后缀名。
如果一篇文章里多个文件的原文件名相同，如 https://countryside.fanbox.cc/posts/968477 有一个 zip 和一个 pdf 的文件名都是“shokumusu_c94_r18”，导致了程序内部出现错误，只下载了同名的第一个文件。现在进行修复。
同一个段落里有多个链接的，如 https://kirastar3626.fanbox.cc/posts/1116141 ，之前只抓取到第一个。现在做出优化，可以都抓取到了。
https://twitter.com/i/web/status/ 加上推文的 id
fanbox 域名从 www.pixiv.net/fanbox 迁移到了独立域名 fanbox.cc，对此进行了适配。
- 配置不能充分共享。
因为 fanbox.cc 的域名前缀可能是用户名，例如 user1.fanbox.cc 和 user2.fanbox.cc 就是跨域的了，所以如果在 user1 里修改了设置条件，但在其他用户页面里是读取不到的，读取不到就会使用默认设置。所以这点比较坑。还好一般人不会赞助太多的用户，每个用户自己改一遍设置吧。
- 设置 Origin 时发生错误
有时候扩展会发生错误：
Unchecked runtime.lastError: Invalid header specification '{"name":"Origin"}'.
background 会对没有 Origin 的请求设置 Origin，fanbox 本身的一些请求可能会导致抛出这个错误，但扩展发起的请求不会出现这个错误。
这个错误目前似乎对使用没有影响，也不会导致 fanbox 自身的请求失败，先不管了。
去掉了 manifest.json 里的 "*://*.pximg.net/*"，因为 fanbox.cc 里用户的文件似乎都是 downloads.fanbox.cc的，没有再使用 pximg.net 了，所以去掉。
话说 fanbox 下载器是把 url 交给浏览器下载的，所以实际上也不用在意文件的 url 了。
从 www.fanbox.cc 或者以用户名为前缀的 any.fanbox.cc 去请求 api.fanbox.cc 的 url，请求失败。
扩展在前台脚本里发送出的 fetch 请求，没有 referer 也没有 origin。这好像有点奇怪。
我在 background 里设置 requestHeaders，把 referer 和 origin 都设置成 www.fanbox.cc，控制台看着是添加上了，但是实际上请求仍然失败。
搜索了好久，原来 chrome 79 开始，扩展修改的请求头如果不符合标准（我理解的是像 origin 这样本来不应该修改的请求头），会先向服务器发起 CORS 预检查， response headers 里有 access-control-allow-headers 和 access-control-allow-origin，可能浏览器是根据这些信息来判断的，如果我们的跨域请求被拒绝了，那么我们的这个请求，包括自己修改的 header 就不会被发出去。
如果要欺瞒 CORS 检查，需要添加 extraHeaders 才行。这个标记以前不知道。
相关文档：
https://developer.chrome.com/extensions/webRequest
搜索 extraHeaders 查看这部分说明。
当扩展添加 referer 和 origin 请求头的时候，实际上使用的是 details.initiator。这是因为这两个请求头都必须和发起请求的页面的网址前缀相同：
如果发起请求的页面的网址前缀是 www ，也就是 www.fanbox.cc 开头的，那么 referer 和 origin 设置成 https://www.fanbox.cc 就行。
但是如果发起页的网址前缀不是 www（如果用户自定义了用户名，那么 www 就会变成用户名，如 https://kyomoneko.fanbox.cc），这时候服务器可能检测了一些条件，要求 referer 和 origin 必须符合这个用户名，也就是需要 https://kyomoneko.fanbox.cc 才行。此时如果设置成 https://www.fanbox.cc 那么请求不会报错，但也不会返回任何数据。
今天看到谷歌商店拒绝了这个扩展，说是虚假宣传之类的。我去掉了 logo 上的文字，再试试。
结果：仍然没有通过审核。
- 解决了不能抓取 mega 网盘链接的问题。
之前的正则表达式没有涵盖网址里的一些特殊字符，导致匹配出错，现在修复。
目前的正则是：
/http[s]*:\/\/[\w=\?\.\/&\-\#\!\%]+/g
- 之前在段落包含 links 字段时没有保存里面的链接，现在加以保存。
某些 Article 类型的投稿里，图片在文章里的顺序，与图片在附件数据里的顺序不一致。之前是按照附件数据来存储数据，导致顺序错误，应该以文章里的顺序为准。现在修复了这个问题。
示例投稿： https://www.pixiv.net/fanbox/creator/236592/post/954377
正式发布
如果因为某些异常导致下载卡住，那么暂停、再开始下载，没有反应
下载的问题，大批量下载可能到最后一两个卡住
我的主页：
https://xuejianxianzun.fanbox.cc/
这个画师的免费投稿比较多：
这个画师有一些免费的大图：
https://www.fanbox.cc/@itsuwa0815
有 100 和 500 两档赞助，并且都有对应价格的资源
有对所有人公开的投稿
有图片
有 psd
-没有视频 -没有 zip
测试抓取 tag（标签分类）用：
https://www.fanbox.cc/@sakichisuzu/tags/%E3%82%AA%E3%83%8A%E3%83%8B%E3%83%BC
测试视频用
下载文件时可能遇到 SERVER_BAD_CONTENT 错误：
https://downloads.fanbox.cc/images/post/935/2s2e082blxescogs0wo4g4oo.jpeg Download error! Code: SERVER_BAD_CONTENT. Will try again later.
SERVER_BAD_CONTENT 就是 404 错误。请求的文件不存在。