30万字を超える原稿では、「開いたように見える」だけでは仕事を始められません。先頭が表示できても末尾が欠けていたり、保存後に別の版を開き直したりすれば、長時間の編集が無駄になります。先に確かめるべきなのは、原稿の文字コードと改行、末尾の目印、最小編集後の文字数、そして保存ファイルの同一性です。
固定標本で確認できた結論は明快です。UTF-8・LFの316231文字のファイルを構造検査すると isLargeFile=true となり、末尾の END-366 を1件取得できました。その末尾を END-366-SAVED に変えて同じ名前へ保存し、再検査すると316237文字、検索1件、SHA-256は 5b8960c3cd6a86d15af09e3aadadf009bc98828db24f8697603d70f4acab497a でした。これはファイル内容の読取・保存・再読込を裏づけます。画面の描画速度や、巨大原稿でどの装飾が停止するかまでは測っていません。
まず「大きい」を文字数と末尾で定義する
テキストエディタ 大容量ファイルの確認で、容量だけを見て判断するのは危険です。日本語は文字コードによってバイト数が変わりますし、同じ文字数でも非常に長い一行と短い行の集合では表示負荷が違います。今回の入力は316231文字、3行、UTF-8、LFです。rune inspect text --file <対象> --json で取得した値を、編集前の受入票にそのまま残します。
次に末尾へ固有の印を置きます。一般的な「終」や日付は本文中にも現れやすいため、標本では END-366 を使いました。rune search find-in-file --file <対象> --query END-366 --json の結果は1件、2行目、offset 316223です。先頭から全体を目視でスクロールする代わりに、末尾の所在を機械的に確定できます。
ここでの合格は「先頭が読めた」ではありません。文字数が316231で、末尾印が1件だけあり、その位置まで検索で到達できることです。この三つを一組にすると、途中で切れたファイルや別版を早い段階で除外できます。
原本ではなく複製で最小編集を試す
いきなり制作中の原本を開いて上書きしてはいけません。原稿と同じ内容を持つ検証用コピーを作り、元のSHAや保管場所を記録します。今回の操作も分離した作業場所で行われ、元の末尾 END-366 に六文字分の -SAVED を足す変更だけに限定しました。本文の語句や段落を同時に直してしまうと、文字数の差から保存の成否を判断できなくなるためです。
保存操作は、変更済み内容を同じファイル名へ書き戻す形で実施しています。結果のSHA-256は前述の 5b8960…497a。ファイル名が同じでも内容が同じとは限らないので、名前は識別子ではなく手掛かりにすぎません。編集前後の末尾印、文字数、SHAをそろえて初めて版を特定できます。
実案件では、複製を日付だけで命名するより、案件名・工程・通番を含める方が安全です。原本、検証用、採用候補を別フォルダへ分け、採用するまでは原本を上書きしない運用にすると、試験失敗から戻りやすくなります。
保存後は閉じたつもりで読み直す
メモリ上の編集内容が正しく見えていても、ディスクへ保存された内容が同じとは限りません。そこで保存後のファイルを改めて構造検査します。固定標本では316237文字、3行、UTF-8、LF、isLargeFile=true が返りました。増えた六文字が計数へ反映されています。
続いて検索語を END-366-SAVED に変えます。結果は1件、2行目、offset 316223、length 13です。旧印 END-366 の検索だけでは新しい文字列の先頭にも一致し得るため、保存後の完全な印で確認するのが要点です。最後に保存SHAと採用候補のSHAを照合します。
受入条件は四つです。
- 再検査の文字数が316237である。
END-366-SAVEDが1件だけ見つかる。- UTF-8・LF・3行という入力条件が意図せず変わっていない。
- 保存ファイルのSHA-256が記録値と一致する。
一つでも外れたら、その版を制作へ流しません。「だいたい同じ長さ」や「末尾が画面で見えた」は合格の代わりになりません。
食い違いを見つけたら編集を重ねない
文字数が予想より多いときは、末尾印以外の編集が混ざった可能性があります。少ないときは、書込対象の取り違え、途中切れ、改行変換を疑います。末尾印が0件なら保存先または検索対象が違い、複数件なら印の選び方が不適切です。SHAだけが違う場合も、改行や末尾空白など目に付きにくい差分があり得ます。
この状態で修正を継ぎ足すと原因が増えます。作業を止め、編集前の複製へ戻り、入力条件を読み直してから同じ一変更だけを再実行します。回復の基準は「見た目が戻った」ではなく、316231文字と END-366 1件を再び確認できることです。その基準点から保存試験をやり直します。
長い原稿ほど、問題の位置を絞ることが重要です。先頭、中間、末尾へ別々の印を置けば欠落区間を狭められますが、今回実測したのは末尾印だけです。中間印まで確認済みであるかのようには扱いません。
画面での「快適さ」は別の試験にする
固定証跡から言えるのは、316231文字の内容を検査し、末尾を検索し、最小変更を保存し、316237文字として再読込できたことです。処理時間は計測していません。画面のスクロール、カーソル追従、検索欄の応答、シンタックス表示なども観察していません。そのため、「瞬時に開く」「軽快に編集できる」「大容量時は特定の装飾が自動停止する」とは断定できません。
実際の端末で単独エディタとして使う前には、利用者側の画面試験を追加してください。検証用コピーを開き、先頭表示後に末尾印へ移動し、一文字だけ入力して取り消し、保存せず閉じる確認をします。次に別のコピーで保存試験を行い、再起動後に末尾印を検索します。CPUやメモリ、所要時間を測るなら端末条件も一緒に記録します。この手順は推奨する確認方法であり、今回の固定CLI証跡で実施済みの結果ではありません。
単独エディタへ渡す前のチェック票
制作担当へ渡す情報は、感想ではなく再確認できる値にします。入力は316231文字・UTF-8・LF・3行、末尾は END-366 1件。操作は末尾を END-366-SAVED へ変更して同名保存。出力は316237文字、末尾検索1件、SHA-256 5b8960…497a。失敗時は編集前コピーへ戻り、同じ一変更だけをやり直す。これで入力、操作、失敗、回復、合格が一対一につながります。
テキストエディタ 大容量ファイルを安全に扱う答えは、無条件に「開ける」と言うことではありません。固定した複製で末尾まで読めることと保存後の同一性を先に証明し、画面の快適さは利用端末で別途確認することです。この順序なら、巨大原稿を単独エディタへ渡す判断を、印象ではなく追跡できる記録に変えられます。