type - C#中字符串和字符串有什麼區別?

String（ System.String ）是基類庫中的一個類。 string（小寫）是C＃中的保留工作，它是System.String的別名。 Int32 vs int與Boolean vs. bool類似。 這些特定於C＃語言的關鍵字使您能夠以類似於C的樣式聲明基元。

此YouTube視頻實際上展示了它們的不同之處。

但現在需要很長的文字答案。

當我們談論.NET ，有兩種不同的東西，一種是.NET框架，另一種是使用該框架的語言（ C# ， VB.NET等）。

“ System.String ”又名“String”（大寫“S”）是.NET框架數據類型，而“string”是C#數據類型。

簡而言之，“String”是“string”的別名（使用不同的名稱調用相同的東西）。 因此從技術上講，下面的代碼語句都會提供相同的輸出。

String s = "I am String";

要么

string s = "I am String";

同樣，其他c＃數據類型也有別名，如下所示： -

object： System.Object ，string： System.String ，bool： System.Boolean ，byte： System.Byte ，sbyte： System.SByte ，short： System.Int16等等

現在從程序員的角度來看百萬美元的問題那麼何時使用“String”和“string”？

避免混淆的第一件事是始終如一地使用其中一個。 但是從最佳實踐角度來看，當你進行變量聲明時，最好使用“string”（小“s”），當你使用它作為類名時，首選“String”（大寫“S”）。

在下面的代碼中，左側是變量聲明，它使用“string”聲明。 在右側，我們調用一種方法，因此“字符串”更明智。

string s = String.ToUpper() ;

string是C＃for System.String的別名。
從技術上講，沒有區別。 這就像int 與 System.Int32 。

就指南而言，通常建議您在引用對象時使用string 。

例如

string place = "world";

同樣，我認為如果您需要專門引用該類，通常建議使用String 。

例如

string greet = String.Format("Hello {0}!", place);

這是Microsoft在其示例中傾向於使用的樣式。

看來這個領域的指導可能已經改變，因為StyleCop現在強制使用C＃特定的別名。

String代表System.String ，它是.NET Framework類型。 string是 System.String的C＃語言中的別名 。 它們都被編譯為IL （中間語言）中的System.String ，因此沒有區別。 選擇你喜歡的並使用它。 如果你用C＃編碼，我更喜歡string因為它是C＃類型的別名，並且是C＃程序員所熟知的。

關於（ int ， System.Int32 ）等我可以這麼說。

System.String是.NET字符串類 - 在C＃ string是System.String的別名 - 因此在使用中它們是相同的。

至於指導方針，我不會陷入困境，只是使用你想要的任何東西 - 生活中有更重要的事情，無論如何代碼都是一樣的。

如果你發現你自己構建系統，你需要指定你正在使用的整數的大小，因此傾向於使用Int16 ， Int32 ， UInt16 ， UInt32等，那麼使用String可能看起來更自然 - 並且當它們在不同之間移動時.net語言可能會使事情更容易理解 - 否則我會使用string和int。

string和String在所有方面都相同（大寫“S”除外）。 無論如何都沒有性能影響。

由於語法高亮，大多數項目中首選小寫string

string是System.String的別名（或簡寫）。 這意味著，通過鍵入string我們的意思是System.String 。 您可以在思考鏈接中閱讀更多內容： 'string'是System.String的別名/簡寫。

string是關鍵字，您不能使用string作為標識符。

String不是關鍵字，您可以將其用作標識符：

例

string String = "I am a string";

除關鍵字問題外，關鍵字string是別名System.String，兩者完全等效。

 typeof(string) == typeof(String) == typeof(System.String)

有一個區別 - 你不能在不使用using System;情況下使用String using System; 預先。

僅僅為了完整起見，這裡是相關信息的大腦轉儲......

正如其他人所說， string是System.String的別名。 它們編譯為相同的代碼，因此在執行時沒有任何區別。 這只是C＃中的別名之一。 完整清單是：

object:  System.Object
string:  System.String
bool:    System.Boolean
byte:    System.Byte
sbyte:   System.SByte
short:   System.Int16
ushort:  System.UInt16
int:     System.Int32
uint:    System.UInt32
long:    System.Int64
ulong:   System.UInt64
float:   System.Single
double:  System.Double
decimal: System.Decimal
char:    System.Char

除了string和object ，別名都是值類型。 decimal是值類型，但不是CLR中的基本類型。 唯一沒有別名的原始類型是System.IntPtr 。

在規範中，值類型別名稱為“簡單類型”。 文字可用於每種簡單類型的常量值; 沒有其他值類型具有可用的文字形式。 （將其與允許DateTime文字的VB進行比較，並且也具有別名。）

在某種情況下，您必須使用別名：明確指定枚舉的基礎類型時。 例如：

public enum Foo : UInt32 {} // Invalid
public enum Bar : uint   {} // Valid

這只是規範定義枚舉聲明的方式問題 - 冒號之後的部分必須是整數型生成，這是sbyte ， byte ， short ， ushort ， int ， uint ， long ， ulong ， char一個標記。 ..而不是例如變量聲明所使用的類型生產。 它並不表示任何其他差異。

最後，當談到使用它時：我個人在各處使用別名來實現，但是任何API都使用CLR類型。 你在實施方面使用它並不重要 - 你的團隊之間的一致性很好，但沒有人會關心。 另一方面，如果您在API中引用類型，則以語言中立的方式執行此操作，這一點非常重要。 名為ReadInt32的方法是明確的，而名為ReadInt的方法需要解釋。 例如，調用者可能正在使用為Int16定義int別名的語言。 .NET框架設計者已經遵循這種模式，在BitConverter ， BinaryReader和Convert類中有很好的例子。

兩者都是一樣的。 但從編碼指南的角度來看，最好使用string而不是String 。 這是開發人員通常使用的。 例如，我不使用Int32而是使用int因為int是Int32別名

FYI“關鍵字字符串只是預定義類System.String的別名。” - C＃語言規範4.2.3 http://msdn2.microsoft.com/En-US/library/aa691153.aspx

它已在上面介紹過; 但是，你不能在反射中使用string ; 你必須使用String 。

對於其他程序員似乎常見的做法，我更喜歡String over string ，只是為了強調String是一個引用類型，正如Jon Skeet所提到的那樣。

我想在Ritchers的書中將這個添加到lfousts回答中：

C＃語言規範指出，“作為一種風格，使用關鍵字比使用完整的系統類型名稱更受歡迎。”我不同意語言規範; 我更喜歡使用FCL類型名稱並完全避免基本類型名稱。實際上，我希望編譯器甚至不提供原始類型名稱，並強迫開發人員使用FCL類型名稱。以下是我的理由：

在我閱讀完整段落之前，我沒有得到他的意見。

我聽說過在C＃中使用提供的類型別名的最佳答案來自Jeffrey Richter在他的書CLR Via C＃中 。 以下是他的3個理由：

• 我見過許多開發人員感到困惑，不知道是否在代碼中使用字符串或字符串 。 因為在C＃中，字符串（關鍵字）完全映射到System.String（一種FCL類型），所以沒有區別，可以使用它們。
• 在C＃中， 長映射到System.Int64 ，但是在不同的編程語言中， long可以映射到Int16或Int32 。 事實上，C ++ / CLI確實將long視為Int32 。 如果某人使用一種語言閱讀源代碼，如果他或她習慣於使用不同的編程語言進行編程，則很容易誤解代碼的意圖。 實際上，大多數語言甚至不會將long視為關鍵字，也不會編譯使用它的代碼。
• FCL有許多方法，它們將類型名稱作為其方法名稱的一部分。 例如， BinaryReader類型提供諸如ReadBoolean ， ReadInt32 ， ReadSingle等方法，而System.Convert類型提供諸如ToBoolean ， ToInt32 ， ToSingle等方法。 雖然編寫下面的代碼是合法的，但浮點線對我來說感覺非常不自然，並且線條不正確並不明顯：

BinaryReader br = new BinaryReader(...);
float val  = br.ReadSingle(); // OK, but feels unnatural
Single val = br.ReadSingle(); // OK and feels good

所以你有它。 我認為這些都非常好。 但是，我發現自己在自己的代碼中沒有使用Jeffrey的建議。 也許我太困在我的C＃世界，但我最終試圖使我的代碼看起來像框架代碼。

沒有區別。

C＃關鍵字string映射到.NET類型System.String- 它是一個保持語言命名約定的別名。

同樣，int映射到System.Int32。

聚會遲到：我100％使用CLR類型（好吧，除非被迫使用C＃類型，但我不記得最後一次是什麼時候）。

根據Ritchie的CLR書籍，我最初幾年前開始做這件事。 我認為所有CLR語言最終都必須能夠支持CLR類型集合，因此使用CLR類型本身提供了更清晰，可能更“可重用”的代碼。

現在我已經做了多年，這是一種習慣，我喜歡VS為CLR類型顯示的顏色。

唯一真正的失敗是自動完成使用C＃類型，所以我最終重新鍵入自動生成的類型來指定CLR類型。

而且，現在，當我看到“int”或“string”時，我看起來真的不對，就像我在看1970年的C代碼一樣。

兩者之間沒有區別 - string但是，在考慮其他開發人員的源代碼時，似乎是首選方案。

是的，他們之間沒有區別，就像bool和Boolean。