「和易ゐ記（わいうぃき＝和文簡易 Wiki 記法）」とは，日本語向け「軽量マークアップ言語」的機能を持つプレーンテキストの記述規則。当サイトの記事は同形式で記述され，HTML に変換して表示している。

　この記事では，「和易ゐ記」考案に至った経緯などについて述べる。

　ウェブ記事の規格である HTML のように，文書の構造……つまり，どこが「見出し」で，どこが「箇条書き」の項目で，どこからどこまでが「引用」か……などを示す記述法を「マークアップ言語」と言う。

　サイトを立ち上げた当初は，その HTML タグを手入力してウェブ記事を作成していた。直接編集できなくもないが，いちいちタグを書き込むのはたいへんだし，何より，「本文」のあちらこちらに HTML のタグが「散在」しているわけで，そのタグを壊さないよう，合間をぬって本文を編集するのは，非常にやりにくい。
　ただ，それはどうやら日本語に限らず，「マークアップ言語」発祥の欧米でも同じ感覚だったのか，HTML に代わるものが考えられるようになっていった。

◆ 「マークアップ言語」はどれも英文向け

　そこで登場して来たのが，HTML より記述を簡単にした「軽量マークアップ言語」と呼ばれる記法。（一般的な）Wiki や Markdown など，いろいろなものが出て来ることになる。
　ただ結局どれも欧米生まれで，英文の記述に特化されていて，日本語で記事を書くにはいろいろ難点も感じ，少々使いづらく思っていた。
　英文向けマークアップ言語で日本語の記事を書く時に何が問題になるかというと，スペースと改行の扱い。英文でスペースは「単語の境界」という扱いだから，単語や文の境目には必ずスペースが入る。たいていは，英文の一部を強調したいとか，下線を付けたい時などは，単語単位のことがほとんどで，「単語の中の一部」にそうした装飾をすることなどはまずないため，その「スペース」の区切りにマーク付けできる。
　たとえば，文章の一部を「強調」する意味で「斜体」にしたい場合，Markdown の記法では以下のように記述する。

   This is an apple. *Not a pineapple!* You see?

　Markdown の記法で処理されると，Not の前にある ＊ から ! マーク直後の ＊ までの中央の文が斜体表示で出力される。前後にスペースがあるため，挟まれた文が何か特別であることが，パッと見である程度わかる。なお，処理により ＊ は取り除かれ，出力されない。

　一方，日本語の場合，極端に言えば「スペースは不要」。文章を書く時，ワープロであろうと原稿用紙であろうと，句読点の直後に必ず空白を置くようなことはしない。句読点の直後にスペースがあってもなくても，そこが文の終わりや区切りだと解釈するはずだ。ましてや，文節の区切りにいちいち空白を入れたりもしないだろう。「ポエム」でもない限り。ところが，日本語で，上記と同じように強調したい部分を分かり易くしようとして前後にスペースを空けて記述すると，処理した結果の HTML にも文の前後にスペースが空いてしまう。英文向けマークアップ言語では，そうしたスペースも単語や文の境界として文中に普通に存在するので問題はないが，スペースがあまり深い意味を持たない日本語で所々に空白が空くと，おかしな感じになってしまう。

◆ 和文と英文で決定的に異なる「改行」の扱い

　英文の場合，改行の扱いもスペースとほぼ同じ，つまり通常は「単語の境界」の扱いになる。もし，人間が記述した元のファイルよりも，ブラウザなどで表示する際の１行の文字数が多い場合，「改行」の部分は「単語の境界」として，１つのスペースで置き換えられて（つまり改行ではなくなって），それを挟んで次の行の最初の単語が前の行の後部につながって表示されるだろう。英文のウェブ記事でも，閲覧中のブラウザの幅を広げると，下の単語が次々と「スペースを１つはさんで」上の行の後部につながって全体の行数が減ることがあるが，これも「英文の扱い」に沿った処理だ。
　一方，日本語では，前述のとおり「スペースで区切る」という法則がないから，本来は「改行」も要らないはずだ。とは言え，メールを書く際など，「読み易くするために」適宜改行を入れることは普通にする。
　ところが，マークアップ言語の「英文の法則」と同じ処理で日本語が扱われると，読み易くするために改行した箇所もスペースで置き換えられ，結果の HTML にも所々に空白が空いてしまうことになり，「キレイじゃない」感じがする。また，日本語でも「読み易くするための改行」は「文節の区切り」ですることが多いが，時として，原稿用紙のように１行を決められた文字数で単純に改行することもあり，その場合は単語の途中での改行も起こりうる。それを日本人が読むぶんには，前の行とつなげて読むのが普通だから問題ない。が，述べたようにマークアップ言語の処理では，その単語の途中で改行した箇所も，英文同様「単語の境界」扱いにされるだろう。それで単語の途中に入れた改行がスペースに置き換えられて出力されると，その単語が検索に合致しなくなってしまったり，また「熟語」の漢字の間で改行されていて，そこがスペース扱いされると，「音読ソフト」で読ませた時に「熟語」としての読みが違ってしまうなどの不都合も生じうる。

　英文の場合，「スペース」はほぼ確実に単語境界だから，スペースがあった場所で改行したり，また改行だった箇所をスペースをはさんで前の行とつなげる処理をするマークアップ言語でも「単語境界」としての役割は同じなので問題ないだろうが，日本語では，単語境界にスペースを入れる規則はないし，逆に「書式（１行の文字数）」を優先して単語途中で改行する可能性もあるから，述べたような扱いをする既製マークアップ言語で処理するには不都合も多い。
　そんなわけで，日本語向け「軽量マークアップ言語」の必要性を感じるようになった。

　述べたような理由から，簡易的にでも「日本語に特化した軽量マークアップ言語」的なものが作れないかと考えた。当初は，全てをプレーンテキストで書いたものを，前の行と後ろの行をスペースを入れずにつないで，自動で HTML のタグを入れるくらいでも，編集はすごくし易くなるのでは……その程度の「効率化」のつもりでシステムを考え始めた。それが，「和易ゐ記」の出発点。
　ただそのうち，やはり「見出し」や「引用」部分，また「箇条書きの項目」など，文書構造を明確にしておきたい部分もあったため，それらの記述規則を追加し，そこに「リンク」などの記述の仕方も盛り込んだものが，現在サイトで使用している「和易ゐ記」になる。
　とは言え，あくまでも個人的に考えたものだし，この記事を書いている時点ではまだまだ発展途上な面も多く全体の仕様が固まったわけではないので，詳しい記述規則については別記事とし，そちらを適宜更新していくことにしようと思う。

　当サイトでは，その「HTML 化」の加工を，サーバ上で行なうようにしてみた。つまり，サーバに「和易ゐ記」で記述したプレーンテキスト形式ファイルを置いて，それを HTML 化して送信するような仕組み。
　というわけで，当サイトでここ最近に作成している記事は，多くはその「和易ゐ記」で記述している。つまり「プレーンテキスト」であり，それをそのままアップロードしただけ。HTML でブラウザに表示される記事も，サーバに「（HTML 形式で）保存されているわけではない」ことも多い。
　具体的には，要求された URL の末尾に拡張子がない場合，該当するファイルが存在せず，代わりにプレーンテキストの拡張子（.txt）がついたファイルが同じディレクトリ上に存在したら，それを「和易ゐ記」の法則により「サーバ上で」HTML 化して，ついでに目次や関連記事のリンクなどを付加して，送信するようになっている。
　そのため，もしウェブブラウザで，筆者サイトをオンラインで読んでいて，URL に拡張子が付いていなかったら，末尾に“.txt”を付加して読み直すと，たいていは元の「和易ゐ記」で記述したプレーンテキストが読める。もちろん，今読んでいるこの記事も同様。
　だから，「『和易ゐ記』ってどんな記述方式だよ？」と思った時は，前述の「URL 末尾に“.txt”を付加する」方法で元のプレーンテキストファイルが読める場合が多く，具体例を直ぐ見ることができる。
　場合により拡張子部分が“.html”などで，明示的に HTML ファイルを要求している時も，該当ファイルがなく，代わりに拡張子が“.txt”のものがあれば，同様な対処をするようになっている。
　なお「和易ゐ記」では，UTF-8 の文字コードが標準であるため，もしプレーンテキスト表示で文字化けしたら，ブラウザの文字エンコードの指定を，UTF-8 か UNICODE に設定して欲しい。ただし，一部ブラウザではこの指定ができないものがあるので注意。詳しくは，以下を参照。

　そんな感じで「とりあえず」作った「和易ゐ記」システムだったが，試験的に運用しているうち，サイト管理やバリアフリーにも相乗効果的な面があることが分かってきた。
　「和易ゐ記」で記述したプレーンテキストのファイルを，サーバ上で HTML に変換して表示できるようにすると，元になるテキストファイルのアップロードだけで，「フォルダ（ディレクトリ）」による階層化されたファイルシステムのサイト管理が，シンプルかつ柔軟に実現する。すると，ちょうど CMS のような役割としても使えることに気づいた。
　 CMS とは「Contents Management System」のことで，ウェブ記事などのデータをサーバ上で管理し，サイトを構成するソフトのこと。
　また，「和易ゐ記」でアップするものはプレーンテキストのファイルであるため，「プレーンテキストで読みたい」という視覚障害者などには，ほぼ何の手間もなく，プレーンテキストで提供できることになる。つまり，容易に「バリアフリー」への配慮が実現した感じになった。

◆ 重たい既存 CMS

　CMS として有名なのは「ワードプレス」などだが，結局それらも欧米産の英文向け CMS だから，どれほど日本語の扱いに向いているのかは疑問。何より，なんやかやとスクリプトが盛り込まれているためなのか何なのか，そうした CMS を使っているらしきサイトは，概して非常に重い感じがする。しかも，その「スクリプト」というのは，ブラウザにより微妙に動作が異なる。ということは，互換性の問題で表示が乱れたり，ブラウザによっては機能しなかったりして，最悪，表示されなくなる可能性もある。
　障害のある人などは，自分の障害に合わせてパソコンを使えるようにするソフトが新しいパソコンに対応できないなどの理由で，古いパソコンを使い続けざるをえないことがある。ワードプレスなど，既存の CMS がウェブ記事に組み込むスクリプトが，そうした方々の使う環境で正しく機能するだろうか。「記事が読めなくなる」ようなことにならないだろうか。そうした懸念があった。自分のサイトを，どんな人でも記事を読めるような「バリアフリー」設計にしたいと思った場合，既存の CMS を利用しようとすると，その仕組みを調べてスクリプトをチェックし，場合によっては作り直す……なんて必要があるかと思うと，とてもじゃないけどやってられない気がした。
　加えて，その手の CMS の多くは「データベース」のシステムを利用しているらしい。で，そのデータベースの処理というのがわりとサーバへの負担が大きいと聞いている。とすると，同時に複数アクセスされたら，レスポンスに時間がかかってしまうことが増えそうな気もする。

　一方「和易ゐ記」では，元の「プレーンテキスト」に基本的な HTML のタグを付加するだけで，複雑なスクリプトを含ませる必要性はなく，データベースのシステムも使用せず，単に既存ファイルを元に生成されるだけであるため，どんな環境で見ても非常に軽いはずだ。

◆ 狙われる既存 CMS

　また，多くの人が使っている CMS は，「サイトの乗っ取り」などの格好の標的になる。実際，筆者サイトにどういったアクセスがあるのかの記録を見ると，存在しない記事を読もうとしているものが多くあり，中でも，ワードプレスの管理ディレクトリを狙ったと思われるアクセスが非常に多い。たぶん，そうした既存 CMS の場合，サイトの諸設定や記事のアップロード用など，機能ごとにディレクトリやスクリプトがあるのだろうから，それを狙って攻撃するため，そうしたアクセスがあるものと考えられる。
　そういった攻撃は「下手な鉄砲」式に無差別攻撃を仕掛ける。そのために「多くの人が使っている」CMS ほど狙われるというわけだ。もし，ワードプレスに何らかのセキュリティの脆弱性が発覚した時に，そこが狙われてサイトを乗っ取られる可能性がゼロとは言えない。「多くの人が使っている CMS」を利用することには，こうしたリスクがある。

　もちろん，当サイトでは，「和易ゐ記」という独自管理方式のため，該当するワードプレス用ディレクトリやスクリプトなどは存在しない。受けた攻撃は全て「徒労」に終わっている。何より，サイトの管理が，従来どおり FTP などで「アップロードするだけ」の方式であるため，CMS 由来の HTTP アクセスでの脆弱性とは無縁であり，それを狙う攻撃も無意味と言っていい。独自システムの当サイトでは，少なくともその手の「乗っ取り」の心配はせずに済んでいる。
　まぁ，そうした既存 CMS のデメリットを嫌ったため，「和易ゐ記」をサーバ上で処理するようにしようと思ったようなところもある。それが結果的に CMS と似た機能を果たせると気付いたような感じだ。

　いつの間にか「ラクしてセキュアな CMS が実現」した形になった。

◆ 図らずも「バリアフリー」が実現

　ちょっと意外な利点も分かった。当サイトを知った視覚に障害を持つ方から，「HTML でも PDF でもなく，プレーンテキストで記事を読みたい」という要望が来たのだ。もちろん，「URL の末尾に“.txt”を付加すれば読めますよ」と伝え，直ぐに対応することができた。

　その方は普段「音読ソフト」と呼ばれるソフトにウェブ記事を読ませて「聞いている」らしい。それがなぜ「プレーンテキストで読みたい」という要望になるのか。
　 HTML で記載されたウェブ記事の場合，いくらでも凝ったレイアウトが実現できる。本文の文章の他，もくじやら画像やら，関連する他記事へのリンクやら，時として他サイトなどは広告なども掲載される。見えているならそれらは飛ばして読めるが，見えていなければ，記事を音読ソフトに読ませた時，今聞いている部分が，目次なのか，本文なのか，広告なのか……しばらく聞かないと判断できず，けっこう煩わしいだろう。ましてや，従来の CMS などでは，他の記事に関連するキーワードが「ズラー」っと並んでいたりすることもあったりして，必ずしも関係の無いそれらの言葉を延々と聞かされるのは，時として苦痛にさえ感じるのではないか。しかも，HTML というのはかなり複雑なレイアウトも可能なので，表示されている順番が，必ずしも元のファイルの記述順と同じとは限らない。一方，「音読ソフト」では，表示とは関係なく元のファイルの記述順に読むことも考えられ，見て読む順番と異なってしまうと，内容が分かりにくくなる可能性もある。
　「音読ソフト」でウェブ記事を聞いている人が，「本文だけプレーンテキストで読みたい」と要望するのは，こんな理由だと思われる。
　というわけで，その要望が来た時，「和易ゐ記」を使っている当サイトでは，「URL の末尾に“.txt”を付加して読んでください」と伝えただけで，すぐ対応できたのだった。その後に受けた連絡によれば，どうやらうまく「聞けた」ようだった。
　「和易ゐ記」の場合，アップロードしてある本文は HTML 化する前のプレーンテキストであり，しかも前述のように，URL の末尾に“.txt”を付加すれば，それもそのままブラウザで読める。わざわざ音読ソフト用に「プレーンテキスト版を用意する必要がない」ことになる。

　いつの間にか「ラクしてバリアフリー化が実現」した形になった。

◆ その他の利点

　ひょっとして，同じ内容の記事を比較すると，プレーンテキストだけで保存できる「和易ゐ記」のほうが，「タグ」を含んだ HTML で保存するより，消費領域がずっと少なくて済んでいるのかもしれない。領域の節約にもなるんじゃないかと思っている。

　当面，この「和易ゐ記」システムを発展させていくカタチで，サイトの運営をしていきたいと考えている。