Phet离线HTML5数据

数据来自于:https://phet.colorado.edu/en/simulations/translated/zh_CN
缘起于前几日pdawiki有坛友发了这个mdx,严格来说是mdd吧。
phet_raw.7z (20.4 MB) 样例网页:wave-on-a-string_zh_CN.7z (250.7 KB)
个人从上述主页dump出来一份单html文件的网页,只有80几个网页,只要将每个网页中的body标签内的部分(最前面一部分是引用的license和repo信息,也是可以去掉的)提取出来,就可已把每个html文件的名字做词头压缩成mdx了(如此并不需要mdd),80几个词条的HTML5动画展示。计划过阵子将WebEngine(Chrome kernel)植入GoldenDict,需要部分测试的媒介,所以本想自己做这个mdx的,奈何掌握的正则手法不过关,所以把文件数据放上来,有能力又有空的坛友能做一下最好了,实在没得到时候我再处理。

我来 :grinning:

链接: https://pan.baidu.com/s/1qW51KNm76afd5HKmYn_N8g 提取码: 67ct

4 Likes

直接用python和bs4合并的

大神真是神速哈 :smiley:

淦 溜了

from bs4 import BeautifulSoup
import os

write1 = open('done.txt', 'w', encoding="utf8")

js_css = """<link rel="stylesheet" href="phet.css" type="text/css" ><script type="text/javascript" src="phet.js"></script>"""

div = '<div class="menu_single"><a href="entry://{}">{}</a></div>'

for _, __, files in os.walk("."):
    zh_entries = []
    eng_entries = []
    for file_name in files:
        if '.html' in file_name:
            print(file_name)
            # print(file_name)
            read1 = open(file_name, 'r', encoding="utf8")
            raw = BeautifulSoup(read1, 'html.parser')
            zh_entry = raw.title.string
            eng_entry = file_name.replace("_zh_CN.html", '').replace("-", ' ')

            write1.write(eng_entry + '\n' + js_css + str(raw.find("body")).replace('\n', '').replace('\r', '') + '\n</>\n')

            write1.write(zh_entry + '\[email protected]@@LINK=' + eng_entry + '\n</>\n')
            zh_entries.append(zh_entry)
            eng_entries.append(eng_entry)
# 目录
# temp = ""
# for i in range(len(zh_entries)):
#     temp += div.format(eng_entries[i],eng_entries[i] + "({})".format(zh_entries[i]))

# temp = js_css + temp
# write1.write('menu' + '\n' + js_css + str(raw.find("body")).replace('\n', '').replace('\r', '') + '\n</>\n')

write1.close()
1 Like

c语言格式化不是也能缩进嘛,我感觉看起来差不多,除了指针(淦!)

cpp一加指针,写个代码都要调半天

对了,打包的时候 block size 设置大一点,直接把文件传上来吧。。这种情况,block size大,总大小就能小很多的,

别提了别提了,想起了被 ** * & && 支配的恐惧了

我还在找,我把我用 mdxbuilder 4.0 的经验弄混了。。。
@atauzki 我刚才试了,大小没有变。。我以前有过改这个 record block size 的经验,改大之后文件大小变小了,这次不知道为啥。
这个 block size 还是让懂的人来说吧,我有一点相关的知识也是加密方法的 block。
估计是以多少字节为一个块来压缩。。。

设大了mdx大小没变化。源文件合并就140多兆

我感觉 mdd 不会再次压缩,只是会写 索引 (文件开头位置这些)

Hi Atauzki,能不能把英文的也爬下来?
https://phet.colorado.edu/en/simulations/index
那样摆弄完中文的可以接着摆弄英文的,顺带学习当中的英文 :grin:

自己弄吧。。

我对Python只会用replace(‘abc’,‘defg’)这样。。。

这样啊,我也试试哈 :grin:

Record BLock Size 对小文件有用,对大文件没用。大文件超过64KB会单独压缩,我实现了MDX和MDD的打包,MDXBuilder打包支持无压缩的方式,偏移量无变化应该是没有选择压缩的原因。

不知道出问题的词头是哪个?晚点有时间下载看看。

我这试了gx0001这个词头,其中几张图片,

01/f/0001.png
01/e/0001.png
01/d/0001.png

我这同样打不开,分别提示:

index 179096 out of range for slice of length 65263
index 105968 out of range for slice of length 87826
index 104864 out of range for slice of length 87008

查看了下具体原因错误,发现这些文件的RECORD_BLOCK边界很多不符合预期,理论上应该放到下一个RECORD_BLOCK的文件,仍然放在上一个RECORD_BLOCK里。

“\02\gxfow035.png” { comp_pos: 1047637498, decomp_len: 113775, comp_len: 112610, record_offset: 0, record_len: 113775 }
“\02\gxfow036.png” { comp_pos: 1047637498, decomp_len: 113775, comp_len: 112610, record_offset: 113775, record_len: 120710 }

上面是一个完整的RECORD_BLOCK,里面有两个文件,comp_pos是压缩的BLOCK位置,decomp_len是BLOCK解压后的大小,record_offset是文件相对于BLOCK里的偏移位置,record_len是文件大小。

第一个文件是对的,能正常读取,第二个文件会报错,仔细看record_offset值是错的,应该放下一个RECORD_BLOCK里。但既然MDict能正常读取,一定有哪个值是读错了。

我找阿弥陀佛要要原始文件,和他的打包程序看看。