Files
reader/web/test/encoding.test.ts
T
cnb.dQC5J6ohAGA c18664f1e3 feat(reader): 按窗口读取、真机可编译的 Android 壳,以及分章契约的收口
两件事:把 PR #8 里那四项合并进来(A 选项),然后把 issue 里一直没落地的
「一次只取一章」从服务端契约一路做到客户端。

## 一、PR #8 的四项(Android 外壳最值钱)

- Android 原生整页图渲染:NativePageView + 桥接 v2(renderPage/hidePage)。
  只画整页图,EPUB 永远留在 WebView;画不了就返回 false 回退,不出现空白页。
- 离线队列:脏集合语义固定为契约,补上「请求在途时位置被改写」的三条用例。
- TXT 编码探测:GB18030 与 Big5 都解一遍再按损坏证据评分选优。
  原来「先 GB18030 失败再 Big5」永远走不到第二步——两者字节范围重叠,
  同一串字节通常两边都能解出合法字符,繁体书会整本乱码。
- 格式嗅探:magic number 优先于扩展名,并明确拒绝非书籍的媒体容器。

## 二、Android 壳第一次真的编译通过

上一轮说「没有 JDK/SDK,只写了契约」,这一轮补上了环境并真的编译。
编译立刻暴露三处——都是只有编译才能发现的:

- colors.xml 的注释里写了 --reader-paper。XML 禁止注释中出现双连字符,
  AAPT 直接拒绝整个文件。Android 壳此前从未构建过,所以从未发现。
- NativePageView.kt 用了 Uint8Array。那是 JavaScript 类型,Kotlin 里不存在;
  桥接的另一侧是 ByteArray。
- AndroidManifest.xml 引用了 @mipmap/ic_launcher,而资源里没有这个文件。

三条都让 :app:assembleDebug 失败,也就是说这个 APK 此前根本产不出来。
现在是 BUILD SUCCESSFUL,产物 3.6MB。

## 三、分窗读取:从契约做到客户端

服务端:
- /manifest 省略 group 现在等价于 group=0。原来省略意味着「发全部条目」,
  于是一本 1200 章的书在它最需要快的那个请求(打开书)里收到 1200 条记录,
  等于分窗对不传参的客户端完全失效。要完整结构用 ?group=all。
- /toc 在没有 OPF 标题映射时回落到章节自身的第一个标题。手作 EPUB 大量
  没有标题映射,原来整本目录会读成「第 1 章 … 第 300 章」,等于没有目录。
- 扫描时的 spine 读取不再解析 NCX 与 nav:扫一遍全库本该只读一次包文档。
- 尾部 Range(bytes=-N)在超过 8MB 时退化为整包响应并撤回 Accept-Ranges。
  前向流无法跳到文件末尾,服务这种请求意味着为三个字节读完整个 400MB 漫画包。

客户端:
- 新增 formats/remote-zip.ts:走 HTTP Range 的只读 ZIP,让浏览器端也能不下整本书。
- 新增 formats/windowed.ts:分窗文档。分窗是传输边界,目录必须完整,两者分开
  —— 合在一起就是原来目录面板显示「第 1 章 – 第 40 章」的原因。
- reader-screen 接上 /toc,并且点击目录项会先取对应窗口再跳。

## 验证

server:  133/133(typecheck + test + build)
web:     179 vitest + 29 node:test(typecheck + test + build)
android: BUILD SUCCESSFUL,app-debug.apk 3.6MB
shell:   契约双向校验 + 渲染模式词表校验通过
2026-09-16 19:51:38 +08:00

110 lines
4.7 KiB
TypeScript

import { describe, expect, it } from 'vitest';
import { decodeText, isValidUtf8 } from '../src/formats/text-encoding.ts';
import { big5Bytes, gb18030Bytes, utf8 } from './helpers/fixtures.ts';
/**
* Encoding detection is the difference between a readable TXT and a screen of
* replacement characters, and it is the one place where a wrong guess is
* silently catastrophic rather than merely inconvenient.
*/
describe('UTF-8 validation', () => {
it('accepts ASCII and multi-byte UTF-8', () => {
expect(isValidUtf8(utf8('plain ascii'))).toBe(true);
expect(isValidUtf8(utf8('中文混排 with English'))).toBe(true);
expect(isValidUtf8(utf8('日本語のテキスト'))).toBe(true);
expect(isValidUtf8(utf8('emoji 🎉 and combining é'))).toBe(true);
});
it('rejects an overlong encoding, which a naive decoder would accept', () => {
// 0xC0 0xAF is an overlong encoding of '/'. Accepting it is the classic way
// a validator becomes a security hole in a path-handling context.
expect(isValidUtf8(new Uint8Array([0xc0, 0xaf]))).toBe(false);
});
it('rejects a lone continuation byte and a truncated sequence', () => {
expect(isValidUtf8(new Uint8Array([0x80]))).toBe(false);
expect(isValidUtf8(new Uint8Array([0xe4, 0xb8]))).toBe(false);
});
it('rejects a surrogate code point encoded in UTF-8', () => {
// ED A0 80 encodes U+D800, which is not a valid scalar value.
expect(isValidUtf8(new Uint8Array([0xed, 0xa0, 0x80]))).toBe(false);
});
});
describe('decodeText', () => {
it('strips a UTF-8 BOM so it does not leak into the first chapter title', () => {
const bytes = new Uint8Array([0xef, 0xbb, 0xbf, ...utf8('第一章')]);
const result = decodeText(bytes);
expect(result.text).toBe('第一章');
expect(result.text.charCodeAt(0)).not.toBe(0xfeff);
expect(result.guessed).toBe(false);
});
it('detects UTF-16LE from its BOM', () => {
const le = new Uint8Array([0xff, 0xfe, 0x2d, 0x4e]);
const result = decodeText(le);
expect(result.encoding).toBe('utf-16le');
expect(result.text).toBe('中');
});
it('decodes valid UTF-8 without guessing', () => {
const result = decodeText(utf8('第三章 风起'));
expect(result.text).toBe('第三章 风起');
expect(result.guessed).toBe(false);
});
it('falls back to GB18030 when the bytes are not valid UTF-8', () => {
const bytes = gb18030Bytes('第一章 起始');
// Guard the premise: if these bytes happened to be valid UTF-8 the test
// would pass without exercising the fallback at all.
expect(isValidUtf8(bytes)).toBe(false);
const result = decodeText(bytes);
expect(result.text).toBe('第一章 起始');
expect(result.encoding).toBe('gb18030');
expect(result.guessed).toBe(true);
});
it('marks the result as guessed so the UI can offer an override', () => {
const result = decodeText(gb18030Bytes('测试'));
expect(result.guessed).toBe(true);
});
it('chooses Big5 over GB18030 when GB18030 produces damage and Big5 does not', () => {
// The whole reason the two candidates are scored instead of tried in order:
// these bytes also decode "successfully" as GB18030, so a fixed order would
// never reach Big5.
const bytes = big5Bytes('第一章 測試內容這是一段中文文本用來判斷亂碼');
expect(isValidUtf8(bytes)).toBe(false);
// Guard the premise of the test: GB18030 does decode them without throwing.
expect(new TextDecoder('gb18030').decode(bytes)).not.toBe('');
const result = decodeText(bytes);
expect(result.encoding).toBe('big5');
expect(result.text).toBe('第一章 測試內容這是一段中文文本用來判斷亂碼');
expect(result.guessed).toBe(true);
});
it('still prefers GB18030 for Simplified bytes, which also decode as Big5', () => {
// The other half of the same overlap: Simplified GB18030 bytes are accepted
// by the Big5 decoder too, and are only distinguishable by the damage they
// produce there. If the scoring were wrong in the other direction the
// majority of Chinese TXT libraries would break.
const bytes = gb18030Bytes('第一章 起始');
const result = decodeText(bytes);
expect(result.encoding).toBe('gb18030');
expect(result.text).toBe('第一章 起始');
});
it('marks the result as guessed so the UI can offer an override', () => {
const result = decodeText(gb18030Bytes('测试'));
expect(result.guessed).toBe(true);
});
it('always returns something for undecodable bytes rather than throwing', () => {
const garbage = new Uint8Array([0x81, 0x82, 0x83, 0xff, 0xfe, 0x00]);
const result = decodeText(garbage);
expect(typeof result.text).toBe('string');
});
});