netatalk.io

Netatalk 4.5.0

文字セット

文字セットの紹介

内部的には、コンピューターは文字（キャラクター）について、 テキストについて何も知らない、唯一“数字（数）”ならコンピュータにもわかる。 それ故各々の“字”には“数”が割り当てられている。文字セット、しばしば charset あるいは codepage とも呼ばれるが、これは“数”と“字”の一対一対応を規定している。

二つあるいはそれ以上のコンピューターがお互いに通信する必要がある場合、各々は同じ文字セットを使う必要がある。1960 年代には ASCII (American Standard Code for Information Interchange) 文字セットが ASA（米国標準協会：the American Standards Association）によって標準化された。 オリジナルの ASCII 形式は、英語で用いられるアルファベット及び数字を網羅するのに十分な数より多い 128 のキャラクターを表している。今日においても、ASCII はコンピューターで使われるキャラクタースキームの標準的なものである。

国際的にもっと都合よく、そして若干内輪向けの記号文字を含めるために、つづくバージョンでは 256 のキャラクターを規定した。 このエンコードの仕様だと一文字はきっちり 1 バイトに収まるが、明らかに、256 キャラクターというのは、 いろいろな言語で用いる全ての文字を一つのキャラクターに一対一対応させるのに依然十分ではなかった。

結果的には後にローカライズされた文字セットが規定された。例えば ISO-8859 文字セットである。 ほとんどのオペレーティングシステムベンダーは自らの要求を満たすために、独自の文字セットを導入した。すなわち IBM であれば コードページ 437 (DOSLatinUS)、アップルは MacRoman コードページ、などである。127 以上のキャラクターが定義されているものを拡張 キャラクターと呼ぶ。 これらの文字セットは異なるキャラクターに同じ番号をふってあるので、 他の文字セットとまたは文字セット同士で衝突を起こす。

そういった文字セットのほぼ全てが 256 個のキャラクターを定義していて、最初の 128 個（0 から 127 まで）のキャラクターを ASCII と同一対応となるようにしている。結果的に、違ったコードページを使っているシステム同士の通信では、事実上 ASCII 文字セット限定となった。

この問題を新たに解決するために、より大きい文字セットが規定された。より多くのキャラクターマッピングの場所を確保するために、 これらのキャラクターセットは一つのキャラクターの格納のために最低でも 2 バイトを使用する。 このためそういった文字セットはマルチバイト 文字セットと呼ばれる。

標準化されたマルチバイトキャラクターエンコード方式として知られているものの一つとして ユニコードがある。 マルチバイトキャラクターセット使用の大きな利点として“それ一つで済む”がある。 二つのコンピューターが通信しているときに両者が同じ文字セットを使用しているか確認する必要がない。

Apple で使われている（使われていた）文字セット

過去に Apple クライアントは、ネットワーク間の通信のためにシングルバイトのキャラクターセットを使用していた。 年を経るに従い、Apple はいくつものキャラクターセットを定義したが、欧米ユーザーは MacRoman コードセットを最もよく使用するであろう。

Apple の定義したコードページに含まれるもの：

• MacArabic, MacFarsi

• MacCentralEurope

• MacChineseSimple

• MacChineseTraditional

• MacCroatian

• MacCyrillic

• MacDevanagari

• MacGreek

• MacHebrew

• MacIcelandic

• MacJapanese

• MacKorean

• MacRoman

• MacRomanian

• MacThai

• MacTurkish

Mac OS X 以降そして AFP 3.x 以降では UTF-8 が用いられる。UTF-8 は Unicode キャラクターを ASCII 互換のやり方でエンコードする。各々の Unicode キャラクターは一個から四個のバイトにエンコードされる。 故に、UTF-8 自体が本当の文字セットなのではなく、ユニコード文字セットのエンコーディングなのである。

厄介なことにも Unicode はいくつかの normalization（正規化） 方式を規定している。Samba はほとんどの UNIX ツールも好んで用いる precomposed Unicode を使用する。一方 Apple は decomposed normalization を使うことに決めた。

例として、文字 ‘ä’（小文字aにダイエリシスがついたもの）についてみてみる。Precomposed normalization を使えば Unicode はこの文字に 0xE4 を対応付ける。Decomposed normalization では ‘ä’ を正確には 0x61 と 0x308 の二つの文字に対応付ける。0x61 は ‘a’ に、0x308 は COMBINING DIAERESISに対応付けられている。

Netatalk では precomposed UTF-8 を UTF8 と、decomposed UTF-8 を UTF8-MAC と呼ぶ。

afpd と文字セット

新しい AFP 3.x クライアントも古い AFP 2.x クライアントも同時にサポートするために、afpd は使われている様々な文字セット間の変換が可能であることを必要とした。AFP 3.x クライアントは常に UTF8-MAC を、AFP 2.x クライアントは Apple コードページのうちの一つを使う。

本稿執筆時点（訳注：原文の）で、Netatalk は以下の Apple コードページをサポートしている：

• MAC_CENTRALEUROPE

• MAC_CHINESE_SIMP

• MAC_CHINESE_TRAD

• MAC_CYRILLIC

• MAC_GREEK

• MAC_HEBREW

• MAC_JAPANESE

• MAC_KOREAN

• MAC_ROMAN

• MAC_TURKISH

afpd は三つの異なる文字セットオプションを扱う：

unix charset

オペレーティングシステムの内側で使われているコードページである。 もし指定されていなければ、デフォルトで UTF8 になる。もし LOCALE が指定されていて、 システムが UNIX locales をサポートしていれば、afpd はコードページを検出しようとし、afpd は検出したコードページを使って設定ファイルを読む。 なので、ボリューム名やログインメッセージなどに拡張文字を使うことができる。

mac charset

旧式の Mac OS クライアント（AFP 2.2 までのもの）は afpd と通信するのにコードページを用いる。しかしながら、AFP プロトコルにはクライアントが使用しているコードページの折り合いをつけるというサポートはない。 もしほかのどこかで指定されていないと、 afpd は MacRoman コードページが使われていると仮定する。 クライアントが別のコードページ、例えば MacCyrillic を使っていたならば, それを明示的に設定しなければならないだろう。

vol charset

afpd がディスク上のファイル名として使うべき charset を定義する。デフォルトでは unix charset と同じである。もし iconv がインストールしてあるならば、iconv が提供する文字セットも使用することができる。

afpd はファイルをUNIXのファイルシステムに保存する時、拡張マッキントッシュキャラクター、あるいは UNIXのファイル名として不正なキャラクターを保持する手段が必要である。初期のバージョンでは、いわゆる CAPエンコーディングを使った。拡張キャラクター (>0x7F) は :xx の16進数に変換される。例えば、アップルのロゴ (MacRoman: 0xF0) は :f0 として保存される。 いくつかの特殊なキャラクターも :xx という表記に変換される。’/’ は :2f にエンコードされる。もし、usedotsオプションが設定されていなければ、先頭のピリオド ‘.’ は :2e にエンコードされる。

本ドキュメントでのバージョンではファイル名のデフォルトエンコーディングとして UTF8 を使っているにもかかわらず、/ は : に変換される。欧米のユーザーにとって別の有用な設定として vol charset = ISO-8859-15 もあり得る。

もし、あるキャラクターが mac charset から選定した vol charset への変換ができない場合、マック上で -50 エラーを受け取るだろう。 注意： 可能な限り常に、デフォルトの UTF8 ボリュームフォーマットにしてください。