如何将 Unicode 字符转换为其 ASCII 等效字符答案

【问题标题】：How to convert a Unicode character to its ASCII equivalent如何将 Unicode 字符转换为其 ASCII 等效字符
【发布时间】：2026-02-22 05:00:01
【问题描述】：

问题来了：

在 C# 中，我从旧的 ACCESS 数据库中获取信息。 .NET 在将内容交给我之前将数据库的内容（在此问题中为字符串）转换为 Unicode。

如何将此 Unicode 字符串转换回它的 ASCII 等价物？

编辑
Unicode char 710 确实是 MODIFIER LETTER CIRCUMFLEX ACCENT。这里的问题更精确一点：

 -> (Extended) ASCII 字符 ê (Extended ASCII 136) 被插入到数据库中。
 -> Access 或 .NET 中的读取组件将其转换为 U+02C6 U+0065
    （修饰符字母 CIRCUMFLEX ACCENT + 拉丁文小写字母 E）
 -> 我需要（扩展的）ASCII 字符 136。

这是我尝试过的（我现在明白为什么这不起作用......）：

string myInput = Convert.ToString(Convert.ToChar(710));
byte[] asBytes = Encoding.ASCII.GetBytes(myInput);

但这不会导致 94 而是一个值为 63 的字节...
这是一个新的尝试，但它仍然不起作用：

byte[] bytes = Encoding.ASCII.GetBytes("ê");

解决方案
感谢csgero 和bzlm 指出正确的方向，我解决了here 的问题。

【问题讨论】：

“扩展 ASCII”一词令人困惑。如果您的输入数据确实是 ASCII，则没有 ë 或“字符编号 136”。您的数据更有可能包含 ASCII 无法表示的字符，例如可通过 Windows-1252 等传统 8 位编码表示的国际数据。
我知道，有一篇关于这个主题的完整*文章。
您应该将解决方案作为答案而不是在问题中发布，以便我们能够投票支持它。

标签： c# .net unicode ascii

【解决方案1】：

好的，让我们详细说明。 csgero 和 bzlm 都指向了正确的方向。

由于 blzm 的回复，我在 wiki 上查找了 Windows-1252 页面，发现它被称为代码页。 Code page 的*文章声明如下：

这些“extended character sets”没有正式的标准； IBM 只是将这些变体称为代码页，就像它一直对 EBCDIC 编码的变体所做的那样。

这导致我进入代码页 437：

n ASCII 兼容代码页，低 128 个字符保持其标准 US-ASCII 值，并且可以在高 128 个字符中提供不同的页面（或字符集）。例如，为北美市场制造的 DOS 计算机使用 code page 437，其中包括法语、德语和其他一些欧洲语言所需的重音字符，以及一些图形画线字符。

所以，代码页 437 是我称之为“扩展 ASCII”的代码页，它的 ê 作为字符 136，所以我还查找了其他一些字符，它们看起来是正确的。

csgero 带有 Encoding.GetEncoding() 提示，我用它来创建以下语句来解决我的问题：

byte[] bytes = Encoding.GetEncoding(437).GetBytes("ê");

【讨论】：

查看 Unicode 规范化主题，特别是两种形式的等价：规范和兼容性 - en.wikipedia.org/wiki/Unicode_normalization 在 .NET 字符串实例上，调用 Normalize 方法，传递 NormalizationForm.FormD 或 NormalizationForm.FormKD，这对应于规范和可兼容的分解形式。例如，在像“êwś”这样的字符串上调用它，将产生字符串“e^ws'”。您也可以反过来，通过调用 Normalize( NormalizationForm.FormC ) 或 Normalize( NormalizationForm.FormKC ) 将“e^”之类的字符串转换为“ê”。

【解决方案2】：

您不能在此处使用默认的 ASCII 编码 (Encoding.ASCII)，而必须使用 Encoding.GetEncoding(...) 使用适当的代码页创建编码。您可以尝试使用代码页 1252，它是 ISO 8859-1 的超集。

【讨论】：

像这样：byte[] bytes = Encoding.GetEncoding(437).GetBytes("ê");

【解决方案3】：

ASCII 没有定义 ê；数字 136 来自 8 位编码（如 Windows-1252）中的抑扬符数字。

您能否验证在这种情况下，带有抑扬符 (ê) 的小 e 实际上是应该存储在 Access 数据库中的内容？也许 U+02C6 U+0065 是转换错误的结果，其中输入实际上是一个 e 后跟一个抑扬符，或者完全是其他东西。也许您的 Access 数据库存在损坏的数据，因为指定的编码与内容不匹配，在这种情况下，.NET 客户端可能会错误地解析数据（使用错误的解码器）。

如果在从数据库读取过程中确实引入了这个错误，也许粘贴一些代码或配置设置可能会有所帮助。

在Code page 437 中，第 136 位字符是带抑扬符的 e。

【讨论】：

谢谢！您的提示很有帮助，实际上是代码页 437 (MS-DOS)。使用 Encoding.GetEncoding(437) 就可以了。

【解决方案4】：

嗯……我不确定你指的是哪个角色。插入符号（“^”，CIRCUMFLEX ACCENT）在 ASCII 和 Unicode (U+005E) 中具有相同的代码。

/编辑：该死，我的错。 710 (U+02C6) 实际上是修饰符字母 CIRCUMFLEX ACCENT。不幸的是，这个字符根本不是 ASCII 的一部分。它可能看起来像普通的插入符号，但它是一个不同的字符。简单的转换在这里无济于事。我不确定.NET 在从 Unicode 转换时是否支持类似字符的映射。不过值得研究。

【讨论】：

OJ：这和 UTF-8 有什么关系？
@OJ，我知道这一点。但是，一个字符的代码点在所有 Unicode 编码中都是相同的。
@Chris：在 Konrad 的原始帖子中，他谈到了 UTF8，而不是 Unicode。
你是对的，它确实是 MODIFIER LETTER CIRCUMFLEX ACCENT，看我的编辑。

【解决方案5】：

值 63 是问号，又名“我无法以 ASCII 显示此字符”。

【讨论】：

所以，你指出了我的问题。问题是我该怎么做，我知道我尝试的方法不起作用。