摘要：正則學起來說真的，不去正兒八經的學正則，對付一般的工作是沒啥問題的，雖然我們可能會經常用到，但畢竟度娘能提供大多時候你想要的可當我看一些框架的源碼，總會被里面一長串一長串的正則給嚇到之前一篇博客里有關于簡單的爬蟲實踐，其實離達到我預期的效果

說真的，不去正兒八經的學正則，對付一般的工作是沒啥問題的，雖然我們可能會經常用到replace，但畢竟度娘能提供大多時候你想要的；可當我看一些框架的源碼，總會被里面一長串一長串的正則給嚇到；之前一篇博客里有關于簡單的爬蟲實踐，其實離達到我預期的效果就差一批正則（Nodejs，不一樣的爬蟲實踐）；所以，一般的正則毫無壓力，非一般的情況下的正則，令人望而生畏；簡直就是語言界的一朵小奇葩！

正則其實就是用一串字符去描述一套規則，所以，首先得自個兒很清楚要實現的正則具備哪些規則，然后用一串字符組合搭配去描述它；以下正則，能力有限，暫不考慮性能問題，僅供參考；

指定一個子表達式，用小括號包括起來；

參與結果的分組：結果保存在$1-$9中：

"abc-123".replace(/(w+)-(d+)/,"$2-$1");
// "123-abc"

不參與結果的分組：(?:reg) reg參與匹配規則，匹配到的結果不參與分組的結果

var str1="abc123";
var str2="abc";
var reg=/w+(?:d+)?/;
reg.test(str1);    // true
reg.test(str2);    // true

反向引用：對相同的分組簡寫為對第一個分組結果的引用

// 匹配h1-h6的標簽
var reg=/.*?/i;

"
hhhhh1111
".test(reg)   // true
"
hhhhhaaaa
".test(reg)   // true

// 如果像這樣確實可以匹配到一般的h1-h6，
// 但其實它也會匹配
....
這種前后不對等的情況，
// 使用分組，反向引用就能避免這種情況

var reg=/.*?/i;
// 1即是對第一個分組([1-6])的引用

"
hhhhh1111
".test(reg)   // true
"
hhhhhaaaa
".test(reg)   // false

貪婪模式與非貪婪模式只影響用次數修飾的子表達式，貪婪模式在整個表達式匹配成功后會繼續向后盡可能多的匹配，非貪婪模式在表達式首次匹配成功后即返回結果；？除了表示匹配0次或1次之外，還有在次數修飾的子表達式后面表示是否啟用貪婪模式；

// 過濾html標簽
var str1="abc
cde
hf";
var reg=//ig;      // 貪婪模式
var reg1=//ig;  // 非貪婪模式

str1.replace(reg,"");                  // hf
str1.replace(reg1,"");                // abccdehf

// 可以看到非貪婪模式下的結果才是我們過濾標簽后想要的結果

在JS里只支持向前斷言，也就是向前查找；

(?=reg) 零寬正向先行斷言

(?!reg) 零寬負向先行斷言

這兩種斷言里的reg只作為整個表達式的一個必要條件，而不返回匹配結果，同樣不能與分組弄混淆；一般小括號用來劃分一個子表達式，(?:reg)的reg匹配的結果不參與整個表達式結果的分組；斷言的reg只作為一個必要條件，參與整個表達式匹配的判斷，匹配的內容卻不參與整個表達式匹配的結果；

向前查找即從斷言開始的位置的右邊開始匹配；

var str="abc123cdef456...........";

// 匹配數字后面跟著字母的內容，
//“跟著字母”僅作為一個條件，這個條件匹配到的結果不參與整個表達式匹配的結果
str.match(/d+(?=[a-z]+)/g);     // 123 而不是 456
str.match(/d+(?!w+)/g);          // 456

其他基礎如：s S w W b B d D [0-9a-zA-Z_] 等基礎符號組合應該相對好理解，作為很基礎的部分，必須牢記咯；

其實絕大多數人都用過正則，但我更相信大多數人用的正則都是度娘提供的，為了真正的走近正則，而不只是道聽途說，必須全面的過一遍，并且盡可能的用到實際工作中，比如：驗證個url，過濾個標簽等，相信自己弄出來一串字符的話，肯定別有一番意思；如下Url模塊，對于前端來說基本上是多余的，因為瀏覽器有location；parse方法的作用在于對非location情形下的自定義url或可認為是url的字符串進行解析；比如：用戶輸入一串url，首先驗證是否符合url規則，然后提取協議類型，提取域名等，這些就是location做不到的，而且對于簡單的爬蟲操作替換或補全url，該方法就派上用場了；

Url.parse(url)；//返回一個object

如果不帶url參數，則默認為location.href；這時返回的結果和location能取到的一樣；

如果帶上url，無論是否自定義的，都將重新用正則解析，并返回一個和location能獲取到的一樣的結果集，包括格式化后的query；

Url.normalize(url)；//返回url

首先對接收的url去空白字符，嘗試將多個連續的/符合替換為一個，將多個.去掉(../或./的情況)，相當于放寬url的限定規則；

Url.isAccessUrl(url)；//返回true|false

驗證是否符合正確的url規范；

Url.query；//返回 object

取得url上的查詢參數，{name:value}格式，如：Url.query.id取得url上id=123的值即返回123；

var Url=function(loc){
    var urlUtils=function(){
        return {
            trim:function(url){
                return url.replace(/^s+|s+$/,"");
            },
            norProtocol:function(url){
                if (!/https?:///i.test(url)) throw url+" http or https protocol needed !";
                return url.replace(/(https?://)/+/,"$1");
            },
            getProtocol:function(url){
                return this.norProtocol(url).match(/(https?://)/)[1];
            },
            tryOnce:function(url){
                return this.getProtocol(url)+
                       this.norProtocol(url).substring(this.getProtocol(url).length)
                       .replace(/.+(?=/)/g,"")
                       .replace(//+/g,"/");
            },
            normalize:function(url){
                var nor=this.tryOnce(this.trim(url));
                return nor.match(/https?://(w+(?:.w+)+)(:d{2,5})?$/)?nor+="/":nor;
            },
            isAccessUrl:function(url){
                return /https?://(?:w+(?:.w+)+|localhost)(?::d{2,5})?/S*/i.test(this.normalize(url));
            },
            convertQs:function(qs){
                var qs=qs||loc.search.substring(1);
                if(!qs) return null;
                var qsArr=qs.split(/&/),qsPar={};
                for(var i=0;i
將得到如下結果：

正則研究的不太深，該模塊難免會有BUG，或繁瑣的地方，個人認為在實際工作中還是有用武之地的，后續慢慢修復吧；
正則這朵小奇葩還是挺有意思的，相信更加熟練后在以后的前端之路上會帶給我意想不到的收獲！
如果你已在路上，就勇敢的向前吧！
原文來自：花滿樓（http://www.famanoder.com/boke...）