現在是下午2點50分，眼睛和肩膀都有點酸，腦子有點木。
整理下做計算器的過程和結果：
1，表格布局按鍵和區域：
一個6行的表格。第一和第二行分別是兩個type=“text”的<input>，寬度占據了四列的寬度，colspan="4"，分別是輸入和輸出的顯示行。第三行有兩列，分別是清零和退位按鍵。給每個按鍵標記id和value.
2，腳本寫的時候思路真的很重要，代碼的邏輯塊很凌亂，結構和可讀性差，進入狀態就得一會功夫啊。
2.1按照按鍵分類：
如果按下小數點，但輸入中已經包含了一個小數點時，此時按鍵無效；
如果按下0，且之前無輸入值時，此時按鍵無效，如果還有按鍵0一直按下，則按鍵仍無效；
如果輸入值的長度過大，則按鍵無效；
如果按下小數點，但此前無輸入值或輸入值為0時，則存儲當前輸入值為"0.";
如果按下0，且輸入值長度大於1時，則認為當前輸入有效，依次存儲到輸入值中；
如果按下的1-9或.，則依次存儲到輸入中；
如果按下運算符號+-*/，將輸入值轉化成浮點型存儲到number1中，並清空輸入值，將當前的運算符號存儲在mysi中；
如果按下=，將輸入值轉化成浮點型存儲到number2中，並清空輸入值，按照已存儲的mysi的運算符號、number1，進行計算；
2.2
輸入值、輸出值的實時顯示。
2.3
最后考慮清零鍵，退位鍵和輸入輸出建立關系，並完善。
3，多次測試，查bug。
結果：功能基本完成。
體會：2/3的時間是最后輸入值和輸出值的實時顯示，真的有點不可思議。有可能是前面的部分功能已實現，沾沾自喜、盲目大意。一個特別清醒的狀態做最后的完善真的很重要，這兩天雜事多，狀態不好。
最初的邏輯框架清晰簡潔很重要，就像建築物的根基。根基太淺，負重過大，代碼很累贅。孔隙太小，塞磚頭的地方太少，房子空間太小，太局限了。
最后的完善部分往往能畫龍點睛、錦上添花，但是這點我真的做的不好。
善始善終，勉勵自己。
-------------------------------------------------------
2015年5月23下午：
收到一系列的修改意見
1，輸入框：校驗無效的輸入字符（漢字，字母等），限制輸入位數。
2，沒有a=?的運算
3，連續計算1+2+5=？
動態監聽輸入框輸入的值。
利用onkeydown去指示用戶按下按鍵后執行的代碼。
在這個事件屬性下，定義一個函數。event.keycode可以讀取當前鍵盤按下的keycode值。（keycode不同於ASCII）
keycode的一個按鍵（可能含多個符號）對應一個鍵碼值，那么問題來了：
問題1：鍵盤上“+”和“=”同時占用了一個按鍵，讀取鍵碼值后若經過keystring=string.fromcharcode(keycode)轉化為按鍵的鍵碼符號是取其中的哪一個？
問題2：鍵盤上又存在多個鍵“1”（大鍵盤）和“1”（小鍵盤），規定用戶兩個鍵都可輸入1還是怎么辦呢？
如果只用大鍵盤，其中“8”和“*”復用同一個鍵碼。不好辦！
如果大鍵盤啟用數字1-9，運算符號+-*/啟用小鍵盤，感覺也不是很合理。
如果大鍵盤中和小鍵盤的數字都可用，運算符號只能用啟用小鍵盤。
如果只用小鍵盤，應該也算合理。
----------------------------------------------------------------------------------------------
2015年5月23晚：
動態監聽輸入框輸入值，我糾結了一個下午+吃飯的時間。
其實仔細想想onkeydown屬性明明就已經說的很明白了，一個鍵按下去檢測這個鍵。不可能用shift去復用，因為shift也是一個鍵。
甚至還想到shift+8后期處理正則表達式的時候再去從新定義，但這給用戶使用時帶來很多疑惑和不便。
只能說，我醉心於自己的腦洞了。
然則，動態監測鍵盤輸入oninput屬性和onpropertychange屬性。分別是非IE和IE下對當前值改變做出響應的腳本。
經過event.target.value或event.srcElement.value即可讀取當前輸入框的value。
啊哈，經過敲代碼驗證發現這個方法真的很靠譜，克服了onkeydown中只讀取一個單獨鍵碼的缺點。
既然已經可以讀取當前的輸入表達式，接下來的問題就是用正則表達式去分析數學表達式的問題了。
-----------------------------------------------------------------------------------------------------
2015年5月24中午：
用正則表達式匹配輸入的計算式。
1，輸入的字符串中如果有包含0-9，小數點，+-*/，=和（）以外的符號，就認為這個計算式是非法的。非法的計算式應該在用戶輸入的時候就給予提醒和限制，這和用戶在填寫表單時客戶端腳本驗證的情況應該是一樣的，所以，這里還需要完善一下。
2，輸入的字符串中先考慮篩選括號。從左到右匹配過程中，如果匹配到左括號按照先后順序則標注下來“L1”“L2”---“LN”，直到遇到右括號，標注為"RN"，再繼續匹配到“R1”。如果再遇到左括號“L(N+1)”以此類推。如果匹配完后，左右個數不等，也認為輸入的表達式無效。匹配好的括號，從內存依次向外計算，直到退去括號。
3，退去括號的表達式匹配*/，並計算，直到所有*/都計算完。
4，表達式中只包含+-,依次計算得到最終結果。
這是我遇到問題時，最早的想法。可是，我又一次發現自己把問題想的太復雜了。
只要將字符串經過匹配轉化成計算式，計算機本身可以計算含括號的計算式。為什么老是把問題復雜化啊，讓我這種智商低的人悄悄地哭一會吧。
接下來我要做的就是把字符串匹配轉化成有效的計算表達式。好吧，現在去吃飯拿快遞回去睡覺吧。
-----------------------------------------------------------------------------------------
2015年5月26日晚：
現在的心情略有一點點興奮，剛剛自己測試完1.91版本，沒有發現bug.
站在不同的高度俯瞰全局確實是不同的思路。
第一個版本的計算器：界面上的按鍵輸入，不允許連續運算。
第二個版本的計算器：除了界面上的按鍵輸入，還可識別用戶用鍵盤在輸入框輸入的字符，不允許連續運算。
第三個版本的計算器：界面上按鍵輸入和用戶鍵盤輸入可交叉進行，並且允許連續計算。