本文へ
ハクソク

世界を動かす技術を、日本語で。

プレーンテキストは今でも私たちが持っている最良の技術の一つです

元記事: 原文(deadparrotbbs.com)

概要

  • Plain text は50年後も読める信頼性の高いファイル形式
  • シンプルさが長寿命と互換性の理由
  • Markdown はプレーンテキストの弱点を補う実用的な妥協案
  • 複雑なアプリ依存を避け、 データ所有権 を保ちやすい
  • すべてに万能ではないが、 長期保存 に最も適する選択肢

プレーンテキストの信頼性と長寿命

  • プレーンテキスト は50年後も読める数少ないファイル形式の一つ
  • スプレッドシートやリッチなレイアウトは扱えないが、 最も単純で広く理解される形式 として残存
  • Unicode標準 により、文字コードの連なりのみを保存し、フォントや色、レイアウト情報は持たない
  • 特定アプリに依存せず、 Linux・Windows・Webサーバー・様々なエディタ で編集・閲覧可能
  • 多くのドキュメント形式がアプリ依存であるのに対し、 プレーンテキストは独立性が高い

プレーンテキストが基盤であり続ける理由

  • ソースコード・設定ファイル・ログファイル など、基幹システムで広く利用
  • HTML・XML・JSON・CSS・シェルスクリプト 等、構造化フォーマットも本質はテキスト
  • テキストエディタで内容を直接確認・編集可能
  • 設定ファイルのトラブル時にも 直接調査・バックアップ・バージョン比較 が容易
  • アプリに依存せず、 データ保守性・移植性 が高い

豊富なツールとの相性

  • grep・sed・awk・sort・diff など、Unix系ツールで自在に操作可能
  • スクリプトや自動処理にも適し、人手を介さず大量処理が可能
  • グラフィカルエディタ・プログラミング環境・ノートアプリ など、多様なアプリが対応
  • 情報が特定インターフェースに縛られず、 自由度が高い
  • 近年のアプリはデータ管理を囲い込む傾向があるが、 プレーンテキストは利用者の自由を維持

Markdownによる実用的な拡張

  • プレーンテキストの弱点は 書式情報の欠如
  • Markdown は2004年登場、シンプルな記法で見出し・リスト・リンク等を表現
  • ソフトウェアドキュメント、Web、ノート、書籍など多用途で利用
  • Markdownのソース自体が 可読性・編集性 を維持し、専用ツール消滅後も有用
  • バイナリ形式と異なり、 書式が隠れず、内容が確認しやすい

プレーンテキストの長期保存性

  • 多くのファイル形式やアプリが消滅する中、 プレーンテキストは生き残る
  • 文字コードや改行問題はあるが、 他形式の互換性問題に比べれば小さい
  • Unicode対応 で世界中の文字体系も表現可能
  • ファイル内容が プロプライエタリ形式に依存せず、将来も読み出しやすい

データの所有と管理のしやすさ

  • クラウドやサブスクリプション型サービスが増加する中、 テキストファイルは自分で管理可能
  • バックアップ、バージョン管理、他マシンへのコピーも 自由自在
  • エディタ提供会社の存続やサービス継続に依存しない
  • 専用アプリやクラウドサービスには独自の利点もあるが、 複雑さが増すほど依存度も上昇
  • プレーンテキストで十分な場合、 将来の障害要因を大幅に減らせる

プレーンテキストの限界と適材適所

  • すべての用途に万能ではなく、 画像や複雑な表計算 には不向き
  • リッチなドキュメントやアプリケーションの 抽象化・構造管理 能力はテキストだけでは代替困難
  • 問題はリッチツールの利用自体ではなく、 必要ない場面での過剰依存
  • シンプルな表現が 最も長持ちするケース が意外と多い

「つまらなさ」こそ最大の強み

  • プレーンテキストは 目立たないが信頼性抜群
  • 企業やサービスの都合に左右されず、 移植性・検索性・スクリプト化・バックアップ容易性 に優れる
  • 長期的視点で見れば、 「地味だが壊れにくい技術」 は大きな価値
  • プレーンテキストは万能ではないが、 最小限の要件で情報を安定して保存できる
  • シンプルさが 最大の成果

提供: ハクソク · 要約更新:

AIによる日本語要約です。内容は原文とあわせてご確認ください。

Hacker Newsの議論を読む

Hackerたちの意見

Rustプログラミング言語の創設者、グレイドン・ホアは2014年にテキストに関する重要な記事を書いた。その中で彼は「テキストは、これまでで最も強力で、便利で、効果的なコミュニケーション技術だ」と言っている。[1] テキストは耐久性がある。

└

archive.phの代替案。JavaScriptなし、CAPTCHAなし、地理的ブロックなし。https://web.archive.org/web/20141014043202if_/http://graydon... JavaScriptなしのAlgolia検索。テキストのみ(JSON) https://hn.algolia.com/api/v1/search?query=always+bet+on+tex...

└

この作品のことはずっとぼんやりと覚えていて、いつか掘り起こしたいと思ってたんだけど、検索ワードの組み合わせがうまくいかなかったんだ。リンクしてくれてありがとう!読んだ後はちょっとがっかりしたけど、作品自体は素晴らしいね。ただ、記憶の中ではもっと長かった気がする!

これは、ついにスタンダードが勝利した公の配当だ。この記事ではUnicodeにクレジットを与えているが、ASCIIが明確に勝ったことがプレーンテキストのポータビリティと長寿命をもたらしている。Unicodeも同じように勝ちつつあるようだが、まだそこには至っていない。私が書くテキストファイルのほとんどはまだ純粋なASCIIだ。予期しないグリッチを避ける唯一の方法だから。[0] Windowsの改行は別として。

└

ASCIIでファイルを書けば、すでにUTF-8で書いていることになるよ。

└

ああ、プレーンテキスト、そこで「プレーン」が重要な役割を果たしている。もしプレーンテキストに4バイトのシグネチャがあれば、もっとずっと良くなっていたかもしれない。今のところ、プログラムは次のことを推測しなきゃいけない。A) エンコーディング。ANSIならどのコードページ?Unicodeならどのエンコーディング?UTF-16の場合はビッグエンディアンかリトルエンディアンか?B) 行の終わりは?CR?LF?CRLF?LFCRを使う人はいないよね…?C) 数字のフォーマットは?100.000それとも100,000?日付のフォーマットは?mm-dd-yyyyそれともdd-mm-yyyy?D) どの言語で書かれているの?E) CSV?話がそれるけど…はい、テキストはXLSよりもずっと読み込みやすく、解析しやすく、推測しやすい。上記のことはある程度「推測」できる。BOMは少なくともエンコーディングの問題を解決しようとするために存在するけど、ほとんどのファイルはそれを使っていないし、多くのツールもサポートしていない。もちろん、ASCIIファイルは英語で、アメリカの日付フォーマット、Windowsの改行…全く問題ないけどね。

└

そして、ファイルの終わりについて…

└

「Windowsの改行はさておき、“Windows”の改行はHTTPやSMTPのような多くの通信プロトコルでも標準なんだ。それはWindowsやDOSのせいじゃなくて、CRとLFの両方が必要だったテレタイプの標準だったからだ。むしろ、Unixのようなシステムがその標準から逸脱したと言えるかもしれない。ASCIIを超えると、サポートが良いところから悪いところ、変わったものから問題のあるUnicodeの領域に滑り落ちるのは同意するよ。例えば、HNは結合文字(Zalgoテキスト)や絵文字のような多くのUnicodeテキスト要素をフィルタリングしていて、何をサポートしているかを示す仕様がないんだ。ASCIIの中でも、ほとんどの制御文字にはポータブルな意味がないから、実際にはASCIIの印刷可能な部分だけなんだよね。厳密に言えば、ASCIIの地域的なバリエーションがあって、日本のものではバックスラッシュが円記号になるから、そこも考慮しないといけない。」

このプレーンテキストの話題、タイミングが面白いね。週末にちょっとしたブラウザベースのプレーンテキスト脚本アプリを作ったんだ。スクリーンライティングソフトがどれだけ使いづらいか、ファイルがどれだけ共有しづらいかに本当にイライラした。プレーンテキストなら、誰にでもどんなデバイスでもファイルを渡せるけど、実際には誰もプレーンテキストのスクリプトを渡されたくないよね。10年前に使っていた脚本を書くためのソフトはもうとっくに廃止されていて、そのファイルは基本的に開けない。だけどプレーンテキストは残っている。

└

ジョン・オーガストも映画やテレビの脚本にプレーンテキストを使うことについて話していて、マークダウンとハリウッドのスタンダードに基づいたフォーマットを指定しているよ: https://fountain.io/ 共有はさておき、プレーンテキストフォーマットはバージョン管理にも役立つと思う。

え、ASCIIアーマードBase64の話が出てないの?恥ずかしい!Base64を使えば、テキストにする必要が全くないものもテキストにできる!しかも、リソースの乱用が広がる中で、Base64は比較的効率的なんだ!ペタバイトを持ってこい!やった、完全に皮肉じゃないよ。

└

それにRFC2045ヘッダーを追加して、エンコーディングが何かを知ることになるんだよね…

Hacker Newsで議論の続きを見る