- ベストアンサー
MS-AccessでUe801のコードが化ける
- MS-Accessでテーブル直接入力で、unicodeのe801に割り当てた外字を入力しようとしたところ、妙な文字になってしまいました。
- EEAO81というコードに化けてしまっているようなのですが、この文字(文字かどうかもわかりませんが)いったい何者なんでしょう?
- 文字化けの回避方法はあるのでしょうか?
- みんなの回答 (8)
- 専門家の回答
質問者が選んだベストアンサー
#6です。 回答を補正します。 Microsoft Office ソフトにおいては、デフォルトでOSに附随してインストールされるフォントでシステムフォントの地位にあるものが私用領域に文字を登録している場合、ユーザーがEUDCファイルに登録した外字よりもそちらを優先してしまうというバグ(?)がありました。 (ワードパッドなどではこのことは起こりません。) これはOffice 2007のService Pack 2で解決されている可能性があります。 下記は周知のMingLiU_HKSCSの場合ですが、今回お尋ねのケースも同様ではないかと考えられるのです。 http://pasofaq.jp/windows/windows7/b-officegaiji.htm #5さんの示唆を受けて、念のため Arial をチェックしたところ、デザインは異なるものの E801,E802,E803,E804,E805 に文字が登録されています。 むしろ“犯人”はArialだと思われます。 あるQ&Aのサイトで、“Win 7 でArialを削除したいができない”という訴えがあり、ArialはWindowsのコアなフォントなので、残したほうがいいとアドバイスしたのですが、ひょっとすると今回お尋ねのケースと同じだったのかも知れません。 Arial Unicode MSは、最近のOSではデフォルトでインストールされないはずですし、システムフォントではないので、削除も容易です。 上記Service Packによる解決が図れない場合の対処策は、 【ユーザー外字をEUDCではなく、「指定したフォントにリンクする」外字ファイルにする。】 つまり、 1.EUDC.TTEファイルをコピーして、Fontsフォルダ外、任意の場所に保存。 2.ファイル名を変更してMyGaiji.tteなどとする。 3.外字エディタを起動、【コードの選択】は[キャンセル] 4.[ファイル]>フォントのリンク 5.「すべてのフォントにリンクする」→「指定したフォントにリンクする」に変更。 6.「フォントの選択」で、リンクさせたいフォントを指定する(仮に「MS明朝 未選択」)。 * MS明朝とMS P明朝は別フォントの扱いになります。 7.[名前を付けて保存] 8.【外字ファイル名の変更】 「保存する場所」を[Fonts]→マイ コンピュータ→[MyGaiji.tte]の保存場所に変更。 9.下のボックスに表示された[MyGaiji.tte]をダブルクリック (=クリック>[保存]) 10.「MS明朝 MyGaiji」のリンク成立を確認して、[OK] 11.[×]にて外字エディタを終了。 これでMS明朝として使われたE801,E802,E803,E804,E805はArialではなく、MyGaijiの外字が表示されます。 その他リンク対象外のフォントとして使われたE801,E802,E803,E804,E805はArialの文字に化けます。 フォントのリンクは複数のフォントについて行えますから、ヘブライ文字の外字など使うことがないと思えば、MS P明朝はじめ行書体にも隷書体にも勘亭流にもリンクさせればいいわけです。 そこまでしなくても当該外字のみをドラッグしてフォントをリンク済みのものに変えるということでも用は足せますが、フォントの指定がはずれて、未リンクの書体に戻ると、文字化けするということはお忘れなく。
その他の回答 (7)
- garamond
- ベストアンサー率53% (1119/2111)
#7です。 参考画像にフォント名を出そうとして、左下に“継ぎ足し”をした際、 E816の字が選択された状態でキャプチャしてしまいました。 上で枠に囲まれた字は問題のE801に間違いありませんので、下のE816は無視してください。 済みません。
- garamond
- ベストアンサー率53% (1119/2111)
- SortaNerd_
- ベストアンサー率59% (309/522)
Windows(あるいはOfficeのみ?)ではユーザー設定の外字より既存のフォントに含まれる外字の方が優先されるようですのでこのようなことが起こります。 対処法は既存のフォントを削除する、あるいはそのフォントを編集してその文字のみ削除することです。後者は面倒な上にライセンスに違反するという考えもあります。 なお、どのフォントにどんな外字が入っているかを判定する簡単な方法は知りません。 >この質問には貼り付けられないので 最近は貼れますよ「 」。検索枠内やAccessと同じ表示になるかは別問題ですが。 >URLからすると、EEAO81というコードに化けてしまっているようなのですが いいえ、表記法が違うだけでEEA081=E801です。 >いったい何者なんでしょう? 外字は人により見え方が違うので(例えばNo4さんにはイ文字に見えているようです)、見えているものが私と同じとは限りませんが、少なくとも私にはヘブライ文字VAV「 ו 」の左上に点が付いたものに見えます。 E801にこの点付きVAVらしき字が入っているフォントはArial Unicode MSがありましたが、字形の違う字が表示されることもあったのでその他にもE801を使っているフォントがあるようです(が探すのは面倒です)。 このコードを望む外字として使いたいなら、Arial Unicode MSなどこれを他の文字として使っているすべてのフォントを削除してください。繰り返しますが、それを発見する簡単な方法は知りません。 >Accessのデータ保管場所である「テーブル」のことで、コードテーブルとかそういったたぐいのものではありません。 ですからそのテーブルが壊れるという話だと思いますが。もっとも本当に壊れるかは私にはわかりません。
お礼
いろいろありがとうございます。 確かにヘブライ語の文字みたいですね。 左の点は母音のようで、右書きのため、このフォントを日本語の文の途中に入れると、カーソルの動きが逆になってしまいました。 Arialが犯人だとすると、消すわけにもいかないので、Access2003のパッチを待ちつつ、回避策を考えて見ます。
- garamond
- ベストアンサー率53% (1119/2111)
お尋ねの字は Unicode:U+A081 (YI SYLLABLE NBOT) ではないでしょうか。 http://www.unicode.org/charts/PDF/UA000.pdf SimSun-18030 というフォントはこの文字を収めています。 ただなぜ E801 が A081 に置き換えられる(?)のかは謎ですが。
OSを明記されたがいいですね。 http://support.microsoft.com/default.aspx?scid=kb;ja;417636 http://support.microsoft.com/default.aspx?scid=kb;ja;870587&Product=xl2002INT 先ず、上記の現象なのかをチェック。
補足
おっしゃるとおり、質問の基本を失していました。 OSはWindowsXP Professional SP3 AccessはAccess2003(11.8231.8329)SP3 です。 NewGulimフォントは削除済みで、コードがE801なので、ふたつ目とも違いそうです。 Unicodeの私用領域に割り当てた外字がなぜか化けてしまいます。
- MRT1452
- ベストアンサー率42% (1391/3293)
外字を使うことを想定してシステムを設計するのは論外です。 ↓ 外字をテーブルデータとして使うことを想定してシステムを設計するのは論外です。
補足
「テーブル」というところで、誤解をさせてしまいました。 Accessのデータ保管場所である「テーブル」のことで、コードテーブルとかそういったたぐいのものではありません。 文字化けが発生するので、いろいろ調べたところ、データシートビューでコード入力すると、必ず再現できるので、このような質問にしてしまいました。 で、外字とシステムの件ですが、そもそも複数PCで共用している外字を管理しようとしていますので、「外字を使うことを前提としたシステム」になっています。 その肝心の外字が化けてしまうので、なにか手は無いものかとヘルプを上げてみました。
- MRT1452
- ベストアンサー率42% (1391/3293)
外字を検索掛けようとしても文字と判断できず、おかしくなった結果かと。 officeはShift_JIS系なので、unicodeを使うならコード変換が必要かと。 ただ、今回は外字ということなので、それで解決する問題ではない気がしますが。 外字はPC依存なので、原則としてデータベース類で使ってはいけません。 ヘタすると正常に処理できないばかりか、テーブルそのものがダメになりかねません。 (外字を使うことを想定してシステムを設計するのは論外です。)
お礼
ありがとうございました。 システムフォントが原因ではないかとのことで、Access2003のパッチを待ちつつ、回避策を考えて見ます。
お礼
いろいろとありがとうございます。 対策はむずかしそうですが、Access2003のパッチが出ることを祈りつつ、考えてみます。