问题标签 [unicode]

我正在编写一个游戏，它接受用户输入并将其呈现在屏幕上。我为此使用的引擎完全是 unicode 友好的，所以如果可能的话，我想保留它。问题是渲染循环看起来像这样：

我对 i18n 了解不多，但我知道上面的代码只会对我和说我的语言的人有用。我更喜欢这样的东西：

这是否存在于核心发行版中？我有点反对在安装中添加额外的要求，但如果这是唯一的方法，我会活下去。

为了更有趣，我无法知道该字符串是否实际上是一个 unicode 字符串。

编辑：我正在使用的库确实可以渲染整个字符串，但是我让用户编辑即时出现的内容 - 如果他们点击“退格”，基本上，我需要知道要砍掉多少字节结束.

有人可以提供一些我在 C# 中处理 Unicode 字符串时应该注意的重要方面吗？

我正在使用TinyXML来解析/构建 XML 文件。现在，根据文档，该库通过 UTF-8 支持多字节字符集。到目前为止，我认为很好。但是，该库提供的唯一 API（用于获取/设置元素名称、属性名称和值，......使用字符串的所有内容）是通过std::stringor const char*。这让我怀疑自己对多字节字符集支持的理解。仅支持 8 位字符的字符串如何包含 16 位字符（除非它使用代码页，否则会否定“支持 Unicode”声明）？我了解您理论上可以采用 16 位代码点并将其拆分为 a 中的 2 个字符std::string，但这不会改变std::string对于“Unicode”字符串，它会使其在大多数用途中无效，并且在写入文件并被另一个程序读入时可能会意外工作。

那么，有人可以向我解释一个库如何提供“8 位接口”（std::string或const char*）并且仍然支持“Unicode”字符串吗？

（我可能在这里混淆了一些 Unicode 术语；对于由此产生的任何混淆，我深表歉意）。

在文本文件中，有一个字符串“我不喜欢这个”。

然而，当我把它读成一个字符串时，它变成了“我不喜欢这样\xe2\x80\x98t”。我知道 \u2018 是“'”的 unicode 表示。我用

命令进行阅读。

现在，是否有可能以这样的方式读取字符串，当它被读入字符串时，它是“我不喜欢这个”，而不是“我不喜欢这个”？

第二次编辑：我看到有人使用映射来解决这个问题，但实际上，没有内置的转换可以将这种 ANSI 转换为 unicode（反之亦然）吗？

更准确地说，我需要知道我是否（如果可能的话，如何）找到给定的字符串是否有双字节字符。基本上，我需要打开一个弹出窗口来显示可以包含双字节字符的给定文本，例如中文或日文。在这种情况下，我们需要调整窗口大小而不是英语或 ASCII。有人有线索吗？

是否可以以独立于平台的方式将 std::string 中的 UTF8 字符串转换为 std::wstring ，反之亦然？在 Windows 应用程序中，我将使用 MultiByteToWideChar 和 WideCharToMultiByte。但是，代码是为多个操作系统编译的，我仅限于标准 C++ 库。

由于 Unicode 缺少一系列零宽度排序字符，因此我需要确定等效字符，以便我可以在按字符值自动排序的列表上强制执行特定顺序。不幸的是，列表项不是按字母顺序排列的，也不可以在它们前面加上可见字符以确保排序结果与想要的结果相匹配。

哪些 Unicode 字符可以放在常规拉丁字母文本前面，并且不会出现，但仍然允许我以我需要的方式“尖峰”排序？

（顺便说一句，这是使用带有用户配置文件列表字段的 Drupal 5 完成的。不要费心建议将其更改为词汇/类别。）

I have a range of Win32 VCL applications developed with C++Builder from BCB5 onwards, and want to port them to ECB2009 or whatever it's now called.

Some of my applications use the old TNT/TMS unicode components, so I have a good mix of AnsiStrings and WideStrings throughout the code. The new version introduces UnicodeString, and a bunch of #defines that change the way functions like c_str behave.

I want to modify my code in a way that is as backwards-compatible as possible, so that the same code base can still be compiled and run (in a non-unicode fashion) on BCB2007 if necessary.

Particular areas of concern are:

• Passing strings to/from Win32 API functions
• Interop with TXMLDocument
• 'Raw' strings used for RS232 comms, etc.

Rather than knife-and-fork the changes, I'm looking for guidelines that I can apply to ease the migration, while keeping backwards compatibility wherever possible.

If no such guidelines already exist, maybe we can formulate some here?

URL 编码 unicode 字符的常用方法是将其拆分为 2 个 %HH 代码。( \u4161 => %41%61 )

但是，解码时如何区分unicode？你怎么知道%41%61是\u4161与\x41\x61（“Aa”）？

需要编码的 8 位字符是否以%00 开头？

或者，unicode字符应该丢失/拆分的点是什么？

由于某种原因，最近我的许多客户端系统上的 *.UDL 文件不再兼容，因为它们曾经保存为 ANSI 文件，不再与预期的 UNICODE 文件格式兼容。最终结果是一个错误对话框，指出“文件不是有效的复合文件”。

以编程方式打开这些文件并保存为 unicode 文件的最简单方法是什么？我知道我可以通过在记事本中打开每个文件然后保存为同一个文件但在另存为对话框的编码部分中选择“unicode”来做到这一点，但我需要在程序中执行此操作以减少支持来电。

这个问题很容易重复，只需在目录中创建一个*.txt 文件，将其重命名为*.UDL，然后使用microsoft 编辑器进行编辑。然后在记事本中打开它并将其另存为 ANSI 编码文件。尝试从 udl 编辑器打开 udl，它会告诉您它已损坏。然后将其（使用记事本）保存为 Unicode 编码文件，它将再次正确打开。