Ultimate data update

[yume-chan]

题外话：

播放地址要是用 "站点名": "地址" 的形式就好了，这样可以直接写备注，比如 优酷（VIP），Acfun（爱奇艺）。

更新内容：

1. 测试了 1310 的所有链接。其它文件，（中等）部分进行了测试。
2. 同步了不同文件中同一番组的信息。
3. 各种 bug 修复。
4. 写了个程序来管理这些文件。
   • 不同文件中，同一日文名的项目被认为是同一番组，使用同一 ID，除了 newBgm 和 endDate 字段，必须完全相同。（有个番组是不分季的分隔放送，我在第二次出现时日文名后面加了个空格）
   • 同一文件中将按照：开始放送时间较早->较晚的番组，（同一天开始放送的）BGM ID 较小->较大的番组的顺序进行排序，并分配了新的 ID
   • 自动测试 pptv 的 302 跳转更新链接。
   • 因此 Compare 已经废了，我也不知道有没有什么问题。
5. 1607 添加了 B 站的专题链接，有个 7 月正版介绍视频（http://www.bilibili.com/video/av5076570/ ）但是我没仔细看，专题页面既然已经开始承包了应该是之后会入正的吧。

[wxt2005]

1. 关于你建议的放送站点的数据格式问题，确实有考虑添加一些字段，起码可以表示是否为收费观看（当年可没这么多妖蛾子）。不过暂时还是打算维持现状（懒）。
2. ID 如果变掉了的话，和现在储存在用户 localstorage 的番组数据进行 merge 的时候会出问题。因此要合并上线的话，可能得掐好换季的时间点 XD
3. 你提到的“Compare 已经废了”是指什么意思？
4. 想问一下：你觉得是现在这种通过 GitHub 来管理 json 文件的方式好，还是我这边搞个后台，然后邀请大家来参与编辑比较好？

[yume-chan]

1. 我一开始其实不清楚 ID 的功能，但是看到后面几个文件跨文件使用了同一 ID，所以依样对前面的文件进行了处理。如果需要的话我可以提供一个对应表，这样可以写一个模块来 merge 用户的数据。不过知道了 ID 的用途的话，好像和我的排序就有些冲突，不能中间插入新的项目了。
2. 是指 GitHub 的 diff 已经废了，所以不能具体地显示出我修改了哪些行。
3. 我无所谓吧，要建后台感觉代码量比较大。而且本项目应该追求准确的数据，最好还是人工审核。比如把现在的提交问题功能直接改为页面上的 form，然后用个 bot 自动 po 到 GitHub 的 issue 页面就行。

[wxt2005]

1. ID 的问题，倒也没必要这么麻烦，因为 merge 的问题只在当季度才存在，下个季度就会用新的 ID 了。所以我明天抓个时间点发布下就行。
2. 反馈用 bot 是个好想法，记下了。

[weizhenye]

数据格式最好不要轻易变，有不少插件和项目都是基于 bgmlist 数据的。
然而我个人还是希望能用新的数据格式。目前跨季番组在不同季度都要复制一遍，信息冗余，且不易维护。一些想法：

1. 是个数组。
2. BGM ID 作为唯一标识。
3. 所有数据都写到一个 JSON 文件中，方便人工维护。
4. 所有番组确保含有 showDate 字段，完结番组确保含有 endDate 字段，长篇未知的可设为 null 之类的，方便识别季度。
5. 为兼容目前数据，可以加个构建过程，json/bangumi-*.json 文件只由新格式数据转化得到。
6. 其他需扩展的字段待议。

[yume-chan]

@weizhenye

1. 我看到 V2，第一个想法就是直接用 BGM.tv ID 做标识。
   但是实际上有的项目是没有 BGM.tv ID 的，我在处理过程中遇到了。在 BGM.tv 搜索，也确实没有对应条目。
2. 全部写进一个 JSON，太大，不太合理。除非 API 由服务器脚本处理，而不是现在这样返回静态文件。

[weizhenye]

@CnSimonChan
无 BGM ID 的应该只有个位数吧，可以整理出来，到 BGM 添加就好了。
写到一个文件里只是面向人工，为了方便维护，在生产环境当然是要 filter 后的精简数据，这个包含在构建过程里了。

[wxt2005]

@weizhenye 这个文件大了之后要人工维护也是挺累的。如果要做数据统一，个人还是倾向有个 API 服务器，而不是现在这种静态文件的形式。但是这样大家一起维护的难度就增加了。

[weizhenye]

@wxt2005 我觉得对于 JSON 文件，100 行和 1000 行没什么区别，反正找内容肯定是 Ctrl+F。做成 API 服务器的话，增删查改的页面、操作的权限，一大堆事情要做。数据库的好处就是它提供了对数据的操作方法，而如果我们把 JSON 静态文件当作简陋的数据库，我们可以写脚本提供必要的方法，比如 filter 出某一季度的番组，把人工维护时可以自动化的都自动化，本质上一样的。

[wxt2005]

@weizhenye 行数多了用 Atom 会卡（笑）
类似 LeanCloud 这种云储存的方案呢？应该可以省去不少工夫。
如果还是沿用人工维护 json 的方式的话，把数据和前端分开成两个单独的 repository 是不是会比较好？

[wxt2005]

这个串不要回复了，到时候就合并了。移步到 #39 吧