我为我的网站开发了一个令人反感的内容检查器,并希望将其发布在GitHub上。但是,源代码包含许多令人反感,种族主义和其他令人讨厌的内容。
来源已被完全记录下来,但是我希望您对是否可以在GitHub上发布这样的作品还是是否让字符串的排列留给读者的想象力表示意见?
我为我的网站开发了一个令人反感的内容检查器,并希望将其发布在GitHub上。但是,源代码包含许多令人反感,种族主义和其他令人讨厌的内容。
来源已被完全记录下来,但是我希望您对是否可以在GitHub上发布这样的作品还是是否让字符串的排列留给读者的想象力表示意见?
Answers:
我不得不不同意ROT-13解决方案。仅仅因为看到它们可能会冒犯某人而使您的单词模糊,这是浪费时间。
无论如何,您的不良词/不良词规则字典应该来自单独的文件(可以在运行时加载,也可以作为资源嵌入)。混淆该文件只会使您/其他开发人员/您的用户更难以更改或解决任何问题。此外,如果我看到一个叫我的硬盘驱动器上的“banned_words.txt”的文件,我会想到它包含的进攻单词的列表。
“计算机科学中的所有问题都可以通过另一层间接解决。” (作者: David Wheeler)。
如果您考虑到可以对内容进行编码,以免打扰读者,那么您的选择不仅限于上传还是不上传。
正如评论中指出的那样,在ROT13字母替换密码中使用了类似上述的方法,该方法以“作为隐藏... 令人反感的攻击性材料的方式...”而闻名。
为了完整起见,请考虑对编码字典另外运行检查程序,以确保选择的编码不会意外地将一个令人讨厌的单词变成另一个。
在对此类内容进行编码时,应仔细检查,因为无法可靠地预测事物。在我过去的一个项目中,当配置错误的检查程序开始以随机字符序列(在ZIP档案的uuencoded内容中)发现令人反感的内容时,我们发生了相当严重的邮件中断。
与传递纯文本Gvdl相比,编码具有充分的好处,可以完全避免法律问题以及所有涉及的风险和依赖性。
试想一下。说,特定存储库中的特定服务条款可以使我的内容正常。
但是,如果他们决定更改TOS怎么办?或者,如果我决定更改条款不兼容的另一个存储库,该怎么办?我该怎么办?
顺便说一句,即使在此时此刻,即使处于“友好”存储库中,也仍然不是完全安全的。
如果有人由于奇怪的Web过滤器而无法下载我的内容怎么办?我是否愿意回应用户的抱怨并解释如何修复过滤器?他们的过滤器...
...您知道,在决定拒绝编码之前,我宁愿三思而后行。即使我决定,也要确保我有一个非常非常好的理由。