強調表示定義ファイルの一行長さについて	No.08814
たまがわ さん　03/05/14 11:21
いつもお世話になっています。 　強調表示定義ファイルをエディタで編集し、鶴亀メールの設定から読み込ませたの ですが、一見正しく読み込めたように見えつつも、ＯＫボタンを押したらエラー表示 が出て、そのエラー表示の内容が文字化けして読めないという状況が見られました。 その後、鶴亀を起動したり、メールエディタを起動したりするたびに、同じ文字化け エラーが出、ときにはアプリケーションエラーで落ちるようになりました。（強調表 示をやめれば直ります） 　エラー自体は、調べてみたところ、どうやら定義ファイルの一行が長すぎたため （正規表現で書いてあります）、鶴亀メールに取り込まれる際に半角２００字ぐらい のところでちぎられた結果、解釈不能に陥ったということのようです。 　試しに、秀丸エディタに同じ定義ファイルを設定しようとしてみたところ、「ファ イルの形式が正しくない」というエラー表示とともに読み込みが阻止されたので、同 じような処理を鶴亀にも入れれば安全かと思います。（文字数制限を少し緩くして欲 しいという気もしてますが、秀丸との互換上難しいかもしれませんね） 　あと、これは要望ですが、鶴亀メールの設定で、強調表示の設定画面を開くたびに、 設定項目の表示順序が入れ替わってしまい、わかりにくいです。できれば、強調１、 強調２というように、ソートして表示してくれるとありがたいですが、ソートが無理 でも、表示順序は一定の方が望ましいように思います。 （windows xp pro sp1, TuruKame 2.78）

[ △ ]

RE:08814 強調表示定義ファイルの一行長さ	No.08815
秀まるお さん　03/05/14 12:40
まいどどうも。強調表示ファイルの読み込み処理は、たしかに秀丸と鶴亀とで 全然別でして、鶴亀側はほとんどチェックのような処理は入ってませんでした。 　いろいろ事情があって秀丸と共通には出来ませんが、とにかく修正させていた だきます。 > 　あと、これは要望ですが、鶴亀メールの設定で、強調表示の設定画面を開くたび > に、 > 設定項目の表示順序が入れ替わってしまい、わかりにくいです。 　特に並べ替えしてるつもりは無いのでバグの可能性が高いです。もしかして並 べ替えしてるようなら修正させていただきます。

[ △ ]

RE:08815 強調表示定義ファイルの一行長さ	No.08816
きいろいまふらあ さん　03/05/14 15:01
横からすみません。 >> 　あと、これは要望ですが、鶴亀メールの設定で、強調表示の設定画面を開くたび >> に、 >> 設定項目の表示順序が入れ替わってしまい、わかりにくいです。 > >　特に並べ替えしてるつもりは無いのでバグの可能性が高いです。もしかして並 >べ替えしてるようなら修正させていただきます。 開くたびに昇順降順が逆になっているようです。 ＃記憶する順番と読み出す順番が逆なのかも。 ちなみに、秀丸の場合は「文字列」の項目でリアルタイムに（新規項目を追加し た時点で）ソート？されているようですね。鶴亀の場合は、どんどん先頭に追加 されていくようです。 処理の優先順位は強調の種類で決まっていくはずですから、ここはもっぱら視認 性の問題だけだと思いますが……ちょっと気になりました。 自分は強調表示をそれほど多用していない（鶴亀では現状２項目のみ）のですが、 たくさん登録している人は「文字列」や「表示方法」でソートしたいことがある かもしれませんね（要望してるわけではありません）。 項目を選択して[Delete]キーで削除されるのは仕様ですよね（念のため）。

[ △ ]

RE:08816 強調表示定義ファイルの一行長さ	No.08817
秀まるお さん　03/05/14 16:46
> 開くたびに昇順降順が逆になっているようです。 　ソースコードを調べたら、つまり、秀丸ではリストビューのウィンドウスタイ ルが「ソート」になっていて、鶴亀では「ソート無し」になっていて、C言語の ソースコード上で同じ処理を動かしたら、たまたま逆順に並んでしまうようでし た。 　なので、秀丸と同じ方式に修正させていただきます。 > 項目を選択して[Delete]キーで削除されるのは仕様ですよね（念のため）。 　問い合わせメッセージも無くさっくり削除されるようですが、秀丸も同じなの で、仕様ってことにします。

[ △ ]

RE:08817 強調表示定義ファイルの一行長さ	No.08831
たまがわ さん　03/05/19 16:52
秀まるおさん、こんにちは。 　強調表示設定の順番の件は、「入れ替わり」がなくなったことを確認しまし た（鶴亀2.81で確認）。ありがとうございました。 　一方、一行が長い定義ファイルを読み込ませると、文字化けエラーが出る件 は引き続き発生します。レアケースということで、現状維持としたのかなとも 思いますが、一応ご報告しておきます。

[ △ ]

RE:08831 強調表示定義ファイルの一行長さ	No.08832
秀まるお さん　03/05/19 17:04
> 　一方、一行が長い定義ファイルを読み込ませると、文字化けエラーが出る件 > は引き続き発生します。 　一応、1行が長い場合は、「強調表示ファイルが壊れているようです。読み込 みを中止します」と出るはずでして、今テストした限りもそう出たんですけど…。 　もしかして、以前間違って読み込んだ状態を再現させて、それで死ぬというこ となら、それは仕方がないです。読み込み処理しか直してませんので。例えば以 前おかしくなった時のレジストリをバックアップしてあって、それを復元してお かしいってことなら仕方がないです。

[ △ ]

RE:08832 強調表示定義ファイルの一行長さ	No.08833
たまがわ さん　03/05/19 20:07
秀まるおさん、こんばんは。 > > 　一方、一行が長い定義ファイルを読み込ませると、文字化けエラーが出る件 > > は引き続き発生します。 > > 　一応、1行が長い場合は、「強調表示ファイルが壊れているようです。読み込 > みを中止します」と出るはずでして、今テストした限りもそう出たんですけど…。 > > 　もしかして、以前間違って読み込んだ状態を再現させて、それで死ぬというこ > となら、それは仕方がないです。読み込み処理しか直してませんので。例えば以 > 前おかしくなった時のレジストリをバックアップしてあって、それを復元してお > かしいってことなら仕方がないです。 　お手数をおかけして申し訳ありません。 　設定しようとしているのは、以下のような強調ファイルでして、「pochi> tama> m ike>」みたいな形にも対応するように作った引用行色分け設定です。 　以前より、基本機能の着色を含めて３段階で常用していたんですが、今回５段階に するため以下のようにしたところ、最後の一番長い行が読み込み時に途中でちぎられ てしまうようです（設定画面で読み込み結果を確認した限りですので、違う理由かも しれません）。 　他のパソコンで試しても残念ながら状況は変わりませんでした。 　ということで、現在はその行を消して４段階で使用しています。 81,^([0-9A-Za-zぁ-んァ-ヶ亜-�K−ー]*| *)[>|＞》｜] *[0-9A-Za-zぁ-んァ-ヶ亜- �K−ー]*[>|＞》｜] *[0-9A-Za-zぁ-んァ-ヶ亜-�K−ー]*[>|＞》｜].* 17,^([0-9A-Za-zぁ-んァ-ヶ亜-�K−ー]*| *)[>|＞》｜] *[0-9A-Za-zぁ-んァ-ヶ亜- �K−ー]*[>|＞》｜].* 145,^([0-9A-Za-zぁ-んァ-ヶ亜-�K−ー]*| *)[>|＞》｜] *[0-9A-Za-zぁ-んァ-ヶ亜- �K−ー]*[>|＞》｜] *[0-9A-Za-zぁ-んァ-ヶ亜-�K−ー]*[>|＞》｜] *[0-9A-Za-zぁ- んァ-ヶ亜-�K−ー]*[>|＞》｜].* 209,^([0-9A-Za-zぁ-んァ-ヶ亜-�K−ー]*| *)[>|＞》｜] *[0-9A-Za-zぁ-んァ-ヶ亜- �K−ー]*[>|＞》｜] *[0-9A-Za-zぁ-んァ-ヶ亜-�K−ー]*[>|＞》｜] *[0-9A-Za-zぁ- んァ-ヶ亜-�K−ー]*[>|＞》｜] *[0-9A-Za-zぁ-んァ-ヶ亜-�K−ー]*[>|＞》｜].* (windows xp pro sp1, TuruKame 2.81)

[ △ ]

RE:08833 強調表示定義ファイルの一行長さ	No.08834
アルビレオ さん　03/05/19 21:08
アルビレオです。 >81,^([0-9A-Za-zぁ-んァ-ヶ亜-�K−ー]*| *)[>|＞》｜] *[0-9A-Za-zぁ-んァ-ヶ亜- >�K−ー]*[>|＞》｜] *[0-9A-Za-zぁ-んァ-ヶ亜-�K−ー]*[>|＞》｜].* >17,^([0-9A-Za-zぁ-んァ-ヶ亜-�K−ー]*| *)[>|＞》｜] *[0-9A-Za-zぁ-んァ-ヶ亜- >�K−ー]*[>|＞》｜].* >145,^([0-9A-Za-zぁ-んァ-ヶ亜-�K−ー]*| *)[>|＞》｜] *[0-9A-Za-zぁ-んァ-ヶ亜- >�K−ー]*[>|＞》｜] *[0-9A-Za-zぁ-んァ-ヶ亜-�K−ー]*[>|＞》｜] *[0-9A-Za-zぁ- >んァ-ヶ亜-�K−ー]*[>|＞》｜].* >209,^([0-9A-Za-zぁ-んァ-ヶ亜-�K−ー]*| *)[>|＞》｜] *[0-9A-Za-zぁ-んァ-ヶ亜- >�K−ー]*[>|＞》｜] *[0-9A-Za-zぁ-んァ-ヶ亜-�K−ー]*[>|＞》｜] *[0-9A-Za-zぁ- >んァ-ヶ亜-�K−ー]*[>|＞》｜] *[0-9A-Za-zぁ-んァ-ヶ亜-�K−ー]*[>|＞》｜].* 本題とは外れますが [0-9A-Za-zぁ-んァ-ヶ亜-�K−ー] の部分は確かにこの記述が正しいわけですが、 [0-9A-zぁ-ヶ亜-�K−ー] という書き方なら実用上それほどは問題はないし、最後の行も185桁となるので 現状での回避策としては有効だと思うのですがいかがでしょうか？

[ △ ]

RE:08834 強調表示定義ファイルの一行長さ	No.08835
たまがわ さん　03/05/19 21:36
アルビレオさん、こんばんは。まいど、ありがとうございます。 >本題とは外れますが >[0-9A-Za-zぁ-んァ-ヶ亜-�K−ー] >の部分は確かにこの記述が正しいわけですが、 >[0-9A-zぁ-ヶ亜-�K−ー] >という書き方なら実用上それほどは問題はないし、最後の行も185桁となるので >現状での回避策としては有効だと思うのですがいかがでしょうか？ 　縮める手はいろいろ考えられますし、ご提案はなかなか結構なアイデアだと思いま す。 　冗長だと感じられるかもしれませんが、ここでは、行が長いと文字化けエラーがで たり落ちたりしますという話の具体例を示すことが目的ですので、そのようなトラブ ルにいたる一つの例示と見てください。どの程度長いとおかしくなるのか（あるいは どういう処理を含ませるとおかしくなるのか）といった視点でご検証いただければあ りがたいです。

[ △ ]

RE:08835 強調表示定義ファイルの一行長さ	No.08836
秀まるお さん　03/05/20 08:31
これは、いわゆるJRE32.DLLのバグによって鶴亀メールおよび秀丸エディタの 動作がおかしくなる症状だと思います。 　具体的に以前報告があったのは以下のような強調表示定義です。この場合、1 行の長さが非常に長い行を作成しただけで鶴亀メールや秀丸エディタがおかしく なります。 --> 動作不安定になった強調定義の内容 <----------------------------- 49,「+[^「|『|（|【|＜|≪|≫|＞|】|）|』|」]* 49,[^「|『|（|【|＜|≪|≫|＞|】|）|』|」]*」+ 49,『+[^「|『|（|【|＜|≪|≫|＞|】|）|』|」]* 49,[^「|『|（|【|＜|≪|≫|＞|】|）|』|」]*』+ 113,（+[^「|『|（|【|＜|≪|≫|＞|】|）|』|」]* 113,[^「|『|（|【|＜|≪|≫|＞|】|）|』|」]*）+ 241,＜+[^「|『|（|【|＜|≪|≫|＞|】|）|』|」]* 241,[^「|『|（|【|＜|≪|≫|＞|】|）|』|」]*＞+ 241,≪+[^「|『|（|【|＜|≪|≫|＞|】|）|』|」]* 241,[「|『|（|【|＜|≪|≫|＞|】|）|』|」]*≫+ 177,【+[^「|『|（|【|＜|≪|≫|＞|】|）|』|」]* 177,[^「|『|（|【|＜|≪|≫|＞|】|）|』|」]*】+ ----------------------------------------------------------------- 　実は今僕が秀丸エディタの過去のバグ修正もやっているんですが、このバグに ついてはJRE32.DLL側がヒープを壊してしまうために、どうにも対応できないで います。JRE32.DLLの作者の山田さんとも連絡が取れない状況だそうで、しいて 対応するならJRE32.DLL相当の物をサイトー企画で作り直すしか無いです。 　ということで、複雑な正規表現を強調表示に使うのは現状あきらめてもらうし か無いです。 ----------- 　誰か適当な正規表現ソースコードの所在が分かれば教えてください。

[ △ ]

RE:08836 強調表示定義ファイルの一行長さ	No.08837
秀まるお さん　03/05/20 08:38
ちなみに「*」が非常に長い行にヒットするとどうもダメらしいので、せめて、 正規表現最終部分にある「*」だけ鶴亀メール／秀丸側で例外的に処理させる手 もあるにはありますが…。

[ △ ]

RE:08837 強調表示定義ファイルの一行長さ	No.08838
秀まるお さん　03/05/20 08:58
っとコメントした矢先なんですが、「*」全般を秀丸側で処理するのは困難で した。「.*」ならなんとか対応できますが、それだけではJRE32.DLLの誤動作を 防ぐことは出来なさそうです。

[ △ ]

RE:08836 強調表示定義ファイルの一行長さ	No.08839
でるもんた さん　03/05/20 09:12
でるもんたです。 > 誰か適当な正規表現ソースコードの所在が分かれば教えてください。 1. http://www.boost.org/ から regex で検索してください。 C++ 専用ですが、DLL 化して DLL を C アプリから呼び出すのは不可能では なさそう。wchar_t を受け付けますが生のシフト JIS は絶望的。 ライセンスは BSD ライセンス風。 2. http://www.pcre.org/ Perl 互換として名高いライブラリ。UTF-8 を受け付けますので、頑張って手を 入れればシフト JIS も通るようになるかも。 3. http://www.gnu.org ここに regex、Rx というライブラリがありますが、いずれも GPL です。 Lesser GPL（旧 Library GPL）ではないので、使用すると秀丸・鶴亀のソース コードの全部公開を求められる可能性があり、お勧めできません。 こんなところでどうでしょう。

[ △ ]

RE:08839 強調表示定義ファイルの一行長さ	No.08840
でるもんた さん　03/05/20 09:22
でるもんたです。 私の要望としては、UNICODE を通さずにシフト JIS での検索にも対応してほしいで す。「JIS第二水準は強調表示」とか、シフト JIS で複数のコード位置が割り当てら れているため一旦 UNICODE にしてしまうと区別できなくなる文字（0x87NN の一部と、 0xED40-EDFC、0xFA50-FA4C）の検索もしたいので…。

[ △ ]

RE:08837 強調表示定義ファイルの一行長さ	No.08841
たまがわ さん　03/05/20 09:53
秀まるおさん、こんにちは。 > 　実は今僕が秀丸エディタの過去のバグ修正もやっているんですが、このバグに > ついてはJRE32.DLL側がヒープを壊してしまうために、どうにも対応できないで > います。JRE32.DLLの作者の山田さんとも連絡が取れない状況だそうで、しいて > 対応するならJRE32.DLL相当の物をサイトー企画で作り直すしか無いです。 > > 　ということで、複雑な正規表現を強調表示に使うのは現状あきらめてもらうし > か無いです。 　JRE32.DLL側の問題でしたか……。分かりました。調査いただき、ありがと うございました。

[ △ ]

RE:08840 強調表示定義ファイルの一行長さ	No.08842
秀まるお さん　03/05/20 10:14
情報ありがとうございます。やるとしたら当然ShiftJISで検索させるつもりで す。 　どっちにしても大仕事になるには違いないので、ソースコードを拾いつつ勉強 しようかなぁと思います。

[ △ ]

RE:08841 強調表示定義ファイルの一行長さ	No.08843
たまがわ さん　03/05/20 10:39
あの…、念のためですが、「途中で切られてしまうぐらい長い行を持つ定義 ファイルが、エラーメッセージを出さずに読み込めてしまう」という状況は、 私の環境で引き続き見られます。 （あの定義ファイルを読み込ませ、設定の「文字列」を確認すると途中までし   か表示されないので、読み込めつつ、切られているのかなと。また、これは   鶴亀の保証外ですが、さっそくJRE32.DLLを他のものに置き換えるDLLを導入   してあの定義ファイルを試したところ、「[]の対応がとれない」というエ   ラーが出たので、内部的にも途中で切られているのかな、と想像しました。   あくまで想像ですけど。）

[ △ ]

RE:08843 強調表示定義ファイルの一行長さ	No.08847
秀まるお さん　03/05/20 16:58
毎度お手数かけてすみません。強調表示の1行の制限を勘違いしてました。秀 丸では199文字で切ってるようです。 　てっきり255文字かと思って、それ以上の場合にエラーを出してました。

[ △ ]

---