windows下獲取文件描述

一 背景

　　前幾天, 在公司寫的獲取文件描述的一段小程序出現了點小問題, 對於通常文件是正常的, 對於win10 C:\Program Files\WindowsApps目錄下的通用程序,就是死活獲取不到, 可是系統確是能夠讀出來的, 截圖以下, 左邊是能獲取到的, 右邊是比較各色的

以前用的方法參考

https://blog.csdn.net/liwen930723/article/details/49471459

vs跟蹤調試了一下有問題的, 整個屬性都獲取到了, languageCharset也獲取到了, 而後就是FileDescription死活獲取不到, 可是看了看前邊保存整個屬性的內存, 文件描述就好好的躺在那, 冥思苦想不得要領, 因而拿調試器調試了一下系統是怎麼獲取的.原來系統是有備選方案的, 關鍵點就在 languageCharset上, 系統是先用從文件中讀出來的languagecharset, 去獲取, 獲取不到再依次用0x040904B0,0x40904E4 ,0x04090000 去獲取, 因而我按照這個邏輯試了一下, 真的就獲取到了, 本文開頭的問題就這麼解決了, 可是你看系統給的備選值貌似存在某些規律, 並且 以前那個獲取出來的languageCharset正好是0x00004B0, 因而又到網上去搜了搜, 結果發現, 正如這個東西的名字languagecharset, 高16bit 表示languageID, 低16bit表示codepage, 

languageID: https://blog.csdn.net/tuwen/article/details/4160153 

codepage: https://baike.baidu.com/item/codepage/416287

0x409 表示英語, 

0x4E4 表示西歐拉丁字母ISO-8859-1

0x4B0 表示UCS-2LE Unicode 小端序

由於0x00004B0 表示語言的部分爲0, 因此係統顯示的就是語言爲中性, 備選的都是英語的codepage組合, 問題到這終於圓滿解決了.

不過, 本覺得全部的顯示"語言中性"的都這德行, 然而並非, 因此我推測應該是某些編譯器在生成這部分信息的時候出現了問題, 致使 languageCharset 跟其餘信息不一致. 可是微軟竟然填這種坑, 因此我大膽的推測, 這個要麼是當初定這個結構標準的時候沒有設計好, 要麼就真的微軟自家的某些編譯器組件的問題