本帖最后由 Yuran 于 2023-7-18 19:32 编辑
这是本人的自习笔记/备忘录。
都没加好友，见谅(以前，咱也曾担任其它论坛的超版. 真的忙不过来，疲于应付 影响自习/研修) ,感谢支持和理解。
前言：先介绍：DIY编程的心得（相当于：本贴所分享的、3D蓝光影碟资源库、数据文件的说明文档）。
这几天，Yuran一直在设计、改良（Python）自编程序的脚本，并做了大量的测试，成果斐然。
毕竟，前些天，本人发布了：3D影视/蓝光资源的帖子《领悟3D、玩转3D！另附rarbg全部3D蓝光影碟/视频等下载信息!》
虽能提供：一千七百多条（2023年RARBG网站关闭前的）3D资源/信息！
但遗憾的是，这里面：夹杂许多非正规的、3D视频/片源  （看上图，就有不少、 SBS、OU 等描述项）。
解释一下：
- Anaglyph （貌似浮雕状的3D视频，实际可用红蓝眼镜隔离、从而观赏3D立体影像）；
- SBS（side by side 左右各半的、3D视频的格式）；
- OU（Over Under上下各半的3D视频）；
而Yuran的需求，比较苛刻，只能是 3D蓝光影碟的原盘（资源）。因此，必须剔除上述非规范片源。！
只有这样，才能确保：高质量的、3D立体影像的体验！
Frame packing ，才是规范的3D视频（左/右眼的视频帧，都能支持 1920 X 1080 FullHD 的规范）！
这也是3D蓝光影碟的靓点（HDMI 1.4 开始支持）。
另外：
即使（手动或自动）筛选后，能得到粗略的、3D蓝光影碟（原盘）的列表/清单（在自编程序中，称之为：中间文件）。
但问题是，相关的磁力链接，是否有效？ 涉及3D蓝光影碟片源属性的描述，也是不着边际（是否 ISO镜像文件？
文件的大小，又分别是多少？！）
若能给出、比中间文件更全面、更详尽的答案，那就更利于下载、归档（在自编程序中，该类答案，称之为：最终文件）！
自己动手、丰衣足食！ 用自编程序来处理/解决吧，一劳永逸！（不再拘泥于：上述千多条的、杂七杂八的信息库）。
实际上，Yuran 所面对的，最全的数据库，那可是：浩瀚的数据量（三百多万条、涉及rargb等片源信息）！
上图中，能看到，最全的数据库（在编程中，称之为：原始文件），竟有 3,468,029行！
囊括 FHD BD、3D BD、UHD BD 等规格的视频源。基本上都是电影。（也有一些、好几个X的那些，已打码，不能分享）。
每行最后，那个奇异的符号，其实是：行尾换行符（按回车键就能生成。在编程脚本中，就是诸如 "\r"，"\n"之类的字符串...）
（上网）爬虫之前，Yuran DIY设计的程序，循序渐进、稳扎稳打。按部就班地、执行下述（操作）流程。
- 检查原始文件（三百多万行的资源库），是何种编码（有ANSI、GBK、UTF-8 等规格），若不符要求，示警后退出！
- 检查中间文件，是否存在。若存在，是何种编码。是否具备完美性（意指：最后一行，是否具备特殊的、终止标识符）。
- 检查最终文件，是否存在。若存在，是何种编码。是否完美（同样，查看其最后一行，是否具备终止符）。
对中间文件来说：
如果，中间文件不完美，则调用专用的函数（子程序），将从原始文件中，重新择选/归纳 3D 蓝光影碟的原盘文件/匹配项！
如果，中间文件完美存在。则直接上网/爬虫，跳过（遍历原始数据库的）归纳流程。
对最终文件来说：
如果，最终文件完美存在。则立即给出提示：既然木已成舟，那就无事可做，直接退出。
还可能，最终文件虽存在，但若信息不全。将自动甄别最后几行的特征符。计算出：已完成多少项；还有哪些，需要补遗！
上面就是：测试实验中的截图。原始文件的样本，有30个（参差不齐的）片源。
自编程序筛选后，剔除5项（不带3D字样。或者：虽有 3D 的表述，但还夹带：half、SBS、OU 等特征字，属黑名单的内容）。
中间文件，虽有26行，但只代表25个匹配项！
毕竟最后一行，是我自定的、终止标识行。即使是全球互联网，也不可能发生：“撞衫”（雷同）的情况。
实际上，从（浩瀚）原始文件中，择选出的、片源信息，不够详尽！
虽存成中间文件，但是，（仅凭上图）谁都不能担保，肯定就是3D蓝光影碟原盘文件。再者，也不知其文件大小。
这就需要：（自编程序上网爬虫、逐项复核、校对过的）最终文件，敢打保票（有对3D 蓝光影碟规格的求证）！
再看最终文件，同理，若带终止行，被自编程序读出后，则视为【完美版】（否则，按 【遗漏版】 处理）
最后一行，若是其它样式，就等于，告诉自编程序：因网络原因、或断电、重启等意外，3D蓝光的复核工作，尚未做完！
Yuran的设计要求：最终文件里，每项（每个电影片源），都必须，占三行！
- 第一行：片名、3D蓝光影碟的属性（经网络爬虫抓取的数据，阐明架构是 ISO 还是 BDMV ，以及相关文件的大小）。
- 第二行：有效磁力链接（在核对中，会遇到片名不同，但URN相同的特例，上网校对后，还能给出磁力链接地址 ）！
如果，经上网/爬虫后，发现片源的属性，实为MP4或MKV、AVI等格式，并非3D蓝光影碟原盘；
就不再提供磁力链接，标注改为 NA（Not Available）...
- 第三行：每个匹配项的结束标记：通常是破折号的形式，若遇到最后一项，则换成终止标识行。
若遇意外情况（片名冲突、磁力链接失效、视频格式不匹配等）。
第三行，就改成：破折号与特殊警示符（ 带 jhyr醒目标识）的组合体，以示区别。
Yuran设计的自编程序，重点关注最终文件。若存在，且不完美，就立即统计：最终文件中，现存内容的行数；
将总行数，除以三，就是已记录在案的（电影/单元项）的序号，代号是 x。
随后，也会查看：倒数第二行，是否夹带 magnet:?xt 等标识符，或 na 、error 等字样。确保磁力链接的正确性。
再让自编程序，拆分倒数第三行，是否能提取，现存序号（x），总项目数（y） 的字样。 将字符串转为整数。
若能正常切片、提取，则证明：最终文件完好，可以继续补充。
为了双重检查，（自编程序）还将（从最终文件中提取的）y值，与中间文件所给出的项目总值，进行比对。
若核实无误，就开始推算：继续（向最终文件）填补的序号（应从 x+1 开始，直至 y ）...
自检流程中，若发现：中间文件失效（不存在、或为空文件、或不完美，也就是：找不到终止标识符）。
就会重头再来，再从原始文件中，筛选、择出（符合3D蓝光影碟原盘的）匹配项，重新建档（中间文件）。
（三类文件）自查结束后，（自编程序）将自动测试： 海外代理 proxy 的有效性...
（兼顾国内特情，为查询海外资料，只能 搭 梯 子）。
再次声明，以前发帖时介绍过的、劫持光猫、嗅探（局域网内）各分设备的（cookie/密码等）上网数据，将自家门禁卡
NFC复制等技术；以及本贴所讲的、自编程序‘搭 梯 子 等程序代码，都是DIY实验、家人专用。不能公开，你懂的...
换言之，该项爬虫利器，须借助proxy环境（http或sockets5搭 梯 子模式），若某项尝试得到响应，就自动切换、开始爬虫！
测试实验中、自编程序的爬虫实例（中间文件完美，最终文件不全。因此，从第五项开始补遗）：
下面都是录屏视频/片段（GIF转码）！
上述（动画）流程的解释：既然中间文件完美无缺。就自测搭 梯 子 环境，http proxy 无效。转为 sockets5 ，成功得到响应。
从中间文件得到的、第五项信息，仅仅是搜索页的状态（而非最终结果页）。因此，需（自编程序）抓取搜索页的链接地址，
再进行智能跳转，调取最终结果页（3D影视详尽信息页）的数据，这才弄清：本项链接，只得到非正规的视频（MKV文件），
并不是Yuran想找的、3D蓝光影碟原盘（资源）。因此，自编程序给出警示。加注 NA 等标识，写入本地文件、再给出屏显...
（所动用的编程技巧，GBK与UTF-8互转、中文网址%E4%B8%AD%E6%96%87类的转码、换行符的识别等，不再细讲...）
爬虫，能从最终结果页，摘取数据。比如下面的图示（我拿一个 UHD片源，BDMV格式的，冒充 3D 1080P，做相关测试）：
第13项，是（冒充 3D蓝光的 ）UHD 蓝光影碟原盘（ BDMV架构、 129 pcs m2ts files_BDMV_size=93.63GB )
众所周知，3D蓝光影碟，都是 ISO格式的下载源，为何用BDMV 的片源（作样品）？！ 本贴的最后，将有'剧透'...
有人会说：爬虫速度慢。 其实，我故意设置了：延时的功能（如果太快太频繁，会被某些网站/反爬虫机制察觉... ）
还有一种特例，某个片源，出现两张3D 蓝光影碟的情况，也拿来做样品，进行自编程序的测试！
注意上图、最下面那行，爬虫后分析出：第17项的属性， ( 2 pcs BD ISO files_size=94.57GB )
看来，自测实验，已达到预期效果。那就可以，（专门）针对三百多万条的浩瀚数据，付诸实战！
从下图中看到，原始文件，3,468,029行数据。Yuran的自编程序，先挑出一千多条、与3D视频相关的片源，
再终经过甄别，择选225个匹配项（接近于3D蓝光影碟原盘的片名），剔除带SBS、OU、Xvid、X264等字样的单元项。
其中，有些（被选中的）片名，看似3D影碟原盘。但上网爬虫、抓取数据后，才知其'真面目'。
仅仅是MKV或MP4之流的、非正规的3D视频。自编程序在文件中特殊标注（屏显是蓝色和粉色），不再提供下载链接！
换言之：Yuran设计的Python程序（脚本），仅对 蓝光影碟的特征符 （ISO 、m2ts）感兴趣！！
这次，才（校验）225项。以后的中间文件，即使是成千上万（行数据），咱也能：泰然处之！
万一中途断电、断网、PC重启、或有事外出，人为关闭程序。看上去像是：最终文件惨遭损毁。
其实不然，Yuran设计的程序（流程），（有针对性地）实施文件保护：逐项保存（写入）、随即关闭（文件读写的模块）。
这就像是：编辑软件的、自动保存功能，随时备份，有惊无险。
这样，以后，再次运行时，自编程序，也能根据（最终文件中、已保存的）序号，'多退少补'（不会浪费时间）...
爬虫过程中，若响应超时，将自动（重复）尝试三次，若还无响应，将自动终止（程序）。
最后，大功告成！
现分享：最终文件！
由DIY自编程序（proxy）上网/（海外）爬虫、逐项校对后，自动归档而成的、满意的答案：
3D 蓝光影碟原盘的、两百多条详尽信息（涉及属性/架构、文件大小、下载链接等）！ 这只是爬虫实用工具（自编程序）第一版。之所以，在编程时，精打细算、步步为营。为的是：更加深远的计划/目标！ 慢慢来，水滴石穿、功到自成！
|
