TXT を PDF に変換 — ページの体裁を付けて

プレーンテキストは何より長生きします。版もなければ、専用のソフトも要らず、崩れる書式もありません。50 年後でも開きます。

その頼もしさは、受け取る側が文書を期待した瞬間に弱点に変わります。提出の仕組みは PDF を求め、印刷には決まった大きさのページが要り、.txt の添付は完成品というより何かの断片に見えます。この変換は、その足りない部分だけを足します。原稿でも、覚え書きでも、書き起こしでも、これで十分で、ほかに考えることはありません。

テキストファイルは、自分がどの文字コードで書かれたかを持っていません。その情報はファイルの中にないので、開く側は推測するしかありません。日本語ではこれが本当によく外れます。Windows のメモ帳が長いあいだ既定にしていたのは Shift_JIS（CP932）で、いまも社内の手順書や古い書き出しはそれで保存されています。それを UTF-8 として読めば、全文が意味のない記号の列になります。

PDF が文字化けしていたら、起きたのはこれです。直し方は 1 つで、元のファイルをエディターで開き、UTF-8 で保存し直すことです。メモ帳でも「名前を付けて保存」の文字コードで選べます。1 度直せば、この先どこで開いても化けません。ファイルに書かれていない情報を、こちら側で当てることはできません。

テキストファイルにはページの幅がなく、PDF のページにはあります。余白を越えた行は次の行へ折り返されます。文章なら正しい動きで、構造のあるものには困った動きです。サーバーのログもプログラムも、1 件が 1 行に収まっていることを前提にしていて、折り返しはその見通しを一瞬で壊します。

組むのは等幅ではない書体です。空白で桁を揃えた表や、罫線を記号で引いた一覧は、そのままでは揃いません。書いたものではなく並べたものなら、行き先はここではありません。

圧縮もせず、解釈もせず、失う書式もありません。もともと書式がないからです。入った文字が、そのままの文字で、ページの上に出てきます。

Windows、macOS、Unix は、行の終わりを別々の書き方で表してきました。片方で書かれたファイルをもう片方で読むと、改行が改行として認識されないことがあります。

ここでは 3 つとも扱うので、これは起きないはずです。それでも 1 つの段落になって出てくるなら、そのファイルはたぶんプレーンテキストではありません。中身が RTF やワープロの書き出しなのに拡張子だけ .txt になっているものは、こういう挙動をします。テキストエディターで開けばすぐ分かります。

標準的な大きさのページ、読める書体、無理のない余白。段落の区切りと空行はそのまま残します。ページ番号は付けます。番号のない紙の束は、落としたときに元に戻せません。

見出しは作りません。テキストファイルに見出しはないからです。見出しに見える行も 1 行の文字列で、そのように組まれます。

数千ページでも、それ自体は困りません。手間は文字の量に比例するだけです。上限を決めるのはメモリーで、文書は全部組み上げてから書き出されるからです。

数百メガバイトの書き出しなら、先に分けたほうが確実です。もっとも、その大きさになっている時点で、それは文書ではなくログか蓄積したデータのはずで、その場合 PDF は行き先として間違っています。

欧文、ギリシャ文字、キリル文字、中国語、韓国語は、こちらの持っている書体で組まれます。UTF-8 で書かれていれば、読める形で出ます。

日本語のファイルで実際に危ないのは、別の 2 つです。半角カナは、古い機器の書き出しにいまも残っていて、文字コードの取り違えで最初に壊れます。絵文字は書体に字が入っていないと出ません。どちらも、心当たりがあるなら結果を目で見てから使ってください。アラビア語やヘブライ語のような右から左に書く文字は、字が揃っているだけでは正しく並ばないので、これも同じです。

好きなだけ置けば、それぞれが 1 つの PDF になり、まとめて ZIP で返ります。1 つの文書にはつなぎません。どの順に並べるかを、こちらで決めることになるからです。

1 冊にしたいなら、先にテキストのほうをつないでから変換してください。そうすれば順番は、ファイル一覧のたまたまの並びではなく、あなたが決めたものになります。