Debian13で起こるフォント名の文字化けの原因はfontconfig

公開日 2026-02-02 更新日 2026-02-06

⇣・ 概要▲

Debianでフォント名を管理する、fontconfig がインストールされているフォントの日本語名(family名)を報告するときに、本来であればshift_jisでデコードすべきMacintosh用のバイト列をutf_16_beでデコードするので、フォントによっては意味のない文字列になってしまい、フォントの選択が困難になります。

また、Macintosh用の英語でないけれどもencodeIDがRomanのバイト列をutf_16_beでデコードしている可能性があります。

この現象の起こる環境は、Debian13で、fontconfig の version は 2.15.0-2.3 です。fc-list コマンドでフォント名の文字化けをみせてくれます。

ttfファイルのnameテーブルを確認して検証しました。

ttfフォントファイル内の記述のミスがあった場合、無視する設計になっているので、文字化けとして現れるのはfontconfig側の問題です。

fonfconfigを使用してフォント名を取得してフォント選択をするソフトウェアは影響を受けます。Libreoffice, GIMP, (The GNOME Projectの)フォント(閲覧ソフト), エディタのフォント選択などです。

文字化けの現象そのものは「フォント名の文字化け-フォント側に問題がないことを確認」を参照してください。

⇣⇡ 凡例▲

フォントデータの記述順

1. 'fc-list -vb' コマンドで名前(の化け具合)を確認。
2. ttfファイルのパスとファイル名、name-offsetの値
3. 01familynameについて、platformID、encodingID、languageID に従ってバイト列をデコードする。(必要に応じて別デコード)
4. 解釈を試みる
5. 02styleについて、platformID、encodingID、languageID に従ってバイト列をデコードする。(必要に応じて別デコード)

表の項目の意味

解釈の方針

まずlanguageIDがen(英語)のものすべて、つまり、mac_enとwin_enのそれぞれをデコードして同一ならまとめると考える。

次にlanguageIDがja(日本語)のものすべてをそれぞれデコードして、enと同じものは省き、日本語独自のものは同一ならまとめ、異なる場合は併記すると考える。

mac_jaは本来ならshift_jisだが、utf_16_beでデコードしているかもしれないということを考慮する。

utf_16_beはその仕組みから、shift_jisでエンコードされたものも正常にデコードできることが多い。正常にデコードできたかは、得られた文字列をもう一度エンコードして元のバイト列と同一になるかで判断しているのではないか。それなら我々にとって意味不明な文字列でもデコードに成功したと判断されることはあり得る。

⇣⇡ IPA P明朝▲

family: "IPA P明朝"(s) "IPAPMincho"(s) "䥐䅐䵩湣桯"(s)
familylang: "ja"(s) "en"(s) "ja"(s)
style: "Regular"(s)
stylelang: "en"(s)

/usr/share/fonts/opentype/ipafont-mincho/ipamp.ttf 0x781ea8

1. enはmac_en,win_enがあり、それぞれの指定通りデコードすると、どちらも"IPAPMincho"になるので、まとめて "IPAPMincho"(en) とする。
2. jaもmac_ja,win_jaがある。それぞれの指定通りデコードすると、macは"IPAPMincho"でenと同じになるので省略。winは"IPA P明朝"になるので、"IPA P明朝"(ja)とする。
3. のはずであるが、"䥐䅐䵩湣桯"もjaとして記録されている。ということは、mac_jaのバイト列をutf_16_beでデコードしているという結論になる。
4. mac_jaのバイト列をshift_jisでデコードしていないということは確証がないが、shift_jisでデコード成功しているのに、さらにutf_16_beでもデコードを試みるというのはありそうにない。
5. ロケールから、jaを先行して報告するのは説明がつくが、"䥐䅐䵩湣桯"(ja)を最後にしているのは理由が見つからない。

1. enはmac_en,win_enがあり、それぞれの指定通りデコードすると、どちらも"Regular"になるので、まとめて "Regular"(en) とする。
2. jaもmac_ja,win_jaがある。それぞれの指定通りデコードすると、どちらも"Regular"でenと同じになるので省略。
3. ということなのかもしれないが、familyをutf_16_beでデコードしているのに、styleはshift_jisというのもあやしい。そこで、utf_16_beでデコードしていると考えると、"剥杵污�"となる。utf_16は2バイトコードなので、6バイトまではデーコードできたが、最後の1バイトは正しくデコードできなかった。そこでこれを無視してmac_jaは報告にはいらず、win_jaが"Regular"でenと同じになるので省略という解釈もありうる。

より詳しくは「フォント名の文字化けの原因をさぐる」の"IPA P明朝"で困った、または"IPA P明朝"の名前文字列のデコード一覧を参照

⇣⇡ IPA明朝▲

family: "IPA明朝"(s) "IPAMincho"(s)
familylang: "ja"(s) "en"(s)
style: "Regular"(s)
stylelang: "en"(s)

/usr/share/fonts/opentype/ipafont-mincho/ipam.ttf 0x78215c

1. "IPA P明朝"とほとんど同じだが、mac_jaで、utf_16_beでのデコードはバイト列が奇数なので失敗する。そこでwin_jaからの"IPA明朝"だけが日本語名となる。
2. もちろん、"IPA P明朝"と比較しなければ、mac_jaはshift_jisでデコードされ、"IPAMincho"となってenと同じなので省略されたという解釈になるかもしれない。

1. "IPA P明朝"のstyleとまったく同じ。

より詳しくは「フォント名の文字化けの原因をさぐる」のIPA明朝は名前が2つ、またはIPA明朝の名前文字列のデコード一覧を参照

⇣⇡ モトヤLマルベリ3等幅▲

debianのパッケージに、fonts-motoya-l-maruberi という名前で登録されているもので、解説には、「モトヤ L マルベリ 3 等幅 - 丸ゴシック、"マルベリ" フォント」とあります。

family: "モトヤLマルベリ3等幅"(s) "MotoyaLMaru"(s) "莂荧莄䲃綃讃碃訳鎙閝"(s)
familylang: "ja"(s) "en"(s) "ja"(s)
style: "Regular"(s) "W3 mono"(s)
stylelang: "ja"(s) "en"(s)

/usr/share/fonts/truetype/motoya-l-maruberi/MTLmr3m.ttf 0x2b8dbc

1. enはmac_en,win_enがあり、それぞれの指定通りデコードすると、どちらも"MotoyaLMaru"になるので、まとめて "MotoyaLMaru"(en) とする。
2. jaはwin_jaがある。指定通りデコードすると"モトヤLマルベリ3等幅"になる。mac_jaはなく、macromja、つまりencodeIDがRomanであり、asciiでデコードする指示になっている。ところがバイト列はasciiの範囲になくshift_jisなので、フォント側の間違いと思われる。encodeIDをJapaneseにしていれば、デコード結果は"モトヤLマルベリ3等幅"でwin_jpと同一である。
3. ところが、"莂荧莄䲃綃讃碃訳鎙閝"がjaとして記録されている。ということは、macromjaのバイト列をutf_16_beでデコードしているという結論になる。指示通りasciiでデコードしたら失敗するので、utf_16_beでもデコードしてみたということなら間違いとはいえないが、はじめからutf_16_beでデコードしたとしても同じ結果になることは覚えておきたい。
4. mac_jaのバイト列を指示通りasciiでデコードして失敗したという確証がないが、shift_jisでデコードしていないというのは確かなようだ。
5. ロケールから、jaを先行して報告するのは説明がつくが、"莂荧莄䲃綃讃碃訳鎙閝"(ja)を最後にしているのは理由が見つからない。

1. enはmac_en,win_enがあり、それぞれの指定通りデコードすると、どちらも"W3 mono"になるので、まとめて "W3 mono"(en) とする。たぶんWeightが3で、等幅という意味なのだろう。02のstyleの意図からすると、Regular, Italic, Bold, Bold-Italic のどれかであるべきで、その他のバリエーションは違うnameIDで指定するようになっているのだが、規格の決められた経緯や、言語の事情、規格のわかりにくさなどの理由で浸透しないのだろう。
2. jaはwin_jaがある。指定通りデコードすると"Regular"になる。やはりmac_jaはなく、macromja、つまりencodeIDがRomanであり、asciiでデコードする指示だが、バイト列はasciiの範囲にあるので"Regular"になる(shift_jisとしてデコードしても"Regular"になる)。win_jpと一致するので、"Regular"(ja)となる。
3. とはいっても、utf_16_beでデコードして失敗し(奇数バイトなので必ず失敗する)、jaの候補から外されて、win_jaが採用され、"Regular"(ja)となった可能性もある。
4. styleもjaとenの値が違えばja先行して併記するということが判明した。

より詳しくは「フォント名の文字化けの原因をさぐる」のモトヤLマルベリ3等幅、またはモトヤLマルベリ3等幅の名前文字列のデコード一覧を参照

⇣⇡ 衡山毛筆フォント行書▲

family: "衡山毛筆フォント行書"(s) "KouzanBrushFontGyousyo"(s) "䭯畺慮䉲畳框潮瑇祯畳祯"(s)
familylang: "ja"(s) "en"(s)
style: "Regular"(s)
stylelang: "en"(s)

/usr/share/fonts/truetype/kouzan-mouhitsu/kouzan-mouhitsu-gyosho.ttf 0x220

1. enはwin_enしかない。指定通りデコードすると"KouzanBrushFontGyousyo"になるので、"KouzanBrushFontGyousyo"(en) とする。
2. jaもwin_jaしかない。指定通りデコードすると"衡山毛筆フォント行書"になる。"衡山毛筆フォント行書"(ja)となる。
3. mac_jaはなく、macrom?? が残っている。上にも書いたが、??は0411で、winならJapaneseと判断されるIDだが、macだと該当がないlangageIDを書いてしまったいうこと。つまりenでもjaでもない第三の不明な言語と扱われたようだ。
4. macなのでencodeIDがRomanであり、asciiでデコードする指示。バイト列はasciiの範囲なので、デコードすれば"KouzanBrushFontGyousyo"になる(バイト列はshift_jisとしてデコードしとも"KouzanBrushFontGyousyo")。enと一致するので省略されるはずだ。
5. ところが、"䭯畺慮䉲畳框潮瑇祯畳祯"が言語表記なしで報告されている。ということは、Romanのバイト列をasciiでなくutf_16_beでデコードしているという結論になる。ascii指示をutf_16_beでデコードするのはびっくりだが、0411というlanguageIDを優先してutf_16_beとしたのなら、まあ、わからないでもない。
6. ロケールから、jaを先行して報告するのは説明がつく。何の言語か不明な"䭯畺慮䉲畳框潮瑇祯畳祯"を最後にしているのは妥当かもしれない。

1. enはwin_enのみであり、指定通りデコードすると、"Regular"になる。
2. jaもwin_jaがある。指定通りデコードすると、"Regular"でenと同じになるので省略。
3. さらに、第三の言語macrom??があるが、指定通りデコードすると、"Regular"でenと同じになるので省略。
4. となるはずだが、Romanのバイト列をasciiでなくutf_16_beでデコードしているという疑いが生じている。ここではutf_16_beでデコードすると失敗するので、無視されたとも考えられるので結論は出ない。

より詳しくは「フォント名の文字化けの原因をさぐる」の衡山毛筆フォント行書-YOz以外のも見てみる、または衡山毛筆フォント行書の名前文字列のデコード一覧を参照

⇣⇡ 衡山毛筆フォント草書▲

family: "衡山毛筆フォント草書"(s) "KouzanBrushFontSousyo"(s)
familylang: "ja"(s) "en"(s)
style: "Regular"(s)
stylelang: "en"(s)

/usr/share/fonts/truetype/kouzan-mouhitsu/KouzanBrushFontSousyo.ttf 0x220

1. enはwin_enしかない。指定通りデコードすると"KouzanBrushFontSousyo"になるので、"KouzanBrushFontSousyo"(en) とする。
2. jaもwin_jaしかない。指定通りデコードすると"衡山毛筆フォント草書"になる。"衡山毛筆フォント草書"(ja)となる。
3. mac_jaはなく、macrom?? が残っている。上にも書いたが、??は0411で、winならJapaneseと判断されるIDだが、macだと該当がないlangageIDを書いてしまったいうこと。つまりenでもjaでもない第三の不明な言語と扱われたようだ。
4. macなのでencodeIDがRomanであり、asciiでデコードする指示。バイト列はasciiの範囲なので、デコードすれば"KouzanBrushFontSousyo"になる(バイト列はshift_jisとしてデコードしとも"KouzanBrushFontSousyo")。enと一致するので省略されたと解釈できる。
5. けれども、Romanのバイト列をasciiでなくutf_16_beでデコードしたと考えても、デコードが失敗になるので無視されたと考えても同じ結論になる。

1. 衡山毛筆フォント行書のstyleと全く同じ。

より詳しくは「フォント名の文字化けの原因をさぐる」の衡山毛筆フォント草書はどうか、または衡山毛筆フォント草書の名前文字列のデコード一覧を参照

⇣⇡ YOzS90bi▲

family: "奏穓㤰扩"(s) "YOzS90bi"(s)
familylang: "ja"(s) "en"(s)
style: "䉯汤"(s) "Bold"(s)
stylelang: "ja"(s) "en"(s)

/usr/share/fonts/truetype/yozvox-yozfont/YOzBS_90i.ttf 0x9ac578

1. enはmac_en,win_enがあり、それぞれの指定通りデコードすると、どちらも"YOzS90bi"になるので、まとめて "YOzS90bi"(en) とする。
2. jaもmac_ja,win_jaがある。それぞれの指定通りデコードすると、どちらも"YOzS90bi"でenと同じになるので省略のはずであった。特に、mac_jaはshift_jisでデコードして"YOzS90bi"になるはずである。
3. ところが、"奏穓㤰扩"もjaとして記録されている。ということは、mac_jaのバイト列をutf_16_beでデコードしているという結論になる。
4. mac_jaのバイト列をshift_jisでデコードしていないということは確証がないが、shift_jisでデコード成功しているのに、さらにutf_16_beでもデコードを試みるというのはありそうにない。
5. ロケールから、jaを先行して報告するので、"奏穓㤰扩"(ja)が先になる。win_jaのフォント名をenと同じにしたことがYOzフォントが文字化けで目立ってしまった一因であるが、YOzに非はない。

1. styleも全く同じ流れで"䉯汤"(ja)が現れる。

より詳しくは「フォント名の文字化け-フォント側に問題がないことを確認」のNameRecordの実例を読む、またはpythonでデコードしてみるを参照

⇣⇡ YOzS90i▲

family: "YOzS90i"(s)
familylang: "en"(s)
style: "Regular"(s)
stylelang: "en"(s)

/usr/share/fonts/truetype/yozvox-yozfont/YOzRS_90i.ttf 0x98b520

1. enはmac_en,win_enがあり、それぞれの指定通りデコードすると、どちらも"YOzS90i"になるので、まとめて "YOzS90i"(en) とする。
2. jaもmac_ja,win_jaがある。それぞれの指定通りデコードすると、どちらも"YOzS90i"でenと同じになるので省略したと解釈すれば平和に説明できる。
3. けれども、mac_jaでもバイト列をutf_16_beでデコードしようとして失敗し、無視されたとしても説明がつく。
4. enしかないので、"YOzS90i"(en)のみの報告となる。

1. styleも全く同じ流れで"Regular"(en)のみ報告される。

より詳しくは「フォント名の文字化けの原因をさぐる」のYOzS90iは文字化けしていない、またはYOzS90iフォントの名前文字列のデコード一覧を参照

⇣⇡ YOzS▲

family: "奏穓"(s) "YOzS"(s)
familylang: "ja"(s) "en"(s)
style: "Regular"(s)
stylelang: "en"(s)

/usr/share/fonts/truetype/yozvox-yozfont/YOzRS_.ttf 0x8c8a34

1. enはmac_en,win_enがあり、それぞれの指定通りデコードすると、どちらも"YOzS"になるので、まとめて "YOzS"(en) とする。
2. jaもmac_ja,win_jaがある。それぞれの指定通りデコードすると、どちらも"YOzS"でenと同じになるので省略のはずであった。特に、mac_jaはshift_jisでデコードして"YOzS"になるはずである。
3. ところが、"奏穓"もjaとして記録されている。ということは、mac_jaのバイト列をutf_16_beでデコードしているという結論になる。
4. mac_jaのバイト列をshift_jisでデコードしていないということは確証がないが、shift_jisでデコード成功しているのに、さらにutf_16_beでもデコードを試みるというのはありそうにない。
5. ロケールから、jaを先行して報告するので、"奏穓"(ja)が先になる。win_jaのフォント名をenと同じにしたことがYOzフォントが文字化けで目立ってしまった一因であるが、YOzに非はない。

1. enはmac_en,win_enがあり、それぞれの指定通りデコードすると、どちらも"Regular"になるので、まとめて "Regular"(en) とする。
2. jaもmac_ja,win_jaがある。それぞれの指定通りデコードすると、どちらも"Regular"でenと同じになるので省略。
3. ということなのかもしれないが、familyをutf_16_beでデコードしているのに、styleはshift_jisというのもあやしい。そこで、utf_16_beでデコードしていると考えると、"剥杵污�"となる。utf_16は2バイトコードなので、6バイトまではデーコードできたが、最後の1バイトは正しくデコードできなかった。そこでこれを無視してmac_jaは報告にはいらないという解釈もありうる。

より詳しくは「フォント名の文字化けの原因をさぐる」のYOzSはフォント名だけ文字化け、またはYOzSフォントの名前文字列のデコード一覧を参照

⇣⇡ YOzSF90bi▲

family: "奏穓䘹ぢ楘"(s) "YOzSF90bi"(s)
familylang: "ja"(s) "en"(s)
style: "䉯汤"(s) "Bold"(s)
stylelang: "ja"(s) "en"(s)

/usr/share/fonts/truetype/yozvox-yozfont/YOzBSF90i.ttf 0x9ac974

1. enはmac_en,win_enがあり、それぞれの指定通りデコードすると、どちらも"YOzSF90bi"になるので、まとめて "YOzSF90bi"(en) とする。
2. win_jaは指定通りデコードすると、"YOzSF90bi"でenと同じになるので省略になる。
3. 実は分けて書いてあるがwin_enもwin_jaもnameID01,03-07まですべて同じ文字列が指定されている。winについてはenもjaもutf_16_beでデコードすることになっているので問題ない。
4. mac_enはascii、mac_jaはshift_jisとエンコードが異なるが、asciiの範囲であればデコードしたときに同じ文字列になるので問題ない。
5. けれども、nameIDが01の場合だけ特殊な仕組みにしている。バイト列のスペースは10バイト分を確保してあるのだが、nameIDが01でなおかつmac_jaときだけ10バイトの長さだけれども、その他はmac_enもmac_jaも9バイトの長さが指定されている。こういう指定はttfの仕様上間違いではない。
6. なので、mac_jaのnameID01の部分を指定通りshift_jisでデコードすると"YOzSF90biX"になる。enの名前とは"X"がついている分、同一ではない。ところがフォント名で報告されていないので、shift_jisではデコードされていないことになる。報告されているのは"奏穓䘹ぢ楘"で、mac_jaのバイト列をutf_16_beでデコードしているという結論になる。utf_16_beでのデコードが成功するのは10バイトになっているからである。YOzのフォント名にXの記号も入ることがあるが、"bi"記号の後に来ることはないので、なぜこうなっているかは謎である。
7. これで、mac_jaのバイト列をshift_jisでデコードしていないということが明確になったといえる。
8. ロケールから、jaを先行して報告するので、"奏穓䘹ぢ楘"(ja)が先になる。

1. enはmac_en,win_enがあり、それぞれの指定通りデコードすると、どちらも"Bold"になるので、まとめて "Bold"(en) とする。
2. win_jaも指定通りデコードすると、"Bold"でenと同じになるので省略になる。
3. mac_jaは本来はshift_jisでデコードするべき所、utf_16_beでデコードして"䉯汤"を得る。これを"䉯汤"(ja)として採用する。
4. ロケールから、jaを先行して報告するので、"䉯汤"(ja)が先になる。

より詳しくは「フォント名の文字化けの原因をさぐる」のYOzSF90biは奇数バイトなのに、 またはYOzSF90biフォントの名前文字列のデコード一覧を参照

Debian12でのYOzSF90bi(2026-2-6の追記)

Debian12では、文字化けはこらない。これは前から確認済みだが、fc-listでは、次のように報告される。

family: "YOzSF90bi"(s)
familylang: "en"(s)
style: "Bold"(s)
stylelang: "en"(s)

しかし、nameテーブルの内容は全く同じなので、"奏穓䘹ぢ楘"にならないとしても、YOzSF90biXは日本語名として出てきそうなのに出てきていない。win_jaではenと同じ文字列になり省略になるが、mac_jaではのnameID=10だけ10バイトなのでYOzSF90biXになり、ja独自の文字列となるからだ。

この原因はわからない。ただひとつ推測するとすればnameオフセットテーブルでは同じ開始位置のバイト列を複数のnameIDで使い回されるので、lengthも同じであろうと処理される可能性がある。開始位置が同じでlengthが異なるという指定はあまりないことなので、確認が漏れていたのではないだろうか。

⇣⇡ VL Pゴシック▲

family: "VL Pゴシック"(s) "VL PGothic"(s)
familylang: "ja"(s) "en"(s)
style: "regular"(s)
stylelang: "en"(s)

/usr/share/fonts/truetype/vlgothic/VL-PGothic-Regular.ttf 0x3c6c5c

1. enはmac_en,win_enがあり、それぞれの指定通りデコードすると、どちらも"VL PGothic"になるので、まとめて "VL PGothic"(en) とする。
2. jaについてはmac_jaがない。win_jaは指定通りデコードすると、"VL Pゴシック"でenと異なるので、"VL Pゴシック"(ja)として報告される。とてもすっきり。

1. enはmac_en,win_enがあり、それぞれの指定通りデコードすると、どちらも"regular"になるので、まとめて "regular"(en) とする。
2. 他のフォントは"Regular"であるが、小文字のまま受け入れられている。
3. jaについてはmac_jaもwin_jaも存在しないので、enのみとなる。とてもすっきり。

より詳しくは「フォント名の文字化けの原因をさぐる」の"VL Pゴシック"はデフォルトの日本語フォント、 または"VL Pゴシック"の名前文字列のデコード一覧を参照

⇣⇡ BIZ UDゴシック▲

family: "BIZ UDゴシック"(s) "BIZ UDGothic"(s)
familylang: "ja"(s) "en"(s)
style: "Regular"(s)
stylelang: "en"(s)

/usr/share/fonts/truetype/bizud-gothic/BIZUDGothic-Regular.ttf 0x45b910

1. mac_enもmac_jaもない。winだけで完結していて、わかりやすいが、macでも使えるかは不明。

1. mac_enもmac_jaもない。winだけで完結していて、わかりやすいが、macでも使えるかは不明。

より詳しくは「フォント名の文字化けの原因をさぐる」の"BIZ UDゴシック Regular"から先に、 または"BIZ UDゴシック Regular"の名前文字列のデコード一覧を参照

・⇡ BIZ UDゴシック▲

"BIZ UDゴシック"はファミリー名なので、RegularもBoldも同じ名前になる。日本語フォント名では少数派だがttfの仕様を見ると、これが本来の姿なのだそうだ。

nameID=04のfullnameにはRegular,Boldがついて区別される。ttfファイルは別になっている。解釈についてはRegularと同じなので省略。

family: "BIZ UDゴシック"(s) "BIZ UDGothic"(s)
familylang: "ja"(s) "en"(s)
style: "Bold"(s)
stylelang: "en"(s)

/usr/share/fonts/truetype/bizud-gothic/BIZUDGothic-Bold.ttf 0x454690

より詳しくは「フォント名の文字化けの原因をさぐる」の"BIZ UDゴシック Bold"、 または"BIZ UDゴシック Bold"の名前文字列のデコード一覧を参照