[99]
現在、情報機器 で文字 を扱うには、
抽象化された文字 を表す文字コード 層と字形 を記述したフォント 層が分離された体系によることが多いです。
しかし
Unicode
が普及するまでは、
両者が渾然一体となったシステムが世界各地で多数使われていました。
現在も
Unicode
に存在しない文字 や Unicode で扱いにくい文字 などでそうした手法が使われ続けています。
本稿ではそうした手法群をフォント依存符号化 と総称します。
呼称 [100]
本稿では総称してフォント依存符号化 としています。
[101]
8ビット符号 系フォント依存符号化 手法のフォント の類やその符号化 は
8-bit font ,
font-specific encoding ,
legacy font,
legacy encoding
などと呼ばれることがあります。
[97]
印度 方面では8ビット符号 系フォント依存符号化 手法のフォント の類を
clip font
ということがあります。 clip font
[131]
鍵盤 入力の便宜を中心に設計したものを鍵盤符号化 , keyboard encoding ,
鍵盤配置, keyboard layout などということがあります。
[132]
日本 では、当時 JIS になかった文字や JIS
で区別されない異体字 を提供するフォント の類を外字フォント などということがあります。
ANSI フォント [80]
8ビット符号 系フォント依存符号化 手法のフォント の類を
ANSI , ANSIフォント などということがあります。
語源 をたどると、
[81] ANSI は米国 の標準化団体 [82] ANSI が ASCII を制定する[83] 米国の計算機業界で ASCII が実装される[84] Windows が ASCII や ISO/IEC 8859 を基に独自に拡張したシステムの文字コード のことを ANSIコードページ と呼ぶ
(MS-DOS の OEMコードページ や Windows NT の Unicode との対比)[85] Windows での利用を想定したフォント依存符号化 のフォント のことが
ANSI と呼ばれるようになるで、ここでの ANSI の対義語は Unicode フォントです。
[93]
もちろんこの ANSI は本来の ANSI とは無関係ですし、
対義語が Unicode フォントになっているにも関わらず、ここでいう ANSI
フォントのほとんどは技術的には Unicode を実装していることになっている OpenType
フォントです。
裏フォント [92]
日本語圏 では裏フォント 、裏フォント方式 という言葉があります。
この語は平成時代 初期にそれなりに使われていた痕跡がありますが、
現在では Web 上で数えるほどしか用例が見当たりません。
[94]
現存する用例をみると、 JIS X 0208 の通常のフォント のかわりに他の文字 を割り当てたものを指しているようですが、
注意深く読むとその意味するところには微妙にズレが見られます。
まったく別の文字 を割り当てるものを指している用例が古そうですが、
JIS X 0208 の文字 の異体字 を割り当てたものや、
JIS X 0208 の包摂規準 の範囲内の別字形を割り当てたものを指すものもあります。
[90]
ほら貝:文字コード ,
加藤弘一 ,
This page was created on Nov15 1999.,
2016-08-02T01:44:05.000Z , 2025-10-04T12:01:43.666Z http://www.horagai.com/www/moji/2000a.htm
文字コードと文字セットの違いは最初に述べたが、新しい文字コードを作ろうとすると複雑な問題がからんでくるので、符号化を棚上げし、ひとまず文字セットだけを作ろうという動きが進んでいる。コードがふられていなくては、コンピュータで使えないのではないかと思うかもしれないが、フォントが無償公開されていれば、お互いに共通のフォントを共有でき、そのフォントにおける通し番号を伝えることで、どの文字かが特定できるのである。研究者の間では諸橋轍次の『大漢和辞典』の検字番号でJIS表外字を特定する方法がかなりおこなわれていたが、そのフォント版といえる。
変則的だが、多くのCD-ROM出版物のように、JIS表外字をマッピングした「裏フォント」を使う手もあるし、XMLの実体参照でも文中に表示することができる。ただし、どちらも検索や置換といったテキスト操作はできない。
[96] 前段で指しているのは今昔文字鏡 やGT明朝 やe漢字 など。[89] 第2回 - 中国語情報処理 ,
09/28/2001,
2003-11-28T10:03:15.000Z , 2025-10-04T12:00:22.263Z https://www.rikkyo.ne.jp/univ/masutani/diannao/diannao2001/2.html
裏フォント方式の中国語入力ソフト
「cWnn」(オムロンソフトウェア株式会社):8401にインストール済み独自フォントを用いて表示するため、「cWnn」で入力した中国語は同じソフトのある環境でしか読めないが、中国語変換補助、辞書などの入力支援機能が便利である。 「Chinese Writer」(光電社) [95] 関連: シフトGB [87] ほら貝:文字コード ,
加藤弘一 ,
This page was created on July21 2002.,
2016-08-02T01:43:50.000Z , 2025-10-04T11:58:12.129Z http://www.horagai.com/www/moji/int/saito.htm
――20万字というと裏フォント方式ですか?
斎藤 そうではありません。
[88]
*正字體フォント作成法――或いは、余は如何にして或種のフォントを作り得ざりし乎 , 森洋介 MORI,Yousuke ,
發行日 2007年10月14日 開板/2007年11月26日 改版,
2025-10-04T11:58:46.000Z , 2019-03-31T12:18:09.269Z https://web.archive.org/web/20190331114747/http://livresque.g1.xrea.com/Data/font01.htm
[91] 字体 - Wikipedia , 2025-10-03T12:42:45.000Z , 2025-10-04T12:03:52.419Z https://ja.wikipedia.org/wiki/%E5%AD%97%E4%BD%93#%E6%96%87%E5%AD%97%E9%9B%86%E5%90%88%E3%81%A8%E7%95%B0%E4%BD%93%E5%AD%97
フォント切り替え(裏フォント方式) 同じコードポイントに異体字を収録したフォントを複数(異体字の種類分)用意し、それによって字体の切り替えを行う。 [141] >>28
嘘字方式 [187]
平成時代 初期頃に作られた今昔文字鏡 は嘘字方式 と呼んでいました。
[188]
「いわゆる「嘘字方式」」としていること >>185 Web検索 で確認できる用例は今昔文字鏡 関係のものだけです。
[189]
なお「嘘字」は同時期にいくつかの意味で使われていた言葉であり、
ビットマップフォント が解像度 の都合で字画を省略していることを指したり、
JIS X 0208 に含まれる文字 で論者が気に食わないもの (主に拡張新字体 )
を貶めて言ったりする用例が見られます。[185] 9万字を収容した今昔文字鏡 ,
1999/12/27 00:00:00,
2016-06-10T05:47:00.000Z , 2025-10-05T12:29:59.731Z https://www.jagat.or.jp/past_archives/story/836.html
実装はいわゆる「嘘字方式」である。本来JIS漢字が入っているべきところに,JISの定義とは関係ない配列で文字を定義している。このようなフォントを複数用意して,フォント名とコードポイントを指定して表示を切り替える。たとえば,文字鏡フォント101は,シフトJISでは「亜」が入っているべきところに「一」を定義している。
[186]
[ qa:55053] Re: 文字鏡文字の表示本田 ,
2010-06-21 10:07:04,
2010-06-21T01:07:04.000Z , 2025-10-05T12:30:40.574Z https://okumuralab.org/~okumura/texfaq/qa/55053.html
Mojikyo M101 亜
というような形式(これが嘘字方式)で
[198]
1199 , 2001-07-09T23:19:18.000Z , 2026-01-16T14:38:20.034Z https://okumuralab.org/~okumura/texfaq/qa/1199.html
フォント切り替え方式 [196]
フォント切り替え方式によるTRONの多漢字機能 - 超漢字ウェブサイト , 2025-11-26T22:30:40.000Z , 2026-01-13T15:17:27.162Z https://www.chokanji.com/ckv/manual/01-07-19.html
概略 [102]
フォント依存符号化 と他の文字符号化 との最大の違いは、
フォント依存符号化 がアプリケーション やプラットフォーム のレベルで実装されていない、
なんなれば他の文字符号化 が実装されている点にあります。
[103]
他の文字符号化 の実装であれば、アプリケーション やプラットフォーム のプログラム は多かれ少なかれ当該文字符号化 の知識を実装しています。
例えばどの符号 が改行 を表し、
どの符号 が間隔 を表し、
どの符号 が数字 を表し、
どの符号 とどの符号 が大文字と小文字 の関係にある、
といった知識がプログラム の機能に反映されています。
それによって行 の折り返し 位置が決められたり、
文字列 として記入された整数 の演算 を実行したり、
行頭 を大文字 に置換したりといった処理が実現されます。
あるいは鍵盤 からの入力と文字 の符号 が関連付けられたり、
他の文字コード との相互変換が実装されたり、
音声 による読み上げや全文検索 システムの自然言語処理 と統合されたりしています。
[104]
フォント依存符号化 は、文字 のこうした多角的な処理のうち、
文字図形を表示するという1点のみに特化したものです。
例えば本来A が表示されるべき符号 にあ の文字図形を割り当てたフォント を用意することで、
プログラム を改変せずにラテン文字 対応システムを仮名 対応システムに出来ます。
容易に導入できるという利点と引き換えに、表示以外の処理を悉く諦める必要があります。
使えないだけでなく壊れることもあります。
プログラム が大文字と小文字 の違いを自動的に無視する検索機能を持っていれば、
A と a のかわりにあ と他の文字を同一視する機能に化けてしまいます。
[105]
フォント依存符号化 は、他の文字符号化 との関係で3種類に分類できます。
[106] 他の文字符号化 の文字 を置き換えるもの[107] 他の文字符号化 の空き領域 を勝手に使うもの[108] 独自の文字 の割当のための領域を使うもの[109]
このうち >>106 , >>107 が狭義のフォント依存符号化 というべきもので、
>>108 は Unicode の PUA や Windows の EUDC を含むいわゆる外字 の仕組みとして区別することもできますが、
>>107 と >>108 の区別が明確ではない文字符号化 もありますし、
>>106 や >>107 のフォント も外字 と呼ばれることがあるなど、
厳密に区別しづらいこともあります。
[153]
当初 >>107 だったものが、他の文字符号化 の改定による拡張と衝突して >>106
となる事例もままあります。
[133]
日本 のように早くから公的標準が確立された地域では、そこから漏れた文字 (外字 )
を併用するために、少数なら >>108 や >>107 の手法を使い、
それでは収容しきれない大量の外字 の表示に >>106 が使われることになりがちです。
[134]
アジア その他の基本文字の標準も確立されていなかった地域では、
8ビット符号 で文字数が限られている場合がほとんどであることもあって、
はじめから >>106 が有力な選択肢となってきます。
[98]
印度 方面ではフォント依存符号化 手法のフォント の類のうち、
主に
ASCII文字 を置換したものを monolingual、
ASCII文字 を温存して主にLatin-1 文字を置換したものを bilingual
と区分することがあります。
インド系文字の文字コード
English と地域言語の2言語の文字を共存できるかどうかを意味しています。
[152]
DTP ソフトウェアには、文字コード 的文字 を介さずフォント のグリフID を直接指定して貼り込む機能を有するものもあります。
このような使われ方のフォント は >>108 に類するものといえますが、
利用形態が限定的ですから、一般的なフォント依存符号化 のフォント ほど相互運用性 上の有害性はありません。
[150]
なお、 >>107 や >>108 に当たるもので計算機 システムの提供者が予め組み込んで製品化していたものを日本 では機種依存文字 と呼び、
外字 の一類型としていました。機種依存文字 は >>102 の性質を持たないという点に於いて本項でいうフォント依存符号化 とは異なりますが、
製品によっては内字 よりも機能的支援が限定的だったり、
組み込まれたフォント ごとに対応、未対応の違いがあったりと、
フォント依存符号化 的性格を持つこともあります。
例えば Mac OS ではフォント ごとに異なる外字 (機種依存文字 )
を実装している場合がありました。 MacJapanese
[151]
よく似た語で環境依存文字 なるものが平成時代 後期頃から一部で使われるようになっています。
これは意味が不明瞭な俗語であり、
機種 の概念が不明瞭な時代の旧機種依存文字 の置き換え語として使わたり、
一部のプラットフォーム でシステムフォントに含まれない
Unicode文字 を指したりするように見受けられますが、
いずれにしても本項のフォント依存符号化 とは無関係です。[135]
フォント依存符号化 の主な利用の主体と方法は、
[136] 当該文字 と言語 を母語 として使う一般の人々であり、
通常の文字表記の手段として使う[137] 当該文字 と言語 を母語 として使う一般の人々、
ただしほとんどの文字 は公的標準でカバーされており、
そこから漏れた場合に限られる[138] 当該文字 を言語 や地域 の研究で使う専門分野の人々[139] 当該文字 を特定の専門分野で使う人々のようなパターンがあります。 >>136 はアジア や各国少数民族に多く、
>>137 は東アジア に多いです。
>>138 は欧米 の研究者に多く、
母語 として使う現地とは異なる慣習が成立していた場合もあります。
「母語 として使う現地」のない古代文字 の場合もあります。
[140]
>>139 は専門分野の図記号など Unicode に追加されそうにないものも多く、
狭い範囲で現在も使われ続けていることがあります。
Unicode にあっても入力しづらいなどの理由で独自符号が使われ続ける事例もあります。
>>139 ないし >>138 に該当する使われ方としてはその他に、
娯楽や装飾や宗教を目的として使われるもの、
人工文字 であるものなどがあります。
[110]
フォント依存符号化 のほとんどは、フォント の開発者の独自の符号化 です。
当該フォント 以外との互換性は一切ありません。
[111]
場合によっては同じ開発元の他のフォント と互換性があり、
異なる見た目の別の書体 に切り替えられる場合もあります。
[112]
時には特定のフォント依存符号化 が地域や言語コミュニティーの事実上の標準 の地位を得るほどに普及した場合もあります。
そうなると異なる開発元からいくつも互換性のあるフォント が出現することになります。
[113]
国家標準 等のフォント と分離された文字コード 規格がありながら、
それがフォント依存符号化 として運用されていることもあります。
欧米の計算機業界があまり重視していない地域だと、
プラットフォーム や重要アプリケーション が国家規格 が制定されても対応しないためにそうなってしまいます。
符号化機構 8ビット符号 [114]
ASCII を拡張した形の8ビット符号 は通常の文字符号化 としても非常に広く使われていますが、
フォント依存符号化 に属するものの大部分もこの類型です。
[120] 純粋8ビット符号型 >>115 [121] Unicode 化8ビット符号型 >>116 [122] 8ビット符号・Unicode 統合型 >>118 [115]
20世紀 のものの多くは真の意味で8ビット符号 です。
PostScript / PDF や TeX での利用を想定したフォント や単純なビットマップフォント の多くはこれに該当します。
[116]
20世紀 末から少し事情が複雑になってきます。
Windows をはじめとする多くの応用 や
TrueType / OpenType のようなフォント 技術の
Unicode
化が進み、たとえ文字列 の入出力が8ビット符号 であっても応用 内部の文字列 型データや表示に使うフォント は
Unicode であるケースが増えていきます。
すると入出力の8ビット符号 は Windows-1252 など当該システムの文字コード によって
Unicode に変換された形でシステム内部で処理されることになります。
[117]
つまり [ 0x00 , 0xFF ] の8ビット符号 のように見えて、
実態は U+0100 以上 の Unicode文字 としてプログラム は扱うことになり、
フォント も U+0100 以上 の Unicode文字 にグリフ を割り当てることになります。
[123] Windows-1252 で Unicode と対応付けたものが世界中で最も広く用いられています。[125] OTF Windows NT compatibility mapping
は純粋8ビット符号型から Windows-1252 型への移行措置といえます。[124] Windows-1251 によるものが旧東側 諸国で用いられています。[154] MacRoman によるものが Mac OS 利用者や TrueType フォントで利用されています。[126] symbol encoding は Unicode の PUA
に対応付けるものです。[118]
これを更に発展させて本来の Unicode文字 と「両対応」させたフォント も出現してきます。
例えば 0xA1 に文字 う を割り当てていたら、
U+00A1 と本来の Unicode文字 う の両方にう のグリフ を割り当てておくことで、
従来の8ビット符号 の文書 も Unicode の文書 も1つのフォント で表示できることになります。
もちろんこれでは本来の U+00A1 は表示できませんし、
このような使い方は Unicode に違反するのですが、元々 0xA1 を置き換えていたのですから、
U+00A1 が使えないことでこれまで以上に不便になることはありません。
むしろ後方互換性 を保った優れた移行策という評価すら可能です。
[119] 事情は異なりますが、 U+005C に YEN SIGN
を割り当てた日本語 フォントと構図は同じです。鍵盤符号化 [143]
8ビット符号 型のフォント依存符号化 を使うと、
欧米の8ビット符号 前提の計算機 でもフォント の差し替え・指定だけで任意の文字 を表示させられます。
しかし、
ただ単に使わない文字 を置き換えるだけだと、
どのように置き換えた文字 を入力するかが問題となります。
[144]
基本的な文字とは別の頻度が低い文字を補助する目的のフォント なら、
コピペ や特殊な打鍵操作でもいいかもしれませんが、
常用する基本的な文字がそれでは困ります。
そこで専用のワープロ やエディター を開発したり、
入寮補助用ソフトウェアを開発したりされてきました。
[145]
そうしたソフトウェアすら不要で入力したいという要求から作られたのが、
鍵盤符号化 (keyboard encoding )、鍵盤配置 (keyboard layout)
などと呼ばれる類のフォント依存符号化 系フォント 群です。
[146]
鍵盤符号化 は、打鍵操作でプラットフォーム が入力する文字 を、
その打鍵操作に割り当てたい文字 に差し替えるものです。
[147]
置き換え元となる文字 はプラットフォーム が元々対応しているものであり、
プラットフォーム ごとに異なりますが、多くの場合は ASCII文字 です。
旧ソ連 などではロシア語 用キリル文字 のこともあります。
[148]
書き換え先、つまりフォント依存符号化 に属する文字 は、
書き換え元の文字 と同じような音価 とする、つまり翻字 のような関係とすることもあります
(例えば A にあ を割り当てるものです)。
逆に書き換え元の英語鍵盤 やロシア語鍵盤 とはまったく無関係に、
対象言語 の入力に適して設計された鍵盤配置に基づいて割り当てられることも多いです。
その鍵盤配置はまったく新しく設計されることもあれば、
タイプライター 時代の伝統を受け継いだものもあります。
[149]
鍵盤符号化 は入力も出力も簡単に実装できるという特徴があり、
地域によってはよく使われていました。
鍵盤配置の好みに合わせたカスタマイズが文字コード レベルの変更に発展してしまうのが難点です。
ジョージアの8ビット符号
Windows symbol encoding symbol encoding
Windows-1252 としての実装 [17]
フォント依存符号化 が Windows-1252 前提で実装されていることは、
世界中でよくみられます。
[127]
Windows-1252
を使ったフォント依存符号化 は、
Windows-1252
としての処理とフォント が割り当てた文字 の性質が整合しないと不都合が生じます。
[128]
最も問題となるのは 0xAD SOFT HYPHEN で、
ここにグリフ を割り当てても改行 次第で表示されたりされなかったりします。
>>9
[129]
世界各地のフォント依存符号化 の事例でも、
古いソフトウェアは単純に表示しているだけで 0xAD
に割り当てていても支障は無かったものが、
新しい版のソフトウェアが SOFT HYPHEN
を実装したことで壊れてしまい、
他の符号位置 に割り当て直す羽目になったりしています。
インド系文字の文字コード
[130]
入力された " を “ , ” に自動変換する smart quotes
機能も意図せず動作してデータを破壊しがちで、
変換器や入力補助ソフトウェアなどがこれへの対処を実装している事例がよくみられます。
[9] Antenna House によるXSL拡張仕様
(2015-05-29T04:41:14.000Z , 2020-10-28T07:48:00.515Z )
https://www.antenna.co.jp/XML/axf-extension/axf-extension.htm#axf%3Asoft-hyphen-treatment 通常、SOFT HYPHEN (U+00AD) は、行分割しなかったときは表示せず、行分割した場合は表示される。しかし、この処理では、絵文字のようなフォントを使用した場合、U+00AD に割り当てられているグリフが印字されない場合が発生してしまう。axf:soft-hyphen-treatment プロパティを使用することで、この問題を回避することができる。
OTF Windows NT compatibility mapping [79]
platformID 4 encodingID [ 0 , 255 ] が
OTF Windows NT compatibility mapping
として使われます。
>>311
[81]
platformID 4
は、
Type 1
フォント 由来の OpenType フォント を通じて古い応用 との互換性を維持するための遺物 です。
cmap platformID 4
を使って、
非Unicode 応用 に対してフォント を
Windows ANSI符号化 されているように見せかけられます。
>>311
[82]
Windows ANSI符号化 でない Type 1 フォント 、
例えばキリル文字 や中欧 フォントは、
過去 Adobe が出荷した際に
.PFM ファイルの CharSet 欄を
0 (Windows ANSI )
としていました。
ATM for Windows 9x
は
CharSet
を無視していました。
>>311
[83]
Adobe は
Encoding が StandardEncoding でない Type1 フォント から変換された
OpenType フォント において
cmap platformID 4
を使います。
>>311
[84]
platformID 4
の
encodingIDType 1 フォント の .PFM
ファイルの
Windows charset 値 [ 0 , 255 ]
に設定しなければなりませんmust 。
>>311
[85]
platformID 4 encodingID [ 0 , 255 ]
が
CFF アウトラインの OpenType フォント で使われた場合、
Windows NT の OTF フォントドライバーは、
次のように動作します。
>>311
[86] 文字コード [ 0 , 255 ]
に符号化されているグリフ を、
Windows ANSI コードページ1252 における Unicode符号点 に対応付けます。[87] Windows ANSI (CharSet 0 ) をフォント が対応する
CharSet の一覧に追加します。[88] encodingID を Windows CharSet 値とみなし、
フォント が対応する CharSet の一覧に追加します。[90]
cmap の符号化 は、
CFF の符号化 と同一identical でなければなりませんmust 。
>>311
[80]
platformID 4
は、現在広くは用いられていません。
新しいフォント では使うべきではありませんshould not 。
>>311
[89]
cmap 部分表 の format0 , 6
でなければなりませんmust 。
>>311
[311] cmap - Character To Glyph Index Mapping Table (OpenType 1.9) - Typography | Microsoft Docs
(PeterCon , 2022-08-16T01:57:58.000Z )
https://docs.microsoft.com/en-us/typography/opentype/spec/cmap MacRoman としての実装 [16]
フォント依存符号化 が MacRoman 前提で実装されることは、
Mac OS
利用者の間でしばしば見られました。
[18]
ただ、 Mac OS の利用者 数がそこまで多くないことや Mac OS X への移行のため、
実際に利用されたとみられる事例数はそこまで多くはありません。
[19]
TrueType フォント の cmap (文字コード とグリフID の対応表)
には複数の文字コード 体系のデータを格納できます。
現在は Unicode を用いる場合がほとんどすべてですが、
フォント 生成ソフトウェアは後方互換性 のために MacRoman
(など Mac OS 用の文字符号化 ) 用の表を生成する場合が未だにあり、
MacRoman (など) 用の表が入った TrueType / OpenType
フォント をよく見かけます。
[20]
そうした表はフォント 生成ソフトウェアが Windows-1252 や Unicode
と MacRoman (など) の対応関係から自動的に生成しただけの場合が大部分と思われ、
表示用のフォント として実利用されたことがどれだけあるかは大変疑わしいです。
[21]
フォント依存符号化 のフォント にもこの事情は当てはまるので、
多くのフォント依存符号化 は Windows-1252 版と MacRoman
版が存在することになりますが、 MacRoman 版がどれだけ実用されたかは大いに疑問です。
多バイト符号 [23]
東アジア の多バイト符号 の世界では内字 以外を使う場合、
[155] 内字 を置き換える[156] 空き領域を利用する[157] 外字 領域を利用する[158] 文字符号として利用可能な領域を拡張するといった手段が採られました。このうち >>158
はアプリケーション やプラットフォーム のプログラムの改変が必要になることが多いため、
フォント依存符号化 では採用されづらい手法です。
[24]
平成時代 初期頃までは >>156 や >>157 も含めて文字の領域を自由に使うことが可能でした。
ところがプラットフォーム の Unicode への移行が進むと文字列型 データやフォント へのアクセスで従来の多バイト符号 と
Unicode の変換が頻繁に発生するようになり、空き領域は
Unicode に対応しない (エラーまたは代替文字への置換が発生する)
こととなったために、 >>156 (や >>158 ) が非現実的となりました。
[3]
日本 で使われるフォント依存符号化 の TrueType / OpenType フォント は、
シフトJIS の文字を入れ替えたものと説明されることが多いですが、
実際にはシフトJIS の文字に相当する Unicode フォントの形になっているのが普通です。
[142]
日本 では JIS X 0208 の仮名 を音価 の近い他の表音文字 に置き換えた事例がまま見られます。
[159]
日本 では JIS X 0208 の漢字 を外字 や異体字 に置き換えた事例がまま見られます。
大量の追加文字のためにいくつもフォント を用意した事例もあります。
[160]
外字 の需要が多い日本 など東アジア では、
外字 のグリフ やフォント のデータを転送、共有する仕組みが多数考案、利用されました。
業界標準となったものもあれば、製品独自のものもあり、
特定応用分野や組織内で使われていました。個人レベルの一般に広く普及したものはありません。
外字
こうした仕組みは文字情報の永続性、相互運用性 の観点でみれば単なるフォント依存符号化 より幾分安定、信頼できるものではありますが、
広く公開されるデータで用いられる手法ではありませんし、
システムの更改や外部システムとの相互接続などで常に問題となってきました。
[67]
関連:
JIS X 0208 ,
GB 2312とその拡張 ,
Big5 ,
EUDC ,
DRCS
[165]
現在では多バイト符号 のデータも内部的に Unicode として解釈される場合がほとんどですが、
平成時代 初期頃にはそうではない実装方法の場合がありました。
当時と今とでフォント依存符号化 のフォント が適切に反映されるかどうかが違うことがあります。
[22] シフトJIS と混在して使われる8ビット符号 系フォント依存符号化
Symbolフォント
[70] Making Home Pages in Korean - EHC , 2021-12-31T02:07:47.000Z , 2025-06-17T10:05:43.059Z http://www.kmml.net/ehc/hhpage.html#_two
対象となるブラウザやOSを限定するのであれば、<font face=>タグによるフォント指定を利用してハングルフォントと日本語フォントを使い分け、ハングルと日本語の混在したページを作ることも可能です(たとえばWindows NT上のNetscape 3.0x。ただし<meta>タグでcharsetを決め打ちするとうまく行きませんので、外しておかなければなりません)。
ただし、指定されたフォントがなければせっかくの<font face=>の指定内容は無視されます(とくに異機種、異OSや異言語環境に対する配慮は忘れられがちです)し、ブラウザのバージョンやOSの言語仕様によっても見え方が異なります。と、いうわけで、個人的にはあまりお勧めしません。絶対やるなとまでは言いませんが、やるなら各ブラウザ(できればできる限り複数のOS、複数の言語環境)で一通り表示テストを行い、正常に表示できる環境を明記しておきましょう。
[71]
まじか! そんなことできたのか! シフトJIS とEUC-KR が混在していても適切に
font で括っておけばそれぞれのフォント + ANSIコードページ でレンダリングされたってこと?
フォント選択 [76]
フォント依存符号化 の利用のためのフォント 選択の手法はいくつかあります。
[77] プラットフォーム のフォント を置き換える
OS やアプリケーション に組み込まれたシステムフォントを改変するものです。
プラットフォーム が提供する正規の方法でフォント を指定する場合と、
通常の方法でフォント が指定できないため改造して置換する場合とがあります。
アジア 等の諸地域で英語版等の OS を地域用に改変する手法としてよく用いられました。 [78] プラットフォーム のフォント 指定機能を利用する
初期の Webブラウザー では通常の文字コード 体系に加えて
「利用者定義」 (x-user-defined) のような特殊な文字符号化 を文字コード指定メニュー から選ぶことができ、
利用者 は設定画面でその表示に使うフォント を指定できました。
アジア 等の諸地域で地域用のフォント依存符号化 を利用する手法としてよく用いられました。 [161] プラットフォーム の外字 機能を利用する
OS やアプリケーション に組み込まれた外字 機能を使うものです。
外字エディタ のようなソフトウェアで文字 単位で登録する場合と、
外字フォント を登録して一括で切り替える場合とがあります。
東アジア で内字 以外の文字を追加で使用する手法としてよく用いられました。 [162] ワープロ やマーク付け言語 のフォント 指定機能を利用する
HTML / CSS 、
RTF 、
その他各種のワープロ ソフトウェアは文字列 の一部又は全部のフォント名 を指定できます。
更に HTML や PDF や一部のワープロ では利用するフォント を埋め込んだり、
URL で参照したりもできます。
多くのフォント依存符号化 がこうした手法で利用されています。 [163]
>>77 >>78 は単一のフォント依存符号化 で用が足りる場合に用いられた方法です。
[164]
文字数が多くて単一のフォント で収容しきれない場合は >>162 が必須となります。
基本的な文字集合が標準搭載されていて追加分にフォント依存符号化 系の手法を用いる場合も
>>162 や >>161 によることになります。
応用との統合 文字コードの判定 , フォントの選択
Web での利用 [42]
記述方法としては、
[43] 特に何もせず利用する。Webブラウザー の表示用フォントを利用者 が設定しておく。[45] <font face> で指定する。フォントを利用者 がインストールしておく。[46] 後に font-family も使われるようになった[47] font-family で指定する。 Webフォント を使う。[48] NN4 用の rel=fontdef + PFR で指定するもの、
IE 用の @font-face + EOT で指定するもの[180] その後は @font-face + TrueType や OpenType (含む WOFF )があります。なお CSS は style 要素 、 style="" 属性 で
HTML文書 中に指定する方法の他に、外部CSS で指定する方法も使われます。
[49]
文字コード としては、
[51] 7ビット符号 : ASCII文字 の一部を差し替えるタイプ[58] この場合、 HTMLタグ を理解しないとただの ASCII [50] 8ビット符号 : Latin1 等の一部を差し替えるタイプ[59] 8ビット符号 の文字参照 : >>50 を Latin1 とみなして
HTML の名前文字参照 に置換したタイプ[60] この場合、 HTMLタグ を理解しないとただの ASCII [61] HTML として解釈すると >>52 に変換できる[62] >>50 や >>52 と混在状態のファイルも存在する可能性がある[64] 多バイト符号 [167] 外字 領域を使うタイプ[168] フォント 指定により非標準の文字を使うタイプ[52] UTF-8 [65] >>50 を Latin1 とみなして Unicode に移行したタイプ[66] >>64 から Unicode に移行したタイプ[166] 当初から Unicode ベースのタイプ[169] 外字 領域を使うタイプ[170] フォント 指定により非標準の文字を使うタイプ[53]
文字コード 指定としては、
[54] 無指定 : かなり多い[55] Windows-1252 : 多い[56] Windows-1251 : 東側で見られる[57] x-user-defined [63] 独自の値[171] 多バイト符号 や Unicode : >>64 や >>52 [173]
8ビット符号 系フォント依存符号化 の文字 は、
そのまま8ビット符号 のバイト として記述される場合もあれば、
名前文字参照 や数値文字参照 で記述される場合もあります。
名前文字参照 はLatin-1 の文字 に合わせて命名されていますが、
フォント依存符号化 はそれを独自の文字 に読み替えて使っていますから、
HTML 構文上の名前と実際に表示される文字 が食い違うことになります。
[174]
文字参照 が使われていると、実際上は8ビット符号 であるにも関わらず、
表面的には7ビット符号 のテキストファイル に見えることとなります。
HTML を理解しないエディター や変換器では処理できないことになります。
[175]
HTML や CSS
では部分文字列ごとにフォント を指定できますから、
複雑な指定も可能で、現に用いられています。
漢字 (外字 )
やエチオピア文字 やチベット文字 のように単一のフォント ですべての文字 を収容しきれない場合には、
複数のフォント依存符号化 のフォント を組合せて
font 要素 や font-family
で切り替えながら併用することになります。
また、フォント依存符号化 に存在しない Unicode文字 を数値文字参照 で埋め込むこともできます。
[181]
HTML3 時代の font 要素 はその後不適切とされ CSS
への移行が進みました。フォント依存符号化 の観点では、
フォント名 を毎回指定する手間とデータ量を節約できるメリットもあるものの、
事実上の文字コード 切り替えの指示が文字 データから離れた位置に分離される
(特に外部CSS の場合は別ファイルにまで分離される)
というのはデータの複雑性を増しただけであり、
他の文字コード への変換などの処理の難易度が高まりました。
[182]
Webフォント は日本 では平成時代 後期頃にようやく普及が始まりましたが、
フォント依存符号化 が使われたアジア 諸国等では実装初期から使われていました。
地域によっては Webサイト ごとに異なるフォント が使われ、
初回訪問時に利用者 に手動でダウンロードとインストールを求めているような状況でしたから、
Webフォント によってその手間が無くなりました。
初期のものは Netscape Navigator 対応で、
その後 Internet Explorer と両対応のものが出現し、
やがて Internet Explorer のみ対応のものも出現するという、
世界的な Webブラウザー 市場の動向と同じような経過をたどっているようです。
[183]
Webフォント として指定された当時の Netscape Navigator や Internet Explorer
用のフォント は現在の Webブラウザー が対応していない形式で、
Internet Archive に残る当時の Webサイト は正常に表示されなくなっていることが多いです。
フォント ファイル自体は Internet Archive
に保存されている場合が多いので、現行 Webブラウザー が扱える形式に変換すれば当時のように表示できると思われます。
[184]
Webブラウザー事業者 らは Web互換性 の維持を謳ってはいますが、
Unicode への移行が進む中で需要が減少していたこうした機能に対しては冷淡で、
容赦なく切り捨てられていきました。
そのため Webフォント に依存していた過去の Webサイト は表示すら出来ない現状に追い込まれたわけです。
意識的にそうしたわけではないとしても、
米国や西欧の Webサイト は十数年前のものも正常に表示できるのに、
アジアのサイトはそうではないというのは非難されるのも致し方ない欧米中心主義 でしょう。[179]
関連:
Webにおける文字コード
[68] <FONT FACE> réputé nuisible , 2025-06-16T14:28:19.000Z , 1999-02-21T11:01:55.673Z https://web.archive.org/web/19990221105800/http://babel.alis.com:8080/web_ml/html/fontface.html
[69] >>68 <font face> は有害、ちゃんとした文字を使えと。最初に例示されているギリシャ文字 なら確かにそう。
でも Unicode ですらまともに扱えなかった文字をこの時代に他にどうしろと?
(なお平成11年は Unicode はかなり頑張ればアルファベット 等は実用になるかな、くらいの時期。)
[6] 1054817 – Icon fonts don't work when "allow pages to choose their own fonts" is unchecked
( (2014-08-18 02:20:12 +09:00 版))
https://bugzilla.mozilla.org/show_bug.cgi?id=1054817
[8] 789788 – Not allowing pages to choose their own fonts breaks with icon fonts
( (2014-08-19 05:33:45 +09:00 版))
https://bugzilla.mozilla.org/show_bug.cgi?id=789788
[12] chardetng: A More Compact Character Encoding Detector for the Legacy Web
(Henri Sivonen , 2020-06-08T16:23:51.000Z , 2021-10-15T03:19:30.133Z )
https://hsivonen.fi/chardetng/#fonts
処理 [191]
文字符号化 として x-user-defined が指定されたとき、これを
Windows-1252
と読み替える必要があります。
x-user-defined
[190]
encoding sniffing algorithm では、フォント依存符号化 を検知してこれを
Windows-1252
と処理する必要があります。
頻度解析等の手法
[193] WebKit は本格的に実装しようとしたものの、10年以上放置されています。 >>192
[192]
Bug 22339 – Support Indian web sites with EOT by on-the-fly transcoding to Unicode
( (2013-02-16 10:15:02 +09:00 版))
https://bugs.webkit.org/show_bug.cgi?id=22339 [194] Support sites using EOT fonts and font encoding with the on-the-fly transformation to Unicode with an extension [ 40286311] - Chromium , 2025-11-16T05:14:29.000Z https://issues.chromium.org/issues/40286311 RTF での利用 [1]
RTF の通常の方法によりフォント名 を指定することになります。
[172]
RTF は文字 をバイト列 として記述する方法の他に、
escape により記述する方法も用意しています。
8ビット符号 系フォント依存符号化 の文字 も escape
されていることがあります。
あくまで本来の Windows-1252 等の escape が流用されているにすぎませんから、
HTML の名前文字参照 と同様、構文上の名前と実際にフォント で表現される文字 が食い違うことがあります。
事例 [2] フォント Symbol Wingdings Zapf Dingbats ISO/IEC 646の版 ISO/IEC 8859-3 ジョージアの8ビット符号 ArmSCII インド系文字の文字コード 東南アジア島嶼部の文字コード アラビア文字の文字コード キリル文字の文字コード エチオピア文字の文字コード VNI Inuktut SILフォント WinGreek シフトGB Shift-KS 今昔文字鏡 GT書体 アイコンフォント 合字フォント バーコードフォント ユーリオンフォント 返り点 JIS外字フォント EUDC 楽譜 モールス符号 アーヴ文字 Sarati Tengwar 甲骨文字 神代文字の文字コード 漢字庫 楽譜 点字の文字コード Unicode非互換割当 [36] GitHub - MichinariNukazawa/RuneAssignMN_Series_Fonts , 2024-10-25T01:41:53.000Z https://github.com/MichinariNukazawa/RuneAssignMN_Series_Fonts/
本フォントは、A〜zを入力するだけで手軽にルーン文字が使えるよう作成されました。
ルーン文字に割り当てられているユニコード領域にはグリフを置いていません。
[13]
Using FONT FACE to extend repertoire? (2006-07-13 00:17:01 +09:00 版) http://ppewww.physics.gla.ac.uk/~flavell/charset/fontface-harmful.html 消滅確認 2020-03-04T05:43:10.600Z [15] 絵文字フォントと特殊文字[簡単タグ集] (2008-06-27 14:32:52 +09:00 版) http://www3.ocn.ne.jp/~uri-o313/yumesato/tag/1/font-style2.htm 消滅確認 2020-03-04T05:43:04.000Z 絵文字フォントと特殊文字[簡単タグ集] , 2020-03-04 14:42:44 +09:00 https://web.archive.org/web/20120315225931/http://www3.ocn.ne.jp/~uri-o313/yumesato/tag/1/font-style2.htm
[27]
Thai Keymapped YKの詳細情報 : Vector ソフトを探す! , 2022-10-11T03:33:55.000Z http://www.vector.co.jp/soft/data/writing/se019766.html [26] thai-yk <=> Unicode , 2003-02-10T17:16:27.000Z , 2022-10-11T03:33:43.317Z https://ha1.seikyou.ne.jp/home/akairingosaita/hangul/thai-yk.htm [28]
Japanese Windows and hangul , 2009-12-02T16:07:09.000Z , 2022-10-11T05:31:42.507Z https://ha1.seikyou.ne.jp/home/akairingosaita/hangul/hangul02.htm
"Yamada Language Center"で配布されている"Sorawin.ttf"は、
なんと1byte文字のフォントです。
初声、中声、終声を重ね打ちしてハングルを表示します。
欧文フォントの裏フォント(外字フォント)形式であり、
通常のハングルフォントとの互換性はありません。
[35] フォント
(2018-08-19T09:28:00.000Z , 2021-01-05T03:26:30.339Z )
http://www.yamadera.info/fonts/fonts-index.htm
[5] Microsoft Word - AFSTrainPassFont-info - AFSTrainPassFont-info.pdf , 2020-03-12T06:51:31.000Z , 2025-06-24T03:57:39.520Z https://www.fontucom.com/pdf/AFSTrainPassFont-info.pdf [7] Microsoft Word - ã†flå‹©çfl¨ã†®ã†fl桋僖.doc - AFSTrainPassUserGuide.pdf , 2020-03-12T07:08:15.000Z , 2025-06-24T03:57:53.118Z https://www.fontucom.com/pdf/AFSTrainPassUserGuide.pdf [10] AFSTrainPassLatinFontMap - AFSTrainPassLatinFontMap.pdf , 2020-03-12T06:51:31.000Z , 2025-06-24T03:58:00.093Z https://www.fontucom.com/pdf/AFSTrainPassLatinFontMap.pdf [11] Î2⁄W - AFKakomiMaru-Map.pdf , 2024-10-10T01:03:10.000Z , 2025-06-24T04:02:44.072Z https://www.fontucom.com/pdf/AFKakomiMaru-Map.pdf [25] Î2⁄W - AFKakomiSikaku-Map.pdf , 2024-10-10T01:03:10.000Z , 2025-06-24T04:03:23.838Z https://www.fontucom.com/pdf/AFKakomiSikaku-Map.pdf [30] Î2⁄W - AFKakomiHasenMaru-Map.pdf , 2024-10-10T01:03:10.000Z , 2025-06-24T04:03:43.387Z https://www.fontucom.com/pdf/AFKakomiHasenMaru-Map.pdf [32] Î2⁄W - AFKakomiHasenKaku-Map.pdf , 2024-10-10T01:03:10.000Z , 2025-06-24T04:03:58.684Z https://www.fontucom.com/pdf/AFKakomiHasenKaku-Map.pdf [34] Microsoft Word - AFYubi-info.docx - AFYubi-info.pdf , 2024-03-14T00:17:20.000Z , 2025-06-24T04:09:33.214Z https://www.fontucom.com/pdf/AFYubi-info.pdf [37] 指文字 [38]
Î2⁄W - AFYubi_aite-Map.pdf , 2024-03-13T07:28:18.000Z , 2025-06-24T04:10:07.007Z https://www.fontucom.com/pdf/AFYubi_aite-Map.pdf [39] Î2⁄W - AFYubi_aite_Kana-Map.pdf , 2024-03-13T07:28:17.000Z , 2025-06-24T04:10:16.502Z https://www.fontucom.com/pdf/AFYubi_aite_Kana-Map.pdf [40] Î2⁄W - AFYubi_Jibun-Map.pdf , 2024-03-13T07:28:17.000Z , 2025-06-24T04:10:23.629Z https://www.fontucom.com/pdf/AFYubi_Jibun-Map.pdf [41] Î2⁄W - AFYubi_Jibun_Kana-Map.pdf , 2024-03-13T07:28:17.000Z , 2025-06-24T04:10:31.261Z https://www.fontucom.com/pdf/AFYubi_Jibun_Kana-Map.pdf [72]
Release Monu Math v0.x · MY1L/Unicode · GitHub , 2025-07-02T10:43:12.000Z https://github.com/MY1L/Unicode/releases/tag/Math
[73]
GitHub - ShikiSuen/Yuzuri-Font: 島岡系芸大和声記号専用フォント。 // A typeface which allows easy typography of Shimaoka Roman Numerals used among conservatories in Japan.A typeface which allows easy typography of Shimaoka Roman Numerals used among conservatories in Japan. , 2025-07-02T10:44:09.000Z https://github.com/ShikiSuen/Yuzuri-Font
[74]
将棋プログラム「激指」のページ , 2005-02-28T16:48:54.000Z , 2025-07-02T15:46:14.168Z https://www.logos.t.u-tokyo.ac.jp/~gekisashi/download.html
[75] JIS X 0208 ベース[197]
The Birth of Xiis — A Guide to Font Creation - Filosofía Moderna, Arguméntame , Reflexiones de la Vida y Filosofía Moderna , 2025-09-06T15:45:36.000Z , 2024-02-24T22:21:46.018Z https://web.archive.org/web/20240224221836/https://argumentame.com/the-birth-of-xiis-a-guide-to-font-creation/
[195]
漢索フォント - にせねこメモ , 2025-12-03T14:26:53.000Z https://nixeneko.hatenablog.com/entry/2015/12/24/031005
他の文字コードへの変換 文字コードの変換
.map
研究史 [176]
フォント依存符号化 系の手法群は、個別のフォント や符号化 がその地域や言語の文字記述の手法として研究対象になることこそ多少はあれど、
技術体系として総合的に研究の対象となったり、技術史の観点から検討されたりした事例はほとんど見当たりません。
[177]
文字コード 技術の専門家からは Unicode に置き換えられるべき幼稚な手法とみなされてほとんどその存在を無視されているように見受けられます。
フォント 技術の専門家や文書 記述形式の専門家からも、
自然言語処理 等の専門家からも、自分達の分野の守備範囲とみなされていないように思われます。
[178]
今後は情報技術の発展史的な視点の文字コード 技術の研究や、
デジタルアーカイブ 的観点の Webプラットフォーム 技術史研究の分野などで調査研究の進展が期待されるところです。