GetPrivateProfileString Oddity

我只是在修補kernel32中的.NET的GetPrivateProfileString和GetPrivateProfileSection，並發現了一些奇怪的東西，我不明白。GetPrivateProfileString Oddity

讓我們先從這個encantation：

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在文件的第二行進行統計，它將返回預期值。

起初我雖然是在Declare中使用W版本和Unicode，但改變這些似乎沒有效果。

我錯過了什麼？

來源

2008-09-24 claco

檢查您正在打開的文件是否有byte order mark（標記文本編碼類型的幾個字節）。

這些Windows API調用似乎沒有幫助字節順序標記，並導致它們錯過了第一部分（因此，如果有空行，一切工作正常）。

來源

2008-09-24 01:00:17

有沒有辦法讓工作室停止爲簡單測試文件編寫BOMS？ – claco 2008-09-24 01:16:09

我沒有意識到BOM暗中偷偷的事實。我幾乎花了一個小時想知道發生了什麼，然後才找到答案。大！ – 2010-11-20 09:24:24

良好的通話。編輯VS.NET中的ini文件當然是（Duh）添加utf-8 BOM。哎呀。在記事本中打開它並執行SaveAs ASCII操作會產生預期結果。

很明顯。所以懶惰。在垃圾箱下一小時。 :-)

謝謝！ - = Chris

來源

2008-09-24 01:06:43 claco

GetPrivateProfileString Oddity

回答

相關問題