preg_replace 密码过滤器
对于 PHP，我想对密码使用 preg_replace() 过滤器，这样密码可用的唯一字符是 US ASCII 可输入字符、减号控制代码和 NULL。
可以插入到 preg_replace() 中的正则表达式是什么？
编辑：
自从我现在“明白”以来，我就被建议编辑这个问题，并且不会做这种非常不受欢迎的技术，并且将允许任何可输入的字符，甚至是我键盘上可能没有的字符，只要它们不是控制代码。
With PHP, I'd like to use a preg_replace() filter for passwords such that the only characters available for passwords are US ASCII typable, minus control codes and NULL.
What's the RegEx to achieve that which I can plugin to preg_replace()?
EDIT:
I've been advised to edit this question since I "get it" now and won't be doing this terribly unpopular technique and will permit any typable character even ones I might not have on my keyboard, just as long as they aren't control codes.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
正如其他人所说，不要限制密码中允许的字符集。 仅仅因为您的键盘上没有 ä、å 或 ö，就没有理由阻止我们这些拥有这些字母（或无论如何知道如何键入它们）的人使用这些字母。 无论如何，您都会将密码存储为加密哈希（或至少作为加密字符串），不是吗？ 如果是这样，那么您的数据库是否可以成功/安全地存储密码中的实际字符并不重要，只有加密算法输出的字符才重要。 （如果不是，那么以明文形式存储密码是一个比密码可能包含或不包含哪些字符要大得多的问题 - 不要这样做！）
您明显想要通过以下方式强制执行字符集限制：默默地删除您不喜欢的字符，而不是告诉用户“再试一次，这次只使用这些字符：a、e、i、o、u”。 使你提出的方法真正残暴，因为这意味着如果我尝试使用密码
fäîry（不是非常安全，但应该能够抵御轻量级字典攻击），我的实际密码将不为人所知我，将被fry（如果您的密码是一个三个字母的单词，直接从字典中取出并且常用，您可能甚至不必打扰）。 哎哟!As others have said, don't restrict the set of characters that are allowed in passwords. Just because your keyboard doesn't have ä, å, or ö on it is no reason to stop those of us who do have them (or know how to type them anyhow) from using those letters. You're going to be storing the password as a cryptographic hash anyhow (or at least as an encrypted string), aren't you? If so, then it doesn't matter whether your database can successfully/safely store the actual characters in the password anyhow, only the characters output by your crypto algorithm. (And if not, then storing passwords in plaintext is a far bigger problem than what characters the passwords may or may not contain - don't do that!)
Your apparent intent to enforce your character set restrictions by silently stripping the characters you dislike rather than by telling the user "Try again and, this time, only use these characters: a, e, i, o, u." makes your proposed method truly atrocious, as it means that if I attempt to use, say, the password
fäîry(not incredibly secure, but should hold up against lightweight dictionary attacks), my actual password, unknown to me, will befry(if your password is a three-letter word, straight out of the dictionary and in common use, you may as well not even bother). Ouch!就我个人而言，当网站或服务试图强迫我使用遵循某种（通常是彻头彻尾的愚蠢）限制的密码时，我总是感到非常不安。
密码的全部意义不就是不容易被猜到吗？ 为什么您希望它们没有用户希望的那么复杂？ 我无法想象需要使用“仅 ASCII”作为密码的技术限制。
让您的用户使用他们喜欢的任何密码，对其进行哈希处理并将其存储为 Base64 字符串。 这些只是 ASCII。
Personally, I've always found it highly disturbing when a web site or service tried to force me to use passwords that follow a certain (usually downright stupid) limitation.
Isn't it the whole point of passwords that they are not too easily guessable? Why would you want them to be less complex than your users want them to be? I can't imagine a technical limitation that would require the use of "ASCII only" for passwords.
Let your users use any password they like, hash them and store them as Base64 strings. These are ASCII only.
给你：
假设你不想要空密码； 否则就是：
允许空的。
我不确定您为什么要询问
preg_replace- 我对操纵人们输入的密码持谨慎态度。 最好强制执行只接受可打印 ASCII 的规则，并告诉用户他们是否违反了该规则（或者，正如其他人所说，不要有任何规则，但我认为您有理由这么做）。如果您正在考虑悄悄删除不匹配的字符，并且有人提供了 Úéåæ 密码，那么您将在他们不知情的情况下为他们存储一个空密码。
Here you go:
assuming you don't want empty passwords; otherwise it's:
to allow empty ones.
I'm not sure why you're asking about
preg_replace- I'd be wary of manipulating the passwords that people type. Better to enforce the rule that you only accept printable ASCII, and tell the user if they break that rule (or, as others have said, to not have any rules, but I assume you have reasons for them).If you're thinking of quietly removing the characters that don't match, and someone comes along with a password of Úéåæ, then you'll be storing an empty password for them without their knowledge.
请不要过滤您的用户密码。 这违背了很多要点。 我在这里写了更多相关内容： http://www.evanfosmark.com/2009/06/why-do-so-many-websites-fail-with-password-restrictions/
Please don't filter your user passwords. That defeats a whole lot of the point. I wrote more about this here: http://www.evanfosmark.com/2009/06/why-do-so-many-websites-fail-with-password-restrictions/
/[\p{Cc}]/ 获取控制字符（我认为这涵盖了 0-31）
我同意 Richie 的观点。 使用 preg_match 而不是 preg_replace。
/[\p{Cc}]/ to get control characters (I think this covers 0-31)
I agree with Richie. Use preg_match instead of preg_replace.
我不同意没有理由拒绝非 ASCII 字符，尽管由您来决定利大于弊。
如果您允许非 ASCII 字符，那么您实际上是在承诺将 Web 应用程序的该部分正确国际化。 对于许多应用程序来说，国际化是事后才想到的。 对于 Web 应用程序来说，这是一件非常重要的事情。
如果在字符和字节之间切换时没有显式控制字符编码，那么您基本上依赖于部署的默认值。 如果您的配置发生变化（例如从 Windows 迁移到 Linux，或切换到另一个 Web 服务器），那么您的默认设置很可能会发生变化，然后非 ascii 字符将序列化为不同的字节序列。 因此，突然之间，在密码中使用它们的人的哈希值将与数据库中的内容不匹配，并且他们将被锁定在帐户之外。
当然，我确实同意仅仅过滤掉这些字符是完全不可接受的； 您必须接受或拒绝该密码。
I disagree that there is no reason to reject non-ascii characters, although it's up to you to decide whether the pros outweigh the cons.
If you allow non-ascii characters, then you are in fact committing to properly internationalize that portion of your web application. For many applications, internationalization is an afterthought. For web applications, it's a very non-trivial matter.
If you don't explicitly control the character encoding when you go between characters and bytes, then you are basically relying on whatever the defaults happen to be for your deployment. If your configuration ever changes (e.g. migrating from Windows to Linux, or switching to another web server), then your defaults have a good chance of changing from under you, and then the non-ascii characters will serialize to a different byte sequence. So, all of a sudden, the hashes of people using them in their passwords will not match what's in the database, and they'll get locked out of their accounts.
I do, of course, agree that it's completely unacceptable to just filter out those characters; you have to either accept or reject the password.