| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
本章では、非ASCIIに関連する特別なことがらと それらが文字列やバッファにどのように保存されるかについて述べます。
| 32.1 テキスト表現 | ||
| 32.2 テキスト表現の変換 | ||
| 32.3 表現の選択 | ||
| 32.4 文字コード | ||
| 32.5 文字集合 | ||
| 32.6 文字とバイト | ||
| 32.7 文字の分割 | ||
| 32.8 文字集合の走査 | ||
| 32.9 文字の変換 | ||
| 32.10 コーディングシステム | ||
| 32.11 入力方式 |
Emacsには2つのテキスト表現、つまり、 文字列やバッファでテキストを表す方法が2つあります。 これらは、ユニバイト（unibyte）と マルチバイト（multibyte）と呼ばれます。 各文字列や各バッファでは、これらの2つの表現の一方を使います。 ほとんどの目的には、Emacsがこれらのあいだで適切に変換するので、 読者はこれらの表現に関しては無視できます。 Lispプログラムでは、これらの違いに注意する必要がしばしばあります。
ユニバイト表現では、各文字は1バイトを占め、
そのため、可能な文字コードの範囲は0から255です。
コード0から127はASCII文字です。
コード128から255は非ASCII文字集合の1つ
（変数nonascii-insert-offsetに設定して文字集合を選べる）
に使われます。
マルチバイト表現では、1文字は1バイト以上を占め、 そのため、Emacsの文字コードの範囲全体を格納できるのです。 マルチバイト文字の最初のバイトはつねに128から159（8進数で0200から0237）の 範囲にあります。 これらの値をリーディングコード（leading code）と呼びます。 マルチバイト文字の2バイト以降はつねに160から255（8進数で0240から0377）の 範囲にあります。 これらの値をトレイリングコード（trailing code）と呼びます。
バッファでは、変数enable-multibyte-charactersの
バッファローカルな値が使用する表現を指定します。
文字列の表現は、文字列を作成するときの文字列の内容に基づいて決定されます。
nil以外であると、バッファはマルチバイトテキストを保持する。
さもなければユニバイトテキストを保持する。
この変数に直接設定することはできない。
そのかわりに、バッファの表現を変更するには、
関数set-buffer-multibyteを使う。
(default-value 'enable-multibyte-characters)に完全に等価であり、
この変数に設定するとデフォルト値を変更する。
バッファのenable-multibyte-charactersのローカルな束縛に設定することは
許されていないが、デフォルト値を変更することは可能であり、
そうしても既存のバッファには影響しないので理にかなっている。
コマンド行オプション`--unibyte'は、
起動時の早い段階でデフォルト値にnilを設定することで役目を果たす。
tを返す。
Emacsはユニバイトテキストをマルチバイトに変換できます。 マルチバイトテキストをユニバイトにも変換できますが、 この変換では情報が欠落します。 バッファにテキストを挿入するとき、あるいは、 複数の文字列から1つの文字列にテキストを収めるときに、 一般にこれらの変換が行われます。 文字列の内容をどちらかの表現に明示的にも変換できます。
Emacsは、文字列を作成するときにはその内容に基づいて 文字列の表現を選びます。 一般則は、ユニバイトテキストを他のマルチバイトテキストに組み入れるときには ユニバイトテキストをマルチバイトテキストに変換します。 マルチバイト表現のほうが汎用であり、 ユニバイトテキストのどんな文字でも保持できるからです。
バッファにテキストを挿入するときには、Emacsは、
当該バッファのenable-multibyte-charactersの指定に従った
バッファの表現にテキストを変換します。
特に、ユニバイトバッファにマルチバイトテキストを挿入するときには、
マルチバイトテキスト内のすべての文字を一般には保存できなくても、
Emacsはテキストをユニバイトに変換します。
自然な代替案はバッファ内容をマルチバイトに変換することですが、
これは受け入れられません。
バッファの表現はユーザーが選択したものであり自動的には無視できないからです。
ユニバイトテキストをマルチバイトテキストに変換しても
ASCII文字は無変更であり、128から159も同様です。
160から255の非ASCIIについては、
各文字にnonascii-insert-offsetの値を加算することで変換します。
この変数に設定すると、ユニバイト文字がどの文字集合に対応するかを指定できます
（see section 32.5 文字集合）。
たとえば、nonascii-insert-offsetが
(- (make-char 'latin-iso8859-1) 128)の2048であると、
非ASCIIのユニバイトはLatin 1に対応します。
(- (make-char 'greek-iso8859-7) 128)の2688であると、
ギリシャ文字に対応します。
マルチバイトテキストをユニバイトに変換するのは簡単で、
各文字コードと255の論理積をとります。
nonascii-insert-offsetに
文字集合の始まりに対応する合理的な値が設定されていれば、
この変換は逆変換になります。
つまり、ユニバイトテキストをマルチバイトに変換し、
それをユニバイトに戻すともとのユニバイトテキストになります。
self-insert-commandにも適用される。
しかし、関数insert-charはこの変換を行わない。
文字集合csを選択する正しい値は、
(- (make-char cs) 128)である。
nonascii-insert-offsetの値が0であると、
実際の変換には0ではなくLatin 1文字集合に対する値を使う。
nonascii-insert-offsetのより一般的な代替を提供する。
128から255の範囲の各コードをマルチバイト文字に変換する方法を
独立して指定するために使える。
その値はベクトルかnilであること。
これがnil以外であると、nonascii-insert-offsetに優先する。
既存のバッファや文字列がユニバイトであるときに マルチバイトとして調べたり、その逆のように調べるのが 有用なこともあります
nil以外であると、バッファはマルチバイトになる。
multibyteがnilであると、バッファはユニバイトになる。
この関数は、バイト列としてみたバッファ内容を変更しない。 その結果、文字として見たときの内容を変更できる。 マルチバイト表現では1文字とみなされる2バイトの列は、 ユニバイト表現では2文字になる。
この関数は、enable-multibyte-charactersに
どちらの表現を使用しているかを記録する。
さらに（オーバレイ、テキスト属性、マーカなどの）バッファ内のさまざまな
データを調整して、それ以前と同様に同じテキストに及ぶようにする。
stringがすでにユニバイトであると、 値はstringそのものである。
stringがすでにマルチバイトであると、 値はstringそのものである。
ユニバイトとマルチバイトのテキスト表現では、 異なる文字コードを使っています。 ユニバイト表現において正しい文字コードは0から255の範囲であり、 これらの値は1バイトに収まります。 マルチバイト表現において正しい文字コードは0から524287の範囲ですが、 この範囲のすべての値が正しいとは限りません。 特に、値128から255は （『生のバイト』にはありうる。see section 32.10.7 明示的な符号化と復号化）、 マルチバイトテキストでは正しくありません。 0から127のASCIIコードのみが、どちらの表現でも完全に正しいのです。
tを返す。
(char-valid-p 65)
=> t
(char-valid-p 256)
=> nil
(char-valid-p 2248)
=> t
|
Emacsは文字をさまざまな文字集合（character set）に分類します。 文字集合にはシンボルである名前があります。 各文字はたった1つの文字集合に属します。
一般に、異なる文字体系ごとに1つの文字集合があります。
たとえば、latin-iso8859-1は1つの文字集合であり、
greek-iso8859-7は別の文字集合であり、
asciiも別の文字集合です。
Emacsの1つの文字集合には最大9025個の文字を保持できます。
したがって、論理的には1つの文字集合にまとめられる文字群を、
複数の文字集合に分割する場合もあります。
たとえば、Big 5として一般には知られている中国文字の1つの集合は、
Emacsの2つの文字集合、chinese-big5-1とchinese-big5-2に
分割されます。
tを返す。
さもなければnilを返す。
マルチバイト表現では、各文字は1バイトかそれ以上のバイトを占めます。 各文字集合には、通常は1バイト長か2バイト長の 導入列（introduction sequence）があります （例外：ASCIIの導入列は0バイト長である）。 導入列は、文字集合の任意の文字のバイト列の始まりです。 文字のバイト列の残りの部分は、同じ文字集合内で他の文字とその文字を区別します。 文字集合に依存して、区別するためのバイトは1バイトか2バイトです。 そのようなバイト数を文字集合の次元（dimension）と呼びます。
文字集合の導入列のバイト長を判定するもっとも簡単な方法はつぎのとおりです。
(- (char-bytes (make-char charset)) (charset-dimension charset)) |
本節の関数は、文字とそれを表現するために用いられるバイト値のあいだの 変換を行います。 ほとんどの目的に関しては、Emacsが必要に応じて自動的に行うため、 文字を表現するためのバイト列を扱う必要はありません。
(char-bytes 2248)
=> 2
(char-bytes 65)
=> 1
(char-bytes 192)
=> 1
|
マルチバイト表現とユニバイト表現のどちらに対しても この関数で正しい結果を得られるのは、 2つの表現で用いられる非ASCII文字コードに重なりがないからである。
(split-char 2248)
=> (latin-iso8859-1 72)
(split-char 65)
=> (ascii 65)
|
ユニバイトの非ASCII文字は、
文字集合asciiの一部とみなす。
(split-char 192)
=> (ascii 192)
|
split-charのほぼ逆関数にあたる。
通常、文字集合charsetの次元に応じて、
1つか2つのbyte-valuesを指定する。
たとえばつぎのとおり。
(make-char 'latin-iso8859-1 72)
=> 2248
|
byte-valuesを指定せずにmake-charを呼び出すと、
その結果は文字集合charsetを代表する
汎用文字（generic character）である。
汎用文字は整数であるが、文字としてバッファに挿入するには
正しくないものである。
1つの文字集合全体を表すためにchar-table-rangeで使える
（see section 6.6 文字テーブル）。
char-valid-pは汎用文字に対してはnilを返す。
たとえばつぎのとおり。
(make-char 'latin-iso8859-1)
=> 2176
(char-valid-p 2176)
=> nil
(split-char 2176)
=> (latin-iso8859-1 0)
|
バッファや文字列の一部分にどの文字集合が現れるかを 調べられると有用なことがあります。 その1つの用途は、当該テキストすべてを表現する能力がある コーディングシステム（see section 32.10 コーディングシステム）を探すことです。
省略可能な引数translationは、
テキストを走査するときに使用する変換表を指定する
（see section 32.9 文字の変換）。
これがnil以外であると、領域内の各文字をこの表を介して変換し、
戻り値は、バッファ内の実際の文字のかわりに変換した文字に関する情報を与える。
省略可能な引数translationは変換表を指定する。
上記のfind-charset-regionを参照。
変換表（translation table）は、文字群を文字群へ対応付けます。 これらの表は、符号化と復号化、他の目的に使われます。 独自の変換表を指定するコーディングシステムもあります。 他のすべてのコーディングシステムに適用される デフォルトの変換表もあります。
(from . to)の形であり、
文字fromをtoへ変換することを意味する。
1つの文字集合全体を同じ次元の別の文字集合へ対応付けることも可能である。 それには、fromに（文字集合を表す）汎用文字を指定する （see section 32.7 文字の分割）。 この場合、toも、同じ次元の別の文字集合の汎用文字であること。 こうすると、この変換表は、fromの文字集合の各文字を toの文字集合の対応する文字へ変換する。
復号化では、もとの復号化結果の文字に変換表による変換を適用します。
コーディングシステムに属性character-translation-table-for-decodeが
あれば、これは使用する変換表を指定します。
さもなければ、standard-character-translation-table-for-decodeが
nil以外であれば、復号化ではその表を使います。
符号化では、バッファ内の文字に変換表による変換を適用し、
変換結果を実際に符号化します。
コーディングシステムに属性character-translation-table-for-encodeが
あれば、これは使用する変換表を指定します。
さもなければ、変数standard-character-translation-table-for-encodeが
使用する変換表を指定します。
Emacsがファイルを読み書きしたり、 Emacsがサブプロセスへテキストを送ったり サブプロセスからテキストを受け取るときには、 コーディングシステム（coding system）で指定される 文字コード変換と行末変換を行います。
文字コード変換（character code conversion）とは、 Emacsの内部で使用する符号と他の符号とのあいだでの変換のことです。 Emacsでは、相互に変換できる多くの異なる符号を扱えます。 たとえば、Emacsは、Latin 1、Latin 2、Latin 3、Latin 4、Latin 5、 ISO 2022のいくつかの変種を相互に変換できます。 同じ文字集合に対する異なる符号を扱うこともできます。 たとえば、キリル（ロシア語）文字に対しては ISO、Alternativnyj、KOI8の3つのコーディングシステムがあります。
ほとんどのコーディングシステムでは変換する文字コードを特定しますが、 指定せずにデータに基づいて発見的手法で選ぶものもあります。
行末変換（end of line conversion）は、 ファイル内の行の終りを表すさまざまなシステムで 使われている3つの異なる慣習を扱います。 UNIXの慣習では、行送り文字（改行文字とも呼ぶ）を使います。 DOSの慣習では、行末には復帰と行送りの2文字の列を使います。 Macの慣習では、復帰のみを使います。
latin-1のような基底コーディングシステム（base coding system）
では、行末変換を指定せずにデータに基づいて選びます。
latin-1-unix、latin-1-dos、latin-1-macのような
変種コーディングシステム（variant coding system）では、
明示的に行末変換も指定します。
ほとんどの基底コーディングシステムには、
`-unix'、`-dos'、`-mac'を付加して作られる名前の
対応する3つの変種があります。
コーディングシステムraw-textは
文字コード変換を行わない特別なもので、
このコーディングシステムで訪問したバッファはユニバイトバッファになります。
行末変換も指定しないので内容に基づいて決定でき、
行末変換を指定する3つの変種もあります。
no-conversionはraw-text-unixに等価であり、
文字コードも行末も変換しないことを指定します。
コーディングシステムemacs-muleは、
Emacs内部での符号でデータを表現することを指定します。
これは、コード変換を行わないという意味ではraw-textに似ていますが、
結果がマルチバイトデータになる点が異なります。
mime-charsetがある。
この属性の値は、当該コーディングシステムで読み書きする
文字コード向けのMIMEに使用する名前である。
(coding-system-get 'iso-latin-1 'mime-charset)
=> iso-8859-1
(coding-system-get 'iso-2022-cn 'mime-charset)
=> iso-2022-cn
(coding-system-get 'cyrillic-koi8 'mime-charset)
=> koi8-r
|
属性mime-charsetの値は、
コーディングシステムの別名としても定義されている。
コーディングシステムの主目的は、ファイルの読み書きに使うことです。
関数insert-file-contentsはファイルのデータを復号化するために
コーディングシステムを使い、
write-regionはバッファ内容を符号化するために
コーディングシステムを使います。
使用するコーディングシステムを明示する（see section 32.10.6 1つの操作向けにコーディングシステムを指定する）
こともできるし、
デフォルトの機構（see section 32.10.5 デフォルトのコーディングシステム）を暗に使うこともできます。
しかし、これらの方式ではすべきことを完全に指定しきれないこともあります。
たとえば、undefinedのようなコーディングシステムを選んで、
データに基づいて文字コード変換を行うようにするかもしれません。
そのような場合、コーディングシステムの選択は
入出力操作によって完了します。
しばしば、選択されたコーディングシステムをあとで知りたくなります。
write-regionでバッファの一部を書くときに使われる。
これらの操作において、ユーザーに別のコーディングシステムを指定するように
問い合わせた場合には、buffer-file-coding-systemは
指定された別のコーディングシステムに更新される。
write-regionには使わないが、
バッファを保存するために使うコーディングシステムを指定する。
バッファを保存する際に、ユーザーに別のコーディングシステムを指定するように
問い合わせ、かつ、save-buffer-coding-systemを用いている場合には、
これは指定された別のコーディングシステムに更新される。
警告：
サブプロセスから出力を受け取るとこの変数が設定されるため、
Emacsが待つたびに変化する可能性がある。
したがって、読者の興味がある値を保存するような関数を呼び出した直後に
その値をコピーして使うこと。
変数selection-coding-systemは、
ウィンドウシステムのセレクションを符号化する方法を指定します。
See section 28.18 ウィンドウシステムのセレクション。
コーディングシステムを扱うLispの機能について述べます。
nil以外であると、
値には基底コーディングシステムのみを含める。
さもなければ、値には変種コーディングシステムも含まれる。
tを返す。
coding-system-error付きのエラーを通知する。
eol-typeで指定された行末変換のものである。
eol-typeは、unix、dos、mac、nilの
いずれかであること。
nilであると、返されたコーディングシステムは、
データから行末変換を決定する。
nilであると、
undecidedかeol-codingに応じたundecidedの変種の1つを返す。
テキストにマルチバイト文字が含まれない場合、
関数はリスト(undecided)を返す。
(undecided)を返す。
この関数は、通常、走査したテキストの復号化を扱える
コーディングシステムのリストを返す。
それらは優先順位の降順に並ぶ。
しかし、highestがnil以外であると、
戻り値はもっとも順位の高い1つのコーディングシステムである。
領域にASCII文字だけが含まれる場合、
値はundecidedか(undecided)である。
detect-coding-regionと同様であるが、
バッファ内のバイトのかわりに文字列stringの内容に作用する。
サブプロセスとの入出力に使用されるコーディングシステムを 調べたり設定する方法については、See section 36.6 プロセス情報。
省略可能な引数preferred-coding-systemは、
最初に試すコーディングシステムを指定する。
それが指定領域のテキストを処理できるならば、それを使う。
この引数を省略すると、
buffer-file-coding-systemのカレントバッファでの値をまず試す。
領域内にpreferred-coding-systemで符号化できない マルチバイト文字がある場合、 この関数は、当該テキストを符号化可能なコーディングシステム一覧から ユーザーに選択してもらい、ユーザーが選択したものを返す。
特殊機能： fromが文字列であると、
文字列を調べる対象とし、toは無視する。
補完を用いてユーザーにコーディングシステムを指定させるために使える 2つの関数はつぎのとおりです。 See section 19.5 補完。
本節では、特定のファイルや特定のサブプログラムを実行するときの デフォルトのコーディングシステムを指定する変数と、 それらを使った入出力操作を行う関数について述べます。
これらの変数の目的は、読者が望むデフォルトをいったんこれらに設定しておけば、
再度変更する必要がないようにすることです。
Lispプログラムの特定の操作向けに特定のコーディングシステムを指定するには、
これらの変数を変更しないでください。
かわりに、coding-system-for-readやcoding-system-for-writeを
使って上書きします（see section 32.10.6 1つの操作向けにコーディングシステムを指定する）。
(pattern . coding)の形であり、
patternは特定のファイル名に一致する正規表現である。
patternに一致するファイル名に当該要素を適用する。
要素のCDR、codingはコーディングシステムであるか、 2つのコーディングシステムを収めたコンスセルであるか、 関数シンボルであること。 codingがコーディングシステムであると、 ファイルの読み書きの両方にそのコーディングシステムを使う。 codingが2つのコーディングシステムを収めたコンスセルであると、 そのCARは復号化に使うコーディングシステムを指定し、 そのCDRは符号化に使うコーディングシステムを指定する。
codingが関数シンボルであると、 その関数は、コーディングシステムか、 2つのコーディングシステムを収めたコンスセルを返すこと。 その値は上に述べたように使われる。
file-coding-system-alistと同様に働くが、
patternはサブプロセスを始めるために用いたプログラム名に対して
一致を取る点が異なる。
この連想リストに指定したコーディングシステムは、
サブプロセスとの入出力に使用するコーディングシステムの初期化に用いれるが、
set-process-coding-systemを使って、
あとで別のコーディングシステムを指定できる。
警告：
データからコーディングシステムを決定するundecidedのような
コーディングシステムは、非同期サブプロセスの出力に対しては
完全に信頼性のある動作はできない。
これは、Emacsが非同期サブプロセスの出力が
到着するたびに一塊で処理するからである。
コーディングシステムが文字コード変換や行末変換を未指定にしていると、
Emacsは1つの塊から正しい変換を検出しようと試みるが、
これがつねに動作するとは限らない。
したがって、非同期サブプロセスでは、可能な限り
文字コード変換と行末変換の両方を指定したコーディングシステムを使います。
つまり、undecidedやlatin-1などではなく、
latin-1-unixのようなものを使います。
file-coding-system-alistと同様に働くが、
要素内のpatternはポート番号か正規表現である点が異なる。
それが正規表現であると、ネットワークストリームを開くために
使用したネットワークサービス名に対して一致をとる。
値は、(input-coding . output-coding)の形の
コンスセルであること。
ここで、input-codingはサブプロセスからの入力に適用され、
output-codingはそれへの出力に適用される。
(decoding-system encoding-system) |
第1要素decoding-systemは （operationが復号化を行う場合には）復号化に用いる コーディングシステムであり、 encoding-systemは （operationが符号化を行う場合には）符号化に用いる コーディングシステムである。
引数operationは、Emacsの入出力基本関数の
insert-file-contents、write-region、call-process、
call-process-region、start-process、
open-network-streamのいずれかであること。
残りの引数は、これらの入出力基本関数に指定するであろう引数と同じであること。
基本関数に依存して、引数の1つを対象として選ぶ。
たとえば、operationがファイル入出力を行う場合、
ファイル名を指定する引数が対象である。
サブプロセスの基本関数では、プロセス名が対象である。
open-network-streamでは、サービス名やポート番号が対象である。
この関数は、operationに応じて当該対象を
file-coding-system-alistや
process-coding-system-alistや
network-coding-system-alistで探す。
see section 32.10.5 デフォルトのコーディングシステム。
変数coding-system-for-readと／やcoding-system-for-writeを
束縛することで、特定の1つの操作向けのコーディングシステムを指定できます。
nil以外であると、
ファイルを読むときや同期プロセスからの入力に用いる
コーディングシステムを指定する。
これは非同期プロセスやネットワークストリームにも適用されるが、
異なった方法で適用される。
サブプロセスを開始したりネットワークストリームを開いたときの
coding-system-for-readの値は、
そのサブプロセスやネットワークストリームの入力の復号化方法を指定する。
変更されない限り、そのサブプロセスやネットワークストリームに
対して使われ続ける。
この変数の正しい使い方は、特定の入出力操作に対して
letで束縛することである。
そのグローバルな値は通常はnilであり、
グローバルにこれ以外の値を設定するべきではない。
この変数の正しい使い方の例をつぎに示す。
;; 文字コード変換せずにファイルから読む ;; CRLFが行末を表すと仮定する (let ((coding-system-for-write 'emacs-mule-dos)) (insert-file-contents filename)) |
その値がnil以外であると、
coding-system-for-readは、
file-coding-system-alist、
process-coding-system-alist、network-coding-system-alist、
を含めて入力に用いるコーディングシステムの
他のすべての指定方法に優先する。
coding-system-for-readと同様に働くが、
入力ではなく出力に適用される点が異なる。
ファイル、サブプロセス、ネットワーク接続へ書くことに影響する。
call-process-regionとstart-processのように、
1つの操作で入力と出力を行うときには、
coding-system-for-readとcoding-system-for-writeの
両方が影響する。
nil以外であると、
コーディングシステムでなにが指定されていようと行末変換を行わない。
これは、Emacsの入出力とサブプロセスのすべての基本関数、
明示的な符号化／復号化関数（see section 32.10.7 明示的な符号化と復号化）に適用される。
Emacsへ／からテキストを転送するすべての操作には、 テキストを符号化したり復号化するコーディングシステムを使う能力があります。 本節に述べる関数を用いてテキストを明示的に符号化したり復号化できます。
符号化の結果と復号化する入力は、通常のEmacsのテキストではありません。
それらは『生のバイト』、つまり、外部ファイルと同じ方法で
テキストを表現するバイト列です。
バッファに生のバイトが収められている場合、
set-buffer-multibyte（see section 32.3 表現の選択）を用いて
バッファはユニバイト表現であると印を付けるのがもっとも自然ですが、
これは必須ではありません。
バッファの内容が単に一時的に生のバイトであるときには、
バッファはマルチバイトのままにしておきます。
バッファ内容を復号化すれば正しくなります。
明示的に復号化するためにバッファに生のバイトを入れる普通の方法は、
insert-file-contents-literally（see section 24.3 ファイルの読み込み）で
ファイルから読むか、
find-file-noselectでファイルを訪問するときに引数rawfileに
nil以外を指定します。
テキストの明示的な符号化で得た結果である生のバイトを使う普通の方法は、
ファイルやプロセスへそれらをコピーします。
たとえば、write-region（see section 24.4 ファイルへの書き出し）でそれらを書くには、
coding-system-for-writeにno-conversionを束縛して
write-regionの符号化を抑制します。
生のバイトには、正しいマルチバイト文字に 余分なトレイリングコードが付いたように見える長すぎるバイト列が 含まれる場合があります。 ほとんどの目的には、バッファや文字列のそのような列をEmacsは1文字として扱い、 その文字コードを調べるとマルチバイト文字の列に対応した値を得るはずです。 余分なバイト列は無視されます。 このふるまいは透明性がよくありませんが、 生のバイトはEmacsの限定された場面でのみ使われ、実用上の問題は回避できます。
Emacsは、コーディングシステムを用いてキーボード入力を復号化したり、
端末出力を符号化できます。
Latin-1などの特定の符号を用いてテキストを送信したり表示する
端末に対しては、これは有用です。
Emacsは、端末に対する符号化や復号化では
last-coding-system-usedに設定しません。
nilを返す。
nilであると、
キーボード入力に復号化を用いないことを意味する。
nilを返す。
nilであると、
端末出力に符号化を用いないことを意味する。
MS-DOSやMS-Windows上のEmacsは、 特定のファイル名をテキストファイルやバイナリファイルとして認識します。 『バイナリファイル』とは、必ずしも文字を意味しないバイト値のファイルです。 Emacsは、バイナリファイルに対しては行末変換や文字コード変換を行いません。 一方、その名前から『テキストファイル』と印が付いた 新規ファイルを作成すると、EmacsはDOSの行末変換を行います。
buffer-file-coding-systemで
コーディングシステムを指定しない場合、
バッファ内容を書き出すときに用いるコーディングシステムを
この変数を用いて決定する。
テキストに対してはnil、バイナリに対してtであること。
これがtであると、コーディングシステムはno-conversionである。
さもなければ、undecided-dosを用いる。
通常、この変数はファイルを訪問すると設定される。
いかなる変換も行わずにファイルを訪問するとnilに設定される。
nil、
バイナリファイルではt、あるいは、
どちらであるかを計算するために呼び出す関数である。
それが関数であると、1つの引数（ファイル名）で呼ばれ、
tかnilを返すこと。
MS-DOSやMS-Windowsで動作しているEmacsは、
この連想リストを調べて、ファイルを読む際に使用する
コーディングシステムを決定する。
テキストファイルではundecided-dosが使われる。
バイナリファイルではno-conversionが使われる。
指定したファイルがこの連想リストの要素に一致しないと、
default-buffer-file-typeがファイルの扱い方を指定する。
file-name-buffer-file-type-alistが指定しない型の
ファイルの扱い方を指定する。
この変数がnil以外であると、そのようなファイルはバイナリとして扱われ、
コーディングシステムno-conversionを用いる。
さもなければそれらに対して特別なことを行わずに、
Emacsの通常のとおりにファイル内容からコーディングシステムを決定する。
入力方式（input method）は、 キーボードから非ASCII文字を入力する簡便な方法を提供します。 プログラムが読み取るための非ASCII文字の符号変換を行う コーディングシステムと異なり、 入力方式は人間向けのコマンドを提供します。 （テキストを入力するための入力方式の使い方については、 see section `入力方式' in GNU Emacs マニュアル。） 入力方式の定義方法については本書ではまだ明文化してありませんが、 ここではそれらの使い方について述べます。
各入力方式には名前があります。 それは現在のところ文字列ですが、 将来は入力方式名としてシンボルも使えるようになります。
nilであると、バッファでは入力方式が活性ではない。
current-input-methodと異なり、この変数は通常はグローバルである。
default-input-methodにもinput-methodを設定する。
input-methodがnilであると、
この関数はカレントバッファの入力方式を不活性にする。
nil以外であると、
ユーザーが空の入力をするとデフォルトでこれを返す。
しかし、inhibit-nullがnil以外であると、
空の入力はエラーを通知する。
戻り値は文字列である。
(input-method language-env activate-func title description args...) |
ここで、input-methodは入力方式名であり文字列である。 language-envも別の文字列であり当該入力方式を 推奨する言語環境の名前である。 （これは説明文目的のためだけである。）
titleは、この入力方式が活性である場合に モード行に表示される文字列である。 descriptionはこの入力方式と何向きであるかを 説明する文字列である。
activate-funcは、この入力方式を活性にするために呼び出す関数である。 argsがあればactivate-funcへの引数として渡される。 つまり、activate-funcの引数はinput-methodとargsである。
入力方式に対する基本的なインターフェイスは
変数input-method-functionを介して行います。
See section 20.6.2 単一イベントの読み取り。
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |