@在C# String的使用

1. C# 中 字串常量可以以 @ 開頭聲名，這樣的優點是逸出序列“不”被處理，按“原樣”輸出，即我們不需要對逸出字元加上 （反斜扛），就可以輕鬆coding。如
string filePath = @"c:DocsSourcea.txt"; // rather than "c:DocsSourcea.txt"

2. 如要在一個用 @ 引起來的字串中包括一個雙引號，就需要使用兩對雙引號了。
這時候你不能使用 來轉義雙引號了，因為在這裡 的轉義用途已經被 @ “屏蔽”掉了。如
@"""Ahoy!"" cried the captain."; // 輸出為： "Ahoy!" cried the captain.

有點像SQL中的單引號常量處理方式：
DECLARE @msg varchar(100)
SET @msg = ''Ahoy!'' cried the captain.' -- 輸出為： 'Ahoy!' cried the captain.

 

3. @ 會識別分行符號
其實這個特性，我不知道怎麼描述，只是偶然發現的，先看下面的代碼吧：
string script = @"
            <script type=""type/javascript"">
            function doSomething()
            {
            }
            </script>";

 

在cs檔案中寫js，結構就很清晰了，正常情況我們是這樣coding的：
string script2 = "<script type="type/javascript">function doSomething(){}</script>";
// or
string script3 =
            "<script type="type/javascript">" +
            "function doSomething(){ " +
            "}</script>";

通常我們會選擇後者，因為js代碼一般比較長，或者方法體很大，或者需要串連其他變數，這樣結構比較清晰。
注意：如果“拼接”的次數很多，應該考慮使用StringBuilder了，有助於提高效能。
還有一種情境，也很常見，在程式中拼接 SQL 陳述式，如
private const string SQL_INS_USER = @"
            INSERT INTO t_User([UserName], [Password], Email)
                        VALUES(@UserName, @Password, @Email)";

然而，我們需要關注一個問題：字串長度
看下面的測試代碼：
private const string SQL_INS_USER1 = @"
        INSERT INTO t_User([UserName], [Password], Email)
                    VALUES(@UserName, @Password, @Email)";
private const string SQL_INS_USER2 = @"INSERT INTO t_User([UserName], [Password], Email)
                    VALUES(@UserName, @Password, @Email)";

private const string SQL_INS_USER3 = @"INSERT INTO t_User([UserName], [Password], Email)
                                     VALUES(@UserName, @Password, @Email)";

static void Main(string[] args)
{
    Console.WriteLine(SQL_INS_USER1.Length); // 126
    Console.WriteLine(SQL_INS_USER2.Length); // 112
    Console.WriteLine(SQL_INS_USER3.Length); // 86
}

可以看到三個字串長度分別相差了，14=126-112和26=112-86，在代碼編輯器中，SQL_INS_USER1
中第一個分行符號號之後，縮排13個空格（INSERT之前），而
SQL_INS_USER2 中第一個分行符號號之後，縮排25個空格（VALUES之前），
那麼，加上一個分行符號，剛剛好 14和26

如此編寫代碼，雖然提高了代碼的清晰度和簡便性，卻無行中帶來了另一個問題：字元長度！
很多情境下我們希望字串越短越好，如，通過ADO.NET 發送 SQL 陳述式給資料庫執行。
所以還是慎用之！

 

引自:

http://space.baidu.com/jy02206644/blog/item/e311c6cf0478e130b700c8d5.html