⇧ まぁ、方針が間違ってると学習の効果が薄いのは分かり切っていて、その方針を提案してくれるんだから、学習効果は上がるでしょうね。
試行錯誤して探すしかなかった部分を代替してくれるわけだから、それまで徒に浪費していた不毛な時間が削減出来て、本質的な部分に注力できるわけですし。
外字とは？
Wikipediaによると、
外字（がいじ）とは、特定の文字集合（文字コードなど）に含まれない文字のことをいう。日本で一般には、JIS規格の文字コード（通常はJIS X 0208、稀にJIS X 0213やJIS X 0221）に含まれない文字のことをさし、「表外字」、「拡張漢字(ベンダ選定拡張漢字)」とも呼ばれる。常用漢字に含まれない文字のことを外字ということもある。
文字情報基盤事業などの成果として外字を使用しなくてよいように異体字セレクタを利用したUnicode IVD/IVSで定義された文字への包括が推進されている。
文字情報基盤事業では、日本政府の戸籍/住民票業務で必要となる文字を整理して包括させた結果として戸籍統一文字と住基統一文字をとりまとめ、それらをまとめて文字情報基盤として文字セットを定義した。
日本政府では、行政のIT化のために戸籍/住民票業務を中心とした公文書で使える異体字を文字情報基盤で定義したものに包括して限定していく方針である。 MicrosoftもWindowsでの外字のサポートを縮小し、Unicode IVD/IVSによる異体字の利用を推進している。
⇧ とあり、
- 特定の文字集合（文字コードなど）に含まれない文字
→日本で一般には、JIS規格（通常はJIS X 0208、稀にJIS X 0213やJIS X 0221）の文字コードに含まれない文字 - 常用漢字に含まれない文字
のどちらかを指すと。
で、
『一つの文字コードが異なるシステム間で同じ文字イメージであることが保証されないためである。』
とあることから、システム開発をしている側としては、「外字」が利用されていることは最悪な状況ではあると。
とは言え、日本は「漢字」を扱う以上、「外字」を利用せざるを得ない状況なのかも知れないのかは分かりませんが、
『外字を使用しなくてよいように異体字セレクタを利用したUnicode IVD/IVSで定義された文字への包括が推進されている。』
の状況が分かりませんと...
JIS規格（通常はJIS X 0208、稀にJIS X 0213やJIS X 0221）の文字コード
「外字」を『2. 常用漢字に含まれない文字』について考えた場合、「外字」以外については、
まずJIS規格のお話からしていきます。インターネットが一般の人にも普及が始まった頃である2000年に、JIS X 0208の後継として、「JIS X 0213」（※3）が策定されました。JIS X 0208の上位互換となっており、合計で11,233字を収録しています。漢字は第三水準（1,259字）と第四水準（2,436字）が追加され、実は最初に出した2文字はこの範疇に含まれています。皆さんの利用されている環境で変わったのは、2007年にリリースされたWindows Vistaからで、ここからJIS X 0213への対応が始まっています。
「外字」ってなんだろう？利用したくても出せない文字とその解決方法とは？ | つながるプリントラボ - ビジネスソリューション | コニカミノルタ
ただ、現在のコンピューターにおいては、JIS X 0213を網羅しつつ、もっと幅広い範囲で利用できる文字コードの規格を備えています。それが「Unicode」です。
「外字」ってなんだろう？利用したくても出せない文字とその解決方法とは？ | つながるプリントラボ - ビジネスソリューション | コニカミノルタ
⇧ 上記サイト様によりますと、「JIS X 0208」と「JIS X 0213」というJIS規格で扱われている「文字」については、
| No | 文字種 | JIS X 0208 | JIS X 0213 |
|---|---|---|---|
| 1 | 非漢字 | 524字 | 659字 |
| 2 | 第一水準漢字 | 2965字 | - |
| 3 | 第二水準漢字 | 3390字 | - |
| 4 | 第三水準漢字 | - | 1259字 |
| 5 | 第四水準漢字 | - | 2436字 |
| 合計 | 6879字 | 11233字 ※1 | |
※1 「JIS X 0208」の文字種の数の合計（6879字）と合算している
⇧ となっているらしい。
Wikipediaによると、
JIS X 0213は、JIS X 0208:1997を拡張した日本語用の符号化文字集合を規定する日本産業規格 (JIS) である。規格名称は「7ビット及び8ビットの2バイト情報交換用符号化拡張漢字集合」である。
⇧ とありますと。うむ、全然、分からん...
符号化方式
JISベースの文字コード
符号化方式は、ISO/IEC 2022にそった形のみ「規定」としてあり、ISO-2022-JP-2004、Shift_JIS-2004、EUC-JIS-2004は「参考」として記述がある。これらのコード名は今のところIANAが登録していないので、MIME等では "X-" で始まる私用の名称として用いる必要があることになる。
Shift_JIS-2004は、macOSやJava 7などでは既に実装しているが、Windowsでは従来のシフトJIS（コードページ932）と互換性がないことを理由に実装していないため、広く利用することができない。
⇧ なるほど、「JIS X 0213」の規格に対応している文字コードが「Shift_JIS-2004」ということらしい。
「Shift_JIS-2004」の説明を見ると、
Shift_JIS-2004は、日本の文字を符号化するのに使われる文字コードである。JIS X 0213の符号化方式のひとつである。JIS X 0213:2004の附属書1で定義されている。
JIS X 0208の符号化方式のひとつであるShift_JISと同様に、JIS X 0201の1バイト文字とJIS X 0213の2バイト文字とを組み合わせて運用する符号化方式である。Shift_JISの上位互換となっている。
⇧「JIS X 0208」の規格に対応した文字コードが「Shift_JIS」らしい。
「JIS X 0221」については、
JIS X 0221は、日本産業規格 (JIS) の制定している文字コード規格の一つ。規格の名称は「国際符号化文字集合 (UCS)」、ISO/IEC 10646の国際一致規格である。
⇧ よく分からず...
とりあえず、
| No | JIS規格 | 文字コード |
|---|---|---|
| 1 | JIS X 0208 | Shift_JIS |
| 2 | JIS X 0213 | Shift_JIS-2004 |
| 3 | JIS X 0221 | ※1 |
※1 「JIS X 0221 - Wikipedia」を参照
⇧ ということで、「JIS X 0221」がかなりカオスなことになっているっぽいことは何となく分かった...
Javaに限らないとは思うが「外字」の扱いってどうすれば良いのか
で、改めて「外字」とは、
外字（がいじ）とは、特定の文字集合（文字コードなど）に含まれない文字のことをいう。日本で一般には、JIS規格の文字コード（通常はJIS X 0208、稀にJIS X 0213やJIS X 0221）に含まれない文字のことをさし、「表外字」、「拡張漢字(ベンダ選定拡張漢字)」とも呼ばれる。常用漢字に含まれない文字のことを外字ということもある。
⇧ とあるので、
- 特定の文字集合（文字コードなど）に含まれない文字
→日本で一般には、JIS規格（通常はJIS X 0208、稀にJIS X 0213やJIS X 0221）の文字コードに含まれない文字 - 常用漢字に含まれない文字
正確には、『「1. 特定の文字集合（文字コードなど）に含まれない文字」を除く、または、「2. 常用漢字に含まれない文字」』ということになると。
Oracleの公開しているドキュメントによると、
PC 漢字コード
PC 漢字コード (以降、PCK とします) は、一般に「シフト JIS (あるいは MS 漢字) コード」と呼ばれ、Microsoft が Windows 3.1 で規定したマイクロソフト標準キャラクタセットと同等の文字集合およびエンコーディングを提供するものです。ja_JP.PCK ロケールで日本語を表現する文字コード体系として使われています。PCK に関する詳細は、PCK(5) マニュアルページを参照してください。
https://docs.oracle.com/cd/E19253-01/819-0364/japan.utility-10006/index.html
日本語 ECU
日本語 EUC は、EUC (Extended UNIX Code : 拡張 UNIX コード) に、日本語文字集合を割り当てた文字集合およびエンコーディングを提供します。これは、ja または ja_JP.eucJP ロケールで日本語を表現する文字コード体系として使われています。日本語 EUC に関する詳細は、eucJP(5) マニュアルページを参照してください。
https://docs.oracle.com/cd/E19253-01/819-0364/japan.utility-10006/index.html
⇧ 上図が「PC 漢字コード（PCK）」、または「日本語 EUC」を「UTF-8」の文字コードに変換しているフローになるのだけど、「コードポイント」に変換して文字コード間の整合性を取っている模様。
「コードポイント」はというと、
符号点（ふごうてん）は、符号化文字集合内の、文字を割り当てうる個々の点。コードポイント (code point)。Unicodeでは符号位置（ふごういち）と訳す。文脈によっては単に点（てん、point）ともいう。
表現
点（位置）について、ASCIIなどでは、特にこれといった表現方法はなく、オクテットの値を十六進法などで「'A'は4116である」といったように表現する。JIS X 0208などでは「x区y点」あるいは「x-y」（xとyは普通十進法）と表現する。JIS X 0213では「面」がその前に加わる。UnicodeやISO/IEC 10646では、"U+" の後にUnicodeスカラ値を十六進で続けて「U+3042」のようにして表す。
⇧ とありますと。
とりあえず、Javaだと、
⇧ intとして「コードポイント」を取り出す感じになるらしいので、「文字コード」毎の「コードポイント」の対応表みたいのを作る必要があるっぽいですな。
で、
⇧ JIS X系の文字コードがいまいちハッキリしないのだけど、そもそも、Javaの標準APIで文字コードを判定する機能があるのかが分からない...
とりあえず、
⇧ 外部ライブラリを使って、文字列の文字コードを判定するしかないっぽいのか...
と思っていたら、
⇧ 文字コードに対応しているかどうかを確認する方法はあるらしいのだけど、
⇧ 上記の文字セットに対応していると。
何やら、
⇧ 旧いバージョンだと、サポートされている文字セットが少ない模様。
う～む、文字周りは、整理されとりませんな...
Javaの標準APIだと文字コードの判定が厳しそうなので、ホワイトリスト方式で、対応が必要な「外字」をリスト化するしか無さそうなんかね...
あとは、エラーになるのを気にせず、文字コードの変換してtry catchとかでエラーを握りつぶす感じになるんかな...
エンターテインメント系に向いていると言われるJavaであっても、かなり残念なところを見ると、況んや他のプログラミング言語においてをや、ということですかね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
