P.S。 db是通过最佳实践PDO所以没有sql注入的风险
由于
答案 0 :(得分：25)
好的，我们假设您正在完成所有字符串编码任务。您没有任何SQL注入，HTML注入，或者您不应该使用URL编码的地方。所以我们不需要担心像“＆lt;＆amp;％\”这样的字符在某些情况下会变得神奇。而且你使用UTF-8来处理所有内容，因此所有的Unicode都在运行。还有其他什么原因来限制用户名？
首先，所有控制角色，为了理智。没有理由在用户名中包含字符U + 0000到U + 001F或U + 007F到U + 009F。
接下来，拒绝或规范化意外的空格。您可能希望在用户名中允许空格，但您几乎肯定不希望允许前导空格，尾随空格或行中的多个空格。它们可能在HTML中呈现相同的内容，但可能会出现混淆的用户错误。
如果您打算允许使用该用户名通过HTTP基本身份验证登录，则必须禁止使用:字符，因为基本身份验证方案会对“用户名：密码”对进行编码，如果存在，则不会进行转义冒号用户名或密码。因此，用户名和密码中的至少一个必须排除冒号，并且最好是用户名，因为限制人们选择密码比用户名更糟糕。
对于基本身份验证，您可能还需要禁用所有非ASCII字符，因为不同的浏览器会对它们进行不同的处理。 IE使用系统代码页对它们进行编码; Firefox使用ISO-8859-1对它们进行编码; Opera使用UTF-8对它们进行编码。如果HTTP Auth将可用，则在选择非ASCII名称之前至少应该警告用户，因为实际使用它们将非常不可靠。
接下来考虑其他Unicode控制序列，例如bidi覆盖和其中列出的其他字符不适合用于标记。可能你最终会将它们放入标记中，并且你不希望名字中有RLO的人向后翻转你页面中文本的负载。
此外，如果您允许Unicode对您获得的字符串进行规范化。否则，某人可能拥有一个包含o-umlaut字符ö的用户名，并想知道为什么他们无法登录Mac，默认情况下会使用单独的o字符，然后组合umlaut。通常在网络上标准化为组合形式NFC。您可能还希望使用NFKC格式进行兼容性分解;这将允许用户Chris以全长romaji模式从日语键盘登录，输入Chris。这些是一般性问题，对于您的所有webapp输入都是很好的解决方案，但是对于像用户名这样的标识符来说，正确起来可能更为重要。
最后，确保长度可以适合数据库，而不会更改名称的静默截断，尤其是当您要存储为UTF-8字节时，您不希望在字节序列的中途进行剪切。用户名截断通常也是一个安全问题。
如果您使用用户名作为一种独特的身份识别方式，您还有更多需要担心的问题：已经提到的类似问题，例如Сhris（带有西里尔文Es С）。有太多这些让你合理处理;限制为ASCII或具有识别用户的其他方法。 （或者不在乎，就像SO没有;当我可以很容易地称自己为Chris时，我无需自称С - hris。）
答案 1 :(得分：5)
取决于很多事情，例如，如果用户要拥有自己的URL，您要小心创建用户名“％41llan”的人不会与名为“Allan”的用户发生冲突，而允许正斜杠可能会导致问题。留意那些限制。
答案 2 :(得分：4)
我从来没有看到过对用户名添加限制的重点。如果您的代码抵抗sql注入攻击，那么让他们放入他们想要的任何东西。
我添加的唯一限制是最大长度为1，以便可以存储在数据库表中
让他们在用户名中使用任何Unicode字符。 对允许的字符添加限制可能只会让使用非ascii语言的人烦恼。
答案 3 :(得分：2)
SQL注入保护是必须的，但这应该在您的代码中，而不是在用户名限制中。某些字符肯定应该被转义，例如\，％等。
它将在你正在运行的网站上，但我认为一些淫秽的字词限制会使你的网站看起来更专业，无论如何。如果有人看到允许人们使用“EXPLETIVE”，因为他们是用户名，那么您的网站看起来会很幼稚。这就像允许青少年在你的书店恕我直言中猖獗。你可能不需要比那更挑剔，尽管它完全取决于你。
这稍微偏离主题，但作为另一个用户名建议，任何网站的一个很棒的功能是允许用户随着时间的推移更改他们的用户名。你可以将一个数字作为主键，并允许他们这样做可以节省很多抱怨和人们创建新帐户，因为他们想要更改他们的用户名。 ：d