文字エンコーディング（？）などについて書かれてる文章で（？）「8ビット透過」とかありますがどのような意味でしょうか。

【8ビット透過の問題】

１オクテット(=8ビット)のうち、7ビットでASCIIの範囲は表現できるため、余っ

た１ビット分を他の用途に転用しているシステムや環境があります。このよう

なシステムを「8ビット透過ではない」と呼びます。逆に「8ビット透過である」

システムとは、8ビットをちゃんと全てデータとして扱うことができ、処理の際

に別の用途に転用されたりしないシステムだということです。今となっては

「8ビット透過」は普通のシステムです。

8ビット目をデータの一部として使用するような文字エンコーディグ(Shift JIS、

EUCなど)のテキストは、8ビット透過ではない環境では正しく処理できないことに

なります。しかし、我々日本人が使う環境やシステムでは、8ビット目を使えるよ

うに対処されており、それによる問題に直面することは、多くの場合はありません。

しかし、インターネットメールの転送システムにおいては、そのような環境が

深刻な問題になります（なることがありました）。なぜなら、インターネット

メールは、バケツリレー方式で次々とメールサーバー間でメールが転送されて

いきますが、その経路の一つにそのような8ビット透過ではないシステムが１

つでも挟まっていれば、文字化けが生じることになるからです。

とはいえ、日本語でメールを送信する際に用いられる文字エンコーディングで

あるISO-2022-JPは、8ビット目を使用することの無いエンコーディングなので、

上記のようなシステムがメール転送の途中に挟まっていても問題ありません。

というより、上記のようなシステムがあっても正しく動作するように

IOS-2022-JPが設計され、選択されていると考えても良いでしょう。

同種の理由により、SubjectやヘッダなどではMIMEエンコーディングが用いられ

ます。

まとめると、8ビット透過かどうかは、過去のある時期確かに問題であったが、

今や、8ビット透過ではないシステムは限られているので、過去の問題となりつ

つある。UTF-8などの普及により、8ビット目を使わないシステムは論外となっ

てきているので今後この問題に直面する機会はさらに少なくなっていくであろ

うと思われる。

【32ビット機から64ビット機になることの問題】

さまざまな複雑な問題が絡み合っているので、綿密に説明することは私の手に

余りますので、簡単な例を挙げるだけにとどめます。

アプリの互換性の問題としては、一般には上位互換があるように作ってあるの

で、それは64ビットだから動く／動かないとか言う問題というより、その互換

機能の制限／限界と捉えた方が良いでしょう。OSとかコンパイラとかリンカと

かの機能の問題であり、「64ビットだから原理的に動かない」ということで

はないということです。

互換性とは少し離れて、一般的な話として32ビットと64ビットの処理の違い

に関して例を挙げてみます。

64ビットアドレッシングでは、１つのデータの「場所」を表すために、64ビッ

トのデータが必要になります。つまり32ビットと比べて、あるデータを指し示

すために倍のデータ量が必要になるのです。

32ビットアドレッシングでは、100万個のデータを保持するために100万

x(32bit=4byte)つまり4メガバイトの領域で事足りていたのが、64ビットアドレッ

シングでは単純計算で8メガバイトのメモリ領域が必要になります。メモリ仮想

化によって、「メモリが足りなくなって動かない」ということは起きないかも

しれませんが、性能劣化の可能性はあります。

とはいえ、一般には、メモリが沢山あるから64ビットCPUをつかうわけで、この

ぐらいのメモリ利用容量増加は気にならない、と思うかもしれませんが、CPUの

キャッシュような、限られた領域の場合は性能劣化に直結する可能性もあるで

しょう。巨大なメモリ容量を一度に使うようなアプリケーションではない限り、

64ビットモードで動作させる場合、一般には性能が劣化すると考えた方が良い

ようです。