我居然完成了备份discord的脚本，之前写的那个是水货，它只支持50条为单位dump，而且完全没法判定什么时候结束循环

于是我重新写了一个

当然和我的其他discord项目一样，它还是受到了某聊天室环境的影响，这次是ucc

I gaycar

garcar原名gaker，是个加拿大小屁孩，最喜欢干的事情就是在交通工具频道之外的地方，尤其是anime频道，刷交通工具的图片，难怪叫做gaycar；在我调查anime频道的历史时，我发现一开始几条消息就能看到gaycar的杰作了，可见这个频道建立的时候就受到了很多人反对；我现在总算明白为什么这个频道无论什么时候都有一群animehaters在那儿作妖了，原来这是它的优良传统啊（手动滑稽

在ucc这么一个活跃成员连20都不见得有的地方，一个人渣的出现对聊天环境的破坏比hrpc这种地方要严重得多，通常我管理这种小型聊天室的时候我会仔细审核成员的，然而raymond chan并不这样想，他出于猎奇能将drate chan这种苏卡放进nsfw频道，他当然也能干出留gaycar到处破坏这种事情来，而且更草的是，gaycar现在还是ucc狗管理之一

当然整个ucc的传统就是raymond chan瞎鸡巴搞，下面的人用过激的方式回应，无论在anime频道刷飞机还是在nsfw频道刷飞机都是如此🙃

ucc其实还有更过分的animehater，比如那个叫做jono的傻逼，是raymond chan的直系手下；某天raymond chan突然在anime频道里面挂起BJK的几十条消息，都和某件（二次元之外的）东西的娘化形象有关，jono这个娘炮最讨厌的就是娘化了，比如ucc就有条屑rule：

{"id": "667413725166305290", "type": 0, "content": "<@&279572070281773056> posting UCC \"chan\" will result in a suitable punishment.", "channel_id": "406933309189521409", "author": {"id": "223865652463534091", "username": "Jono(JSalty254)(CTzen)", "avatar": "6967c71ceccc1184bc518cef2bd638f9", "discriminator": "8331"}, "attachments": [], "embeds": [], "mentions": [], "mention_roles": ["279572070281773056"], "pinned": false, "mention_everyone": false, "tts": false, "timestamp": "2020-01-16T17:03:52.027000+00:00", "edited_timestamp": null, "flags": 0}

raymond chan挂出那些BJK的娘化形象发言就是为了拿jono取乐，草，这个troll狂魔为了troll人真的连亲妈都不要了，自己人都不放过；然后BJK就被关禁闭了，此时我感觉这事情是anime频道被橄榄的前兆，吓得我赶紧去写脚本了

II attachment reuploadin'

如果jono这些司马玩意真的准备橄榄anime频道，我估计它里面的附件也会回归虚无，所以我必须想办法存储它们，至少在discord的语境下（毕竟我已经写了那么多别的东西上传discord的脚本了），只需要将它们找出来，重新上传到一个在我掌控之中的频道里去，然后在消息备份里替换掉链接即可

而且保险起见，用webhook上传是最安全的（但用普通账号也没有遇到过被橄榄的情况，我从18年搞futaba.sh起就用nanakolover往我自己的guild里面塞了十万甚至⑨万张冻鳗色图，都没被橄榄），当遇到比8MB大的文件时，这部分文件就可以用nitro账号传了，既然是消息及其附件备份，我肯定不会像discord drive那样弄分卷压缩包这种操蛋玩意

还好ucc除了我外没人上传什么大文件，所以不会出现比我的nitro等级支持的最大文件体积（50MB）还要大的文件

为了能在discord返回的消息里面找到附件，我们需要知道每次discord返回的东西其实是个json数组，去掉数组前后的方框后，它剩下的是以逗号隔开的json对象，一个对象对应着一条消息，将对象与对象之间的逗号变成回车，就可以将消息分割成行，然后直接存储或者用for循环处理了；问题是}, {不见得是消息对象之间的特征，有时候它还是reaction列表之间的特征，有时候它还是附件和附件之间的特征（因为它们都TM是数组），所以我最后在后面加了id和type之后，它才终于能够只分割消息对象了，体现就是一次抓取消息最多只处理50条，如果计数出现了51，那它肯定把什么不该分割的东西分割了🤔

由于我们成功地将消息分成条了，除了获取附件信息外，还能精确获取每条消息的id，从而断点续传和增量备份也成为了可能，前者只需要在第一次抓取时设置before参数为上一个文件的最后一条消息id即可，后者只需要搞到上一个文件的第一条消息id，然后在脚本运行过程中加一个判断，如果当前消息id等于这个消息id，直接退出脚本，这样就完美地只处理了最新的部分🤔

至于附件重新上传，我不清楚怎么可能，但discord一条消息真的可以带多个附件，它们会存储为一个数组，用grep将数组那部分提取出来后，去掉数组前后的方括号，然后将}, {替换为}\n{即可，这次里面没有再嵌套数组了，直接替换即可，然后写个for循环处理它们

按照惯例每一个下载的附件会放在临时文件里，然后用for循环上传临时文件夹里的文件，尽管我写了for循环，但它只会被循环一次，毕竟里面才下载了一个文件；至少它比其他的写法看起来简单很多🤔

bash里面没有do-while循环体，所以只能先do一次（curl抓取50条消息，按照设置有直接抓取最新的或者抓取指定id之前的），然后进行while判断，循环结束（没有新内容拖）的标志是discord返回一个空数组[]，非常简单，而且也符合逻辑，比如对一个已经拖完的dump实行断点续传，它第一次请求返回的就是空数组，使得整个过程都不会开始🤔

ps. 用正则表达式来处理json，尤其是像discord消息这种对象套着数组又套着对象的json不是什么值得推荐的做法，正确的做法是调用专用json解析程序，比如jq；但我的所有discord脚本设计时就是为了能在ibm cloud这种什么都没有的小🐔🐔上跑，所以只能写成这个样子了🙃🤔

III deployment

实测拖anime频道花了两个小时半，mlp频道可能花了半小时吧，毕竟有大量附件重新上传的过程；但拖general和pictures频道时我没有使用重新上传，很快就完成了；现在我在尝试完全备份nsfw频道，毕竟死🐴白左raymond chan经常威胁要删掉nsfw频道，而且ums的nsfw频道的确被删了（毕竟那儿白左至少有三个🙃

至于dump大小，anime频道大约有1.5万条消息，dump有8.6MB；mlp频道有1478条消息，dump有966KB；pictures频道有两万条消息，dump有12MB；general频道有17.6万条消息，dump有87MB；nsfw频道有6.7万条消息，dump有38MB；考虑到discord消息高度冗余，压缩起来非常容易，哪怕包含general频道的dump了，它也能压缩成两个普通用户能上传的包🤔

对了，对于原来脚本就有的重新上传回去羞辱狗管理的antics，我给它加了一个greta笑话生成器，用来取代原版里小号可能用不了的嘲讽表情合集；最经典的greta笑话内容是两个萌妹和greta困在沙漠里面，我写了一个数组用来枚举萌妹，然后用随机数下标选择萌妹，这样就非常的草了🤔

function gretajoke {
    cuties=("Ann" "Chie" "Marie" "Yukari" "Fuuka" "Futaba" "Hifumi" "Riley" "Cosette" "Alice")
    cutie1="Cosette"
    cutie2="Cosette"
    while [ "cutie1" = "cutie2" ]
    do
        cutie1={cuties[((RANDOM%{#cuties[@]}))]}
        cutie2={cuties[((RANDOM%{#cuties[@]}))]}
    done
    echo "cutie1 chan,cutie2 chan, and Greta Thunberg were all lost in the desert. They found a lamp and rubbed it. A genie popped out and granted them each one wish. cutie1 chan wished to be back home. Poof! She was back home.cutie2 chan wished to be at home with her family. Poof! She was back home with her family. Greta Thunberg said, \\\"How dare you fucking call me Greta Chan! \\\""
}

草，我发现它这玩意有时候会出500错误，导致脚本无限循环；所以可以考虑写个迫真异常处理，如果500的话就不停请求直到不是500为止，当然这玩意不像py，每个请求都能返回一个对象，里面可以查返回码，好在discord的500和它的空数组一样是一段固定文字，请求下面写一个while循环即可，通常情况下这个while循环压根就不会执行🤔

当然我还发现它一开始的sed替换写错了，导致保存下来的json里type后面出现了两个冒号，不过这个好修复，由于只有type后面有两个冒号，一个sed -i就够了🤔

IV antics

我在ibm的小🐔🐔上跑起了这个脚本，跑的是只保存文本模式，感觉还是要慢一拍的，每秒大约只能处理四到五个消息（与此同时我的vps可以一秒钟处理50个），可能是因为它的CPU太弱吧，毕竟它处理每一个消息需要调用好几遍grep和sed

但至少我可以在ibm小🐔🐔上跑，这样我折腾的那么多正则表达式可以说终于得到了回报（迫真

V assumptions

我猜测无论我疯狂20线程上传东西，还是不设置暂停时间地疯狂下载东西，discord仍然没有橄榄我的小号，而当我用web端时我的账号却经常被橄榄，最重要的一个原因是discord利用一个叫做science的api来监测部分行为，而我用bash的时候压根就不会用到science，discord顿时眼瞎了，失去了橄榄我需要的感官（手动滑稽

当然这是毫不靠谱的猜测，还是用webhook保平安吧🤔

接下来我打算写一个更加强力的玩意，用多线程来完成附件重新上传的过程，已知附件大小也在消息json里面，可以找出来并按照大小归类到某个线程里面（一个nitro线程、若干个webhook线程）