1read 100read
2011年10月1期UNIX正規表現 TOP カテ一覧 スレ一覧 削除依頼 ▼
・　次のスレ
小中高などの教育機関へUNIXの導入を
ホストが落ちた時の言い訳を考えよう【Var.2】
◆◆詰めスクリプト◆◆
*BSD/ThinkPad


正規表現


1 ：02/12/06 〜 最終レス ：11/08/03
正規表現

2 ：
終了

3 ：
/\s*終\s*了\s*/

4 ：
oreillyの本読めば全てに限りなく近く分る。よって終了。

5 ：
板地害

6 ：
http://www.oreilly.co.jp/BOOK/regex/

7 ：
釣り合いの取れた括弧にマッチする正規表現を教えてください。
()
((()))
((((()))))
(()())
((())(()()))

8 ：
正規表現ってFAだけで実装してるの?PDAも使うの?

9 ：
>>7
無い。

10 ：
(・)(・)
. .) (
( Y )

11 ：
性器表現

12 ：
限界までgrepやればいい気持ち

13 ：
正則表現って訳してる本無かったっけ？

14 ：
詳説正規表現に正則表現という言葉が出てきた気がする

15 ：
>>7
Perl 5.6 以降なら、可能。
#! /usr/local/bin/perl
@kakko = qw[()
())
((()))
(()()))
((((()))))
(()())
((())(()()))];
$regex = qr/[^()]*\((??{$regex})*\)[^()]*/;
foreach (@kakko) {
if(/^$regex$/) {
print "Match: $_\n";
} else {
print "Unmatch: $_\n";
}
}

16 ：
でも、それ正規表現じゃないんじゃないの？
文脈自由文法のクラスでしょ？

17 ：
それ言ったら、今の「正規表現」なんてそもそもの定義から外れちゃうような気がするぞ。

18 ：
数学的文脈におけるいわゆる「正則な表現」だけで括弧の釣り合いにマッチさせるスレはここですか?

19 ：
ここは既に終了したスレです。

20 ：
いやん、正規表現がんばろー。
16>>
拡張正規表現で納得しろ。

21 ：
そもそも正規言語は数をかぞえられないんだから、
拡張正規表現でもないでしょ。

22 ：
拡張正規表現 = 「正規表現」の定義を拡張。;)

23 ：
>>20
言った方がいいかどうかわからんが
16>>
逆だ

24 ：
/^(U).\/*&_$&&*_@&(&*@+|@_(@)(?!<>)_##[o-Q](.*O+)&^&%^#)#+#$/

25 ：
いま glibc のマルチバイト回りをやってる人が書いたドキュメント
http://lc.linux.or.jp/lc2001/papers/dfa-i18n-paper.pdf
http://lc.linux.or.jp/lc2002/papers/hasegawa0918h.pdf
>>13
オートマトンで有名な本
http://www.saiensu.co.jp/books-htm/ISBN4-7819-0374-6.htm
には正則表現って書いてあった。

26 ：
ttp://sorekika.com/dame.jsp?idx=352

27 ：
question = ( to ) ? be : ! be;
　　　　　　　　　-- Wm. Shakespeare

28 ：
凸

29 ：
（＾＾）

30 ：
質問よいでしょうか・・・
英辞郎の読み仮名を削除したいのですが、
｛(←全角です)ではじまり｝(←これも全角です)でおわる文字列を
ごっそり置換したいのですが、どう表現すればいいのかよく
わかりません・・・・　おしえてくださいおながいします

31 ：
>>30
処理系は何？

32 ：
>>30
sed "s/｛.*｝//" < input > output
では駄目かい？

33 ：
>>32
その解は1行に複数の対が出てきたときに破綻する

34 ：
>>31
入れ子になっていない、かつsedが日本語に対応しているならば
s/｛[^｝]*｝//
というパターンを使うのが楽。

35 ：
>>31
Windowsなんですよね・・・xyzzyの置換使おうかと思ってたんですが
あ、Pythonも使い方よくわからないけど(汗汗)入ってます
# Pythonだとどうかくんですかね？？
ダメだったらCygwinでも入れてやってみようと思います。
皆様有難う御座います。

36 ：
秀丸の置換使えば？

37 ：
perlぐらいうごかん？

38 ：

39 ：
>>34さんの方法で問題なく出来ました。
有難う御座いました。とりあえず、この表現の
意味をきちんと理解しとこうと思います。ﾒﾓﾒﾓ･･･
ところで、>>36さん、何故秀丸？

40 ：

41 ：
BNF使え

42 ：
http://pc2.2ch.net/test/read.cgi/software/1040201710/641-643
より移行してきますた。
正規表現の話はこっちでしましょ。
俺には大した知識はないんだが。
>642 ：名無しさん＠お腹いっぱい。 mailto:[sage] ：03/02/21 15:28 ID:esOQbptZ
>なんのために [:alpha:] のような書式があるのかと子一時間
これは知らんかった。
テキストエディタの粋を脱しそうだが。

43 ：
>643 ：名無しさん＠お腹いっぱい。 mailto:[sage] ：03/02/21 15:31 ID:+tcoIlhs
>>>641
>文字クラスが文字コードに依存するって言うのは恥ずかしいことでしかないと思うんだが。
>どんなコードでも入力が同一なら出力も同一であるべきじゃないの？
後半はよくわからんが、文字クラスが文字コードに依存するのは当然のことだと思うぞ。
文字 a は a というアルファベットという意味があるわけではなく単なるコード(0x61)なわけ。
テキストエディタでは普段から文字コードなんて考える必要はないんだけど、
正規表現では [a-z] とすると
Shift-JISなら [\x61-\x7A]
EBCDICなら [\x81-\xA9]
というふうに変わってくる。
当然文字コードに依存する。
ここで文字コードに依存せずに認識するとなると、EBCDICの場合
[a-z]=[\x81-\x89\x91-\x99\xA2-\xA9]
になってしまって本来の [\x81-\xA9] にはならなくなってしまう。
そのために 642 のような [:alpha:] なんかが用意されている。
さもなければ文字コード共通正規表現用文字テーブルなんてものが必要になりかねない。
テキストエディタで扱う文字コードとして EBCDIC を例に出すのは適当ではないが。
エディタがしているのは文字コードを認識して表示するということで、
文字コードを変換しているわけではない。
もちろん明示的に変換(文字コードを変更して保存等)すれば変わる。

44 ：
>文字クラスが文字コードに依存するって言うのは恥ずかしいことでしかないと思うんだが。
そりゃ確かに恥ずかしい。
でも [a-z] という表記が「小文字アルファベットの文字クラスを指定している」ものだと誤解して、
誤用しているほうがもっと恥ずかしい。
「-」を使った表記は文字コード上で連続した複数の文字を意味しているだけだから、
本当に文字クラスを指定しなければならないシーンでは [:lower:] や \l を使うべき。
代表的なエンコーディングでは偶然文字コードが連続しているから
[a-z] で期待した動作になるので常用されているの。

45 ：
[:alpha:] とかってウムラウトがどうたらとかいう話のためにあるのだと思ってた

46 ：
unicode などが本格的に使われ出して
多国語があたり前になったら
[:Japanese:] とか [:Korean:] とか
できるのかな。

47 ：
>>45
その通り。 POSIX ではロケールによって変わるよ。

48 ：
興味があるので誘導されてきました。
ってココは関連Linkないので張るね。
●正規表現最新リンク集2003
ttp://www2.famille.ne.jp/~akio1998/l_grep.html
●正規表現メモ
ttp://www.kt.rim.or.jp/~kbk/regex/regex.html
で向こうのスレでの疑問で思ってたんですが、
| また正規表現の正しい、正しくないってあるのか？
上の引用についてずばり解決してくれる神はおられませんか？
向こうでも思ってたんだけど中途半端な正規化だから文字コードに
依存するって思ってたんですが。

49 ：
>>44
>本当に文字クラスを指定しなければならないシーンでは
> [:lower:] や \l を使うべき。

つーことは[B-Yb-y]は本当に文字クラスを指定せんといかんシーンでは
　[BCDEFGHIJKLMNOPQRSTUVWXYbcdefghijklmnopqrstuvwxyz]
あるいは
　[^AZaz[:digit:](憶えとらんので略)]
と書かねばならんわけか…

50 ：
[:alpha:] とかって、実際に実装されてるのあるの?

51 ：
>>48
ある正規表現が書かれた目的を果たせるかどうかで、正しい正しくないを言うことはで
きるでしょう。ただし目的を果たすといっても厳密でなければならない場合やアバウト
で大丈夫な場合と様々なレベルがあるわけで、ケースに応じて使い分けるのが大人とい
うものです。
それから正規化しているから正規表現というわけじゃないです。ある有限オートマトン
が受理する特定の言語(記号列)を正規言語と呼び、その受理される言語の全ての集合を
正規集合と呼び、その集合を表現する方法を正規表現と呼んでいるのです。文字コード
云々が問題になるのは、SJISやEUCのようなマルチバイトコードで表現された1文字を1
つの記号として認識しない正規表現エンジンがあるからで、またエンジンが認識する場
合でも利用者側が記号としての文字と文字コードとの関係を、[a-zA-Z] と [:alpha:]
のようにゴッチャにしているからです。もっとも後者についてはマルチバイトには依存
しない話ですけれど。
>>49
厳密にはそういうことになります。メンドイのでそこまでする人は少ないでしょうが。

52 ：
| また正規表現の正しい、正しくないってあるのか？
俺なんかの知識じゃたいしたこと言えないが、現在においては統一的な正しさなんて無いと思う。
ものによって実装が違うから、egrepでは正しくedでは正しくないとかあろうね。
使い手が自分で何をしようとしているのか理解できているかどうかが問題になりそう。
Q「s/[A-z]//g としたら[や^まで消えてしまいました。この正規表現は間違っていますか？」
A「正規表現もパターンマッチの結果も正しいです。ただ、あなたの求めている正規表現ではないでしょう。」
>向こうでも思ってたんだけど中途半端な正規化だから文字コードに
>依存するって思ってたんですが。
エディタは文字コードを勝手に認識してくれるからユーザーが考える必要はないけど、
文字クラスで[a-z]とかやる場合はどうしたって文字というより文字コードを扱うってことになる。
ただ、普通は上に書いたように[A-z]なんてやる奴はいないだろうから、
実質的には文字コードに依存していないかのように扱えるというだけだと思う。
ところで [a-z] として、これがどういう意味であって欲しいんでしょうか？

53 ：
[a-z]
"a"の文字コードから"z"の文字コードまでの文字コードの文字のことかな

54 ：
>51,52
すまん質問の仕方が悪かった。
上で正規表現の仕様が悪いみたいな雰囲気があったから疑問に
おもったんですが、たとえば「grepの仕様は正しいが、awkの仕様は
間違ってる」みたいな正規表現の仕様上の問題で間違いというのが
あるのかという疑問でした。
>[a-z]
その正規表現で規定されているaのキャラクタからzのキャラクタまで。
文字コードでも文字でもないはずだ。
たとえばProxomitronなら[a-zA-Z]と同じようになるようにキャラクタの
並びが規定されている。

55 ：
正規表現が実装されているなら
実装の細部がgrepとawkでは異なるというだけで
正しいも正しくないもないんだってば。

56 ：
全然議論が噛み合ってないなぁ。
「正規表現」(オライリー)の一冊くらい読んでから出直してきて欲しいな。
でなきゃこんなの不毛だよ。

57 ：
>>51
> それから正規化しているから正規表現というわけじゃないです。ある有限オートマトン
> が受理する特定の言語(記号列)を正規言語と呼び、その受理される言語の全ての集合を
> 正規集合と呼び、その集合を表現する方法を正規表現と呼んでいるのです。文字コード
これが理解できません。

58 ：
>>[a-z]
>その正規表現で規定されているaのキャラクタからzのキャラクタまで。
>文字コードでも文字でもないはずだ。
「aのキャラクタからzのキャラクタまで」ってのが文字コードそのものだと思うぞ。
「文字コードでも文字でもない」ってのが [:alpha:] なんじゃないの。
[a-z] だけ特殊な意味合いを持って欲しい、なんてことではないでしょう。
>たとえばProxomitronなら[a-zA-Z]と同じようになるようにキャラクタの
>並びが規定されている。
絶対そんな規定されてないよ。
Proxomitronで規定されているのは「大文字小文字を同一視する」ってこと。
だから [a-Z] なんて書いても [a-z] と同等の文字コードの並びとして扱われる。
これは単にProxomitronの性質上、扱う文字列の大文字小文字を区別するより
区別しない方が圧倒的に多いということから独自に規定されたものだろ。
「文字でも文字コードでもない」として扱うためには、エディタ作者なりが
新たな文字の統一コードを規定していろんな文字コードに対応した変換表でも作り、
ユーザーは既存の文字コードの代わりに作者の規定したコードを理解して使うってことになるんじゃないか？

59 ：
形式言語の教科書くらい読んでから来い

60 ：
>55
ですよね、最近そういった話を耳にするんで敏感になってました。
きっぱり否定してくださって助かります。
51氏も分かりやすい説明ありがとうございます。
>58
それが正規表現関係の資料をいくら読んでも必ず「aのキャラクタから
zのキャラクタまで」だったと記憶してます。
逆にコードで表記されてる資料がありましたら、ご提示願えませんか？
# 日本語の資料だとよく文字コードの話もみます。
>「大文字小文字を同一視する」
の実装はどうされているのでしょうか？
まさか一度さきに別に小文字を大文字に書き直して正規表現を当ては
めてから元の小文字に戻すという芸当はされてないと思います。
私は憶測ですが正規表現上で小文字と大文字を同一文字だと規定し
ているように思えます。
# 文字コードレベルだと高とはしご高の関係に近いと思います。

>59
お勧めのありますか？

61 ：
>>6 くらい通読して出直してから議論してくれよ。でなきゃこんなやりとり無駄だよ。
いや、煽りじゃなくてマジでさ。

62 ：
>>6の本って目次だけ見ると各ツールの「実装」について述べてる
みたいだけど、正しい「定義」については載ってるの?

63 ：
規格としては POSIX 1003.2 があるけど、
正しい定義なんてものはないと思う。

64 ：
>>62
『正しい「定義」』なんてないんだからおまいらの議論は不毛だって言ってんの。
中途半端な知識と思い込みだけの虚しい空論だよ。

65 ：
>>62
たしかに目次には各ツールの実装についての記述が目立つ。
だが、この本のキモは4章と5章だ。
君が正規表現をある程度自在に扱えるのであれば、
この二つの章を読むだけでも価値はある。
とりあえず話はそれからだ、と思うぞ。

66 ：
文字クラス中の - が文字コードでの連続を表すか文字としての連続を表すかは実装依存です、
で終了。

67 ：
>>63-65
いや、>>66の言うように実装依存だと思ってたから、
正しい「定義」が載ってるなら、読んどこうかと思ったんですが。
>>61の発言を(それまでの流れと併せて)読むと、さも載ってそうなんですが、
目次見たら(-_-)ぁゃιぃ…だったので。

68 ：
http://www.opengroup.org/onlinepubs/007904975/basedefs/xbd_chap09.html
規格が「正しい」かどうかは別として…

69 ：
正規表現の定義ねぇ。どうもどこかの団体がきっちりまとめた規格
のような「定義」を期待してるようだが、このあたりのハナシは計算
機科学色が強いから定義など教科書の数だけある、と言ってみるﾃｽﾂ。
本質はみな同じのはずだけどナ。
しかも見慣れぬ数学記号飛び交う抽象的な議論になるから、
オライリー本で充足しているヤシにはカルチャーショックだろう。
大学の図書館でもけ。

70 ：
>>67
> >>61の発言を(それまでの流れと併せて)読むと、さも載ってそうなんですが、
> 目次見たら(-_-)ぁゃιぃ…だったので。
漏れの発言を勝手な解釈すんなよ。
正しい「定義」なんて載ってるわけないだろ。正しい「定義」なんてないんだから。

71 ：
>>67
ていうかあれだ、「定義」の話じゃなくて「規格」の話をしたいのか？
「定義」の話なら、>>69 の言うように、
計算機科学（の世界だと「正則表現」の方が通りが良いか？）の本でも
紐解いて読んでみるのが良いと思う。
そうでなくて、単に、
文字列バターンマッチに使われる「正規表現」の正しい「規格」の話、
ってことなら、そんなものは無い。
強いて言えば、>>68 くらい。

72 ：
>>67
「定義」=「決め」でしょ。
その場その場で都合のいいように「定義」するわけだから
「正しい『定義』」なんてのはあるわけがない。

73 ：
>>67
じゃ、まずは「正しい」の定義から始めようか。

74 ：
というわけで、このスレは、「ホップクロフト&ウルマンを輪読するスレ」になりますた。

75 ：
規格として[a-z]の解釈について正しい定義はあるのか?
っていう議論中に、「ｺﾚ読め」と言われたら載ってるように
見えても仕方ないと思うんですがねぇ。
「>>6に載ってないから無い」、とは言えんでしょ。
何の為に読めと言ったのか聞いてよろしい?>>61

76 ：
POSIX 1003.2 に厳密に従っていればこれにある通り。
http://www.linux.or.jp/JM/html/LDP_man-pages/man7/regex.7.html
が、世にある実装は大抵そうでない。

77 ：
>>76
見た感じ、EBDICでもロケールが英語なら[a-z]は
英小文字のセットとして評価されるべきみたいですな。

78 ：
>>75
全く違う。
そもそも君の話は正しい定義がこの世に存在する事を
前提としている。しかし実際はそのようなものは
ないわけだ。（「正しい」の意味が私の考えている
ものと違うならわからないが）
そのことを理解するために（というか議論のための
基礎知識を得るために）読んでおくべきと 61 は
言いたかったのだと勝手に解釈してみる。
厳密な定義という意味で正しいと言っているなら
計算機科学の教科書をひもといてみるといいかもなあ。

79 ：
>75
そんなマヌケな話を避けられるようになるよ、
とそういう意味で勧めてくだすったんだろう。

80 ：
>>78
>そもそも君の話は正しい定義がこの世に存在する事を前提としている。
ｼﾃﾈｰﾖ。
つーか著名ﾂｰﾙの実装に関する本を読んだ所で、
[a-z]の解釈は〜という議論に決着つくのですか。
1-60までのｽﾚの流れと、>>61の勧めた>>6の内容を
良く見てから出直して下さい。>>78,79

81 ：
取り合えず読んでみる、と言う選択肢は
意図的に無視されているのだろうか…

82 ：
もともと [a-z] なんていう表記は、素な正規表現/正則言語にはない。
でもそれじゃ面倒だから - で繋いだ2つの文字の間の文字群を略記する方法が、
及び実装としては単に文字コードを繋ぐ方法がデファクトスタンダードになった。
それを勘違いしたバカが [a-z] は論理的なアルファベットを意味すべきだとか言い始めて
[[:alpha:]] や \l やら \a が導入されるようになったり、変な挙動をする実装もでてきたかもしれん。
でここでPOSIXなんて有名無実なものが定義されたわけだ。
なのにさらにバカが [a-z] の正しい解釈、定義を教えろとかいう。
やれやれだ。

83 ：
ここは62=75の脳内正規表現を研究するスレになりますた。
# 素直に勉強してから出直せばいいのに。。。

84 ：
>>82
やれやれとはこっちが言いたい。
[a-z]の解釈が文字コード依存なのは承知済みだっつーの。
>>61のタイミングで論議を不毛と評しつつ、正規表現の本読めと
言われたら、規格か何かが載ってるとしか思えんでしょうが。
著名ﾂｰﾙの実装見たところで、議論の不毛を悟れますか?

85 ：
少なくとも読めば実装により異なることは察することができたかもね

86 ：
規格自体を読みたいなら68にリンクがあるし、なんでそう粘着してるんだろうか

87 ：
なぜに著名ツールの実装しか載っていないと決めつけ
勝手な解釈で話を進めるのだろう？
とにかくおかしな前提と曲解が多い上に粘着だ。

88 ：
もう放置しようよ……。

89 ：
非放置国家 2ch

90 ：
>>87
決め付けてませんが。
>>62で実装以外の内容(具体的に規格など)は
載って無いかと聞いてるんだし。
おかしな前提・曲解・粘着は認めますがね。
で、偉そうに読めとか言った>>61は何処ったの?

91 ：
>>90
> で、偉そうに読めとか言った>>61は何処ったの?
読んだら出てくるんじゃねーの?

92 ：
とっくの昔に読んでいるんだが…
(立ち読みでざっとだけど)

93 ：
形式言語系の本は読んだのかYO!

94 ：
>>92
そんなの読んだうちに入らん。

95 ：
理屈が通用すると勘違いせず、粘着は放置しましょう

96 ：
腹が減ってるもんで
こんなのでも食いついてしまうんです。

97 ：
>>90
君が何を知りたいのか、
おじさんわかんなくなっちゃったよ。
ここらでひとまず
疑問点を整理して箇条書きにしてみないか?

98 ：
技術系の本を立ち読みしただけで読んだ気になれる人には
何を言っても無駄ではなかろうか。

99 ：
（＾＾）

100read 1read
1read 100read
TOP カテ一覧 スレ一覧 削除依頼 ▲
・　次のスレ
小中高などの教育機関へUNIXの導入を
ホストが落ちた時の言い訳を考えよう【Var.2】
◆◆詰めスクリプト◆◆
*BSD/ThinkPad