仏典をコンピュータで扱おうとすると、表示できる漢字の制限に引っかかります。
「ない｣文字は外字を作ってしまえばとりあえず表示できますが、そうすると、データの互換性の問題が避けられなくなります。当サイトではデーバナーガリーも扱っており、その関係もあって、文字コードについて勉強し直しました。
コンピュータの内部では、文字といっても、すべて文字コードと呼ばれる「番号」で扱われています。まず、文字コードと実際の文字との関係から整理しましょう。
文字コードという「数値」で表されているものを、「文字」として画面に表示するには、字形のデータが必要になります。個々の文字の字形データをグリフ、文字コード一式分のデザインの揃ったグリフをフォントと呼びます。ＭＳ 明朝、ＭＳ ゴシックなどが、フォントの実例です。ゴシック体の 字 も明朝体の 字 も、文字コードは同じなのです。
その上で、どのように文字コードを割り当てるか、もう少し正確に表すならば、どの文字を「同じ」と考え、どの文字を「異なる」とみなすか、ということが問題になります。漢字で、旧字体や異体字を扱うときなどが該当します。
漢字を中心に考えている限り、字体が別ならばすべて異なる文字コードを割り振ればよさそうに考えてしまいます。しかし、そもそも「字体が別」ということがどういうことかということから整理しなくてはなりません。
、
は実際に別の文字コードが割り振られ、その意味で「別字」と扱われています。
、
も、通常使うことは少ないでしょうが、（ユニコードでは）別の文字コードを持っています。しかし 
、
は、現時点で個別の文字コードを割り当てられていません。『今昔文字鏡』というソフトウェアには、「竜」の関連字だけで、42 文字が収録されています。すべて別の文字としてしまうと、文字コードが膨大になるだけでなく、文書の検索時などに、「龍之介｣は検索できるけれども「竜之介｣は見落とす、などといったことになりかねません。つまり、区別しすぎると、同じで「も」あるという情報が隠れてしまうのです。
ここで話をがらりと変え、「文字」そのものについての整理をします。
漢字は「表意文字」です。表意文字の場合、文字コードをどうするかは、極論すれば量の問題になります。力技で、「すべての異なる字体に、異なる文字コードを割り振る」ということも、やってできなくはありません。ところが、表音文字の方にかえって、コード化するにはやっかいな問題があるのです。
表音文字の歴史をたどってみると、当初の絵文字（表意文字）が、意味を離れ、冒頭の音のみを表す「音節文字」として用いられ始めたことが母胎になります。そこから、音節文字が母音を捨て、子音のみを表す「単子音文字」となって、実用的な表音文字となりました。フェニキア文字や、現在でも用いられるヘブライ文字などが単子音文字です。表音文字が生まれるには、母音が少なくて、子音だけ並べれば見当がついたというセム系言語の特徴が、重要なファクタだったのです。
ギリシア人もフェニキア文字を借用しました。しかしギリシア語には母音が７つあったため、ギリシア語に必要のない子音字を母音に転用するようになりました。そのようにして成立した文字を「音素文字」と呼びます。ギリシア文字はじめ、ローマ字やキリル文字はすべて音素文字です。
表音文字にはもう１種類、「結合音節文字」と呼ばれるものがあります。子音を表す文字要素に、母音を表す文字要素が合体して、１つの文字となります。デーバナーガリーなどのインド・東南アジア系の文字や、ハングルが結合音節文字の例です。
結合音節文字であるデーバナーガリーでは、「文字の真ん中」で単語が区切れていることが少なくありません。これでは、字体の違いに立脚して文字コードを割り当てると、単語の検索が非常に複雑な処理になってしまいます。
結合音素文字のコード化はまだ錯綜段階で、国・言語によってまったく異なるアプローチがされています。韓国では、ハングルの別の字体ごとに別のコードを割り振る、漢字の場合と同様な方法を採っていますが、インドでは、文字から抽象した「音素」にコードを割り当てています。画面表示上の一文字が、「文字コード」としては複数なのです。
続いて、現在用いられている文字コードの規格を概観しておきましょう。
まず、漢字などの特殊な文字を考えず、アルファベットの大文字・小文字と数字、若干の記号類だけをコード化したものを、ＡＳＣＩＩ（アスキー、American Standard Code for Information Interchange）コードと言います。
次に日本語の漢字を中心に考えた場合、ＪＩＳコードがベースになります。しかしＪＩＳコードも改訂を重ねており、78JIS（旧ＪＩＳ）と 83JIS（新ＪＩＳ）だけでも、同じ文字コードで「鶯｣と「鴬」の字体が入れ替わっているなど、互換性が保証されていない点はあちこちにあります。
ＪＩＳコードで表された文字をＡＳＣＩＩ コードと共存させるには、漢字の前後に特別な制御コードを付加するなどの追加処理が必要になります。それを避けるために考案されたのがシフトＪＩＳで、ＡＳＣＩＩ コードと競合しない範囲にＪＩＳコードを並行移動（シフト）したような形になっています。確かに文字の扱いの上ではＪＩＳコードよりも楽なのですが、拡張性がまったくなく、そのためＪＩＳ補助漢字（90JIS）の普及を妨げたなど、問題も生みました。
Windows 98 以降、マイクロソフト社はユニコードというコード体系を打ち出し、今はそれが広まりつつある段階です。ユニコードを用いると、たとえば『浄土真宗聖典』をすべてテキスト化する場合、ＪＩＳの枠内では 244 文字にのぼる「未定義文字」が、26 文字まで減ります（拡張Ａまで実装された場合）。
しかし、ユニコードという規格はアメリカのフォント関係者が唱導したもので、いろんなところに米国の都合がちらついている代物なのです。ユニコードに押し切られたような形で全く普及していないのですが、仮に ＪＩＳ拡張漢字（97JIS）が使えるようになっていたとすれば、外字で対応するしかない漢字はもっと少なくて済みました。ユニコード万歳、という訳ではありません。
このほか、Windows 外字や IBM 拡張漢字なども互換性を妨げる要因として取り上げる必要がありますが、いささか長くなったので割愛しましょう。なお、Unix 系 OS で用いられている文字コードの EUC には触れませんでした。
最後に、当サイトでの文字コードの扱いについて簡単に紹介しておきましょう。試行錯誤の末、当サイトのデータは、文字コードはできるだけ共通にしたまま、適用するフォントを変えることで字体を変えるという方法を採っています。たとえば、『大笑小笑』では旧字や異体字をふんだんに使っていますが、入力は通常の新字で行っており、それを「大笑小笑明朝.ttf」で表示すると旧字・異体字で表示されるのです。
【直接参照した資料：加藤弘一『図解雑学 文字コード』（ナツメ社）、『今昔文字鏡 単漢字10万字版』（紀伊国屋書店）】