✨ add uploader video download support #39
Conversation
|
This pull request is being automatically deployed with Vercel (learn more). bilipi – ./🔍 Inspect: https://vercel.com/siguremo/bilipi/ax5v98ezm bilili – ./docs🔍 Inspect: https://vercel.com/siguremo/bilili/2x5xv1lf0 |
|
删除不必要的改动吧，这个 PR 只包含你所描述的 space feature，尽可能不要包含其他的改动，当然也不要包含 ide 配置文件 |
|
ok |
|
刚刚看了下，想法非常棒，原来我对于 UP 主空间视频下载的想法是每个投稿一个目录，上层再加一层目录，这样也就相当于在外层多次调用，当然这需要我把原来的主函数处理一下，但一直以来懒得弄。 你的这种直接为 UP 主空间做了一个解析器的想法非常简洁且有效，但是有一个问题就是，这种方法并不适用于 #25 ，对于它我仍然需要一次循环调用。 另外就是，对于 UP 主投稿，是每个投稿放在一个目录下好呢，还是全部放在同一个目录？哪一个会更合适些呢？ 另外有注意到你修改了 dash 无法获取时自动调整为 flv 机制，但代码太冗余，直接再次调用自身即可（参数换为 flv）。不过该机制是否在该 API 内实现需要考虑下，我的想法是在 space API 内实现（尚需斟酌，这样也会出现 space API 与 acg video API 的不对称），当捕获到不支持 dash 的异常的时候采用 flv 格式。 以上问题皆可讨论 (・ω< )★，近期空闲时间不多，需要辛苦你做一些改动了（感谢～），不过我会尽可能 Review 的～ |
|
关于 cookie 的保存，暂时我感觉没必要。然后各种默认参数先不要修改。至于正则，我是没明白修改后有什么用。还有去掉某些 Unicode 字符的操作，这些修改最好有一个理由。不过这个 PR 还是全部恢复吧，这个 PR 只涉及 UP 主个人空间下载问题，如果需要修改其他内容的话，在 issue 里讨论。 |
SigureMo
changed the title
因为我的使用场景是cmd 里面，cmd 不支持有些特殊字符，会变成乱码。 |
字幕默认的 xml 下载 ，ass 下载要更通用一些把，，，， 修改是否询问下载就是为了解决 #25 的地方，批量up 自动下载。自动下载还要输入是否选择下载的参数有点反人类了，虽然可以通过参数解决， |
#25 的提出本来就有其他的解决方案，就像是你前你说的ffmpeg 和you-get,youtube_dl 一样，本身提供了单个下载，需要下载多个，就是用命令行进行多次调用即可，明明 bat 脚本可以直接解决，为什么还要做一个格式特定的文本进行操作呢。 这个我也不清楚， 嗯 |
bilili 面向的是现代的支持 Unicode 的终端，建议使用 Windows Terminal，不过后端选用什么 shell 是 cmd 还是 powershell 就随意了。
这倒确实是个问题，但是否直接使用正则方式来修改需要考虑下。不过这种修改方式确实是最简单的，只是在语义上有些不是尽如人意。
bilili 是命令行工具，但不一定完全面向自动化啊，也有可能是人手动来运行呀，如果没有那步确认，你会发现她会直接开始下载，你并不知道她到底选择了什么具体的清晰度等等（该信息会被直接刷掉，就完全没有显示的意义了），这步确认是在自动化与人性化的折衷，自然不能两者都做到最好，但我觉得能通过参数调节就好了。另外我觉得没必要将跳过作为默认参数，真的需求自动化的一定会把所有参数都看了的，我又木有做太多的参数…… 另外 FFmpeg 也有
#25 中我提出的解决方案是类似于 aria2 的解决方案，其重点是每个 url 可以指定自己的参数，当然这个可以通过 shell 脚本实现，但我觉得各自解析后统一下载是否会更好？这样下载就不用跑多遍了，而且有一个统一的进度条，界面更加友好一些。不过从另一方面来说，这种从文件读取的方式其实更加适合自动化调用，这种情况下的人性化需求其实并没有那么高了，所以我也在纠结这个要不要做，至少现在是一直搁置的。 |
|
关于 UP 主视频下载，我想到一个问题，如果现在使用选集功能的话，并不是按投稿来计算的，而是按 P 计算的，比如我想要下载某 UP 主最近三次投稿，但最新投稿分了 3P，那么只会下载最近这一次投稿了，这也许会影响选集功能的效果。所以我现在对所有视频直接放在同一级目录中还是有所顾虑的。 |
尽管我把从up下载单独拆出来了一个目录，但是这个问题，的确是没有办法，不过我并不使用这个功能，直接全部下载就好了emmmm |
简单就好啦，能用就行，，，，， |
这个对于我来说也没有这个需求。测试的时候需要知道这个东西。但是他成为了一个合格的工具之后通常是默认的界面不应该这么出来的，可以通过配置参数让运行的时候显示这个东西。 昨天批量下载了一堆的视频和动漫，基本稳定，还是主要使用都是希望他可以自动化的下载东西的，这个东西又没有打包，不行的话，他们手动到包源码里进行修改就好啦。 |
|
新的PR 已经提交，里面 主要修改了一个repair_filename， 添加了对投稿视频下载时额外增加一个文件夹用于保存整个文件夹 |
|
emmm，貌似没有删掉与 up 主无关的代码呀，自动保存 sessdata 什么的特性我没有一票否决，而是说不应该在这个 PR 里实现，这样我不方便 review 和 merge。每个 PR 所涉及的功能应当尽可能独立。那些修改完全可以继续讨论，但应当在别的 issue 或者 PR 里。 白天只能使用手机看代码，上面那些我也会晚些回复。 |
emmmm，主要是我这边已经不知道原来的地方写的什么了，就当是作为参考了，里面逻辑应该是一眼就可以看出来我添加了什么部分的把~~~ |
|
这个页面下的 Files Changed 选项卡下可以显示你所有的更改的，我晚上自己改一下吧。 |
|
自我调用如何实现？我这边还是出现了异常报错,我又改回来了之前的那种，另外文件夹重命名的地方有点问题，我稍微做了修正 |
|
就是文件的名称最后是 ..... 的时候，写入文件或文件夹时会直接被隐藏掉，这样文件就会被隐藏掉，因此我把里面的。 都替换掉了 |
| """ 修复不合法的文件名 """ | ||
| def to_full_width_chr(matchobj): | ||
| def to_full_width_chr(matchobj): |
There was a problem hiding this comment.
这个我不知道欸，只是重命名的时候，发现这个东西没有命名成功
There was a problem hiding this comment.
这个不需要放在外面，是我写的有问题了，刚才测试了一下
| @@ -96,8 +96,9 @@ def to_full_width_chr(matchobj): | |||
| filename = regex_path.sub(to_full_width_chr, filename) | |||
| filename = regex_spaces.sub(' ', filename) | |||
| filename = regex_non_printable.sub('', filename) | |||
| filename =filename.replace(".","") | |||
There was a problem hiding this comment.
就是文件的名称最后是 ..... 的时候，写入文件或文件夹时会直接被隐藏掉，这样文件就会被隐藏掉，因此我把里面的。 都替换掉了
Linux 和 Mac 确实会自动隐藏 . 开头的文件，但与文件结尾有关吗？你的实现为什么直接把所有 . 全部删掉了？
There was a problem hiding this comment.
文件名最后时点的时候，文件创建出来就没有 . 了，然后找不到文件名称就会报错
There was a problem hiding this comment.
我这边测试了一下
https://www.bilibili.com/video/BV1df4y1q7SL?from=search&seid=104752438868448442
我这边主要是去掉了，base_dir = touch_dir(os.path.join(config["dir"], repair_filename(title + " - bilibili")))
中的 - bilibili 后缀，导致的后缀最后是 ... 的时候会自动隐藏，导致写入文件找不到文件夹，如果添加上之后就不会报这个错误。因为后缀统一修改成为了 - bilibili .
There was a problem hiding this comment.
https://www.bilibili.com/video/BV1df4y1q7SL?from=search&seid=104752438868448442
去掉 -bilili 之后的报错
video_dir = touch_dir(os.path.join(base_dir, "Videos"))
File "c:\users\xin\appdata\local\programs\python\python38\lib\site-packages\bilili\utils\base.py", line 49, in touch_dir
os.makedirs(path)
File "c:\users\xin\appdata\local\programs\python\python38\lib\os.py", line 223, in makedirs
mkdir(name, mode)
FileNotFoundError: [WinError 3] 系统找不到指定的路径。: '别爱我，没结果，除非.....\Videos'
因为文件夹在创建的时候直接自动隐藏掉 .... 导致创建的文件夹是这个样子的
别爱我，没结果，除非\Videos'
There was a problem hiding this comment.
隐藏掉？我没有删去 .... 的逻辑啊，能测试下我原版的是否有这个问题吗
There was a problem hiding this comment.
原版，我刚才下载测试了， 因为有 (title + " - bilibili") 的后缀让最后的部分不会是.... 因此不会产生这个问题
去掉了 " - bilibili" 就会有这个问题
但 bilili 设计之初便支持本功能啊，我不是很希望某一种下载方式不支持该功能，而且这也并不是无法实现的问题。
关于 youtube-dl，略有耳闻但没深入了解，以后有机会去学习一下。 现在 bilii 的基本调用方式基本稳定，我不是太希望在修改现有功能的前提下去适配新功能，如果真的必要我可能会舍弃新功能。 |
|
关于 UP 主视频下载，在我之前的设想中，是先令 bilili 支持批量下载（#25），然后额外添加一个 UP 主视频解析器，之后通过管道来实现，就像这样 bilili-parser <space_url> | bilili -d /home/sigure/vidoes --disable-proxy但这样使用起来貌似比较麻烦，所以我也一直没有去实现，这个计划也是一直搁置，但 UP 主主页视频下载我是早就有计划的。 关于这个是否直接使用一级目录来实现，我觉得还是需要考虑下，这个并不是只要能用就可以的。 |
|
太多无关改动了，还有一堆格式化问题、注释问题、冗余代码问题，下次遇到这样的我就直接 close 了。恢复这些再去改动，还不如我自己从头来写效率高。 |
二级目录昨天刚刚修改好，我晚些传过去 |
因为我是windows 用户啊 ,冗余代码那个我昨天按照你说的修改了，自调，修改参数，然后不知道为啥报错了，不想找原因，于是就直接还原了 |
|
实际的下载效果如图： |
这个是可以实现的，但是需要在增加一个参数，或者更改循环判断的逻辑，不过那样就比较麻烦了。 |
旧的功能很好啊，我修改的地方除了设定的部分，其他的部分是都是在完全支持原有的逻辑的基础上进行的扩充，，，， 对于正则的修改，是完全兼容之前的，这个有测试过，只是稍微扩充了一下只输入 av bv 号的时候也可以进行下载。 |
|
还有我这边遇到了 下载过多造成的接口出现 下载请求被禁止的情况，目前主要是 下载 xml 的字幕的时候会出现 api/subtitle.py 里面是不是缺少了异常包的导入 我这边异常的时候，看到了 |
唔，下载的稳定性的话，昨天下了一天，下了将近200G 把，暂时 space 是稳定的 |
我没说这些修改不能加，就是你放在一个 PR 里我只能一起 merge 或者一起 close，如果你说你只有一两个这样修改还好，但你这样改了一堆直接塞给我我怎么处理？而且大多数改动在我看来是完全没必要的。 就那个异常处理，确实是我忘记加了，你单独给我一个 PR 我随便扫一眼就直接 merge 了，但你突然在一个 PR 里夹杂这么多私货我觉得是不合适的。 |
|
每一个改动都应当有充分的理由，但你的改动里明显很多我是完全不理解的。比如为什么删掉 所以我让你把单独的，纯粹的，space 相关代码抽出来，我才能专注处理这一件问题。 |
为什么保留 -bilibili 呢，纯粹的文件名很舒服啊，当然保留也是可以的，youtube-dl 里的下载就会保留下载视频的具体地址。 这些都是无伤大雅的东西，不是主要的，当然主要的只有一个space api 和相关调用。 |
很抱歉我并不是经常使用git ，不是很了解git 的设计原则。 |
|
如果运行出现了问题，我会配合进行调试（可以提供远程） |
|
不想跟你说了，我全程只说了一件事，抽单独一个 feature，但你到现在都坚定认为自己做的都有理由，我说你有理由另开啊，你这样我怎么 merge。谁说这是 dev 分支的，dev 分支都是 owner 主动开的，owner 也是有权限决定是否合并到 dev，如果你认为这是你的 dev 请自行维护。 |
概述
本 PR 的类型（至少选择一个）
✨ feat: 添加新功能
增加up 下载
🐛 fix: 修复 bug
📝 docs: 对文档进行修改
🎨 style: 对代码语义无影响的格式修改（如去除无用空格、格式化等等修改）
♻️ refactor: 代码重构（即不是新增功能，也不是修改 bug 的代码变动）
⚡ perf: 提高性能的代码修改
✅ test: 测试用例添加及修改
🔨 build: 影响构建系统或外部依赖关系的更改
👷 ci: 更改 CI 配置文件和脚本
❓ chore: 其它不涉及源码以及测试的修改