安全程序設(shè)計：06 國際化安全

1、第六章國際化安全 國際化(internationalization)，是為了保證軟件產(chǎn)品適應不同區(qū)域語言要求的一種方式由于英文單詞 internationalization的首末字符i和n之間的字符數(shù)為18，因此業(yè)界內(nèi)常把I18N作為“國際化”的簡稱以WEB應用為例，隨著經(jīng)濟的發(fā)展，全球經(jīng)濟一體化已經(jīng)慢慢成為一種主流趨勢，WEB應用要求必須能夠支持多國語言對于同一個WEB應用，在不同的語言環(huán)境下需要顯示不同的效果，來方便用戶我們經(jīng)?？吹?，一些網(wǎng)站都有各個不同的語言版本，在運行時，能夠根據(jù)客戶瀏覽器所在的國家和語言的不同，顯示不同的用戶界面軟件支持多種不同的語言，絕不是開發(fā)了軟件的多個版本業(yè)界具

2、有一定的規(guī)則讓信息進行復用，即對同樣信息進行各種代碼的轉(zhuǎn)換。這樣可以使得當需要在應用程序中添加對一種新的語言的支持時，不需要重新再開發(fā)一個軟件，造成重復勞動。而安全問題就存在于代碼轉(zhuǎn)換的過程之中本章主要針對國際化過程中的安全問題，首先介紹常見的國際化過程，然后介紹國際化轉(zhuǎn)碼中需要注意的安全問題6.1 國際化的基本機制隨著經(jīng)濟全球化的發(fā)展，軟件也應該具有支持各種語言和地區(qū)的能力。國際化的主要目的，是調(diào)整軟件，使之能適用于不同的語言及地區(qū)。如圖所示是一個表單在中國和美國的兩個顯示效果。從以上界面上看出，兩個頁面功能相同，但是在不同的地區(qū)，為了照顧不同的用戶，顯示界面不同，這就需要在開發(fā)的過程中充分

3、考慮國際化問題與國際化類似的另一個概念是本地化(localization)。在業(yè)界內(nèi)，兩個概念一般一起講，有時候甚至被等同起來。不過，從概念上說，本地化是實現(xiàn)國際化的一些手段的集合國際化的概念，比較偏向表達軟件的設(shè)計思想，要求當軟件被移植到不同的語言及地區(qū)時，軟件的業(yè)務邏輯和程序源代碼不用作改變或修正，但是軟件又必須讓該地區(qū)和語言的用戶方便地使用本地化的概念偏向?qū)浖M行加工，使之滿足特定地區(qū)和特定語言的用戶對語言和功能的特殊要求，實際上是指一系列工作的過程軟件本地化工作，可能涉及文字的翻譯、用戶界面布局調(diào)整、本地特性開發(fā)、聯(lián)機文檔和印刷手冊的制作，以及保證本地化版本能正常工作等，實際上也算是

4、軟件質(zhì)量保證活動的一部分國際化簡稱為I18N，本地化由于其單詞localization的L和N之間有10個字母，因此也被簡稱為L10N國際化和本地化這兩個工作，一個是設(shè)計思想，一個是工作的手段，相輔相成，互為補充在有些企業(yè)中，也使用全球化(globalization)來表示國際化和本地化的合稱，使用 G11N作為簡稱從具體的工作內(nèi)容上說，國際化與本地化工作，實際上包括的細節(jié)很多，也很繁雜。以下列舉一些常見的工作：不同語言表達方式； 電子文件的編碼； 數(shù)字命名系統(tǒng)的不同； 文字書寫方向(如英語是從左到右，阿拉伯語從右到左)； 語言細微差別（如英國英語中的Colour和美國英語中的Color）；

5、貨幣； 日期格式； 數(shù)字格式；等等6.1.2 國際化過程開發(fā)軟件時，國際化和本地化對開發(fā)者是一個有挑戰(zhàn)性的任務很多軟件，在剛開始設(shè)計時，并沒有考慮到需要在不同的語言和地區(qū)使用，于是就沒有按照國際化的思想去設(shè)計，但是一段時間之后，軟件突然出現(xiàn)要在其他地區(qū)使用的任務，國際化和本地化的工作將會十分艱難6.1.2 國際化過程怎樣讓程序從一開始就為國際化和本地化提供開發(fā)基礎(chǔ)呢？我們知道，軟件的難度在于程序的業(yè)務邏輯，一般情況下不應該隨便對業(yè)務邏輯進行改動程序在不同地區(qū)運行的過程中，實際上，程序的邏輯只有一份，只是界面的表示有所不同，而應該避免的是程序邏輯的修改因此，通常作法是：將文本和其他與環(huán)境相關(guān)的資

6、源單獨編寫，和程序代碼相分離這樣，在理想的情況下，應對變化的環(huán)境時，無需修改代碼，只需要修改資源，從而顯著簡化了工作以下是國際化（本地化）的基本過程。 從上面的圖中可以看出，國際化過程包括3個部分：資源文件。是一個文件，能夠保存各種不同語言所對應的資源讀取工具。能夠根據(jù)語言來讀取資源文件應用程序。調(diào)用讀取工具，讀取資源文件在很多軟件里面實現(xiàn)了國際化，以Java框架為例，要開發(fā)一個支持英文和中文的歡迎界面，該界面標題根據(jù)系統(tǒng)語言的不同而自動變化，可以利用接下來的一些代碼來實現(xiàn)：以下是支持英文顯示的資源文件：messageResource_en_US.properties以下是支持中文顯示的資源文

7、件(在Java中實現(xiàn)了轉(zhuǎn)碼，將“歡迎您來到本系統(tǒng)”轉(zhuǎn)化成了ASCII碼表示，用native2ascii來實現(xiàn)。這是Java的語言特點，其他語言不一定相同)：messageResource_zh_CN.propertieswelcomeMessage=Welcome to visit our system! welcomeMessage=u6B22u8FCEu60A8u6765u5230u672Cu7CFBu7EDF 首先，將系統(tǒng)語言變?yōu)橹形?中國)。如果使用的是windows系統(tǒng)，你可以通過控制面板中的“區(qū)域和語言選項”來修改： 運行，得到如下界面；然后將系統(tǒng)語言變?yōu)椤坝⒄Z”，運行，得到如下界

8、面。 6.2 國際化中的安全問題6.2 國際化中的安全問題國際化過程中，遇到的最重要的問題是不同的語言文字，在不同的系統(tǒng)中具有不同的表達方式，也就是通常所說的編碼編碼是不同國家的語言在計算機中的一種存儲和解釋規(guī)范，在各個不同規(guī)范中，存儲了相應能夠表達一定內(nèi)容的的若干字符，稱為字符集最原始的字符集是美國國家標準學會(American National Standards Institute, ANSI)的美國信息交換標準碼(American Standard Code for Information Interchange，ASCII字符集)，它使用7個比特來表示一個字符，總共表示128個字符由

9、于一個字節(jié)一般占用8個比特，為了充分利用一個字節(jié)所能表達的最大信息，IBM公司對ASCII字符集進行了擴展，用一個字節(jié)來表示一個字符，這樣，讓ASCII碼字符集總共可以表示256個字符不過，我們常說的ASCII碼字符集表達的還是128個字符，常見的ASCII碼字符集表也是基于128字符的ASCII碼字符集編寫的由于英文和大部分的西方語言都是以字母拼寫為基礎(chǔ)的，需要的字母數(shù)量不多。因此，以上ASCII碼字符集對這些語言的表達，基本能夠勝任但是，世界上的語言種類多種多樣，如中文、日文、韓文等，語言中含有的文字就幾千個，ASCII字符集就無法勝任其表達。因此，在ASCII字符集的基礎(chǔ)之上，又派生出了

10、一些新的字符集，如：GB2312、UTF-8、UTF-16等，稱為MBCS（Multi-Byte Chactacter System，多字節(jié)字符系統(tǒng)）提示：注意，同一個字，在不同的系統(tǒng)中可能有不同的表達方式。如“中國人”，在GB2312字符集和UTF-8字符集中，其表達方式完全不一樣，可以編寫相應的程序進行驗證有人可能會問，為什么不將這些字符集統(tǒng)一成為一個呢？這是因為各種字符集都有其發(fā)布的歷史，一個字符集發(fā)布一段時間，功能需要擴充，于是出來了新的字符集，但是原有的項目要改成新的字符集，需要花費一些成本。久而久之，就造成了很多字符集并存的局面6.2.2 字符集轉(zhuǎn)換在實際的項目中，源數(shù)據(jù)可能來自于

11、不同的字符集(如支持不同字符集的數(shù)據(jù)庫)，而源數(shù)據(jù)需要以某種方式被目標程序使用，如顯示在界面上、或者被目標程序進行加工等等這時候遇到的最大問題就是：目標程序所支持的字符集和源數(shù)據(jù)屬于的字符集可能不一致。此種情況下，可能造成系統(tǒng)顯示出錯根據(jù)情況的不同，分類如下：1：當目標程序所支持的字符集和源數(shù)據(jù)屬于的字符集完全不兼容時，數(shù)據(jù)無法顯示(或者以亂碼形式顯示)例如，對于中文來說，如果源數(shù)據(jù)庫使用字符集GBK，從數(shù)據(jù)庫中查出來的中文內(nèi)容，想要在目標程序上使用，而目標程序默認支持ASCII，由于GBK是16位字符集，而ASCII是7位字符集，兩者完全不兼容，或者說沒有任何關(guān)系，每一個中文字符在ASCII

12、中，都不能夠找到對等的字符，所以所有中文字符都會丟失而變成亂碼形式2: 當目標程序所支持的字符集是源數(shù)據(jù)屬于的字符集的子集時，信息會部分丟失例如，如果源數(shù)據(jù)庫使用GBK，而目標程序字符集使用GB2312，這個過程中絕大部分字符都能夠正確轉(zhuǎn)換，但是由于GB2312字符集小于GBK，因此一些超出GB2312字符集的字符變?yōu)閬y碼在這些情況下，就必須進行字符集轉(zhuǎn)換，俗稱轉(zhuǎn)碼各種語言中都有不同的轉(zhuǎn)碼支持。本節(jié)以Visual C+為例來說明轉(zhuǎn)碼問題在Visual C+中，有如下兩個函數(shù)對轉(zhuǎn)碼進行支持： MultiByteToWideChar WideCharToMultiByte在這兩個函數(shù)中，“Mult

13、iByte”稱為短字符，一般為8bit或8bit以內(nèi)來表示的字符，如ASCII碼?！癢ideChar”稱為寬字符，一般是指用16bit或以上(如果有的話)表示的字符，如UNICODE MultiByteToWideChar函數(shù)的功能是：將一個由短字符組成的字符串轉(zhuǎn)換為一個寬字符組成的字符串。函數(shù)原型是： int MultiByteToWideChar(UINT CodePage, DWORD dwFlags, LPCSTR lpMultiByteStr, int cchMultiByte, LPWSTR lpWideCharStr, int cchWideChar) 由于內(nèi)容所限，不對該函數(shù)進

14、行詳細的介紹，只對有關(guān)各參數(shù)，在此進行簡單的闡述：1：CodePage：指定執(zhí)行轉(zhuǎn)換的代碼頁(實際上就是字符集或編碼方式)，這個參數(shù)可以為系統(tǒng)已安裝或有效的任何代碼頁所給定的值。你也可以指定其為下面的任意一值：CP_ACP：ANSI代碼頁； CP_MACCP：Macintosh代碼頁； CP_OEMCP：OEM代碼頁； CP_SYMBOL：符號代碼頁； CP_THREAD_ACP：當前線索ANSI代碼頁； CP_UTF7：使用UTF-7轉(zhuǎn)換； CP_UTF8：使用UTF-8轉(zhuǎn)換。 2：dwFlags：一組標記，用以指出字符的處理方式?？梢允且韵聵擞洺Ａ康慕M合，含義如下： MB_PRECOMPO

15、SED：由一個基本字符和一個非空字符組成的字符只有一個單一的字符值。這是缺省的轉(zhuǎn)換選擇。不能與MB_COMPOSITE值一起使用。注意，推薦使用該標志，因為這會在某種程度上消除產(chǎn)生組合字符的可能并加速規(guī)范化。MB_COMPOSITE：由一個基本字符和一個非空字符組成的字符分別有不同的字符值。這是缺省的轉(zhuǎn)換選擇。該選項不能與MB_PRECOMPOSED值一起使用。MB_ERR_INVALID_CHARS：如果函數(shù)遇到無效的輸入字符，它將運行失敗。該標記能夠捕獲未定義的字符，因此，在不大于50000的CodePage中，推薦使用該標記。MB_USEGLYPHCHARS：使用象形文字替代控制字符。3

16、：lpMultiByteStr：將被轉(zhuǎn)換字符串的字符4：cchMultiByte：指定由參數(shù)lpMultiByteStr指向的字符串中字節(jié)的個數(shù)。如果這個值為-1，字符串將被設(shè)定為以NULL為結(jié)束符的字符串，并且自動計算長度5：lpWideCharStr：指向接收被轉(zhuǎn)換字符串的緩沖區(qū)6：cchWideChar：指定由參數(shù)lpWideCharStr指向的緩沖區(qū)的字節(jié)個數(shù)。若此值為零，函數(shù)返回緩沖區(qū)所必需的寬字符數(shù)該函數(shù)返回值含義為： 如果函數(shù)運行成功，并且cchWideChar不為零，返回值是由lpWideCharStr指向的緩沖區(qū)中寫入的寬字符數(shù)； 如果函數(shù)運行成功，并且cchMultiByt

17、e為零，返回值是接收到待轉(zhuǎn)換字符串的緩沖區(qū)所需求的寬字符數(shù)大??； 如果函數(shù)運行失敗，返回值為零WideCharToMultiByte函數(shù)功能是：將一個由寬字符組成的字符串轉(zhuǎn)換為一個由短字符組成的字符串。函數(shù)原型是： int WideCharToMultiByte(UINT CodePage, DWORD dwFlags, LPWSTR lpWideCharStr, int cchWideChar, LPCSTR lpMultiByteStr, int cchMultiByte, LPCSTR lpDefaultChar, PBOOL pfUsedDefaultChar ) 1：CodePage

18、：指定執(zhí)行轉(zhuǎn)換的代碼頁(字符集或編碼方式)，意義和MultiByteToWideChar中類似。2：dwFlags：一組位標記用以指出字符的處理方式，意義和MultiByteToWideChar中類似；不過，該參數(shù)還有一個WC_NO_BEST_FIT_CHARS標記推薦使用，該標記可以防止函數(shù)將字符映射到相似但語義完全不同的字符上。3：lpWideCharStr：指向?qū)⒈晦D(zhuǎn)換的unicode字符串。4：cchWideChar：指定由參數(shù)lpWideCharStr指向的緩沖區(qū)的字符個數(shù)。如果這個值為-1，字符串將被設(shè)定為以NULL為結(jié)束符的字符串，并且自動計算長度。5：lpMultiByteSt

19、r：指向接收被轉(zhuǎn)換字符串的緩沖區(qū)。6：cchMultiByte：指定由參數(shù)lpMultiByteStr指向的緩沖區(qū)最大值（用字節(jié)來計量）。若此值為零，函數(shù)返回lpMultiByteStr指向的目標緩沖區(qū)所必需的字節(jié)數(shù)，在這種情況下，lpMultiByteStr參數(shù)通常為NULL。7：lpDefaultChar和pfUsedDefaultChar：只有當WideCharToMultiByte函數(shù)遇到一個寬字節(jié)字符，而該字符在CodePage參數(shù)標識的代碼頁中并沒有它的表示法時，WideCharToMultiByte函數(shù)才使用這兩個參數(shù)。lpDefaultChar意義如下： 如果寬字節(jié)字符不能被轉(zhuǎn)

20、換，該函數(shù)便使用lpDefaultChar參數(shù)指向的字符； 如果該參數(shù)是NULL（這是大多數(shù)情況下的參數(shù)值），那么該函數(shù)使用系統(tǒng)的默認字符。pfUsedDefaultChar參數(shù)指向一個布爾變量： 如果Unicode字符串中至少有一個字符不能轉(zhuǎn)換成等價多字節(jié)字符，那么函數(shù)就將該變量置為TRUE； 如果所有字符均被成功地轉(zhuǎn)換，那么該函數(shù)就將該變量置為FALSE； 當函數(shù)返回以便檢查寬字節(jié)字符串是否被成功地轉(zhuǎn)換后，可以測試該變量該函數(shù)的返回值意義為： 如果函數(shù)運行成功，并且cchMultiByte不為零，返回值是由 lpMultiByteStr指向的緩沖區(qū)中寫入的字節(jié)數(shù)； 如果函數(shù)運行成功，并且c

21、chMultiByte為零，返回值是接收到待轉(zhuǎn)換字符串的緩沖區(qū)所必需的字節(jié)數(shù)；如果函數(shù)運行失敗，返回值為零在Java語言中，字符集的轉(zhuǎn)換也具有一定的支持，列舉如下：1：編譯階段：一般javac根據(jù)當前操作系統(tǒng)區(qū)域設(shè)置，自動決定源文件的編碼，可以通過-encoding強制指定。如：2：資源文件：資源文件一般為.properties文件，可由Properties用ISO-8859-1編碼讀取，需要使用JDK 的native2ascii工具轉(zhuǎn)換漢字為uXXXX格式，才能正確讀取里面的漢字。如： 如前面的例子中，中文資源文件messageResource_zh_CN.properties的內(nèi)容如下(可

22、用文本編輯器打開閱讀)： 等號右邊的內(nèi)容實際上就是“歡迎您來到本系統(tǒng)”經(jīng)過native2ascii命令轉(zhuǎn)碼之后的結(jié)果native2ascii -encoding GBK sourceFile destFile javac -encoding gb2312 Hello.java welcomeMessage=u6B22u8FCEu60A8u6765u5230u672Cu7CFBu7EDF 3：字節(jié)數(shù)組：可使用new String(byteArray,encoding) 和 String.getBytes(encoding) 在字節(jié)數(shù)組和字符串之間進行轉(zhuǎn)換。如下例子，如果我們得到的字符串strin

23、g是由ISO-8859-1轉(zhuǎn)碼方式產(chǎn)生的，要在支持GB2312中文的界面上顯示，可以以如下方式轉(zhuǎn)為正確的中文： 4：JSP：如果要支持漢字，可在頭部加上： 這樣的標簽。JSP表單的過程中，經(jīng)常會出現(xiàn)亂碼問題，如表單中的中文漢字無法被獲取之后成為亂碼，此時可以采用上面字節(jié)數(shù)組的處理方法，也可以使用： 來處理，當然，也可以編寫過濾器，將該內(nèi)容放在過濾器中。string = new String(string.getBytes(ISO-8859-1), GB2312); string = new String(string.getBytes(ISO-8859-1), GB2312); request

24、.setCharacterEncoding(gb2312); 6： Servlet：如果要輸出中文，確定設(shè)置：另外，在標記語言中，也可以設(shè)置其編碼方式：1：XML文件：XML文件讀寫同于文件讀寫，如果有漢字，應注意確保XML頭中聲明如：與文件編碼保持一致。2：HTML：在head中加上：讓瀏覽器正確確定HTML編碼。 response.setContentType(text/html; charset=GB2312); 6.2.3 I18N緩沖區(qū)溢出問題在轉(zhuǎn)碼時，如果使用不當，就會出現(xiàn)緩沖區(qū)溢出問題。這種情況在使用MultiByteToWideChar和WideCharToMultiByte函

25、數(shù)時更容易出現(xiàn)。如下函數(shù)：int MultiByteToWideChar(UINT CodePage, DWORD dwFlags, LPCSTR lpMultiByteStr, int cchMultiByte, LPWSTR lpWideCharStr, int cchWideChar) 函數(shù)的參數(shù)5中，定義了目標字符串的指針。怎樣定義目標字符串呢？一種方法是，事先定義一個足夠大的寬字符數(shù)組，但是可能有如下的缺陷：當lpMultiByteStr占用空間較小時，可能會造成空間浪費；如果為了避免空間浪費，分配的數(shù)組空間較小，當lpMultiByteStr占用的空間超過了預分配空間時，又可能造成

26、緩沖區(qū)溢出因此，該方法不是一個最好的辦法此種情況下，我們需要通過一些手段來獲知轉(zhuǎn)碼的目標數(shù)組lpMultiByteStr所需要的數(shù)組空間。方法是：將MultiByteToWideChar函數(shù)的第四個形參設(shè)為-1，即可返回所需的短字符數(shù)組空間的個數(shù)。下面就是一個例子：nLen中得到的就是所需的短字符數(shù)組空間的個數(shù)。因此，完整的安全的代碼結(jié)構(gòu)如下： int nLen = MultiByteToWideChar (CP_UTF8, 0, lpMultiByteStr, -1, NULL, 0); /獲得需要分配的內(nèi)存大小，存入nLen int nLen = MultiByteToWideChar(C

27、P_UTF8,MB_ERR_INVALID_CHARS, lpMultiByteStr,-1, NULL,0); if(nLen=0) /函數(shù)調(diào)用異常，作異常處理 /跳出 /為新的字符串分配內(nèi)存LPWSTR lpWideCharStr = (LPWSTR)GlobalAlloc(0,sizeof(WCHAR)*nLen); if(lpWideCharStr=NULL) /內(nèi)存分配失敗，作相應處理 /跳出 /正式轉(zhuǎn)換nLen = MultiByteToWideChar(CP_UTF8,MB_ERR_INVALID_CHARS, lpMultiByteStr,-1, lpWideCharStr,n

28、Len); if(nLen=0) /函數(shù)調(diào)用異常，作異常處理 /跳出 /其它收尾操作6.3 推薦使用Unicode 實際上，理想的情況是，在軟件開發(fā)的過程中，全程使用某一種編碼；并且不在這種編碼和別的字符集之間進行轉(zhuǎn)換，自然不會出現(xiàn)字符集轉(zhuǎn)換中信息丟失的問題在我們要選擇的編碼中，Unicode(Universal Multiple-Octet Coded Character Set)是一種值得推薦的字符集隨著信息化交流的迅速發(fā)展，個體之間進行的數(shù)據(jù)交換越來越頻繁，不同的編碼體系漸漸成為信息交換的障礙雖然我們可以進行編碼轉(zhuǎn)換，但是由于多種語言的文檔共存的現(xiàn)象不斷增多，編碼轉(zhuǎn)換也成了一件麻煩的事情

29、因此，設(shè)計一種統(tǒng)一的編碼顯得非常重要，此種情況下，Unicode應運而生。Unicode又稱統(tǒng)一碼、萬國碼或單一碼，是國際組織制定的可以容納世界上所有文字和符號的字符編碼方案。Unicode于1990年開始研發(fā)，在1994年正式公布。隨著網(wǎng)絡的發(fā)展和信息交流的增強， Unicode也在面世以來的十多年里得到普及。作為一種在計算機上使用的字符編碼，針對每種語言中的每個字符，Unicode為都設(shè)定了統(tǒng)一并且唯一的二進制編碼，這樣，不管在什么語言，什么平臺下，Unicode不需要轉(zhuǎn)碼，滿足了跨語言、跨平臺進行文本轉(zhuǎn)換、處理的要求在Unicode公布之前，對于同一個字符，可能出現(xiàn)多種不同的編碼，由于無法知道