我正在尝试开发一个小的实用程序,它应该使uTerrent的洪流池中的一些维护任务自动化。要验证部分下线股票的散列,我必须从~uTorrentPartFile_XXX.dat文件中检索uTorrent保存它们的部分,这些部分并不完全包含在下载的文件中。这就引出了两个问题:
.torrent文件,如何计算相应~uTorrentPartFile_XXX.dat文件的名称(即uTorrent使用的十六进制字符串而不是我的~uTorrentPartFile_XXX.dat)发布于 2019-08-02 08:52:02
BiglyBT团队在创建迁移插件时对~uTorrentPartFile_XXXX.dat格式进行了反向工程。
https://www.biglybt.com/download/utMigrate
https://github.com/BiglySoftware/BiglyBT-plugin-migratetorrentapp
/**
* uTorrent partfile
* Basically, torrent data is split into 64k parts. Header has 4 byte index for
* each part, pointing to data if index is > 0.
* After the header is the 64k data chunks, first data chunk is 1, second is 2, etc.
* Last data chunk may be smaller than 64k.
*
* ~uTorrentPartFile_*<hexsize>*.dat
* <Header>, <data>
*
* hexsize
* torrent data length in bytes in hex with no leading 0
*
* Header
* <DataIndex>[<Num64kParts>]
* Raw header length = <Num64kParts> * 4
*
* Num64kParts
* How many parts is required if you split torrent data length into 64k sections.
* ie. Math.ceil(torrent data length in bytes / 64k)
*
* DataIndex
* 4 byte little endian integer. Values:
* 0
* No data for this 64k part
* 1..<num64Parts>
* 1-based positional index in <data>
* Location in part file can be calculated with
* (Header Size) + ((value - 1) * 64k)
*
* data
* <DataPart>[up to <num64kParts>]
*
* DataPart
* 64k byte array containing torrent data.
* Bytes in <DataPart> that are stored elsewhere in real files will be 0x00.
* ie. non-skipped files sharing the 64k part will be 0x00.
* Last <DataPart> may be less than 64k, which means the rest of the 64k would
* be 0x00 (and part of a non-skipped file)
*
*/奖金
代码注释中还有一些关于resume.dat和settings.dat中的内容的有用信息:
https://stackoverflow.com/questions/51021703
复制相似问题