话说wp手机版一年前还是半年前来着砍掉了传统格式文章的创建，强推起了它那个什么区块模式（悲🤔然而我这个站用的是markdown解释器，所以它只能用传统格式（确信🤔
其实只需要在右上的选项里点html格式，然后随便写点啥发表，再修改的时候就是传统格式了（确信🤔我猜测在点html格式然后写入纯文本时，它保存到wp-posts表的东西就是纯文本，而用web版的md编辑器时它保存的也是纯文本（区别于没装md编辑器时它保存的是修饰过的html代码🤔
另外，用html模式可以看出它的所谓区块模式只不过是用一个特制html标签圈住一个区块而已🤔理论上来说md渲染器可以保留html标签，进行html和md的混合渲染（换句话说就是既用区块模式又用md），但为了避免各种奇怪的问题，我这边只用md，不用html🤔而且我这边是用一级标题来实现区块的功能，所以我更不需要区块模式了（确信🤔
thonk
多年的blog实践证明，在数据库里保存html除了会产生额外空间占用外，还会产生一系列非常蛋疼的问题，比如一篇有大量排版的文章，渲染后看上去是正常的，但当你打开html模式看它的html代码时，你会发现它标签什么的全たま乱套了，里面插入了十几个标签，改都没法改的那种🤔而且试图将这段文字复制到另外一个html编辑器里时，它的排版绝对要乱掉（悲🤔而且后期文字一多，比如到几万字这个级别，它能卡到打一个字产生肉眼可见的延迟，就像批乎浏览了几千个答案之后的页面一样🤔无论是qq空间的、wp的还是ao3的html编辑器，到后期都会便乘一坨⑩，我当时在ao3上写迫真ソナ，排版乱到最后花了好几个小时才迁移回md，基本上算是重新排版了一遍，从此我再也不用html编辑器了（悲🤔
而使用md渲染器，保存的只是带排版信息的纯文本，这些纯文本可以随便复制粘贴并组合，排版信息绝对不会丢失，它在最后一刻才开始一次性转html并渲染，哪怕你需要将html粘贴到别处去，它的html格式也是非常工整的，不会到处乱用标签（确信🤔况且这么算下来，还能迫真节省数据库空间，尽管也节省不了多少就是了🤔
newpixiv
昨天本来准备找点cuties impact破处的pixiv色图，结果到最后我撸出来了一个全新的pixiv拖站脚本🤔和phpdisk垃圾网盘搏斗多年，已经让我养成了分析一个站的网络请求看它有没有ajax的习惯🤔而改版后的pixiv刚好大量使用了ajax，所以我需要找的信息全在ajax请求返回的json里面，用bash分析json可比分析html轻松多了（确信🤔
所以，这玩意比我18年写futaba.sh时搞的pixiv脚本效率高多了，而且代码看上去也简洁多了🤔找到所有图片后写入list文件然后用aria2批量下，但别忘了加上一条--header "Referer: https://www.pixiv.net/artworks/1145141919810"或者诸如此类的东西，免得它报403🤔pixiv批量下图片反正比那个什么sankaku好多了，一点也没有限制，除了貌似限了一下总速度，25MB/s，四舍五入下来200Mbps，还可以接受（迫真🤔
下一步，是不是可以把这玩意搞成github actions或者ibm cloud（那个已经有了，futabruh.sh）或者诸如此类的玩意，全程白嫖呢🤔问题是哪儿有可以白嫖放pixiv图片的地方，考虑到pixiv上面的色图一大半是属于“二刺螈儿童色情”的那种，比如什么klee或者早柚酱的图，它肯定不适合在没有任何处理的情况下扔discord drive（半恼🤔backblaze？那玩意只有10GB免费空间，而且每注册一个账号需要验证一次电话，烦skr人🤔搜书盘？谁能解决验证码自动识别谁去搞吧，它也只有10GB空间🤔
barbruh
我去，数据库又たま崩了，看来我得清理些空间然后在那10GB空间里面建一个swap🤔挂上一个10GB的block storage，清理出了3GB文件，并转移到了三号机🤔不错，除去swap它还剩2GB🤔不清楚为啥vultr的block storage最小只能设成10GB，不然我可以搞一个2GB空间专门挂swap🤔
jajaja
在我看了一会儿github actions的教程之后，发现它貌似有一个叫做upload artifact的功能，可以把运行脚本过程中生成的文件打包上传到它的暂存服务器上，这样的话就可以直接下了🤔所以，我就随手撸出来了用github actions拖pixiv的玩意：
https://github.com/AquaCriUGUU/pivix-antics
它有一种手动触发模式，可以在手动执行action的时候往里面填参数，比如pixiv的artist id或者tags或者诸如此类的东西🤔甚至连headers也可以填进去，对了，我最好在readme.md里写下如何制备headers，不是所有人都会玩f12抓包这一套🤔
JAJAJAJAJA
在拖pixiv所有破处色图的过程中，这些色图直接撑爆了github action可怜的14GB可用空间🤔这让我想起当年在ibm cloud上写的定期按照空间上传backblaze的玩意，也许github action也可以设置为下完指定内容就开始上传？🤔
问题是它这个玩意上传artifact的操作不是在一个step里的，而是作为另外一个step超然于其外的（所以用文件总大小来决定什么时候上传是别想了），而它在外面也没有提供一个类似于循环的玩意，可以设置循环终止条件来做下载和上传的循环（悲🤔
不过至少它的每一个step提供了终止条件，而且可以将这个终止条件设置为检测里面的某个文件存在与否，比如列表文件，它要是不存在了接下来的step就能直接不执行🤔
那么我目前想出来的主意就是：用bash将一组steps（下载、上传和清理上传后的rar文件）复制114.514次，然后将那一坨庞然大物保存成yml，然后执行它🤔每一组steps里，下载step将列表文件分成两部分，开头的指定数目行（比如前1145行）挪到wiebitte文件夹里面跑aria2c，剩下的部分生成另外一个列表文件🤔那么当这个列表文件里的行数小于1145行时，前者会生成一个包括所有行的文件，后者会生成一个空文件🤔那么当列表文件为空时直接将其删掉即可，这样下一组step监测到列表文件不存在了，就直接跳过🤔剩下两个steps监测的是rar文件，如果rar文件都上传完并删除完毕，而且新的列表文件也没有的话（意味着没有东西被下载，也没有rar被生成），它们接下来也会直接跳过，这样接下来所有的steps都全部跳过了（确信🤔
外加我还在下载开始前先把分析出的list文件上传成artifact，方便以后断点续传🤔这样，我就可以驱动它搞大型项目了🤔对了，它现在貌似在拖破处色图，可以去围观下🤔神奇的是每1145个图片文件拖的时候只需要半分钟，下载速度能够突破100MB/s，但上传的时候居然需要五分钟🤔这玩意性能居然™比我的三四号机加起来还要高可还行🤔我们来看下，它能否在6个小时的硬性限制前跑完🤔
todolist
- 按照占用空间而非图片文件数目来分step，这在futabruh.sh里面是极其自然的搞法，但在可以多线程的pixiv里怎么看怎么不合适🤔实在不行这么写吧，它不是一次可以最多下64个文件吗，那么就写一个while循环，循环内每次挪64的整数倍个文件到新list里面，下载完统计大小，没超过某个大小就接着挪，超过了就去rar打包（确信🤔反正什么时候挪完什么时候删掉list就vans了🤔当然如果这个值就是64的话，我估计批量下载的流水线肯定要经常断掉，也许会造成一些速度损失，也许不会造成多少，毕竟这玩意120MB/s的下载速度实在是离谱🤔我回去做个测试（迫真🤔
比如（这鬼玩意是我在公交上写的草稿，最终成品见https://github.com/AquaCriUGUU/pivix-antics/blob/AquaCriUGUU/.github/workflows/antics.v3.original.yml：
mkdir wiebitte
while [`space` -lt (quota*1024*1024-114514)] # 可能它会超一点点，因为它只有超了才能结束循环（悲
do
head -((multiplier*64)) list > wiebitte/list
tail +$((multiplier*64+1)) list > list2
rm -f list
[ -s list2 ] && mv list2 list
cd wiebitte
aria2c -i list
rm -f list
cd ..
done
mv wiebitte xxxx
rar xxxx xxxx.rar xxxx
- 给list方式（提供一个list文件的url，直接开始下载，而非花几个小时重新分析链接）一个新选项，让它可以将rar文件名命名为任何给定名称，还好github actions加参数实在是太方便了，比bash脚本方便多了（确信🤔
-
给rar加上-hp参数，上密码，这样等github搞完就可以直接撸到discord drive上了（迫真🤔话说这玩意的yml写起来至少我感觉和bash也没啥区别，除了参数实在是灵活的批爆🤔当然这玩意既没有循环也没有流程控制，所以流程控制需要在bash部分完成，并且需要一点技巧（确信🤔不过它居然支持bash变量，这个是我没有预料到的（🤔
-
- 话说public repository的actions居然可以被所有壬围观，而且artifact居然可以被任何账户下🤔更生草的是你需要一个github账号才能下artifact，所以如果想往discord drive导的话，就得像pixiv一样，获取header参数（悲🤔所以我才准备重写一遍分step方式，不然一个包才几百MB多没意思🤔
-
不过如果写成上述那样的话，这两种分step方式能否共存？🤔也许将quota直接设置成1甚至0的话，那么它每次都只执行一次下载，这样它就能退化到按照图片数目分step了（确信🤔除了这种情况下只能设置成64的整数倍，至少1145是别想了（悲🤔或者，我可以把这个值也放开得了，不需要它每次都乘以64，大不了把默认值设成256啥的🤔よし，回去就折腾v3，说不定我能刚好看见那个破处的dump超时，然后我就去想办法续（确信🤔
fischlthonk
另外那个破处dump在第37个包时完成了，倒数第二个包只有432MB🤔它默认按照时间逆序，所以最后几个包都是基本上15年前的老图了（确信🤔有意思，看来我回去折腾新的分step法后，也许包数量还能再降（确信🤔
另外我敢肯定pixiv上面带破处标签的色图，90%都是没眼看的，画风合我口味的只有百分之个位数（确信🤔所以，这些玩意我以前都是当troll material爆破discord聊天室用的🤔当然pixiv色图用来找炼铜出警魔怔壬的乐子可以说是我的优良传统了，最早可以追溯到18年（迫真🤔
luminethonk
新版github actions脚本用两个多小时跑完了，生成了7个文件，其中最后一个只有几百MB，别的文件都是⑨GB以上的（尽管我设置的quota是8192🤔可以去这里围观一下（确信🤔
对比这两者花的时间，我们可以发现大型打包比小型打包居然多出了将近半个小时🤔
现在遗留下了这个问题：如何将这些玩意导回比如某台存储vps？毕竟github只保留⑨0天🤔
这个也好办（确信🤔而且貌似比pixiv简单很多，比如这样（当然，搞``的方式和pixiv基本上算是大同小异了：
function dumpgithubartifacts() {
for links in `eval "curl '1'parameters" | grep -Eo "/.*artifacts/[0-9]+" | sort | uniq`
do
for file in `eval "curl -I 'https://github.comlinks'parameters" | grep "[L|l]ocation:" | sed 's/[L/l]ocation: //g;s/[L/l]ocation://g'`
do
aria2c "file"
for file2 in `ls | grep zip`; do unzip "file2"; done
rm -f *.zip
done
done
}
然后我发现github在artifact上居然和它项目首页的打包项目一样，限制单线程而且还限速，只有10MB/s（悲🤔看来，这玩意尽管下载和rar的速度够快，但重新上传和下载的速度还是挺拖后腿的，不过它有长达⑨0天的保存时间，而且我的存储vps肯定不会像我在vultr开的临时vps一样很快就要删了，所以一切都可以慢慢来（确信🤔
好，那么我们可以将那两个github action页面用这玩意跑一下，然后用time记录时间，看下大文件打包和小文件打包下起来哪个快了（🤔当然，其中有一个是ssd，所以解压zip应该会快一些，所以这玩意完全只是图一乐🤔
barbruh
草，我三号机上的下载挂了，那台机子动不动自动重启，难怪我再也没用它挂过u2（悲🤔另外一台机子跑出了⑨4分钟的结果，其实对像我这样20年前就在使用pc的老壬来说，这个时间还是可以接受的，我们十几年前挂机下东西时间都是以天计的（迫真🤔干脆在那台机子上跑下v3得了，这样硬盘速度的差别就没了（确信🤔
time dumpgithubartifacts https://github.com/AquaCriUGUU/pivix-antics/actions/runs/1652401659
# real 94m19.679s
# user 7m24.458s
# sys 6m17.907s
time dumpgithubartifacts https://github.com/AquaCriUGUU/pivix-antics/actions/runs/1653489286
# real 92m59.414s
# user 7m15.158s
# sys 6m8.410s
看起来没啥区别嘛，另外这个也包括解压的时间（确信🤔打包下来这些东西貌似49.2GB，话说我突然想到一个问题：github actions每次打包aritfact的时间都那么长，是不是因为它在尝试压缩这些根本压缩不动的图片视频还有压缩包？🤔而且如果我那个项目是个private repository的话，我只有2000分钟的actions执行时间和0.5GB的artifact存储，根本不够存储色图的（悲🤔
