服务端部分
服务端部分,虽然我认为 Python 非常优秀,而且效率极高,但由于服务器限制(使用学校服务器,目前暂时使用 Windows 平台,未搭建 Python 环境)。最终还是选用了 PHP 作为服务器端的脚本。
这次服务器的代码很短,这里一个数据:我编写的客户端脚本代码:17.1KB (仅含 main.js);我所编写的服务器端代码:7.6KB (7个文件)。当然,这里仅限我写的,在这次的服务端引用的各种库是非常庞大的。
首先是关于识别上传文件格式及读取时间等信息的问题,这里选用了 getID3 这一库。这个库虽然看起来其名不扬,不过功能却非常强大,能够支持几乎所有多媒体文件和部分其他文件的信息解析和写入,而且由于是高度模块化的,可以根据自己需要精简。我就留下了 MP3 可能是用的 ID3v1、ID3v2、APEtag 和 Lyrics3 的读取写入及 MP3 的信息识别这几个库。虽然功能强大,但效率是在不敢恭维……
另一个是下载用的模块,这个类使得 PHP 转发的文件可以支持多线程下载。当然,我们还可以研究一下能不能用来屏蔽迅雷~
关于下载的问题,我们发现 IE 对于下载会有一些特殊的情况,就是会出现乱码!看来 ie-fix 还得延伸到服务器端。解决方法是这样的(其中原有的文件名称为 UTF-8 编码的):
1 2 3 | if (preg_match('/MSIE/', $_SERVER['HTTP_USER_AGENT'])) $filename = rawurlencode($filename); header('Content-Disposition: attachment; filename="' . $filename . '"'); |
另外,这次的音乐 ID 不再是由 MySQL 自增了,而是使用随机数,这主要是为了后面为不同用户生成不同排序,和后面投票时对 ID 做简单的反作弊加密,而做的。虽然由于需要增加冲突检测,提交时效率可能会受一点影响,而且由于没有使用具有事务特性的库,因此可能会提交失败,但还是这样做了……因为这样能使后面更简单和有效率些~
还有值得一提的,大概就只有获取歌曲列表的地方使用了缓存。服务器端确实没什么好说的了,就那点代码……
使用部件
参考资料
界面展播
最后还是把界面亮出来吧……虽然在贴吧上已经公开过了……
Pages: 1 2




看的头晕了…
已经在帖吧里置顶了……
看起来反响还是不错的,对平台,以及对活动……
不过,我一直担心这个上传功能……要是有人吃饱撑着传N个20M的MP3上去,把服务器硬盘撑爆,或者把数据库拖跨……
虽然单机很难做到,但是多台机子用脚本同时上传的话……这莫非就是DDOS了……
那个…那个…你的主页在opera mini上的显示很有问题……