問題的起源是上面的帖子，昨天晚上看到帖子的時候已經超過12：40了。沒有時間去思考，給了個答案就匆匆睡了。初步診斷了ie7下的環視出現了bug
早上起來就開始折騰這玩意，廢話不多說，看看bug到底出在什麼地方吧
首先我把正則簡化了問題，因為錯誤的不確定性，我試圖刪除各個地方以達到盡量展示錯誤的**。最後得到的正則如下
/^(?=.*/d).$/
這個時候測試依然錯誤。也可以檢測出和環視有關係
給每個部分加上分組測試
/^(?=(.*)(/d))(.)$/
這個正則依然不具有任何意義，因為他找不到匹配，逐步調整
var s = "abc123123";
var reg = /^(?=(.*)(/d))(.+)$/;
alert(reg.exec(s));
測試結果完全正確，看不出和其他瀏覽器及正則原理有任何不同。由此可見環視中.*確實是貪婪匹配，/d也正常匹配的數字。
再做一次調整。
var s = "abc123123";
var reg = /^(?=(.*)(/d))(.)$/;
alert(reg.exec(s));
問題出現了
.*竟然匹配abc而非abc123123。難道說.*不是貪婪匹配麼？不對啊，剛才的測試證明他確實是貪婪匹配啊。只能猜測.*影響了後面的匹配。
var s = "abc123123";
var reg = /^(?=(.*)(/d))(.)$/;
alert(reg.exec(s));
這次匹配的結果是.*匹配abc1231
/d匹配的是2
根據兩次的測試，初步得出的結論是.*是貪婪匹配，但是環視中的匹配位置出現了錯誤。
.的匹配證明了/d是沒有問題的，因為/d雖然匹配了1，但是沒有占有任何字元和位置，把字元1交還給了.
由此可見。.*最大只能匹配到總長度減去.的最小長度
引用下好奇的說法：
ie的預查和量詞是有bug的。。。
實際上這裡的
量詞它是從預查裡的lastindex開始計算的。
就是a這個位置前面的那個位置，所以顯然是false。
下面是我的解釋：
它是從預查裡的lastindex開始計算的。 這裡有點更正 是從預查的.*的lastindex開始計算
比如.*/d 這個時候他不是從/d後面的position開始計算 而是.*的position開始計算
當後面的量詞最小值為n的時候 .*被迫回溯到後面匹配所需的n個元素的position
IE6 IE7之浮動元素最後乙個字母重複Bug
這個bug影響 ie7,ie6ab c div p span bug出現 1.我們有乙個確定寬度的div元素.2.在這個div中有乙個屬性margin right屬性設定為任何非0數值的 3.元素在這個p元素中有三個float屬性設定為left，並且寬的設定為大於父容器div寬度的寬度值的span元...
IE6 IE7中li底部4px的Bug
當li的子元素中有浮動 float 時，ie6 ie7中元素的下面會產生4px空隙的bug。xhtml ul class list li div vapour div li li divdiv li li div div li li div 迅雷 div li ul 經過測試發現 li的子元素浮動是...
IE6 IE7中li底部4px的Bug
當li的子元素中有浮動 float 時，ie6 ie7中元素的下面會產生4px空隙的bug。xhtml ul class list li div vapour div li li divdiv li li div div li li div 迅雷 div li ul 經過測試發現 li的子元素浮動是...