2008-11-18 132 views
14

這主要是一個我只是很好奇的理論問題。 (我沒有試圖通過編碼它自己或任何東西來做到這一點,我不是在重新發明輪子。)如何在Unicode中將字符串設置爲大寫/小寫?

我的問題是大寫/小寫表格的等效性如何適用於Unicode。例如,如果我必須使用ASCII來做這件事,我會選擇一個角色,如果它與[a-z]範圍一起下降,我會總結A和a之間的差異。

如果它不在這個範圍內,我會爲10個左右重音字符加上一個小等價表。 (或者,我可以只有一個完整的等值數組,256條目,其中大部分將與輸入相同)

但是,我猜測有更好的方式來指定Unicode中的等價性,給定有成千上萬的角色,並且從理論上講,可以添加一種新的語言或一組角色(並且我期望在發生這種情況時您不需要修補窗口)。

Windows對每個字符都有一個巨大的硬編碼等價表嗎?或者這是如何實施的?

一個相關的問題是SQL Server如何實現基於Unicode的重音不敏感和不區分大小寫的查詢。它是否有一個內部表格,告訴它它和E都等於「e」?

在比較字符串時聽起來不太快。

它如何快速訪問索引?它是否已將索引值轉換爲其「基本」字符,與該字段的整理對應?

有沒有人知道這些東西的內部?

謝謝!

+0

我希望如果他們給unicode添加了一個新的字符集,那麼你需要補丁窗口,但是這將是一個非常低優先級的補丁,因爲最初沒有人會使用這些字符。 – 2008-11-18 02:40:03

+0

「爲10個左右重音字符加上一個小等價表加上 - 」 - 你必須明白,「小」意味着大約100倍於你認爲的意思。 – 2008-11-18 03:30:54

回答

11

有一個映射文件,其中包含所有具有1:1映射比率的大小寫映射。通常操作系統/框架/庫支持特定版本的Unicode,並且由於這個案例映射文件是版本化的,所以你會得到你的特定OS /框架/庫/無論支持哪種版本的Unicode的映射。

有關Unicode案件映射的詳細信息,請參閱:http://www.unicode.org/faq/casemap_charprop.html

3

大多數書寫系統沒有單獨的大寫和小寫字母。根據維基百科,例外包括「羅馬,希臘,西里爾和亞美尼亞字母」。

所以沒有那麼多字母需要擔心。 This page顯示大範圍的字符遵循一個簡單的方案,即將大寫字符加1以獲得小寫等效(儘管當然有一些例外)。

16

我要解決這個問題的MS SQL Server部分,但「正確的」答案實際上取決於支持的語言和應用程序。

當您在SQL Server中創建表時,每個文本字段都具有隱式或顯式指定的排序規則。這會影響排序順序和比較行爲。大多數英語(美國)語言環境的默認值爲Latin1_General_CI_AS,或Latin 1,不區分大小寫,強調敏感。這意味着,例如,a = A,但a!=Ä和a!=ä。您還可以使用不區分重音的(Latin1_General_CI_AI),它將「A」的所有變音變體視爲相等。

一些語言環境支持其他類別的比較;例如,法國命令含有變音符號的單詞與德語有些不同。土耳其語認爲無點我和點綴我的語義不同,所以如果您使用土耳其語,不區分大小寫,區分變音的歸類,我和我即使不區分大小寫也不匹配。

您可以更改每個數據庫,每個表,每個字段的排序規則以及一些成本甚至每個查詢的排序規則。我的理解是索引按照指定的整理順序進行規範化,這意味着索引基本上保持了原始字符串的扁平化版本。例如,對於不區分大小寫的排序規則,Apple和Apple被存儲爲Apple。在搜索之前,使用相同的排序規則將查詢展平。

在日語中,還有另一類規範化,其中全角和半角字符(如ア=ア),以及在某些情況下,兩個半角字符被平化爲單個語義等同字符(バ=バ)。最後,對於某些語言來說,還有另一個帶有複合字符的蠟球,其中獨立的變音符可以與其他字符合成(例如,ä中的變音符是一個字符,由簡單的形式a組成)。越南語,泰語和其他幾種語言都有此類別的變體。如果存在規範形式,則Unicode規範化允許組合和分解形式被視爲等同形式。 Unicode規範化通常在進行任何比較之前應用。總結一下,對於不區分大小寫的比較,您可以做比較比較ASCII範圍字符串時的操作:將比較的左側和右側平鋪爲「小寫」(例如),然後比較數組作爲二進制數組。不同的是,你需要 1)將字符串規範化爲相同的Unicode格式(kC或kD) 2)根據該區域的規則將字符串規範化爲相同的大小寫3)根據重音規範化口音靈敏度規則 4)根據二進制比較進行比較4)如果適用,例如在排序的情況下,使用附加的二級和三元排序規則進行比較,其中包括類似於諸如「Mc」之類的事物在「M」之前排序的事物在某些語言中。

是的,Windows存儲所有這些規則的表。除非您通過控制面板的東亞語言支持和複雜腳本支持添加對它們的支持,否則在每次安裝中都沒有默認使用它們。

1

正確答案稍微複雜一點,具體取決於您要做什麼。

當比較字符串時,爲了排序或搜索應用程序,要使用的正確算法在UTS #10: "Unicode Collation Algorithm".中指定。不區分大小寫是混合的一部分,但表示多個字符的方式不同,應用程序經常需要處理各種表述等同。

排序規則是區域設置相關的。當您對結果進行排序以顯示給用戶時,這主要是一個問題。忽略規則可能會挫敗用戶,甚至導致安全漏洞。

如果您只是爲顯示目的而嘗試大寫單詞,那麼規則可能會非常棘手;有一對多的轉換和其他問題。根據區域設置的不同,相同的字母可能會大寫。字母在單詞中的位置可以有所作爲。還有一個明顯的「標題案例」的概念,你只想把每個單詞的首字母大寫。有時角色的標題大小寫與大寫字母不一樣。

相關問題