GetGeoInfoW 函式 (winnls.h)
[GetGeoInfo 可用於需求一節中指定的作業系統。 它在後續版本中可能會變更或無法使用。 請改用 GetGeoInfoEx。
]
擷取指定地理位置的相關資訊。
語法
int GetGeoInfoW(
[in] GEOID Location,
[in] GEOTYPE GeoType,
[out, optional] LPWSTR lpGeoData,
[in] int cchData,
[in] LANGID LangId
);
參數
[in] Location
要取得資訊的地理位置識別碼。 如需詳細資訊,請參閱 地理位置資料表。 您可以呼叫 EnumSystemGeoID來取得可用的值。
[in] GeoType
要擷取的資訊類型。 可能的值是由 SYSGEOTYPE 列舉所定義。 如果 GeoType 的值GEO_LCID,函式會擷取地區設定識別碼。 如果 GeoType 的值GEO_RFC1766,函式會擷取符合 RFC 4646 (Windows Vista) 的字串名稱。 如需詳細資訊,請參閱<備註>一節。
Windowsxp: 當 GeoType 設定為 GEO_LCID 時,擷取的字串是 8 位數的十六進位值。
Windows Me: 當 GeoType 設定為GEO_LCID時,擷取的字串會是十進位值。
[out, optional] lpGeoData
這個函式擷取資訊的緩衝區指標。
[in] cchData
lpGeoData所指示的緩衝區大小。 大小是函式 ANSI 版本的位元組數目,或 Unicode 版本的字數。 如果函式傳回所需的緩衝區大小,應用程式可以將此參數設定為 0。
[in] LangId
語言的識別碼,與 Location值搭配使用。 應用程式可以將此參數設定為 0,並針對 GeoType指定GEO_RFC1766或GEO_LCID。 此設定會藉由呼叫 GetUserDefaultLangID來擷取語言識別項。
傳回值
傳回在輸出緩衝區中擷取之地理位置資訊的 Unicode) (ANSI) 或單 (字的位元組數目。 如果 cchData 設定為 0,函式會傳回緩衝區所需的大小。
如果函式未成功,則傳回 0。 若要取得延伸的錯誤資訊,應用程式可以呼叫 GetLastError,這可以傳回下列其中一個錯誤碼:
- ERROR_INSUFFICIENT_BUFFER。 提供的緩衝區大小不夠大,或設定為 Null不正確。
- ERROR_INVALID_PARAMETER。 任何參數值都無效。
備註
如果應用程式為 GeoType指定GEO_RFC1766,它應該指定適用于指定地理位置識別碼的 LangId 語言識別項。 適當的語言是地區設定中性語言,或是具有對應至指定識別碼的地區設定。 產生的字串符合 RFC 4646 (Windows Vista) ,構成 地區設定名稱。
例如,如果Location指定為 美國的0xF4,則 GeoType會指定為 GEO_RFC1766,而LangId會指定為地區設定中性英文的 0x09,或針對英文 (美國) 0x409,則函式會在成功傳回時擷取 「en-US」。 事實上,函式會忽略語言的地區設定特定部分。 因此,如果應用程式將 LangId 指定為英文 (英國) 的 0x809,函式也會將 「en-US」 寫入 lpGeoData。
請考慮另一個範例。 如果Location指定為 美國 的0xF4,GeoType會指定為 GEO_RFC1766,而LangId會指定為中文的 0x04,則函式會在成功傳回時擷取 「zh-US」。 這不是支援的地區設定名稱。
如果應用程式指定 GeoType的GEO_LCID,函式會將語言識別項視為地區設定識別碼, (LCID) 。 如果它以某種方式與提供的地理識別碼相關聯,它會嘗試傳回地區設定識別碼。
注意
winnls.h 標頭會將 GetGeoInfo 定義為別名,根據 UNICODE 預處理器常數的定義,自動選取此函式的 ANSI 或 Unicode 版本。 混合使用編碼中性別名與非編碼中性的程式碼,可能會導致編譯或執行時間錯誤不符。 如需詳細資訊,請參閱 函式原型的慣例。
規格需求
最低支援的用戶端 | Windows XP [傳統型應用程式 |UWP 應用程式] |
最低支援的伺服器 | Windows Server 2003 [傳統型應用程式 |UWP 應用程式] |
目標平台 | Windows |
標頭 | winnls.h (包含 Windows.h) |
程式庫 | Kernel32.lib |
DLL | Kernel32.dll |
另請參閱
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應