Question

我将文化设置为匈牙利语，而Chr（）似乎被打破了。

System.Threading.Thread.CurrentThread.CurrentCulture = "hu-US"
System.Threading.Thread.CurrentThread.CurrentUICulture = "hu-US"

Chr(254)

当它应为“þ”时返回“ţ”

但是，Asc("ţ")会返回116。

这：Asc(Chr(254))返回116。

为什么Asc（）和Chr（）会有所不同？

我检查了'宽'功能是否正常工作：ascw（chrw（254））= 254

Answer 1

Chr(254)通过查看System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage属性，以系统相关的方式解释参数。请参阅MSDN article about Chr。您可以检查该值是否符合预期。 “hu-US”（美国使用的匈牙利语区域）可能会在那里做一些奇怪的事情。

作为旁注，Asc()对its current documentation中使用过的代码页没有承诺（它一直存在到3.0）。

通常我会坚持使用unicode变体（以-W结尾），或者使用Encoding类来明确指定转换。

Answer 2

我最好的猜测是你的Windows尝试将Chr（254）=“ţ”表示为组合字母，其中第一个字母是Chr（116）=“t”，第二个字母是“（¸”或类似的东西））无法返回，因为Chr（）只返回一个字母。

不应逐个字符地处理Unicode文本。

Answer 3

听起来您需要为当前线程设置代码页 - 当前文化不应对Asc和Chr产生任何影响。

Chr文档和Asc文档都有此行：

返回的字符取决于当前线程的代码页，该代码页包含在ANSICodePage类的TextInfo属性中。可以通过指定TextInfo.ANSICodePage来获取System.Globalization.CultureInfo.CurrentCulture.TextInfo.ANSICodePage。

Answer 4

我在Mac上看到了VBA中的几个问题，其中127以上的字符和一些控制字符未得到正确处理。这包括段落标记（特别是在从互联网复制或扫描的文本中），“¥”和“Ω”。

不能总是搜索它们，不能在文件名中使用 - 尽管它们可能在过去，并且在测试时，会出现另一个ascii编号。我不得不编写算法来在文件打开时更改这些，因为它们通常看起来像是正确的字符，但是当它们行为异常时会崩溃我的一些宏。保存文件时，该字符将正常显示，但在重新打开时可能会更改。

我最终会尝试切换到unicode，但我不确定这是否有助于解决这个问题。

这可能不是您所观察到的问题，但我不排除某些字符的孤立问题。我过去曾向MS发过关于此事的说明，但没有收到任何快乐。

如果找不到其他解决方案并且在输入时字符看起来正确，那么我建议使用下面的宏代码，我在更新表时运行。您当然必须将theRange设置为您正在查看的区域。整个文件可能需要一段时间。

        For aChar = 1 To theRange.Characters.count
            theRange.Characters(aChar).Select
            If Asc(Selection.Text) = 95 And Selection.Text <> "_" Then Selection.TypeText "Ω"
        Next aChar

当语言为匈牙利语时，Asc（Chr（254））在.Net 1.1中返回116

4 个答案: