■ ブログに過去の日記の記述を大量一括入力する方法
INDEX
■ ブログの理由
ブログを付ける人の理由はさまざまなはずだ。
単なる日記の延長として、身辺雑記的なことをつづるか。あるいはビジネスシーンのアイディア備忘録としてか。などなど。
実際の紙媒体の日記がそうであるように、ブログもまた、人の数だけ理由があり、異なるブログが存在する。
そうした（普通の）ブログの利用形態をとる人には、本稿はあまり参考にならないだろう。
以下に述べるのは、非常に特殊な事例についてである。
別なブログに引っ越す、といった場合には参考になるかも知れないが、もとより、本稿は、そうしたことを目的としてはいない。
筆者は、日記は付けない（＜いきなり、そう来るか？ と思わないでほしい(笑)）。
ただし、夢の記述を長くつづけていて、その論理資源はかなり厖大な量となっている。
これを、効率的にWebページにアップするには、ブログを利用するのが一番早い。
自分でHTML文書を書いても同じ結果は得られるが、効率が段違いである。結果が同じなら効率がよい方がいいに決まっている。
だが、問題がある。ブログは基本的には、その当日に書いた記述が、その日付で登録される、ということだ。
むろん、編集機能があり、その中には、日付の変更も可能である。
しかしながら、筆者のように、あらかじめ大量の文書をかかえている場合は、どうするのか。
いちいち編集機能での日付の変更など、やっていたら大変な作業である。あまり現実的ではない。
ところで、ブログには、「引越し」機能というのがある（ないものもある）。
世界で標準になっているのは「MT（Movable Type）」形式と呼ばれる代表的な初期ブログ・システムのフォーマットである。このフォーマットでエキスポート（書き出し）されたテキストファイルなら、ほとんどの「引越し」機能を備えたブログへのインポート（読み込み）が可能となる。
筆者は、単に、これまで書きためた夢の記述をWebページに変換するために、ブログを利用しようとして、その方法を探し当てた。
だが、世の中には、これまで書きためた本当の日記や短文などを、そのようにして、書いた日付でアップロードしたい、と考えている人がいるのではないか、とも思う。そう考えて、その方法論を公開することにした。
以下のエントリが、そうした人たちの一助になれば、幸いである。
■ ブログの選択
筆者が選んだブログは「ココログ」だった。
これは、偶然である。筆者が契約しているプロバイダがニフティであり、ココログもまた、ニフティが運営していたのだ。
さらに、たまたま、以前、買ったが、その時はあまり興味がなくて「積ん読」にしていたブログ関係の本を、ある日、読んでみたら、それがココログに多くページを割いており、いくつもの細かい事例まで図解入りで載っていた、ということも大きい。特に編集機能で「日時の変更」が利くと判ったので、それなら使えるかな、と思ったわけだ。つまりは全くの偶然の結果である。結果オーライで、この選択は好かった。
だから、以下は、ココログを中心とした記述となる。留意されたい。
さて、世には、さまざまなブログがある。
だが、その運営母体も、さまざまであり、いつどうなるか判らない。
たとえ、無料会員ではなく、月額数百円を払っている有料会員であっても、そんなことは、運営母体である会社が（そこも、たいてい、別な大きな企業の傘下にあるし）、根こそぎ、買収されたりして、来春には、このサービスは打ち切りになります、ごめんなさい、といった事態も、ありうるのだ。
IT企業は、栄枯盛衰が烈しい世界である。明日ありと思う心のあだ桜、という言葉のとおり、明日のことなど誰にも判らない。
この世知辛い世の中で、月々、数百円ぽっちで、安心が買えるなんてことはない。
どこの大企業系列だから、万古不易の安心、といったことは、この世界には、ない。そう考えていた方がいいだろう。
だったら、「引越し」機能がないブログを利用しているのは、非常に危険である。たとえ、そのブログにどのような魅力的な機能が他にあったとしても、だ。
ネットはリスクの地雷原のようなものだが、わざわざ危険だと判っている地域を選んで足を踏み入れることもないだろう。
危険を孕んだ事業をする人間は、最小限の保険はかけておくものだ。
これから始めるのであれば、そうした危ういブログは可能な限り避けて、一朝事あるときに期して、保険を取っておくことを推奨する。
「MT」形式でバックアップログを取れば、多少の脱落（画像その他）があっても、大体、記述本体は残る。なにもかも失なうよりはマシだろう。
ある人が調べた結果によると――、
ココログ
ブログ人
シーサーブログ
ライブドアブログ（有料）
――といったブログが、エキスポートとインポートの機能の両方を備えているそうである。
最初の２つは、本家の「Movable Type」の簡易版「TypePad」を元にしているので、設計思想は同じである。
（ただし、この資料は少し古いので、今ではもっと多くのブログが対応している可能性はある）
なお、ここで云うブログとは、Web2.0時代のWebサービスで、主に無料で企業が提供しているものを指している。
自分のマシンをサーバとして、PHPプログラミング言語によって、自分独自のブログを構築する、とか、そういった高等なことを意味していない。
できるなら、無料で利用できるサービスを使って、自分の手持ちの論理資源を活用したい、といった目的に適うものを選ぶ。そういう方針である。
次に、インポート機能にだけ対応しているブログがある。
他のブログからの引越しや、自分の論理資源をインポートするなら、よいだろうが、出ていく時は難儀しそうだ。
最後に、エキスポートもインポートの機能も備えていないブログがある。
引越す際は、出るのも入るのも大変そうである。
上述した「調べた人」のサイトでは、ブログの実名を挙げていたが、少し古い資料なので（2006年）、現時点で、どうなっているのか、正確には不明である。だから、他のブログの名前を挙げることはしない。ブログは、まだ新しい技術であり、サービスも進化の途上にある。企業もユーザの声を反映して便利なものを作っていかないと、立ち枯れてしまう。
筆者が選んだココログも、以前は無料コースは制約が多かったようだが、今では、少しずつ、変化しているようである。ニフティ会員が無料の「ベーシック」プランは、以前は「css」が全く使えなかったので、デザイン変更に制限があったらしいが、今では、多少は使えるようになっている。
ともあれ、どこを選ぶにせよ、入る前に諸元を確認した方がよいだろう。
インポート／エキスポートが共に出来ないようなブログを選ぶと、いったん入ったら、出ていくのが非常に面倒になる。
むろん、ネットは、よくしたもので、そうした機能障害のブログでも、どうにかしてくれるツールを発明する人はいる。
「log2mt」というフリーソフトがあり、これを使えば、そうしたブログのログから、「MT」形式のファイルを作成可能だ。
しかしながら、筆者がこれを書いている時点では、「log2mt」の作者は、サイトを閉めて、ツールの配布も中断している由である。
だから、まぁ、一番最初に挙げたインポート／エキスポート両方可能なブログか、それに類したところを選ぶのが、賢明だろう。
どうするかは、利用者の自由だが、ネットには、絶えず「自己責任」が付きものである。
で、筆者の場合は、別に他のブログに入っていたわけでもなく、単に利用させてもらうだけだから、気兼ねがなかった。
縁があったから、ココログの無料コース（ベーシック）を選んだだけだ。
だが、最初から、順風満帆であったわけではない。
いろいろな試行錯誤をした挙げ句、どうにか、自分の思う通りの設計思想と期待に適う画面に辿り着いた、といったところである。
そのことについて、以下に記録を残しておきたいと思う。
■ MT形式
MT形式のフォーマットとは、下記のようなものだ。ココログの内容を「書き出し」たファイルである。
[ ]内には、その人のブログやエントリ固有の文字列が入る。
「DATE」は投稿日時であり、「mm/dd/yyyy」は、各々「月／日／年」を表す。
なお、これはココログの出力フォーマットなので、他のブログでは細目が異なることもある。
（確認するためには、一度、「書き出し」機能でエキスポートして、エディタで開いてみるとよいだろう）
AUTHOR: [ブログネーム] TITLE: [エントリのタイトル] STATUS: Publish ALLOW COMMENTS: 0 CONVERT BREAKS: 0 ALLOW PINGS: 0 PRIMARY CATEGORY: [カテゴリー名] CATEGORY: [サブカテゴリー名] DATE: mm/dd/yyyy 00:00:00 ----- BODY: <p>本文本文本文本文本文本文本文<br /> 本文本文本文本文本文本文本文</p> <p>本文本文本文本文本文本文本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文本文本文本文本文本文本文</p> <p>本文本文本文本文本文本文本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文本文本文本文本文本文本文 本文本文本文本文本文本文本文本文本文本文本文本文本文本文</p> <p>本文本文本文本文本文本文本文本文本文本文本文本文本文本文</p> <p></p> ----- EXTENDED BODY: ----- EXCERPT: ----- KEYWORDS: ----- -------- AUTHOR: [ブログネーム] （以下、くり返し）
なお、いわずもがなのことだが、「エントリ」とはブログにおける１つの記事の単位を表している。
ブログの形態にもよるが、1日に何度も投稿する人は、当然、同じ日付で複数の記事＝エントリがあるわけだ。
だから、日記の（日付の）単位とは別に、投稿された記事の項目として、区分するために、分けたのだろう。
とはいえ、ブログは今世紀の産物であり、たかだか10年ほどの歴史しかないのに、こうした内輪での独特の言葉遊びは、筆者の好みではないが、今やブログ人口は数百万単位だから、それに倣うしかない。語源的には、日記に記述された記事の１つ、ということらしい。それなら「記事（Article）」でよかないか？ と思うのだが、まあ、いいだろう。些末なことだ。
（ちなみに、「エントリ（entry)」と称した本家の初期ブログシステムの「Movable Type」は現在の版では、「エントリ」の呼称を止めて「ブログ記事」と呼んでいる由である）
ということで、以下、便宜上、「エントリ」と云えば、この記事の１単位だと思ってもらいたい。
さて――、
ふだんブログを書いていても、エキスポートして、中味を検証した人でないと、こうした形式のテキストファイルは見たことがないだろう。
HTML文書を見たことがある人なら、すぐに気づくだろうが、「本文」以外には、「段落タグ」や「改行タグ」は用いられていない。
これが「MT」フォーマットの特徴でもある。また、後で、インポート用のテキストファイルを作成する際の注意点でもある。
だが、それ以前に、このファイル形式は、ココログなどのブログの大元となった「Movable Type」というブログのエントリの表示形態でもあるのだ（正確には、ココログは、Movable Typeの簡易版「TypePad」を元にしている）。
本家の「Movable Type」で、全ての項目を表示させると、このような項目の順序でエントリのタブ画面が開くのである。
以下に、ザッとした項目の説明を付しておく。
AUTHOR: エントリを書いた人のハンドルネーム
TITLE: エントリのタイトル
STATUS: エントリの公開設定（Publish：公開 Draft：非公開(下書、草稿)）
ALLOW COMMENTS: （エントリへコメントを受け付けるか受け付けないか（0：受け付けない 1：受け付ける）
CONVERT BREAKS: 本文ログの改行にあわせて改行タグを挿入するかしないか（0：挿入しない 1：挿入する ）
ALLOW PINGS: エントリにトラックバックを受け付けるか受け付けないか（0：受け付けない 1：受け付ける）
PRIMARY CATEGORY: カテゴリー名
CATEGORY: サブカテゴリー名
DATE: mm/dd/yyyy 00:00:00 エントリの投稿日時
BODY: エントリ本文
EXTENDED BODY: 本文への追記
EXCERPT: 抜粋（概要）
KEYWORDS: キーワード
さほど用語の説明は要しないと思うが、筆者固有の条件として――、
ALLOW COMMENTS:
ALLOW PINGS:
――の２つの項目（トラックバックとコメント）は、筆者の「夢の記述」ブログでは、ともに「受け付けない」設定（＝引数値「0」）にしている。こうすることで、後で、反映（再構築）する際に、最初から「受け付けない」設定が生きるのだ。うっかり「受け付ける」設定で反映すると、後で、さらに「受け付けない」設定を反映させねばならず、二度手間となる。だから、最初からこういう設定値を入れている。
だが、これは、普通のブログでは、当然、「受け付ける」（引数値＝「１」）だろう。
筆者は、別段、「現実の日記」としてのブログが書きたくて、ココログを使っているのではない。
自分の「夢の記述」を公開するのに、最も適したツールが、ブログだったから、それを利用しているだけある。
となると、ブログの機能の大半は不要だ。RSSやAtom の配信なども要らない。
だから、管理画面で、ほとんどの機能をオフにしているのだ。
MT形式でのエキスポートでも、それが反映されている。
それで、筆者のトラックバックやコメントの引数値が「０（受け付けない）」なのである。
だが、むろん、一般のブロガーは別に真似しなくてもいいから、この箇所は、「受け付ける」設定（＝引数値「1」）にされたし。
また、「EXTENDED BODY」は、エントリ本文に追記した場合の二番目の「（拡張された）本文」である。違いはよく判らない。
ココログで、ここに（あらかじめ）注釈などを入力すると、ブログ画面には反映されるが、なぜか編集画面には、出て来ないのだ。
編集が出来ない、ということは、事実上、修正も削除も利かないわけで（どうしても必要なら、一旦削除して再投稿するしかない）、一括入力の場合は、ここには記述をしない方がよいと思われる。
そうでなくとも、ブログというシステムは（特に、企業が無料で提供するフリーのそれなどは）ブラックボックスの部分が多く、ユーザの自由に設定変更できる箇所が少ない。編集不能な項目に、わざわざ記述する必要はないだろう。
（ちなみに、ココログは、有料ブログの上級＝高額になるにつれ、自由度が増す、というニフティらしい吝嗇な方法をとっている）
だから、なにか必要があって、追記する場合は、本文（BODY）内に数行の空白行を空けて、そこに追記した方がいいと思っている。まあ、個人の自由だ。
「EXCERPT」は、エントリの「抜粋（概要）」で、何も記述していなければ、システムが自動的にエントリの最初の何行分かを挿入する由（ただし、今回のように一挙に入力する際には、そうはならないだろう。あくまでも、日常的に入力した時の話である）。一括入力の場合、自分でエクセプトを作成するのも面倒だし、筆者の目的にも合わないので、無視した。Atom などの関係で必要な人は自分で工夫されたい。
「KEYWORDS」項目も、実は、よく判らない。ブログを設定する時に、そのブログ独自の「キーワード」を入力する項目があり、それが自動的に入るような気がするが、違うのかも知れない。エキスポートした際に、何も出力されないからである。
これは、たとえば、「カテゴリー」項目などは、未入力だと「未分類」との注記が入るが、それ以外の項目は、エキスポートした時に、入力されていなければ、何も出力されないのだ。いずれにせよ、筆者は何も入力していない。
SEO とやらで、自分のブログを検索エンジンに対し「最適化」して人気ランクやカウンタ数を稼ぐような、シャバっ気のある人間以外は関係ないと思っている。そういうことが好きな／必要な人は自分で調べてもらいたい。
いずれにせよ、筆者は、RSSやAtom の利用をオフにしているので、こうしたデータ収集用の機能や項目は無用である。
RSS は本来、XMLで記述されたサイトの構成要素を指すコトバだったが、今では単語単位で、情報収集するツールだと見なされているようだ。Atom は（単語単位ではなく）コンテンツ自体をフルテキストで配信するものである。RSSの規格が乱立したため、その代替として作られたともいうが、筆者には関係がない。
（あるいは、ブログ内検索の際に、これが有効になるのかも知れないが、筆者はブログ内検索も必要としていない。もし検索の必要があっても、その時は、全エントリをエキスポートしたテキストファイルにGREP をかけるだろう。筆者のような人間（＝Web1.0どころか、いまだにＭＳ−ＤＯＳ時代に生きている ＩＴ原人）には、その方が早いのである(^^;)）
なお、「公開」設定項目の「STATUS」は、実際の「引越し」作業では、こう記述していても、ある種のブログでは、「未公開」がデフォルト設定となる由である（ココログではない）。
「未公開」状態では、いかなる内容も画面に表示されない。そもそも、その時点で、システム内では、エントリを表示するHTML文書が生成されていないのだ。
ブログとは、その実体は、ひじょうに複雑な相互に入り組んだコンテンツ・マネージメント・システム（CMS）であり、ユーザがブラウザで見る画面は、そのシステムが自動的に吐き出した仮りのHTML文書でしかない。
東浩紀氏のいうところの「データベース」から任意に抽出され、消費される断片（＝１ページ）なのである。
だから、「未公開」の状態では、まだ、HTML文書は作成されないわけだ。
管理画面で「公開」設定にして、ブログの「再構築」により、それが全ページに「反映」されて、初めて個々のエントリ（HTML文書）が作成され、ユーザの目に触れるのである。
「Movable Type」などを自分でシステムから構築する人間以外は、ブロガーの大半は、アリモノのブログサービスを、中味がどうなっているかも理解せず（しないでもいいので）、ただ使っているだけだろう。しかし、引越しとか、そういう事態となった場合、その構造がどうなっているか、あらかじめ知識として憶えておいた方がいいことがあるかも知れない。
まあ、しかし、別段、中味など知らなくても、Web2.0 時代のツールは使えるので、気にならない人は気にしないでよい。
■ 置換作業
● エディタによる一括置換
筆者が記していた元の夢の記述は、大体、以下のような形式で書かれていた。むろんテキストファイルである。
●２０００年１月３１日（水）Reve[改行] [改行] 本文本文本文本文本文本文。[改行] 本文本文本文本文本文本文本文。[改行] 本文本文本文本文本文本文本文本文本文本文本文本文本文本文（実際は改行なしで続く） 本文本文本文本文本文本文本文本文本文本文本文本文本文本文。[改行] [改行] 本文本文本文本文本文本文。[改行] 本文本文本文本文本文本文本文。[改行] 本文本文本文本文本文本文本文本文本文本文本文本文本文本文（実際は改行なしで続く） 本文本文本文本文本文本文本文本文本文本文本文本文本文本文。[改行]
つまり、冒頭に、日付があり、それは、夢の記述であることを明示的に示すために「Reve」という（夢を意味するフランス語――実際はアクセント記号が入る）単語で締めた、1行があり、空白行のあと、本文がつづく。
本文も、意味を考えて、一つの夢のシークェンス（＝同じ視点から見た「情景」）を1段落としている。
その中でも、「情景」が変われば、改行は入れるが、空白行は入れない。
シークェンス（視点）が変わった段階で、そこに空白行を入れて、改行する。
なぜ「情景」よりも「視点」の変化を重視するか、というと、夢の記述において「見たまま」を原則としている筆者にとって、「視点」の方が、夢のなかで絶えず流動し、変容する景色よりも重要だからだ。視点は、いつもの現実の自分と同じ男性の一人称から夢それ自体（＝神の視点）まで、さまざまに変位する。時にはジェンダー的に女性の視点になることもある。その変化を際だたせるために、改行し、空白行を入れるのである。
これらは、夢の記述を始めた当初に決めた筆者独自の「規則」だが、この規則性が、今、役立っている。
ちなみに、筆者の「夢の記述」の「規則」ないし「方針」は以下のものである。
解説めいたことは一切、記述しない。というか、夢を「解釈」するあらゆる視座を排しているのだ。
ただ、一度、目醒めて、時系列的に違う夢の記述をするときだけ、「【一度目醒めて、違う夢。だが、同じ時間、同じ空間】」といった「注釈」を入れることがある。一度、目醒めると、次の夢は、連続性が断たれる。それを考慮しての注記だ。
これも、たいがい、夢の記述内に組み込んでいるので、項目上の問題はない。
筆者の「夢の記述」は、「夢判断」の材料を書いているわけではない。
ましてや、その前後にどういう出来事があって、それを夢の検閲官が検閲して、こうなったのだろう、といった俗流フロイディズム的な理由も説明も一切、記述しない。さらには、その夢を見た後、その日、その夢が「正夢」となった、かくかくの出来事があった、などという記述も（たとえ、あったとしても）しないように心がけている。
「夢日記」を付ける人は、検索してみると意外に多く（「はてな」などは、その項目にダイアリークラブを１つを割いているほどだ）、そのうちの少なからぬ数が、夢から「何か」を読み取ろう、としているようである。さらには夢が自分の人生における「指針」であるかのように思っている人さえ、いる（らしい）。
だが、筆者は、そのようなことは考えないし、そんな記述はしない。「精神世界」に遊ぶ人は、夢が現実へと与える影響を思うわけだろうが、筆者にとって、「夢」とは、現実の生活とは切り離された世界で、もう１人の自分が体験する、「幻の現実（＝幻実）」だと考えている。そこに解釈は不要だし、物欲しげな「教訓」など、入る余地は全くない。夢はただ、夢として、そこにある。それだけだ。
だから、筆者も、ただ単に、見たままを記述するだけである。それが自分なりの夢の記述の方針だ。
むろん、原則とか方針とか云っても、「心がけている」程度のものだから、厳密に全てそうであるわけではない。
あくまでも規則であり、例外のない規則はない。
とはいえ、こうした方針では、そのためにブログを利用しても、筆者には、そこで、上に記した以外の要素は必要がないのだ。
さて――、
こうした記述の論理資源は、デジタル化された分だけでも、ザッと15年間分ほどある。テキストファイルで、約１MB弱だ。
一挙にアップロードすれば、コンテンツとして、まあ、何とか、まとまった分量になる、と判断した所以でもある。
しかしながら――、
こうした「普通の叙述」の文章を、「MT」形式に変換するのは、大変だと思われるかも知れない。
だが、世の中には、正規表現による一括置換、というエディタ機能がある。
エディタに関しては、拙サイトの他のページで説明しているので、ぜひ、その該当箇所を披見ねがいたい。
一言だけ、この種の作業に際しては、エディタは必需品である、と云っておこう。Word など全く役に立たない。
筆者は、ふだんは、ＷＺエディタを愛用しているので、それに基づいた説明をするが、最終的には、古いＷＺでは対応できない文字コードの仕様（ユニコード）があったため、そこだけ、「秀丸」を使っている。普通のユーザは、最初から秀丸を使うことを推奨する。
秀丸は、オンラインソフト（シェアウェア）ながら、100万のダウンロードユーザを持つ怪物的なエディタである（Windows 版のみ）。同じシェアウェアでは、ＱＸやＭＭなども名が高いし機能的にも優れているが、なんといっても使っている人数が多いのがベストだ。
市販のマニュアル本も多いし、現在、もっとも普及しているエディタだろう。ＷＺは残念ながら（商用ソフトなのに）、そこまでのシェアはないので、ユーザは秀丸を使うのがよいと思う所以だ。
秀丸は、そのマクロには、すこし特殊で、説明しづらい箇所があるのだが、普通に正規表現を使って一括置換するぶんには、問題がない。
それで、置換作業だけなら、エディタ一般として、汎用性があると思う（秀丸は→ここからダウンロードできる）。
だから、ここはＷＺで行なった事例で説明するが（すなわち、以下、エディタと書かれていれば、特に注記がない場合は、ＷＺエディタのことである）、一応、秀丸でも動作確認しているので、秀丸でも同様の結果が得られるはずである。
（ただし、ユーザの便宜を図って、途中、代表的な置換作業だけは、秀丸でのスクリーンショットを用いて解説した）
ついでながら、「正規表現」の説明も省略する。
拙ページに、簡略な説明を書いているので、そちらを披見ねがいたい。
で、正規表現を使って、どういう置換の仕方をするか、というと――、
まず、云っておきたいのは、「正規表現」とは、文書を「文字列のパターンデータ」として処理する、ということだ。
文書内容は一切、関係ない。どういう意味だとか感情がこめられているとか、全く排したところで成り立っている。
そこで文字はデータであり、つまり、Excelで数値をあつかうように、エディタでは、文字をデータとして扱うのである。
そこで、問題となるのは、「パターン」である。
文字列の中に、どういう同じパターンがあるか、または異なるパターンがあるか。
別なコトバで云えば、「ユニークネス（一意性）」があるか。そこに着目しなければならない。
筆者が、夢の記述を、１つのテキストファイルに、ただ「のべたら」にコピーしていったら、それは、どこからどこまでが１つの日記の単位だか判らない。段落数とかも当てにはならない。改行の数もまちまちだから、これもダメである。
それが文字列でなく、たとえ数値であっても、不定形なデータというのは、マシンには扱いにくいものなのである。
不定形なデータを、どこで区切るのか。どこにパターンを見つけるのか。そこが問題だ。
それで注目したいのは、上図で、日付の前におかれた「●」マークである。これが、日記の１単位の始まりである。
だから、これを中心に、変換が可能となる。
（ただし、日記本文内に、同じ「●」マークが使われていない、という前提である。もしあれば、別な記号を考えなければならない）
ただし、問題は、そう簡単ではない。
筆者も長いこと夢の記述をしているため、この「●」印を付けたり、付けなかったり、また、日付も、全角だったり半角だったり、その時々において、元データは、けっこう、いい加減だったりする。こうした「ブレ」は、「前処理」として、統一しておかねばならない。
マシン（＝エディタ）は、愚直である。こうと決めた方式に従って操作すれば、どんなに（人間がやるなら、気が遠くなるような作業でも）やってくれる。だが、ミスが１つでもあれば、結果はメチャクチャになる。だから、「前処理」は、非常に大切で重要なのだ。
● 秀丸エディタ
エディタを使えば、そうした前処理も統一も簡単である。
まず、日付があっても（日付がない記述は、さすがに「日記」としては考えられないので、条件としては無視できる）、「●」印がない場合は、１つのファイルに、1年分だけ格納している場合は、たとえば、「２０１０年」とあるならば、行の冒頭に、「２０１０年」が来る場合が他に考えにくい。だから、これは「ユニークネス」（＝一意的なもの）と見なしていいだろう。
その場合は、検索文字列に「２０１０年」と入れて――、
置換文字列を「●２０１０年」にして一括置換すれば、一瞬にしてカタがつく。
もし、冒頭以外の場所で、そういう年号を使っていると、そこにまで「●」印が入ってしまうので、そういう時は、正規表現を使う。
すなわち、検索文字列に「^２０１０年」と入れて――、
置換文字列を「●２０１０年」にして――、
置換の方式をデフォルトの「基本」から「正規（表現）」に換えて、一括置換すれば、冒頭に年号がきている箇所だけ換わる。
半角の山形記号「^」は「キャレット」といい、正規表現で論理行（＝段落行）の冒頭を表す。「論理行」とは、見かけの「表示行」と異なり、１つの改行コードがあるまでの段落を指す。
また、半角で年月日を入力していた場合は、これもエディタ（ＷＺ）の「編集」＞「変換」＞「半角文字と全角文字の変換」機能で容易に全角に直すことが出来る。
メニューの「編集」から「変換」を選び、クリックすると、ウィンドウが開く。
「半角文字と全角文字の変換」という項目がトップにあるので、ＯＫボタン押下（別の項目にラジオボタンのチェックが入っていたら、付け直す）。
一覧から（デフォルトでは、全部「そのまま」なので）「数字」の項目だけ「全角へ」に換えて、ＯＫボタン押下すれば、そのファイル内の全ての半角数字が全角に換わる。むろん、タイトルに使った年号以外の数字も換わってしまうのだが、ブログにアップするのに、それほど問題もないと思われるので、構わないだろう。不都合があれば、範囲指定して、範囲内だけの置換も可能だ。
秀丸では、もっと簡単に、「編集」＞「変換」＞「英数字のみ全角に」である。
前処理がすんだら、もう一度、全項目を見直す。いざ一括置換をやった場合、間違えると後が大変だからである。
すると、本文に使った「Reve」が、エキスポート文書のカテゴリーやサブカテゴリーにも入力されていることが判る。
この本文の「Reve」で終わる日付行は、1段落とみなすので、末尾に段落タグの終端タグ「</p>」タグを入れる予定だ。
だが、一括置換すると、本文以外のカテゴリー箇所にも、「</p>」タグが入ってしまう。
これでは不都合なので、まず、一番最初の置換を、この「Reve」箇所に行なうことにする。
（このように、置換作業は、順々にやっていくのだが、その「順序」が重要となる。本稿では、そこまで述べないが、もしこれらをマクロで、何度も一括処理するような高等な段階になったら、一層、作業の順番が重視される）
検索メニューから「置換」を選び――、
「検索」文字列の窓に「Reve」を入れて――、
「置換」文字列に「Reve</p>」を入力。
「すべて置換」で一括置換になる。
秀丸でも同じで、「検索」＞「置換」＞「全置換」」で一括置換される。
しかしながら、これは、筆者の例なので、あいにく汎用性がない。
他の人は、どうしたらいいのか。
だが、それが「日記」ならば、たぶん、同様に冒頭には、「日付」があると思われる（日付がない日記は、ちょっと考えられない）。
そして、日付の後には（丸カッコで囲まれた）「（曜日）」があるのではないだろうか。
そして、その形式の曜日つきの日付の記述は、本文には、おそらく、ないだろう。
だったら、そこをキーにして、検索文字列に「曜）」を、置換文字列に「曜）</p>」を入力して、一括置換できるだろう。
この場合、曜日を囲む丸カッコが、全角か半角か、どちらでもいいが、「統一」する必要がある。留意されたい（全角文字と半角文字は正規表現では峻別されるのだ）。
さて、次は、「●」である。
これは、たまたま、筆者の場合、そうだっただけだが、よい「ユニークネス」なので、推奨したい。
「●」でなく、本文の中には使っていない記号なら、なんでもよい（■とか◆とか▼とか）のだが、とにかく、それをキーにして、日記の記述の1日分の単位が区分されるのである。そして、ブログの画面にあっても、そう見映えも悪くならず、見づらいことはない。
具体的には（以下、ユーザの便宜のため、「秀丸エディタ」での用例を図示する）――、
「●」の前に、「AUTHOR」から「BODY」までの文字列が入ればよいわけである。
だから、下図のような（日付冒頭に「●」がある）日記の「原文」があったとして――、
メニューバーから「検索」を選ぶ。
すると、下図のようなドロップダウンメニューが表示されるので、「置換」を選択する。
下図のような「置換画面」のコンボボックスが表示される。
ここでは「正規表現」を使うため、ＷＺエディタでは、「基本」でよい（＝秀丸でのデフォルト＝何もしないに相当）が、秀丸では、きちんと「正規表現」の項目にチェックを入れる。
また、「大文字／小文字の区別」にも、チェックを入れておこう。
ほかの項目は、そのままでいい（一括置換は、思わぬ置換結果を招くことがあるので、不安な人は、「置換の前に確認」にチェックを入れてもいいだろうが、大体、間違えたら、その直後に気づくので、その際は、ツールバーの「やり直し」または、CTRL + Z のショートカットキーで、「元にもどす」。
最初の編集段階まで、「元にもどす」ことは可能だ。
だから、それほど気をつかわなくてもいいと思う。
上図のように――、
検索文字列に「●」を――、
置換文字列に「AUTHOR: noirseuil\nTITLE: ★★\nSTATUS: Publish\nALLOW COMMENTS: 1\nCONVERT BREAKS: 0\nALLOW PINGS: 1\nPRIMARY CATEGORY: Reve\nCATEGORY: Reve\n\nDATE: mm/dd/2000 00:00:00\n-----\nBODY:\n</p>●」を――
入力して、「全置換」（＝一括置換）を行なう。
文字列の間にある「\n」は「改行コード」の正規表現である。
結果は、下図のようになる（赤い囲みが、置換された文字列）。
「TITLE」項目を「★★」にしているのは、後で（手作業で）標題を入力するのに、判りやすい（あるいは、間違えないようにする）ためである。
トラックバックやコメントは、「対応する」の値「1」にしている。
「●」の前の<p>（＝段落開始タグ）は、一気にここまで置換した方が、あとの処理がラクだからである（本当は、図では、その行末の「Reve」の後に</p>（段落終端タグ）がないが、あらかじめ、そちらを先にやっておく。でないと、カテゴリー内に「Reve」が先に入ってしまい、面倒になるからである）。
この場合、エントリの作成年月日の箇所は、いつも同じではない。
「DATE: mm/dd/yyyy 00:00:00」の箇所である。「yyyy」には、その日記の年を入れる。この場合、上図の例では、2000年の記述なので、「2000」にしている。「mm/dd」は、英語式の表記らしいが（「月／日／年」の順になっているので、あとで月と日を間違えないように留意する）、さすがに、ここまでは、日付の取得が出来ない（ひょっとしたら、秀丸の手練れのマクロ使いなら、可能なのかも知れないが、筆者には、その技倆がない）ので、手作業で、後から、入力し直す。
さらに、この後、今度は、新しく入力された「AUTHOR」の箇所に注目する。
これも、「ユニークネス」な（本文では決して使われないだろう）文字列である。
これをキーとして、本文の後に付ける文字列――「EXTENDED BODY:」などに一括置換する。
「AUTHOR: [ブログネーム]」を検索文字列にして――、
「-----\nEXTENDED BODY:\n\n-----\nEXCERPT:\n\n-----\nKEYWORDS:\n\n-----\n\n\n--------\nAUTHOR: [ブログネーム]」を置換文字列に入力し、一括置換する。
この場合も、ＷＺでは「基本」で、秀丸では「正規表現」にチェックを入れる。
ただし、これだと、一番最初のエントリの前に、余分な末尾用の文字列が加えられ、また、一番最後のエントリの後には、末尾用の文字列が無い、という結果になる。
だから、その箇所には、前者は削除し、後者は、コピー＆ペーストで該当箇所を貼り付けてやる。
さらに、エディタで一括置換が可能な項目としては――、
トラックバックやコメントを「受け付ける」か「受け付けない」かの数値がある。
デフォルトでは、ふつう、「受け付ける（数値＝1）」となっている。大半のブログを書く人はそうだろう。
だが、筆者は、自分の夢の記述に他人がコメントを寄せたりするのを許容する気はないので、ここは、「受け付けない（数値＝0」にする。
もし、筆者と同じようにする場合、これをエディタでやるには――、
検索文字列に、「ALLOW COMMENTS: 1」を――、
置換文字列に「ALLOW COMMENTS: 0」を入力し、一括置換。
また、検索文字列に、「ALLOW PINGS: 1」を――、
置換文字列に「ALLOW PINGS: 0」を入力し、一括置換する。
これで、トラックバックやコメントを「受け付けない」設定になる（普通のブログを書く人は真似しないでよい）。
さらに、段落の終端タグ「</p>」も、エディタでの一括置換での入力が可能だ。
さすがに、段落冒頭の開始タグは、目で見て判断しないと付けられないが、終端タグの方は、規則性がある。この「規則性」に着目することが、一括置換では大事であり、間違うとエライことになるが、きちんと見定めて行なえば、後の処理が格段にラクになる。
段落の終端タグは、たいてい、文章の終わりは、「。」（句点）で終わっているはずであり、さらにその後に空白行が１つ空いている。
これを正規表現で表すと、「。\n\n」となる。「\n」は改行を表す正規表現だから、空白行が続く行は、それが2つ連続するわけだ。
すなわち、エディタでは――、
検索文字列に、「。\n\n」を――、
置換文字列に「。</p>\n\n」と入力して、一括置換すればよい。
全部の文章の末尾が「。」であるとは限らないだろうから、これでは完全ではないが、ほとんどの段落終端タグは、これで付けられる。
例外箇所は、むろん、あとで出てくるだろうが、それは（数も少ないので）手作業で処理すればよい。
以上で、インポート用のテキストファイルの整形は終了である。
ただし、もう１つ最後に保存する際の約束事がある。
ココログでは、基本的に文字コードが（ユニコードのエンコードの１つである）「UTF-8]形式を採っている。
だから、インポートする際にも、文字コードをそれに合わせる必要があるのだ。
ふつうにShift-JISの文字コード文書にして、インポートの際に、ドロップダウンメニューから、「日本語（Shift-JIS）」を選んでもいいような気もするのだが、この種のことで手を抜くと、後で、ろくなことがないので、キチンと「UTF-8」形式で保存をした方が無難だろう。
筆者が秀丸を使ったのは、ここである。
ＷＺの旧版では、ユニコード対応ではなく、新しいＷＺは馴染みが薄いのだ。
秀丸は、現在、ver.8 だが、筆者はver.7を使っていて、別段、問題はなかった。
むろん、ユニコード対応で、保存する際に、文字コードのエンコードの種類を選べる。
上図のように、ファイル＞名前を付けて保存＞ の後に、ファイル名を聞いてくる。
このコンボボックスで、「エンコードの種類」が選べる。
ドロップダウンメニューから、「Unicode(UTF-8)」を選択して、「保存」ボタン押下すれば、それでＯＫである。
以上で、インポート用ファイルのエディタの置換機能による作業は完了である。
● 手作業による改行
エディタによる一括置換は、限界があり、これだけでは、インポート用ファイルには不足である。
これから先は、手作業となる。
まず、HTML文書に馴染みがない人には、段落タグと改行タグだけ、憶えてもらう。
段落タグとは「<p> </p>」であり、改行タグとは「<br / >」である。
前者は囲みタグで、２つのタグ（開始と終端）で囲まねばならない。後者は終端タグだけでよい。
段落タグは、１つの文章のまとまりを明示的に示し、自動的に、その後は、空白行が入る。
HTML がver.1.0 の頃には、われわれは、このタグを「間に空白行を入れる改行タグ」だと思っていた。
開始タグだけで終端タグも入れなかったくらいだ。今は違う。段落タグだから、必然的に、その後には、自動的に空白行が入るのだ。
改行タグは、ただ単に文章を改行する（1個だけなら、空白行は入らない）。
ココログは、外国製の「Movable Type」というブログシステムの、簡略版サブセットである「TypePad」ブログを元にしている。
そこでの、これは、記述文法だと思えばよい。HTML を基にしているが、もっと簡単だ。たった2つのタグだけなのだから。
１つの段落は、必ず、段落タグ「<p> </p>」で囲む。
そうすれば、自動的に、その次の段落との間に、空白行が1行、入る。
改行は、画面での見やすさを考えて、長文の場合、時々に入れたり、意味内容から、入れることもある。
間に空白行は入らないが、改行されるので、そこで１つの文章の区切りである、と（読み手には）判る。
よく、ブログで、長い間をとって、効果を出している人がいるが、あれは、間に空白スペースを空けて書いている。
ココログの編集画面で、HTMLのタブ画面があるので、それを参照すれば判る。
その結果が、文法的には、この段落タグとなる。対になった囲みタグを２つ使えば２行の、３つ使えば３行の空白が空く。
奇しくも、夢の記述をしていた筆者と同じことになったのだが、それは好都合なだけで、基本原則は、上記の通りである。
ユーザは、そうしたことを踏まえて、あとは、手作業で、段落タグと改行タグを入れなければならない。
とはいえ、ここでも、エディタの機能が使える。
筆者は、まず、「<br /><p></p>」というタグの連続を「ｂｐ」（全角英文字）で単語登録した。
それを、本文が終わった後の空白行と波線の間に入力する。「ｂｐ」と打鍵して変換すれば「<br /><p></p>」となる。
どのみち、波線のすぐ上には、「<p></p>」という段落タグで空白を入れることになるので、この位置が最適だろう。
そうしておいて、まず、カーソルキーで改行タグの「<br />」を範囲指定して「切り取る」（CTRL + X のショートカットキーが使える）。
本文の、改行を必要とする箇所に、右手でマウス操作で移動させつつ、該当箇所にカーソルを宛て、左手で、CTRL + V キー押下で、次々に改行タグを入力してゆく。
この作業は、エントリの冒頭部分から下に下りていくようにやった方がよい。
間違いが少なくなるからである。
次に、カーソルキーで段落タグの終端タグ「</p>」を範囲指定し、これは「コピー」する。
そして、段落の終わりの箇所に、これまた、入力してゆく。数的には少ないはずである。
最後に、段落タグの開始タグ「<p>」を同様にして入力する。
１つのエントリでの作業が終わったら、エディタ画面を最大にして、よく見てチェックする。
必ず、見落としがあるはずである。
エディタは機械だから、一括置換での間違いは（あらかじめ入力した文字列に過ちがなければ）ありえないが、人間の目と手の作業は、必ず、間違いを孕んでいる。じっくり検証されたい。
特に、段落タグの間違いがあると、間が詰まってしまうので、後で編集画面での修正が必要となり面倒である。チェックは入念にやることだ。
人間の目では、やはり見逃すミスは、これもマシンに代行させる手がある。
エディタの検索機能で、定型的な、変更しなければいかない文字列を、検索するのだ。
代表的なものとしては、まず、タイトルを代入すべき「★★」がある。
あと、投稿日時の「DATE: mm/dd/yyyy」も、年号はあらかじめ入力しているからいいとして、「mm/dd」の箇所が、意外と忘れがちなので、検索文字列を「mm/dd」にして検索する。
あと、正規表現を使った、行末の「。」の後に、然るべき終端タグがない箇所を調べるには、検索文字列に「。$（＝句点の後、改行コード）」でやればいいように思うが、タイトル項目の行末に「。」を入れている場合があるため、これは実用的ではない。
以上のような検索でエラーが皆無なら、それ以外を目と手でチェックするとよいだろう。
これを、エントリ単位ごとに行なう。
全ての作業がすんだら、そのファイルを秀丸で、「UTF-8]形式で別名保存する。
（たとえば、元ファイルが「1999OUT.TXT」だったら、「1999OUTex.TXT」とかの別名にする）
以上で、インポート用ファイルは完成である。
■ ブログへのインポート作業
この先は、ココログ独自の仕様なので、他のブログでは、勝手が違うはずである。
だが、インポート／エキスポート機能を備えたブログなら、だいたい同じような画面になると思われるので、一応、記述しておく。
他のブログ・ユーザでも、参考になれば、幸いである。
下図が、ココログにログインした際の管理トップページである。
（注意：ブログは、運営する企業が、しょっちゅうサイトデザインを換えることが多いので時期によって画面が違うことがある。以下の操作も数年前は別な画面から行なっていた。もし、変わっていたら読み替えること）
現時点（2010.10.20）での方法を述べる。
まず、管理トップページから、「ブログ」タブ画面に切り替える。
「ブログを書く」の下に「その他の操作」内に折りたたまれている項目をクリックしてドロップダウンする。
メニューから「ブログの管理」を選択しクリック。
「ブログの管理」画面で、「管理」タブ画面を開く。
上部のメニューから「読み込み／書き出し」を選んでクリックする。
（または、右側の「便利メニュー」から「記事の読み込み／書き出し」をクリックする）
下図の、「読み込み／書き出し」画面で、「読み込む」項目で作業を行う。
「ファイル」は「コンピュータ上のファイル」にチェックを入れる。
「参照」ボタンをクリックすると、下図のような画面が開く。
階層をたどって、自分が作成したファイルを選択する。
「ファイル」項目に、作成したファイルが入る。要確認のこと。
「文字コード」は、上述したように、キチンと秀丸でユニコードに対応していれば、デフォルトの「Unicode(UTF-8)」を選ぶ。
準備が整えば、下の「読み込む」ボタン押下。
別ウィンドウが開いて、「読み込み」と「反映（再構築）」が示される。作業は自動的に始まり、終わる。
終われば、別ウィンドウは閉じる。
念のために、「記事一覧」を見るか、あるいは、「ブログを表示」ボタン押下して、ちゃんと反映されているかどうか確認する。
反映されていれば、成功である。
最後は、人間の目と手に頼る以上、ミスがあるかも知れない。その場合は、通常の編集と同じように、該当エントリを編集すればよい。
以上で、一度に大量の記事をブログにアップロードし、再構築する手順は完了である。