Question

问题在于：

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

如何将此Unicode字符串转换回其ASCII等效字符？

<小时/> 的修改
Unicode char 710确实是MODIFIER LETTER CIRCUMFLEX ACCENT。这个问题更加精确：

 -> (Extended) ASCII character ê (Extended ASCII 136) was inserted in the database.
 -> Either Access or the reading component in .NET converted this to U+02C6 U+0065
    (MODIFIER LETTER CIRCUMFLEX ACCENT + LATIN SMALL LETTER E)
 -> I need the (Extended) ASCII character 136 back.

<小时/> 这是我尝试过的（我现在看到为什么这不起作用......）：

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

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

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

<小时/> 的 Soltution
感谢csgero和bzlm指向正确的方向我解决了问题here。

Answer 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("ê");

Answer 2

您不能在此处使用默认的ASCII编码（Encoding.ASCII），但必须使用Encoding.GetEncoding（...）使用相应的代码页创建编码。您可以尝试使用代码页1252，它是ISO 8859-1的超集。

Answer 3

ASCII不定义ê;数字136来自8位编码（例如Windows-1252）中的抑扬数。

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

如果在从数据库读取期间确实引入了此错误，则可能粘贴某些代码或配置设置可能有所帮助。

在Code page 437中，字符编号136是带有抑扬符的e。

Answer 4

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

/编辑：该死，我的错。 710（U + 02C6）实际上是MODIFIER LETTER CIRCUMFLEX ACCENT。不幸的是，这个字符根本不是ASCII的一部分。它可能看起来像普通的插入符号，但它是一个不同的角色。简单的转换在这里没有用。我不确定.NET是否支持从Unicode转换时类似字符的映射。值得调查一下。

Answer 5

值63是问号，AKA“我无法以ASCII格式显示此字符”。

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

5 个答案: