现在是下午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.
站在不同的高度俯瞰全局确实是不同的思路。
第一个版本的计算器：界面上的按键输入，不允许连续运算。
第二个版本的计算器：除了界面上的按键输入，还可识别用户用键盘在输入框输入的字符，不允许连续运算。
第三个版本的计算器：界面上按键输入和用户键盘输入可交叉进行，并且允许连续计算。
