ハフマン符号系

　JIS2単位符号系では、どのキャラクタに対しても16桁のビット列が符号として割り当てられている。したがって、JIS2単位符号系を使ってテキストを記録したり通信したりする時に媒体にかかる負荷は、完全に字数だけで決定してしまう。たとえば100文字のキャラクタからなるテキストによる負荷は1600ビットになる。これは、テキストの中に含まれているキャラクタが何だろうと全く関係ない。このことは、ISO符号系でも、数の表現に使われる標準的な一括辞書順符号でも変わらない(▽図)。
　ところで、ふつうの日本語のテキストでは、ひらがなは何度も現われるけれど、漢字はそれに比べるとめったに現われない。ひらがなのうちでも、"あ"、"き"、"て"などはよく現れるが、"ぬ"、"ふ"などはそれほど現れない。だから、"あ"、"き"、"て"のようによく現われるキャラクタに対しては短い(たとえば4桁の)ビット列の符号を割り当て、漢字に対しては長い(たとえば24桁ぐらいの)符号を割り当てるようにすれば、テキスト全体では符号に使われるビットの個数をもっと減らすことができる。これは、記録や通信に使う媒体への負荷を減らすことにつながる。この考え方を徹底して作った符号系をハフマン符号系という。
　スチルは各セル(のそれぞれに対する各色成分)の明るさを集めたものとして表現されるので、同じ手法を使って媒体への負荷を減らすことができる。たとえば、もともと紙に描かれていた絵を電子化したものなら、ほとんどのセルでは明るさが(0～1の実数で表すとして)1になっている。そこで、1には短い符号を、ほかの数には長い符号を割り当てるといい。実際に、JPEGのスチルはこのような作業を経て作られている。
　ハフマン符号系は、記録や通信の効率では最高に優れている。しかし、符号の切れ目が1個ごとに違うので、復号の手間が大きくなる。また、もとの情報の集合の構造(たとえば数ならその大小)と符号の集合の構造とを対応させることはできなくなるので、加工(数の場合は足し算などの処理)には使えなくなってしまうという短所もある。しかも、あらかじめ唯一の符号系を決めておくことができないから、テキストやスチルの本体と同時に符号系の表の方も記録または通信しておかなければならない。

　きちんとしたハフマン符号系を作るには、符号化しようとしているテキストごとにキャラクタの分布を調べて、その結果に基づいて特製の符号系を作らなければならない。テキストの中に現われるキャラクタの頻度は、テキストによって微妙に異なっているからだ。分布に応じて最適な符号系を作るのはかなり面倒なので、実際には、一般的なテキスト(たとえば一般的な日本語のテキスト)を想定した共用のハフマン符号系を決めておいて、いつもそれを使うということも行なわれている。たとえば、JPEGでは各セルの各色成分の明るさを表現するのにハフマン符号系が使われているが、一般的な写真に合わせてあらかじめ準備しておいた一定の符号系が使われることが多い。

　ラテン文字用のモールス符号系(▽図左)は、ハフマン符号系の考え方をかなり意識して作られている。しかし、日本で作られたかな用のモールス符号系(同右)では、符号の長短とキャラクタの頻度とを対応させる努力が全く行なわれていない。このため、規則性がなくて、しかも媒体への負荷は減っていないという困った符号系になってしまっている。