回答編集履歴
2
表現を修正
answer
CHANGED
|
@@ -4,8 +4,10 @@
|
|
|
4
4
|
|
|
5
5
|
[RegExp.prototype.exec() - JavaScript | MDN](https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/RegExp/exec)
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
1回目の`exec`では、`lastIndex`の値が0なので、検索対象となる文字列の先頭からマッチを試み、想定する部分にマッチする。このとき、`lastIndex`の値は「次に検索を開始する位置」に設定される(今回だと39)。
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
2回目の`exec`では、検索対象となる文字列がリストの次の要素に代わっていたとしても、`exec`は`lastIndex`以降からマッチを試みる。今回のデータでは、検索対象となる文字列の長さが統一されており、インデックス39以降には文字がないため、このマッチはかならず失敗することになる。すると、`lastIndex`の値は0に設定される。
|
|
10
10
|
|
|
11
|
+
というわけで、これ以降も「奇数回目の`exec`では、`lastIndex`が0なので想定される部分にマッチ」し、「偶数回目の`exec`では、`lastIndex`が39なのでマッチに失敗」する、という動作が繰り返される。
|
|
12
|
+
|
|
11
|
-
対処方法としては、`linkRegExp`に`g`フラグを付けない(ステートフル動作をさせない)こと。
|
|
13
|
+
対処方法としては、言うまでもなく`linkRegExp`に`g`フラグを付けない(前回の状態を引き継ぐステートフル動作をさせない)こと。
|
1
補足を追加
answer
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
|
|
5
5
|
[RegExp.prototype.exec() - JavaScript | MDN](https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/RegExp/exec)
|
|
6
6
|
|
|
7
|
-
偶数回目の`exec`では、**直前の検索でマッチした箇所の直後(今回だと39)に`lastIndex`が設定**されており、`exec`はそのインデックス以降からマッチを試みる。今回のデータでは、検索対象となる文字列の長さが統一されており、このマッチはかならず失敗することになる。
|
|
7
|
+
偶数回目の`exec`では、**直前の検索でマッチした箇所の直後(今回だと39)に`lastIndex`が設定**されており、(検索対象となる文字列がリストの次の要素になっていたとしても)`exec`はそのインデックス以降からマッチを試みる。今回のデータでは、検索対象となる文字列の長さが統一されており、このマッチはかならず失敗することになる。
|
|
8
8
|
|
|
9
9
|
すると、`lastIndex`の値は0に設定されるので、奇数回目の`exec`では、検索対象となる文字列の先頭からマッチを試み、想定する部分にマッチする。
|
|
10
10
|
|