一般来说，没有理由不在密码中使用任意字符，除非处理密码的系统对它们做了一些愚蠢的事情（比如完全删除它们，留下一个空密码）。

在特定语言字符集的糟糕时代，当您切换到另一台计算机时，总是存在具有非 ASCII 字符的密码可能会停止工作的风险，因为它对这些字符进行了不同的编码。但是现在每个人都将 Unicode 作为标准通用字符集进行了标准化，因此除非处理旧的遗留系统，否则这个原因很少适用。

（当然，我们仍然有不同的方式将 Unicode 字符编码为字节，如 UTF-8、UTF-16-LE/BE、UCS-32 等，但至少这些通常都在接收程序的控制之下，与过去依赖于用户的操作系统和/或终端设置（如字符集选择）相反。而且，老实说，UTF-8 作为 I/O 目的的标准 Unicode 编码已经非常成熟，即使某些软件可能使用其他内部编码。）

事实上，使用来自更广泛池的字符会使攻击者更难通过暴力破解猜出您的密码。也就是说，使密码稍长通常比在密码中添加“奇怪”字符（强制性 xkcd 链接）更有效，因此，如果您可以轻松输入并记住它们，则只能在密码中使用非英文字符，例如因为你说一种使用这些字符的语言。

尽管如此，您有时可能不想在密码中使用非 ASCII 字符还是有一些原因：

• 如果您需要使用不同的键盘从共享/借用的计算机登录，或者您自己的计算机的键盘布局由于某种原因被切换，它们可能不容易输入。

  （实际上，ASCII 标点符号也是如此，因为许多键盘布局都喜欢切换这些键。但至少您通常可以在任何键盘上键入它们。）

• 处理密码的系统可能不接受它们。 人们对什么才是有效密码有一些有趣的想法，尤其是一些较旧的系统（尤其是如果它们是在美国开发的）可能会简单地拒绝接受密码中除了可打印的 US-ASCII 字符之外的任何内容。他们甚至可能有某种正当理由这样做，例如，如果密码在使用不同字符编码的旧旧系统之间在内部传递，或者以某种方式破坏非 ASCII 数据（见下文）。

• 即使在客户端，一些旧的字符集问题可能仍然会引起注意。例如，如果密码是在网页上的 HTML 表单中输入的，并且如果页面没有明确指定其字符编码，不同的浏览器可能会自动检测不同的编码，从而导致密码（以及输入到表单中的任何其他文本） ) 以不同方式编码。

• 对于某些书写系统，Unicode 规范化也可能导致问题。在不深入细节的情况下，有几种等效的方法可以在 Unicode 中表示许多字符。如果密码处理系统在对密码进行哈希处理之前没有通过 Unicode 规范化算法显式运行密码（很多人没有），那么在不同的计算机上键入相同的字符可能会导致不同的 Unicode 代码点序列，从而导致密码使用该字符不匹配。

如果处理密码的后端从未设计或测试过除了 ASCII 字符之外的任何东西，它也可能在给定不期望的输入时简单地中断。例如：

• 不同的部分可能以不同的方式处理非 ASCII 字符。 您可能期望给定系统中的所有密码处理都将通过相同的代码，但实际上，很可能有多个实现密码哈希（例如，对于相同的后端数据的不同用户界面），他们可能不同意 100 % 意外输入。例如，这可能意味着您的密码可能在网络上有效，但不适用于本机客户端应用程序，反之亦然。

• 系统可能会去除非 ASCII 字符，甚至在第一个这样的字符处截断密码。您会认为对密码执行此操作是一件很疯狂的事情（确实如此！），但系统可能会通过一些通用的“输入清理”功能运行所有输入，该功能只会删除它无法识别的任何内容“安全的”。在大多数情况下，这并不是一个糟糕的安全措施（即使通常发出错误信号而不是默默地丢弃数据更安全）；对于密码，这可能是灾难性的。

• 系统可能在内部使用非 ASCII 字符作为分隔符，假设这些字符永远不会出现在真实数据中。这似乎是一件愚蠢的事情，但我已经看到它完成了，包括在 Stack Exchange 上。充其量，例如设计会迫使系统不接受分隔数据中的此类字符；在最坏的情况下，使用此类字符可能会导致数据被截断或乱码。显然，这对于密码来说可能真的很糟糕。

  （当然，某些系统也可能使用 ASCII 分隔符来执行此操作，从而导致诸如“密码可能不包含@或%”之类的愚蠢限制。）

• 系统可能会限制密码长度。 许多旧的密码散列方案（甚至一些相对现代且看似不错的方案，例如1999 年的bcrypt）不会接受长度超过一定字节数的密码，甚至可能会默默地截断超过限制的密码。这通常是一个潜在的安全问题，但使用可变长度编码（如 UTF-8）可能会加剧这种情况，其中非 ASCII 字符每个字符占用两个或更多字节。因此，例如，将密码限制为 16 个字节的 UTF-8 的系统可以处理 16 个字符的 ASCII 密码，但只能处理 8 个字符，例如希腊语或西里尔文文本。

所有这一切的结果是，一般来说，在密码中仅使用可打印的 US-ASCII 字符最不可能触发软件错误或限制。鉴于密码处理错误通常很难处理（因为您经常得到的唯一响应是“无效密码”），很多人可能会发现坚持这些错误最简单、最安全。

如果您确实想使用非 ASCII 密码（例如，让自己不那么容易成为暴力破解密码的目标，或者只是因为您更容易输入和记住），您可能需要测试系统是否真正处理以（合理）理智的方式输入您的密码。我建议至少测试一下：

1. 您可以使用您的密码登录（使用所有可用的登录方法，如果系统提供多种登录方法，并且使用您可能使用的所有浏览器或其他客户端）；
2. 与您的密码相关联的所有功能（例如加密存储）确实可以正常工作；和
3. 您无法使用密码的简单变体登录，例如更改某些非 ASCII 字符或在末尾附加额外字符。

无论如何，有一个论点是，至少在所有情况下，至少在 95% 的情况下，您不应该选择自己的密码。相反，您应该使用安全的密码管理器，并让它为您生成随机密码。这种随机生成的密码通常是一长串可打印的随机 ASCII 字符，以最大限度地提高熵，同时最大限度地减少潜在的兼容性问题，但这并不重要，因为您不需要自己输入或记忆它们。

当然，您仍然需要为密码管理器选择一个密码。但希望您的密码管理器至少编写得很好，并且能够正确处理非 ASCII 密码。

如果您从较大的可能密码空间中随机选择密码，则密码会更强大。所以从技术上讲，这种说法是错误的。

当要在键盘上键入具有外语字符的密码时，可能会引入弱点。但这不是密码学的问题。

字符长度

还没有人提到密码的长度，所以我将在此处添加。

提供该建议的人可能正在考虑保持较高的字符数，当您将自己限制为拉丁字符集时，这一点非常重要。例如，以下将是您如何计算基于 alpha 的密码的强度。

26 ⁿ ≈ 2 ^{5 n}

即使你包括大小写和数字，长度仍然很重要

96 ⁿ ≈ 2 ⁷ⁿ

将字符集扩大到整个 UTF-8 字符集可以为您提供

1114112 ⁿ ≈ 2 ²¹ⁿ

但实际上，如果你只是使用最常见的汉字

2000 ⁿ ≈ 2 ¹¹ⁿ

因此，虽然给出建议的人可能一直在想“由于单个字符更多的单词，东方密码可能会更短”，但与仅 alpha 密码相比，存在改进。

字符与单词

但是，最近出现了向“密码短语”或使用多个随机单词组成密码以使密码更复杂的巨大转变，然后（仅用英语）与整个 UTF-8 相当字符集。

1025110 ^m ≈ 2 ^21m

虽然再次，只是使用最常见的英语单词

3000 ^m ≈ 2 ¹²ⁿ

我无法想象如果你开始包含来自其他语言的单词，那么这个集合会有多大，因为肯定会有重叠的单词，但是考虑到字符发生的情况，我认为你可以放心地假设它仍然会是一个更大的数字。

警告

所有这些都是基于字符/单词的随机分配，然而，应该注意字符和单词的选择不是随机的，而是根据它们的知名度以及它们被使用的可能性来加权。此外，模式变得常见，例如“ll”或“qu”。所有这些通常都会降低密码的安全性。

确保您的密码安全

鉴于所有这些，有一些方法可以让您的密码难以猜测但相当容易记住：选择 3 到 5 个对您有意义的单词，将 1 或 2 个单词中的随机字符替换为其他随机字符，或另一组完全的信息，使用不止一种语言和字符集......

例子不好

一些最知名的密码和密码示例通常被读者直接使用，并被黑客等人阅读。这会降低这些密码的安全性。因此，请从这些技术中汲取灵感并自己制作。

摘要（并回答操作问题）

我可以从中看出，通知你的人是误传了自己（按密码长度），或者觉得互联网不是 unicode 字符的地方。

这听起来像是使用外语词典中的完整单词与允许外语字符混淆。您不应该使用完全（或部分）作为外语词典中的完整单词组成的密码，就像您不应该使用英语词典一样，因为将外语词典添加到密码破解攻击中是微不足道的。

正如其他人所说，在密码中使用外来字符会使密码在许多情况下更难破解。