【问题标题】:Application chat character limits?应用聊天字数限制?
【发布时间】:2016-10-04 13:48:03
【问题描述】:

我正在构建一个MEAN Web 应用程序,我希望不久之后可以在开放的互联网上部署它。此应用程序的一部分包括由WebSockets 支持的出色Primus 抽象层支持的聊天功能。当我编写聊天模块时,我想到了是否对这些消息施加字符限制的问题。

我的结论是,有一些限制可能很好,但我不知道如何去决定应该是什么限制。它应该完全取决于我的服务器的强大吗?我应该选择一些合理的限制吗?究竟什么是被认为是合理的限制,为什么?

Google 和 Facebook 等网络巨头如何决定其应用程序的聊天字符数限制?是否有人只是说“嗯,这似乎很合理”,仅此而已?

一些额外的 Google 搜索出现了一些东西,例如 this question about Jabber chat limits、A request to increase the chat character limit in the Blade and Soul MMOthis comment about Twitch chat character limits,但我似乎无法找到 任何东西来表明典型的聊天字符限制适用于基于 Web 的应用程序,或者为什么它们首先受到限制。

我知道在过去,我自己和我认识的其他人在某些聊天应用程序上达到了看似不必要的短字符限制。这可能会成为一个主要的烦恼,尤其是在尝试复制和粘贴大量信息时。我想避免给我的用户带来这种烦恼,同时仍然保护服务器和带宽的完整性,请记住,某些用户可能会在网络使用限制等情况下使用该应用程序。

编辑

我正在开发的应用程序是一款游戏,但有时会涉及玩家之间的一些重要外交和战略讨论。为该用例提供具体建议会很有帮助,但显然有一些基本原则来指导各种应用程序的聊天限制会更有帮助。

【问题讨论】:

    标签: javascript node.js web-applications chat mean-stack


    【解决方案1】:

    我得出的结论是,有一些限制可能很好,但我没有 想法如何去决定那个限制应该是什么。应该是 完全取决于我的服务器的强大程度?我应该选择 一些合理的限制?究竟什么才是合理的限制, 为什么?

    对事情保持限制是好的,应该这样做的原因可以分解成很多部分。当我依次回答您的问题时,我将分点并逐步解释这一点。

    Google 和 Facebook 等网络巨头如何决定聊天内容 字符数限制应该针对他们的应用吗?有人只是 说“嗯,这似乎很合理”,就这样?

    Facebook 和 Google 不会在没有经过深思熟虑的情况下做出决定。首先,当你开始做某件事时,项目的主要因素是可行性,当然这些事情对于 Facebook 和谷歌这样的巨头来说就他们可用的资源而言并不重要,但他们也会确保在滥用的情况下存在限制系统。

    应该关注的因素

    1. 可行性 - 您必须考虑可供您使用的资源的可用性。由于您实际上并不知道用户群规模是多少,因此我建议您预测您的用户群的实际情况以及您实际可以处理多少数据,以便您不要妨碍效率和用户体验,例如,系统的响应时间必须很好,因为您使用的是实时系统。当您使用基于服务器端的直接对等连接时,请查看影响内存消耗的因素,服务器端充当通信的中间点,它肯定会利用您的 CPU 内存。

    2. 用户体验 - 你的实际用例是什么,专注于它,在最初的决定之后,你不能永远坐在它上面。谷歌等有很多活动的论坛,他们会根据反馈改变他们的系统并引入新功能,这就是现实世界中事情的运作方式。当系统投入现实世界时,必须根据用户的选择进行更改。对用户在您的案例中的实际需求进行简单研究,这可能有助于您做出决定。

    3. 限制滥用系统 - 假设您有著名的聊天应用程序,但不知何故,您忘记对任何内容进行任何限制,现在某个臭名昭著的家伙刚刚创建了一个系统来通过机器人滥用您的应用程序系统。现在,他可以在每笔交易中发布 10k 条消息,每条消息中有 n 个字母,并且在某个时间点您的系统会崩溃。因此,请记住这一点,并确保您注意证券和垃圾邮件检测。

    结论:主要是你的用例,然后是可行性,两者必须齐头并进。用户想要什么以及您可以为他们提供什么是主要的决定线。采取预防措施并制定标记系统个性的规则。

    更新:让我们举两个例子

    1. Twitter 发布了一篇博文,称他们正在测试增加了字符限制的产品版本。有N多人提出了同样的关注,为什么? (查看文章)由于人们不希望独特的体验结束,许多人认为 Twitter 不是用来分享文章的,这就是为什么需要时间来达到平衡的原因。

    2. 在 cmets 的情况下,堆栈溢出对字符的限制,为什么?限制的目的是因为他们不希望您在 cmets 中粘贴文章和答案。然后还有最小字符的限制以减少垃圾邮件。

    更新只是为了在我给出的理论和实际应用之间架起一座桥梁。

    【讨论】:

    • 很高兴看到一些来自大牌的官方材料,但你提出了一些很好的观点供考虑。谢谢!
    • 我最后写的都是从网上发表的很多文章的节选中摘录的在我的大学课程期间以及之后的职业生涯中进行管理和用例。
    【解决方案2】:

    这实际上取决于聊天的用例。我的意思是,如果您的用户应该保持他们的消息简短(例如 Twitter 或其他),那么您应该将其缩短,例如 150、250 或类似的内容。

    如果您的用户要讨论内容,那么您将需要更多的字符,例如 5000 个以上的病房。

    【讨论】:

    • 您抛出 5000 用于讨论,但这样做的理由是什么? 5000 听起来是不是一个不错的最小值?还是背后真的有统计数据?
    • 这实际上没有统计上的原因,我只是认为如果您想进行适当的对话(而不是像每 3 个字一样点击发送),那么您需要一个适当的字符限制。如果你相信以下 2015 年的文章,facebook 甚至有 20,000 的限制:cnet.com/news/…
    【解决方案3】:

    限制标准

    嗯,有一个标准(我不记得名字,我会搜索它)说电子邮件的字符限制是 50、64 或 72(我推荐第一个),对于名称的限制是 96;对于一条消息,它取决于它可能是 256、512 甚至 625。谷歌两年前发布了一份关于设计的清单,其中说明了这一点。我在我的own website 中使用这个标准,我有一个聊天应用程序。

    合理的限度

    回到您的问题,“合理限制”取决于您应用的上下文。想一想:它是干什么用的?用户将发送什么样的消息?是否需要写他/她的电子邮件?一种疯狂的方法可能是消除限制,并在分析工具的帮助下查看输入的平均长度。希望对您有所帮助。

    【讨论】:

    • 有你提到的标准和谷歌出版物的参考/链接会很好。
    • 是的,我会搜索它。
    猜你喜欢
    • 2012-08-11
    • 2020-08-13
    • 1970-01-01
    • 1970-01-01
    • 2019-11-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2021-07-27
    相关资源
    最近更新 更多