顯然Microsoft開發(fā)人員和管理人員并沒有表達清楚，事實上ASP.NET Core 2.0將會得到整個.NET Framework的支持。當前的更改只實現(xiàn)了在ASP.NET上提供.NET Core，這是為了便于開發(fā)而采取的一個臨時步驟。對此，在ASP.NET Core預覽發(fā)行聲明中給出了如下的解釋：

在發(fā)布ASP.NET Core 2.0預覽版時，僅提供了對.NET Core 2.0 SDK的支持。我們的目標是在.NET Standard 2.0中發(fā)布ASP.NET Core 2.0，使應用可運行在.NET Core、Mono和.NET Framework上。團隊正致力于在Build大會之前解決最后一些問題，最突出的問題是在ASP.NET Core 2.0預覽版中使用了.NET Standard 2.0之外的API，這妨礙了在.NET Framework上的運行。由于這些問題，我們限制了Preview 1版本對.NET Core的支持，以免對開發(fā)人員在.NET Framework上將ASP.NET Core 1.x應用升級到ASP.NET Core 2預覽版時造成破壞。

在Register的一次采訪中，Miguel de Icaza確認了Microsoft對.NET Framework的承諾：

我要對此做出澄清。我感到十分遺憾的是，即將推出的.NET Core 2.0是我們專為Build大會準備，它只是一個預覽版，因為我們發(fā)現(xiàn)其中存在一系列在.NET Framework上無法很快得到解決的問題。因此，我們推出的軟件包僅支持在.NET Core 2.0上運行ASP.NET Core 2.0。我們將會修復這個問題，.NET Core 2.0終將運行在.NET Framework上。

即便是臨時性更改，一個依然需要解決的問題是：要想進一步改進ASP.NET的性能，需要提供更好的字符串處理庫。

內(nèi)存分配上的考慮

在.NET中，幾乎所有的字符串處理方法都要做內(nèi)存分配，該問題長期以來一直為人所詬病。在解析JSON、XML等格式時，substring方法常會產(chǎn)生成百上千的微小字符串分配。這不僅耗費了大量時間生成拷貝，而且對垃圾回收造成了很大的壓力。這并非應用開發(fā)人員所能掌控的。

這種做法有其合理性。與.NET一樣，在Java中字符串也是不可變的。而Java自帶的substring方法并不分配新的字符串，它創(chuàng)建一個指向原始字符串的指針。雖然Java的substring方法無需分配內(nèi)存，但是存在著內(nèi)存泄漏的風險。一個字符串substring方法可以保留5MB字符串不被垃圾回收（這個問題相當惡劣，因此在Java 1.7u6版中做了更改，substring方法做內(nèi)存分配）。

在“Span<T>建議”中，開發(fā)人員可以選擇使用兩種不同的substring方法，即分配內(nèi)存的方法和不做內(nèi)存分配的方法。ASP.NET Core所使用的解析庫也可以被覆寫，在內(nèi)部使用不分配內(nèi)存的substring方法。但在解析操作的最后階段，需要確保釋放所有Span<char>的實例。

這一更改還需要重新實現(xiàn)更高效的基本類型解析方法，例如Int32.Parse和Inta32.TryParse等。理想情況下，這些方法將會加入到基類庫（BCL，Base Class Library）中，而不是以單獨庫的方式提供。這就回到了.NET Framework、Standard和Core的對比問題上。

毫無疑問，可以加快對.NET Core的更改過程。除了操作系統(tǒng)特定的功能，新特性將做優(yōu)先更改。否則，只有得到所有.NET/Mono的各種實體（incarnation）支持的新特性，才會出現(xiàn)在.NET Standard中。雖然從理論上講，這些實體也歸屬于Microsoft的，但是新特性的添加依然會是一個冗長的過程。

因此，在開發(fā)ASP.NET Core的過程中，基于ASP.NET進行構(gòu)建是合乎情理的。這使得新的API在提交標準化前，得到真實用例的精煉。

默認編碼上的考慮

并非所有開發(fā)人員都了解，在.NET內(nèi)部使用的是UTF16字符串。除了實現(xiàn)文件或網(wǎng)絡I/O處理之外，對于大部分用例，開發(fā)人員都無需考慮編碼問題。

Web應用主要基于UTF8編碼。同樣，在處理大部分用例時，服務器端開發(fā)人員也無需考慮編碼問題。只需確保無論使用何種內(nèi)部格式，最終都會轉(zhuǎn)換為UTF8編碼。

當需考慮性能時，這種做法就存在問題。所有的Web請求最初都是以UTF8編碼的，需要在被.NET理解前轉(zhuǎn)化為UTF16編碼。反之，所有來自.NET服務器的響應，需要由UTF16編碼轉(zhuǎn)化為UTF8編碼。

現(xiàn)在已有一些建議方法，意在消除這種轉(zhuǎn)換的必要。一種做法創(chuàng)建了Utf8String類并匹配字符串處理庫，之后就可以新建直接操作類的解析庫。這一做法是完全“明確征得同意”（Opt In）的，因此風險很低。

更全面的建議是由Matt Warren提出的，稱為“緊湊字符串（Compact String）實現(xiàn)”。該建議受到了OpenJDK中類似建議的啟發(fā)，它會在字符串中添加一個類型字段，用于指示所使用的編碼。這是一種更大程度上的更改，對Span<T>存在一些負面影響。

原文地址：http://www.infoq.com/cn/news/2017/05/ASPNET-Core-2b

---

.NET社區(qū)新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關(guān)注

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎勵來咯，堅持創(chuàng)作打卡瓜分現(xiàn)金大獎

總結(jié)

以上是生活随笔為你收集整理的ASP.NET Core改进了.NET Framework中的字符串处理的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。