大约一周前，我发现每当出现带有较长日文文件名的文件时，µTorrent 中的文件列表就会挂起不到一秒钟。我觉得这很奇怪，但当时我真的没有时间担心它，尤其是因为它仅限于 µTorrent。
然而，今天我意识到事实并非如此。例如，如果我保存一个带有长多字节字符文件名的文本文件，并在记事本中打开它，我会得到一些奇怪的结果。当我尝试调整窗口大小时，一切都变得非常缓慢。然而，我可以松开对窗口的控制，看看我的光标一分为二，其中一个由我控制，另一个是一种“幽灵光标”，因为找不到更好的词来形容它，它执行我最初用鼠标进行的拖动动作。这仅适用于这种性质的文件名，我也在记事本和 µTorrent 以外的应用程序中测试过它。
我尝试寻找导致这种奇怪行为的原因，但一无所获。这里有人知道发生了什么吗？
不幸的是，我无法截取此屏幕截图，因为似乎所有屏幕截图应用程序都会挂起，直到调整大小完成后才能截取屏幕截图......
编辑：我录制了一个视频来演示这个问题。我不确定这是否有助于确定原因，但它至少应该比我上面的解释更好：
编辑2：这是所要求的示例文件：请注意，它只是一个具有长多字节文件名的空文件：http://goo.gl/bgnGP（对于浏览器无法处理文件名的用户，这里有一个 zip 文件：https://dl.dropbox.com/u/55495248/multibyte.zip）
答案1
我可以解释 Unicode 是如何处理的，但我无法直接回答你的问题。第一次写入时速度很慢，但一旦完成，速度又会变快……
Unicode 由我们所谓的平面组成。平面有 256 个字符。在许多情况下，字体将处理一个平面，部分原因是为了避免文件过大，但也因为它足以容纳许多语言（英语、法语、德语……）。但是，亚洲语言使用覆盖多个平面的较大字体。如果我没记错的话，对于完整的日语字符集，您将获得大约 10 个平面。中文更多（尤其是繁体中文！）
使用此类字体进行渲染时，您必须选择相应的字体（如果一种字体不足以处理所有字符，操作系统会为您切换字体；这是幕后操作，但确实会发生。）这很耗时。此外，系统第一次使用该字体写入时，需要从磁盘加载它。亚洲语言的字体很大，这也需要时间。
最后，您遇到的情况可能更可能如此，字符（或字形）通常更复杂。这意味着需要更多时间来渲染字符。虽然可以使用带有 OpenGL/D3D 的视频板来完成此操作，但对于字体来说，这并不是很好。您会损失很多质量（尽管 MS-Windows 下的字体质量...）因此，这通常是由处理器完成的。
最后要说的是，虽然我真的怀疑这是否值得担心，但默认情况下，Win7 会使窗口边缘半透明。这可能会加剧问题。然而，这部分渲染肯定是通过视频板上的加速 2D/3D 功能完成的。
答案2
如果您的电脑渲染多字节字符，速度会变慢，因为它可能需要执行多条指令来处理该字符。
64 位版本可以在 1 次调用中获取 64 位名称，在 1 次调用中处理它并在 1 次调用中存储它 = 3 次调用。
32 位版本必须先处理前 32 位，然后再处理另外 32 位，然后管理这两个操作：
通过 3 次调用获取 64 位名称，通过 3 次调用对其进行处理，并通过 3 次调用将其存储 = 9 次调用。