Legado项目中第三方书源重复问题的技术分析与解决方案

问题背景

在开源阅读应用Legado中，用户可以通过导入第三方书源来扩展阅读资源。然而，随着书源数量的不断增加，出现了一个显著的技术问题：大量重复书源的存在。这些重复书源不仅占用数据库空间，还会对书源服务器造成不必要的请求压力。

问题根源分析

经过技术分析，我们发现导致书源重复的主要原因在于书源URL的处理方式。许多书源作者为了在书源中留下标识信息，会在bookSourceUrl参数后添加"#名称"这样的片段标识符。虽然这些URL指向的是同一个域名下的资源，但由于片段标识符的存在，系统会将其识别为不同的书源。

从技术角度来看，URL中的片段标识符（即#后面的部分）本应用于页面内锚点定位，不应该影响资源的实际定位。但在当前实现中，系统将整个URL字符串作为唯一标识，导致了重复书源的产生。

技术解决方案

1. 域名提取与匹配

核心解决方案是引入域名提取功能，通过正则表达式从URL中提取出真实的域名部分进行匹配。我们实现了以下关键函数：

fun getDomain(key:String):String? {
    val urlRegex = "https?://(?:[a-zA-Z0-9-]+\\.)?([a-zA-Z0-9-]+(?:\\.[a-zA-Z0-9-]+)+)".toRegex()
    val matchResult = urlRegex.find(key)
    return matchResult?.groupValues?.get(1)
}

这个正则表达式能够准确提取URL中的主域名部分，忽略协议、端口和路径等信息。

2. 数据库操作优化

在数据库层面，我们实现了基于域名的查询和删除操作：

@Query("select * from book_sources where bookSourceUrl like '%/' || :domain || '%' or bookSourceUrl like '%.' || :domain || '%' limit 1")
fun getBookSourceByDomain(domain: String): BookSource?

@Query("delete from book_sources where bookSourceUrl like '%/' || :domain || '%' or bookSourceUrl like '%.' || :domain || '%'")
fun deleteBookSourceByDomain(domain: String)

这些操作允许我们基于域名而非完整URL来管理书源。

3. 书源导入处理流程

在书源导入阶段，我们增加了以下处理步骤：

1. 过滤无效书源（无法提取域名的URL）
2. 按域名分组
3. 在每个域名组中保留最新更新的书源
4. 将处理后的书源加入数据库

val filteredBookSources = validSources
    .groupBy { getHost(it.bookSourceUrl) }
    .mapValues { entry -> entry.value.maxBy { it.lastUpdateTime } }
    .values.toList()

技术争议与考量

在解决方案讨论过程中，出现了不同的技术观点：

1. 自动化处理的必要性：支持方认为随着书源数量增长，手动管理变得不现实；反对方则认为不同书源可能有不同的优势功能，自动化处理可能丢失有价值书源。

2. 用户选择权：折中方案建议将重复书源处理作为可选功能，让用户自行决定是否启用。

3. 性能考量：大量书源确实会影响应用性能，但完全依赖自动化处理可能无法满足所有用户需求。

实现建议

基于技术分析，我们建议采取以下实施方案：

1. 在设置中增加"自动处理重复书源"选项，默认关闭
2. 提供一次性清理重复书源的功能
3. 在书源导入界面增加重复检测提示
4. 保留完整URL信息的同时，使用域名作为主要比对依据

这种方案既解决了技术问题，又保留了用户的选择权，能够满足不同用户群体的需求。

总结

Legado项目中的书源重复问题是一个典型的技术实现与用户需求之间的平衡问题。通过引入基于域名的书源管理机制，我们能够有效减少重复书源带来的各种问题。同时，保持功能的可配置性也尊重了不同用户的使用习惯。这种解决方案不仅适用于当前问题，也为未来可能出现的类似技术挑战提供了参考框架。