这是一个专门讨论 idea 的地方。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
每个人的时间，资源是有限的，有的时候你或许能够想到很多 idea，但是由于现实的限制，却并不是所有的 idea 都能够成为现实。
那这个时候，不妨可以把那些 idea 分享出来，启发别人。
这是一个创建于 3207 天前的主题，其中的信息可能已经有所发展或是发生改变。
魔法数(2 bytes)
主版本
元数据区块
- 唯一 ID
- 标题
- 作者
- 发行
- 来源
- ...
数据区块
- 唯一 ID
- 解析方法
- flag
- CRC32 校验
- 数据(protobuf)
-- 类型(默认=TEXT/1 可省略)
-- 内容(string/bytes/link)
拓展区块(类 gzip)
可拆分~重组
前面直接插入 jpeg _(:з)∠)_ 还能当封面~2333
以上纯属 娱乐~ 欢迎来黑~
主版本
元数据区块
- 唯一 ID
- 标题
- 作者
- 发行
- 来源
- ...
数据区块
- 唯一 ID
- 解析方法
- flag
- CRC32 校验
- 数据(protobuf)
-- 类型(默认=TEXT/1 可省略)
-- 内容(string/bytes/link)
拓展区块(类 gzip)
可拆分~重组
前面直接插入 jpeg _(:з)∠)_ 还能当封面~2333
以上纯属 娱乐~ 欢迎来黑~
第 1 条附言 · 2016-02-12 10:32:16 +08:00
_(:з)∠)_ 这轮子我不造了~2333
第 2 条附言 · 2016-02-12 16:10:47 +08:00
初衷
闲着慌 + 6.1k 本书～
设计过程
图标都一样，名字全是 id
前面塞个 jpeg 当缩略图
zip 包纯文本什么都看不到～
加个 meta
json 直接读略麻烦，好像只有 img 来着
来换个 md ！可读性 max
webp 压缩效果不错～但是不支持怎么办～如果不要图怎么办～
好加个拓展包
啊～原 zip 包没法解了
基于 gzip 重写解压工具
看看File 格式
来个魔法数 就 knv 吧～ 233
假如升级怎么办加个版本
大概要个 UUID 做拓展包
CRC-32 校验保留吧～
然后就出来这个鬼～～
原数据
.
├── cover
├── data
│ ├── 19925.json
│ └── 20037.json
├── image
│ ├── 01468b6d85803b47f52f0a2a62978754
│ ├── 135d8742fbf16d580ce65c6c518787b0
│ └── febb215a2552db7918830dca52d4326c
└── information
├── book.json
├── chapters.json
└── volume.json
3 directories, 32 files
Format
Byte Order: Little-endian
Offset Lnegth Contents
0 3 bytes magic header `knv`
3 2 bytes Major version
5 4 bytes UUID
9 2 bytes Length of Meta(a)
9 4 bytes Length of Data(b)
13 (a) byte Meta(plain text,eg:"id,title,subtitle,description,author,press,source",'\0' terminated)
13+a 4 bytes CRC-32
17+a 2 byte 0x02 (STX)
21+a (b) byte Data(bytes,compressed data)
21+a+b 2 byte 0x03 (ETX)
23+a+b (b) byte Extension Block(bytes,compressed data)
Meta Block
包含可直接浏览的纯文本描述
eg:
{
"bookid": 109,
"volumeid":2576,
"title": "狼与香辛料",
"subtitle": "第 14 卷",
"author": "支仓冻砂",
"intro": "芙兰答应帮罗伦......卷中重新登场！",
"press": "电击文库",
"source": "http://xxx.xx/xx"
}
m 狼与香辛料" 支仓冻砂* 电击文库...
Content Block
序列化数据（使用 JSON/FlatBuffers ）
压缩：可选
[{
"C": "3d4caaf680dfde29a849a467d181c484",
"T": 1
}, {
"C": "有话要说——被这么叫进房间的罗伦斯刚一推开房门就不禁为眼前的这片光景屏住了呼吸。",
"T": 0
}, {
"C": "实在是太美了。",
"T": 0
}]
Extension Block
压缩过的可替换数据
如：图片的 jpeg 和 webp 版本
 |
1
love 2016-02-11 12:28:14 +08:00
自已瞎搞的二进制的不好调试，何不随大流用 zip 格式打包的 xml 及相关文件
|
 |
2
Strikeactor 2016-02-11 12:30:55 +08:00
各平台没有相关客户端实现的话，拿这玩意打包了要咋看
|
 |
3
vcfghtyjc 2016-02-11 12:39:02 +08:00
格式这种东西，说到底还是看支持的平台多不多。
|
 |
4
9hills 2016-02-11 12:50:12 +08:00 via iPad
为啥不用 epub
|
 |
6
dphdjy OP @Strikeactor 这个不是问题~除了 iOS~相关库可以轻易写出来~233
|
|
7
dphdjy OP @9hills 那几千本轻小说没有用上 epub 的特性就是 txt+jpeg~用 epub 在制作~储存~解析方面产生的浪费~
简言之:杀鸡焉用牛刀 |
 |
8
Quaintjade 2016-02-11 13:18:15 +08:00 via Android
@dphdjy
epub 还是 txt+jpeg 就好，别想着搞什么特效。 以前试过一些号称制作精美的 epub 电子书，结果几乎每个 epub 阅读器的显示效果都不一致，其中至少一半根本就是页面布局崩了。 |
|
9
dphdjy OP @Quaintjade 对！因为标准复杂~每个实现差异太大~反之浪费 epub 的特性远不如 txt+jpeg
所以才想做一个轻量高效的格式~ 刚开始准备 zip 打包进 markdown+jpeg 后来发现可能只要用 4 种格式~ 还是比较麻烦~遂沿用之前的部分东西变成二进制 元数据明文保存 数据区块 可明文 /压缩 拓展区块 可压缩 区块可分离~ 元数据区块维护 hash 表外链~ |
 |
10
msg7086 2016-02-11 16:15:34 +08:00 via Android
为了节约几个时钟周期或者几个字节去重新造轮子才叫牛刀。别说 ios ，你先研究下怎么让你的书在 kindle 上看。
|
 |
12
loading 2016-02-11 18:35:19 +08:00 via Android
对于小说正文的内容来说，附加信息也就那么一点，还不如直接 json
|
 |
13
FFLY 2016-02-11 19:35:47 +08:00
话说很久以前也想自己造个轮子， PC+移动，全平台，后来发现就算造出来了，还要把那么多轻小说都转格式，否则就是自娱自乐，再看看工作量，果断放弃。
|
|
14
dphdjy OP |
 |
16
shyling 2016-02-11 19:56:21 +08:00
我需要一个目录
|
 |
17
pynix 2016-02-11 19:58:01 +08:00
新轮子
|
|
19
dphdjy OP |
|
20
dphdjy OP |
|
22
dphdjy OP @Earthman 比如~前年为了开发某国内小说平台的 android APP 原始数据 txt~我硬是写了 epub 转化+fb 精简版+UI 适配~然后主要放在适配上用了 2 个月
现在看来那时候完全没必要用上这些东西~自己造轮子 一周大概就可以了~那样编写核心问题就在 Android 显示上，也不用后期花几倍时间精简 fb 的各种模块 最后 APP 完成是 2MB 左右来着~ |
 |
24
yonglanyouyou 2016-02-12 10:08:47 +08:00
诺基亚时代有一种流行的小说文本图片打包格式叫做 umd
|
 |
25
fy 2016-02-12 11:39:51 +08:00
LZ ， json 啊。文本格式本身在扩展方面有巨大优势，而且别人根本不用费力读你的二进制文档就能生成出差不多的书，同时能将信息丢失的影响减小到最小。
meta 信息首尾各一单行 json 来描述，正文爱用什么用什么， markdown 在段落上丢失信息太多，并不适合电子书。 还不如只是加上一个对图片、加粗、斜体等等简单排版的支持（而且也不是不能扩展）。 |
|
26
dphdjy OP @fy 现在就是 json 唷~
结构如下: zip 壳 - data -- x.json - img -- x - info -- book.json -- vol.json -- chap.json - cover _(:з)∠)_ 感觉做出新格式多好玩 23333 以及粗略统计轻小说的内容格式很单一 md 完全可以胜任 不考虑其他问题，只关注这种格式的需要优化的问题 PS:目前用二进制压玩和 zip 基本没体积优势 2333 |
|
28
fy 2016-02-12 12:38:27 +08:00
@dphdjy markdown 你试试这种文本：
1 2 3 4 5 6 7 再比如写信的格式 OOXX ： XXXXXXXXXXXXXXXXXXXXXXXX. XXXXXXXXXXXXXX: OOOOOO OOOOOOO XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX OOXX OOXXOOXXOOX 能正确显示才有鬼了 |
|
29
fy 2016-02-12 12:41:06 +08:00
尼玛，空格都被吃了
 |
|
30
dphdjy OP @fy 来个源文件给你~
http://pan.baidu.com/share/link?shareid=3288077794&uk=655169298 其中 json 是分段储存~ 以及上面那 12 什么的(ಥ_ಥ) 那是什么鬼~ 不过可以用 pre 框起来~ 下面的信~这格式好谜~ 这个只有更高等的语法才能表示 233 (如果不表意 pre 依然可以~) 不过这边的原文并没有用到~~ 我并不准备做一个 epub 类的万能文档格式~ 只是做个轻小说的而已~ |
 |
31
ipconfiger 2016-02-12 13:24:08 +08:00
这个轮子造起来既没有实用性也没有技术含量, 有神码意义? 小说本来就是文本, 你用什么二进制的 meta 根本省不到几个 byte, 简直就是脱了裤子放屁, 还不如老老实实用文本的, 实在要节约体积 zip 一下就好了. 发明什么的好歹要以理论为基础用实践为准绳, 这种民科似的发明创造实在是不可取的
ps: 一再强调轻小说什么的, 那是个什么贵, 比重小说要高级? |
|
32
dphdjy OP |
|
34
dphdjy OP @ipconfiger 关于强调轻小说只是都和 epub 比较
小说是纯文本 文档可以包含各种插入内容，更佳复杂的排版信息 但是轻小说主要就是纯文本+插图 本身就是 txt+jpeg 一般也就是 zip 加个壳 至于上面的二进制什么的~其实只是对 txt 和 jpeg 部分的压缩 meta 是因为压缩之后不可读而已，还有拓展区块的 link 比如对于图片储存什么的可以对整体压缩打包~ 我再去加个附言说明 |
|
37
dphdjy OP |
|
38
dphdjy OP @dong3580 md 更爽～！！
txt: 虽然这话自己听着都刺耳，可赫萝却平静地回答道。 “要是和人谈起赚钱的事情，咱的利益不就减少了呗?” 如果她不是露出恶作剧般的笑容这样说的话，罗伦斯也许连苦笑着接受那话都很困难。 赫萝起身，轻轻伸个懒腰动了动耳朵。 “不可以太过亲近。”这是他们彼此间心照不宣的重要事项。 可是在注意那件事时事情不但向相反的方向发展了，罗伦斯甚至还曾抛开过那重要事项。 即使是赫萝，在漫长到也许接近永远的旅途中，也绝对不止一次两次踢飞过挡路的大石头。 就算那样，也不能因此改变现实。 赫萝把柯尔比作“使自己保持贤狼的重石”，应该不是夸张的表现。 拿柯尔捉弄罗伦斯除了事情本身很有趣以外，大概也包含自卫的意味在内吧。 为了不越过那条线。 为了将明明明白却无计可施的事情蒙混过去。 将那焦躁作为最低限度的借口。 md:  |
|
39
FFLY 2016-02-12 19:18:22 +08:00
@dphdjy 我说说我之前的想法，首先为了实现跨平台和在线阅读，我把图片和文本做了分别的封包。然后通过标识符和语法，实现简单的排版和图片占位。
123.data - 主封包，包含文本和图片。 123.th.data - 预览用封包，包含小说简介和封面。 之前就是计划这样分开做，还蛋疼的写了个简单校验和加密，后来就没有然后了。 |
Select Language