2019年12月

视频点此

半个月前,我提到了硬盘的一些单位。那今天,借着这些单位,来看一个问题:打开文件时,你的硬盘是怎么找到文件的。

一、“古典概型”

没什么特别的意思。我就突然想起来这个词了。我想说的意思就是,在若干年前,硬盘要如何定位文件呢?

正如之前的内容所说,一块硬盘里有多张碟片,每个碟片有两个磁头,在磁道上读写着它所对应的碟片面的扇区,而所有碟片的相同半径的磁道就构成了柱面。想一想,磁头可以确定一个扇区所在的碟片面,碟片切柱面便得到了扇区所在的磁道,再加上扇区号,这三个维度便可以确定一个扇区了。

这就是传统的三维寻址,学名叫C(Cylinder,柱面)H(Head,磁头)S(Sector,扇区)寻址方式。注意,这种方式下,磁头和柱面从0开始计算,而扇区数则是从1开始算的。至于为什么这么定义,标准。因为当年的IBM兼容机就是这么规定的,你要想兼容,那按要求做就行了。

规定的这一部分稍微的扩展一些吧:在IBM兼容机中,INT 13H中断被用作硬盘操作。如果调用这个中断来读写硬盘,就需要一组CHS参数来定位一个扇区。其中,C用10个二进制位存储,最大到1023;H用8个二进制位存储,最大255;S用6个二进制位存储,最大63. 而一个扇区的大小一般是512B,所以调用了INT 13H中断的程序,只能读写到1023 * 255 * 63 * 512字节大小的硬盘区域,核算过来就是可以读写到硬盘前8G左右的扇区。但现在的硬盘肯定远远大于8G,所以为了照顾使用INT 13H的老程序,微软等几家公司制定了扩展INT 13H标准,又出现了采用线性寻址方式来操作硬盘,从而突破了这个限制。

而线性寻址,也是当今机械硬盘主要的寻址方式。全称逻辑块寻址,缩写LBA(Logical Block Address)。

二、LBA

这种寻址方式就简单粗暴了很多。从0柱面0磁头1扇区开始,一直到最后一个柱面最后一个磁头最后一个扇区结束,每一个扇区都有一个独一无二的序号,这个序号是从0开始记录的。也就是说,0柱面0磁头1扇区转换到线性地址上就是逻辑0扇区,这便是“扇区从0还是从1开始的”这种矛盾症结所在,知道就行了。

再来看LBA本身。它其实也有一个进化的过程。

CHS寻址,就像之前所说,一共用了24个二进制位来存储了坐标的3个量,LBA一开始也用了24位。区别只限于CHS将这24位分成了3份,LBA则用来保存一个数。那这个数有多大呢?16777215. 算上可以用0了,一个可以编号16777216个扇区。这有多大?8589934592字节。注意哦,单位是字节,换算过来只有8.6G多一些。很明显,啥用都没有。因此,LBA扩大了一次存储的二进制位数,达到了28位。这时候能编号多少扇区了呢?268435456。核算过来最大容量137.4G左右。很明显还是不够啊,因此LBA再次进行了扩展,用48位来保存。此时不考虑其他的情况下,按512字节一扇区来计算,可以访问到144PB的位置,这个数量级,一段时间内应该够用了。

容量问题解决了,再来看一个问题:我已经知道逻辑0扇区对应的CHS坐标了,那么之后的序号按什么顺序排列呢?我是把0柱面1磁头1扇区编号为逻辑1扇区,还是把0柱面0磁头2扇区编号为逻辑1扇区呢?在了解了磁盘使用扇区的顺序之后,你应该就能知道了。

现在的多碟片硬盘,虽然有多个磁头,但往往都是由一个轴统一带动的。因此很容易想象出来,同一时刻,各个磁头会处在同一个磁道——或者说柱面上面。而移动磁头到其他柱面是硬盘读写过程中最消耗时间的一个步骤,所以尽最大可能让磁头不动才能确保有更高的执行效率。因此,编号从0柱面0磁头1扇区开始,到0柱面0磁头这一圈都编好序号之后,才会切换到0柱面1磁头1扇区继续编号,从而保证了效率最高。

你可能会有一个疑问:移动磁头最耗时间,那磁盘转动同样要消耗时间。这么一看,好像不需要任何机械动作的切换读写磁头这个动作才是最快的。那为什么我不先把所有柱面同一位值的扇区都写完,再切换到下一个扇区的位置呢?换句话说,为什么不按照0柱面0磁头1扇区 - 0柱面1磁头1扇区 - 0柱面2磁头1扇区这个顺序给扇区编号呢?另外,就像前边我说到的,其实扩展INT 13H也打破了8G界限。如果你想计算的话,在28位LBA的时候,CHS28位同样可以记录到136G多的位置(CHS寻址下,28位分成这三份:柱面使用两个寄存器共16位,扇区用一个寄存器共8位,磁头用一半寄存器共4位)。但为什么好好地CHS就被抛弃了,硬要造一个线性寻址方式呢?以后再说。

视频点此:
第一期第二期第三期

虽然我用Arch,但是更常去的Linux相关的论坛还是Deepin。而越看论坛里边询问有关启动项的问题,越感觉这些用户把EFI想的复杂了。所以就简单的来说说EFI启动模式相关的东西。

一、BIOS和UEFI启动,有什么不同

1、BIOS

一句话概括:

BIOS启动,只认识设备。

详细来说,因为只认识设备,所以必须要事先约定好读取设备的哪个部分才能保证正常读取引导。因此这种启动方式,需要定义一个主引导记录,位于硬盘的柱面0 磁头0 扇区1。它的大小是512B,由3部分构成:主引导程序446B+DPT硬盘分区表64B+磁盘有效标志0x55 0xAA

启动时,BIOS按照保存的设备启动顺序依次检索设备的有效标志。如果不是55AA,则跳过,是,则表示可启动,转而去读主引导程序。但引导程序到底会做什么,主板不管。

正是因为BIOS读取的位置固定这个特性,使得一个设备只会出现一个引导程序,后加入的程序会覆盖先前的引导,就有点儿刻板了。

2、UEFI

UEFI则解决了这个问题。因为UEFI

不但认识设备,还认识分区,更认识文件。

因为整体高级了不少,所以UEFI在启动的时候会有一系列的初始化操作。至于都初始化了什么,怎么初始化的,这里暂不细究。但是其中有一个初始化要说一下。这个初始化的名字叫DXE——Deiver eXecution Environment.

在这一步,UEFI会加载设备的驱动。如果说加载驱动前,主板只能知道当前它访问的设备是个什么东西,那么在加载驱动之后,主板就能知道这个东西的详细信息都有什么了。

至于需要加载什么,以及要依照什么顺序去检索这些设备可否启动,这些就都是从BIOS存储的设备序列来读取出来了。与传统方式相同,UEFI在BIOS中同样保存了一个启动顺序,UEFI会根据这个序列去依次查找启动项。至于启动项,EFI又分成两个:文件启动项和设备启动项。

文件启动项,即一个指向明确文件存储位置的启动项。使用这个启动项,UEFI会直接去往这个位置来加载执行。

设备启动项,则只指向一个设备。对于这种启动项,UEFI定义了一个标准,即如果这个设备可以启动,那么这个设备的efi引导文件一定是/efi/boot/bootx64.efi。对于一个设备启动项,EFI会直接执行这个路径下面的文件。如果可执行则继续,找不到则报失败。

对于UEFI+GPT,UEFI又有一个标准,即这个硬盘如果可以启动,则需要有一个EFI分区(ESP),格式为FAT32,而文件启动项放置在路径/EFI/厂商名下。这便是一个ESP分区最基本的结构。

二、如何指定一个EFI启动项

因为有两种启动项,所以启动自然分为两种情况

1、选择从哪个硬件启动

在用户选择了启动磁盘后,UEFI会在这个磁盘中寻找EFI分区,然后找这个分区下的/EFI/Boot/bootx64.efi(UEFI可以执行的二进制文件),由这个文件进行下一步操作(引导操作系统),这个文件通常由操作系统给出,在光盘/EFI/BOOT目录下。

2、选择用哪个文件启动项启动

这个启动项记录了引导文件(*.efi)所在的磁盘和分区以及文件名,直接执行这个efi文件即可开始进行下一步操作(引导操作系统)

硬件启动项比较容易,可以自己尝试把安装盘镜像直接拷贝到fat32格式的U盘下面即可。

至于文件启动项,这涉及到写入信息,可以使用efibootmgr来尝试一下

三、几个常见问题的解决

最后,就可以看看几个典型“问题”了。也许看过之后你就能明白为什么我会说“有些人把EFI想的复杂了”。

1、有Windows,又装了Linux双系统,为什么不能引导到Linux上?

同理,还有一个问题:我有双系统,删掉Linux后,为什么Windows的启动项回不来?

这不是Linux有Bug,只是你的BIOS设置有问题。

装好Linux后,EFI系统自然会创建对应的文件启动项。这个启动项对应着GRUB引导程序,它可以识别并启动到Linux和Windows中。而Windows自身的Windows Boot Manager,只能识别微软系列的系统。所以如果Windows Boot Manager排列在了最前方,自然就不能引导到Linux中了。解决办法就是进入你的BIOS,将GRUB的引导项移动到最上方的位置。

反之,删除Linux后Windows的引导回不来,就是因为Windows Boot Manager被放在了最下方,挪上去就可以了。

2、如何制作一个UEFI的安装光盘

正如前面所说,对于硬件启动项,EFI会自动寻找硬件的bootx64.efi文件。而一个支持EFI启动的安装盘镜像,自然会有这个路径。因此只需要把你的U盘格式化成FAT32,并将镜像解压到U盘中即可。

当然,如果你的安装盘中有单文件大于4G,受限于FAT32的最大文件限制,这时候你可能才需要启动盘制作工具。否则,解压即可万事大吉。

总的来说,UEFI表现给用户的东西要比传统启动简单了太多太多。很多时候问题来源于你的设置,而不是系统厂商。

伴随着我服务器的切换,最近把Nextcloud云盘从服务器上头下线了。它确实很强大,但强大的同时也意味着臃肿。而我只需要这臃肿中的同步功能。而它的同步又是全量同步,且不好设置需要同步的文件夹,这就偏离了我自己的需要了。所以一句话,我只需要一个可以增量同步我指定的任意文件夹下的内容的工具。

曾经使用过坚果云。但是每月1G上载3G下载的流量限制让我最终放弃了它。

Dropbox,印象里很不错。但是用它还得翻墙,不值当的。

OneDrive,微软家的东西,很好用。但是速度实在是不稳定。

最终,还是在服务器上面搭建了一个同步工具——Syncthing

这是一个开源工具,据说类似于BTSync的开源实现(这个我并没有考证)。正好符合我的需求:简单、增量同步。不过说是“同步盘”,其实更像是两个朋友间“共享文件夹”。因为这个工具,无论是服务器上还是终端上,安装的都是相同的程序,只需事先添加对方到列表,即可开始文件夹的“共享”之旅。下面具体说说怎么搞。

不必纠结下面的步骤哪个是服务器的哪个是客户机的。因为步骤都一样。

一、服务器 & CentOS

我更倾向于用Docker安装。因为手工部署需要人工把服务文件复制到systemd中,如果更新的话还需要再操作一遍。对于服务器,使用其他方式安装还需要额外配置,就麻烦了。Docker方法如下:

  1. 拉取镜像。关于这个工具的镜像有很多,其中我更倾向于使用 linuxserver/syncthing。官方的有权限问题,可能是我的操作有误吧…docker pull linuxserver/syncthing
  2. 建立容器。使用命令

    docker create \
      --name=syncthing \    # 容器名称
      -e PUID=1000 \        # UserID
      -e PGID=1000 \        # GroupID
      -e TZ=Asia/Shanghai \    # 时区
      -e UMASK_SET=022 \    # 文件夹权限
      -p 8384:8384 \        # 对外端口映射 - GUI端口
      -p 22000:22000 \        # 对外端口映射 - 协议端口
      -p 21027:21027/udp \    # 对外端口映射 - 本地发现端口
      -v /path/to/appdata/config:/config \    #文件夹映射 - 程序文件
      -v /path/to/data1:/data1 \    # 文件夹映射(自定义数据文件夹)
      -v /path/to/data2:/data2 \    # 文件夹映射(自定义数据文件夹)
      --restart unless-stopped \    # 始终重启容器
      linuxserver/syncthing

    其中,参数nameTZ-p-v都可以根据自己的情况进行修改。对于这几个端口,保证本机相应的端口没有被占用且没有被防火墙限制即可。

  3. 启动容器docker start syncthing

    现在,你就可以打开ip:8384映射出来的端口号在图形化界面中设置了。其中,ip地址需要使用:

    • 本机,使用地址127.0.0.1
    • 服务器,使用地址服务器公网ip

二、Debian&Arch安装

源中已提供,直接安装对应的包即可。其中,服务器端和客户端都可使用包syncthing,客户端亦可以使用syncthing-gtk获取一个显示在托盘的同步状态标志及便捷的设置入口和服务起停入口。

  • Debian系

    apt install syncthing    # 安装
    systemctl enable syncthing    # 设置服务开机启动
    systemctl start syncthing    # 启动服务
    # 如果是客户机,可使用下面的命令代替上面的
    apt install syncthing-gtk
  • Arch系

    pacman -S syncthing    # 安装
    systemctl enable syncthing@你的用户名    # 设置服务开机启动
    systemctl start syncthing@你的用户名    # 启动服务
    # 如果是客户机,可使用下面的命令代替上面的
    pacman -S syncthing-gtk

对于本地机器,如果安装的包syncthing,则可打开127.0.0.1:8384进入图形化的设置界面;如果是syncthing-gtk,则找到程序syncthing-gtk,运行即可。

对于服务器,再进行下述操作:

  1. systemctl stop syncthing停止服务
  2. 找到syncthing文件夹,编辑config.xml,将<address>127.0.0.1:8384</address>修改为<address>0.0.0.0:8384</address>

三、GUI设置

1、服务器端

操作 - 设置,打开设置界面。

  • 常规:

    • 如果不是用Docker 安装的,那么请确保默认文件路径的合理性
  • 用户图形界面

    • 设置一个 图形管理界面用户名
    • 设置一个 图形管理界面密码
  • 连接

    • 保证勾选了启用NAT遍历
    • 保证勾选了全球发现

2、客户端

安装的syncthing,则点击操作 - 设置,打开设置界面。

  • 常规:

    • 如果不是用Docker 安装的,那么请确保默认文件路径的合理性

安装的syncthing-gtk,则打开窗口后点击右上齿轮 - 守护程序设置,打开设置界面。

  • 取消其中的全部勾选

四、开启同步之旅

  1. 服务器端的设置界面,点击操作 - 显示ID,复制弹出窗口中的字符串
  2. 本机中,选择添加设备,ID粘贴刚复制的字符串,地址填入服务器ip:22000(或者docker容器,22000映射的端口号),确定
  3. 等一会儿,服务器会弹出添加请求,通过
  4. 本机添加共享文件夹。在共享给设备中,勾选刚添加的服务器,确定
  5. 等一会儿,服务器会弹出建立共享文件夹请求,通过
  6. 共享已联通。同步正式开始了

虽然Dedipath的终身优惠让我可以以每月2.6刀的价格拥有一台双核、1G内存、100G存储、双ip的服务器。不过这么一段时间下来,还是在一些地方感觉有那么点儿不舒服:

  • OVZ架构,内核版本只能用默认的2.6
  • 往大陆直连速度不快(虽然做了加速)
  • ssh经常会被断开(大概是因为经常性的25%的丢包率)

所以,我前两天终于是给它给换掉了。你大概不知道,当你看到这篇文章时,这个博客的伺服器已经从Dedipath的德国机房转移到RackNerd的洛杉矶mc机房了。

根据介绍,该机房的的路由对大陆地区还是不错的。目前中国电信已经加入了cn2线路直连,虽不保证cn2,但相比之前没有加入要好;另外洛杉矶mc机房一直对联通支持的比较友好,联通169骨干直连;移动线路相对弱一点走的也是联通骨干。

那我这台服务器的配置怎么样呢?

3核、2G内存、75G硬盘、月流量2T。

至于速度,北京鹏博士ping出去延迟在200ms左右,下载基本保持在800kb~1M,而这是在没有开启bbr加速的情况下测试的。要打开了bbr,你就琢磨去吧。

没错,这个服务器能打开bbr,这意味着它的内核可以被升级到4版本以上,也就意味着我可以随意调整内核版本,也就说明这个机器是KVM的!

哇,3核2G,75G存储,还是KVM虚拟化,更有cn直连,如此美好的东西价格如何呢?

说出让你死心的价格吧:月缴9.59刀。我又附加了一个ip,所以月缴10.59刀(合74.3)。

当然,它原本应该是这么贵的。

实际上,现在有月缴模式终身5折的优惠。所以我这机器实际月缴5.29刀。按现在汇率算,38块钱一个月!想一想,38块钱就买到了一个三核2G加上75G存储的双ip、KVM虚拟化服务器,而这些钱买腾讯云能买到啥?至少你的带宽就只有可怜的1Mbps(核算过来从服务器下载数据速度最高128k);而6刀买国外服务器又能买到啥样的?要想kvm的话,撑死1核1G了吧?

这么看,超值了啊!

比我这个配置低的还有两个KVM方案:

  • 单核512M、30G存储、500G流量,只能年缴23刀
  • 双核1G、50G存储、1T流量,月缴5.59刀,加一个终身5折优惠,月缴才1块多美元啊!

要是最近想买服务器,快去!

购买传送门:

双核1G+50G存储

我的同款

优惠码(我也不知道啥时候失效,所以尽快):zhujicepingcom50mo

记得改成月缴呦~

视频点此

硬盘,一个存储着你所有资源的一个设备。也许你知道你的硬盘大小4TB,但你是否意识到了,这其实只是在以文件为视角在进行度量呢?有没有其他的度量方式呢?

先来看硬盘本身。也就是物理层面的玩意儿。

1、碟片和磁头

不考虑固态硬盘,那么一块硬盘最主要的构成就是存数据用的“光盘”了。想要读写数据,就必定会有一个东西作为改变光盘电子的媒介。这个媒介就叫做磁头。如果想要最大程度的利用一张光盘,正反两面都进行存储必然是最容易想到的解决方案。所以硬盘中,一张碟片会用两个磁头分别从上下两面进行数据操作。

进一步考虑,在工艺一定的前提下,一张碟片的最大存储量是固定的。那如果想要进一步扩展容量,需要怎么办?没错,加入第二张、第三张碟片。硬盘就是这么干的。与之对应的,加入碟片的同时就要加入更多的磁头完成数据的操作。因此,一块硬盘也可以有4个、6个,甚至更多的磁头。关于磁头就先说到这里。接下来看看碟片上的东西。

2、磁道、柱面和扇区

众所周知,碟片是由中心的轴带动着转动的。因此如果给定一个从轴心开始的线段,那么在旋转的碟片上会留下一个圆环。不同长度的线段会留下半径不同的圆环,每个圆环就是一个磁道。而多个碟片摞在一起,相同半径的圆环就会变成一个空心的圆柱体。每个碟片就是这个圆柱体的一个切面。柱面就这么形成了。自然,磁道和柱面其实说的是同一个东西,只不过一个把视角落在了单张碟片上,一个是落在了多张碟片形成的体上。

从圆心沿碟片向外拉两条直线,跟每一个磁道相交,便会形成一个扇形的区域。而磁盘转速一定,所以如果控制了时间间隔,同一个磁道上的扇形区域大小便也相同,每一个扇形区域就叫做一个扇区。不过要注意,现在的硬盘跟以前的硬盘对扇区的划分方式有所不同,不过这里涉及不到就不讨论了。

至此,物理层面上的一些“单位”就介绍完了。所以在硬盘眼里,存在着一组新的描述硬盘大小的说法:这块硬盘有8个磁头,单面10000磁道,平均每个磁道12500扇区。

没什么用。不过这对于硬盘本身来说,是寻找文件存储地址的一个工具。这个以后会来聊一聊。今天先接着来看度量衡。

通过上面的介绍,想必你已经意识到硬盘中最小的单位是物理层面上都不可再分的扇区了,一块硬盘的容量便可通过扇区数x扇区大小来计算。而一个扇区的大小是多少?512B,当然如今 4K的也不少见。想一想,即便是4G一个扇区,对于当今动辄4T的硬盘容量,也需要1000个扇区才能表示完全。所以如果让系统直接面向扇区进行数据的处理,那记录下一个文件在那些扇区中是多么的琐碎?所以,为了减轻寻址的繁琐,一个文件系统会把相邻的一些扇区合并起来,提供给操作系统统一使用。合并后的每一个区域,就叫做一簇,或者一个块。这个地方,请翻看我之前的关于磁盘碎片的内容吧。

所以,在操作系统眼中,硬盘容量的说法又变了。它会变成“这个硬盘一共有62500000个簇,每个簇64k”。

至于文件视角,我们便熟悉了:这个硬盘容量4T

感谢原插件(WikimoeBangumi)的创作者 广树,我所做的仅仅是在其基础之上进行了些许改动而已。
不想看废话的,就请直接拉到最后。

Übermorgen/Typecho追番插件-B站来源


最近更新

  • 1.0.0.245, 2024.5.13更新

    • 考虑了好长时间如何能加快封面加载速度,今天意识到给封面路径加个限定参数便可以通过官方方法压缩图片质量以降低文件体积…现在速度大概是终于可以保证正常浏览了——即使事前没有手工访问构建缓存。
  • 1.0.0.2210, 2022.10.23更新

    • 合并请求,修复undefined问题
    • 自定义翻页键样式输入框可以随意回车了
  • 1.0.0.2010, 2020.10.25更新

    • 进一步避免jQuery对主题的依赖
    • 支持自定义每页数量
    • 支持翻页按钮自定义
  • 1.0.0.207, 2020.7.12更新

    • 隔离jquery依赖
  • 1.0.0.204, 2020.4.22更新
    追番信息分页显示,每页30个
  • 1.0.0.202, 2020.2.8更新
    兼容伪静态站
  • 1.0.0.201c, 2020.1.20更新

    1. 进一步撤销了no-referrer标记
    2. 现在番剧封面不直接从b站获取了,会保存到服务器供使用

    注意:因为现在需要下载封面到服务器,所以设置好插件后应先访问一次以构建封面缓存。时间可能较长,耐心等待。

  • 1.0.0.201b 20200116更新
    新增:番剧块背景可调(番剧封面/空白)
    更新请先禁用再启用
  • 1.0.0.201 20200115更新

    1. 修复了评论与番剧封面不兼容的问题
    2. 优化了载入速度。理论上每多45个番剧,载入速度能提升2倍
    3. 现在的番剧封面默认走https协议了

一、为什么想做这个

自打从WP转到Typecho,我就突然有了浏览独立博客的习惯。但博客内容并不是我浏览的重点所在,我更喜欢去看每位博客作者的 关于 页面。真的有意思。

除此之外,我很好奇每个博客的结构。比如都有哪些分类,页面都有什么元素之类的。这关注点有点儿奇怪,不是吗?

但不知是不是我的选择性记忆,我逐渐发现不少的博客都有一个追番页。你说它有什么用吗?我其实没感觉有啥用说实话…所以我也一直没怎么太注意过这种插件。直到我开始应用了看板作为我的进度及备忘工具之后,突然感觉追番页这种有条理的东西,放在那儿也挺有意思的啊。于是便简单搜了搜这类插件。自然,如果你检索过这种插件,那么仅有的两个结果你大概也就知道了:我使用的这个主题的大佬做的熊猫追番,以及WikimoeBangumi。这两个的来源都是 Bangumi 的API,而我从来都是在B站上头(不管是看还是追)的,单开一个账号我也想不起来去打理,又白消耗人家一丁点数据库空间。所以,我便尝试着把WikimoeBangumi改造,用B站的api来实现一个追番插件了。

二、现在成什么样了

每天两小时,连蒙带猜的搞了两天,已经改的差不多了。用抽风Crazy这个头油怪的账号试了一下(不,他并不认识我,之后你会明白为什么可以拿别人账号测试),83个追番加载的速度还算可以接受吧。刨去我的服务器从德国向B站请求数据->B站返回给德国->处理好后将网页发送到圣何塞->圣何塞转送给北京这种由于世界人民大团结而产生的延迟,我认为3秒加载还是可以接受的(这地方我觉得我以后会改一改。我觉得…)

主要更改了哪些呢?

  • api:这是当然的。现在会通过B站来请求追番数据了
  • 登录方式:大佬原本的插件是通过用户名密码,很友好的登陆的。但是B站的第三方登录需要API Key,否则需要破一道图片验证码…这太麻烦了,所以我改成了直接用cookie登录。自然,插件设置页变更成了填写UID和cookie。所以设置的时候有点儿麻烦,但恕我才疏学浅,实在想不到怎么能比较方便的实现登录了…
  • 块显示内容:原本插件会显示中文番剧名、外文番剧名、首播日期、进度。现在更改成了中文番剧名、最后更新的剧集名、首播日期、进度。
  • 进度条显示内容:原本是简洁的当前话数/总话数(类似10/135/未知),但B站的剧集数并没那么规矩,而好在B站api直接提供了一个当前观看状态的值(类似于 已看完第13话已看完PV1看到第2话 1:37这种),顺便为了友好化未知这种冷冰冰的词,所以更改成了观看状态(截掉了具体的观看位置)/共 num 话(类似于 已看完第13话/共 13 话已看完PV1/未完结看到第2话/共 12 话
  • css:稍微的调整了块高度,使其在RAW主题上可以更好地显示;亦调整了图片长宽,避免变形;换成了em单位,对于不同分辨率,显示应该更好一些了?还调整了进度条,现在当番剧未完结时,进度会显示成50%了。
  • (201b新增)css: 块背景可选透明还是番剧封面
  • 函数变更:整体到底是麻烦了还是简单了我也说不清,总之删掉了部分函数,更改了载入追番的逻辑(B站API默认不能直接获取到所有,但是它会返回一个追番总数。所以目前暂时用了一个简单粗暴的解决方案:分多次获取,然后全部显示)(204取消了这个粗暴的逻辑)分页获取,提供上下翻页按钮,更改了curl的方法(加入了伪装登录用的各种需要的头),自然也更改了各种变量对应的json字段,最后增加了一个函数,用于截掉详细进度信息。
  • (201c新增)函数:增加了下载封面到服务器的方法。现在可以完全规避b站禁止跨域导致的封面403问题了。
  • (2010新增)函数: 可以自定义每页展示的番剧数量以及翻页键按钮样式了。
  • (207新增)依赖:独立了jQuery依赖,使得不再要求主题带有jQuery库,(2010新增)并且包含在插件中,不必再担心获取js速度的问题了。

效果 看这里

三、怎么用?

注意

你的博客根目录下不存在bangumi文件。注意是文件,文件夹是没问题的。因为封面会保存到这个文件夹内,所以如果存在同名文件夹没有关系(共用就好),但文件就不成了。

a、插件部署

clone或下载zip,解压放到你的Typecho文件夹/usr/plugins/,并更改文件夹名为BiliBangumi,启用即可。

b、番剧页

参考WikimoeBangumi的部署方法。只不过语句要改成<?php BiliBangumi_Plugin::output(); ?>

c、插件设置

目前一共两个设置项:UID、cookie。

截止到2010,共有5个设置项:UID、cookie、块背景、每页数量和自定义翻页键。

UID很好说,直接把你的BilibiliUID填入即可。此时会有两种情况:

  • 如果你的追番信息是公开的(即别人可以从你的主页看到你追的番):这时候你的追番页应该就可以显示出追番信息了——除了进度相关是失效的。这就是为什么我可以用头油怪的账号做实验。
  • 如果你的追番信息是隐藏的,或者说你想要显示出追番进度,那么就需要“登录”——也就是填入cookie。

至于块背景,你可以选择使用番剧封面还是默认背景色(默认是透明的);每页数量则定义了每一页中展示的番剧数量,默认是10。

自定义翻页键则属于比较高级的设置项。可通过编写css自定义翻页按钮的样式实现更细致的美化。这里只需使用css中属性: 变量;的语法顺次写入即可。不要回车,回车会触发Typecho设置页面的确定按钮。

d、所以如何获取cookie?

  1. 在Bilibili登录你的账号(电脑网页端,推荐使用Chrome)
  2. 点击头像,进入个人主页(此时网址应该是space.bilibili.com/uid号。如果uid号后面还有一堆字符,删掉即可)
  3. 按下万能的F12,切换到Network标签
  4. 清空一下Network里边的内容,然后F5刷新
  5. 不出意外,此时在Network列表内,应该有一项是以UID为名称的条目。点击它
  6. 弹出一个预览窗格,切换到Headers标签页
  7. Request Headers栏目下,会有一个cookie项目。把这个的值复制下来,粘贴到插件设置页,保存
  8. enjoy

e、疑难解答


Q: 封面获取逻辑

A:因为使用no-referrer总会间歇性的失效导致封面无法获取,所以从版本201c开始,封面获取逻辑改为从服务器自身获取:

  • 第一次进入到追番列表的番剧,自动去b站下载封面到typecho文件夹/bangumi/
  • 之后每次访问,封面就会从上述的文件夹获取封面文件了

因为需要下载,所以在初次启用插件时,最好在设置好后自己先访问一次以完成封面下载工作。受限于服务器传输速度和追番数量,第一次访问加载的时间可能会很长,耐心等待封面下载完成即可。

想清除封面文件,只需清理typecho根目录/bangumi即可

Q:迷の版本号

A:是一个拼接出的结果:原插件版本号.日期后两位+月份。这里边我只会更新我自己的版本号部分,原插件版本号会一直保留原样,作为基于哪个版本的参照。这是我的习惯,就像我喜欢留点儿缺陷,后期刷版本号的一种执念::(滑稽)

四、更多信息

下载地址:https://gitee.com/stsiao/typecho_bangumi_bili


任何问题,留在这里吧。码云的issue我可能很难想起来去看…