正文倒是都可以看，就是无法解压出来，在win下会把文件名识别成下划线 _ 。好奇这是怎么做出来的。
<item id="mid002" href="Styles/:**:*:*:**:*:::*:*::*:*:::::**:*******:*::***:::*::*.css" media-type="text/css"/>
看着像是sigil做的，用sigil也打不开。但是正常阅读都没问题。
这是什么，完全看不懂
压缩后在压缩包里改名呗， 大概。
简单来说就是他把epub里面每一个文件名“加密”了。
正常是 第一章.xhtml 第二章.xhtml 全部换成 **:*:*:**:*.xhtml 格式。虽然在阅读器里能正常阅读，但是把epub解压出来后，因为系统限制，导致文件名变成 ______.xhtml 这样解压出来的内容，因为文件名相同，会互相覆盖，最后只得到部分内容。
1k+的文件，我不认为是压缩后改的，难道有压缩包内批量改名文件？更何况还要做章节对应顺序。
看起来好像摩斯电码？
Windows文件名不能用*号？和这个有关系吗？
这思路真是厉害，有意思。
我问了gpt如何用符号混淆zip内文件名，他的回答：
import zipfile
import os
def obfuscate_filename(filename):
# 这是一个简单的混淆函数，你可以根据需要修改
return filename.replace('a', '*').replace('e', ':').replace('i', '*').replace('o', ':').replace('u', '*')
def obfuscate_zip(input_zip, output_zip):
with zipfile.ZipFile(input_zip, 'r') as zip_ref:
with zipfile.ZipFile(output_zip, 'w') as new_zip:
for file_info in zip_ref.infolist():
# 获取原始文件名
original_filename = file_info.filename
# 混淆文件名
obfuscated_filename = obfuscate_filename(original_filename)
# 读取文件内容
file_data = zip_ref.read(original_filename)
# 写入新的zip文件中
new_zip.writestr(obfuscated_filename, file_data)
input_zip = 'input.zip' # 替换为你的输入zip文件路径
output_zip = 'output.zip' # 替换为你想要输出的zip文件路径
obfuscate_zip(input_zip, output_zip)
print(f"混淆完成，生成的zip文件为: {output_zip}")
你可以反向试试
如果可以，把文件发出来让大家把玩下
只是在Windows系统下不允许路径使用*号，这种要修改也简单，首先要能够正常显示文件名，找个Linux/Unix系统试试。
看了一眼文件名，开头的字符都是一样的，很可能就是简单的将原文件名按照字符一个个替换成点和星号的特定组合。
lz能分享一个样本吗，有点好奇
7z就有命令行版本
“
rn (Rename) command
rn (Rename) command
Renames files in archive.
Syntax
rn <archive_name> <src_file_1> <dest_file_1> [ <src_file_2> <dest_file_2> … ]
Example
7z rn a.7z old.txt new.txt 2.txt folder\2new.txt
renames old.txt to new.txt and 2.txt to folder\2new.txt .
”
有命令行≈能批量
如何把原文件名转换成 : / * ,自己选个方法就好
但是为什么不把文件名弄短点呢， 还能减少epub体积
手动缩减了体积，但文件结构还在。不知道为什么明明没删css，但是整个页面都乱了。
他用了两个同名文件，unix允许同名文件存在吗？专门拉一个进去压缩包内也挺奇怪的。
大概扫了眼opf，不是一眼能看出来的规律。可能不是英文转的。
可能是运营商的限制，我这里无法访问您分享的文件。但我有一个猜测：会不会是压缩文件编码的问题，也就是说文件名中的星号其实不是文件的本名，而是因为系统无法识别压缩包文件名的编码而错误显示出来的。
至少 Linux 不支持。
传了个度盘，300多k，应该网页就能下。
折腾了一下，手上没合适的工具，还确实拿他没办法。不过据说Linux下文件名支持各种特殊字符（除了路径分隔符），所以对付这种文件名应该也不在话下，也许是个解决方案？
搜到了混淆与反混淆工具代码 GitHub - cnwxi/epub_tool: 一些可用的epub工具
此帖终结
4 个赞
完美还原。
怕不是同一个作者，想出来如此清奇的脑回路。
用字符串的多寡来进行加密？牛的
这不能叫混淆吧，东西全都在 toc.ncx 里，随便看的
1 个赞
虽然本质上是图一乐，毕竟toc.ncx和content.opf里写了文件的整体架构，文件本身的名字本来就不重要。但是作者这个脑洞是真的大。