【问题标题】:GetPrivateProfileString OddityGetPrivateProfileString 奇数
【发布时间】:2010-09-12 14:13:36
【问题描述】:

我只是在修补从 .NET 调用 kernel32 中的 GetPrivateProfileString 和 GetPrivateProfileSection 并遇到了一些我不明白的奇怪问题。

让我们从这个咒语开始:

    Private Declare Unicode Function GetPrivateProfileString Lib "kernel32" Alias "GetPrivateProfileStringW" ( _
    ByVal lpApplicationName As String, _
    ByVal lpKeyName As String, _
    ByVal lpDefault As String, _
    ByVal lpReturnedString() As Char, _
    ByVal nSize As Int32, _
    ByVal lpFileName As String) As Int32

如果我传递一个 lpApplicationName(部分),没有 lpKeyName 和 lpDefault,我应该得到该部分的所有密钥,而且确实有:50% 的时间。

如果 ini 文件的 lpApplicationName 从第一行开始,则缓冲区不返回任何内容。如果 lpApplicationName 统计在文件的第二行,它会返回预期值。

起初我虽然是在声明中使用 W 版本和 Unicode,但更改这些似乎没有效果。

我错过了什么?

【问题讨论】:

    标签: winapi unicode encoding ini


    【解决方案1】:

    检查您打开的文件是否有byte order mark(标记文本编码类型的几个字节)。

    这些 Windows API 调用似乎无法识别字节顺序标记,导致它们错过了第一部分(因此,如果有空行,一切正常)。

    【讨论】:

    • 有没有办法告诉工作室停止为简单的测试文件编写 BOMS?
    • 我不知道 BOM 偷偷溜进来的事实。在找到您的答案之前,我几乎花了一个小时想知道发生了什么。太好了!
    【解决方案2】:

    好电话。在 VS.NET 中编辑 ini 文件当然是(Duh)添加一个 utf-8 BOM。嗯。 在记事本中打开它并执行 SaveAs ASCII 会产生预期的结果。

    如此明显。这么迟钝。又过了一个小时。 :-)

    谢谢! -=克里斯

    【讨论】:

    • 是的——我最近自己失去了那个小时!我没有一个好的解决方案,最简单的方法是在打开文件并发出错误之前手动检查文件,但这并不能真正帮助用户。
    猜你喜欢
    • 1970-01-01
    • 2013-07-02
    • 2012-11-14
    • 2012-05-17
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多