第11章 データー変換

	ヒント
	iconv(1) はlibc6 パッケージの一部として提供されていて、文字の符号化方式変換のために実質的に全てのUnix的システムで常に利用可能です。

以下のようにするとテキストファイルを iconv(1) を使って変換できます。

$ iconv -f encoding1 -t encoding2 input.txt >output.txt

符号化方式 (エンコーディング) 値をマッチングする際には、大文字小文字の区別は無く、"-" や "_" を無視します。"iconv -l" コマンドにより、サポートされている符号化方法が確認できます。

	注記
	一部の符号化方式 (エンコーディング) はデーター変換のみサポートされており、ロケール値としては使われません (「ロケール」を参照下さい)。

ASCII や ISO-8859 文字セットのような1バイトに収まる文字セットに付いては、文字の符号化方式 (エンコーディング) とは文字セットとほとんど同じ事を意味します。

日本語のための JIS X 0213 や実質的に全ての言語のためのユニコード文字セット (UCS, Unicode, ISO-10646-1) のような多くの文字を含む文字セットの場合には、バイトデーター列に落とし込む多くの符号化手法があります。

これらに関しては、文字セットと文字符号化方式の間にはっきりとした区別があります。

コードページは、一部のベンダー固有のコードページで文字符号化テーブルと同義語として使用されています。

	注記
	ほとんどの符号化システムが7ビット文字に関して ASCII と同じコードを共有している事を承知下さい。もちろん例外はありますが。もし古い日本語の C プログラムや URL のデーターをカジュアルにシフト JIS と呼ばれている符号化フォーマットから UTF-8 フォーマットに変換する際には、期待される結果を得るために "shift-JIS" ではなく "CP932" を使います: 0x5C → "\" と 0x7E → "~"。こうしないと、これらが間違った文字に変換されます。

	ヒント
	recode(1) は、十分使えますし、iconv(1) と fromdos(1) と todos(1) と frommac(1) と tomac(1) を組み合わせ以上の機能を提供します。詳しくは "info recode" を参照下さい。

以下のようにするとテキストファイルが UTF-8 でエンコードされていると iconv(1) を使って確認できます。

$ iconv -f utf8 -t utf8 input.txt >/dev/null || echo "non-UTF-8 found"

	ヒント
	最初の非 UTF-8 文字を見つけるには上記例中で "--verbose" オプションを使います。

#!/bin/sh
ENCDN=iso-8859-1
for x in *;
 do
 mv "$x" "$(echo "$x" | iconv -f $ENCDN -t utf-8)"
done

"$ENCDN" 変数値には、旧OS下で用いられたファイル名に用いられた元となる表11.2「符号化方式値とその使い方リスト」中にあるエンコーディングを指定します。

もっと複雑な場合にはそのようなファイル名を含有するファイルシステム (ディスクドライブ上のパーティション等) を mount(8) オプションに適正な符号化方式 (エンコーディング) (「ファイル名の符号化方式」を参照下さい) を指定してマウントし、その全内容を他の UTF-8 でマウントされたファイルシステムに "cp -a" コマンドを使ってコピーします。

行末 (EOL) フォーマット変換プログラムに関して、fromdos(1) と todos(1) と frommac(1) と tomac(1) は非常に便利です。recode(1) もまた役に立ちます。

	注記
	python-moinmoin パッケージ用の wiki のデーター等の Debian システム上の一部データーは、MSDOS スタイルの CR-LF を行末コードとして用います。あくまで上記は一般則と言うだけです。

	注記
	ほとんどのエディター (例えば vim や emacs や gedit 等) は MSDOS スタイルの行末を透過的に取り扱えます。

	ヒント
	MSDOS と Unix スタイルが混在する行末スタイルを MSDOS スタイルに統一するには、todos(1) を使う代わりに "sed -e '/\r$/!s/$/\r/'" を使う方がより好ましいです。(例えば、2つの MSDOS スタイルファイルを diff3(1) を使ってマージした後。) todos は全ての行に CR を追加するというのがこの理由です。

indent パッケージにある indent(1) コマンドは C プログラム中のホワイトスペースを完全にリフォーマットします。

vim や emacs 等のエディタープログラムもまたタブ変換に使えます。例えば vim を使うと、":set expandtab" として ":%retab" するコマンドシーケンスでタブ変換が出来ます。これを元に戻すのは、":set noexpandtab" として ":%retab!" とするコマンドシーケンスです。

$ vim u-file.txt

$ vim '+e ++enc=latin2 pu-file.txt'

$ vim '+e ++enc=eucJP ju-file.txt'

$ vim '+e ++enc=CP932 ++ff=dos jw-file.txt'

vim オンラインヘルプ中の mbyte.txt "multi-byte text support" と、"++enc" に使われるロケール値に関する表11.2「符号化方式値とその使い方リスト」を参照下さい。

emacs ファミリーのプログラムもまた同様の機能の実行ができます。

以下はウェッブページを読みテキストファイルに落とします。ウェッブから設定を取ってくる時や grep(1) 等の基本的な Unix テキストツールをウェッブページに適用するときに非常に有用です。

$ w3m -dump https://www.remote-site.com/help-info.html >textfile

同様に、次を用いることで他のフォーマットからプレーンテキストデーターを抽出出来ます。

XML テキストはちょっと HTML のようにも見えます。これを使うと一つの文書から複数のフォーマットのアウトプット管理できるようになります。簡単な XML システムの一つはここで使っている docbook-xsl パッケージです。

各 XML ファイルは以下のような標準的な XML 宣言でスタートします。

<?xml version="1.0" encoding="UTF-8"?>

XML 要素の基本的シンタックスは以下のようにマークアップされます。

<name attribute="value">content</name>

空の XML 要素は以下の短縮形を使ってマークアップされます。

<name attribute="value" />

上記例中の "attribute="value"" はオプションです。

XML 中のコメントセクションは以下のようにマークアップされます。

<!-- comment -->

マークアップを追加する以外に、XML は以下の文字に関して事前定義されたエンティティを使い内容を少し改変する必要があります。

	注意
	"<" と "&" はアトリビュートやエレメントには使えません。

	注記
	例えば "&some-tag;" 等の SGML スタイルのユーザー定義エンティティが使われた場合、他の定義は無効で最初の定義が有効です。エンティティ定義は "<!ENTITY some-tag "entity value">" と表現されます。

	注記
	XML のマークアップがタグ名の何らかの組み合わせで (あるデーターを内容としてであれアトリビュート値としてであれ) 整合性を持ってされている限り、他の XML の変換は拡張可能スタイルシート言語変換 (XSLT) を使うととっても簡単な作業です。

拡張可能スタイルシート言語 (XSL) のような XML ファイルを処理に利用可能なツールは沢山あります。

基本的に、良くできた XML ファイルを一度作ると、いかなるフォーマットへも拡張可能なスタイルシート言語変換 (XSLT) を使って変換できます。

フォーマットオブジェクト用拡張可能スタイルシート言語 (XSL-FO) がフォーマットのための答えとなるはずです。fop パッケージは Java プログラム言語 に依存するため Debian の main アーカイブでは新規です。このため、 LaTeX コードが XML から XSLT を使って通常作成され、DVI や PostScript や PDF 等のプリンタブルなファイルが LaTeX システムを使って作成されます。

XML は標準一般化マークアップ言語 (SGML) のサブセットなので、ドキュメントスタイル構文規程言語 (DSSSL) 等の SGML 用として利用可能な広範なツールで処理できます。

	ヒント
	GNOME の yelp は DocBook XML ファイルを X 上に体裁良く表示するので時々便利です。

伝統的には、roff が主な Unix テキスト処理システムです。roff(7) と groff(7) と groff(1) と grotty(1) と troff(1) と groff_mdoc(7) と groff_man(7) と groff_ms(7) と groff_me(7) と groff_mm(7) と "info groff" を参照下さい。

groff パッケージをインストールすると "/usr/share/doc/groff/" 中に "-me"マクロに関する良い入門書や参考書が読めます。

	ヒント
	"groff -Tascii -me -" はANSI エスケープコードを含むプレーンテキストを生成します。もしマンページのような多くの "^H" や "_" を含む出力が欲しい場合には、この代わりに "GROFF_NO_SGR=1 groff -Tascii -me -" を使います。

	ヒント
	groff が生成した "^H" や "_" をテキストから削除するには、それを "col -b -x" でフィルターします。

TeX Live ソフトウェアーディストリビューションは完全な TeX システムを提供します。texlive メタパッケージは、ほとんどの一般的タスクに十分な TeX Live パッケージのまともな選択を提供します。

TeX と LaTeX に関する多くの参考書が利用可能です。

これはもっとも強力な組版環境です。多くの SGML 処理ソフトはこれをバックエンドのテキスト処理ソフトとしています。多くの人が Emacs や Vim をソースのエディターとして使う一方、lyx パッケージが提供する Lyx と texmacs パッケージが提供する GNU TeXmacs は洒落た LaTeX のWYSIWYG 編集環境を提供します。

多くのオンラインリソースが利用可能です。

文書が大きくなると、TeX はエラーを発生する事があります。この問題の解決には (正しくは "/etc/texmf/texmf.d/95NonPath" を編集し update-texmf(8) を実行することで) "/etc/texmf/texmf.cnf" 中のプールの数を増やし修正しなければいけません。

	注記
	"The TeXbook" の TeX ソースは www.ctan.org tex-archive site for texbook.tex にあります。このファイルには必要なマクロのほとんど全てが含まれます。この文書は7から10行をコメントして "\input manmac \proofmodefalse" を追加すると tex(1) で処理できると聞いた事があります。オンラインバージョンを使うのではなくこの本 (さらに Donald E. Knuth 氏による全ての本) を購入される事を強く勧めます。しかし、そのソースは TeX の入力の非常に良い例です！

プレーンな troff フォーマットでマンページ (マニュアル ページ) を書く事は可能ですが、それを作成するヘルパーパッケージがあります。

印刷データー処理の核心はラスタ画像を生成する Ghostscript という PostScript (PS) インタープリタです。

	ヒント
	"gs -h" とすると Ghostscript の設定が表示されます。

2つの PostScript (PS) や Portable Document Format (PDF) ファイルは Ghostscript のgs(1) をつかってマージできます。

$ gs -q -dNOPAUSE -dBATCH -sDEVICE=pswrite -sOutputFile=bla.ps -f foo1.ps foo2.ps
$ gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=bla.pdf -f foo1.pdf foo2.pdf

	注記
	PDF は、クロスプラットフォームの印刷可能フォーマットとして広範に使われていて、本質的にいくつかの追加機能と拡張がされている、圧縮 PS フォーマットです。

	ヒント
	コマンドラインの場合、psutils パッケージ中の psmerge(1) 等のコマンドは PostScript 文書を操作するのに便利です。pdftk パッケージの pdftk(1) も PDF 文書を操作するのに便利です。

Common Unix Printing System (CUPS) が提供する、lp(1) と lpr(1) コマンドの両方が印刷可能なデーターの印刷をカスタム化するオプションを提供します。

以下のコマンドの内のひとつを使い一つのファイルに対し３部の印刷をページ順に揃えてできます。

$ lp -n 3 -o Collate=True filename

$ lpr -#3 -o Collate=True filename

さらに、コマンドライン印刷とオプションに書かれているように "-o number-up=2" や "-o page-set=even", "-o page-set=odd" や "-o scaling=200" や "-o natural-scaling=200" 等の印刷オプションを使ってカスタム化できます。

メイル (SMTP) データーは7ビットデーター列に限定されるべきです。だからバイナリーデーターや8ビットテキストデーターはMultipurpose Internet Mail Extensions (MIME) を用いたり文字セット (表11.2「符号化方式値とその使い方リスト」を参照下さい) を選択して7ビットのフォーマットに エンコードされます。

標準のメールストレージフォーマットは RFC2822 (RFC822 の更新版) により定義される mbox フォーマットです。mbox(5) (mutt パッケージが提供) を参照下さい。

欧州言語の場合、ほとんど8ビット文字が無いので ISO-8859-1 文字セットとともに "Content-Transfer-Encoding: quoted-printable" がメールに通常使われます。欧州のテキストが UTF-8 符号化された場合、ほとんどが7ビット文字なので "Content-Transfer-Encoding: quoted-printable" が大体使われます。

日本語には、テキストを7ビットにしておくために伝統的に "Content-Type: text/plain; charset=ISO-2022-JP" がメールに通常使われます。しかし、古い Microsoft システムは適正な宣言無しに Shift-JIS でメールデーターを送るかもしれません。日本語のテキストが UTF-8 で符号化される場合、多くの8ビットデーターを含むので Base64 が大体使われます。他のアジアの言語でも状況は同様です。

	注記
	もし IMAP4 サーバーと話せる非 Debian クライアントからあなたの非 Unix メールデーターがアクセス出きるなら、あなた自身の IMAP4 サーバーを実行することでメールデーターを引き出せるかもしれません。

	注記
	もし他のメールストレージフォーマットを使っている場合、mbox フォーマットに移動するのが良い第一歩です。mutt(1) のような汎用クライアントプログラムはこれに非常に便利です。

メールボックスの内容は procmail(1) と formail(1) を使って各メッセージに分割できます。

各メールメッセージは mpack パッケージにある munpack(1) (または他の専用ツール) を使って開梱して MIME 符号化された内容を取り出せます。

以下のメタパッケージは aptitude(8) を使って画像データーツールを探す良いスタート地点です。"Packages overview for Debian PhotoTools Maintainers" も別のスタート地点です。

	ヒント
	aptitude(8) の正規表現 "~Gworks-with::image" (「aptitude を使った探索方法」を参照下さい) を使ってさらなる画像ツールを探します。