很久以來,我對Unicode的使用問題感到折磨。 Unicode允許加速和簡化軟件開發(就全球化而言),但我擔心以下因素:軟件中的Unicode使用情況
- 增加的內存和磁盤空間使用率;
- 減少文本處理性能;
- 亞洲語言對待所有這些都損害了國家的特殊性。
隨着第一段的所有這是顯而易見的......但我不知道真的或不是其他人。有沒有人需要爲亞洲國家本地化軟件,並準備分享經驗?
目前我嘗試使用窄輪廓編碼(cp1251 - 對於俄羅斯,cp1254對於土耳其等)。有人會就這個問題提出建議嗎?
很久以來,我對Unicode的使用問題感到折磨。 Unicode允許加速和簡化軟件開發(就全球化而言),但我擔心以下因素:軟件中的Unicode使用情況
隨着第一段的所有這是顯而易見的......但我不知道真的或不是其他人。有沒有人需要爲亞洲國家本地化軟件,並準備分享經驗?
目前我嘗試使用窄輪廓編碼(cp1251 - 對於俄羅斯,cp1254對於土耳其等)。有人會就這個問題提出建議嗎?
前兩點非常可忽略不計。您需要有一個非常具體的用例,其中大小和性能的差異會產生可辨別的差異,證明混合編碼的麻煩是正確的。
關於Unihan字符:它們按照字符的含義分組,但是該字符在不同的書寫系統中可能會略有不同。這是正確標記語言的問題,它不是一個真正的編碼問題。在HTML文檔中,您可以使用lang
屬性標記文檔和/或使用CSS設置特定的字體,這將相應地改變該語言字符的外觀。如何正確處理這取決於軟件的類型(HTML,桌面應用程序等)。我建議你打開一個新的,詳細的問題。
謝謝關於「lang」的建議......我只看了http://en.wikipedia.org/wiki/Han_unification#Examples_of_language_dependent_characters,看到Unihan角色並不像我想的那麼大。 – user1717043
'lang'屬性對渲染只有邊緣效應(儘管其影響可能會增加)。它可能會影響*默認*字體的選擇,因此CJK字符以中文或日文字體顯示。但網頁主要是自己的字體設置,然後默認字體通常不重要。 –
增加文字大小:是的。文字大小可增加至6倍(對於UTF-8)。但現在的文本存儲不是什麼大問題。
降低文本處理性能:根據我的意見,沒有。一個UTF-8字符最多可能需要6個字節,但是當掃描文本時,以及在UTF-8字符的第一個字節處,我們已經知道需要多少字節才能讀取它(掃描中的當前字符)。因此,掃描性能很可能與O(n)保持一致,其中「n」是文本的長度。爲了保持最佳性能,儘量不要通過索引訪問文本中的字符(是的,這是性能的一個下降點)。 Java字符串不受字符串字符的隨機索引訪問影響,因爲Java字符串是一系列2字節字符。
亞洲語言的處理都是一樣的國家的具體的損害:是的,當以文本格式呈現的人類語言都是相似的,但一個字母「I」一箇中風或信的「長」 16招只是一個角色。
字符的UTF-8編碼形式最多爲4個字節。有關6個字節的信息已過時(從將Unicode編碼空間限制爲0..10FFFF之前的時間段開始)。 –
查看官方Unicode FAQ。對這些問題有很多要說的。
我決定使用Unicode更合理(但需要保留用戶語言)。 – user1717043
增加文本大小,以下所有內容實際上都是不真實的。
對於unicode的老派編碼,比如UTF-16,它們可能是正確的。對於僅ASCII字符串,UTF-8不會更大或比ASCII更慢,但它允許對每個Unicode代碼點進行編碼。 UTF-8也是今天在市場上做Unicode的事實上的標準。
對http://www.utf8everywhere.org中的不同Unicode編碼的性能有廣泛的分析,包括亞洲語言。
你真的認爲「增加文字大小」是一個真正的問題? o.O – 2012-11-01 06:59:27
你的第三點意味着什麼並不清楚 - 你的第一點意味着什麼?*記憶*? (如果你和大多數人談論文字大小,他們會認爲你在談論屏幕上字形的大小......) –
最後一個很大程度上取決於你正在開發的軟件的細節和種類。如果有的話,請更多的背景。 – deceze