支持演员艺名固定（演员多个艺名时均使用同一艺名处理）

参考了之前另一位的 PR，不知道为何最终阵亡了：#181

使用一个 json 文件保存演员的艺名，针对数据集来源，我大概查看了几个网站，最后感觉可能只有 javdb 提供的信息比较合适，所以额外写了个函数从 javdb 来爬取并保存。

目前有以下问题可能需要进一步考虑：

数据的未来维护：个人认为可以考虑项目定期爬取更新与用户自定义相结合。实际使用中感觉容易存在别名冲突的主要就是枫哥、有腿那些改了名的较出名演员，有必要维护的也就那么些，可以项目自行爬取各类目下演员的前10页（约等于 Top500），提供的数据基本就能覆盖大多数用户需求了。实在没覆盖到的（小众 xp），用户自行编辑文件加入个别的演员也不是很费劲，毕竟个人理解这个功能主要就是为了解决“同一演员：放在了不同文件夹/在多媒体系统中识别为不同人/不便检索”类似的问题，完全可以由用户自行在检视结果时根据需要来修改。
json 文件位置：我在代码中是放在了 data 文件夹下，在源码运行时没关系，但是打包为 exe 后用户就无法自行编辑了，考虑类似 config.ini 那样处理或者直接作为外置文件放在 exe 同目录下来读取和编辑。
数据爬取功能支持：目前只是写了爬虫函数，没有将其暴露给用户，我个人是通过直接运行 javdb.py 来爬的。需要考虑是否将这个功能提供给用户，目前有 2 种想法：(a)提供一个新的配置项，由用户选择是否需要在刮削时对每部影片的演员进行一次艺名查询（即边刮边更新），这样能保证人人有数据，但是增加了不少网络压力；(b)新增一个运行模式（同样还是根据配置项判断），该模式专门运行艺名爬虫，这样的话可能就有必要进一步丰富一下爬虫函数的参数，比如从第几页开始爬取什么的。
数据更新：这个功能支持用户自己设定固定使用哪个艺名，使得 json 文件有用户自定义配置的意义，这就导致不能通过直接覆盖来更新数据，可能需要额外写一个函数来实现 json 的无损更新。

其实感觉可以将爬虫和 json 文件这部分分离出来，新增一个项目或分支专门放置爬虫程序和 json 文件更新函数（如果会写）和最新爬取的 json 数据。原项目仅提供读取并根据 json 文件来在保存信息时固定艺名的功能（目前加入的代码效果基本就是这样子，只是 json 文件保存位置应该需要进一步考虑）。

感谢PR。我去年底其实就有梳理过一些思路，但是最近工作挺累一直没有付诸实现，也还有一些问题没想好怎么处理。以下是之前的思路，希望能在讨论中得到完善。

JavLibrary的演员名鉴页面会按照罗马拼法的首字母显示演员的名称，通过切换语言可以获得同一演员的简中、繁中、英文、日文名。需要记录下演员的ID javdb记录了丰富的演员别名，但是默认显示的名字通常不是常用名。可以在演员详情页面，看到演员出现的影片。按照【看过人数+单体作品】排序，取第一部影片，在JavLibrary中进行搜索，以此通过影片将演员关联起来。

JavLibrary有一些问题，发现存在从女优页面看作品列表为空实际有作品的情况（SAI-005）相应地，只能从javdb演员页面获取影片信息，然后去javlib找，而不能反过来 Javlib页面要选择【所有的影片】，而不是默认的【有评论的影片】
javdb中演员页面每次最多只显示30页，31页及以后都是重复第30页的数据。需要通过筛选功能（如年龄），控制每次返回的演员数量无码演员无法筛选，只能获得前30页
如果javdb中没有单体影片？先解析所有有单体影片的演员，然后对于那些没有单体影片的演员，选一部非合集/N时间类的作品（这样演员少一些）进行解析，可能参演演员中其他人都是能够确定的，从而确定演员关联。如果还是没法确定的，由后续人工介入处理
如果遇到javdb没有作品的女优？记录下来后续处理
如何处理同一女优以相同或者不同的名字出演有码和无码视为同一女优，并且统一使用相同的名字使用csv组织演员别名以便修改，javdb和JavLib的演员ID各一列，为每个语言(zh_CN, zh_TW, JP, EN)分别提供一列，封面图片URL一列，并在最后一列提供以中英文逗号分隔的、除了英文名以外的演员的所有别名

即使如此可能获得的也不是常用名，比如【田中檸檬, 田中レモン, 楓カレン, 楓花戀, 枫花恋】，现在她用的是田中的名字，但是更广为人知的是枫花恋。可以以Google Trend输入一个词时，它返回的提示词作为（当前浏览器语言下）别名接受度的标准。以【枫花恋】为例，输入她的几个别名，返回的行业提示都是【枫花恋】

在仓库内保存两个文件，一个是直接扫描得到的，一个是扫描后人工校对差异项手动修改的

关于数据更新，我倾向于由开发者进行维护，预计另开一个仓，同时接收PR更新，以减小对源站点的请求压力。另开一个仓的话，相应数据也更容易被其他有需要的项目（如果有）所使用

之前的PR被关闭主要是并没有预置一个足够的数据集，我认为这种状态很难称得上对用户可用。此外，我比较倾向于最终使用csv格式管理数据，因为在Windows系统上csv容易借助Excel进行方便的编辑，方便用户自己添加整理数据，而不需要用户学习json格式。

按照您的思路，如此实现下来确实工作量相当庞大，就数据爬取方面而言预计也会相当耗时。首先，我主要就功能定位大概有如下观点：

功能支持优先于数据支持：目前项目在没有别名设置的支持下，经常会出现同演员不同名等情况，不便于 Emby、Jellyfin 等媒体库的使用（典型场景就是通过一个电影的演员查询，仅能查到该演员同名的作品，而对以其他别名保存的作品则没有办法）。
- 加剧了这一问题的另一个情况是，同一演员在不同网站上可能被标记为了不同的名称，例如有的网站默认使用翻译名，有的则使用原名（与网站的语言设置有关）。由于刮削结果最终可能来源于不同网站，最终整合的结果出现同人不同名的概率相对较高。
- 而提供别名固定功能，我认为其首要价值在于支持用户自行根据使用的实际情况进行设置，至于相关数据的提供和维护则优先级相对较低。
- 一方面，提供一个相当【庞大】（此处单纯考虑演员数量）的数据库，在我看来可能超出了本项目的【工具】范畴。另一方面，我倾向于认为大部分用户的需求是前 30 页的演员列表就能基本覆盖的，超出此范畴的演员，其热度和活跃度可能都处在一个较低的水平，秉持着对大众审美（尤其是使用本工具的用户群体的审美）的信任，我认为即使要提供足够的基础数据，30 页的量也完全够了。
- 同时，相对于开发一个完善而耗时间久的功能，尽快提供一个简单但够用的功能可能更加符合用户（我）的需求。即别名固定功能首先在于【提高下限】，其次才是【提高上限】。

以上基本是我个人对功能定位的理解，接下来是我对具体实现思路的建议（可能涉及到代码实现的地方均是考虑使用 json 和字典的情况）：

对演员译名与原名区分的支持：我个人理解引入 javlib 主要目的是维护演员的多语言译名（#96）。实际上，javdb 在中文选择时已经同时就现用名提供了中文译名、原名的信息（我提交的刮削函数中有对此进行简单处理）。考虑项目主要用户群，除原名外，简繁体名称仅提供一个即可（通常为繁体），英文名则是除了发音外在辨识度和姓名含义上均无意义（或许甚至像片假名拼单词一样值得唾弃），个人认为暂时没必要刻意维护。因此，目前根据 javdb 的数据，其实已经完全可以满足相关需求，或许不必要也不值得去为此进一步实现与 javlib 的联动。
演员常用名维护：我个人认为没有必要刻意选择演员常用名进行维护。
- 常用名和现用名的实际冲突可能在于社交媒体上的观众大部分保持常用名称呼而非现用名称呼，这通常由于某位较著名演员进行了改名，而这种情况实际上较少，且困扰可能仅仅是在对女优进行辨识时（实际上一般不会有困扰）。也就是说，从用户需求来考虑，大部分用户（我）实际需要的其实只是演员名称的统一而非一定要在此基础上使用常用名，即使有此需求，可以预见涉及的女优也相对较少，是可以由用户或项目自行设置维护的。
- 即，追求使用代码确定演员常用名可能较为【吃力不讨好】。
- 借助 GoogleTranslate 来确定常用名真是个令人（我）赞叹的想法，但是适用于这种情况的可能只有热门演员。实际情况可能是：热门演员改名罕见，改名影响小（把马甲穿上照样认识你），可以人工解决；非热门演员改名影响无所谓（甚至一些演员打一炮换一个位置），可以不解决。
数据格式：我认为 json 或是 csv 均可，个人则更倾向于 json。
- json 可以直接像我目前提交的方案一样直接使用字典，在结构和阅读上都相对直观。
- json 在 Windows 上使用记事本也就可以编辑，而其结构本身也是具有极强的规律性的，对理解和编辑不太会有什么困难。
- 实际需要的编辑无非是【搜索】后对已有演员项进行修改，对没有演员项进行添加（在队首即可），至于 Excel 独有的一些功能（如排序、筛选）就数据本身应用场景（依然是作为字典）并没什么使用的必要。
- 考虑本项目所处位置（Github），我认为使用 json 对用户并不会有很大的学习成本（倒不如说这点困难都克服不了的话最好还是不要 ghs 了）。
- 相比 csv，自认为 json 要更加 elegant 一些。实际上二者应该并不是一个明显优于另一个的情况，也不需要把用户看得太过于傻瓜。同时，两种格式的在线互转在搜索引擎上也是唾手可得。
另建仓库：赞同另建仓库以维护数据，至于数据的维护，我认为不是特别需要提供两个版本的数据，而是提供一个相对来说较为正确的数据即可【如人工校对发现的不同名上下马的同一演员】，常用名这种设置则是可能存在较强的个人主观喜好因素，需要斟酌。
- 同时就需要提供数据的无损合并脚本（避免直接替换文件而覆盖掉用户自定义设置，实际效果就是保持 key 不变，仅修改 value）
- 考虑出现演员改名（现用名变更）的情况，在爬取维护时需要能对上号。
- 也就是不能仅仅依靠 key 来判断是否是同一个人。但或许可以通过倒数第 1 个别名来判断？
- 或者爬取时记录新增演员，人工进行核对，如果固定只爬前 30 页的话每次增加的演员可能不会太多。
- 应当需要提供【默认原名】和【默认译名】两个版本，除了固定值（key）是否被翻译以外在内容上没有任何区别。

以上是个人目前的全部想法，核心观点其实就是将功能支持与数据提供分离，先把功能做了，至于数据可以另行考虑甚至另起项目维护。

另外，满足所有用户的长期需求可能是困难甚至不现实的（从您的设计思路来看，应该是尽可能地考虑了各种情况和潜在用户需要来设计），（就本项目而言）在实际进行功能设计时或许还是以能够满足大部分用户的目前可见需要为主，在考虑未来可扩展性的前提下进行小增量迭代设计与开发，“一步到位”可能并不是特别适合这种还在不断发展完善的长期维护开源项目。

先提供基本功能再考虑完善这点您说得很有道理，有理有据，令人信服~不过数据格式这点我还是比较坚持采用csv。诚然github上很多用户是有技术背景的，编辑json并无困难，但有很多用户虽然拥有github账号可能只是用来提issue。csv的编辑门槛要低很多。

Yuukiy / JavSP

支持演员艺名固定（演员多个艺名时均使用同一艺名处理） #228