C# 字串與正規表達式完整指南：格式化、操作、StringBuilder、Regex 實戰

一、字串基礎

.NET 中 string（System.String）為不可變參考類型，每次修改（連接、替換、Substring）都會建立新物件。宣告方式：

string s1 = "Hello";
string s2 = null;
string s3 = s1; // 參考同一物件

二、字串格式化

1. 複合格式化 string.Format

string fmt = string.Format("Value: {0:C}, Date: {1:yyyy-MM-dd}", 1234.5, DateTime.Now);
// Value: $1,234.50, Date: 2024-01-15

格式項語法：{index[,alignment][:formatString]}

2. 常用日期時間格式指定符

3. 數值自訂格式

double d = 1234.5;
string.Format("{0:#,##0.00}", d);     // 1,234.50
string.Format("{0:0.00%}", 0.234);    // 23.40%
string.Format("{0:$#,##0.00;($#,##0.00);Zero}", -56.78); // ($56.78)

分號分隔：正數格式;負數格式;零值格式

三、字串操作與比較

範例

string s = " Mary Had a Little Lamb ";
Console.WriteLine(s.Trim());                    // "Mary Had a Little Lamb"
Console.WriteLine(s.Split(' ')[3]);             // "Little"
Console.WriteLine(s.ToLower());                 // " mary had a little lamb "

四、StringBuilder：高效能字串建構

適用於大量連接、迴圈累加場景，避免產生大量暫時字串物件。

var sb = new StringBuilder();
sb.Append("Greetings!\n");
sb.AppendFormat("Price: {0:C}", 129.99);
sb.AppendLine("Big concatenated string.");
Console.WriteLine(sb.ToString());

關鍵方法：Append、AppendLine、AppendFormat、Insert、Remove、Replace、Clear、ToString()

五、正規表達式

命名空間：System.Text.RegularExpressions

1. 驗證輸入 Regex.IsMatch

string emailPattern = @"^[\w-\.]+@([\w-]+\.)+[\w-]{2,4}$";
bool valid = Regex.IsMatch("test@example.com", emailPattern); // true

2. 提取資料：群組與 Match/Matches

string urlPattern = @"^(?\w+)://[^/]+?(?:\d+)?/";
var url = "https://server.com:2100/home.aspx";
var m = Regex.Match(url, urlPattern);
if (m.Success) {
    Console.WriteLine(m.Groups["proto"].Value); // http
    Console.WriteLine(m.Groups["port"].Value);  // :2100
}

3. 取代 Regex.Replace

string input = "Order 123, Order 456";
string result = Regex.Replace(input, @"\d+", "###"); // "Order ###, Order ###"

4. 常用 RegexOptions

• IgnoreCase：忽略大小寫
• Compiled：編譯為 IL，重複使用提升效能
• Singleline：. 包含換行
• Multiline：^/$ 匹配行首尾

六、總結

• 字串不可變 → 大量操作用 StringBuilder
• 格式化用 string.Format 或插值字串 $"..." (C# 6+)
• 正規表達式功能強大，但複雜模式需註解、測試，避免效能陷阱（災難性回溯）
• 驗證 Email/URL/電話等常用模式，建議採用成熟庫或標準規範（如 RFC 5322）