やっぱり、OpenOffice3.2（on ubuntu10.04）では、ユニコードの拡張Bに属する文字は表示できないようだ。[openoffice:6501] UnicodeのSurrogate Pair（Ext-B）対応の件によれば、OpenOfficeがサロゲートペアに対応していないかららしい。
上記記述は2004年のものだが、2011年をもってしてもいまだ対応していない。このへんの技術的な理由はよく分からない。OpenOfficeの度重なる買収が関係しているかどうか。
ExtensionB、Cの漢字を表示させるフォントには、日本語フリーフォントの花園明朝（→Hanazono fonts）がある。しかしアプリケーション自体が対応していないと、フォントが反映されるわけではないこともまた知られているとおり。Wordや一太郎の高いバージョンならば表示できる。
ユニコードについては、ここのunicodeの記述は勉強になる（→Unicode―文字コード入門―）。2011年6月現在ではUnicode 5.2.0が最新規格だそう。unicode4.0の段階で16bitですべての文字を収録する方針を捨て、まずは文字コードポイントを確保する動きとなったらしい（現在のポイント数は1,112,064）。
現在unicodeで規定されているCJK統合漢字は20,902字。これに漢字拡張集合;ExtensionA,B,Cを加える。
CJK統合漢字20,902字
ExtensionA 6,582字
ExtensionB 42,721字
ExtensionC 4,149字
文字コードの専門家でない限り、ユニコードと言う時には拡張文字を含む場合とそうでない時があるし、そのことは多くの場合暗黙の了解となっているかあるいは気づかずに拡張領域に突入していることもあるかも知れない（入力できちゃった！的な）。
これまで僕はデータ運用の利便性からいわゆる83jisでデータベースを作ってきたけれど、共同作業をするひとたちがWindowsの進化にそのまま乗ってきたために、分担入力されたデータの中にユニコード文字が混入することとなり、ひいてはデータ全体を調整しなければならないこととなった。これまではjis外文字を今昔文字鏡で処理していたが、文字鏡は著作権問題もあるし、入力にも表示にもひと手間かかるために、直接的に入力できるユニコード文字のほうがたしかに利便性が高いだろう。データ全体に混入したユニコード文字を特定し、いちおう備考欄に大漢和辞典番号を入力しておき万一表示されないときへの対応しておく、などの作業をしておく。
漢字関係のデータベースを作る人たちは、みなこのコード問題に悩まされているのだろうと思う。先だっての日本語学会でのシンポジウムもそんな感じだった。どこかで発想の転換をしなければいけないかもしれないな、と思う。実際、いま僕が関わっているデータベースは表記ではなく、漢語の語形に依存するものなので、仮名で表記したって原理的には問題はない。しかし漢語というのは表記を経由して、異なる語形を導き出すことが歴史的にはいくらでもあるので困ったことだ。
これを機会に、これまで逃げていた文字コード問題を少し勉強したりしているが、正直なし崩し的な印象もないではない。素人が首を突っ込むとやけどするという、おそれも。このあたりの問題は、やっぱり文字コードのプロに任せたいところ。
（追記）
拡張Bでも出る文字がある。拡張Aでも出ない文字がある。さっそくやけどしてます。これはどういうことだろう？？
（追記2）
結局これは花園フォントがあったとしても、OpenOfficeがExtension（拡張領域）に対応していない、ということですね…別PCに入っているWinのExcelだったら表示できたので。
OpenOffice.orgは内部的にUnicodeで処理しているようですし、データ保存時にも
Unicodeで記録していますが、現状ではSurrogate Pairに対応していません。
そのため、Ext-Bの漢字などを入力しても、正しく表示されません。WordやExcel
でExt-Bの漢字入りのドキュメントを作成して、これを読み込んだ時も表示だけは
されますが、Surrogate Pairを正しく処理していないため、通常に編集することが
できません。
もちろん、現状においては、Surrogate Pairへの対応は緊要ではありませんが、
・今後、日本国内での標準的文字コードとしてJIS X 0213の定着が見込まれている
・Windows環境などでJIS X 0213に完全対応するためにはアプリケーション側での
Surrogate Pair対応が必須
・既にMac OS XはJIS X 0213完全対応を謳っており、Windowsも次期バージョンでの
対応が公表されている（Longhorn）
・既にWindows XPやMS-IME2003やOffice2003はSurrogate Pairに対応しており、
JIS X 0213対応フォントさえあれば、Ext-B漢字を含めてすべてのJIS X 0213文字
を扱える
・ATOK17/2005や次期一太郎（2005）もSurrogate Pair対応。来年2月の一太郎2005発
売時にはJIS X 0213対応フォントの無償公開が予定されている
といった動きがありますので、おそらく2005年～2007年頃にかけてSurrogate Pair
対応が必要となってくるのでは？と思っています。
上記記述は2004年のものだが、2011年をもってしてもいまだ対応していない。このへんの技術的な理由はよく分からない。OpenOfficeの度重なる買収が関係しているかどうか。
ExtensionB、Cの漢字を表示させるフォントには、日本語フリーフォントの花園明朝（→Hanazono fonts）がある。しかしアプリケーション自体が対応していないと、フォントが反映されるわけではないこともまた知られているとおり。Wordや一太郎の高いバージョンならば表示できる。
ユニコードについては、ここのunicodeの記述は勉強になる（→Unicode―文字コード入門―）。2011年6月現在ではUnicode 5.2.0が最新規格だそう。unicode4.0の段階で16bitですべての文字を収録する方針を捨て、まずは文字コードポイントを確保する動きとなったらしい（現在のポイント数は1,112,064）。
現在unicodeで規定されているCJK統合漢字は20,902字。これに漢字拡張集合;ExtensionA,B,Cを加える。
CJK統合漢字20,902字
ExtensionA 6,582字
ExtensionB 42,721字
ExtensionC 4,149字
文字コードの専門家でない限り、ユニコードと言う時には拡張文字を含む場合とそうでない時があるし、そのことは多くの場合暗黙の了解となっているかあるいは気づかずに拡張領域に突入していることもあるかも知れない（入力できちゃった！的な）。
これまで僕はデータ運用の利便性からいわゆる83jisでデータベースを作ってきたけれど、共同作業をするひとたちがWindowsの進化にそのまま乗ってきたために、分担入力されたデータの中にユニコード文字が混入することとなり、ひいてはデータ全体を調整しなければならないこととなった。これまではjis外文字を今昔文字鏡で処理していたが、文字鏡は著作権問題もあるし、入力にも表示にもひと手間かかるために、直接的に入力できるユニコード文字のほうがたしかに利便性が高いだろう。データ全体に混入したユニコード文字を特定し、いちおう備考欄に大漢和辞典番号を入力しておき万一表示されないときへの対応しておく、などの作業をしておく。
漢字関係のデータベースを作る人たちは、みなこのコード問題に悩まされているのだろうと思う。先だっての日本語学会でのシンポジウムもそんな感じだった。どこかで発想の転換をしなければいけないかもしれないな、と思う。実際、いま僕が関わっているデータベースは表記ではなく、漢語の語形に依存するものなので、仮名で表記したって原理的には問題はない。しかし漢語というのは表記を経由して、異なる語形を導き出すことが歴史的にはいくらでもあるので困ったことだ。
これを機会に、これまで逃げていた文字コード問題を少し勉強したりしているが、正直なし崩し的な印象もないではない。素人が首を突っ込むとやけどするという、おそれも。このあたりの問題は、やっぱり文字コードのプロに任せたいところ。
（追記）
拡張Bでも出る文字がある。拡張Aでも出ない文字がある。さっそくやけどしてます。これはどういうことだろう？？
（追記2）
結局これは花園フォントがあったとしても、OpenOfficeがExtension（拡張領域）に対応していない、ということですね…別PCに入っているWinのExcelだったら表示できたので。
コメント