VB 程式字型字型大小的修改（合篇）

VB 程式字型字型大小的修改（合篇） 點睛工作室--梁利鋒

聲明 個人可以自由轉載本文，不過應保持原文的完整性，並通知我；商業轉載先請和我聯絡。 本文沒有任何明確或不明確地提示說本文完全正確，閱讀和使用本文的內容是您自己的選擇，本人不負任何責任。 如果您發現本文有錯漏的地方，請您給我指出；如果有什麼不理解的，請您給我提出。 意見、建議和提出的問題最好寫在我的首頁 http://llf.126.com 的留言版上。 （阿濤按：本文由梁利鋒兄的四篇VB文章整合而成，並附加了梁利鋒兄其它相關文章的摘選，本文保留了原文的所有內容和敘述順序） 第一篇：初論 VB 程式字型字型大小的修改 (2000.05.15) 字型字型大小的問題 以前“偉乾”問為什麼修改 VB 的可執行檔的字型後，程式啟動會出錯，我於是也做了測試，也修改了一個可執行檔的字型，也同樣滿懷希望的運行，也同樣出錯了，我不知道為什麼，於是就放下了。 不過我一直納悶，它的出錯提示很奇怪，是“無效檔案格式”，最近仔細想一想，所謂“無效檔案格式”想必是因為 VB 把整個表單的資料當作一個檔案傳送給了 VB 的運行庫 “Msvbvm50.dll”（或 Msvbvm60.dll），而一般我們漢化檔案的時候修改字型名總會比原字型名短，比如在美國程式中比較常用的“MS Sans Serif”，佔用 13個位元組，中文軟體常用的是“宋體”，佔用四個位元組，從這一方面來說，本不應該出現問題，但是最終出現問題了，除非字型也是作為一個整體處理的，當然，字型確實是一個整體：

BeginProperty Font Name = "宋體" Size = 9 Charset = 134 Weight = 400 Underline = 0 'False Italic = 0 'False Strikethrough = 0 'False EndProperty

好的，首先應該知道 Size = 9 並不一定表明可執行檔中的也是“09”，如果大家用過 Win32pad的話，在 Windows 的目錄下會有一個Win32pad.ini，開啟它可以知道，當我們選擇“宋體,9”的時候，Size其實是 180 ，但是 VB 中是否使用的也是 180 呢？也不一定，不過我們先對以上的數字進行一下到十六進位的轉換：字型大小 9 可能是“09”，也可能是“B4”；Charset是語系，一般的一種字型只有一種語系，比如“宋體”的語系就是 “GB_2312”，也就是 134 ，十六進位數是“86”；Weight 應該是字寬，不太清楚，不過也進行轉換，400 就是“90 01”，然後我們就可以進行可執行檔的尋找和編輯了。 因為是一個整體，所以其它的資訊既可能在字型名的前面，也可能在字型名後面，在例子檔案中同一個檔案都有兩個字型塊，一個是表單的，一個是標籤 （Label）的，所以可以比較一下，具體的比較很乏味，有興趣可以自行進行，我在這裡只簡單的說一下，才開始我以為資料應該在字型名後面，我錯了，後來我以為資料只在字型名前面，我又錯了，最終的結論是：在字型名之前的 10 個位元組（或 11 個位元組，因為向前第 11 個位元組都相同，但是看不出有什麼用）和字型名之後的 1 個位元組和字型名共同組成了字型塊。 所以要把字型字型大小改成“宋體,9”的話，需要把現成的有“宋體,9”的檔案中的字型塊複製到要修改的檔案中。在例子檔案中，英文字型塊的十六進位如下“00 00 00 90 01 44 42 01 00 0D …… FF”，其中“……”表示字型名，從這裡我們見到了“90 01”（Weight），其它的倒也不知道是什麼意思；中文字型塊的十六進位如下“86 00 00 90 01 90 5F 01 00 04 …… FF” ，從這裡，我們不僅僅見到了“90 01”，還見到了“86”（Charset），這也是我判斷字型塊大小的重要依據。最後要做的就是替換了，這一步比較簡單，不過有一點需要注意，最後的結尾的字元不一定是“FF”，在我的例子檔案中也有“46”的，其它的程式中應該也是這兩種，但如果不是也不奇怪，只要把原字型名之後的一個位元組複製到修改後的字型名之後就可以了。至於在字型塊中哪一個位元組是字型大小我不知道，不過只要全部複製，顯示出來的就是“宋體,9”了。當然，如果想要和原字型一樣的顯示加粗，斜體，底線的話，就需要對其中的位元組進行比較判斷，應該不會太難，各位可以自己試一下。（我推測“FF”可能是整個表單的結束標誌，不過沒有證據） 具體的圖例我就不給出了，各位可以參見並比較例子檔案，應該會收到更好的效果。

第二篇：再論 VB 程式字型字型大小的修改 (2000.05.19) 延續的戰爭 這兩天，又繼續研究了一下 VB 可執行檔中的字型塊的結構，現在基本上可以確定，字型塊是由字型名和它前面的十二個位元組所組成，本文主要介紹結果，具體過程略去，如對過程有興趣，可以和我聯絡。 本文有與之配合的例子程式，在這個例子程式中，包含了全部有“Font”屬性的非 ActiveX控制項，同時，這個例子程式使用了我所有的英文字型，在閱讀完本文之後，應該看一下這個例子，並且親自修改一下試試。 字型塊的研究 第一個位元組表示此字型塊所屬的控制項類型，已知的控制項類型如下（其中的數字均為十六進位）：

Frame = 1BOption = 1DCommand = 1DDrive = 1EDir = 1FCheck = 20Data = 21Label = 25Combo = 26List = 27File = 29Text = 2EPicture = 39Form = 40

第二個位元組的意義未知，在現在所能找到的字型塊中它的值均為“01”，也可能是和第一個位元組共同構成一個雙位元組整數。 第三個位元組代表“語系”，也就是“Charset”，英文為“00”，簡體中文為“86”。 第四個位元組的意義未知，在現在所能找到的字型塊中它的值均為“00”，不過應該和上一個位元組沒有關係，可能是保留區。 第五個位元組是標誌位元組，用來指示字型的風格，分別是“斜體”、“底線”、“刪除線”，其中“斜體=02”，“底線=04”，“刪除線=08”，可以複選，比如要同時有“刪除線”和“底線”，則此位元組為“08+04=0C”。 第六、七這兩個位元組共同組成一個雙位元組整數，表示字型的“粗體因素”（Weight），一般的值為 400 或 700 ，分別表示正常和粗體，但在字型“Bookman Old Style”中也有可能是300，所以這兩個位元組的值是“90 01”（400），“BC 02”（700）或“2C 01”（300）。關於“粗體因素”，VB 的協助裡是這麼說的：

返回或設定組成 Font 對象的字元的權重。權重指的是字元的寬度，或“粗體因素”。值越大，字元越粗。 Font對象在設計時不能直接使用。取而代之的是，在“屬性”視窗中通過選擇控制項的Font屬性並單擊“屬性”按鈕來設定Weight屬性。可以通過從“字型”對話方塊的“字形”框中選擇一個項來隱含地設定 Weight 屬性。正常和斜體設定值的 Weight 值是 400（預設值），而粗體和斜粗體設定值的 Weight 值是 700。然而在運行時，通過為 Font 對象指定 Weight 屬性值可直接設定 Weight。 如果在運行時將 Font 對象的 Weight 設定為不同於 400 或 700 的值，那麼 Visual Basic將把這個值轉換為 400 或 700，這取決於哪個值與設定的值更接近。精確的範圍為：Weight > 400 並且 < 551 則轉換為 400；Weight > 550 則轉換為 700。

第八、九、十、十一位元組共同組成一個四位元組整數，表示字型的大小，它的值是具體設定的 10000 倍，比如 9 ，在這裡就是 90000，相應的這四個位元組就是“90 5F 01 00”。 第十二個位元組表示字型名的長度，比如字型名是“Courier New”，則此位元組就是“0B”。由此也可知道，字型名不能長於 255個位元組。 後面所有的位元組是字型名。 字型塊的修改 通過以上的介紹應該對字型塊的修改有一個大致的瞭解了，我說一下具體的問題。 在漢化中，第三個位元組是需要修改的，把原來的“00”改成“86”，另外字型的大小是需要修改的，一般是把“80 38 01 00”（8）改為“90 5F 01 00”（9），字型名可以不修改，不過對於“Fixedsys”、“System”或者中文字型來說，如果希望顯示為“宋體”，就需要修改字型名，不過因為字型塊和其它部分共同構成了表單的結構，所以不適合於修改字型名的長度，可以把原字型名改成一個不存在的字型名，這樣，系統會自動使用“宋體”來顯示（事實上是使用預設字型來顯示），可以把字型名的所有位元組都改成空格，這樣可以保證不會重名。其它的位元組，不止不需要修改，而且不應該修改，慎之！ 限制 修改字型塊確實可以改變字型，不過有些情況就無效了。 首先，如果可執行檔中沒有字型塊，這種方法就不適用了；另外，如果是主表單中的一個控制項有字型塊，而主表單沒有字型塊的話，則只能修改那一個控制項的字型。 還有，如果程式是在運行時動態地修改字型，這種方法也不適用。 最後，可能是因為英文版的原因吧，像 Vopt99 這樣的程式雖然表單沒有字型塊，但是顯示的字型大小卻是 8 （本來應該是 9 的），這種情況目前也沒有辦法。 （修改 Vopt99 的字型塊後，Splash表單的字型正常；主表單下方的磁碟檔案分布圖字型正常；上排第三個圖框的字型可以修改，不過顯示有重影，盡量不要修改；上排第四個圖框上方的 Label的字型正常；其它的部分的字型都不正常。有兩種可能，一是因為它在運行時動態地修改字型，二是因為某處有英文版的標記，我傾向於認為是第二種情況） 展望 經過幾天的考慮，我覺得字型塊和其它的部分一起組成了表單塊，而這個表單塊和 Delphi 的 RCDATA 是類似的，也就是說，如果我們可以知道表單塊每一部分的含義，則可以像現在修改 Delphi 的資源一樣的修改 VB 的資源，不過目前考慮，即使清楚的知道了表單塊的含義，一樣有一個限制，這就是修改後的表單塊的大小需要小於原表單塊，這一點上，VB 資源的編輯不會有 Delphi 那樣使用 Windows 資源格式的靈活性，除此之外，應該是都相同的。

第三篇：還是字型塊 (2000.05.24) 向前進 接著上一次的展望，這兩天又再窺竊了一些 VB 表單塊的秘密。不像字型塊，表單塊的結構太龐大，非一人一時所能研究得透的，只能把目前的一些結果說一下，也希望能有更多的人蔘與到這個行列裡來，共同研究這個項目。 正像我上一次所說，首先可以確定表單塊確實存在，而所以把它稱為表單塊，就是說 VB 程式在載入表單的時候其實只用到了一個指向表單塊的指標，而表單究竟怎麼顯示和顯示什麼取決於表單塊的結構。換句話說，VB顯示表單和控制項是基於分析表單塊的結構，而並不像我們以前所想象的是分別編譯的。 VB程式的一般包含表單和模組，而編譯的時候也是這樣，所以也可以說，編譯出來的可執行檔也有表單和模組，只不過可能界限比較模糊。不過，我們還是可以找出一個 VB 可執行檔的項目中究竟有哪些表單和模組。不過，我對於此目前並沒有太好的辦法，幾乎只是靠經驗判斷，只有一條很不準確的判斷方法：VB 的“工程名”、“表單名”和“模組名”是放在一起的，其間用不定個數的“00”隔開。 另外一方面，作為表單塊，在它的“表單名”之前的 11 個位元組也可以作為一種判斷的方法（其實不止 11 個位元組）。這 11 個位元組，前四個位元組組成一個長整數，表示從此到整個表單塊的結尾的大小；然後的四個位元組組成的長整數表示表單本身的大小；最後的三個位元組的意義未知。不知道我是否講明白了，具體說，表單本身的大小 + 表單上控制項的大小 = 整個表單塊的大小。 剛才說“其實不止 11 個位元組”，因為在這 11 個位元組之前有大量的“00”也可以作為判斷的標誌，而且在這些“00”之前還有很多位元組也是屬於表單塊的，而且其中有很多項是相同的，作為標誌更為合適。 再回首 再進一步研究之前，我想停下來看看我們現在知道的東西是否已經可以派上用場了。 首先，一個表單塊很大，其中包括了此表單上的控制項；另外，表單塊是作為一個整體而存在的，其中的任何一部分都不是單獨存在的。 回憶一下我上篇文章裡所說的限制，“如果主表單中的一個控制項有字型塊，而主表單沒有字型塊的話，則只能修改那一個控制項的字型”，如果表單塊是作為一個整體存在的，我們能不能把控制項的字型塊移動到主表單上呢？ 能！ 移花接木 以 Vopt99 4.15 為例。在這裡我用的是“Weiping”漢化的版本，上次說過，修改字型塊後，主表單因為沒有字型塊顯示不正常，主表單下方的“圖例”框的字型顯示正常，所以就拿它開刀。 首先，用我剛才說的那種“不確定法”得知 Vopt99 包含一個工程“Vopt99”，三個模組“NTVoptB”、“NTVopt2B”和“NTVoptM”，另外就是五個表單“NTVoptHex”、“NTVoptF”、“Xclean”、“Settings”和“Splash”。進一步可以判斷主表單是“NTVoptF”。 現在找到“圖例”框的字型塊，因為“圖例”框是一個“PictureBox”（通過 Spy++取得其“類名”，就可以知道，此法還可判斷程式是否 VB 編的），所以我們先用 UEdit 開啟 Vopt99.exe ，然後尋找“39 01 00 00 00 90 01”，第一個查到的字型塊位於“PicHistoF”控制項塊中，並不是我們要找的；第二個字型塊位於“picMap”中，也不是我們所要找的；然後找到第三個字型塊，真奇怪，它居然就位於“圖例”中，如果這是我編的程式那就不足為奇了，但不是，所以這是漢化的結果，不過卻是錯的，因為此處的名稱並不顯示，而是作為“Name”屬性儲存的，如果程式中用到了“Name”屬性，這樣的翻譯將會導致錯誤，所以我們先將其改回“legend”。（關於哪一個字型塊是需要找的，我做了測試，並非一次就判斷對了的） 現在，我們找到字型塊的開頭，選中字型塊，因為是 “Arial”，所以共有 17 個位元組，按“Ctrl+X”剪下。然後，可以見到在控制項名前第 7 個位元組開始的一個長整數表示此控制項塊的大小，原值“40 00 00 00”，減小 11h，所以修改成“2F 00 00 00”。 按“Ctrl+Home”回到檔案頂部，再次尋找字串 “NTVoptF”，一次找到，因為總體大小保持不變，所以第一個長整數“C9 76 00 00”不需要變化，而第二個長整數“5A 03 00 00”就需要修改了，增加 11h ，所以修改成“6B 03 00 00”。 在表單名“NTVoptF”的下一行有一個“Vopt99”，這是表單的“Caption”，然後下面有一屏多的亂七八糟的東西，這是表單的表徵圖，把它翻過去，在一串“00”之後有一個“Form1”，這是表單的“LinkTopic”，和 DDE 有關，一般程式現在都不使用 DDE ，所以一般也沒有什麼用處，程式員很少關心，VB 編輯器會自動產生類似“FormN”這樣的“LinkTopic”，所以也可以作為一個判斷標誌使用。 再下去兩行，有“46 02 49 01 FF”，把游標停在“46”的“4”上，檢查 UEdit 在“插入模式”按“Ctrl+V”粘貼。（為什麼在“46”之前呢？我不知道，我是經過好幾次測試了的。反正有什麼不知道的，試一試！） 最後修改字型塊。因為是 PictureBox，所以原字型塊以“39”開頭，現在是表單了，所以把“39”改成“40”，再把語系（Charset）改成“86”，然後把字型大小改成 9 ，也就是“90 5F 01 00”，然後把字型名都改成空格。存檔。 運行，可以看到，主表單的字型已經被修改成“宋體,9”了。 （“Settings”表單是 Vopt99 中另一個重要的表單，關於對話方塊和所有的設定對話方塊都是它，但是因為“Settings”雖然大，但是在其中卻沒有一個控制項有字型塊，所以不能作這樣的修改，而增加字型塊至少需要12個位元組，把“LinkTopic”改成空也只能增加 5 個位元組，還有 7 個位元組沒有著落，所以目前不能修改。以後可以通過把翻譯空餘的位元組累加到表單上來實現增加字型塊。）

第四篇：突出重圍 (2000.05.29) 無中生有 上次說過，關於 “Settings”表單，可以使用增加字型塊的方法更改字型，“Weiping”也來問：“究竟加在哪裡呢？”。我想先澄清一下，關鍵不是字型塊“加在哪裡”，而是從其它地方刪除位元組之後，應該修改的字串計數器和控制項塊計數器都有哪些？都在哪裡？ 好的，就以“Settings”表單為例。這一次使用上一次修改後的檔案，所以所說的位移量也以此為準。 用 UEdit開啟 Vopt99.exe 。跳到位移量“12480h”處（為簡單起見，尋找過程略），我們見到，這裡就是“Settings”表單名所在的地方了，不過這個表單沒有表徵圖，也沒有“Caption”（VB中所有希望沒有標題列的表單必須沒有“Caption”），所以下一行可辨認的就是“LinkTopic”，也就是“Form1”。不過我們先把這些放下，因為我們還沒有空間加入字型塊呢。 再下去兩行，可以見到 “Frame1”，然後下一行是這個幀的“Caption”，在這裡是“顯示參數設定”，共 12 個位元組，但是“顯示參數設定”之前的兩個位元組是“13 00”，也就是十進位的 19 ，所以這裡可以給我們提供 19 - 12 = 7 個位元組。選中“顯示參數設定”之後的 7 個位元組的“00”，按“Ctrl+X”剪下（UEdit在此情況下的刪除是沒有作用的），然後把“13 00”改成“0C 00”，向上一行，可以見到“FF”之後的“01 3F 00 00”，在這裡，“FF”是上一個“塊”的結尾標誌，從“01”開始就是這個控制項的地盤了，而“3F 00”是這個控制項從“3F”開始的大小，所以減少 7 ，改成“38 00”。現在我們已經得到 7 個位元組了。 再往下走在“12589h”處，可以見到“DisplayCheck”，然後是它的標題（Caption）“隱藏大檔案名稱單”，共 14個位元組，之前的“字串計數器”是“14 00”，就是20，所以在此我們又可以得到 20 - 14 = 6 個位元組。類似上例，剪下後面的 6 個“00”，修改“14 00”為“0E 00”，找到此“塊”的開頭“1257fh”處，把下兩個位元組“3F 00”減少 6，改成“39 00”。現在，我們又有了 6 個位元組，一共得到了 13 個位元組，已經可以開始插入字型塊了。 現在就要考慮字型塊插在哪裡的問題了。還是像上一次那樣加在“46”之前試一下吧。 到“12479h”處，上一次說過，這裡的數值是表單本身的大小，現在是“43 00 00 00”，增加 13 個位元組，就是“50 00 00 00”，修改它。現在先找到表單的結尾，計算 12479h + 43h = 124bch，跳到“124bch”處，向前的三個位元組是“46 03 FF”，就插在“46”前面好了。隨便複製 13 個位元組，並以“插入”模式加入“46”之前，然後把它們改成“40 01 86 00 00 90 01 90 5F 01 00 01 20”存檔。 好的，現在運行，選菜單的“關於”，出現了什麼呢？“無效檔案格式”錯！ 沒有關係，我們把字型塊前移一個位元組，再存檔，再運行，再次“無效檔案格式”錯。That's all right ，again，再前移一個位元組，再存檔，再運行，如何？ —— Enjoy it！ 變本加厲 是否從剛才偷取字型塊所需的空間的時候，就開始想要為一些因空間問題而未能漢化的標題之類的做打算了？很好，我們開始。 還是 Vopt99 。在“顯示參數設定”後面，有三個按鈕，“協助”、“取消”和 …… “OK”，就是“OK”，讓我們繼續。 “取消”的英文是“Cancel”，共 6 個位元組，而“取消”只需 4 個位元組，可以省出 2 個位元組，正好能送給“OK”。 跳到“12547h”，這裡是“取消”的字串計數器，把它從“06 00”改成“04 00”，並且把原來翻譯時加在兩邊的空格剪下掉，然後把“12531h”處的“塊計數器”減 2 ，改成“2D 00”。 跳到“12577h”，在“OK”前插入 2 個位元組，並把這四個位元組改成“確定”，把它前面的計數器改成“04 00”，並把“1255fh”處“塊計數器”改成“2D 00”，存檔。 好的，運行，進入“顯示參數設定”方式，看到了嗎？原來的“OK”已經被改成了“確定”。 （有時候，某些計數器不修改也能運行，但是一定要保持修改計數器的習慣，這是保證程式正常啟動並執行首要條件，並且，這種累積的錯誤很有可能造成無法挽回的後果，一定要注意！） 成長的煩惱 剛才，進入“顯示參數設定”方式時，除了看到“OK”已經被改成了“確定”，還看到了什麼呢？對了，那個“CheckBox”的標題“隱藏檔案分布情況圖”因為字型的加大，由一行變成了兩行，並且這兩行都沒有完全顯示出來，這樣的結果可是不行，可說是過猶不及了。 怎麼辦呢？當然是修改控制項的寬度了。 跳到“125c7h”處，這裡是“隱藏檔案分布情況圖”所在控制項“塊計數器”的位置，它的值是“3F 00”，所以125c7h + 3fh = 12606h，然後又跳到“12606h”處，“FF” 就是它的結尾標記，再向前 12 個位元組，從此開始的 8 個位元組是這個“CheckBox”的位置資訊，目前是“F0 00 D0 02 08 07 C3 00”，每 2 個位元組組成的數依次是它的“Left”、“Top”、“Width”和“Height”，我們所需要修改的是“Width”，就是“08 07”，十進位是“1800”，把它改成“2000”，就是“D0 07”，現在，修改，存檔。 現在，再次運行，進入“顯示參數設定”方式，不錯吧？繼續把其它的也修改了就可以了。 （注意，這裡我沒有列出所有控制項的位置資訊的位置，因為尋找起來比較費事，但是如果使用 WinHEX 的話，因為它能顯示當前游標所在的 1 位元組、2 位元組和 4 位元組的十進位整數的大小，會很有協助。） 異域採風 昨天，見到一個所謂的 VB5 線上反編譯的網站，URL 是 http://www.support.ems.ru/%7Egold/vb5/index.html，試了一下，並不能真的反編譯，為了看別人的原始碼的人就不必去了，但是它能把表單的資訊“反編譯”出來，對於漢化人來說，夫複何求呢？！ 這個網站在格林威治時間 18 點到淩晨 3 點或星期天全天可以提供 1MB 以下的反編譯，其它時間只能有 50KB 而已，所以北京時間淩晨 2 點到中午 11 點之間再去吧。（可以先用 Zip 打包） 看來，在我之前已經有人在研究這個問題了，只不過他把這種工作定位在“反編譯”上，最終卻只能“反編譯”一些表單出來，可能是很失望了，所以從 98 年到現在都沒有更新過。（而且不支援中文，不過做漢化，要反編譯的自然是英文軟體了） 雖然不能真的把它反編譯出來的程式再編譯成正常的可執行檔，但是卻可以提供我們很多的資訊，比如哪些字串是需要翻譯的，哪些不能翻譯，哪一個控制項的位置資訊是多少等等。（真想得到它的原始碼，那樣我就不需要再研究表單塊的結構了。:） （今天[5.29]得知經常說的 VB5 的反編譯器 vb4tools確實可以反編譯出表單資訊和組合語言的函數，不過僅僅對於極其簡單的程式有效，稍微複雜的程式，在反編譯的過程中會出錯退出，以至於無功而返，希望上面的線上反編譯不要出現這種問題） 最終幻想 剛才說不能重新編譯，其實也不是完全不可重新編譯，雖然沒有代碼，我們一樣可以使用VB的可視化環境編輯這些表單（真的很棒！），修改字型，修改標題，修改位置，然後重新編譯，雖然所得的這個程式並不是我們想要的，但是我們可以把其中的表單塊複製出來，替換原程式的表單塊。不過有一點需要注意，這樣得到的表單塊一般總是和原表單塊不一樣大的。如果大於原來，則需要修改原始碼，使之減小，再重新編譯；如果小於原來，需要在表單塊的某些地方增加一些位元組，使之和原表單塊一樣大，然後再進行替換。所幸增加位元組還是很容易做到的。:) 而且既然表單可以被反編譯出來，那麼製作 VB 的“終極漢化工具”也不是很困難的事情，所有的問題都只是工作量而已。 好的，現在我來總結一下。 VB 中有兩種資源形式。一種就是我們在這裡所說的“表單塊”，因為所有的的 ASCII 字串都是存在於“表單塊”之中的，所以不存在“ASCII 字串”資源；另外一種就是 UniCode 字串，使用我編的“字串替換器”可以找到所有的這種 UniCode 字串（指的是 VB 格式的 UniCode 字串，VB的可執行檔中也有一些不是 VB 格式的 UniCode 字串，但是這些字串並不顯示，不需要翻譯，所以我的“字串替換器”並不提取這種 UniCode 字串，即使 “無限制尋找”的時候也不提取。）。都可以進行翻譯，表單塊裡的字串可以改變長度，但是 UniCode 字串的修改不能長於原字串。 （VB 程式也可以使用標準的 Windows 格式的資源 —— 也就是通常所說的 VC 格式的資源 —— 不過因為 VB 使用 Dialog 之類的資源得不償失，所以即使使用，也不會有 Dialog、Menu、Accelerator之類的資源，而只會有 String 或 BitMap 之類的資源，可以使用標準的資源編輯器進行漢化，但是因為 VB 本身並不能編輯這種資源，所以一般是使用 VC 編輯並編譯再連結到 VB 程式中的。我不認為這種資源屬於 VB 資源） 至此，我想關於字型塊的問題已經完全結束；另外，也可以說我已經解決了所有 VB 基礎漢化（使用這些技巧已經可以完美漢化 95%以上的 VB 程式，如果想要完美漢化另外的 5% ，我想可能是需要有一定的編程經驗了）中的疑難問題，所以如果不出意外的話，這一篇文章不只是我字型研究的結束，也同樣是我關於 VB 漢化的終結篇。 （另外，今天[5.29]得知，新起點漢化工作室的阿濤也研究了 VB 字型的修改，並且有一種我沒有發現的修改字型的方法，建議作 VB 漢化的同志們也看一看。）

附加篇：漢化中的幾個問題（VB 部分） (2000.07.16) 怎樣判斷 VB 編寫的程式 在偉乾和 YY 寫的關於 VB 漢化探討的文章裡曾介紹過怎樣判斷 VB 編寫的程式，其中使用的是軟體 FileInfo。 FileInfo可以用來判斷程式的很多資訊，包括使用什麼方法壓縮、加密，基地址，各段及其位移量等，當然也可以用來判斷程式是用哪一種編譯器編譯的，確實不錯。 最近用了 YY 漢化的 Chime Tray Play，打眼一看我就覺得是用 VB 編寫的，但是表單的字型都很小，我就比較奇怪，按說我已經寫了四篇文章說這個問題，而且阿濤也寫了一篇文章，修改 VB 程式的字型應該不成問題，為什麼沒有修改呢？所以我就使用 FileInfo 查看了一下原程式，發現 FileInfo 報告說這是一個 Windows GUI 程式，並沒有說是 VB 程式，那麼它究竟是不是 VB 程式呢？ Chime Tray Play 的原程式只有一個檔案“TrayPlay.exe”，用 FileInfo 可以知道這個程式使用 NeoLite 2 壓縮，所以使用 ProcDump 進行解壓縮，使用 FileInfo 檢測解壓縮後的程式就會發現被報告成 Windows GUI 程式。不過還是可以使用其它的方法檢測一下的。 運行 eXeScope，開啟解壓縮後的“TrayPlay.exe”，開啟“Import”，這裡是程式的函數匯入表，如果是 VB5 編寫的程式，其中會包含 MSVBVM50.DLL ，如果是 VB6 編寫的程式，其中會包含 MSVBVM60.DLL ，而且因為是 VB 專用的運行庫，其調用格式並未公布，所以基本可以肯定，只要使用了 MSVBVM50.DLL 的程式一定是 VB5 編寫的，而使用了 MSVBVM60.DLL 的程式一定是 VB6 編寫的。而且大部分的VB程式只匯入這一個動態連結程式庫，其它的 API 呼叫使用“Declare”來定義，並不使用匯入表，包括 Vopt99 也是這樣。（我的程式一般會多出一兩個庫，這是使用類型庫的結果，不過不會很多）而“TrayPlay.exe”正好有且只有一個 MSVBVM60.DLL 的匯入，基本可以肯定是 VB6 編寫的。（VB4 使用 VBRUN40.DLL ，VB3 使用 VBRUN30.DLL ，不過這些程式中讓人有興趣漢化的就非常少了） 另一種方法。運行一個 VB 編寫的程式，等它的主介面出來以後，使用 Spy++（VC中附帶的軟體）的尋找視窗模式，拖動其中的靶子表徵圖到目標程式的介面上，注意其中的“Class”項的值，若是 ThunderRT5xxxx，就說明是用 VB5 編寫的程式，如果是 ThunderRT6xxxx，就說明是VB6寫的程式，其中最後的 xxxx 表示不同的控制項，比如 VB5 編寫的程式中的 ListBox 的“Class”項就是 ThunderRT5ListBox，而 VB6 編寫的程式中的 TextBox 的“Class”項就是 ThunderRT6TextBox 。作為“TrayPlay.exe”有一些不太方便使用這種方法，因為如果選擇其它的程式的話，其主表單會自動隱藏，使之不容易檢測，不過可以先選擇“關聯”按鈕，出現訊息框，這時就可以切換到其它的程式而它並不消失，也就可以檢測，結果也同樣發現是 VB6 寫的。（使用我編寫的“刺客”程式也可以進行這種檢測，雖然比起Spy++來說功能不強大，但是對於這種任務來說反而方便不少。在“刺客”中，“類名”就是“Class”） 還有一種方法。在阿濤的關於 VB 漢化的文章裡說過，只要在 VB5/6 的程式中尋找 “VB5!”就可以找到需要複製那22個位元組的位置，因為其中只會有一個 “VB5!”。如果連 VB 編寫的程式中也只有一個“VB5!”的話，那麼其它程式有“VB5!”的可能性就幾乎為 0 了，不是嗎？:) 需要注意的是，這並不是說 FileInfo 的檢測不準確，這裡的問題其實是 ProcDump 引起的，想必它在解壓縮的時候改變了檔案的某些結構，從而使 FileInfo 出現了不能正確檢測的後果，所以，如果有專用的解壓縮程式的話，盡量不要使用 ProcDump 這種通用解壓縮的程式。（現在很多程式使用 ASPack 2.1 壓縮，ProcDump 解壓此種檔案並不好，甚至使用了漢化新世紀提供的新的 INI 檔案也同樣不是很好，而 UnAspack 1.091 已經可以解壓縮這種檔案，應該盡量使用 UnAspack 1.091 來解壓縮 ASPack 2.1 壓縮的檔案。） 修改 VB 程式的字型大小 關於 VB 程式的字型大小我已經有文章說過了，不過還是覺得阿濤的最後對於無字型塊的程式的修改法更好，所以也學他的方法修改了此檔案“TrayPlay.exe”，結果程式不能運行了，真是奇怪。 阿濤的原文說複製 22 個位元組，而其中的圖顯示的卻是 44 個位元組，不過這是小問題，問題在於究竟複製的這些多位元組有什麼用處呢？ 我不知道它有什麼用處，所以進一步測試，發現根本不需要複製這些位元組，而只需要加入“vb5chs.dll”這個字串就可以了。 在“TrayPlay.exe”檔案中尋找 “VB5!”，找到後，再向後的第三個位元組是“*”，十六進位是“2A”，後面是一大串“00”，只要把從這個“*”開始的地方修改“vb5chs.dll”，程式就可以正常顯示“宋體,9”了。 對於 VB6 編寫的程式，一般的可以改成“vb6chs.dll”，不過即使改成 “vb5chs.dll”也沒問題，同樣能讓程式正常顯示“宋體,9”，因為不管是 vb5chs.dll 還是 vb6chs.dll 都不是代碼所在的地方，它們只是提供一些資源罷了，即使沒有這些資源，程式也一樣能照常運行。 著作權符號的問題 這不是 VB 的問題，而是所有英文軟體的問題，不過這裡也使用一個 VB 程式作例子。 開啟 Vopt99 ，選擇菜單“協助->關於 Vopt99”，可以看到第一行資訊是“Copyright ? Golden Bow System”，很奇怪的是其中有一個“?”，難道作者對於著作權的資訊本身有疑問嗎？當然不是，其實這裡是的“?”是著作權符號 ，因為使用的是大於 7F 的 ASCII（具體說就是 A9），其編碼和 GBK 有衝突，而 Windows 的轉換函式在轉換過程中如果發現非法的字元就會把它轉換成“?”，所以這個著作權符號就成了“?”。因為 GBK的編碼中沒有著作權符號，所以很不方便，很多程式使用“(C)”來代替，是一個不錯的選擇，漢化時也應該如此，而不是把“?”留在那裡或者乾脆真的轉成“?”。類似的情況可能還有註冊商標符號 (AE) 也同樣需要注意。 對於大多數的 C 程式來說，因為是 ASCII，所以如果一個字串如“Copyright Golden Bow System”的話，因為 是非法字元，所以很多尋找 ASCII 的程式會尋找不到這個字串，而我的字串替換器也不例外，查到的字串將是“ Golden Bow System”。 對於 VB 程式來說，可能是 ASCII ，也可能是 UniCode ，具體取決於作者是使用在 IDE 裡設定屬性的方法（ASCII），還是使用在程式中賦值的方法（UniCode）。在這裡，Vopt99使用的是 UniCode ，而且分成兩部分，“Copyright ”和“Golden Bow System”，這是因為“Golden Bow System”是從資源的版本資訊中取得的。因為“Copyright ”中的非法字元在最後，所以使用我的字串替換器不管使用尋找 VB 字串還是尋找 UniCode都不能尋找到這個字串，只有使用尋找 VB 字串的“非限制尋找”模式才能找到。（“非限制尋找”模式會有很多非法字元，而很多對照項會有很多的“?”也正是因為這個原因，並非原來就是“?”。） 對於 ASCII 來說，因為我的字串替換器不提供“非限制尋找”模式，所以不能正常尋找到，只能使用手工尋找修改的方法。 當然，很多 C 程式的著作權資訊在資源裡，所以使用普通的資源修改器（比如 eXeScope、ResHacker 等）就可以找到並修改，而不需要這麼麻煩。但是修改是需要的，千萬不要讓大家以為所用的軟體的著作權都是有疑問的。 可能在 NT/2000 下使用 UniCode 模式的著作權符號可以正常顯示，不過這需要確實是全都是使用的 UniCode 的函數，VB在 NT/2000 下好像用的是先把 UniCode 轉換成 ASCII ，然後再由 Windows 轉換成為 UniCode 的方法，所以仍然不能正常顯示。不過我沒有在 NT/2000 上驗證過。