微軟若不再支援A版API，VBVBA會不會真涼？

你怎麼看？

1、熟悉Win32API的朋友，肯定知道部分函式有A/W版之分，而有的卻沒有。

A/W版之分，主要就是針對字串的，說明這樣的函式跟字串有關。

a、要知道

計算機的發展，無論是從硬體還是軟體，很多時候回頭去看，貌似都有走一步算一步的味道。

受工業革命的影響，計算機的機械時代，自然在歐洲（尤其是法國）首先發育出來。而到了電氣時代，則轉移到了北美繼續發育。總之，計算機早期，都是英語國家在研究，而英語只有26個字母，再加上其他抽象出來與機器控制有關的符號，127個符號範圍，就已經足夠用了，這就是ASC字元。

b、

受限於當時的硬體投入、實用性等原因，並沒有考慮那麼多。

比如後面的千年蟲問題，當然也包括字串的編碼問題。但隨著計算機技術的進化，比如被用於曼哈頓計劃，不少先驅們開始意識到計算機將對人類的生產生活產生深遠的影響，必須對之前的“小氣”做出一些改變。比如John Kemenyk開始考慮讓普通人參與程式設計，便誕生了後來的BASIC（VB前身）。比如要讓非英文國家使用計算機（賺錢），但將127個擴充套件到255個，都是不夠用的呀。怎麼辦呢？

繼續擴呀，這就是後來的ANSI和Unicode編碼。

二者對計算機而言雖然都可以處理任意字元，但是

在顯示時，ANSI就麻煩了(很多亂碼的源頭就在這裡)。

c、所以隨著世界變成地球村，為了便於交流，計算機系統基本上都以Unicode為標準了。Unicode以2位元組表示1個字元，

雖然對英語國家而言有點浪費，但畢竟通用了，能將各色產品賣到全球，就沒什麼不好了。

2、從Windows2000（XP之前）就是Unicode核心了，

Win32API就以W版為主，即便為了相容還保留了A版，但本質上也是呼叫W版函式(所以相容的負擔其實不大，能提高佔位率，何樂而不為呢，因此不必擔心不支援的問題)。

既然

系統核心都是Uncode的，自然W版的函式要高效，那為何VB/VBA中要用A版函式呢？

VB/VBA中的字串明明就是Unicode的呀！

3、我們知道VB6是1998年的產物，正值Win9x向WinNT過渡期。當時Win98如日中天，VB所在的生態資源，還是以ANSI為主，所以

內部以ANSI為標準，外部以Unicode為標準。這樣，既滿足了相容，又兼顧了前瞻性，可謂一箭雙鵰。

但隨著Win9x的徹底消亡，VB6又遭受微軟戰略轉型而退居二線，未能得到官方更新。當時的完美策略，終於成了畫蛇添足，多此一舉了。

4、所以，

在VB/VBA內部(編譯器層面)，會將字串視為Unicode，並自動轉換為ANSI。

然後呼叫A版函式，結果再自動轉換為Unicode，

這簡直就是為A版量身定做的。

對於使用者而言，進去的是Unicode，出來的也是Unicode，感覺就是基於Unicode的一樣。想想，如果使用W版函式會怎樣？W版函式接收到的資料是ANSI編碼的，但W版函式自己不會轉換，此時相當於更改了資料，然後結果再轉換為Unicode，保準亂碼了（不信可以試一試哦）。

5、

官方宣佈不再更新VB6已是2008年，為何10年之久，都不更新呢？

因為VB/VBA是夠用的，不需要改啊！

儘管給VB/VBA參考的API宣告就是預設A版，但也可以用W版呀，所以更不用擔心不被支援了。

從上可以看出，

A版呼叫的其實就是W版的程式碼，但在VB/VBA的固有制約下，反而A版更匹配。無論怎樣，W版效率高是不爭的事實。

VB/VBA要如何呼叫W版的API呢？

支援關注BtOfficer

，將專題為你奉獻哦。