準プレーンテキスト形式


公開 (UL): 2020-03-23
更新 (UD): 2020-03-23
閲覧 (DL): 2024-12-31

この記事のもくじ

→本文へ
当サイトは SNS の公式アカウントがないので,「議論ネタ」にする際は,皆さんのブログ,メーリングリスト,SNS や掲示板などで,適当にハッシュタグを付けたりリンクを掲載するなどしてご利用ください。

前の記事

2019-12-06
プレーンテキスト文字化けのブラウザとサーバ対策

次の記事

2020-05-04
エスケープ文字変換/復元

最近の記事

2024-02-11
XMPP - 長く使える安心チャット
2023-09-15
Perl の正規表現での A と Z の扱い
2023-01-16
Android のキーボード・ショートカット一覧
2022-08-09
代表的な画像ファイル形式一覧
2022-04-04
サイトのローカル試験と実ウェブ上の差を縮める手法(Perl)
新着情報
She appears also the top page.

新着情報 Recent docs.

Sorry, but most of these pages are only Japanese.
「ぱそはだ」シリーズ «PASOHaDA: Parts Assignment and Soldering Only Handmade Design Assist.»
高度な技能不要の電子工作で自立介護 DIY。
簡単にできるネット防犯対策 «Simple measures against phishing mails and malwares.»
フィッシングメールを暴き,ウイルスの侵入を阻止する簡単な対策を紹介。
福祉改善を阻むオヤクショ思考 «Japanese subsidy system of communication aid device for disabilities cannot be applied those if it's with features except communication, IDK why.»
「意志伝達」しかできない高額な装置にのみ税金が使われる謎制度。
「理不尽採点」教育と「英語力低下」 «Japanese English skill ranking in the world has been down. I guess one of the reason is that the government's education policy lacks coherence.»
日本人の英語力が低下,しかも小学校から英語が必修になった世代ほど。「教育方針の一貫性のなさが原因」とする考察。
倫理意識の社会的低下 «One day, I set to stop DM from a banking corporation, but those continue to be sent after that. I'm feeling falling sense of ethics in Japanese society.»
某銀行からの DM が,およそ金融と関係ないもの多数。停止設定後も何ヶ月も配信が続く状況に,倫理意識の社会的低下を感じた話。
給使乖離現象 «"Server and User Design Gap" phenomenon (abbr: SUDG), it's the trend to lack of considerations in design for user of the service.»
愚かな経営者たちが考えた劣悪なウェブサービスにより,人々が一方的に不利益を被るという話。
日本の「IT 人材不足」の正体 «The simple reason why Japanese companies lack IT-skill.»
保険会社からのセキュリティガバガバメールが「IT 人材不足」の正体を暴く。

人気記事 Frequent view pages.

現在当サイト人気 No.1!
Android のキーボード・ショートカット一覧 «The list of Android Keyboard Shortcuts (EN ready).»
Android のスマホやタブレットにキーボードをつないだ時に知っていると便利なキー操作。
表計算で「令和」に対応する方法
How to adapt the Gengo era "Reiwa" on spreadsheet applicaiton.

古いアプリも OK。「表計算 令和」の検索結果上位御礼!
表計算ソフトで予定表を自動作成する超便利な方法 «How to make the schedule table automatically on spread-sheet.»
「毎月第○×曜日」的な法則は自動で作らせてラクしよう!
表計算ソフトに「個人情報保護機能」を仕込む方法 «Prevention to leak private-data with spread-​sheet macro function.»
「漏えい」のためのフェイルセーフ。「表計算 個人情報」の検索結果上位御礼!
Wary-Basher (ワリバッシャー)
DIY device that enables the handicapped to operate many things with a switch like push-button.

障害者の様々な操作をスイッチ操作で実現する器具。キットも発売中! 「作り方」PDF ダウンロード多数御礼!←地方教育委で人気。

おすすめ! Recommend

貧乏人を殺す行政の構造 «Structurally, the administrators kill the poors in Japan.»
ヘタすると多摩川に流されるところだった台風 19 号

この記事に対する → 調布市の反応
[PDF 118KB] 生活保護申請時のオヤクショ対策
申請の「水際作戦」を突破するための心得。「ホームレス総合相談ネットワーク」製作の図解を小サイズ化したもの。

出典 ☞ 路上からもできるわたしの生活保護申請ガイド (2017 年版) (外部リンク)
文字ベース天気予報 «Weather forecast in text mainly from JMA Json-data.»
古いブラウザやスマホ,音読ソフトでも大丈夫! 気象庁の JSON データを利用した文字ベースの天気予報(試験版)。
「事故防シート」について «Cared persons taking with "Jiko-​Bow-​Sheet" prevents from accidents.»
介護現場の負担軽減と事故防止のアイデア
【連載】 キーボードの「キー」の詳しい使い方 «The detial of usage each key on keybord.»
各キーの機能詳細。機能別五十音順一覧。
和易ゐ記 (WAI-WIKI) «WAI-WIKI is light­weight markup language for Japanese, and generates HTML on this server on-​demand.»
当サイトで開発/使用中の日本語向けに特化した軽量マークアップ言語

ご連絡 Contact

▼ メールフォームはこちら
SSL 証明書の更新に不具合が多いため,期限切れエラーが出た際は,お手数ですが「例外指定」をお願いいたします。 一時期,送信できなかったようです。すみません。今は大丈夫だと思います(テストは OK)。

ファイルの暗号化
当サイト管理者(石川)宛にメール添付で送信するファイルを暗号化したい時は,唯一のパスワードを PPOP で取得できます。 PPOP gives a password for encryption of the file(s) attached your mail to the admini­strator of this site M.Ishikawa.
PPOP

MEMO / Email to the Author
あとで調べたい点のメモなどに利用可能。
下部ボタンでそのまま著者にメールできます。 一時期,送信できなかったようです。すみません。今は大丈夫だと思います(テストは OK)。


CAPTCHA: easy math prob in Japanese

時事川柳 News Senryu

パーティー券  
民意も一緒に
  蹴り返し
Kick back both party tickets and people's opinions.

 自民党の一部(?)派閥がパーティー券のノルマを上回る分の売上げを議員にキックバックしておきながら政治資金収支報告書に不記載だった問題が広がりを見せている。なるほど,こうしたことが党内で常套化していたのだとすれば,岸田総理はじめ同党政治家にことごとく「民意を蹴り返すクセ」が付いているのは当然という感じもする。これっぽっちも「悪いこと」と思わなかったのだろうな。そんな人たちに誰が票を入れるのだろうか。少なくとも,岸田の広島と「頭悪いねぇ」と暴言を吐いた議員を選出した長崎に「ふるさと納税」はしないことにしよう。
参考: 自民県 絶対しないぞ ふるさと税

今回はもう一句!

危機感の  
ワリに二階は
  誰も居ず
Having sense of crisis, but nobody takes shelter of 2F.

 大雨などで危機感を持ったら二階のような高い所へ避難すべき的な話を聞いたよーな気がするのだが? パーティー券のノルマ上回り分キックバックの政治資金収支報告書不記載問題で,安倍派は何人も辞任したのに,同じく捜索を受けている二階派に辞任する話があるかというと,今のところ誰もいない。総理は「危機感を持って」とか言っているらしいが,どこが「危機感」なのやら。

(⌚2023-12-19)

ご支援 Support this site.

まだまだ コロナ失業中!!
CORONA-NEET, seeking works now!

この活動をご支援いただける方はこちらへ Could you support this site, see here (but Japanese).
都道府県庁さん, 地方自治体さんや教育委員会さん, 障害者就労支援機関さんやその他公的機関,省官庁さん, 「タダ見」しているだけでは, 格差が広がるだけだと思いませんか?
Welcome!
Amazon    Google
The companies, thanks for many accesses every months! Are the articles I wrote helping for increasing your income? Although, I cannot get even a penny and jobs from that.

 「準プレーンテキスト」とは,ブラウザ(ウェブ記事閲覧ソフト)でプレーンテキストを表示する時に起こる「文字化け」を回避する対策。
 ウェブ記事の規格である HTML では,ブラウザの違いでレイアウトが崩れたり,それを「音読ソフト」に読ませると読む順番が狂ったりすることがあって,そうなると内容を正確に伝えることが困難になる。これは,「避難情報」などの緊急性の高い配信では大きな問題。その点では「プレーンテキスト形式」のほうが,作成も容易で,ほぼ記載順の通り表示する点で適しているが,文字化けし易く,ブラウザによっては全く読めなくなる難点がある。ここでは,HTML を知らなくても記事作成が容易でレイアウトも崩れにくいプレーンテキストの特徴を活かし,HTML の機能を少しだけ付加して,文字化けなく公開できる工夫を紹介する。
 なお「準プレーンテキスト」の呼称は,筆者が勝手に付けたもの。

● 有用性

 「準プレーンテキスト」とは,HTML とプレーンテキストの,いわば「いいとこ取り」。特徴は以下の通り。

 上記特徴から,さらに以下のような利点が導かれる。

 HTML,プレーンテキストとの比較を表にすると,以下の通り。

▼ 各形式ごとの優位性
各形式ごとの優位性

◆ 背景……一部ブラウザの劣化

 ウェブ記事の標準規格である HTML は,本文の文字以外にも,画像の挿入や文字の色,大きさの指定,複雑なレイアウトも実現できるようになっているが,全てのブラウザで必ずしも同じレイアウトで見れるとは限らない。ブラウザによっては,時としてどこに何が記載されているのか分からないレベルに乱れる可能性もある。また,それを視覚障害者が使うような「音読ソフト」で聞こうとすると,画像や文字の色,大きさなどには意味がないし,むしろ複雑なレイアウトが原因で,読む順番が聞きたい順番と合わなくなることも起こりそうで,そうなると聞いてて理解しにくくなってしまう気がする。しかも,HTML という規格は元々英文向けのもので,通常は空白や改行がいくつ続いていても,「1つの単語の境界」と見なされて,空白1個で置き替えられて1行に入りきるまで前行に詰められる……という英文の記述方式に沿った扱いになる。つまり,段落の意味で入れた改行も,引用を示したつもりの行頭の空白も,読む側のブラウザ(ウェブ記事閲覧ソフト)の表示には反映されない。整ったレイアウトの書面を作りたいと思ったら,ウェブ記事で使われる HTML という記述法をある程度知っている必要があるが,使いこなせる人はそう多くない。ウェブで公開できる文書を作れる人材が限られることになり,緊急時の避難情報のような「迅速に公開したい文書」を作りたい時に困難が生じる可能性がある。
 その点「プレーンテキスト形式」は,画像や複雑なレイアウトの指定はできないものの,文書を作った側で入れた「空白や改行」はそのまま表示されるため,それらを使用したレイアウトは HTML を知らなくても比較的容易に作れる。しかも,異なるブラウザでも空白の扱いに違いが少なくレイアウトが崩れにくい。また「本文の文字だけ」のデータのため,「音読ソフト」でも記述された文が順番通り読まれるだけだから,聞く時にも都合がいい場合が多いと思われる。一方,プレーンテキストには内部に「文字コード」を明記する規定がなく,ブラウザで見た時,自動検出した文字コードが違ってしまい「文字化けを起こし易い」という欠点がある。
 とはいえ,少し前なら,ブラウザに文字コードを指定して読む機能があったので,いくつか文字コードを試せばたいてい読めていたが,最近はその機能が元からは備わっていないブラウザも多いらしい。すると,そのままでは「文字コード」が設定できないから「文字化けしたら全く読めない」ことになる……粗悪なブラウザが増えただけの気がする。
 サーバの設定をいじれない場合は,ウェブ記事を「作成する側で」できる文字化けの防止対策は限られる。「準プレーンテキスト形式」は,その限られた手段の中で最も誰でもできそうなものだと思う。

 なお,プレーンテキストで「文字化け」が起きた時に,「読む側で」対策する方法と,サーバ設定での対策については,以下の記事を参照。

▼ プレーンテキスト文字化けのブラウザとサーバ対策
http://treeware.jp-help.net/?ssss1

● 実際の方法

 「プレーンテキスト」には,内部に「文字コード」を示す規定がないが,ウェブ記事で一般的な規格である HTML にはある。だから,「文字コード」を明示した HTML の中に「プレーンテキスト」記事を記述すれば,「文字化け」は回避できることになる。原理としてはそんな感じ。
 たとえば UTF-8 という文字コードで記述したテキストを正しく表示させたい時は,以下のようにする。

▼ 準プレーンテキスト形式
      <HTML><HEAD><META CHARSET="UTF-8" />
      <META HTTP-EQUIV="content-type"
          CONTENT="text/html; charset=UTF-8" />
      <TITLE>表題(この行は省略可能)</TITLE>
      </HEAD><BODY><PRE>
	   :
      記事本体(任意の文字データ=プレーンテキスト)
	   :
      </PRE></BODY></HTML>

 この“<PRE>……</PRE>”の間の「記事本体」の部分は,空白(スペース)の数も改行の位置もそのままブラウザに表示されるため,空白と改行でレイアウトを作った文書はほぼそのまま見れる。上の5行と最下行の1行だけをどこかに保存しておけば,記事を作成する時に,それをコピペして来て,間に「記事本体」を入れるだけで完了する。
 「表題」の行は省略可能だが,設置がお勧め。そこに記載した表題はブラウザのタイトルの部分に表示されるほか,ブラウザのブックマーク(お気に入り)機能を使った時にもそのタイトルになり,あとで分かり易い。また,「音読ソフト」などに「タイトルを読む機能」付きのものがあれば,今読んでいる記事が何であるかを把握し易くなる。この行がないと,そのどの機能も使えないが,もし省略するなら,1行まるごと(つまり <TITLE>……</TITLE>)削除する。
 なお,もちろん「記事本体」の文字コードと,上部記載の文字コード(UTF-8 の部分)が一致しないと,結局文字化けしてしまうので注意。作成した文書の文字コード指定は,たいていは「名前付け保存(=いちばん最初の保存)」する時に指定する必要がある。ちなみに,現在世界的に「標準」として使われている文字コードは「UTF-8」と思われる。
 また,基本的に HTML 規格なので,例のように「表題」をつけたり,「記事本体」の中に,強調やリンクを付けることも可能。ただし次節の「エンティティ」に注意。

◆ 注意点……エンティティ

 注意すべきは,HTML の機能を利用するために,HTML で特殊な意味を持つ文字は,そのまま記述できない点。具体的には,いずれも半角で,不等号(< と >)は,HTML で「タグ」と呼ばれる「書式指定」に使われていて,また & の記号は「エンティティ」と呼ばれる記述法で特殊文字を表すのに使われている。そのため,「記事本体」中にこれらがあると,正確に表示されない。回避するためには,その「エンティティ」と呼ばれる方式を使い,以下のように記述する。

 なお,「エンティティ」が関係するのはあくまで半角文字で,全角の文字にはこの心配はない。表記のアルファベットも半角を使う。
 逆に「エンティティ」を文中に記載することで,これら以外の特殊な文字の使用も可能になる。たとえば &hearts; と書けば ♥ が表示される。

◆ 記事作成に使うソフト

 「プレーンテキスト」というのは,文字の装飾(大きさや色を変えたり,斜体や太字にしたり)などが一切無い形式なので,作成に使うソフトは「メモ帳」的な簡易な記述ソフトで十分。一般的に「エディタ」と呼ばれるコンピュータ用のプログラム作成時に使われるソフトが最適だと思う。
 「ワープロ」ソフトでも作れなくはないが,保存する時に「プレーンテキスト」で保存することを忘れてしまうと,うまくいかない。また,文字装飾は関係ないため,その機能がサポートされたワープロソフトで作るのは少々重いかもしれない。しかも,それでつい「文字装飾」をしてしまうと,プレーンテキストで保存できなくなる可能性もあるから,注意が必要。それと,この <PRE> で囲む方式では,ブラウザでは「固定ピッチ」のフォントで表示されることが多いから,ワープロで多く使われるプロポーショナルのフォントで作った記事は,レイアウトの再現性はあまりよくない。作成時,最初に「固定ピッチ」のフォントを設定して作成したほうがいいと思われる。

 ちなみに,ほぼ同じ名前の日本語のフォントがあり,P の文字が付いているかいないか程度の違いだった場合,付いているほうは「プロポーショナル」で,無いほうは「固定ピッチ」であることが多い。

◆ レイアウト作成上の注意

 レイアウトが「崩れにくい」とはいうものの,使えるのは空白と改行だけという制約がある。ただこの <PRE> を使うと,表示に使われるのはたいてい「固定ピッチ」のフォントで,多くは「半角と全角」の幅の比がちょうど 1:2 になっている。それを利用してレイアウトを作れば,ほぼ同じレイアウトを見れることが多いだろうと思う。
 が,ブラウザというのは,見る側が必ずしも同じフォントで見るとは限らない。微妙に文字幅が異なれば,「表」のようなものでは右の欄ほど位置がズレていってしまう可能性が高くなる。この方法でレイアウトを作る際は,空行をあけたり,あるいはせいぜい「左側の文字開始位置(インデント)を揃える」のに空白が使える程度と考えておいたほうがいいと思う。

 ちなみに,「数字」の文字幅はたいてい各フォントごとに(プロポーショナルでも)同じであることが多い。

◆ SSI が使えれば超簡単

 サーバで「SSI」という機能が使えれば,かなり簡単に実現できる。例にあげた「記事本体」以外の部分を別のファイルにしておいて「インクルード」すれば済むことになる。
 ただし,この方法では「表題」が付けられないので注意。「表題」はあったほうがいいので,なるべく「記事本体」の前の部分も個々に記載して,「表題」を入れることを推奨したい。

 もしやるとすれば,具体的には,まず「記事本体」より上の部分を,たとえば header.html というファイルにする。

▼ ファイル header.html
      <HTML><HEAD><META CHARSET="UTF-8" />
      <META HTTP-EQUIV="content-type"
          CONTENT="text/html; charset=UTF-8" />
      </HEAD><BODY><PRE>

 サーバソフトが Apache なら,同じ場所(フォルダ)に記事ファイルを置く場合は,プレーンテキストの記事本体に,以下の最初と最後の行(つまり2行だけ)を付け足せば済むことになる。

▼ 実際の記事ファイル
      <!--#include virtual="header.html" -->
	   :
      記事本体(任意の文字データ=プレーンテキスト)
	   :
      </PRE></BODY></HTML>

 なお,SSI の機能を使いたい場合,Apache の Include 機能が有効である必要がある(Apache の Options Includes,または XBitHack ディレクティブを参照)。実際に利用可能かどうかは,サーバ管理者に確認か相談が必要。また,場合により,記事ファイル名の末尾(拡張子)を .html ではなく .shtml にする必要がある。

 この方法の利点は,header.html に当たるファイルに,そのサイトの標準ヘッダ(見出しの装飾,トップのロゴやイラストなど)を収録しておけば,サイトのページデザインの統一性を保ちながら,簡単に記事が追加していける点。最下行についても,サイトの標準フッタのファイル(たとえば footer.html)を作成して署名や連絡先を記載しておいて,インクルードで対応させることもできるだろう。

◆ SSI で「タイトル」も入れる方法

 この節は,Apache の SSI をちょっと詳しく知っている人向け。
 ひょっとすると「内部変数で『表題』を指定できるのでは?」と思っている人もいるかもしれない。筆者も試してみたので,備忘録的に記載しておきたい。

 具体的には,まず「ヘッダ」のほうは,こんな感じ。表題を示す変数を title としているが,#if はその指定が無かった場合の対応。

▼ ファイル header.html
      <HTML><HEAD><META CHARSET="UTF-8" />
      <META HTTP-EQUIV="content-type"
          CONTENT="text/html; charset=UTF-8" /><!--#if
          expr="\"$title\" != \"\"" -->
      <TITLE><!--#echo encoding="none" var="title"
          --></TITLE><!--#endif -->
      </HEAD><BODY><PRE>

 「呼び出す」本体側は,その「表題」を指定しておいて呼び出す必要がある。だから,include の前に title の指定が必要。

▼ 実際の記事ファイル
      <!--#set var="title" value="タイトル文字列"
         --><!--#include virtual="header.html" -->
	   :
      記事本体(任意の文字データ=プレーンテキスト)
	   :
      </PRE></BODY></HTML>

 いちおう日本語(UTF-8)を記載しても使えたが,どんな環境下でも可能かどうかは分からない。7ビット文字(最上位ビット7が0)でも使えるかどうか試してみたが,多少複雑だった。というのは,エンティティ(&……;)を使うと,&amp; が & に直されて渡されるようで,しかも ASCII 文字以外は文字化けが起きた。何とか成功したのは,以下のようにして渡した場合(表題は「タイトル」)。

▼ ASCII 文字だけのタイトル指定
      <!--#set var="title" value="&amp;#12479;&amp;#12452;&amp;#12488;&amp;#12523;"
         --><!--#include virtual="header.html" -->

 HTML なんだから,エンティティをそのまま渡してくれりゃいいのにと思ったが,こうしないとダメだった。まぁ,直接 UTF-8 を記載して機能してくれたら,それに越したことはないと思う。
 なお,試した Apache のバージョンが少々古い(1.3)。バージョンにより差が出るのかどうかは分からない。

● じつは HTML の特徴を殺す禁断の方法

 じつはこの「全体を“<PRE>……</PRE>”で囲む」という書式の指定は,筆者にとって「最もやってはいけない」と考えていた禁断の方法。そりゃあ,作成者の意図で入れた空白やスペースでレイアウトを作っても,HTML では通常無視されてしまうから,無視されないようにできる方法が使えれば,作成者はそのほうが都合がいいだろうが……。
 一方,HTML という規格は,そうした文書に共通する「構造」を示すためにあるような側面があり,そのための符号が多数決められている。たとえば,そこが「見出し」とか「引用部分」とか「箇条書きの項目」であることを示す細かな「きまり」がある。公開された時,つまり外部から読まれる時も,どこが見出しで,引用で,箇条書き項目かといった「文書構造」が,世界共通で分かるように作られている。だから本来,HTML で書かれたウェブ記事は,そうした「構造」をレイアウトに反映するよう作られるべきで,実際,細かい書式の指定をせずに HTML で記述した記事は,自動的にそれなりのレイアウトになる。

 つまり,なぜ「禁断」なのかというと,空白と改行だけでレイアウトを作成して「全体を“<PRE>……</PRE>”で囲む」ことは,その「構造を示す」という HTML の特徴を殺すことにほかならないからだ。作成者の意図で空白や改行が入れられてレイアウトが作られると,そこに空白や改行がある理由は,作成者にしか分からない。独自のレイアウトでも,所属する組織内だけで通用すれば済むならいいが,外部に公開する文章でそれをすると,構造が分からないため通用しない状況が起きてしまう可能性がある。
 たとえば,いまや「ワープロソフト」は世界共通で使われているが,たいてい「見出しの一覧(つまり『もくじ』)を自動生成する」という機能がある。作成者が「前後に空行が2行ずつあるのが『見出し』」と決めていても,それをコンピュータに伝える方法がないと,コンピュータはどこが「見出し」なのか判断できないから,そうした「もくじ」の自動生成機能が使えないことになる。一方 HTML なら「見出し」を示す記述が決められているため,その「自動処理」ができる。実際,筆者は「もくじ」を付けたい文書は HTML をワープロに取り込んで作ることも多い。「見出し」とそのページ番号の一覧は,ほんの数秒でできる。
 「そんなの,どこが『見出し』かくらいは見りゃ分かるだろ」と言いたくなる人もいそうだが,コンピュータは見て判断するわけではない。「世界共通で」使われるワープロだから,「世界共通で」使われている HTML 文書に合わせて作られるのは,ある意味当然だ。

 だから,筆者は今でも,空白や改行を使ってレイアウトを作るのは,「本来的に」禁断だと思っている。

 ただ今回は,「プレーンテキストで文字コード指定できず,文字化けして読めない」ような,欠陥品のブラウザが多く出回ってしまったという事情もある。「プレーンテキスト」なら,どんなブラウザでも表示に差がなく,「音読ソフト」などでも正確に情報が伝えられると思われるが,そうした情報提供を妨げる,バリアフリーに逆行するようなブラウザが多く使われるようになってしまったわけだ。「避難情報」のような緊急性のある情報などは,発信する側は「迅速,かつ確実に読めるよう公開したい」と考えていてしかるべきだろうが,やれ「ブラウザを限定しないと正しく見れない」とか,「HTML が分かる人がいないと記事が作れない」などの制限があると,避難が遅れて死に至る人が出てしまう可能性もある。そうした危険性を減らす手段として,「プレーンテキスト」並に容易に作れて,どんなブラウザでも確実に読める「準プレーンテキスト」が役立ちそうな気もしたので,提案する次第。

◆ 遅れている気がする日本の文書処理自動化

 HTML のような「文書を構造化する」記述法は「マークアップ言語」と呼ばれることがあるが(末尾の“ML”というのはその意味),それにしても,そうしたものの活用で使えるようになる「目次の自動生成」のような機能を「メリット」と感じたり,逆にその機能が使えないことを「デメリット」として捉える傾向は,特に「日本では」少数派なような気がする。というのは,ネットで配布されていて,ワープロソフトなどで作られたと思われる PDF を見ていると,「ブックマーク」の機能が使われていないことが多いように思われるため。この機能が使えると,読んでいる本文の隣に「目次」を表示しておき,そこの読みたい見出しをクリックすればパッと該当の部分が表示されるから,目次を見ながら「××についてはどう書いてあったっけ」などと,本文の側を行ったり来たりしながら読める,スゴく便利な機能。ただこの機能も,ワープロで「ここが『見出し』」といった「構造」をキチンと示した文書を作らなければ働かない。特に日本語の文書では,その機能が使われていないものが多いような気がする。つまり,まだまだ「構造」を意識した文書の作り方をされることが少ないのだろうと思う。
 「構造化がなんぼのもんや?」と思っている人もいるかもしれない。
 以前,治療中の患者の病状について,人工知能に何千万件かの論文を読ませて,非常にまれなケースであると特定ができたために治療に活かせたような話を聞いたことがある。それだって,読ませる文書のどこが「見出し」で,「箇条書きの項目」なのか……といった「文書構造」も含めて,コンピュータで内容が把握できるようになっていたからこそできたのではないかと思う。どーせ,その「読ませた」という文書の多くが,HTML などのマークアップ言語で記述された「英文」だったんじゃないか。とすれば,つまり研究成果を文書にしても,「構造化」されていなかったら,そうした「命を救う」ことに役立てられないかもしれない。日本語の文書は,どれほど「世界規模で」活かされるだろうか。
  PDF の「ブックマーク」のような機能があまり活かされていない現状を見るにつけ,文書処理にとどまらず,自動化やら効率化やらが,他の国と比較してかなり遅れていると言われている原因の一端を垣間見ているような気もする。
 紹介した「全体を“<PRE>……</PRE>”で囲む」方法で記載することは,述べたように,「文書の構造」を示すことを無視するようなもの。構造が明確にされない文書が,前述の「人工知能」や,「検索」の結果などに十分に活かせるとは思えない。つまり,作った文書が活かされない……そうした意味でも「禁断の方法」だと思っている。

● 封印された方法

 ちなみに,封印された記述法として,<PLAINTEXT> というのもある。HTML の中にこの記述があると,それ以降は全て「プレーンテキスト」扱いになって,空白も改行も記号もそのまま表示される。ただ,今も,今後についても,ブラウザでの有効性や動作は保証できない。
 前述した <PRE>……</PRE> は,中の HTML 表記は有効で,タグによるリンクや文字の装飾もできるが,<PLAINTEXT> では,タグもエンティティも認識しないらしく,不等号(< と >)や & 記号でも,記述したものがそのまま表示されるようだ。
 本来なら <PLAINTEXT>……</PLAINTEXT> で囲んだ部分を「プレーンテキスト」として扱う仕様であってよさそうなものだが,述べたように,不等号もそのまま表示するようになるため,エンドタグ(</PLAINTEXT>)も認識しなくなり,ファイルの終わりまで全て「プレーンテキスト」として扱ってしまうことになるのだろうと思う。
 リンクを付けたり文字の装飾などもできず,利用価値があまりないと感じられたのか,現規格では「廃止」扱いにされたようだ。



© M.Ishikawa; TREEWARE 2024.