爲什麼.net/c＃中沒有字節字符串？

Question

是否有一個很好的理由，即.NET僅爲UTF-16提供字符串函數（如搜索，子字符串提取，拆分等）而不是字節數組？我發現很多情況下，使用8位字符而不是16位字符更容易，效率更高。

讓我們以MIME（.EML）格式爲例。它基本上是8位文本文件。使用ANY編碼無法正確讀取它（因爲編碼信息包含在文件中，而且不同的部分可能有不同的編碼）。

所以，你基本上更好地讀取MIME文件作爲字節，確定它的結構（理想情況下，使用8位字符串解析工具），並找到所有編碼依賴數據塊的編碼後應用encoding.GetString（數據）以獲得正常他們的UTF-16表示。

另一件事是與base64數據塊（base64只是一個例子，也有UUE和其他）。目前.NET期望你有一個base64的16位字符串，但是它不能有效地讀取兩倍大小的數據，並且爲了解碼這些數據而進行從字節到字符串的所有轉換。處理兆字節的數據時，它變得很重要。

缺少的字節字符串操作函數導致需要手動編寫它們，但實現明顯效率低於字符串函數的本地代碼實現。

我不說它需要被稱爲8位字符，讓我們保持它的字節。只需要一組反映大多數字符串操作例程的本地方法，但是需要使用字節數組。這只是我需要的還是我錯過了一些關於常見.NET架構的重要內容？

Answer 1

處理混合編碼字符串操作的代碼是不必要的困難，很難解釋/得到正確。你建議處理每個「字符串」的混合編碼的方式需要保持編碼信息，框架必須提供所有可能的編碼組合的實現。

此類問題的標準解決方案是提供定義明確的方式，將所有類型轉換爲/從單個「規範」表示形式執行，並對該規範類型執行大多數操作。您可以更輕鬆地在圖像/視頻處理中將隨機傳入格式轉換爲一種格式工具知道，處理並轉換回原始/任何其他格式。

.net字符串幾乎是用「規範」的方式來表示Unicode字符串。從用戶的角度來看，還有很多方法可以表示實際上由不同的char元素組成的字符串。即使是常規的字符串比較也是一個巨大的問題（除了編碼之外還經常出現語言環境差異）。

注

• 已經有很多API處理字節數組比較/片的 - 無論是在Array/List類和LINQ幫手。唯一真正的缺失部分是類似於正則表達式的匹配。
• 即使處理單一類型的字符串編碼（在許多其他系統中的UTF-16 in .Net，UTF-8）也很難 - 即使得到「sting length」也是一個問題（你是否需要只計算代理對或者包含所有組合字符，或者僅僅是.Length就足夠了）。
• 嘗試自己編寫代碼以查看複雜程度來自何處以及特定的框架決策是否有意義是一個好主意。嘗試實現10-15個通用的string函數以支持多種編碼 - 即（UTF8，UTF16和8位編碼之一）。

Answer 2

讓我們MIME（.EML）格式的例子。它基本上是8位文本文件。您無法使用ANY編碼正確讀取它。 （因爲編碼信息包含在文件中，而且不同的部分可以有不同的編碼）。

所以，你在談論一個通用字節串方法不是很有用的情況，你需要專門化。

然後換另一些情況下，你需要重新專注。

再次。

其實，我覺得字節字符串的方法會比你的例子表明，更加有用，但它仍然是一個很多關於他們的案件有從其他用途的不同之處不兼容的方式特殊需求。

這表明它可能不是非常適合於基部庫。這不像你自己做的那樣適合那些專門的需求。