불쾌감을주는 콘텐츠를 GitHub에 업로드 할 수 있습니까? [닫은]

내 웹 사이트에 대한 불쾌감을주는 콘텐츠 검사기를 개발하여 GitHub 에 게시하려고합니다 . 그러나 소스 코드에는 공격적이고 인종 차별적이며 불쾌한 콘텐츠가 많이 포함되어 있습니다.

소스는 완전히 문서화되어 있지만 GitHub에 그러한 작업을 게시 할 수 있는지 또는 독자의 상상력에 따라 문자열 배열을 남겨 둘지 여부에 대한 귀하의 의견을 원했습니다!

ROT-13 솔루션에 동의하지 않습니다. 금지 된 단어를 보는 것이 난처 해 보이는 것은 누군가를 화나게 할 수 있기 때문에 시간 낭비입니다.

나쁜 단어 / 나쁜 단어 규칙의 사전은 어쨌든 별도의 파일에서 가져와야합니다 (런타임에로드되거나 리소스로 포함될 수 있음) . 이 파일을 난독 처리하면 사용자 / 다른 개발자 / 사용자가 파일을 변경하거나 문제를 해결하기가 더 어려워집니다. 또한 하드 드라이브에서 "banned_words.txt"라는 파일을 보면 불쾌감을주는 단어 목록이 포함될 것으로 예상 됩니다.

"컴퓨터 과학의 모든 문제는 다른 수준의 간접 지시로 해결할 수 있습니다." ( David Wheeler에 의해 ).

독자를 방해하지 않도록 컨텐츠 를 인코딩 할 수있는 옵션을 고려할 경우 선택 사항은 업로드 여부에 국한 되지 않습니다.

• 예를 들어, 단순히로 이동 다음 글자 유명한 네 편지 설정할 수 있습니다 (완전 인코딩 A를 이동 Z와 등 B, C에 B에 A) 단어를 완전히 무해한로 Gvdl . 응용 프로그램에서 사용해야 할 것은 A를 Z로 이동 하고 반대 방향으로 이전 문자로 다시 이동하는 것입니다.

코멘트에서 지적했듯이 , 위와 같은 접근 방식은 ROT13 문자 대체 암호 에 사용되며, " 캐주얼 한 시각에서 공격적인 재료 를 숨기는 수단으로 ..."

완전한 인코딩 을 위해 선택한 인코딩이 실수로 한 단어를 다른 단어로 바꾸지 않도록 인코딩 된 사전 에 대해 검사기를 추가로 실행 하는 것이 좋습니다.

_{그런 것들을 인코딩 할 때, 확실하게 예측할 수 없기 때문에 이중 확인하는 것이 좋습니다. 지난 프로젝트 중 하나에서 잘못 구성된 체커가 임의의 문자 순서로 불쾌한 내용을 발견하기 시작했을 때 ( ZIP 아카이브 의 uuencoded 내용 에서) 메일이 상당히 중단되었습니다 .}

일반 텍스트, Gvdl 을 전달하는 것과 비교하여 인코딩은 법적 문제와 관련된 모든 위험과 종속성 을 완전히 피할 수있는 실질적인 이점이 있습니다.

그냥 생각 해봐 특정 리포지토리의 특정 서비스 약관에 따라 내 콘텐츠를 사용할 수 있습니다.

그러나 TOS 를 변경하기로 결정하면 어떻게됩니까? 또는 용어가 호환되지 않는 다른 저장소로 변경하기로 결정한 경우 어떻게해야합니까? 내가 뭘 할까?

그런데 지금도 "친숙한"저장소에 있어도 여전히 안전하지는 않습니다.

이상한 웹 필터로 인해 누군가 내 콘텐츠를 다운로드 할 수 없으면 어떻게합니까? 사용자 불만에 응답하고 필터를 수정하는 방법을 설명해 드리겠습니다. 그들의 필터 ...

... 인코딩에 대해 결정하기 전에 두 번 생각하는 것이 좋습니다. 그리고 내가 결정하더라도, 나는 그것에 대해 아주, 아주 좋은 이유 가 있는지 확인 합니다.