看到黑暗有一個關於中文難字的繁簡轉換處理的文章, 先記錄部份在這裡.

http://blog.darkthread.net/post-2015-03-06-strconv-half-full-width-notes.aspx

      var ncrString = toNCR("黑暗執行緒犇ＡＢＣ１２３");
      Debug.WriteLine(ncrString); //黑暗執行緒犇ＡＢＣ１２３
      var convString = Microsoft.VisualBasic.Strings.StrConv(
        ncrString, Microsoft.VisualBasic.VbStrConv.Narrow, 1028);
      Debug.WriteLine(convString); //黑暗执行绪犇ABC123
      var resultString = fromNCR(convString);
      Debug.WriteLine(resultString); //黑暗执行绪犇ABC123


    static string toNCR(string input)
    {  
      StringBuilder sb = new StringBuilder();
      Encoding big5 = Encoding.GetEncoding("big5");
      foreach (char c in input)
      {
        //強迫轉碼成Big5，看會不會變成問號
        string cInBig5 = big5.GetString(big5.GetBytes(new char[] {c}));
        //原來不是問號，轉碼後變問號，判定為難字
        if (c!='?' && cInBig5=="?")
          sb.AppendFormat("&#{0};", Convert.ToInt32(c));
        else
          sb.Append(c);
      }
      return sb.ToString();
    }
 
    static string fromNCR(string input)
    {
      return Regex.Replace(input, "&#(?<ncr>\\d+?);", (m) =>
      {
        return Convert.ToChar(int.Parse(m.Groups["ncr"].Value)).ToString();
      });
    }

寫一下, 以備不時之需, Codepage 和 Name 可以用來取得 encoding.
CodePage, DisplayName, Name
37, IBM EBCDIC (美國-加拿大), IBM037
437, OEM 美國, IBM437
500, IBM EBCDIC (國際), IBM500
708, 阿拉伯文 (ASMO 708), ASMO-708
720, 阿拉伯文 (DOS), DOS-720
737, 希臘文 (DOS), ibm737
775, 波羅的海文 (DOS), ibm775
850, 西歐語系 (DOS), ibm850
852, 中歐語系 (DOS), ibm852
855, OEM 斯拉夫文, IBM855
857, 土耳其文 (DOS), ibm857
858, OEM 多語系拉丁文 I, IBM00858
860, 葡萄牙文 (DOS), IBM860
861, 冰島文 (DOS), ibm861
862, 希伯來文 (DOS), DOS-862
863, 加拿大法文 (DOS), IBM863
864, 阿拉伯文 (864), IBM864
865, 北歐字母 (DOS), IBM865
866, 斯拉夫文 (DOS), cp866
869, 希臘文，現代 (DOS), ibm869
870, IBM EBCDIC (多語系拉丁文 2), IBM870
874, 泰文 (Windows), windows-874
875, IBM EBCDIC (希臘現代), cp875
932, 日文 (Shift-JIS), shift_jis
936, 簡體中文 (GB2312), gb2312
949, 韓文, ks_c_5601-1987
950, 繁體中文 (Big5), big5
1026, IBM EBCDIC (土耳其拉丁文 5), IBM1026
1047, IBM 拉丁文 1, IBM01047
1140, IBM EBCDIC (美國-加拿大-歐洲), IBM01140
1141, IBM EBCDIC (德國-歐洲), IBM01141
1142, IBM EBCDIC (丹麥-挪威-歐洲), IBM01142
1143, IBM EBCDIC (芬蘭-瑞典-歐洲), IBM01143
1144, IBM EBCDIC (義大利-歐洲), IBM01144
1145, IBM EBCDIC (西班牙-歐洲), IBM01145
1146, IBM EBCDIC (英國-歐洲), IBM01146
1147, IBM EBCDIC (法國-歐洲), IBM01147
1148, IBM EBCDIC (國際-歐洲), IBM01148
1149, IBM EBCDIC (冰島-歐洲), IBM01149
1200, Unicode, utf-16
1201, Unicode (位元組由大到小), utf-16BE
1250, 中歐語系 (Windows), windows-1250
1251, 斯拉夫文 (Windows), windows-1251
1252, 西歐語系 (Windows), Windows-1252
1253, 希臘文 (Windows), windows-1253
1254, 土耳其文 (Windows), windows-1254
1255, 希伯來文 (Windows), windows-1255
1256, 阿拉伯文 (Windows), windows-1256
1257, 波羅的海文 (Windows), windows-1257
1258, 越南文 (Windows), windows-1258
1361, 韓文 (Johab), Johab
10000, 西歐語系 (Mac), macintosh
10001, 日文 (Mac), x-mac-japanese
10002, 繁體中文 (Mac), x-mac-chinesetrad
10003, 韓文 (Mac), x-mac-korean
10004, 阿拉伯文 (Mac), x-mac-arabic
10005, 希伯來文 (Mac), x-mac-hebrew
10006, 希臘文 (Mac), x-mac-greek
10007, 斯拉夫文 (Mac), x-mac-cyrillic
10008, 簡體中文 (Mac), x-mac-chinesesimp
10010, 羅馬尼亞文 (Mac), x-mac-romanian
10017, 烏克蘭文 (Mac), x-mac-ukrainian
10021, 泰文 (Mac), x-mac-thai
10029, 中歐語系 (Mac), x-mac-ce
10079, 冰島文 (Mac), x-mac-icelandic
10081, 土耳其文 (Mac), x-mac-turkish
10082, 克羅埃西亞文 (Mac), x-mac-croatian
12000, Unicode (UTF-32), utf-32
12001, Unicode (UTF-32 位元組由大到小), utf-32BE
20000, 繁體中文 (CNS), x-Chinese-CNS
20001, TCA 台灣, x-cp20001
20002, 繁體中文 (Eten), x-Chinese-Eten
20003, IBM5550 台灣, x-cp20003
20004, TeleText 台灣, x-cp20004
20005, Wang 台灣, x-cp20005
20105, 西歐語系 (IA5), x-IA5
20106, 德文 (IA5), x-IA5-German
20107, 瑞典文 (IA5), x-IA5-Swedish
20108, 挪威文 (IA5), x-IA5-Norwegian
20127, US-ASCII, us-ascii
20261, T.61, x-cp20261
20269, ISO-6937, x-cp20269
20273, IBM EBCDIC (德國), IBM273
20277, IBM EBCDIC (丹麥-挪威), IBM277
20278, IBM EBCDIC (芬蘭-瑞典), IBM278
20280, IBM EBCDIC (義大利), IBM280
20284, IBM EBCDIC (西班牙), IBM284
20285, IBM EBCDIC (UK), IBM285
20290, IBM EBCDIC (日文片假名), IBM290
20297, IBM EBCDIC (法國), IBM297
20420, IBM EBCDIC (阿拉伯文), IBM420
20423, IBM EBCDIC (希臘文), IBM423
20424, IBM EBCDIC (希伯來文), IBM424
20833, IBM EBCDIC (韓文擴充), x-EBCDIC-KoreanExtended
20838, IBM EBCDIC (泰國), IBM-Thai
20866, 斯拉夫文 (KOI8-R), koi8-r
20871, IBM EBCDIC (冰島), IBM871
20880, IBM EBCDIC (斯拉夫俄文), IBM880
20905, IBM EBCDIC (土耳其), IBM905
20924, IBM 拉丁文 1, IBM00924
20932, 日文 (JIS 0208-1990 和 0212-1990), EUC-JP
20936, 簡體中文 (GB2312-80), x-cp20936
20949, 韓文 Wansung, x-cp20949
21025, IBM EBCDIC (斯拉夫塞爾維亞文-保加利亞文), cp1025
21866, 斯拉夫文 (KOI8-U), koi8-u
28591, 西歐語系 (ISO), iso-8859-1
28592, 中歐語系 (ISO), iso-8859-2
28593, 拉丁文 3 (ISO), iso-8859-3
28594, 波羅的海文 (ISO), iso-8859-4
28595, 斯拉夫文 (ISO), iso-8859-5
28596, 阿拉伯文 (ISO), iso-8859-6
28597, 希臘文 (ISO), iso-8859-7
28598, 希伯來文 (ISO-Visual), iso-8859-8
28599, 土耳其文 (ISO), iso-8859-9
28603, 愛沙尼亞文 (ISO), iso-8859-13
28605, 拉丁文 9 (ISO), iso-8859-15
29001, 歐洲, x-Europa
38598, 希伯來文 (ISO-Logical), iso-8859-8-i
50220, 日文 (JIS), iso-2022-jp
50221, 日文 (JIS-Allow 1 byte Kana), csISO2022JP
50222, 日文 (JIS-Allow 1 byte Kana - SO/SI), iso-2022-jp
50225, 韓文 (ISO), iso-2022-kr
50227, 簡體中文 (ISO-2022), x-cp50227
51932, 日文 (EUC), euc-jp
51936, 簡體中文 (EUC), EUC-CN
51949, 韓文 (EUC), euc-kr
52936, 簡體中文 (HZ), hz-gb-2312
54936, 簡體中文 (GB18030), GB18030
57002, ISCII 梵文語系, x-iscii-de
57003, ISCII 孟加拉文, x-iscii-be
57004, ISCII 坦米爾文, x-iscii-ta
57005, ISCII 特拉古文, x-iscii-te
57006, ISCII 阿薩姆文, x-iscii-as
57007, ISCII 歐利亞文, x-iscii-or
57008, ISCII 坎那達文, x-iscii-ka
57009, ISCII 馬來亞拉姆文, x-iscii-ma
57010, ISCII 古吉拉特文, x-iscii-gu
57011, ISCII 旁遮普語, x-iscii-pa
65000, Unicode (UTF-7), utf-7
65001, Unicode (UTF-8), utf-8

20211102 補充一下 (下面網址可以下載工具調整 reg)
Nartac Software - IIS Crypto
--------------------------
網路上有一些工具可以看出網站SSL連線是不是安全  這是我測試的結果 (用 www.nalimay.com 測試)







看樣子主要是支援舊的 SSL 2.0 SSL 3.0 造成 F 等級，所以網路上搜尋一下
​發現IIS 要改 registry 資料(也就是把一些設定關掉 一些定打開) 然後重新開機才會升級  
請參考附件   升級後就好一點了  變 B ，換成另外一種警告  有空再看看如何解，








 

自從 8/1 起 shopunt 就呈現奇怪的現象



基本上是每日半夜12點流量暴增 (peak 到 80mb)，然後逐漸下降，到了 5~6點又慢慢爬升，直到 10 點以後就驟降

基本上，網站沒有掛掉，沒有太多Exception，LB兩台server的流量很平均，Server Diff 查也沒有過多的Session
可以排除被攻擊的可能性

為了找問題，只好從 IIS Log著手......
1. 首先，查詢12點有甚麼網頁或網址異常多點擊數，並且比較 11 點與 12點兩者差異，結果都沒有任何異常
    卻意外發現有家廣告合作廠商半夜會來抓產品圖，只是這個流量不大，發生點也不是在12點整，不是兇手
2. 起先因為 IIS log 沒有設定 sc-bytes 這個屬性，只有 time-taken 屬性，發現有些圖片 load 的特別久，但還是無法確定問題，所以想說把 sc-bytes 加到 IIS log 再來觀察
3. 加了 sc-bytes 之後的 IIS log，才發現驚人的事實，有幾張圖片竟然高達好幾MB，最大張是放在周年慶的 landing 圖片，竟高達 7.8MB



光1小時，一張圖片吃掉 8.6GB 的量，換算平均值約 13 mb/sec , OMG!
趕緊請設計把圖片換掉

只是這樣，還是有一個奇怪現象，為何半夜12點流量暴增，早上 10 點流量驟減?


這是禍首最大張圖片的點擊數統計(時間是GMT，16是半夜12點, 15是晚上11點)，
就跟流量圖一樣，00~10 點擊數很高，其他時間很低
下面是這張圖片所屬頁面的點擊數統計 (/tch/fixpage.aspx?id=689)



從圖片點擊數看來，我以為是 ISP 某種 transparent proxy cache 發揮作用 (半夜 00~10點關閉 所以流量增加)，
但是看到 fixpage.aspx 的點擊數也是一樣的狀況，我就不知道該怎麼解釋了??
ISP transparent proxy 也會處理 *.aspx ?? 

還是回歸到最基本的原因，網站的廣告曝光量是 00~10點最高??

 

半夜被老闆 Line，跟我說網頁發生錯誤，他無法看統計報表，會出現作業逾時的錯誤 我查了一下網頁程式，發現是這筆SQL指令跑太久

 Select Id, (IsNull(Total, 0) - IsNull(CouponDiscount, 0) + IsNull(CouponAdd, 0)) as Total, Buyer_Email, EN_Packing_List_Status, EN_Order_Source, En_Stock_Status, Create_Date

From V_Order_main With(Nolock)

Where Id in (select Order_Id from Ad_Trace With(NoLock) where (Parameter_Id = 14278))

AND Create_Date >= '2014/10/3' And Create_Date < '2014/10/12' 

--> 跑了50秒~ 1分鐘

 Select Id, (IsNull(Total, 0) - IsNull(CouponDiscount, 0) + IsNull(CouponAdd, 0)) as Total, Buyer_Email, EN_Packing_List_Status, EN_Order_Source, En_Stock_Status, Create_Date

From V_Order_main With(Nolock)

Where Id in (select Order_Id from Ad_Trace With(NoLock) where (Parameter_Id = 14278))

--> 拿掉日期限制 > 秒殺，  結果跑出 47 筆資料

跑一下執行計畫 原來子查詢的 Ad_Trace 沒有建立Index造成


加上 Index 之後，再跑第一支SQL --> 秒殺

奇怪的地方:
明明訂單日期欄位(Create_Date) 跟 Ad_Trace 沒有多大關係，但是加上日期限制之後，居然會引發 Ad_Trace 搜尋過久的現象
他好像是先依照訂單日期找出所有訂單，然後再從子查詢 Ad_Trace 裡面搜尋有無符合的條件訂單
而不是先跑子查詢找出 Ad_Trace 所有的 Order_Id，再去找符合 Create_Date 的訂單

SQL內部運作的機制真是有點讓人想不透，幸好有評估計畫可以看出問題在哪裡
這讓我想起以前學SQL時的一句話 => 盡量用Join來取代子查詢
使用子查詢真的是效能殺手啊

------繼續補充--------------------------------------

上面的SQL在雙11活動後，由於當日訂單過多，一樣造成SQL timeout 的現象，研判還是子查詢造成的問題

Select Id, (IsNull(Total, 0) - IsNull(CouponDiscount, 0) + IsNull(CouponAdd, 0)) as Total, Buyer_Email, EN_Packing_List_Status, EN_Order_Source, En_Stock_Status, Create_Date

From V_Order_main With(Nolock)

Where Id in (select Order_Id from Ad_Trace With(NoLock) where (Parameter_Id = 14720))

And Create_Date > '2014-11-10' And Create_Date < '2014-11-11'

--> 跑了51秒

所以先將子查詢拿出來跑出一串字串 865828,865890,865901,865903,865928,865955,865990,865993,866005,866035.....
(共1452筆)
再把他拼入sql跑   --> 7秒
 

建置


想使用 SQL Server的全文檢索功能，先去[控制台][系統管理工具][服務]看以下兩項服務是否有啟動：
1. SQL Full-Text Filter Daemon Launcher(MSSQLSERVER)：建立 fdhost.exe處理序的服務，這是主控處理全文檢索索引之文字資料的斷詞工具與篩選的必要項目。
2. SQL Server Agent(MSSQLSERVER)：透過 SQL Server Agent作業的排程，啟動全文檢索－索引母體的擴展，累加資料表母體擴展。

如果沒有啟動第一項服務(SQL Full-Text...)，直接進行 Select全文查詢，會出現錯誤訊息如下：
SQL Server在與全文篩選器的後台程序宿主(FDHOST)的進程通信時遇到錯誤0x80070218。
請確保 FDHOST進程正在運行。若要重新啟動FDHOST進程，請運行 sp_fulltext_service 'restart_all_fdhosts' 的命令或重新啟動 SQL Server實例。

參考網址：
http://blog.xuite.net/sugopili/computerblog/76684376-SQL+Server%E5%85%A8%E6%96%87%E6%AA%A2%E7%B4%A2%E5%B0%8F%E6%8A%80%E5%B7%A7

使用 & 設定
設定
看網址
使用

設定全文檢索並以建立索引後，就可以透過條件 WHERE CONTAINS(欄位,搜尋的字)的方式，
來做全文檢索的查詢方式，下面範例程式碼， 依序介紹平常使用Like及全文檢索下CONTAINS用法。

參考網址：
http://www.dotblogs.com.tw/dotjum/archive/2009/08/01/9796.aspx

1. 打開 Service/Firewall
 

2. 按下最上方的 +
 

3. 填入 source 並把 Action 改為 Deny，再按下右上方的 "Apply" 即可。 
 
 

SELECT cast(ProductID AS NVARCHAR ) + ',' from [Order Details]

where OrderID = '10248'

FOR XML PATH('')

參考: http://www.dotblogs.com.tw/kevinya/archive/2012/06/01/72553.aspx

EX:

SELECT ',' + ltpid

FROM V_ltp_main WHERE ltpkind = 2

FOR XML PATH('')

STUFF ( character_expression , start , length ,character_expression )
下列範例會傳回從第一個字串 (abcdef) 中，從位置 2 (b) 開始，刪除三個字元所建立的字元字串，且會在刪除點插入第二個字串。

SELECT STUFF('abcdef', 2, 3, 'ijklmn')

http://technet.microsoft.com/zh-tw/library/ms188043(v=sql.105).aspx

EX:

select STUFF(

(SELECT ',' + ltpid FROM V_ltp_main WHERE ltpkind = 2 FOR XML PATH(''))

, 1, 1, '')

 

要記得打開 "顥示所有設定"