字符串（「; P」）較大或字符串（「-_-」）較大？

排序文本文件時發現非常混亂。不同的算法/應用產生不同的結果，例如，在比較兩個字符串str1=";P"和str2="-_-"字符串（「; P」）較大或字符串（「-_-」）較大？

僅供參考這裏給ASCII在這些字符串中的每個字符：

char(';') = 59; char('P') = 80; 
char('-') = 45; char('_') = 95;

所以，我已經嘗試了不同的方法來確定哪些字符串是更大的，這裏是我的結果：

在Microsoft Office Excel 排序命令：

「; P」 < 「-_-」
C++的std :: string ::比較（串& STR2），即str1.compare(str2)

「; P」> 「-_-」
C＃string.CompareTo（），即str1.CompareTo(str2)

「; P」 < 「-_-」
C＃string.CompareOrdinal（），即CompareOrdinal(w1, w2)

「; P」> 「-_-」

如圖所示，結果很多！實際上，我的直觀結果應該等於方法2和4，因爲ASCII（';'）= 59大於ASCII（' - '）= 45。

所以我不知道爲什麼Excel和C＃string.CompareTo（）給出了相反的答案。注意到在C＃中第二個比較函數名爲string.CompareOrdinal()。這是否意味着默認的C＃string.CompareTo()函數不是「序數」？

任何人都可以解釋這種不一致嗎？

任何人都可以解釋CultureInfo = {en-US}，爲什麼它告訴; P> -_-？什麼是潛在的動機或原則？我曾經聽說過不同的文化信息中的不同的雙重乘法。這是一個文化衝擊..！

來源

2012-03-02 JXITC

查看'CompareTo（）'中的第二個參數 – SLaks 2012-03-02 00:08:44

除了基於序數值的排序之外，還有兩個選項是長度比較（不太可能）或詞典比較，這很可能是您的情況「更大」的確是錯誤的單詞，「更大」的字符串將是「-_-」，因爲它是3個字符，而「P」有2個字符 – Xeo 2012-03-02 00:18:00

可能與[標點符號n標記vs字母]（http://stackoverflow.com/questions/9475535/order-of-punctuation-marks-vs-letters）。檢查我的答案那裏的鏈接 - 特別是CompareOptions.StringSort之一。 – 2012-03-02 03:17:00

？
std::string::compare：「字符比較的結果僅取決於其字符代碼」。它只是序數。
String.CompareTo：「使用當前文化執行一個詞（區分大小寫和區分文化）比較」。所以，這不是次序，因爲典型的用戶並不希望事情按照那樣排序。
String::CompareOrdinal：根據名稱「使用序號排序規則執行區分大小寫的比較」。

編輯：CompareOptions有一個提示：「例如，連字符（」 - 「）可能會分配給它這樣一個很小的權重是‘雞窩’和‘雞舍’旁邊顯示對方一個排序列表。「

來源

2012-03-02 00:12:07

My CurrentCultrueInfo = {en-US};我想知道爲什麼在{en-US} cultrue';'可以小於' - '？動機是什麼？對不起，我只能在.Net中找到CultureInfo的定義，但不知道爲什麼不同文化應該爲角色定義不同的比較方法。 – JXITC 2012-03-02 00:20:22

新增1.確保數字與問題中的相同。不幸的是，SO標記並不尊重您在構建列表時使用的實際數字。 – 2012-03-02 00:21:07

是的，如果有人能解釋爲什麼Excel（Office 2003）也產生這樣的結果？ – JXITC 2012-03-02 00:22:03

的Excel 2003（或更早）做了某種忽略連字符和撇號，讓您的排序確實比較;到_，這讓你有結果。這裏有一個Microsoft Support link了。漂亮稀疏，但足以讓

來源

2012-03-02 00:34:13

哎呀！哈哈我從來沒有想過他們會忽略連字符。有趣！ – JXITC 2012-03-02 00:36:41

非常感謝！ – JXITC 2012-03-02 00:36:57

字符串（「; P」）較大或字符串（「-_-」）較大？

回答

相關問題