Có thể chấp nhận tải lên nội dung gây khó chịu lên GitHub không? [đóng cửa]

Tôi đã phát triển một trình kiểm tra nội dung gây khó chịu cho trang web của mình và muốn xuất bản nó trên GitHub . Tuy nhiên, mã nguồn chứa nhiều nội dung gây khó chịu, phân biệt chủng tộc và mặt khác.

Nguồn này được ghi lại đầy đủ, nhưng tôi muốn ý kiến ​​của bạn về việc có thể chấp nhận xuất bản tác phẩm như vậy trên GitHub hay không để lại chuỗi các chuỗi theo trí tưởng tượng của người đọc?!

Tôi phải không đồng ý với giải pháp ROT-13. Làm xáo trộn những từ bị cấm của bạn chỉ đơn giản vì việc nhìn thấy chúng có thể xúc phạm ai đó là một sự lãng phí thời gian.

Từ điển của bạn về các từ xấu / quy tắc từ xấu phải xuất phát từ một tệp riêng biệt (có thể được tải trong thời gian chạy hoặc được nhúng dưới dạng tài nguyên) . Việc che giấu tập tin này chỉ đơn giản là làm cho bạn / các nhà phát triển khác / người dùng của bạn gặp khó khăn hơn trong việc thay đổi nó hoặc khắc phục bất kỳ vấn đề nào. Ngoài ra, nếu tôi thấy một tệp có tên "cấm_words.txt" trên ổ cứng của mình, tôi sẽ mong đợi nó chứa một danh sách các từ gây khó chịu.

"Tất cả các vấn đề trong khoa học máy tính có thể được giải quyết bằng một mức độ gián tiếp khác." ( của David Wheeler ).

Tùy chọn của bạn không bị giới hạn trong việc tải lên hay không, nếu bạn tính đến việc bạn có thể mã hóa nội dung để nó không làm phiền độc giả.

• Như một ví dụ, chỉ cần chuyển sang các chữ cái tiếp theo (A đến B, B đến C, vv với Z chuyển sang A đến mã hóa đầy đủ) có thể biến bốn chữ cái nổi tiếng từ vào hoàn toàn vô hại Gvdl . Tất cả những gì bạn cần để sử dụng nó trong ứng dụng của bạn sẽ là chuyển nó trở lại theo hướng ngược lại, với các chữ cái trước đó , với A chuyển sang Z.

Như đã chỉ ra trong các bình luận , một cách tiếp cận như trên được sử dụng trong mật mã thay thế chữ ROT13 , được biết đến với công dụng "như một phương tiện để che giấu ... các tài liệu gây khó chịu từ cái nhìn thoáng qua ..."

Để hoàn thiện, hãy xem xét thêm việc chạy trình kiểm tra của bạn dựa vào từ điển được mã hóa , để đảm bảo rằng mã hóa được chọn không vô tình biến một từ gây khó chịu thành một từ khác.

_{Khi mã hóa những thứ như vậy, sẽ rất hợp lý khi kiểm tra lại, bởi vì người ta không thể dự đoán được mọi thứ một cách đáng tin cậy. Trong một trong những dự án trước đây của tôi, chúng tôi đã bị mất thư khá nghiêm trọng khi một người kiểm tra bị định cấu hình sai bắt đầu phát hiện ra nội dung gây khó chịu trong các chuỗi ký tự ngẫu nhiên (trong nội dung uuencoding của kho lưu trữ ZIP).}

So với việc chuyển xung quanh văn bản thuần túy, Gvdl , mã hóa có một lợi ích đáng kể là tránh hoàn toàn các vấn đề pháp lý và tất cả các rủi ro và phụ thuộc liên quan .

Chỉ cần nghĩ về nó. Nói, điều khoản dịch vụ cụ thể tại một kho lưu trữ cụ thể cho phép nội dung của tôi, tốt.

Nhưng, nếu họ quyết định thay đổi ĐKDV thì sao? Hoặc, nếu tôi quyết định thay đổi sang kho lưu trữ khác, có các điều khoản không tương thích. Tôi sẽ làm gì đây?

Lưu ý bằng cách ngay cả khi ở kho lưu trữ "thân thiện", ở đây và bây giờ, vẫn không hoàn toàn an toàn.

Điều gì xảy ra nếu ai đó sẽ không thể tải xuống nội dung của tôi vì bộ lọc web kỳ lạ ? Tôi có sẵn sàng trả lời các khiếu nại của người dùng và giải thích cách khắc phục bộ lọc không? Bộ lọc của họ ...

... Bạn thấy đấy, tôi thà suy nghĩ kỹ trước khi quyết định chống lại tiền mã hóa. Và ngay cả khi tôi quyết định, tôi sẽ đảm bảo rằng tôi có một lý do rất, rất tốt cho việc đó.