觸摸屏中文無法顯示是一個比較常見的問題，一般是因為系統中沒有支持的字庫導致的，需要我們手動導入下字符庫。以前在威倫和西門子觸摸屏 wincc中都有遇到過。
下面以MP277 10" Key的觸摸屏為例子說下如何手動導入字符庫，以及引起這種無法顯示的原因。
軟件版本：Wincc Flexible 2008 SP5
Wincc Flexible在組態的時候可以設置可選最多四種字體，兩種是默認的，兩種是可以自定義的。我們可以在設備設置>語言和字體 中看到所有可用的字體。
固定的字符集是指觸摸屏中固定可選的字體，默認是兩種。西語兩種可選的字體是Tahoma和Courier New,中文是宋體，不可修改。觸摸屏在運行時默認使用的字體。
已組態的字體集是指開發者可以添加的字體，最多可以另外添加兩種。這些新添加的字體會在下載觸摸屏程序時下載到觸摸屏中。
?這里就有個問題，既然默認的字體是宋體，為什么觸摸屏上還是會無法顯示呢？
既然無法正常的顯示，我們就需要把電腦中的宋體字符庫拷貝到觸摸屏中。
系統中的字符庫的路徑在??C:\Windows\Fonts中，拷貝宋體字符庫文件到U盤或者SD卡中
由于宋體字符庫的大小為17.3MB，需要檢查下WinCE系統中存儲區分配的大小是否足夠，如果存儲空間不夠在拷貝的時候會出現彈窗提示。
這時我們需要調整下存儲空間的大小。在?System>Memory?中滑塊往右滑動增加存儲區的大小。
將字符文件simsun.ttc?拷貝到觸摸屏的?\Windows\Fonts?路徑下
將字符拷貝到觸摸屏的Fonts文件夾下后，運行觸摸屏程序，字體就能正常顯示了，但是重啟后發現Fonts文件夾下的宋體字庫沒有了，界面也不能正常顯示。由于\Windows\Fonts ?還是屬于臨時存儲區，還需要在OP菜單中將字符文件永久保存。
這個永久保存文件的操作在我另一篇第三方VNC遠程連接觸摸屏中也有介紹到。
本來問題已經解決了，有個問題一直比較奇怪是我們上面提到的組態時中文默認是宋體，但是為什么還是沒有正常顯示呢？以前是正常顯示的。
難道觸摸屏里面沒有存有宋體還是丟了呢?
我們在Fonts中沒有發現任何的字符庫文件，WinCE中的字符庫文件存儲在什么地方？
打電話給西門子咨詢下，得到的回復原來這是組態軟件Wincc Flexible 2008 SP5的一個Bug,該問題已經在WinCCflexible2008_SP5_Upd1中解決了。查了下軟件的改進記錄中有下面這一項。
因此現在就有兩種方法可以解決中文字符無法顯示的問題了
CSDN移動將持續為您優選移動開發的精華內容，共同探討移動開發的技術熱點話題，涵蓋移動應用、開發工具、移動游戲及引擎、智能硬件、物聯網等方方面面。如果您想投稿、參與內容翻譯工作，或尋求近匠報道，請發送郵件至tangxy#csdn.net（請把#改成@）。
本文出自：owensd.io，譯文出自：SwiftGG
最近Swift的熱點都圍繞在協議上，他們覺得任何東西都應該是協議。理論上這挺好，但是事實上，這種觀點會產生一些副作用。
我在代碼中使用協議時，總是牢記下面兩條規則：
我看到的（和我一開始寫的）許多方法都是在繼承關系里把協議當成一個基類。我不認為這是協議的正確用法，這種設計模式仍然停留在“面向對象”的思維方式上。
換句話說，假如你的協議只在繼承關系里有意義，那就應該捫心自問是否真的有必要使用協議。我不贊同這種說法：“我的類型是結構體，所以我需要用協議來代替。”如果真的需要這樣，那就重構它，把它變得更通用。
進一步的驗證可見：http://swiftdoc.org/swift-2/。需要關注所有那些協議（不以 _ 開頭的協議）嗎？所有的協議都能適用不同的類型，不管是不是類型繼承。
這并不是一個小問題，一旦你把協議泛型化，就無法再使用包含不同協議實例的類型集合。我認為這是嚴重的設計缺陷。比如說，無論在哪里使用協議，協議中所有不受Self限制的功能都應該保證調用安全。
這條規則同樣適用于遵守泛型協議的協議，比如Equatable，泛型會傳染。
下面這行代碼就是典型的例子：
protocol Foo : Equatable {}來個實際點的例子吧：
我們想要對HTTP response建模，并且想要支持兩種不同的response類型：String和JSON。
你可能會這樣寫：
class HTTPResponse<ResponseType> {
var response: ResponseType
init(response: ResponseType) { self.response=response }
}我認為這樣寫不好。一旦這樣寫，我們就人為地限制了使用這個類型的能力；比如，這不能在復雜情況下的集合里使用。現在，為什么我想要在集合里使用不同的ResponseType？假設，我想要構建一個 response/request的測試工具。返回response的集合里需要有我支持的類型：String和JSON。
使用AnyObject是個不錯的做法。雖然可行，但是真的很操蛋。
另一種方法是使用協議。然而，除了構建ResponseType協議之外，讓我們想想真正想要什么。我真正關心的是，HTTPResponse接收到的ResponseType都能表示成String。
揣著這樣的想法，我寫出這樣的代碼：
protocol StringRepresentable {
var stringRepresentation: String { get }
}
class HTTPResponse {
var response: StringRepresentable
init(response: StringRepresentable) { self.response=response }
}對我而言，這為API使用者提供了極大的方便，也維持了類型的明確性。當然，這樣做是有弊端的。假如你真的需要為response使用特定的類型，那么就需要進行類型轉換。
class JSONResponse : StringRepresentable {
var stringRepresentation: String="{}"
}
let http=HTTPResponse(response: JSONResponse)
let json=http.response as? JSONResponse這個方法明顯更好。調用者知道可能的返回類型或返回值。這明顯與遍歷整個集合取出返回值是不同的，因為，代碼的使用者可能使用的是其他的返回類型，比如 XMLResponse ，而我們的代碼不可能知道這個。
最好是這樣寫：
class HTTPResponse<ResponseType : StringRepresentable> {
var response: ResponseType
}
<span style="font-family: Helvetica, Tahoma, Arial, sans-serif; font-size: 14px; white-space: normal; background-color: initial;">let responses=[json, string] //responses變量是以HTTPResponse為元素的數組，元素中的ResponseType是未指定的。</span>如果要用集合，你還是需要強制轉換response的類型，不過現在你可以直接用JSON實例來驗證類型。
反正我是每次都用[HTTPResponse]類型的集合，而不是[AnyObject]。
預告：2015中國移動開發者大會（MDCC 2015）將于10月15-16日在北京新云南皇冠假日酒店召開。大會特設五大技術專場：平臺與技術iOS、平臺與技術Android、產品與設計、游戲開發、企業移動化。此外，大會更是首次舉辦國內極具權威影響力的IoT技術峰會，特設硬件開發技術與虛擬現實兩大專場。大會將聚集國內最具實力的產品技術團隊，與開發者一道進行最前沿的探討與交流。
第一時間掌握最新移動開發相關信息和技術，請關注mobilehub公眾微信號（ID: mobilehub)。