ASRock 880GMH-LE/USB3 當機要按 reset

ASRock 880GMH-LE/USB3 藍屏當機後，長按電源開關關機。重開機後發現只能用 DOS，Win7 或 XP 都在啟動過程中藍屏當機自動重開。

跑 Win7 RAM test 沒問題... 反正依 boot 順序檢查各種可能都排除問題，程序不多，可是每次藍屏當機後重開要跑 disk check 浪費很多時間。後來在 BIOS self-test 訊息中忽然發現，幾時我的 X3 變成 X4 了？最最基本的沒看到，萬萬沒想到 BIOS 設定沒跑掉但卻自動開核！

ASRock 華擎 Turbo UCC「一鍵超核」： 當您在電腦開機時按下「X」鍵，系統即會自動重新啟動。之後，系統將運行 UCC 功能。開啟 UCC 功能後，可自動幫助您解鎖額外的 CPU 核心，讓您享受即時的 CPU 性能飛躍。
在電腦開機時按下「D」鍵取消超核。

而一開始藍屏當機原因：1. RAM SPD 1.5V，BIOS 設 Auto 會給 1.65V，因此手動設成 1.5V，可能因 power 電壓不穩當機。改回 Auto 看看。2. 經常是在 XP disk I/O 時當掉：driver、chipset 過熱(42~45度)、sata 線、HD 都有嫌疑。3. power 不穩，省錢沒辦法。

為何一開始藍屏當機後，按電源開關關機而不按 reset：因為藍屏當機後按 reset，硬碟似乎是正在存取鎖住，SMART 要等一會兒才開始。

用勾表測電腦耗電量DIY

市面上有一些方便的產品可以測電器的耗電量，像是瓦數監控延長線(還是日本大廠Sanwa出的)--附瓦特計的延長線；或是電源監測器(變電家)。我是選擇用勾表量測出交流電流來計算。基本的原理都是 W(功率) = IV (電流*電壓)，測出電流就可以算出功率。雖然交流電必須再計算功率因子PF，但台電對家用電費不計較虛功，所以可以簡單用 測出交流電流 * 110V 得到功率，但須記得電腦的瓦數遠大於計算，一般電腦 PF 約 0.5~0.7。

***注意：電學不懂，或是不知道何為火線水線(實務不懂)，或是不知道插座小孔是接哪一線(實務隨便)，請千萬不要DIY。電力危險非同小可，早年無知電死許多人，電線走火是火災主因！***

首先必須去買個精度能達到 0.01A 的勾表。大廠出的勾表精度夠，但成千上萬很貴。我是在露天買的 DT-200，一開始還買錯了買到 DT-266，大容量可量到1000A但精度只到0.1A，不合用。感謝starshop無償換貨還指導如何使用。這支 DT-200 雖然便宜(光附的攜行包一般相機包就大約那個價錢)，但精度還是達到 0.01A (讀數誤差2.5%)，俗又大碗。

再來必須自製一條延長線，電線必須分開：火線、水線(地線)是可以分開單股的，專門用來量電流。因為勾表測電流是利用霍爾效應電磁感應，必須只勾住火線或水線單股，盡量保持垂直在中央等等在誤差範圍內 對我們的應用沒差。

然後電腦接到延長線，勾表勾住火線或水線開始量了。以下皆為電流 A：

Pentium3-733 + nVidia TNT2M64
關機 0.02 工作 0.54 ~ 0.78 (60~86W)
可以拿來當動物機

PF775 CRT
待機 0.01 工作 (黑)0.64 (白)0.79 (70~87W)
CRT背景設成黑色比較省電

Pentium3-733 + nVidia FX5600XT + SCSI 燒錄機
關機 0.01 工作 0.77 ~ 1.02 (85~112W)
SCSI 燒錄機沒用要拔掉

IBM 17" LCD
待機 0.00 工作 (黑、白)0.26 (29W)
LCD顏色沒差都很省

Asus VW225TL 22" LCD
待機 0.00 工作 (全黑)0.22 (白)0.19 (一般)0.20 (21~24W)
這台最省電，還有喇叭(小瓦數音質破爛)

X3-450
待機 0.01 開機 1.83 工作 (怠速)0.83 (全速)1.63 (91~180W)
設最小電源後：
怠速 0.65(72W)
FireFox上網 0.85(94W)
720p影片 0.81~0.90(89~99W)
無雙蛇魔 1.32(145W)
全速 1.48(163W)
開機最耗電201W，多出20W是硬碟吧。每瓦計算力還是高出 Pentium3 數倍。

TERA DK-1206MR 電扇
弱 0.26 (29W) 中 0.32 (35W) 強 0.43 (47W) 擺頭馬達 +0.02 (約2W)
電扇比日光燈還省電！這支泰瑞的遙控電扇很好，可以遙控擺頭，十幾年前買的才七百多，現在極少看到有遙控電扇可以遙控擺頭的。

刪除 Yahoo! RD

Yahoo! RD 就是 global.ard.yahoo.com/SIG=...*URL
tw.ard.yahoo.com/SIG=...*URL
tw.rd.yahoo.com/referurl/...*URL
諸如此類的落落長 Yahoo 轉址。

不管 Yahoo 是要衝 Alexa 流量排行，還是要追蹤用戶行為，都是他的自由；我覺得好像不好，世上真正更不好的事何其多，其實我反抗意識不要那麼強，Yahoo 速度還是很快，沒必要在 hosts 設 127.0.0.1 tw.rd.yahoo.com 等等讓自己麻煩過不去再來寫這個無聊的 IE bookmarklet 與 Firefox 擴充元件。既然寫了就丟出來吧，只是奉勸有需要用的人，心胸放寬點。

rm_rd.xpi 會把轉址的部份吃掉 (Google 不准放 xpi，請自行改名)

IE6 請用 bookmarklet RemoveYahooRD URL=javascript:(function(d,l,i){l=d.links;for(i=0;i0){l[i].href=l[i].href.replace(/http\:[\w\.\/]+rd\.yahoo\.co.+\*http/i,'http');}}})(document);
PS. Blogger 這啥 HTML 編輯，不能貼 bookmarklet，請自己改吧

為何還在用 IE6？還何不食肉糜哩！IE6 在 Pentium3 上跑好快...

URI 編碼 / 解碼 v1.0

http://funlung.googlepages.com/htmldecode.html

請將要處理的文字填在這裡 Input text here:	[test]   [paste from clipboard]
escape() / unescape():	[copy to clipboard]
encodeURI() / decodeURI():	[copy to clipboard]
encodeURIComponent() / decodeURIComponent():	[copy to clipboard]
HTML Unicode Hex:	[copy to clipboard]

URI (Universal Resource Identifier) 通用資源識別字

URL (Uniform Resource Locator) 統一資源網址

escape(), encodeURI(), encodeURIComponent() 這三個函數都可以用來對 URI 進行編碼。

Why encoding? 不知其所以然？人活的好好的 幹嘛沒事要去編碼？

BECAUSE WE CAN !!!

因為資料(data)與特殊控制字元(control)對系統有不同的意義，如果資料與特殊控制字元無法完全隔離，就需要 脫離(escape) 來處理。

若資料與特殊控制字元分別存在於完全隔離的通道(例 FTP: port 21 control, port 20 data; packet format: byte0~3 length, byte4~ data; file: header, data...)，其實在處理上也等同於 escape，只是方便性與效率的考量來決定用何種方式來區分 data / control。

一般為了方便(free format)與空間利用效率很難將資料與特殊控制字元完全隔離，其實只要有一點共識(協定、標準、規格)就不需要這麼(完全隔離)作。例如講電話的 "喂"、"Hello" 表示確認、通訊開始(SYN, ACK, STX, reset)，若不知協定會發生錯誤，例如不懂日語的聽到 Moshimoshi(もしもし) 或無線電收到 CQ CQ 會把它當通話內容而回答。

處理中文或日文必須特別注意 escape 字元，因為中文 Big5 與日文 JIS/shift-JIS 都把常用的 escape '\'(0x5C) 納入編碼範圍。中文簡字 GB 2312-80 原本避開了 0xA0 之前的所有位置，但 GBK 又改成包含 0x40 ~ 0x7E，也有同樣問題。


中文(Big5)含有 0x5C 的字，含使用者造字部份(Unicode補完計畫)：

0

1

2

3

4

5

6

7

8

9

A

B

C

D

E

F

日文(shift-JIS)含有 0x5C 的字：

0

1

2

3

4

5

6

7

8

9

A

B

C

D

E

F

用引號標記字串開始與結束，字串內的引號要用 escape，而字串內的 escape 則要用 escape 的 escape，例如 "\"\\\""

CR LF 等表示格式的字元，人要處理時，輸入要用 \r \n，看不見的字元必須設法表示(如 MS Word)

HTML 同時標註內容與格式，使用了一些特殊字元如： < > &

檔案名稱裡 ; \ / | "

Why:

http 傳資料難免要 GET/POST。對 URL 編碼，以方便任何字串組成的 URL 可以 GET。

How:

1. 了解你的編碼對象，是 ASCII(Big5) 還是 Unicode(UTF-8)？

2. 了解前台(client, browser)的處理方式，(IE 設定選項) Always send URL as UTF-8(永遠將 URL 傳送成 UTF-8)。

3. 了解後台(CGI, JSP, PHP, ASP)的處理方式，哪些是特殊控制字元？是吃 ASCII 還是 Unicode？中文是否要另設 locale 處理？ (Java,PHP)request.setCharacterEncoding("UTF-8"); (Delphi)THTTPRIO.HTTPWebNode.UseUTF8InHeader := true;

4. 若前台與後台的處理方式牽涉到系統，要再去了解系統是大端/小端？word 是幾位元？long 有多長？(Windows)Unicode 是 16-bit 還是 (Linux) 32-bit？

5. 了解編碼方法，選擇合適的方法來使用。不為保密的緣故而自己寫編碼函數，難驗證、難維護、效益低，純粹只是浪費時間。

6. 多種系統混合使用，就要注意 escape of escape。例如 C/Java/Perl/Python... 與 regular expression 字串的 escape 字元都是 \，因此 \ 本身會變成 ==> regular expression /\\/ ==> regular expression in string "\\\\"

Delphi 字元 ' 會變成 ==> regular expression /\'/ ==> regular expression in Delphi string '\'''

URL 編碼方法的比較

escape() 方法：

對傳入字串進行 "脫離(escape)" 編碼。所有的空格、標點符號、特殊字元以及其他非 ASCII 字元都將被轉化成 %xx 格式的編碼 (xx 等於該字元在字元集裡的 16 進制數值)。例如空格的編碼是 %20。

[MSIE] 以 Unicode 處理，傳回 Unicode string。值大於 FF 的字元，以 %uxxxx 格式來編碼。

[Mozilla] 以 ISO Latin 字元集處理，傳回 ASCII string。不適合對非 ASCII 字元編碼：JavaScript 1.5 and later, use encodeURI, decodeURI, encodeURIComponent, and decodeURIComponent.

不會被此方法編碼的字元： * + - . / @ _

encodeURI() 方法：

把URI字串採用UTF-8編碼格式轉化成escape格式的字串。

不會被此方法編碼的字元： ! # $ & ' ( ) * + , - . / : ; = ? @ _ ~

encodeURIComponent() 方法：

把URI字串採用UTF-8編碼格式轉化成escape格式的字串。與encodeURI()相比，這個方法將對更多的字元進行編碼，比如 / 等字元。所以如果字串裡面包含了URI的幾個部分的話，不能用這個方法來進行編碼，否則 / 字元被編碼之後URL將顯示錯誤。

不會被此方法編碼的字元： ! ' ( ) * - . _ ~

因此，對於中文字串來說，如果不希望把字串編碼格式轉化成UTF-8格式的（比如原頁面和目標頁面的charset是一致的時候），只需要使用escape。如果你的頁面是GB2312或者其他的編碼，而接受參數的頁面是UTF-8編碼的，就要採用encodeURI或者encodeURIComponent。

另外，encodeURI/encodeURIComponent是在javascript1.5之後引進的，escape則在javascript1.0版本就有。

---

參考文章： Comparing escape(), encodeURI(), and encodeURIComponent()

http://xkr.us/articles/javascript/encode-compare/

Reference:

RFC 1630: Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web, June1994.

RFC 1738: Uniform Resource Locators (URL), December 1994.

Copyright © 2007 Fun, Lung. All rights reserved.