分类 通用知识 下的文章

视频点此

之前留下了一个问题:为什么现在不用传统的三维寻址了呢?

因为不好用了呗。但为什么不好用了呢?这就说到今天介绍的问题了:碟片上的扇区都有哪些划分方式。注意哦,我说的是碟片,所以这就包括了硬盘、CD在内的很多圆盘样的存储设备了。慢慢说。

在正式开始之前,先用这种方式来简单理解一下扇区:固定时间间隔,读写头一时间单位在碟片上面划过的长度。再记住线速度与角速度关系的公式:v=Ω·r. 好了,可以开始了。

1、CLV

一开始的技术叫做CLV:恒定线速度。核心:整张盘的线速度都相同。根据刚才说到的公式:如果v一定,则r同Ω成反比。也就是说,磁头越接近内圈,需要的转速越高。所以这种技术需要马达不断的调整转速,寿命自然也非常短,通常用在低于12倍速光驱中。

2、CAV

CLV因为不停的更改机器的转速,会对机器的寿命造成一定的影响,而且磁盘转速也不能无限制的加快。所以后来又有了一种磁盘技术叫做CAV:恒定角速度,即马达的转速恒定。显然这对马达有了很不错的保护。而根据公式,角速度一定时,线速度同半径是成正比的。所以越靠近外圈,碟片的线速度就越快。再根据前边提到的扇区定义,很轻易就能得到一个结论:越靠近外圈,一个扇区的面积会越大。但这为硬盘带来了几个优势:一个扇区的面积越大,对应的磁介质就会越稀疏,而相互之间干扰出错的可能性就会越小。因此硬盘留下了一个传统:靠前的分区在磁盘外圈。

换一个角度来看:角速度一定,Ω/t就是一个定值(记为k),进而可以得出,360°/k是一个定值。因此CAV模式下,不仅越外圈的扇区密度越小,每个磁道拥有的扇区数还是相同的。这就让CHS有了极大地用武之地:磁头、柱面、扇区,这三个量每个量都是从0到一个固定值的,管理起来就能方便很多。

3、ZDR

但随后的ZDR——区域数据记录技术——让CHS疑惑了。

简单来说,ZDR就是分区CAV:每个区域内为恒定角速度,而各个区域内的角速度不同。从磁盘的最外圈到内圈划分出若干个区域,每个区域内的每磁道扇区一致,但靠内的区域比外侧的区域的每磁道扇区数要少,从而可以根据不同的磁道长度来合理设定扇区的数量,以达到充分利用磁盘存储空间的目的。

可以想象,虽然磁头和磁道还是可确定的范围,但扇区却根据磁道所处区域的不同而有不同的范围,这种情况下的CHS显然就没那么好用了。而由于密度可以做到内外圈类似,所以越靠近外圈读写可以越快,因此第一个分区放在最外圈依旧是一个好的习惯。

还有一些其他的划分方式,比如P-CAV(内圈CAV外圈CLV)、Z-CLV(划块线速度)就不详细介绍了,这些都是在上面的基础之上进行的组合和改良。

正是ZDR的出现,让传统CHS变的不再那么好用了。所以也催生了LBA的产生。而现在的SSD,更是进一步舍弃了CHS三元素,让物理CHS更彻底的成为了历史。

视频点此

一、尽量在Linux下做所有的工作

我感觉,先将自己置身在Linux是最重要的一步。我党有句话:从群众中来,到群众中去。学习Linux就有这么一个思路:先去用Linux,遇到问题时就去学习,然后返回到Linux中解决它。其实也不止Linux,学数学物理这种也是这么个路子,只不过从现实抽象这一步骤放到了前人的身上了而已。

而在使用的过程中,坚持一个原则:避免提问,善用搜索——尤其是刚接触Linux的一大拦路虎:软件缺失。我不止一次的说过,现在的Linux有绝大多数可以对应Windows专属的软件,仅仅是你不会使用搜索引擎而已。就像很多人说的CAD。说实话,每次看到这种说法我就觉得这人“学傻了”。但是转念一想,检索技巧在大学也是一门课,所以不会用百度也是正常的。至于搜索这部分,我一会儿再细说。

二、阅读帮助文档

使用中针对出现的问题学习无疑能学到对于你自己最实用的一些知识,但是想要系统的学习还是需要一些资料来阅读。其中,帮助文档就是最容易得到的——无论是Windows还是Linux。只需要鼠标轻点,loading一下即可万事大吉。对于命令行的指令,Linux下也可通过在命令前加一个man来获得手册。

但是这有一个问题:受限于汉化程度的不同,有些手册你可以无痛理解,有些可能需要你配备一本英汉词典来使用。而且这对于解决问题往往没什么帮助——因为它平铺直叙了所有可能的操作方法,但并不能告诉你出现什么错误可能会是哪里导致的。这时候,Wiki或官方网站可能就是一个更好地选择了。

三、Wiki/官网

不只是发行版,一些开源项目,wiki或官网也是很有用的工具。这个的优势很明显:

内容完整。对于一个项目来说,wiki作为知识库的存在,可以拥有最完善的介绍体系。

步骤细致。作为作者发布的教程,wiki通常会写出这个项目需要的所有依赖、可配置的参数和所有可行的部署方法。所以很多时候只需要无脑复制粘贴命令即可,甚至不需要理解这些指令都在做什么。

官方的疑难解答,这是相对于帮助文档突出的一点。一些常见问题在wiki中会有详细的解决方案,比盲目的网上检索针对性更强。

实时更新。任何新版本的改动,作为与作者关系最近的wiki自然会得到最先的调整。

但缺点也存在:

很多wiki可能使用英文编写,或根本不存在。

对于学习Linux,我会推荐两个Wiki:ArchWiki和DebianWiki。

Archwiki,内容全面而完善,所有的发行版都可以将Archwiki作为参考资料使用。而且有些内容会附带常见问题的可能的解决方案,很有参考性。即使不是为了查找出错的解决方法,单独当做ArchLinux入门来看也是个不错的“教材”。但部分页面的中文翻译跟最新的英文原版内容有脱节的现象,所以有的时候可能需要查看英文原版的页面。而且因为Arch的包比较多,包管理器又跟Debian、RHEL之类的不一样,所以对于Debian分支,Debianwiki也是个不错的工具。

DebianWiki,很显然是根据Debian分支的命根子——Debian而出现的百科,所以这个wiki下面的内容通常可以对应到各个基于Debian的发行版中。只不过Debian的包往往比较老旧,所以如果有些东西编写的年代比较早了,那配合着ubuntuwiki来看会是一个不错的方法。但我可能不会单独推荐ubuntuwiki。一来,Ubuntu相对Debian有很多改动的地方,所以其他的Debian发行版不一定能通过Ubuntuwiki适配上,二来感觉Ubuntuwiki的内容不是很多的样子,但这可能是我不会用吧…

四、社区

在此之下的路子,就是各个开源社区了。社区这个概念具体我就不介绍了,总之社区就是一个由相同兴趣的人聚齐而成的一个讨论区。因此往往会有一些歪门邪道但很好用的小技巧能学到,对于疑难解答也是不错的地方。这里主要列举几个还不错的位置。

Discord。虽然更主要的是用在了游戏讨论或联机语音上,但作为Linux社区,同样有相关的分类。而正因为其最本质的功能,所以这里的实时性很不错。但语言基本就是英语确定了,而且可能访问上面有点儿问题。

Reddit。所谓美版天涯+贴吧。用户基数很大,相关的问题也很多且基本都有很有效的解决方法。如果你注意过的话,百度一些Linux或者开源相关的问题经常会引导到Reddit的帖子上,且很有效。但是跟Discord一样,语言基本就是英语了,可访问性也有点儿飘忽不定。

项目GitHub的issue。这自然是针对特定开源项目的一个“社区”。因为所有话题都围绕着一个软件产生,所以更容易看到与自己类似的情况,且能获得作者的解答。但不一定每一个项目都把issue维护的那么好,而且可能看到世界各地的各种各样的语言。

放眼国内,Linux相关的综合社区不算太多。我注意到的就是Linux社区和Linux中国。这俩都是老牌的Linux相关“发布站”,有时候也有一些其他的开源项目的使用教学。不过交流性不强,更适合作为信息获取平台而非解答平台。

开源中国也很出名,内容覆盖的多而广。但针对Linux的内容就有些不好找了。

与开源社区对应的,就是以独立单位发布的自媒体了。这包括博客和视频两类。

博客,可以说层出不穷,而且经常有很多实用的解决方案和操作技巧的文章出现。但受限于SEO的问题,除了CSDN这种博客外,很多个人博客有可能很难找到。且由于是个人维护,时效性便得不到保证了。因此如果使用个人博客的内容,建议先看一看文章的发布时间和最后修改时间。

视频,其实针对Linux的自频道在国内可以说是很罕见了。放眼全球,中文语言的Linux自频道数量也不多。所以虽然视频演示的话相比博客会更容易理解,但想寻找到关于这类的中文自频道就比较困难了。所以视频这方面我就直接推荐几个英语频道吧。有兴趣的可以看一看。

Chris Titus Tech,也是我一直在看的一个频道。围绕Linux的包括但不限于基本操作教学的各种内容,也有一小部分Windows的视频。总体来说质量还挺好的。

DistroTube,一个倾向于介绍各种发行版的频道。跟随它可以第一时间跟进各种热门发行版的新特性以及发行版之间的各种比拼。这是一个很纯粹、完全不涉及其他类型系统的频道。

TLG // Technology · Linux · Gaming,看频道名也明白了,这个频道专门发布Gaming on Linux内容的视频。我认为看过这个频道之后,就能破除很多人对Linux的那种停留在十多年前的印象了。

ExplainingComputers,诺丁汉大学教授运营的一个频道。内容涉及从Linux系统到计算机硬件层面的内容。对于学习Linux来说,可能不如前面三个频道来得快,不过这个频道能很好的拓宽你的视野。

五、检索

想要聚合上面说到的所有资源,搜索自然是最好的一个聚合工具了。显然,综合了各种可能的资源,一起展现是搜索引擎最大的优势。而且都是根据你搜索的内容筛选的结果,针对性更高。但大量的结果也对应一些问题:结果掺杂广告是一方面,由于Linux及开源的性质,越有用的信息,英文占比越大是一方面,需自行对有价值的结果进行筛选才是最有难度的一个问题。而为了最大程度优化初筛的结果(也就是输入了搜索条件后点击搜索按钮后得到的页面结果),这里不得不提一些检索相关的技巧了。

第一,使用关键词搜索而不是一句话,关键词用空格隔开。

这是最应记住的基本的检索技巧。通过关键词检索,你的检索条件有用信息占比可以达到最高水平,自然就能最大程度命中最符合你的检索需求的内容了。

第二,不管你信不信,国外在开源方面的讨论更有技术性,通常也更有帮助。所以寻找解决方案的时候,使用英语关键词在必应国际版或谷歌上搜索,效率会更高。

至于中文方面,个人博客通常更有参考性。因此如果实在不想读英语,使用中文关键词在必应国内版或谷歌上进行检索,也会有还算不错的结果展现。

最后,才应该想到提问这个路子。就我本人来说,从09年开始用Linux到现在,我一直没有提出过问题,仅仅检索到的东西就足够应对出现的问题了。事实也是这样。毕竟Linux出现了半个世纪了,啥可能的坑都有前人踩过了,因此很难出现一直到现在还没有人问过的问题。所以如果用作日常使用的话,可以检索到的内容应该足以解决问题。解决不了只能说明是检索技巧出现了差错。

所以说,提问仅仅在你竭尽所能的利用检索技巧但仍没有有用的信息时的一个解决方案。而去社区提问是最佳选择,所谓人多力量大。

反之,最下策才是向个人提问。一来个人不可能拥有那么多那么全的经验,而且时延太没谱了。

可能有人不明白:上学时候总说不懂的要问,怎么这里反而不推荐了呢?

首先,问到的结果一来自己不容易记住,二来得到的解答无脑照着操作,得不到任何提升,最后,Linux的自定义性太高了,所以如果不自己理解的话,往往会把本身是解决方案的解答判断成无效的方案。也正因最后一点,如果提问的时候仅仅描述了出现了什么问题,那么这个提问可以被称作是一个无效问题了。所以,一个最容易得到有效解答的提问最好包含下面几点:

想干什么的时候出现了什么错误;

出现此问题前都对系统进行过哪些调整;

尝试过了哪些方案;

与此出错操作有关系的组件都处在什么状态,部署在了什么文件夹中;

用户配置文件是什么样的;

用的哪个发行版;

相关的软/硬件环境如何

如果不了解自己的Linux的这些内容,那么最好的解决方案还是重装吧…不知道这些内容说明对Linux还不是很熟悉,而解答者不知道这些内容,也就只能给出通用方案。而面对这个通用方案,提问者往往又不能根据自己的电脑做对应的修改,也就成了死结了。

以上就是我学习Linux的一些来源和方法了。总结一下,核心是使用,在使用中自然会遇到不知道的问题,这时候针对问题来查找解决方法,而一个解决方法往往连带出一些基本的操作,所以慢慢的,对Linux的理解自然就提升上来了。

视频点此

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

一、“古典概型”

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

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

这就是传统的三维寻址,学名叫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表现给用户的东西要比传统启动简单了太多太多。很多时候问题来源于你的设置,而不是系统厂商。

视频点此

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

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

1、碟片和磁头

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

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

2、磁道、柱面和扇区

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

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

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

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

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

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

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

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

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


最近更新

  • 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我可能很难想起来去看…