スズカワエディタ　Suzukawa Editor

お知らせ

1. 2022年04月13日15:00 追加
   スズカワエディタの難所は現在世界で私Suzuki一人だけが乗り越えることができた難問である。世界中の大学、企業、研究所、私Suzuki以外の個人が解決に取り組んでも誰一人成功したことがない。おこがましいことであるが、「難問」ということばも大げさなことではあるまい。

   「フェルマーの定理」の解決には330年の年月を要した。ここで敢えて宣言する。スズカワエディタの難所は500年の年月をかけても解決できないだろう。私Suzuki自身は難問中の難問であると信じている。ただし、残念ながら解決したからと言って名誉にも金にも有名にもならないし、何かの賞をもらえるわけでもない。

2. 2022年01月27日08:30 追加
   スズカワエディタのパクり
   


3. 2021年05月26日13:00 追加
   スズカワエディタの難所
   


4. 2019年04月09日17:30 更新
   巨大テキストエディター世界Top3


5. 2018年06月17日14:00 更新
   2018年06月12日17:50 追加
   テキストエディタ：外部ファイルの読み込みと保存


6. 2023年10月03日13:00 更新
   2016年08月17日09:00 追加
   

   2019-04-03 12:00
   スズカワエディタ最新版：ver05.00.38
   

   2021-04-05 04:00
   スズカワエディタ改良版：ver05.01.02
   

   2023-10-03 13;00
   2019-10-28 追加
   試用版ライセンスキーファイル

7. 2018年06月17日14:00 更新
   2018年06月12日17:50 追加
   

   テキストエディタ：外部ファイルの読み込みと保存

   2018年06月17日14:00 更新
   

   • SublimeTextを追加した。表に示す通り、ファイルサイズ225GB以上（最大サイズは現在未確認）、行数18億行以上（最大21億行）テキストファイルを読み込み、保存、テキスト入力、改行、スクロールできることを確認した。
   • 010Editorの保存時間を56分から25分に訂正した。随分の違いであるが、今となっては原因は不明である。56分の保存実行時はこんなものかと結果を訝しく感じなかった。010Editorのときだけ、保存HDDの残り容量が少なかったのが原因かもしれない。

   テスト条件

   テキストファイル

   ファイルサイズ：約225GB
   行数：約18億行

   パソコンメモリ

   96GB
   2018年06月17日14:00 追加
   これまで種々のテストで使用したパソコンのメモリは最大16GBであった。今後のテストではメモリを膨大に使うテキストエディタについて、今まで知らなかった特徴を知ることができるだろうと思う。

   本テストのテキストエディタ

   テストでは200GB以上を読み込むことができるテキストエディタについて調べる。それは下表の通り5本だけである。もし、他にもあれば、ご教示願います。ちなみに200GB以上というファイルサイズに特段の意味はありません。

   スズカワエディタの特殊性

   スズカワエディタは外部ファイルを開くとき、読み込みと同時に加工したワークファイルを保存する必要がある。本テストではワークファイルの保存のためにSSD（360GB）を使用している。

   下表の順番

   取り扱い可能なテキストファイルのサイズと行数の大きい順番
   2018年06月17日14:00 追加
   ファイルサイズ225GB以上のSublimeTextと最大ファイルサイズ248GBのEmEditorの順番に違和感を持つ向きもあると思うが、これは次の理由による。SublimeTextは任意の位置での文字入力がスムーズにできるし、Return Keyを押すと即座に改行結果が表れる。鉛直スクロールタブのドラッグによるページスクロールも滑らかにできる。ところが、EmEditorは文字入力はスムーズにできるが、Return Keyによる改行結果が表れるのに約5秒間かかる。スクロールも滑らかとは言い難い。基本動作である改行が即座にできないのは、ここに掲げるテキストエディタの中でEmEditorただ一つである。性能云々はきちんと基本動作ができることが前提である。基本動作をなおざりにして性能もへったくれもない。

   テキストエディタ	性能	読み込み時間	保存時間	使用メモリ	備　考
   スズカワエディタ （32bit）	5TB以上 2兆5000億行以上	71分	43分	約25MB	備考A
   010Editor （64bit）	数TB 数千億行	22分	25分	約180MB	備考B
   PilotEdit （64bit）	400GB 400億行	60分	95分	約7.5GB	備考C
   SublimeText （64bit）	225GB以上 21億行	100分	30分	約28GB	備考D
   EmEditor （64bit）	248GB 21億行	21分	90分	約42GB	備考E

   結果

   読み込み時間

   一番速いのはEmEditor、一番遅いのはSublimeText

   保存時間

   一番速いのは010Editor、一番遅いのはPilotEdit

   使用メモリ

   一番大きく使用するのはEmEditor、一番少ないのはスズカワエディタ

   
   
8. 2017年02月01日12:40 追加
   折り返し（WordWrap）ができないテキストエディタ
9. 2016年12月30日12:30 更新
   2016年12月22日14:00 追加
   内部ファイルに対する複数行テキストの検索・置換：追加
10. 2016年12月20日09:45 更新
    2016年12月15日21:15 追加
    巨大テキストエディタ三つと似て非なるもの一つ


11. 2017年02月01日12:40 追加
    

    折り返し（WordWrap）ができないテキストエディタ

    EmEditorはファイルサイズが約400MBになると折り返し（WordWrap）ができなくなる。約400MB以下のテキストファイルを開くと折り返しメニューは有効であるが、それ以上のファイルサイズのテキストファイルを開くと折り返しメニューが無効表示になり、折り返しを実行できない。折り返しを実行するかしないかの判断基準は不明である。ファイルサイズだけで判断するのか、行数も考慮するのか、あるいは文字数も計算に入れているのか、わからない。

    宣伝文句では、ファイルサイズ248GB、行数21億行までのテキストファイルは扱うことができると謳っているのであるが、それにしては400MBは小さすぎる。1GB以上、1000万行以上のテキストファイルを読み込み編集できる世界のテキストエディタの中で、400MB、300万行程度のテキストファイルを折り返しできないのは、EmEditorだけである。

    なぜEmEditorは、400MB程度のテキストファイルの折り返しをできなくするのか？

    下記の手順で調べてみる。

    1. 約300MBのテキストファイルをEmEditorで開いてみる。
       このとき、折り返しメニューは有効表示。
    2. 桁数50文字で折り返しを実行する。これをAテキストファイルとする。
    3. 100MB程度の任意のテキストをコピーする。
    4. これをAテキストファイルの先頭付近（どこでもよい）でペーストする。
    5. 4の操作を繰り返す。
    6. タスクマネージャーでみると、EmEditorの使用メモリが12GB位になり、それ以上には増えない。
    7. Aテキストファイルが数GBになるまで、4の操作を繰り返す。
    8. Aテキストファイルの先頭付近でキーボードから直接、半角文字（数字、アルファベット）を入力してみる。
       このキーボード入力がサクサクできない。入力した文字が直ちに表示されない。文字を入力してから表示されるまでに時間がかかる。これがまともであれば、入力した文字は直ちに表示されるのである。

    どうやら、ファイルサイズが数GB程度になると、折り返しを実行したテキストファイルでキーボード入力がチンタラしてスムーズにできないというのが、折り返しをできなくする理由ではないかと思われる。この他に折り返しで行数が大きくなり使用メモリが極端に増加する。保存を実行してみると、途中で止まってしまう症状も見られる。他にも問題があるのかもしれない。いずれにしても、EmEditorなりに諸般の事情を慮って400MB程度で折り返しをできなくしているということだろうと思う。

    EmEditorはファイルサイズ248GB、行数21億行まで読み込み編集できるという謳い文句であるが、これだけの巨大テキストファイルをまともに取り扱うに相応しい能力、技量、志を備えていないようである。

    
    
12. 2016年12月30日12:30 更新
    2016年12月22日14:00 追加
    

    内部ファイルに対する複数行テキストの検索・置換：追加

    内部ファイルに対する複数行テキストの検索・置換に追加。検索条件は同じ。

    EmEditorと他のテキストエディタを比較されたい。

    表1 - 内部ファイルに対する複数行テキストの検索・置換にかかる時間
    

    テキスト エディタ	① 1.2GB 920万行 13,457個	② 2.4GB 1840万行 26,914個	③ 3.6GB 2760万行 40,371個	④ 4.8GB 3680万行 53,828個	⑤ 6.0GB 4600万行 67,285個	⑥ 12.0GB 9200万行 134,570個	⑦ 24.0GB 18400万行 269,140個	備　考
    EmEditor 64bit （ver16.3.1）	6分02秒 5分30秒 5分05秒	22分48秒 21分13秒 19分20秒	52分35秒 47分03秒 42分47秒	90分08秒 81分38秒 75分24秒	141分46秒 129分02秒 117分15秒	559分35秒 実行しない 途中終了	24時間で中断 約50時間 （約3000分）	備考A1 備考A
    スズカワ エディタ 32bit	19秒 14秒 12秒	36秒 26秒 25秒	55秒 38秒 38秒	1分16秒 52秒 48秒	1分31秒 1分14秒 1分06秒	5分38秒 4分35秒 4分13秒	12分53秒	備考B1 備考B
    010Editor 64bit	10秒	23秒	43秒	1分15秒	2分05秒	7分20秒	39分35秒	備考C
    PilotEdit 64bit	45秒 (20秒)	1分42秒 (49秒)	2分13秒 (58秒)	3分00秒 (1分20秒)	3分41秒 (1分35秒)	7分51秒 (3分10秒)	20分46秒 (8分40秒)	備考D
    SublimeText 64bit	32秒	1分04秒	1分35秒	2分08秒	2分37秒	5分10秒	14分11秒	備考E
    UltraEdit 64bit	15秒	28秒	42秒	58秒	1分12秒	途中終了 メモリ不足	-	備考F

    1. 備考A1：EmEditor
       上段の太字が今回追加したもの。前回よりさらに遅くなっている。今回もUndoはできない。リストなし。
       ⑥は前回、前々回共に途中で終了したが、今回は最後まで実行。実に記録的な時間（9時間19分）である。このときの使用メモリ2GB、CPU使用率60％前後。
       ⑦は⑥のファイルを二つ繋げたもの。進捗率41％で24時間経過。ここで強制中断。最後まで実行すると約50時間（3000分）かかりそうである。このときの使用メモリ約4GB、CPU使用率60％前後。
    2. 備考B1：スズカワエディタ
       上段の太字が今回追加したもの。Undoができる。検索・置換リスト（ダブルリスト）を表示。
    
    
13. 2016年12月20日09:45 更新
    2016年12月15日21:15 追加
    

    巨大テキストエディタ三つと似て非なるもの一つ

    巨大テキストエディター 世界Top3に示す通り、巨大テキストを扱うことができるテキストエディタは以下の三つである。

    1. スズカワエディタ（Suzukawa Editor）32bit版、64bit版
       ファイルサイズ：5TB（5120GB）以上
       行数：2兆5000億行（25000億行）以上
    2. 010Editor32bit版、64bit版
       ファイルサイズ：数TB
       行数：32bit版：約320億行、64bit版：数千億行
    3. PilotEdit64bit版
       ファイルサイズ：400GB
       行数：400億行（約150億行）

    上記の他に、巨大テキスト（ファイルサイズ248GB、行数21億行）を扱うことができると活発に宣伝工作活動を展開しているのが日本のEmEditorである。

    EmEditorはファイルサイズ、行数、メモリ、操作性で示す通り、100GB程度のファイルの先頭行で[Enter]キーを押し下げると、その改行作業に1時間もかかるという代物であった。その後２、３年かけて改良した結果、10秒程度まで短縮できたようである。

    最近はどうなっているかテストしてみた。

    テストに使用したテキストファイルは以下の通り。
    （ ）内の数値は下表の（ ）付きの数値と対応する。

    1. ファイルサイズ：約190GB（約19GB）
    2. 行数：20億行
    3. ファイルの内容は1行当たり半角文字（数字、アルファベットの大文字、小文字）100個（10個）程度
    4. 文字コード：Shift_JIS

    使用パソコンはこちら。

    テスト方法は、上記に示すテキストファイルを読み込んで先頭行で[Enter]キーを押し下げて、改行処理にかかる時間（改行時間）を調べるのである。

    EmEditorに限り3つの行数（20億行①、10億行②、5億行③④）について、他の三つのテキストエディタは行数20億行①のケースだけをテストした。

    結果は以下のとおり。

    下表で（ ）が付いていない数値は1行当たりの文字数：約100個のテキストファイル、
    EmEditorの（ ）付きの数値は1行当たりの文字数：約10個のテキストファイル、
    EmEditorの④は1行当たりの文字数：約400個のテキストファイル、
    それぞれに対して改行テストを実行したものである。

    表1 - [Enter]キーによる改行処理にかかる時間
    

    テキストエディタ	ファイルサイズ 行数	読み込み時間	使用メモリ	改行時間	備考
    EmEditor 64bit	① 約190GB （約19GB） 20億行	25分15秒 （9分52秒）	約12GB （約12GB）	16分32秒 （12分50秒） 8分30秒 （8分2秒）	備考A
    	② 約95GB （約11GB） 10億行	11分46秒 （4分18秒）	約12GB （約12GB）	7分10秒 （4分55秒） 3分34秒 （2分30秒）
    	③ 約48GB （約5.8GB） 5億行	5分10秒 （1分12秒）	約11GB （約11GB）	1秒 （1秒） 1秒 （1秒）
    	④ 約220GB 5億行	25分42秒	約9GB	1秒
    スズカワエディタ 64bit	① 約190GB 20億行	55分44秒	約20MB	0秒	備考B
    010Editor 64bit	① 約190GB 20億行	24分30秒	約200MB	0秒	備考C
    PilotEdit 64bit	① 約190GB 20億行	107分42秒	約8.3GB	0秒	備考D

    1. 備考A：EmEditor
       

       改行時間の上段はテキストファイルの先頭行で、下段はテキストファイルの中間行付近でEnterキーを押し下げた場合の時間を示す。いうまでもないことであるが、これは0秒でなければならない数値である。改行時間は一瞬（0秒）であるのが当たり前の話である。ところが１行改行するのに10分以上もかかる。

       テスト結果から結論すると、EmEditorは行数10億行以上のテキストファイルを自由自在に扱うことはできないだろう。大容量メモリ、高性能CPUを装着したパソコンを使用しても20億行ファイルをさくさく編集したり、スムーズにスクロールすることは難しいのではないか。

       改行が自由自在ではないのだからテキストを編集するツールであるテキストエディタとしては失格である。では、テキストを見るだけのツールであるテキストビューワーとしてはどうか。読み込んだテキストファイルで一行目から最後の行まで見ようと鉛直スクロールバーでスクロールタブを上下方向にドラッグしてみると、これがスクロールできないのである。20億行というのは大変な行数である。[PageUp]キー、[PageDown]キーで全行をスクロールするのは膨大な時間がかかる。全体を概観するのはやはり鉛直スクロールバーを使用するのがよいだろう。しかし、そのスクロールが思うに任せないのである。つまりテキストビューワーとしても失格ということである。先頭や最後、任意行にジャンプするのはもちろんできる。

       読み込みは確かに速い。しかし、編集も駄目、見るのも駄目。そうすると、EmEditorは読み込んだ後、何するの？

       ５億行まで行数を減らすと、ファイルサイズに関係なく（③と④）、一瞬、間をおいて改行する。表ではこれを1秒とした。鉛直スクロールバーのドラッグによるスクロールもスムーズにできるようになる。高性能パソコンを使用すれば、10億行ぐらいまでは大丈夫かもしれない。

       他の三つ、スズカワエディタ、010Editor、PilotEditは各自の最大ファイルサイズ、最大行数のテキストファイルで{Enter]キーによる改行、鉛直スクロールバーのドラッグによるスクロールは一切問題なくできるのである。

       複数行テキストの置換でもそうであったが、EmEditorは他のテキストエディタに比較すると技量不足の感を免れないのである。

    2. 備考B：スズカワエディタ
       

       読み込み時間はEmEditorや010Editorに比較すると2倍以上かかる。これは外部ファイルを読み込みながら、ワークファイル（ワンダーファイル）を作成し、保存する作業に時間がかかるためである。スズカワエディタは一旦外部ファイルを読み込むと、編集しても外部ファイルとして保存しなくても、一瞬で閉じることができる。次回から、「ワンダーファイラー]で一瞬のうちに開き編集作業を再開できる。前回以前の編集に対してもUndo、Redoが有効に機能する。一旦読み込んだファイルを瞬間的に開いたり閉じたりする機能、これを仮に「瞬間開閉機能」ということにする。瞬間開閉機能はもちろんスズカワエディタだけのものである。また、この機能がなければ超巨大テキストファイルを扱うことはできないのである。

       スズカワエディタはファイルサイズ5TB以上、行数2兆5千億行以上を編集できる。当然のことながら、[Enter]キーによる改行も問題ない。鉛直スクロールバーのドラッグによるスクロールは010EditorやPilotEditに比較するとぎこちないが問題はない。

    3. 備考C：010Editor
       

       この中で、読み込みが一番速い。読み込み速度はEmEditorと同じ位である。しかし、鉛直スクロールバーを上下にドラッグすると、ページが滑らかにスクロールする。この点はEmEditorとは天地の違いである。

       キーボードによるテキスト編集も問題ない。[Enter]キーによる改行も問題ない。

    4. 備考D：PilotEdit
       

       この中で、読み込み速度は一番遅い。しかし、キーボードによるテキスト編集はさくさくできる。[Enter]キーによる改行も問題ない。鉛直スクロールバーのドラッグによるスクロールも滑らかにできる。

    
    
14. 2016年11月02日22:00 更新
    2016年11月02日17:00 追加
    

    文字数が大きい検索文字列の検索・置換

    複数行テキストの検索と置換ができるテキストエディタは世界広しといえども10個に満たない。この中で文字数が100万個以上の検索文字列を置換できるのはスズカワエディタとSublimeTextの二つだけである。世界で二つしかないということである。

    二つのテキストエディタを大きい検索文字列の検索・置換で比較してみる。

    テストに使用した検索ファイル、検索文字列は日本語（Unicode = UTF-16LE）、置換文字列はアルファベット9文字である。検索文字列のバイト数は1文字あたり2バイト。使用パソコンはこちら。

    結果は以下の通りである。

    表1 - 文字数が大きい検索文字列の検索・置換にかかる時間
    

    テキストエディタ	① ファイルサイズ：6.0GB ファイル行数：4600万行 検索文字列文字数：100万個 検索・置換数：60個	② ファイルサイズ：18GB ファイル行数：13800万行 検索文字列文字数：1000万個 検索・置換数：180個	③ ファイルサイズ：120GB ファイル行数：92000万行 検索文字列文字数：5億個 検索・置換数：100個	備　考
    スズカワエディタ 64bit	24秒 内部ファイル	6分32秒 外部ファイル	42分22秒 外部ファイル	備考A
    SublimeText 64bit	123秒 内部ファイル	12分30秒 内部ファイル	-	備考B

    1. 備考A：スズカワエディタ
       スズカワエディタは1000万個以上の検索文字列は内部ファイルでは検索・置換できない。内部ファイルに対してはUndoで元に戻すことができるが、外部ファイルに対してはそれはできない。外部ファイルではバックアップファイルを作成している。内部ファイル、外部ファイル共に検索リスト、置換リストを作成し、タグジャンプで検索文字列、置換文字列にジャンプし文字列を選択状態にし、二つの文字列を比較することができる。
       ③のファイルサイズ120GBはスズカワエディタにとってはなんでもない。検索文字列5億個はスズカワエディタで最大値であり、現在のところ世界最大でもあるが、処理に余裕はない。
    2. 備考B：Sublime Text
       SublimeTextは外部ファイルに対しては大きい検索文字列を検索・置換できない。①②共にUndoで元に戻すことができる。その処理は極めて迅速である。大きい検索文字列を所定のコントロール（コンボボックス、メモボックス）に設定する作業に時間がかかるのが難点である。
       ③の120GBは読み込むことができない。SublimeTextは検索文字列の文字数が4000万個以上になると、一つ一つ検索した文字列を置換できるが連続置換はできない。

    表中の②は同じ検索条件ではないが、スズカワエディタの方がSublime Textより検索・置換の処理作業が迅速で実行も速いと結論づけても差し支えないだろう。

    
    
15. 2016年11月01日18:45 更新
    2016年10月22日11:00 追加
    

    検索文字列の文字数

    複数行テキストの検索と置換ができるテキストエディタで検索できる文字列の大きさ（文字数）を調べてみた。
    テストに使用した検索ファイル（約5GB）、検索文字列、置換文字列は日本語（Unicode = UTF-16LE）である。バイト数に換算する場合は1文字あたり2バイトで計算するとよい。下記の説明では、「外部ファイル」はHDD、SSDに収納されているファイル、「内部ファイル」は外部ファイルをそれぞれのテキストエディタに読み込んで独自に処理したファイルのことである。
    使用パソコンはこちら。
    結果は以下の通り。結果に異論がある方々、もっと詳細に知りたい方々は自分自身で確認してください。

    1. スズカワエディタ（64bit版）
       検索・置換できる文字列の文字数が最大5億個である。これはテキストエディタの中では世界最大である。
       ただし、1千万個以上の検索文字列を検索・置換できるのは外部ファイルに限られる。内部ファイルに対する検索・置換はかなり無理をして最大1千万個である。検索文字列が大きい場合、正規表現は使用できないことが前提。
       外部ファイルに対する5億個の検索文字列を検索する場合、使用メモリは約12GB。内部ファイル、外部ファイルともに連続的に検索・置換し検索リスト、置換リストを作成。タグジャンプで検索文字列、置換文字列を選択し二つを比較できる。
    2. Sublime Text（64bit版）
       検索できる文字数は約1億9千万個。内部ファイルに対して検索・置換を試した。検索メニュー選択後に検索文字列設定コントロール（メモボックス）が表示されるまで2、3分時間がかかる。さらに検索文字列をメモボックスに貼り付ける作業も時間がかかる。これが難点であるが、検索自体は遅くはない。文字数が大きすぎるせいか、一つ一つ検索した文字列に対する置換、連続置換ともに実行できない。使用メモリは約12GB。
       連続置換ができるのは検索文字列の文字数が4千万～5千万個。一つ一つ検索した文字列を置換できるのは1億5千万個程度まで。それ以上になると、一つ一つ検索できるが、置換はできない。
       2億個になるとパソコンがフリーズする。Windowsが操作不能に陥る。[Ctrl]+[Alt]+[Del]キーでタスクマネージャーが起動しない。ただし、どういうわけかマウスカーソルだけは動く。パソコンはリセットスウィッチで再起動する以外にない。
       私（鈴木）の操作方法が悪いのか、外部ファイルに対しては複数行テキストを検索できないようだが。これはまたの機会にする。
    3. 010Editor（64bit版）
       010Editor最新版（v7.02）では不具合のためか複数行の検索文字列を検索できない。前のバージョンv6.03でテストする。
       設定できる検索文字列の文字数は320万個。検索文字列を設定するコンボボックスで330万個以上の検索文字列を貼り付けていつまで待っても作業が終了しない。
       内部ファイルに対して320万個の検索文字列を一つずつ検索（次を検索）できる。しかし、一つ一つ検索した文字列の置換、連続置換は検索文字列が大きすぎるのか「問題が発生した」旨のメッセージが表示され実行できない。
       外部ファイルに対して320万個の検索文字列を連続検索して検索リストを作成する。しかし、同じ検索文字列を連続置換すると内部ファイルと同様に問題が発生した旨のメッセージを出して実行できない。
       上記に示すとおり、内部ファイル、外部ファイル共に検索のみであれば検索文字列は320万個まで可能である。しかし、置換（一つ一つの検索文字列置換、連続置換）の場合、検索文字列の大きさは極端に小さくなる。内部ファイル、外部ファイル共に置換できる検索文字列の大きさは8000～9000個の間である。8000個ならば置換できるが、9000個になると「問題が発生した」旨のメッセージが出て置換を実行しない。
    4. PilotEdit（64bit版）は約1万個。EmEditor（64bit版）は約1万個。UltraEdit（64bit版）は未確認。秀丸エディタ（64bit版）は2000個。MIFESは1000バイト（500～1000個）。

    外部ファイルに対する複数行テキストの検索・置換、複数行テキストの検索と置換で示す通り、検索・置換できる数量でもスズカワエディタが世界一であるが、検索・置換できる文字列の大きさでもスズカワエディタがダントツの世界一というわけである。

    検索できる文字列が大きいほうが小さいよりいいことであるのは誰でも異論はなかろうと思う。しかし残念ながら、私（鈴木）は大きい検索文字列を生かす分野、使用方法を知らないのである。もし「大きい検索文字列」が活躍できる場面があるならばご教示願いたい。

    現在5億個であるが、実はこんなものではない。正規表現は使用できないが、100億個でも検索・置換できるのである。しかも使用メモリは100MB以下になるだろう。ただし、その実現には時間と労力と気力が必要である。

    
    
16. 2016年08月22日09:40 更新
    2016年08月18日16:40 追加
    

    内部ファイルに対する複数行テキストの検索・置換

    複数行テキストの検索・置換ができるテキストエディタは世界でも限られているようだ。そのうち、ファイルサイズが5GB以上、行数が5000万以上のテキストファイルを処理できるテキストエディタをここで取り上げる。もちろん、世界のテキストエディタをすべて調べたわけではない。もし、ここで取り上げていないテキストエディタがあれば、ご連絡願いたい。

    秀丸エディタ、Mifesについては前回のテストでも明らかであるが、ここで取り上げるだけの性能を備えていない。

    以下の説明の中で出てくる「前回のテスト」とは、内部ファイルに対する「複数行テキストの検索と置換」を指している。
    外部ファイルに対する複数行テキストの検索・置換も参考にされたい。

    外部ファイルを読み込んだテキスト（内部ファイル）に対する複数行テキストの検索・置換にかかる時間を調べた結果を下表に掲載する。表中の数値は前回のものをそのまま掲載している場合と今回新しく追加した場合がある。

    今回のテストも前回のテストで使用した条件と同じである。

    下表に示す通り、EmEditorが異常に遅い。スズカワエディタと比較すると約100倍の時間がかかっている。EmEditor以外のテキストエディタたちに大きい差はない。それぞれ、恥ずかしくない結果を出している。EmEditorだけが極端に低速である。EmEditorの技量と姿勢には深刻な問題があると言わざるを得ない。

    表1 - 内部ファイルに対する複数行テキストの検索・置換にかかる時間
    

    テキスト エディタ	① 1.2GB 920万行 13,457個	② 2.4GB 1840万行 26,914個	③ 3.6GB 2760万行 40,371個	④ 4.8GB 3680万行 53,828個	⑤ 6.0GB 4600万行 67,285個	⑥ 12.0GB 9200万行 134,570個	備　考
    EmEditor 64bit	5分30秒 5分05秒	21分13秒 19分20秒	47分03秒 42分47秒	81分38秒 75分24秒	129分02秒 117分15秒	実行しない	備考A
    スズカワ エディタ 32bit	14秒 12秒	26秒 25秒	38秒 38秒	52秒 48秒	1分14秒 1分06秒	4分35秒 4分13秒	備考B
    010Editor 64bit	10秒	23秒	43秒	1分15秒	2分05秒	7分20秒	備考C
    PilotEdit 64bit	45秒 (20秒)	1分42秒 (49秒)	2分13秒 (58秒)	3分00秒 (1分20秒)	3分41秒 (1分35秒)	7分51秒 (3分10秒)	備考D
    SublimeText 64bit	32秒	1分04秒	1分35秒	2分08秒	2分37秒	5分10秒	備考E
    UltraEdit 64bit	15秒	28秒	42秒	58秒	1分12秒	途中終了 メモリ不足	備考F

    1. 備考A：EmEditor
       上段が今回、下段が前回のテスト結果。前回より遅くなっている。今回、前回共にUndoはできない。リストなし。
       ⑥は前回、TimeOver（実行しようとしたが時間がかかりすぎで強制中断）だったが、今回は何のメッセージもなく数秒で自ら中断。外部ファイルの置換でも2GBを超えるファイルについては何のメッセージもなくすっ飛ばして実行しない方針である。EmEditorの触れ込みでは処理できるファイルサイズは248GB以下、21億行以下という話である。
    2. 備考B：スズカワエディタ
       上段が検索リストと置換リストを作成。Undoもできる。
       下段が検索リストも置換リストも作成しない。Undoはできる。
       リストを作成するかしないかでかかる時間が大きく変わることはない。
       ⑥はデータサイズが⑤の２倍であるが、時間は４倍近くかかっている。前回は⑤が56秒、⑥が3分45秒。
    3. 備考C：010Editor
       前回のテスト結果をそのまま引用。Undoはできる。置換リストあり。
    4. 備考D：PilotEdit
       前回のテスト結果をそのまま引用。Undoはできる。リストなし。
       下段の（ ）内数値はUndoのために必要なデータを保存している時間。
    5. 備考E：Sublime Text
       今回が初めてのテスト。Undoはできる。リストなし。
       Replaceメニューを実行すると、MainWindowの下部に検索文字列と置換文字列を表示する二つのメモコントロールが表示されるのであるが、前回、長い検索文字列、置換文字列が設定されていると、その二つのメモコントロールが表示されるまで、かなり時間がかかる。今回の3GBのテストで約1分ぐらいかかる。
       Undoで元にもどす時間は数秒程度。かなり速い。
    6. 備考F：UltraEdit
       今回が初めてのテスト。Undoはできる。リストなし。
       初めて実行する場合はかなり速い。スズカワエディタとほぼ同じ。
       Undoは初めて実行する場合の約２倍半時間がかかる。
       ⑥はUndo用データを保存するメモリが足りないというメッセージを出して中断。Undoできるようにするかどうかの設定がないようだが、もしかしたら、Undoはできないが最後まで置換を実行できるのかもしれない。
    
    
17. 2016年07月08日06:30更新
    試用版ライセンス、臨時発行その３（ファイルサイズ無制限、行数無制限）を試用できます。
18. 2016年06月27日18:00更新
    無料版ライセンス（3GB、1億行）を使用できます。
19. 2016年06月27日18:00更新
    スズカワエディタ最新版 ver 04.01.06Aをアップロードしました。
20. 2016年07月08日06:30更新
    

    複数行テキストの検索と置換ができるテキストエディタ

    ファイルサイズ1GB以上、行数1千万行以上のテキストファイルを扱えるテキストエディタで、複数行テキストの検索・置換機能を備えているのは次の通りである。順序は扱うことができるファイルサイズ、行数が大きい順に並べている。

    1. スズカワエディタ改良版（32bit、64bit）日本
    2. 010Editor（64bit）海外
       複数行テキストの検索速度はこの中では一番
    3. PilotEdit（64bit）海外
    4. EmEditor<（64bit）日本
    5. Sublime Text（64bit）海外
       検索できる複数行テキストの大きさ（文字数）はこの中では一番
    6. UltraEdit（64bit）海外
       外部ファイルに対する複数行テキストの検索・置換速度はこの中では一番
    7. 秀丸エディタ（64bit）日本
    8. Mifes（32bit）日本
    Sublime TextとUltraEditは今回が初登場である。上記に示すとおり、この二つは複数行テキストの検索・置換機能では他のテキストエディタに勝るものを持っている。扱うことができるテキストのファイルサイズ、行数については詳しく調べていないが、それほど大きくないようだ。数十GB程度。

    外部ファイルに対する複数行テキストの検索・置換、複数行テキストの検索と置換 の二つのテストから判断して、日本勢のEmEditor、秀丸エディタ、Mifesは複数行テキストの検索・置換機能では世界に伍していくのは、残念ながら、難しいだろう。二つのテスト結果を見れば、説明は不要であろう。

21. 2016年06月28日13:30更新
    

    スズカワエディタ改良版について

    スズカワエディタ改良版は、複数行テキストの検索・置換機能の追加を主軸に置いています。改良の進捗状況は以下のとおりです。
    

    1. スズカワエディタに読み込んだテキスト（ここではこれを内部ファイルと呼ぶことにする）について複数行テキストを検索・置換できる。
    2. 内部ファイルに対しては上から下に向かう場合と下から上に向かう場合の両方で検索・置換を実行しそのUndo、Redoも実行できる。
    3. 外部ファイル（HDD、SSDの収納ファイル）について複数行テキストを検索・置換できる。
    4. 内部ファイル、外部ファイルに対する検索・置換で、検索文字列（または置換文字列）一つごとに、ファイル名、行、桁位置、文字数、検索（置換）付近の文字列を一行ずつリストとして表示できる。このリストをここでは検索リスト、置換リストと呼ぶことにする。
    5. 置換の場合はリストの表示方法は次の４種類から選択できる。
       1. リストを表示しない
       2. 検索リストのみ表示する
       3. 置換リストのみ表示する
       4. 検索リスト、置換リストの両方を表示する（スズカワエディタ独自機能）
    6. 検索リスト、置換リストの各行をダブルクリックするか、F10キーを押し下げると、当該ファイルの当該行を開き、当該検索文字列または当該置換文字列を選択表示する。
    7. 選択文字列は「選択凍結（スズカワエディタ独自機能）」することによって複数行（たとえば数万行）であっても大きな文字数（たとえば100万個）であってもスクロールしたり、先頭や最後にジャンプするなどして確認できる。
    8. 5のⅳのように、置換で検索リストと置換リストを表示すると、置換前のファイルから検索文字列を、置換後のファイルから置換文字列をそれぞれのテキストウィンドウで表示し、二つのウィンドウを左右または上下に並べて比較確認できる。本来こうあるべきであるが、世界広しといえども未だない。これは世界で唯一つスズカワエディタだけができる独自機能。いずれ他のテキストエディタも模倣することになるだろう。
    9. 検索文字列、置換文字列で複数行テキストを指定する方法は、他のテキストエディタとは異なるスズカワエディタ独自のものである。これも世界唯一の方法であろうと自負している。
       他のテキストエディタは次のどちらかのコントロールに対して、検索文字列または置換文字列を直接入力するかコピー＆ペーストする方法を採用している。
       1. 一行表示のテキストボックスまたはコンボボックス
       2. 複数行表示できるがウィンドウサイズが小さく固定しているメモコントロール
       スズカワエディタは複数行テキストを外部ファイルに保存しそのファイル名をコンボボックスで指定する方法を採っている。外部ファイルにテキストを保存するのは手間がかかるだろうと心配する向きもあると思うが、それは簡単にできるようになっている。ファイルに収納したテキストの内容を確認するのも簡単にできる。
       この方法は完璧とは言いかねるが、大量メモリ、大量文字列の扱いを本来得意としていないコントロール（テキストボックス、コンボボックス、メモコントロール）を使用するより、スッキリして整理がつきやすい方法であると私（鈴木）は気に入っている。

    複数行テキストの検索・置換機能は当初、上記の1と2だけしか念頭になかったのですが、改良中にそれだけでは不十分という考えに変化しました。２０１５年２月頃から改良を始めて、１年半近く時間がかかっています。しかし、複数行テキストの検索・置換機能は便利なものであり、未来を開く可能性があると感じるようになりました。この機能を備えているテキストエディタは世界でも数えるほどしかないようです。それも一応備えているが、いずれも性能は十分ではないという状況です。複数行テキストの検索・置換機能の充実は長い時間をかけるだけの価値があると確信しています。

    改良中にいくつか課題が見えてきましたが、これについてはまたの機会にして改良は一旦終了するつもりです。現在は周辺機能を整えているところです。これがなかなか時間がかかるのです。

22. 2016年05月26日18:50更新
    2016年05月25日09:45更新
    2016年05月23日09:45更新
    2016年05月21日13:30更新
    2016年05月20日14:45更新
    2016年05月19日20:45追加
    

    外部ファイルに対する複数行テキストの検索・置換

    1. スズカワエディタ改良版は、複数行テキストの検索・置換機能の追加を主軸に置いています。「複数行テキストの検索と置換」ではテキストエディタのテキストウィンドウに読み込んだテキスト上で複数行テキストの検索・置換をいろいろ試しましたが、ここでは外部ファイル（HDD、SSDに収納されているテキストファイル）に対する複数行テキストの検索・置換を試してみます。

    2. テストするパソコン環境、テキストエディタ、テキストファイル、検索文字列、置換文字列は「複数行テキストの検索と置換」と同じです。

    3. 結果は以下の通りです。
       各テキストエディタの上下2段の欄は上段が検索・置換、下段が検索のみの場合である。
       表中の時間は検索・置換と検索のみにかかる時間を示す。バックアップができる場合はバックアップ時間も含まれる。
       検索リストは検索結果、置換リストは置換結果を示すリスト。
       表1-1 tr id="searchreplacetest_emeditor">

       テキスト エディタ	性　能	置換 バック アップ	置換 リスト	① 1.2GB 920万行 13,457個	② 2.4GB 1840万行 26,914個	③ 6.0GB 4600万行 67,285個	④ 12GB 9200万行 134,570個	⑤ 120GB 9億2000万行 1,345,700個	⑥ 1200GB 92億行 13,457,000個	備　考
       			検索 リスト
       スズカワ エディタ 32bit	5TB以上 2兆5000 億行以上	可	有	20秒	35秒	1分28秒	4分45秒	49分43秒	505分24秒	備考A
       			有	14秒	18秒	47秒	2分04秒	21分44秒	222分18秒
       010 Editor 64bit	数TB 数千億行	不可 ？	有	12秒	33秒	2分53秒	10分20秒	127分05秒	省略	備考B
       			有	8秒	15秒	34秒	1分11秒	36分35秒	TimeOver
       Pilot Edit 64bit	400GB 150億行	不可 ？	無	50秒	100秒	5分20秒	10分48秒	112分05秒	-	備考C
       			有	41秒	78秒	3分28秒	7分28秒	195分00秒	-
       Em Editor 64bit	248GB 21億行	可	無	910秒	実行しない (2300秒)	-	-	-	-	備考D
       			有	18秒	37秒	1分24秒	2分50秒	37分30秒	-
       秀丸 エディタ 64bit	数十GB 1億行	可	有	499秒	1831秒	-	-	-	-	備考E
       			有	18秒	35秒	1分17秒	2分35秒	25分52秒	-
       MIFES 32bit	2GB 数億行	可	有	59秒	-	-	-	-	-	備考F
       			有	14秒	-	-	-	-	-

       表1-2

       テキスト エディタ	備　考
       スズカワ エディタ 32bit	検索・置換はファイルサイズ、検索量が大きくなるとスズカワエディタが最速。⑤では検索のみの場合でも010Editorを抜いてスズカワエディタが最速。 ⑥を完遂できるのはスズカワエディタのみ。私（鈴木）のパソコン環境と時間が許せばもっと大きいファイルサイズ、もっと大量の検索量で試したいのであるが、今のところそれができない。本テストは1200GBで終了するが、スズカワエディタはファイルサイズが10TBでも100TBでも検索文字列が10億個でも100億個でも安定して検索、置換、読み込み、表示ができる。 検索リストから置換前の検索文字列と置換後の置換文字列をそれぞれのテキストウィンドウで表示できる。これは便利な機能であるが、置換前のファイルと置換後のファイルをそれぞれ読み込む必要がある。⑥の例では読み込み時間はそれぞれ約260分ずつかかっている。これは現在スズカワエディタのみができる世界唯一の機能であるが、いずれ他のテキストエディタも模倣することになるだろう。
       010 Editor 64bit	ここで取り上げたテキストエディタの中では検索は最速。検索・置換はファイルサイズ、検索量が小さいうちは速いが、大きくなると処理速度は落ちてくる。③～⑤ではスズカワエディタの方が速い。 ⑥の検索はTimeOver。14時間以上経過しても表示されるプログレスバーに進捗が見られない。メモリは13GB。CPU使用率は0～2％。「応答なし」状態を呈することはない。検索リストが表示されているが、もちろんすべてではない。14時間待ったが、作業が進捗している様子がみられない。強制的に終了。 ⑥の検索・置換は省略。⑤の結果（検索・置換/検索＝127分/37分≒3.4倍）から推測して、TimeOverで完遂できない⑥の検索と同様に完遂できないものと考えられる。したがって、⑥の検索・置換テストを省いても、本テストが公平性と信頼性を欠くことにはならないと判断した。 バックアップはもしかしたら、私（鈴木）が操作方法を知らないだけで、できるのかもしれない。
       Pilot Edit 64bit	検索・置換速度は格別速いというわけでもない。検索のみの場合はここで取り上げたテキストエディタの中で一番遅い。 ⑤では検索・置換より検索のみの方が時間がかかっている。これはリストの作成時間の有無が原因と考えられる。検索・置換では置換リストは作成されないが、検索のみの方は検索リストが作成される。 検索・置換処理中、進捗具合を示す表示がないので、ファイルサイズが大きく時間がかかる場合は処理時間の計測に苦労する。⑤では正確な処理時間を知るために結果として検索・置換と検索のみのテストをそれぞれ2回ずつ実行しなければならなかった。PilotEditのテストが一番手間取った。 バックアップはもしかしたら、私（鈴木）が操作方法を知らないだけで、できるのかもしれない。
       Em Editor 64bit	検索・置換は2GBを超えるテキストファイルに対しては実行できない。248GB、21億行までのテキストファイルを扱うことができるという謳い文句であるが、たかが2GB程度のファイルを検索・置換できないとは驚き呆れるばかりである。 ②の( )内の時間（38分20秒）は約2000MBに削って試した場合を示す。ここで取り上げたテキストエディタの中では最も遅い。「複数行テキストの検索と置換」でも異常な低速ぶりを示したのであるが、こうなると、EmEditor開発者のプログラム技量に問題があると言わざるを得ないだろう。 置換中ダイアログが表示されるが、進捗状況を示す変化が全くなく表示の意味がない。 ただし、検索だけの場合は2GBを超えるテキストファイルに対しても実行できるし、他のテキストエディタに比較して特別に遅いということはない。
       秀丸 エディタ 64bit	秀丸エディタは何をやっても特別に高速でもなく特別に低速でもないが、検索・置換はかなり遅い。ただし、検索だけの場合はかなり速い。 ③の検索・置換についてはテストを省いた。②が30分もかかっているので、できるとしてもその2倍（1時間）以上はかかるだろう。 ⑤の120GBファイルは一応最後まで検索し検索リストも最後まで作成する。処理速度はスズカワエディタに次いで２番目に速い。さて、次の操作段階として検索リストから検索文字列を表示するために検索ファイルを読み込む必要があるが、残念ながら1億行の行数制限で最後まで検索ファイルを開くことができない。
       MIFES 32bit	特別高速ということもなく、特別低速というわけでもない。

23. 2016年05月06日16:30更新
    こちらを見ると巨大テキストエディタの本物と本物にあらざるものを実感できます。
24. 2016年03月01日08:15更新
    2015年11月15日21:00更新
    スズカワエディタ改良版は、下記の特長に示す機能はすでに終了しています。現在いろいろなケースについてテストしながら、さらに改良しているところです。改良は昨年（２０１５年）の２月頃から開始して、もう一年以上かかっています。多大な時間と労力と気力、さらに精一杯の我が能力を費やしてきましたが、もう少しで終わるでしょう。完成すればスズカワエディタは大変便利になるはずです。
    改良中の特長は以下の通りです。
    1. 複数行にわたる（改行コードを挟む）文字列を検索、複数行にわたる（改行コードを挟む）文字列で置換できます。
    2. 前方、後方の両方から検索・置換できます。
    3. Undo、Redoもできます。
    4. 検索・置換を実行したテキスト行は編集と同様に編集マーク行に変更されます。これはUndoによって編集マーク行に変更される前に戻り、Redoによって再び編集マーク行に変更されます。
    5. 検索・置換でBookMark（しおり）はその位置が保持されます。一つの検索文字列の中に複数含まれるBookMarkはその一部が削除される場合がありますが、Undoによって復活、表示されます。
    6. ワードラップ（折り返し）状態でも上記の機能を実行できます。
    7. 他のテキストエディタに比較して高速です。
25. 2015年09月28日08:45 更新
    スズカワエディタとは全く関係ないことですが、youtubeでいろいろな歌手が歌う「Ave Maria」を聴いているうちにMARTINという歌手を知りました。同時に「YOU RAISE ME UP」という歌も 初めて知りました。既にご存知の方もいると思いますが、日本では彼を紹介しているサイトが未だ少ないようです。一見の価値はあると思います。以下にyoutubeにアップされているアドレスを示します。
    1. MARTIN YOU RAISE ME UP
       https://www.youtube.com/watch?v=4RojlDwD07I
    2. You Raise Me Up　 [日本語訳付き] MARTIN
       https://www.youtube.com/watch?v=S0mOXC8pJfM
    3. MARTIN AVE MARIA .wmv
       https://www.youtube.com/watch?v=v8O15DogWgg