現在のHTMLの仕様であるHTML2.0[5]では，文書中に使用できる文字セットをISO-10646に含まれる文字としているが，その符号化の方法については定めていない． 実際には，例えば日本語の場合，現在のところISO-2022-JP（JISコードあるいはjunetコードなどと呼ばれる），シフトJIS，EUC（Extended Unix Code）の3種類の符号化方法が用いられている． 符号化方法の判別のためにHTTP（Hypertext Transfer Protocol）[6]ではContent-Typeヘッダにcharsetパラメータが用意されているが，現状ではこれを使用するWWWサーバはほとんどないため，ブラウザ側で明示的に符号化方法を指定する必要がある[7]．
また現在使用されているほとんどの符号化方法は一言語あるいは二言語のみの使用を前提としているため，複数の言語を一文書中に混在させることはできない． これを可能にする符号化方法としては，ISO-2022に基づいて複数の文字セットをエスケープシーケンスによって切り替えるISO-2022-JP-2[8]，ISO-10646の文字セットの一部を1文字16ビットの固定長で符号化するUnicode（ISO-10646-1）などがある． しかし，ISO-2022-JP-2は文字セットの切り替えが必要なためアプリケーションでの処理が複雑になるという欠点がある． またUnicodeについても，2バイトのコード領域の不足や日中韓の漢字のユニフィケーションなど多くの問題点が指摘されており，どちらも広く使われるまでには至っていない．
また文字セットあるいは符号化とは別の問題として，フォントの問題がある． WWWブラウザが複数の言語の表示に対応していてもユーザの端末上にフォントがなければ，正常に表示されず，いわゆる文字化けという現象が起こる． 例えば，欧米で使われているコンピュータ上に日本語のフォントがインストールされていることは稀で，WWWブラウザが日本語の表示に対応していても，フォントがないために日本語の文書を読むことができない． 同様に日本のコンピュータでは中国語や韓国語の文書を読むことができない． またマイナーな言語の文字や異体字，古典文字なども，ユーザの端末側に対応するフォントが用意されていることは期待できない．
フォントをインストールせずに多言語からなる文書の表示を実現する方法として，文書の文字部分を一文字毎あるいは数文字分まとめてインラインイメージに変換する方法（図
），ページ全体を一枚のインラインイメージに変換し，リンクをクリッカブルマップで実現する方法（図）などが考えられる．
前者の方法は実際にDeleGate
に付属のCII（Character by Inline Image）ライブラリ，およびShodoukaで実現されている．
ただしこれらの方法では，一文字あるいは数文字単位でネットワークのコネクションを張る必要があるため，一文書に必要なコネクション回数が多数となる． 現在のインターネット上ではこのコネクション回数が大きなネックとなり，ある程度以上大きな文書では，文書全体が表示されるまでの時間が実用には耐えないものになる． また，後者の方法，すなわちページ全体を一枚のインラインイメージに変換する方法では，イメージファイルの大きさが非常に大きくなってしまう，サーバ側でのイメージファイルの生成に大きな処理コストを必要とするなどの問題がある．
フォントのインストールなしに多言語からなる文書の表示を実現する前節で挙げた方法における問題点を解決し，サーバ側，クライアント側双方での処理コストを低減する方法として，HTMLテキストに必要最小限のフォントを付加して一つのファイルとして送る方法を提案する．
つまり，一文書中に含まれる文字種分だけのフォントをテキストに付加してクライアント側に送る（図）．
この方法により，コネクション回数の問題が解決され，サーバ，クライアント双方での処理コストの低減が図れる．
この方式をMHTML（Multilingual-HTML）方式と呼ぶ．
MHTMLテキストの構造を図に示す．
MHTMLテキストはヘッダ部，フォント部，テキスト部の3つの部分から構成される． ヘッダ部には，MHTMLのバージョン番号（現在は0.2），大きさ別のフォントの数，テキスト部へのバイトオフセット，各フォント情報が格納される． 各フォント情報の部分には，フォントグリフの幅および高さとその大きさのフォントグリフの文字コードの数が格納される． フォント部には，文書を表示するための必要最小限のフォントグリフが格納される． テキスト部には，各テキスト毎に符号化される内部コード列が格納される．
テキスト部に格納されるコードはASCIIコード，内部コード，制御文字のいずれかである．
HTMLのタグの部分にのみASCIIコードが用いられ，その他の文字の部分はすべて内部コードが用いられる．
内部コードはフォント部に格納された順に一文字16ビットで割り当てられる．
制御文字は16ビットであり，ASCIIコードと内部コードの切り替えなどに用いる．
割り当てられている制御文字の一覧を表に示す．
この符号化はMHTMLサーバによって各テキスト毎に行われるため，内部コードはそのテキスト内でのみ有効なものとなる．
前述の二つの方法とMHTML方式について，同じ文書の転送に要するバイト数の比較を行った．
比較は日本語（ISO-2022-JP）で書かれた6つの論文について行った．
CII（一時文字毎，数文字単位のGIFイメージ），ページ全体のGIFイメージ，MHTMLのそれぞれの方式について，元となるHTML文書に対する転送バイト数の比率を比較した．
CIIの場合は，DeleGateで変換された各インラインイメージの大きさの合計とこれらを表示するためのHTMLテキストの大きさを足したものを用い，ページ全体のイメージの場合はページをWWWブラウザで表示させたもののスナップショットのGIFイメージの大きさを用いた．
比較の結果を図に示す．
この図を見ると，DeleGateのCIIライブラリを用いた場合やページ全体のGIFイメージを用いた場合に比べ，MHTML方式はより少ないバイト数で済んでいることがわかる．
先行研究[9]では，MHTML方式の提案と試験的な実装を行った． この研究では，HTMLテキストをWWWサーバから取得しMHTMLに変換するMHTMLサーバおよび，WWWブラウザと連携してMHTMLテキストの表示およびリンクによるナビゲーションを実現するビューアを実装した． この実装では，ユーザが入力フォーム上に閲覧したい文書のURLと言語を入力して送信ボタンをクリックするとMHTMLサーバに要求が送られ，変換されたMHTML文書はWWWブラウザの外部ビューアとして起動するMHTMLビューア上に表示される． リンクを辿る際には，ユーザがWWWブラウザ上で再び言語を選択し，送信ボタンをクリックすることにより，新たにMHTMLビューアが起動し文書が表示される． このようにビューアがWWWブラウザの外部ビューアとして実現されているため，リンクを辿るごとに文書が新しいウィンドウに表示される形になり，あまり使い勝手が良いとは言えなかった． また，このブラウザを使用するために，事前にユーザ自身が外部ビューアをインストールする作業が必要であるという欠点もあった．
