Regular Expressionスレです。
質問する場合は必ず実装言語や処理系ソフトウェア名を示してください。
前スレ
Regular Expression(正規表現) Part13
http://echo.2ch.net/test/read.cgi/tech/1415149975/
次スレは>>980宜しく
天ぷら等2以降
探検
Regular Expression(正規表現) Part14 [無断転載禁止]©2ch.net
レス数が950を超えています。1000を超えると書き込みができなくなります。
1デフォルトの名無しさん
2017/03/15(水) 02:04:35.47ID:e01p03UP882デフォルトの名無しさん
2019/07/16(火) 17:23:30.54ID:hAAouWtx 読んでるだけで何も考えてなかったけど
/(^|[@;])[^@;]*/g
この書き方以外の書き方で意図した動作になるように書けないのかな
ここの人はこういうの得意だからもしかしたら・・？
/(^|[@;])[^@;]*/g
この書き方以外の書き方で意図した動作になるように書けないのかな
ここの人はこういうの得意だからもしかしたら・・？
883デフォルトの名無しさん
2019/07/16(火) 18:30:33.69ID:AvaVqNzm 一所懸命挑発的に書いてるのに全然乗ってもらえなくてかわいそう
884デフォルトの名無しさん
2019/07/16(火) 19:27:45.24ID:hAAouWtx 言ってることに説得力がありすぎて聞き入ってしまってたよ
どんどん言いたいことを言って欲しい
昔のdanさんを思い出すなぁ
どんどん言いたいことを言って欲しい
昔のdanさんを思い出すなぁ
885デフォルトの名無しさん
2019/07/16(火) 20:41:55.62ID:bFMew56o 入力フォーマットが正しいという前提で /@?[^@;]+/ の方が好み
そもそも正規表現使うより ; でsplitした方が良くね？とおｍ
そもそも正規表現使うより ; でsplitした方が良くね？とおｍ
886デフォルトの名無しさん
2019/07/16(火) 21:03:17.33ID:hMJFhr7R >>881
深くはない、単にバグってるだけ。
そしてそれはやばいどころではなく、全く話にならないレベルの物だ。使い物にならない。
例えば、図書館の蔵書をユーザーにも検索出来るようにしたとして、正規表現検索も選べるとしよう。
この場合、検索結果に現れないケースが発生することになり、使い物にならない。
プログラミング言語内の正規表現エンジンは「今までのプログラムが動かなくなる」危険があるからそうそう交換出来ないが、
図書館DBの検索フロントエンド内のエンジンなんて即交換可能なんだから、問題があればすぐ乗り換えられる。
PCREが気に入らないのならこんなところで無駄吠えするのではなく、
PCREがバグっているケース（例のタグ外側マッチとか）でもばっちり動く検索エンジンを提供して、乗り換えを待てばいいだけ。
現状、PCRE以外全部バグっているのだから救いようがないが。
JavaScriptの場合はatomエディターなる物があって、htmlやプログラムソースコードを編集出来るが、
JavaScriptの場合はreplaceもバグっているので、命中すれば、全置換しても全置換出来てないケースが発生する。
リファクタ等で変数名を変えるとき、手でやるとバグるので、当然エディタ機能で全置換させるわけだが、この場合にもバグる訳だ。
そしてユーザーはこのときに置換漏れが発生するとは全く思わないので、かなり手間取ることになる。
(atomでは対策されていると信じたい)
JavaScriptの場合はこのバグも「仕様」としてしまっているので、
逆に言えば仕様通りならバグに命中したときの挙動も確定してる。だから対策は出来るが、
Rubyみたいに「実装が仕様だ」と言い張る糞言語だとどういう挙動か確認してみなければ分からず、対策が出来ない。
ここらへんもRubyの思想は数周遅れている。
いずれにしてもこんな基本的なところのバグはあっても迷惑でしかなく、さっさと直せ、でしかない。
「速い」以前に「ヒットしない」エンジンなんて使い物にならないだろ。
エンジン競争しているつもりの馬鹿共も、方向性を完全に間違ってる。
「間違いなく動作する」エンジンを提供すれば、文書検索側の人間はサクッと乗り換えてくれるだろうさ。
速い遅いはその後の話だ。
深くはない、単にバグってるだけ。
そしてそれはやばいどころではなく、全く話にならないレベルの物だ。使い物にならない。
例えば、図書館の蔵書をユーザーにも検索出来るようにしたとして、正規表現検索も選べるとしよう。
この場合、検索結果に現れないケースが発生することになり、使い物にならない。
プログラミング言語内の正規表現エンジンは「今までのプログラムが動かなくなる」危険があるからそうそう交換出来ないが、
図書館DBの検索フロントエンド内のエンジンなんて即交換可能なんだから、問題があればすぐ乗り換えられる。
PCREが気に入らないのならこんなところで無駄吠えするのではなく、
PCREがバグっているケース（例のタグ外側マッチとか）でもばっちり動く検索エンジンを提供して、乗り換えを待てばいいだけ。
現状、PCRE以外全部バグっているのだから救いようがないが。
JavaScriptの場合はatomエディターなる物があって、htmlやプログラムソースコードを編集出来るが、
JavaScriptの場合はreplaceもバグっているので、命中すれば、全置換しても全置換出来てないケースが発生する。
リファクタ等で変数名を変えるとき、手でやるとバグるので、当然エディタ機能で全置換させるわけだが、この場合にもバグる訳だ。
そしてユーザーはこのときに置換漏れが発生するとは全く思わないので、かなり手間取ることになる。
(atomでは対策されていると信じたい)
JavaScriptの場合はこのバグも「仕様」としてしまっているので、
逆に言えば仕様通りならバグに命中したときの挙動も確定してる。だから対策は出来るが、
Rubyみたいに「実装が仕様だ」と言い張る糞言語だとどういう挙動か確認してみなければ分からず、対策が出来ない。
ここらへんもRubyの思想は数周遅れている。
いずれにしてもこんな基本的なところのバグはあっても迷惑でしかなく、さっさと直せ、でしかない。
「速い」以前に「ヒットしない」エンジンなんて使い物にならないだろ。
エンジン競争しているつもりの馬鹿共も、方向性を完全に間違ってる。
「間違いなく動作する」エンジンを提供すれば、文書検索側の人間はサクッと乗り換えてくれるだろうさ。
速い遅いはその後の話だ。
887デフォルトの名無しさん
2019/07/16(火) 21:18:41.35ID:hMJFhr7R >>879
BREの場合はやりきる前提ではないので、例えば例のタグ外側マッチだと、
元の文字列に > と < を足してしまって置換し、出力時に削る、みたいなことをする。
具体的には以下。
('>' + str + '<').replace(/>[^<]*</,'>bar<').slice(1,-1)
だからBREしか使えないAWKでも意外と何とかなったりする。
ただしこれはプログラミング出来る前提であって、
Webページに検索窓だけ提供されているような状態ではどうにもならないが。
>>885
それは正しい。実際俺もそれに近いことをしている。
デリミタが最初に出現もあり、最後に付加もあり、つまり
';prop:style1' や
'prop:style1;prop:style2;' もありなので、
結局 /(^|[@;])[^@;]*/g だと後のコードが綺麗に書けなかった。 /(^.|[@;])[^@;]*/g でも同じ。
意味的には @ もデリミタ扱いしているだけなので、実もフタもないが、@を ;@にしてsplitした。
具体的には以下。
str.replace(/@/g,';@').split(';').filter(v=>v)
BREの場合はやりきる前提ではないので、例えば例のタグ外側マッチだと、
元の文字列に > と < を足してしまって置換し、出力時に削る、みたいなことをする。
具体的には以下。
('>' + str + '<').replace(/>[^<]*</,'>bar<').slice(1,-1)
だからBREしか使えないAWKでも意外と何とかなったりする。
ただしこれはプログラミング出来る前提であって、
Webページに検索窓だけ提供されているような状態ではどうにもならないが。
>>885
それは正しい。実際俺もそれに近いことをしている。
デリミタが最初に出現もあり、最後に付加もあり、つまり
';prop:style1' や
'prop:style1;prop:style2;' もありなので、
結局 /(^|[@;])[^@;]*/g だと後のコードが綺麗に書けなかった。 /(^.|[@;])[^@;]*/g でも同じ。
意味的には @ もデリミタ扱いしているだけなので、実もフタもないが、@を ;@にしてsplitした。
具体的には以下。
str.replace(/@/g,';@').split(';').filter(v=>v)
888デフォルトの名無しさん
2019/07/16(火) 22:42:20.32ID:P37s1FHo 一度言った内容は繰り返さなくていいです
889デフォルトの名無しさん
2019/07/17(水) 08:28:41.50ID:2/Bgill9 >>873訂正
俺は俺のケースだけ考えていたが、これだと871内URLの筆者のケースと合致しない。
そこで一応、両方とも合致する実装を考えてみた。
(といってもバグってる実装について推測すること自体はあまり意味がないが)
Perlはおそらく、^のフラグではなくて、空文字マッチ後のそのマッチ区間の*を+にしてる。
（というより筆者もそう言っているのだが俺が早とちりしてしまった）
871のケースだと、正規表現 (?:^|>)(.*?)(?:$|<) に対して、
1回目：(?:^|>)(.*?)(?:$|<)
2回目：(?:^|>)(.+?)(?:$|<)
というわけだ。結果、2回目は「先頭、<含んだ1文字、次の<まで、となり、
その筆者の説明通り先頭タグを含んで次タグ或いは文末まで伸びることになる。
俺のケースでは、正規表現 (^|[@;])[^@;]* に対して、
1回目：(^|[@;])[^@;]*
2回目：(^|[@;])[^@;]+
だから '@time;prop1:style1;prop2:style2' に対して @time のマッチも正しく取れることになる。
こういった場合、実装者は安全側に倒したくなる物だが、
現実は安全側に倒しすぎて余分なケースを含んでしまい、結果、バグっているというわけだ。
JavaScriptは最高に安全な実装、「空文字マッチは1文字進める」とした。（おそらくRubyその他もそう）
これだと絶対に無限ループはしないが、俺のケースでバグる。
Perlの実装だと俺のケースは通るが、871内URLの筆者のケースでバグる。
その他バグケースも出してくれれば俺の推測で合っているかどうかは答える。
俺は俺のケースだけ考えていたが、これだと871内URLの筆者のケースと合致しない。
そこで一応、両方とも合致する実装を考えてみた。
(といってもバグってる実装について推測すること自体はあまり意味がないが)
Perlはおそらく、^のフラグではなくて、空文字マッチ後のそのマッチ区間の*を+にしてる。
（というより筆者もそう言っているのだが俺が早とちりしてしまった）
871のケースだと、正規表現 (?:^|>)(.*?)(?:$|<) に対して、
1回目：(?:^|>)(.*?)(?:$|<)
2回目：(?:^|>)(.+?)(?:$|<)
というわけだ。結果、2回目は「先頭、<含んだ1文字、次の<まで、となり、
その筆者の説明通り先頭タグを含んで次タグ或いは文末まで伸びることになる。
俺のケースでは、正規表現 (^|[@;])[^@;]* に対して、
1回目：(^|[@;])[^@;]*
2回目：(^|[@;])[^@;]+
だから '@time;prop1:style1;prop2:style2' に対して @time のマッチも正しく取れることになる。
こういった場合、実装者は安全側に倒したくなる物だが、
現実は安全側に倒しすぎて余分なケースを含んでしまい、結果、バグっているというわけだ。
JavaScriptは最高に安全な実装、「空文字マッチは1文字進める」とした。（おそらくRubyその他もそう）
これだと絶対に無限ループはしないが、俺のケースでバグる。
Perlの実装だと俺のケースは通るが、871内URLの筆者のケースでバグる。
その他バグケースも出してくれれば俺の推測で合っているかどうかは答える。
890デフォルトの名無しさん
2019/07/17(水) 08:28:59.00ID:2/Bgill9 正しい実装は、「経路全体」（つまりツリーのリーフ）に対してフラグを持たないといけない。
Perlは「区間」(＝経路の一部)に対してフラグをつけてしまったところが間違いだ。
871のケース、単純化する為に (A0|A1)B(C0|C1)として、
1回目：A0BC1 で空文字マッチ
そして空文字マッチの場合はこれを記録し、これと同一の場合は次回以降はスキップする。
結果、2回目：最初に A0BC1 がマッチするがこれは捨てられ、次に A1BC0またはA1BC1となる。
そして非空文字マッチとなったので、この記録を全破棄して、同様にループを繰り返せばいい。
実装の修正は、探索関数そのものにだいぶ手を入れないといけないのでそれなりに大変だ。
まずは全部の最終段に「最終チェック」を入れて上記リストと照合、記載有ればマッチ失敗として探索継続、としなければならないが、
おそらくこれが1ヶ所では済まない。
ただしこれはリターンパスを辿ればいいので何らかのツールが有ればほぼ自動でいけるかもしれない。
次に上記リストを作成する為に全経路を出力させなければならない。
デバッグ用にこれが既にあればラッキーだが、なければ自前で作らなければいけない。
といっても内容はツリーのノードを辿るだけなので、ツリーのフォーマットが分かればすぐだが、
ゴリゴリに高速化とかしていると割と意味不明なコードになっていることが多いので、
その状態で確認するのは結構辛いとは思う。
リストの管理は、空文字マッチなら追記、非空文字マッチならクリア、なので、これはやるだけだ。
リストの管理も探索関数にやらせて、探索関数は
今：マッチ場所とマッチ長さを返す
修正後：マッチ場所とマッチ長さを含んだ『配列』を返す、とし、
「空文字マッチの場合は自動で継続、非空文字マッチまたは終了まで探索、まとめて配列で結果を返す」とするのがいいだろう。
Perlは「区間」(＝経路の一部)に対してフラグをつけてしまったところが間違いだ。
871のケース、単純化する為に (A0|A1)B(C0|C1)として、
1回目：A0BC1 で空文字マッチ
そして空文字マッチの場合はこれを記録し、これと同一の場合は次回以降はスキップする。
結果、2回目：最初に A0BC1 がマッチするがこれは捨てられ、次に A1BC0またはA1BC1となる。
そして非空文字マッチとなったので、この記録を全破棄して、同様にループを繰り返せばいい。
実装の修正は、探索関数そのものにだいぶ手を入れないといけないのでそれなりに大変だ。
まずは全部の最終段に「最終チェック」を入れて上記リストと照合、記載有ればマッチ失敗として探索継続、としなければならないが、
おそらくこれが1ヶ所では済まない。
ただしこれはリターンパスを辿ればいいので何らかのツールが有ればほぼ自動でいけるかもしれない。
次に上記リストを作成する為に全経路を出力させなければならない。
デバッグ用にこれが既にあればラッキーだが、なければ自前で作らなければいけない。
といっても内容はツリーのノードを辿るだけなので、ツリーのフォーマットが分かればすぐだが、
ゴリゴリに高速化とかしていると割と意味不明なコードになっていることが多いので、
その状態で確認するのは結構辛いとは思う。
リストの管理は、空文字マッチなら追記、非空文字マッチならクリア、なので、これはやるだけだ。
リストの管理も探索関数にやらせて、探索関数は
今：マッチ場所とマッチ長さを返す
修正後：マッチ場所とマッチ長さを含んだ『配列』を返す、とし、
「空文字マッチの場合は自動で継続、非空文字マッチまたは終了まで探索、まとめて配列で結果を返す」とするのがいいだろう。
891デフォルトの名無しさん
2019/07/17(水) 08:29:16.56ID:2/Bgill9 なおPerlの実装だと『上位関数のみ』で対策できるため、
「取り敢えず１時間で直せ」と言われたらこうなるのも分からなくはない。
しかしいまだにそのままだというのは怠慢でしかないが。
JavaScript等も同様、『上位関数のみ』で対策出来るところで留まっている点からも、これは言える。
しかし現時点で世界中のプログラマがどれだけ無駄な時間を消費することになっているのかを考えれば、
こんなのは手間であろうがさっさと直せ、でしかないが。
いずれにしても、俺が修正してやる、修正案はこれだ！と具体的に出してくるのならレビューはする。
我こそは！という奴は頑張れ。
「取り敢えず１時間で直せ」と言われたらこうなるのも分からなくはない。
しかしいまだにそのままだというのは怠慢でしかないが。
JavaScript等も同様、『上位関数のみ』で対策出来るところで留まっている点からも、これは言える。
しかし現時点で世界中のプログラマがどれだけ無駄な時間を消費することになっているのかを考えれば、
こんなのは手間であろうがさっさと直せ、でしかないが。
いずれにしても、俺が修正してやる、修正案はこれだ！と具体的に出してくるのならレビューはする。
我こそは！という奴は頑張れ。
892デフォルトの名無しさん
2019/07/17(水) 09:46:24.93ID:u050lnGw 話を単純化すると、
1. ある文字、例えば@ から、次の@ の直前の文字まで
2. 先頭が、@ でなければ、先頭から、@ の直前の文字まで。
つまり、先頭が、@ でなければ、先頭文字を、@ とみなして処理する
つまり、ルール1・2は、同時に適用させず、先にルール1を適用し、
ルール1に適用しないものだけを、ルール2に使う
(^|[@;])[^@;]*
だから、この正規表現がおかしい。
定義があいまいになる、解釈を含んでいる！
OR の部分が、並列ではない。
ルール1を優先すべき！
1. ある文字、例えば@ から、次の@ の直前の文字まで
2. 先頭が、@ でなければ、先頭から、@ の直前の文字まで。
つまり、先頭が、@ でなければ、先頭文字を、@ とみなして処理する
つまり、ルール1・2は、同時に適用させず、先にルール1を適用し、
ルール1に適用しないものだけを、ルール2に使う
(^|[@;])[^@;]*
だから、この正規表現がおかしい。
定義があいまいになる、解釈を含んでいる！
OR の部分が、並列ではない。
ルール1を優先すべき！
893892
2019/07/17(水) 09:51:38.77ID:u050lnGw (^|[@;])[^@;]*
OR を使うと、両方に該当する場合に、どちらの処理がされるのか、あいまい！
つまり、先頭文字が@; の場合に、両方に該当するので、処理があいまい！
A|B
A, B 両方に該当する場合に、A,B どちらの処理がされるのか、あいまい！
OR を使うと、両方に該当する場合に、どちらの処理がされるのか、あいまい！
つまり、先頭文字が@; の場合に、両方に該当するので、処理があいまい！
A|B
A, B 両方に該当する場合に、A,B どちらの処理がされるのか、あいまい！
894デフォルトの名無しさん
2019/07/17(水) 09:53:34.46ID:RL7WDafS 左側優先とかないのかこれ？
895877
2019/07/17(水) 10:06:18.04ID:u050lnGw >>889
Ruby で、
str = "@time;prop1:style1;prop2:style2"
re = /((^|[@;])[^@;]*)/
p results = str.scan( re )
# [["", ""], [";prop1:style1", ";"], [";prop2:style2", ";"]]
[ 0 ]がマッチした部分、[ 1 ]がキャプチャー部分
>>862
の、["", ";prop1:style1", ";prop2:style2"] と同じ結果
# * を、+ に変えた。
re_2 = /((^|[@;])[^@;]+)/
p results_2 = str.scan( re_2 )
# [["@time", "@"], [";prop1:style1", ";"], [";prop2:style2", ";"]]
Ruby で、
str = "@time;prop1:style1;prop2:style2"
re = /((^|[@;])[^@;]*)/
p results = str.scan( re )
# [["", ""], [";prop1:style1", ";"], [";prop2:style2", ";"]]
[ 0 ]がマッチした部分、[ 1 ]がキャプチャー部分
>>862
の、["", ";prop1:style1", ";prop2:style2"] と同じ結果
# * を、+ に変えた。
re_2 = /((^|[@;])[^@;]+)/
p results_2 = str.scan( re_2 )
# [["@time", "@"], [";prop1:style1", ";"], [";prop2:style2", ";"]]
896デフォルトの名無しさん
2019/07/17(水) 13:38:56.68ID:FD/sfaX1 小飼って糖尿病で死んだんだっけ
897デフォルトの名無しさん
2019/07/17(水) 14:01:11.32ID:fOq5lc1d 質問させてください。
PCRE や bregonig で大文字・小文字の区別なしで\x{017F}がsやSにマッチしてしまうのは仕様ですか？
PCRE や bregonig で大文字・小文字の区別なしで\x{017F}がsやSにマッチしてしまうのは仕様ですか？
898デフォルトの名無しさん
2019/07/17(水) 15:07:35.98ID:Jmalh7Yl899デフォルトの名無しさん
2019/07/17(水) 20:30:56.60ID:2/Bgill9 >>894
ないね。
聞いたこと無いし、JavaScriptで試した限り ([@;]|^)[^@;]* でも結果は同じだった。
ただ、確かに普通に考えたら左優先でいいし、上記入れ替えで @time をキャプチャ出来るようになるべきではある。
言われてみれば優先順位が決まってないことに驚きだ。
ないね。
聞いたこと無いし、JavaScriptで試した限り ([@;]|^)[^@;]* でも結果は同じだった。
ただ、確かに普通に考えたら左優先でいいし、上記入れ替えで @time をキャプチャ出来るようになるべきではある。
言われてみれば優先順位が決まってないことに驚きだ。
900デフォルトの名無しさん
2019/07/17(水) 20:37:09.24ID:RL7WDafS >>899
ちょっと知識が深まったよ サンクス
ちょっと知識が深まったよ サンクス
901デフォルトの名無しさん
2019/07/17(水) 20:40:11.08ID:2/Bgill9 >>895
お前は毎回Rubyの話をどのスレにも持ち込んでいる荒らしだろ。
何か言いたいことがあるのなら必ず結論を書け。
何が言いたいのか分からないのでウザイ。だから荒らしなんだよ。
+ に変えて空文字マッチをなくし、結果、希望の文字列を得る、という運用で回避するのはありだ。
ただ、その場合は、プログラマにそう分かるように、
「Rubyの正規表現エンジンは空文字マッチ周りにバグがあるので、注意してください。
空文字マッチがある正規表現を与えた場合、予期せぬ動作になることがあります。」とアナウンスしないといけない。
事実上空文字マッチが使えないが、事実なんだからそうするしかないだろ。
Rubyはこういう事を全くしないからゴミなんだよ。Rubyは滅ぶべくして滅んで行ってるだけ。
JavaScriptは少なくとも仕様に明記はしてる。
ただそれだと弱いからMDNにも書け、というのが俺の主張であり、JavaScriptスレに勝手に依頼しておいた。
以前RegExp.testの件で同様に依頼したら追記されたから、そうなるのを願っている。
そういう、「落とし穴」は共同して塞いでいかないと駄目なんだよ。
完璧な言語なんてない。だから多少バグがあるのは仕方ないとして、
それを未来永劫新規プログラマに押しつけて「キャハハー、お前も落ちたか！」なんてやっているようでは駄目なんだ。
Rubyはプログラマに対してリスペクトが全くない。だから廃れるし、俺もそうなることを願っている。
お前はRubyを吹聴しさえすれば布教出来ると勘違いしているようだが、そんなことはない。
当たり前だが新人にとってはこんなバグにつき合わされること自体大迷惑でしかないんだよ。
今回のでもPCREが一番ましだし、Rubyなんて選ばれる理由がないだろ。
ゴミだと分かっているものを広めるのは、単なる詐欺師でしかないぞ。
お前はお前の行為によってRubyへの反感を得ているだけなことを自覚した方がいい。
あちこちのスレでお前は相当ウザがられてる。
そういうのではなくて、バグを修正するとか、仕様書に明記するとか、
何でそういう建設的な方向に努力出来ないんだ？
こういう地道な積み重ねを全くやってないからRubyの現状はあるわけでさ。
お前は毎回Rubyの話をどのスレにも持ち込んでいる荒らしだろ。
何か言いたいことがあるのなら必ず結論を書け。
何が言いたいのか分からないのでウザイ。だから荒らしなんだよ。
+ に変えて空文字マッチをなくし、結果、希望の文字列を得る、という運用で回避するのはありだ。
ただ、その場合は、プログラマにそう分かるように、
「Rubyの正規表現エンジンは空文字マッチ周りにバグがあるので、注意してください。
空文字マッチがある正規表現を与えた場合、予期せぬ動作になることがあります。」とアナウンスしないといけない。
事実上空文字マッチが使えないが、事実なんだからそうするしかないだろ。
Rubyはこういう事を全くしないからゴミなんだよ。Rubyは滅ぶべくして滅んで行ってるだけ。
JavaScriptは少なくとも仕様に明記はしてる。
ただそれだと弱いからMDNにも書け、というのが俺の主張であり、JavaScriptスレに勝手に依頼しておいた。
以前RegExp.testの件で同様に依頼したら追記されたから、そうなるのを願っている。
そういう、「落とし穴」は共同して塞いでいかないと駄目なんだよ。
完璧な言語なんてない。だから多少バグがあるのは仕方ないとして、
それを未来永劫新規プログラマに押しつけて「キャハハー、お前も落ちたか！」なんてやっているようでは駄目なんだ。
Rubyはプログラマに対してリスペクトが全くない。だから廃れるし、俺もそうなることを願っている。
お前はRubyを吹聴しさえすれば布教出来ると勘違いしているようだが、そんなことはない。
当たり前だが新人にとってはこんなバグにつき合わされること自体大迷惑でしかないんだよ。
今回のでもPCREが一番ましだし、Rubyなんて選ばれる理由がないだろ。
ゴミだと分かっているものを広めるのは、単なる詐欺師でしかないぞ。
お前はお前の行為によってRubyへの反感を得ているだけなことを自覚した方がいい。
あちこちのスレでお前は相当ウザがられてる。
そういうのではなくて、バグを修正するとか、仕様書に明記するとか、
何でそういう建設的な方向に努力出来ないんだ？
こういう地道な積み重ねを全くやってないからRubyの現状はあるわけでさ。
902デフォルトの名無しさん
2019/07/18(木) 16:11:19.79ID:Y8yxmCyC 今の複雑化した正規表現エンジンってエンジンを作った人ですらどう動くのか
予測が難しいところがあるのでは
バグと言えばバグだけど総合的に考えてみてこの動作が最適だからこのままにしよう
という部分もたくさんあると思う
だから怠慢という言葉はちょっと違う気がするなぁ
あとrubyの正規表現エンジンは空文字マッチが〜の件は
つまりonigmoのことを言ってるんだけどonigmo自体は空文字マッチに
対応してると記憶してるからrubyモードの仕様なんじゃないかな
予測が難しいところがあるのでは
バグと言えばバグだけど総合的に考えてみてこの動作が最適だからこのままにしよう
という部分もたくさんあると思う
だから怠慢という言葉はちょっと違う気がするなぁ
あとrubyの正規表現エンジンは空文字マッチが〜の件は
つまりonigmoのことを言ってるんだけどonigmo自体は空文字マッチに
対応してると記憶してるからrubyモードの仕様なんじゃないかな
903デフォルトの名無しさん
2019/07/18(木) 20:03:10.71ID:PnG1z3PK >>902
Ruby周りにはお前みたいなクズしかいないから駄目なんだよ。
プログラミング出来ないのなら黙ってろ。
今のお前が為すべきは、お前が持っているonigmo環境で該当パターンを試し、結果を共有することだ。
Rubyの評判を気にすることではない。
Ruby+onigmoの組み合わせでばっちり動くのなら、
「他環境はゴミです！みなさんの悩みはRubyで解決出来ます！この機会に乗り換えてください！」と言えばいいだけだ。
動くんじゃないかな、みたいなお前の希望的観測なんて何の役にも立たない。
或いは、onigmo単独では動くがRubyのバグ互換モードでは動かない、というのが事実なら、
「Rubyは次のメジャーアップデートでここが対策されます！みなさんご期待ください！」
と言えばいいだけだ。
実際、正規表現の方言/バグに参っている連中はいるんだから、それで乗り換えてくれるだろうさ。
実際、Rubyの奴らはこういう事を全くしない。
そしてRubyの評判だけを気にしているからRubyはゴミのままなんだよ。
871の件、Perl5.6だがPCREもか？と思って試したが、PCREもだ。
そしてPCREには
> using the same syntax and semantics as Perl 5.
と書いてある。つまりこれが本当ならPerl5のバグも含めて挙動は同一、ということになる。
しかしバグまで含めて同一とするにはPerlがこれを仕様化していないとほぼあり得ない。
そこでPerlを確認してみたが、どうやら以下がそれらしい。
> Repeated Patterns Matching a Zero-length Substring
> https://perldoc.perl.org/perlre.html
グダグダ説明はしてあるがPerlは読めんから詳細まで俺の読み通りかは分からんが。
いずれにしても、JavaScriptとPerlは仕様化してる。
Rubyが仕様化しておらず、これが大問題だと認識出来ないのは、Ruby界隈にはまともなプログラマがいないからだよ。
Ruby周りにはお前みたいなクズしかいないから駄目なんだよ。
プログラミング出来ないのなら黙ってろ。
今のお前が為すべきは、お前が持っているonigmo環境で該当パターンを試し、結果を共有することだ。
Rubyの評判を気にすることではない。
Ruby+onigmoの組み合わせでばっちり動くのなら、
「他環境はゴミです！みなさんの悩みはRubyで解決出来ます！この機会に乗り換えてください！」と言えばいいだけだ。
動くんじゃないかな、みたいなお前の希望的観測なんて何の役にも立たない。
或いは、onigmo単独では動くがRubyのバグ互換モードでは動かない、というのが事実なら、
「Rubyは次のメジャーアップデートでここが対策されます！みなさんご期待ください！」
と言えばいいだけだ。
実際、正規表現の方言/バグに参っている連中はいるんだから、それで乗り換えてくれるだろうさ。
実際、Rubyの奴らはこういう事を全くしない。
そしてRubyの評判だけを気にしているからRubyはゴミのままなんだよ。
871の件、Perl5.6だがPCREもか？と思って試したが、PCREもだ。
そしてPCREには
> using the same syntax and semantics as Perl 5.
と書いてある。つまりこれが本当ならPerl5のバグも含めて挙動は同一、ということになる。
しかしバグまで含めて同一とするにはPerlがこれを仕様化していないとほぼあり得ない。
そこでPerlを確認してみたが、どうやら以下がそれらしい。
> Repeated Patterns Matching a Zero-length Substring
> https://perldoc.perl.org/perlre.html
グダグダ説明はしてあるがPerlは読めんから詳細まで俺の読み通りかは分からんが。
いずれにしても、JavaScriptとPerlは仕様化してる。
Rubyが仕様化しておらず、これが大問題だと認識出来ないのは、Ruby界隈にはまともなプログラマがいないからだよ。
904デフォルトの名無しさん
2019/07/18(木) 20:22:20.04ID:Y8yxmCyC BREという超シンプルな正規表現エンジンが持っていた明解な動作の分かりやすさを
現代の超複雑な正規表現エンジンに求めることには無理がある
ちょっと挙動が変なところがあるけどこのほうが便利だよねってのが現代の考え方
なんじゃないかな、それに適応してるのが現代のプログラマということだろう
ゼロ幅マッチで1歩進む件もそういう挙動にするメリットがあるから
そうしてるんだろう、どんなメリットなのかは分からないが
コスト的な問題やセキュリティ的な問題かも知れない
時代遅れのプログラマが何を言おうが正直興味ないわ
現代の正規表現で見れば初心者だし
初心者が内部動作の仮説を立てたところで当たるわけがない
しかもたった数例のコードの動作を見ただけでだ、あほらしい
現代の超複雑な正規表現エンジンに求めることには無理がある
ちょっと挙動が変なところがあるけどこのほうが便利だよねってのが現代の考え方
なんじゃないかな、それに適応してるのが現代のプログラマということだろう
ゼロ幅マッチで1歩進む件もそういう挙動にするメリットがあるから
そうしてるんだろう、どんなメリットなのかは分からないが
コスト的な問題やセキュリティ的な問題かも知れない
時代遅れのプログラマが何を言おうが正直興味ないわ
現代の正規表現で見れば初心者だし
初心者が内部動作の仮説を立てたところで当たるわけがない
しかもたった数例のコードの動作を見ただけでだ、あほらしい
905デフォルトの名無しさん
2019/07/18(木) 20:44:40.06ID:PnG1z3PK >>902
お前みたいなゴミに回答する意味はないが、一応つけておいてやる。
> 今の複雑化した正規表現エンジンってエンジンを作った人ですらどう動くのか
> 予測が難しいところがあるのでは
そんなわけあるか馬鹿タレ。
今現在もスクリプタはプログラマからすると一段下に見られてて、
「スクリプタをプログラマと呼ぶな」という奴も一定数居るだろ。
その理由がこれだよ。
ガチのプログラマは数年前に他人が記述したコードでも必要あれば修正するしかない。
だからこの為に多大なる手間をかけてコードを整備してる。
スクリプタがやってる、今書いて今動いたら捨てておｋ、なんて甘い世界ではない。
まともなコードなら未来永劫整備可能だし、また、それを目指しているのがプログラマだ。
実際、Linuxなんて30年越しで整備され続けてるだろ。
数年前にお前が書いたコードすら読めないのは、お前の問題であって、それを全体のように言うな。
だからスクリプタは馬鹿にされるし、嫌われるんだよ。
正規表現エンジンなんてプログラミング全体からするとかなり簡単な部類だ。
動けばいいだけのエンジンなら再帰しまくりで1000行程度だろう。
最悪全交換でいい規模だから、そこまでガチで整備されている事は期待出来ないが、
それにしてもこの程度の規模のプログラムを読めない、ってことはあり得ない。
高速化はプログラムに対して「複雑度」を増すものではない。
具体的に言うと、静的コールグラフを複雑化することはなく、
単に遅い関数を速い関数に入れ替える、というのが基本になる。
だから、正規表現エンジンを読めない、というのなら、書いた奴か読む奴が馬鹿なだけであって、
ちゃんとした奴が書いたエンジンをちゃんとした奴が読めば確実に読める。
お前みたいなゴミに回答する意味はないが、一応つけておいてやる。
> 今の複雑化した正規表現エンジンってエンジンを作った人ですらどう動くのか
> 予測が難しいところがあるのでは
そんなわけあるか馬鹿タレ。
今現在もスクリプタはプログラマからすると一段下に見られてて、
「スクリプタをプログラマと呼ぶな」という奴も一定数居るだろ。
その理由がこれだよ。
ガチのプログラマは数年前に他人が記述したコードでも必要あれば修正するしかない。
だからこの為に多大なる手間をかけてコードを整備してる。
スクリプタがやってる、今書いて今動いたら捨てておｋ、なんて甘い世界ではない。
まともなコードなら未来永劫整備可能だし、また、それを目指しているのがプログラマだ。
実際、Linuxなんて30年越しで整備され続けてるだろ。
数年前にお前が書いたコードすら読めないのは、お前の問題であって、それを全体のように言うな。
だからスクリプタは馬鹿にされるし、嫌われるんだよ。
正規表現エンジンなんてプログラミング全体からするとかなり簡単な部類だ。
動けばいいだけのエンジンなら再帰しまくりで1000行程度だろう。
最悪全交換でいい規模だから、そこまでガチで整備されている事は期待出来ないが、
それにしてもこの程度の規模のプログラムを読めない、ってことはあり得ない。
高速化はプログラムに対して「複雑度」を増すものではない。
具体的に言うと、静的コールグラフを複雑化することはなく、
単に遅い関数を速い関数に入れ替える、というのが基本になる。
だから、正規表現エンジンを読めない、というのなら、書いた奴か読む奴が馬鹿なだけであって、
ちゃんとした奴が書いたエンジンをちゃんとした奴が読めば確実に読める。
906デフォルトの名無しさん
2019/07/18(木) 20:46:26.35ID:PnG1z3PK > バグと言えばバグだけど
単なるバグだ馬鹿タレ。
> 総合的に考えてみてこの動作が最適だからこのままにしようという部分もたくさんあると思う
非互換になるのでどこでアップデートして修正するかは言語側の選択となる。
だからその前段階、つまり今どこにバグがあってどれくらい問題なのか把握し、
それを広報して共有し、どのタイミングで修正するかを話し合わないといけない。
Rubyはこれが全く出来てない。だからゴミのままなんだよ。
> だから怠慢という言葉はちょっと違う気がするなぁ
バグだと認識した上で、それを仕様として広報するのが最低の義務。
JavaScriptとPerlはそれをやっている。
Rubyの現状はバグに気づいてないか、敢えて黙っているかで、どちらにしても糞でしかない。
> つまりonigmoのことを言ってるんだけどonigmo自体は空文字マッチに
> 対応してると記憶してるから
お前がどんだけ馬鹿なのか分からないが、「バグ」ってのは意図してない動作のことを言うんだぞ。
つまり、対応してるつもりが対応できてないから「バグ」なんだよ。
> rubyモードの仕様なんじゃないかな
そう言うのはちゃんと調べてから言え。希望的観測ではミスリードを大量発生させる。
そしてこれをやりまくっているのがJavaScript界隈で、結果、JavaScripterは馬鹿が再生産されまくってる。
そういうのは止めろ。お互いに得る物がない。
>>904
まあ書いた後に読んだから投稿はしておいた。
話すつもりがないのならさようならでいい。
お前は、自身の問題を認識出来てないタイプだ。まあこのタイプもよくいるが。
単なるバグだ馬鹿タレ。
> 総合的に考えてみてこの動作が最適だからこのままにしようという部分もたくさんあると思う
非互換になるのでどこでアップデートして修正するかは言語側の選択となる。
だからその前段階、つまり今どこにバグがあってどれくらい問題なのか把握し、
それを広報して共有し、どのタイミングで修正するかを話し合わないといけない。
Rubyはこれが全く出来てない。だからゴミのままなんだよ。
> だから怠慢という言葉はちょっと違う気がするなぁ
バグだと認識した上で、それを仕様として広報するのが最低の義務。
JavaScriptとPerlはそれをやっている。
Rubyの現状はバグに気づいてないか、敢えて黙っているかで、どちらにしても糞でしかない。
> つまりonigmoのことを言ってるんだけどonigmo自体は空文字マッチに
> 対応してると記憶してるから
お前がどんだけ馬鹿なのか分からないが、「バグ」ってのは意図してない動作のことを言うんだぞ。
つまり、対応してるつもりが対応できてないから「バグ」なんだよ。
> rubyモードの仕様なんじゃないかな
そう言うのはちゃんと調べてから言え。希望的観測ではミスリードを大量発生させる。
そしてこれをやりまくっているのがJavaScript界隈で、結果、JavaScripterは馬鹿が再生産されまくってる。
そういうのは止めろ。お互いに得る物がない。
>>904
まあ書いた後に読んだから投稿はしておいた。
話すつもりがないのならさようならでいい。
お前は、自身の問題を認識出来てないタイプだ。まあこのタイプもよくいるが。
907デフォルトの名無しさん
2019/07/18(木) 21:56:03.46ID:xdHI+pcE 荒らしと会話するな！
荒らしと会話する者も、荒らしだぞ！
プログラマーとは、コードで語る者だけ！
能書きはいらない！
そいつらは荒らしだから、会話するな！
荒らしと会話する者も、荒らしだぞ！
プログラマーとは、コードで語る者だけ！
能書きはいらない！
そいつらは荒らしだから、会話するな！
908デフォルトの名無しさん
2019/07/18(木) 22:31:51.56ID:PnG1z3PK >>907
お前はコードだけで語りすぎだけどな。
結論を書くようにしろよ。
というかRuby界隈の問題は典型的にこれなんだよ。
Rubyの連中と話してても話が前に進まない。
俺が老害プログラマで荒らしだったとして、
それはRubyの為にも、またこのスレを読んでいる連中の知識になるものでもないだろ。
Rubyの連中は精神年齢がちっと低すぎる。
onigumoが該当パターンに対して正しい答えを出せるのなら喧伝すればいいし、
駄目なら今現在正しく返せるPCRE以下だという現実を受け入れるしかない。
どっちでもないってのは、俺には頭おかしいとしか思えないけどな。
まあ確実に言えるのは、Rubyを今から学ぶのは止めとけ、ってことだ。
Rubyはコミュニティの腐り方がどうも他とは違う。
(JavaScriptも腐ってはいるが、あれは「若すぎる」のが原因だ。
かといって放置しても自然に改善するものでもないが）
お前はコードだけで語りすぎだけどな。
結論を書くようにしろよ。
というかRuby界隈の問題は典型的にこれなんだよ。
Rubyの連中と話してても話が前に進まない。
俺が老害プログラマで荒らしだったとして、
それはRubyの為にも、またこのスレを読んでいる連中の知識になるものでもないだろ。
Rubyの連中は精神年齢がちっと低すぎる。
onigumoが該当パターンに対して正しい答えを出せるのなら喧伝すればいいし、
駄目なら今現在正しく返せるPCRE以下だという現実を受け入れるしかない。
どっちでもないってのは、俺には頭おかしいとしか思えないけどな。
まあ確実に言えるのは、Rubyを今から学ぶのは止めとけ、ってことだ。
Rubyはコミュニティの腐り方がどうも他とは違う。
(JavaScriptも腐ってはいるが、あれは「若すぎる」のが原因だ。
かといって放置しても自然に改善するものでもないが）
909デフォルトの名無しさん
2019/07/19(金) 00:09:18.78ID:KcCrOwH9 PCREに非包含オペレータが搭載されたら起こしてくれ
910デフォルトの名無しさん
2019/07/19(金) 00:50:19.02ID:CNkXpMDT >>909
というかお前もそうだが、onigmo使ってるなら何で試して動作報告してくれないんだ？
そういうところがRubyのコミュニティはおかしいんだよ。
「みんなで前に進む」という感覚がない。
ちなみに
> 鬼車の中の人と Ruby の間の確執がなければとっくの昔に実装されていたのだろうかと思ったり思わなかったり。
> https://qiita.com/k-takata/items/4e45121081c83d3d5bfd
これって何？知ってたら教えてくれれば助かる。
というかお前もそうだが、onigmo使ってるなら何で試して動作報告してくれないんだ？
そういうところがRubyのコミュニティはおかしいんだよ。
「みんなで前に進む」という感覚がない。
ちなみに
> 鬼車の中の人と Ruby の間の確執がなければとっくの昔に実装されていたのだろうかと思ったり思わなかったり。
> https://qiita.com/k-takata/items/4e45121081c83d3d5bfd
これって何？知ってたら教えてくれれば助かる。
911デフォルトの名無しさん
2019/07/19(金) 02:29:00.41ID:CNkXpMDT >>909
入る予定なんてないだろう。
> 8.2 Perl
> Perl には最短一致の繰り返し、バックトラック
> の抑制、否定先読みがある。これにより、非包含オ
> ペレータに似た効果を得ることができる。しかし、
> 7.2 節で詳しく述べたようにこれらは形式言語理論
> からすると適切に扱えず、正規表現の組合せなどに
> 問題が生じる。
> https://staff.aist.go.jp/tanaka-akira/pub/prosym49-akr-paper.pdf
つまり理論畑の人には問題があるが、プログラミング上問題はないんだろ。
そりゃ入れないだろ。
入る予定なんてないだろう。
> 8.2 Perl
> Perl には最短一致の繰り返し、バックトラック
> の抑制、否定先読みがある。これにより、非包含オ
> ペレータに似た効果を得ることができる。しかし、
> 7.2 節で詳しく述べたようにこれらは形式言語理論
> からすると適切に扱えず、正規表現の組合せなどに
> 問題が生じる。
> https://staff.aist.go.jp/tanaka-akira/pub/prosym49-akr-paper.pdf
つまり理論畑の人には問題があるが、プログラミング上問題はないんだろ。
そりゃ入れないだろ。
912デフォルトの名無しさん
2019/07/19(金) 03:16:00.34ID:CNkXpMDT >>910
自己レスだがだいたい分かった。
その他はリンク切れが多くて詳細までは追えないが、どうやら、勝手に使ったことに対して怒っているらしい。
https://kkos.hatenadiary.org/entries/2007/05/25#1180100250
が、ライセンス違反でなければ勝手に使え、というのがBSDだし、
告知しなかったことに関してはRuby側が悪いわけでもない気がするが。
ただこれなら鬼車にはRubyバグを作り込む必要がないから芽がある気はする。
そして文句を言ったところで鬼雲にフォークしてマージしたのなら実質大して変わらない気もする。
よく分からん所で喧嘩してるなとは思う。
自己レスだがだいたい分かった。
その他はリンク切れが多くて詳細までは追えないが、どうやら、勝手に使ったことに対して怒っているらしい。
https://kkos.hatenadiary.org/entries/2007/05/25#1180100250
が、ライセンス違反でなければ勝手に使え、というのがBSDだし、
告知しなかったことに関してはRuby側が悪いわけでもない気がするが。
ただこれなら鬼車にはRubyバグを作り込む必要がないから芽がある気はする。
そして文句を言ったところで鬼雲にフォークしてマージしたのなら実質大して変わらない気もする。
よく分からん所で喧嘩してるなとは思う。
913デフォルトの名無しさん
2019/07/19(金) 11:33:59.54ID:bgAzEf51 このスレでコミュニティうんぬんは脱線しすぎじゃないかい。スレタイとなんも関係ないやろ。
914デフォルトの名無しさん
2019/07/20(土) 15:46:35.52ID:KXtQuYxh 本当にプログラマなのかな
915デフォルトの名無しさん
2019/07/20(土) 17:29:27.69ID:AFOF1ubv JSです
「はい」「はい」
「うん」「うん」
「■●」「■●」
「△◎」「△◎」
など、同じ文字列2回(あるいは2回以上)の繰り返しを探すにはどうすればよいでしょうか？
/「(.+)+」/
とかだと、1回目と2回目が違ってもヒットしちゃいますよね…？
「はい」「はい」
「うん」「うん」
「■●」「■●」
「△◎」「△◎」
など、同じ文字列2回(あるいは2回以上)の繰り返しを探すにはどうすればよいでしょうか？
/「(.+)+」/
とかだと、1回目と2回目が違ってもヒットしちゃいますよね…？
917915
2019/07/20(土) 17:37:46.94ID:AFOF1ubv918デフォルトの名無しさん
2019/07/20(土) 17:45:51.81ID:kkJ7q95a919デフォルトの名無しさん
2019/07/20(土) 20:12:32.11ID:AFOF1ubv >>918
3つ目の
# 重複文字列の抽出にも応用できます
pry(main)> '東京都日野市日野市ほげほげ'.match(/(.+)(\1)/)
=> #<MatchData "日野市日野市" 1:"日野市" 2:"日野市">
ですね、ありがとうございます…！
3つ目の
# 重複文字列の抽出にも応用できます
pry(main)> '東京都日野市日野市ほげほげ'.match(/(.+)(\1)/)
=> #<MatchData "日野市日野市" 1:"日野市" 2:"日野市">
ですね、ありがとうございます…！
920デフォルトの名無しさん
2019/07/21(日) 20:31:55.31ID:Bdf0kkIf >>912
ttps://kkos.hatenadiary.org/entry/20070906/1189084566
松本氏はrb_enc_mbclen()のインターフェースが不適切であるという指摘に対して、何故、その原因を私に責任転嫁したのでしょうか？
rb_enc_mbclen()のインターフェースが不適切になっている本当の理由は何でしょうか？
まつもと
元の表現は「鬼車から継承した」と書いただけで、別に「鬼車に責任がある」というつもりはありませんでした(実際「責任」はないわけですし)。
現在のインタフェースになっている原因が「鬼車がそうなっていたから」であり、その理由は「まつもとがGB18030のようなエンコーディングへの対応に対する関心が薄かった」ということです。
「だったら、最初からそう書けよ」と言われそうですが、すいません、言葉が足りませんでした。
ttps://kkos.hatenadiary.org/entry/20070906/1189084566
松本氏はrb_enc_mbclen()のインターフェースが不適切であるという指摘に対して、何故、その原因を私に責任転嫁したのでしょうか？
rb_enc_mbclen()のインターフェースが不適切になっている本当の理由は何でしょうか？
まつもと
元の表現は「鬼車から継承した」と書いただけで、別に「鬼車に責任がある」というつもりはありませんでした(実際「責任」はないわけですし)。
現在のインタフェースになっている原因が「鬼車がそうなっていたから」であり、その理由は「まつもとがGB18030のようなエンコーディングへの対応に対する関心が薄かった」ということです。
「だったら、最初からそう書けよ」と言われそうですが、すいません、言葉が足りませんでした。
921デフォルトの名無しさん
2019/07/22(月) 01:27:11.95ID:dN38X5eV >>920
おおサンクス。
ただ、それって 2007/05/25 より後だから、別件だね。
無駄に喧嘩してるなあ。
内容はkkos氏の方が正しい。
鬼車は最速を目指したライブラリなのだから、無駄なことは出来る限り省かなければならない。
そもそもスクリプト言語で不完全な文字列って、バイト列を直接与えるとかしないと出来ないはずだし、
その場合にはRuby側でチェックしておけ、というのはその通りで、極めて妥当な要求だ。
Rubyなんてmutable stringなのだから最初に必ずコピーが必要で、普通はその時にやればいいだけ。
その方が今時の型安全にも合うし。
それを「実は僕も問題だと思ってたんだよね」みたいな受け方をするからそりゃ不信感が募る。
これは完全にMatzが糞で、実はC流のグダグダコードを書いていて、
どこで何をするべきか分かってないのだと思う。
そしてRuby界隈ではMatzは変に神格化されてて裸の王様化してる、ってとこだろう。
878の動作結果を見ても、誰も問題だとは指摘出来ないようだし。
これはkkos氏が言っているとおりがそのままで、普通は、というか本当は、
1. Rubyは rb_enc_mbclen(p,end,enc) で記述していたが、
2. 鬼車が rb_enc_mbclen(p,enc) で記述されていることに気づき、
3. 何で end が無いのか確認して、
4. Ruby側にチェックをつける
という流れになる。
1が無いのに、「し、知ってたし」みたいなことを言うから「嘘つくな」になる。
つってもこういうちょっとズルいというか卑怯というか、絶対俺のバグは認めないマンは残念ながら普通にいるから、
いちいち問いただしても始まらない。ただ、多分、kkos氏が切れたのはその後、
> それはそれとして、鬼車を呼ぶ前に「一文字を完成していない不完全なバイト列は含まない」ことをチェックするのはかなりコストが高いのですが、
これだとは思う。鬼車側でチェックしたらコストが安い訳でもないのに、これはない。
これはコイツとは一緒にはやれない、という結論を出すには十分だ。
本来Aでやるべき事をBでやる、みたいなことをすると、コードが一気に劣化していく。
長いこと保守するつもりなら絶対に飲めない。実際、鬼車は今も保守されているし、kkos氏の判断は妥当だ。
おおサンクス。
ただ、それって 2007/05/25 より後だから、別件だね。
無駄に喧嘩してるなあ。
内容はkkos氏の方が正しい。
鬼車は最速を目指したライブラリなのだから、無駄なことは出来る限り省かなければならない。
そもそもスクリプト言語で不完全な文字列って、バイト列を直接与えるとかしないと出来ないはずだし、
その場合にはRuby側でチェックしておけ、というのはその通りで、極めて妥当な要求だ。
Rubyなんてmutable stringなのだから最初に必ずコピーが必要で、普通はその時にやればいいだけ。
その方が今時の型安全にも合うし。
それを「実は僕も問題だと思ってたんだよね」みたいな受け方をするからそりゃ不信感が募る。
これは完全にMatzが糞で、実はC流のグダグダコードを書いていて、
どこで何をするべきか分かってないのだと思う。
そしてRuby界隈ではMatzは変に神格化されてて裸の王様化してる、ってとこだろう。
878の動作結果を見ても、誰も問題だとは指摘出来ないようだし。
これはkkos氏が言っているとおりがそのままで、普通は、というか本当は、
1. Rubyは rb_enc_mbclen(p,end,enc) で記述していたが、
2. 鬼車が rb_enc_mbclen(p,enc) で記述されていることに気づき、
3. 何で end が無いのか確認して、
4. Ruby側にチェックをつける
という流れになる。
1が無いのに、「し、知ってたし」みたいなことを言うから「嘘つくな」になる。
つってもこういうちょっとズルいというか卑怯というか、絶対俺のバグは認めないマンは残念ながら普通にいるから、
いちいち問いただしても始まらない。ただ、多分、kkos氏が切れたのはその後、
> それはそれとして、鬼車を呼ぶ前に「一文字を完成していない不完全なバイト列は含まない」ことをチェックするのはかなりコストが高いのですが、
これだとは思う。鬼車側でチェックしたらコストが安い訳でもないのに、これはない。
これはコイツとは一緒にはやれない、という結論を出すには十分だ。
本来Aでやるべき事をBでやる、みたいなことをすると、コードが一気に劣化していく。
長いこと保守するつもりなら絶対に飲めない。実際、鬼車は今も保守されているし、kkos氏の判断は妥当だ。
922デフォルトの名無しさん
2019/08/01(木) 15:57:12.21ID:BVNOJ7mG >>789やってくれる人はいないか〜
２ｃｈ全盛期なら誰かしらやってくれた可能性高いけどすっかり寂れたな
onigmoに興味があるならtakata氏の日記を読破してみてはどうかな
作りながら考えてたことが分かって面白かったよ
２ｃｈ全盛期なら誰かしらやってくれた可能性高いけどすっかり寂れたな
onigmoに興味があるならtakata氏の日記を読破してみてはどうかな
作りながら考えてたことが分かって面白かったよ
923デフォルトの名無しさん
2019/08/24(土) 12:41:17.80ID:fR0bFJ1E perlで
(?<=(aa|bb))c
ならokだが
(?<=(aa|bbb))c
だとVariable length lookbehind not implementedになるの納得いかないなー
確かに戻り読み部分の長さに複数の可能性があるけど明らかに有限じゃん
秀丸のHmJre.dllだと通るようだ
(?<=(aa|bb))c
ならokだが
(?<=(aa|bbb))c
だとVariable length lookbehind not implementedになるの納得いかないなー
確かに戻り読み部分の長さに複数の可能性があるけど明らかに有限じゃん
秀丸のHmJre.dllだと通るようだ
924デフォルトの名無しさん
2019/08/24(土) 13:46:10.60ID:6nD2xE5w (?<=(aa.*|bbb))c
925デフォルトの名無しさん
2019/08/25(日) 15:17:23.04ID:GRZE+Rz9 (?<=aa|bbb)c
926デフォルトの名無しさん
2019/09/01(日) 12:33:19.59ID:fodjUzDJ JS（ES2017）です
「貫樣」みたいな、中国語でしか使われないような怪しい漢字を弾きたい
（日本語で使われる漢字のみ許可したい この場合は「貫」だけ残して「樣」は消したい）
のですが
CJKとか言って一緒くたになっている以上、Unicode範囲指定などで判別することはできないですかね…？
「貫樣」みたいな、中国語でしか使われないような怪しい漢字を弾きたい
（日本語で使われる漢字のみ許可したい この場合は「貫」だけ残して「樣」は消したい）
のですが
CJKとか言って一緒くたになっている以上、Unicode範囲指定などで判別することはできないですかね…？
927926
2019/09/01(日) 12:38:35.03ID:fodjUzDJ 「樣」は一応日本語でも使うみたいですね…
とりあえず常用漢字じゃなければ弾くくらいでもいいのですが
常用漢字表を作って比較するくらいしかない…のかな？
とりあえず常用漢字じゃなければ弾くくらいでもいいのですが
常用漢字表を作って比較するくらいしかない…のかな？
928デフォルトの名無しさん
2019/09/01(日) 13:31:25.10ID:kCJZVLuH929デフォルトの名無しさん
2019/09/01(日) 13:35:35.35ID:kCJZVLuH ねむい
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/CJK/gb2312-80.gif
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/index-j.html
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/CJK/gb2312-80.gif
http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/index-j.html
930デフォルトの名無しさん
2019/09/01(日) 18:46:39.31ID:VXfAHt8z >>927
樣は様の旧字で現在でも許容字体扱いだから「常用漢字表」にも
出て来る。
https://ja.wikipedia.org/wiki/%E5%B8%B8%E7%94%A8%E6%BC%A2%E5%AD%97%E4%B8%80%E8%A6%A7
>928-929みたいなのはあくまでコンピューター用のコードの
まとまりの話だから常用漢字か否かは区別していない。
上のリンクのウィキの本表をエクセルにコピーして２列目の
通用字体だけを残して改行を消してやり、それと平仮名や
記号を除外規定にして残り全部消すとかなら正規表現だけでも
さっさと終わるんじゃないかな。
JISの範囲内だけがほしいならシフトJISで保存したら他は
疑問符になるだろうからそれをまとめて削除したらおしまいだろうが
繁体字の樣は残る。簡体字の[木羊]は消える。
樣は様の旧字で現在でも許容字体扱いだから「常用漢字表」にも
出て来る。
https://ja.wikipedia.org/wiki/%E5%B8%B8%E7%94%A8%E6%BC%A2%E5%AD%97%E4%B8%80%E8%A6%A7
>928-929みたいなのはあくまでコンピューター用のコードの
まとまりの話だから常用漢字か否かは区別していない。
上のリンクのウィキの本表をエクセルにコピーして２列目の
通用字体だけを残して改行を消してやり、それと平仮名や
記号を除外規定にして残り全部消すとかなら正規表現だけでも
さっさと終わるんじゃないかな。
JISの範囲内だけがほしいならシフトJISで保存したら他は
疑問符になるだろうからそれをまとめて削除したらおしまいだろうが
繁体字の樣は残る。簡体字の[木羊]は消える。
931デフォルトの名無しさん
2019/09/01(日) 21:04:09.80ID:fO6VcsLE Google謹製の正規表現ライブリ「re2」でググったら「バイオハザード2 RE:2」が検索上位に来るのどうにかならない？
932デフォルトの名無しさん
2019/09/01(日) 22:01:25.54ID:Zrnas7uJ >>931
s/^(.+)でググったら「バイオハザード2 RE:2」が検索上位に来るのどうにかならない？$/$1/
s/^(.+)でググったら「バイオハザード2 RE:2」が検索上位に来るのどうにかならない？$/$1/
933デフォルトの名無しさん
2019/09/01(日) 22:50:02.12ID:8GDP8quV RE2 regex とか RE2 正規表現 とかでググれば
934デフォルトの名無しさん
2019/09/10(火) 22:48:57.92ID:CokwQGf+ 直前の文字が1回以上出現することが確実なケースで、仮に0回の出現として考慮しても問題がないという場合に、
+ではなく*で正規表現を記述する理由はありますか？
例えば、慣例として*のほうを使うとか、*とするとマッチしない場合のみ+を使うとかそういう
+ではなく*で正規表現を記述する理由はありますか？
例えば、慣例として*のほうを使うとか、*とするとマッチしない場合のみ+を使うとかそういう
935デフォルトの名無しさん
2019/09/10(火) 23:21:08.02ID:1dbF51qB 0回も許容するなら+ではなく*にする理由は0回も許容するからとしか
936デフォルトの名無しさん
2019/09/10(火) 23:26:41.78ID:L5QX1JAH 具体例で示してくれんとなんか曖昧でよくわからんね
937デフォルトの名無しさん
2019/09/11(水) 12:05:55.89ID:zFEVPQj4 >1回以上出現することが確実なケース
>仮に0回の出現として考慮しても問題がない
矛盾してるな
>仮に0回の出現として考慮しても問題がない
矛盾してるな
938デフォルトの名無しさん
2019/09/11(水) 15:12:05.49ID:wb8QVF41939デフォルトの名無しさん
2019/09/11(水) 16:12:55.15ID:h8Pfy2ne940デフォルトの名無しさん
2019/09/12(木) 02:26:26.53ID:xpiKRNxb やっぱ質問して放置か、教える側も学習すべきだな
まともな質問じゃないと思ったらスルーでいい
まともな質問じゃないと思ったらスルーでいい
941デフォルトの名無しさん
2019/09/12(木) 04:33:29.68ID:+6m2JHnd 別におかしな質問じゃないだろ
942デフォルトの名無しさん
2019/09/12(木) 06:58:37.97ID:1ik9S0iw いや普通におかしいだろ
なんか無理矢理の条件考えて論争させようとしてるような気がする
なんか無理矢理の条件考えて論争させようとしてるような気がする
943デフォルトの名無しさん
2019/09/12(木) 08:21:20.40ID:xpiKRNxb 自分なら人にこういう質問レスを書くかなって考えてみて絶対書かないと
思うものにはレス付けないのがいいかもね
説明不足で意味不明なものとかも
思うものにはレス付けないのがいいかもね
説明不足で意味不明なものとかも
944デフォルトの名無しさん
2019/09/12(木) 09:22:01.93ID:TOasMGF3 ●Regular Expressionの使用環境
Mery
●検索か置換か？
置換
●説明
属性内のアルファベット小文字を削除
●対象データ
id="105I42b 104I41b"
id="99E65e 95B43d 92B87d"
id="97B22d 95D18a 93B22c 93E23b"
●希望する結果
id="105I42 104I41"
id="99E65 95B43 92B87"
id="97B22 95D18 93B22 93E23"
id="((\d+[A-Z]\d+)[a-z] ?){2,}"で検索は出来たのですが置換が思い浮かびません
Mery
●検索か置換か？
置換
●説明
属性内のアルファベット小文字を削除
●対象データ
id="105I42b 104I41b"
id="99E65e 95B43d 92B87d"
id="97B22d 95D18a 93B22c 93E23b"
●希望する結果
id="105I42 104I41"
id="99E65 95B43 92B87"
id="97B22 95D18 93B22 93E23"
id="((\d+[A-Z]\d+)[a-z] ?){2,}"で検索は出来たのですが置換が思い浮かびません
945デフォルトの名無しさん
2019/09/12(木) 10:00:21.41ID:bJPykHLq わかりやすいように、できるだけそのまま書くならこうかな
●検索文字列
(id="|\G )((\d+[A-Z]\d+))[a-z]
●置換文字列
\1\2
●検索文字列
(id="|\G )((\d+[A-Z]\d+))[a-z]
●置換文字列
\1\2
946デフォルトの名無しさん
2019/09/12(木) 10:04:35.65ID:bJPykHLq 置換に問題は無いけど()が二重になってたミス修正
(id="|\G )(\d+[A-Z]\d+)[a-z]
(id="|\G )(\d+[A-Z]\d+)[a-z]
947デフォルトの名無しさん
2019/09/12(木) 10:30:50.86ID:TOasMGF3 >946
出来ました！
ありがとうございます。
田中哲スペシャルっていうやり方なのでしょうか
出来ました！
ありがとうございます。
田中哲スペシャルっていうやり方なのでしょうか
948デフォルトの名無しさん
2019/09/12(木) 11:08:37.62ID:bJPykHLq \Gは照合開始位置と呼ばれる物で、マッチした箇所の後の境界にマッチしてくれるので
さっきのように(特定の文字列or前回置換しところ)の後に置換したい文字列があるときとかに便利で定番
田中哲スペシャルは\gで同じ表現をもう一回使うって奴だから違うかな
さっきのように(特定の文字列or前回置換しところ)の後に置換したい文字列があるときとかに便利で定番
田中哲スペシャルは\gで同じ表現をもう一回使うって奴だから違うかな
949デフォルトの名無しさん
2019/09/12(木) 11:58:31.87ID:TOasMGF3 >948
勉強になります。
ちなみに最初の値にはアルファベットがついてないケースだと拾えなかったのですが
id="97B22 95D18a 93B22c 93E23b"
対応策ありますでしょうか？
勉強になります。
ちなみに最初の値にはアルファベットがついてないケースだと拾えなかったのですが
id="97B22 95D18a 93B22c 93E23b"
対応策ありますでしょうか？
950デフォルトの名無しさん
2019/09/12(木) 12:04:38.94ID:xpiKRNxb 自分ならこの時点でスルー
\Gは文頭にもマッチするから誤爆対策を忘れずに
\Gは文頭にもマッチするから誤爆対策を忘れずに
951デフォルトの名無しさん
2019/09/12(木) 15:04:33.55ID:bJPykHLq952デフォルトの名無しさん
2019/09/12(木) 18:04:49.29ID:TOasMGF3 >951
ヒントありがとうございます。
残りは自分でがんばってみます。
ヒントありがとうございます。
残りは自分でがんばってみます。
953デフォルトの名無しさん
2019/09/12(木) 18:08:37.95ID:EfYu2rO4 文字列 "プログラマー" を "プロクライマー" に書き換える正規表現を教えて下さい
954デフォルトの名無しさん
2019/09/12(木) 21:50:17.55ID:Jdu1U3XN そこにソースがあるから登るんだ。
955デフォルトの名無しさん
2019/09/12(木) 22:19:07.70ID:cqw0/uFd 正規表現の使い方じゃなく作り方、バックトラックなど理論から解説している書籍やそれに準ずるサイトなど知っていたらご教示ください。
こうやればこうなるよ、こういうときはこうすればいいんだよ的な学習では身に付かなくて…
こうやればこうなるよ、こういうときはこうすればいいんだよ的な学習では身に付かなくて…
956デフォルトの名無しさん
2019/09/12(木) 22:56:30.12ID:Yy9Clfy1 自分が参考にしたのはここだったかな
http://fussy.web.fc2.com/algo/search5_regex.htm
実装の仕方がある程度分かれば鬼車の作者さんのブログ(rubyの一件以前の記事)も参考になると思う
http://fussy.web.fc2.com/algo/search5_regex.htm
実装の仕方がある程度分かれば鬼車の作者さんのブログ(rubyの一件以前の記事)も参考になると思う
957デフォルトの名無しさん
2019/09/12(木) 23:14:33.93ID:Uy9QyXie ありがとうございます！
rubyの一件って何ですか？（何て検索したらいいですか？）
rubyの一件って何ですか？（何て検索したらいいですか？）
958デフォルトの名無しさん
2019/09/12(木) 23:43:24.49ID:Yy9Clfy1 Rubyの作者さんと何かあったようで嫌気が差したのかそれ以後ブログで正規表現のことを
取り上げる頻度がめっきり減っちゃったんですよ
取り上げる頻度がめっきり減っちゃったんですよ
959デフォルトの名無しさん
2019/09/13(金) 08:32:54.25ID:sQZEDK+j960デフォルトの名無しさん
2019/09/13(金) 10:47:34.78ID:wKEqF87n961デフォルトの名無しさん
2019/09/13(金) 11:54:40.09ID:X5DxpBbM 正規表現はどの言語でも共通で使えますか？それともちょっと違ったりしますか？
962デフォルトの名無しさん
2019/09/13(金) 12:02:22.73ID:KuW4wLhZ ちょっと違ったりします
963デフォルトの名無しさん
2019/09/13(金) 13:25:46.31ID:8XwQqyT8 Ruby で作った。
一旦、パターンで一致させてから、一致した行だけを変換した。
ただし、同じ行に、id="〜" が複数あると、バグる！
src = <<'EOT'
id="aAxy Xz"
あ
id=""
id="9"
id="9y"
EOT
# id=" で始まって、" 以外の文字が続いて、" で終わる
re = /id\=\"([^\"]+)\"/ # ( ) 内は、$1
dest = src.gsub( re ) do |line|
'id="' + $1.delete( "a-z" ) + '"'
end
print dest
出力
id="A X"
あ
id=""
id="9"
id="9"
一旦、パターンで一致させてから、一致した行だけを変換した。
ただし、同じ行に、id="〜" が複数あると、バグる！
src = <<'EOT'
id="aAxy Xz"
あ
id=""
id="9"
id="9y"
EOT
# id=" で始まって、" 以外の文字が続いて、" で終わる
re = /id\=\"([^\"]+)\"/ # ( ) 内は、$1
dest = src.gsub( re ) do |line|
'id="' + $1.delete( "a-z" ) + '"'
end
print dest
出力
id="A X"
あ
id=""
id="9"
id="9"
965デフォルトの名無しさん
2019/09/16(月) 02:45:59.31ID:dK4dr8mE JSで
101 dogs
7 little goats
30 8 year old humans
↑をそれぞれ
["101", "dogs"]
["7", "little goats"]
["30", "8 year old humans"]
と切り分けるにはどんな正規表現を使えばよいでしょうか？
["7", " ", "little goats"]のような形でもかまいません
.match(/^\d+\s|.+$/)
だと
["7 ", "little goats"]
になってしまい、数字のあとの余計な半角スペースをあとで取り除かなければならなくなるのがなんか嫌で…
101 dogs
7 little goats
30 8 year old humans
↑をそれぞれ
["101", "dogs"]
["7", "little goats"]
["30", "8 year old humans"]
と切り分けるにはどんな正規表現を使えばよいでしょうか？
["7", " ", "little goats"]のような形でもかまいません
.match(/^\d+\s|.+$/)
だと
["7 ", "little goats"]
になってしまい、数字のあとの余計な半角スペースをあとで取り除かなければならなくなるのがなんか嫌で…
966デフォルトの名無しさん
2019/09/16(月) 02:59:29.74ID:/xGIA7r1 正規表現を使えないなら文字列操作でやればいいだけ
正規表現を使いこなせてない人が使うとバグの温床になるからお勧めしない
正規表現を使いこなせてない人が使うとバグの温床になるからお勧めしない
967デフォルトの名無しさん
2019/09/16(月) 07:18:26.85ID:m2l8x1P1 >>965
.split(' ', 2)
.split(' ', 2)
968デフォルトの名無しさん
2019/09/16(月) 12:07:55.69ID:oN5KVYJd Ruby では、
chomp で、末尾の改行を削除する。
split の2 は、分割の最大数
text = <<'TEXT'
101 dogs
30 8 year old humans
TEXT
p ary = text.lines( chomp: true ).map { |line| line.split( " ", 2 ) }
出力
[["101", "dogs"], ["30", "8 year old humans"]]
chomp で、末尾の改行を削除する。
split の2 は、分割の最大数
text = <<'TEXT'
101 dogs
30 8 year old humans
TEXT
p ary = text.lines( chomp: true ).map { |line| line.split( " ", 2 ) }
出力
[["101", "dogs"], ["30", "8 year old humans"]]
969デフォルトの名無しさん
2019/09/16(月) 15:25:40.41ID:YU5GpdCi JSでは、
["30", "8 year old humans"]
ではなく
["30","8"]
となる
limitは、分割結果の制限であり、見つかった要素の数をそこまでで打ち切る
["30", "8 year old humans"]
ではなく
["30","8"]
となる
limitは、分割結果の制限であり、見つかった要素の数をそこまでで打ち切る
970968
2019/09/16(月) 15:36:25.96ID:oN5KVYJd >969
えー!!
えー!!
971デフォルトの名無しさん
2019/09/16(月) 15:52:31.08ID:YU5GpdCi972デフォルトの名無しさん
2019/09/16(月) 16:04:28.98ID:2suJbq8i matchじゃなくてsplitで
str.split(/(?<=^\d+) /)
か
array = str.split(" ");
array[0] + array.slice(1).join(" ")
とかじゃない？
str.split(/(?<=^\d+) /)
か
array = str.split(" ");
array[0] + array.slice(1).join(" ")
とかじゃない？
973デフォルトの名無しさん
2019/09/16(月) 16:06:13.84ID:2suJbq8i 間違えた
下の最後こうか
[array[0], array.slice(1).join(" ")]
下の最後こうか
[array[0], array.slice(1).join(" ")]
974デフォルトの名無しさん
2019/09/16(月) 16:24:50.88ID:VWND3fAL 素直に
"30 8 years old".match(/^(\d+) (.*)$/).slice(1)
じゃいかんの？
"30 8 years old".match(/^(\d+) (.*)$/).slice(1)
じゃいかんの？
975デフォルトの名無しさん
2019/09/16(月) 16:28:11.45ID:53ZoYsUm 正規表現逆引きcgiとかないの？
雑に日本語で書き込んだらAIが判断して正規表現を返してくれる
そんなの
雑に日本語で書き込んだらAIが判断して正規表現を返してくれる
そんなの
976デフォルトの名無しさん
2019/09/16(月) 17:07:19.10ID:YU5GpdCi977デフォルトの名無しさん
2019/09/16(月) 17:20:26.44ID:oN5KVYJd var ary = new Array( 2 )
var str = "30 8 year old humans"
var pos = str.indexOf( " " );
console.log( pos ) // 2
if( pos === -1 ) { // 見つからない
// 何かの処理
} else {
ary[ 0 ] = str.substring( 0, pos )
ary[ 1 ] = str.substring( pos + 1 )
}
console.log( ary ) // [ '30', '8 year old humans' ]
var str = "30 8 year old humans"
var pos = str.indexOf( " " );
console.log( pos ) // 2
if( pos === -1 ) { // 見つからない
// 何かの処理
} else {
ary[ 0 ] = str.substring( 0, pos )
ary[ 1 ] = str.substring( pos + 1 )
}
console.log( ary ) // [ '30', '8 year old humans' ]
978デフォルトの名無しさん
2019/09/16(月) 17:34:55.93ID:hRvCpxCQ979デフォルトの名無しさん
2019/09/16(月) 17:40:28.59ID:enU8we0d >>969
知らなかった
知らなかった
980デフォルトの名無しさん
2019/09/16(月) 18:09:34.33ID:enU8we0d const str = '30 8 year old humans'
(([first, ...rest]) => [first, rest.join(' ')])(str.split(' '))
//=> ["30", "8 year old humans"]
あ、正規表現がねぇｗ
(([first, ...rest]) => [first, rest.join(' ')])(str.split(' '))
//=> ["30", "8 year old humans"]
あ、正規表現がねぇｗ
981デフォルトの名無しさん
2019/09/16(月) 20:46:14.05ID:RGmahsTZ .split(/ (.*)/,2)
レス数が950を超えています。1000を超えると書き込みができなくなります。
ニュース
- 外務省局長は無言で厳しい表情…日中の高官協議終了か 高市首相“台湾”発言で中国が強硬対応 発言撤回求めたか… [BFU★]
- 中国国営メディア「沖縄は日本ではない」… ★6 [BFU★]
- 政府、株式の配当など金融所得を高齢者の医療保険料や窓口負担に反映する方針を固めた [バイト歴50年★]
- ナイツ塙が指摘のローソンコーヒーカップ、ロゴ「L」で誤解生みデザイン変更へ 在庫使い切る3か月後にリニューアル [muffin★]
- バービー、 台湾有事の発言の波紋で「たまったもんじゃない」「高市さんに真意は聞きたい」「国民に向けて説明してほしい」 [muffin★]
- 中国国営メディア「沖縄は日本ではない」…★7 [BFU★]
- 日本政府「高市総理の発言は問題ないと伝え、中国総領事のSNS投稿は問題があると中国に伝えました😊」 [931948549]
- 高市早苗、岸田政権（当時）に「台湾有事は日本の有事か」という質問をしていた [175344491]
- ケンタッキーの○○○バーガーという予告がアレを想起すると話題に [523957489]
- 【悲報】中国→日本行きの航空チケット、高市有事の影響で50万人分がキャンセルされる [834922174]
- 【乞食速報】UFJが5万円配ってる。これもう早苗給付金だろwwwwwwww [201193242]
- 【悲報】早速高市首相のせいで全国の民泊でキャンセルラッシュwwwwwwwwwwww 経営者も嘆き「こんな事は初めてだ…」😲 [871926377]