ＭＬドライバ内部では言語と文字コードに依存した変換処理が必要です。 初期の記録も、ここに残しておきます： ＭＬドライバ内部では言語と文字コードに依存した変換処理が必要です。 (初期設計段階での内部コードは EUC のため) たとえば、ISO-2022-JP と EUC の相互変換が随所で行なわれています。 これはメールでは ISO-2022-JP が使われますが、 (UNIX 上での)プログラム(開発)では EUC が扱いやすいためです。 たとえば、 フィルタ処理や Subject 書き換え、 summary や log などに履歴を書き込む際が代表例です。 基本となるデータフローは、 (1) MIME Encode された文字列を一度 decode し、 (2) Perl 内部表現 現在の Perl 内部処理の基本は UTF-8 ベースの Perl 内部表現に変換し、 文字ベースの処理を行った上で、 バイトベースの文字列に戻すという考え方になっています。 内部表現フラグを設定しない変数は、伝統的なバイト表現だと考えます。 これにより後方互換性が保証されています。 に変換したうえで、 (3) なんらかの文字列処理をし、 (4) ふたたび MIME Encode して外部出力可能な文字列に変換する、 というものです。 [操作概念例] $string->set(); $string->mime_header_decode(); $string->...処理...(); $string->mime_header_encode(); メールの内容を変更する… メールではなく、 &fml8; システムとして summary や log ファイルへ記録を残す場合には、 MIMEエンコードはしていないので、 なんらかの文字コードを使うと決め打ちする必要があります。 ここは従来と変わりません 具体的には、 対象ごとに定義されている (例: ログファイルは $log_file_charset_ja ) 変数にしたがい、文字の符号化を行います。 日本語のデフォルト値は(互換性のため) EUC-JP です。 本章では、 言語依存処理関数について解説します。 言語依存と言っても、日本語処理ではなく、 日本語を使う文脈に依存した処理という表現が適切です。 なお、コマンドに対する返事の言語依存性については 『メッセージの他国語化』 の章を参照してください。 言語依存のクラス名は 「クラス::Language::」 となります。 これらの階層以下に言語依存モジュール群が配置されます。 たとえば次のようなモジュールがあります。 FML::Language::Japanese::String.pm Mail::Bounce::Language::Japanese.pm 前者は、FML モジュール群のために、 日本語の文脈に依存した文字列処理関数 (例: 日本語のメールでは引用に＞を使う…) を提供しています。 後者は Mail::Bounce 階層以下のモジュールに対して、 日本語に依存したエラーメール解析ルーチン (例: 日本の特定の ISP が特殊なフォーマットのエラーメールを返す…) を提供しています。