| 過去の桐井戸端ＢＢＳ （桐ver.８） |
| 4494 | 今昔文字鏡を使えない | 向井正治 | 2000/02/05-20:48 |
| 今昔文字鏡の文字をクリップボードにコピーして張り付けようとしますが利用できません。 どなたか出来た方がおりますでしょうか？ | |||
| 4496 | Re:今昔文字鏡を使えない | 佐田 守弘 | 2000/02/05-23:15 |
| 記事番号4494へのコメント 向井正治さん コメントの前に確認させて頂きたいのですが、「今昔文字鏡」とは何でしょうか。 まだ食べた事がないもので(^^;) 貼り付け先ですが、「今昔文字鏡」というメディアのデータなり、そのアプリで作成 したデータを桐の表に貼り付けるという意味でしょうか。また、どの時点で貼り付け が巧く行かないかもお知らせ下さい。 「今昔文字鏡」が何であるか見当がつかないのですが、食べ物ではなさそうなので、 考えられる想定をしてみます。 ・CDに収録された古典の電子出版物である場合 著作権の関係でクリップボードへのコピーが禁止されている可能性がありますね。 ・アプリケーションの名称である場合 普通はクリップボードにコピーできる筈なのですが。ただしコピーできるのは文字に 限られます。図形で表示している場合にはコピーできません。 それ以外に考えられるものとしては...何でしょうね。 （フォント名という事はなさそうですし） 佐田守弘(KS-00119) | |||
| 4498 | 「今昔文字鏡」はユニコードですね | 佐田 守弘 | 2000/02/06-01:12 |
| 記事番号4494へのコメント 向井正治さん 私の方で「今昔文字鏡」とは何物なのかを調べてみました。 中国軍事史などではなさそうで、いろいろと調べたところ、どうやらそういった名前 の漢字フォントがあるようですね。どうやら９万字もの漢字を扱うフォントとか。 JISコードで９万文字もの文字が扱えるはずはないと思いましたが、リンクをたどっ て調べて行った結果、JISコードではなくて、ユニコードの漢字フォントの様ですね 。 という事で、クリップボードでコピーできない理由は簡単でした。単に漢字体系が違 うためです。 桐は表題に「日本語データベース」と書かれております様に、日本工業規格で決めら れている日本語文字である、JISコード(２バイトコード)をベースにして設計されて おります。このため、文字コード体系が違うユニコードは桐では扱えません。 佐田守弘(KS-00119) 追伸１． 私自身も、ユニコードが使える日本語データベースがあったら良いと思っています。 特に旧漢字を必要とする寺院では必須の機能だと思います。 ですが、桐で対応するのは多分、難しいでしょうね。もし桐をユニコード対応に作り 替えるとすると、データベースエンジンそのものから作り替える必要がでてくるでし ょう。 確かユニコードは３バイトか４バイトコードの文字だったと思います。現在のJISコ ードベースの桐のデータファイルとは共存できませんし、もし全面的にユニコードに 切り換えるとしたら、データファイルのサイズがバイト数の比率だけ大きくなり、デ ータ処理速度も遅くなってしまいまうでしょう。 追伸２． 私としては、サンスクリット文字(梵字)のフォントがあったらと思っております。今 昔文字鏡にサンスクリット文字がないものかと調べてみましたが、サンスクリット文 字には対応してくれていない様ですね。残念。 | |||
| 4502 | Re:「今昔文字鏡」はユニコードですね | hidetake | 2000/02/06-08:46 |
| 記事番号4498へのコメント >私自身も、ユニコードが使える日本語データベースがあったら良いと思っています。 Access は 95 以降に置いて、文字列は Unicode で格納されているのでは？ だから単純に LenB しても半角のバイト数は正しく帰さないと... でも、Access97 に置いても補助漢字は正しく表示できませんでしたが... この時代で補助漢字に対応しているのは Excel97 も駄目で、Word98 だけ だったような気がしますが、Word2000 に加え Excel2000 でも補助漢字は 取り扱えるようになったので Access2000 でも可能な気がしますがどうな のでしょう？ だとする今昔文字鏡も取り扱えそうな気もしますが... 漢字に興味があるのなら中村正三郎さんのところを読んでいるとたまに 出てきますよ。サンスクリットとも... 最近で言えば超漢字か... 但し、この辺までなると単なる Windows 上の話を越えてしまいますが... | |||
| 4505 | Re:「今昔文字鏡」はユニコードですね | hidetake | 2000/02/06-10:50 |
| 記事番号4502へのコメント あと、ついでに書くなら、クライアントのプラットフォームに依存しない まともな DB システム(InterBase とか Oracle とか...)なら、DB にどの 文字コード(EUC , JIS , SJIS , UNICODE)で文字データを保存するか設定 することが可能なはずです。 クライアント側のプラットフォーム(設定)に合わせ、バックエンド DB が ちゃんと文字コード変換してやり取りをしてくれたと思います。 | |||
| 4507 | Re:「今昔文字鏡」はユニコードですね | hidetake | 2000/02/06-11:24 |
| 記事番号4498へのコメント >という事で、クリップボードでコピーできない理由は簡単でした。単に漢 >字体系が違うためです。 この辺も誤解を招く表現のように感じます。 単に桐がその領域の文字の入力を禁止しているからでは？ >桐は表題に「日本語データベース」と書かれております様に、日本工業規 >格で決めら >れている日本語文字である、JISコード(２バイトコード)をベースにして >設計されて >おります。このため、文字コード体系が違うユニコードは桐では扱えませ >ん。 これも桐の言い訳としか思えない。いつの時代の規格？ じゃ〜、JIS で決められた文字は全て取り扱えるのか？ 例えば Windows98 でもサポートされた補助漢字とか... それに Unicode に関する規格はどこまでいったのでしたっけ？ 桐は「今昔文字鏡」の前に、Windows98 以降の MS明朝とか MSゴシックで 標準でサポートされて(備えて)いる、拡張された補助漢字とか Unicode の 文字自体を取り扱えませんからね。 | |||
| 4510 | Re:「今昔文字鏡」はユニコードですね | hidetake | 2000/02/06-12:22 |
| 記事番号4507へのコメント ちなみに ATOK で取り扱える文字は ATOKでは、UnicodeでのCJK統合漢字（0X4E00〜0X9FFF）の うち、JIS第１・第２水準漢字（6,355字）、JIS補助漢字 （5,801字）、諸橋大漢和辞典にあるJIS漢字以外の、CJK 統合漢字（5909字）をCJK漢字といいます。 ATOK13W.HLP(Version=1.0,Lot=1) のようです。 Windows98 やアプリで Unicode を全て使えるという意味 ではありませんので誤解の無きよう... | |||
| 4511 | Re:「今昔文字鏡」はユニコードですね | 佐田 守弘 | 2000/02/06-12:43 |
| 記事番号4507へのコメント hidetakeさん フォローありがとうございました。 > 単に桐がその領域の文字の入力を禁止しているからでは？ 桐が扱えない文字コードの範囲の文字は、そのままコピーしても意味不明な文字 に化けるはずですから、禁止しているのだと思います。 ２バイトコードであれば、桐で基本的に扱えるはずと考えられますが、現在の JISコード体系がどうなっているか、桐は現在、どこまで対応しているのかにつ いては、調べておきたいと思います。 佐田守弘(KS-00119) | |||
| 4512 | Re:「今昔文字鏡」はユニコードですね | hidetake | 2000/02/06-19:44 |
| 記事番号4511へのコメント >桐が扱えない文字コードの範囲の文字は、そのままコピーしても意味不明 >な文字に化けるはずですから、禁止しているのだと思います。 ちなみに MS の製品であれば、自分で持てないコード(文字)については ? に変換され格納されるようです。 >２バイトコードであれば、桐で基本的に扱えるはずと考えられますが、現在の >JISコード体系がどうなっているか、桐は現在、どこまで対応しているのかにつ >いては、調べておきたいと思います。 今丁度、作っているレポートで記号を使いたい部分があるのですが、 Wingdings でも制御コードにあたる部分は桐では使えないようですね。 (;_;) あと、漢字コードに付いては、過去の経緯やしがらみ、いろいろな 考え方・使われ方があり、宗教的な雰囲気の難しい内容になってき ますよね。 桐はその点、ただ Windows 版を出すことに一生懸命で、将来的な 見通しもなく、単に互換性を重視して作ったに過ぎなく感じてしま います。 昔はともかく、桐のマルチ機種対応、あるいは、松のIBM機対応の 時期から何か変わってしまったように感じます。 同じ文章あるいはテーブルを、同じ文字コード体系のパソコンで 使っているにも関わらず、またそれが画面上全く同じ文字として 見えているにも関わらず、同じプリンタに出力しても、印刷した 結果が NEC機と IBM機で違いが生ずるところがあったのですから... (JIS83 で追加された文字と字形の入れ替えられた部分ですね) | |||
| 4529 | Re:「今昔文字鏡」はユニコードですね | hidetake | 2000/02/07-22:25 |
| 記事番号4512へのコメント >今丁度、作っているレポートで記号を使いたい部分があるのですが、 >Wingdings でも制御コードにあたる部分は桐では使えないようですね。 (;_;) なんと、桐は半角カナの領域も全て日本語フォントとしか見なさず 英文フォントやシンボルは使えないのか... (;_;) まぁ〜、お節介というか、親切丁寧と言うか... 私には自由度が無くて不満なだけだ！ | |||
| 4531 | 桐での文字データの扱い方 | 佐田 守弘 | 2000/02/08-00:20 |
| 記事番号4529へのコメント hidetakeさんはご存知の事とは思いますが、他の方々に読んで頂く意味もありますの で、御了承下さい。 >>Wingdings でも制御コードにあたる部分は桐では使えないようですね。 (;_;) >なんと、桐は半角カナの領域も全て日本語フォントとしか見なさず >英文フォントやシンボルは使えないのか... (;_;) これらは桐のデータの持ち方から推定してそうなるのでしょうね。 善し悪しの評価は様々でしょうが、桐の特徴の１つに、「全ての文字を２バイトコー ドで扱う」という点があります。 ●２バイトコード １バイトで扱える文字まで２バイトで扱うのは一見無駄な事をしています。しかし字 種を判断する事なく単純にバイト数だけでデータを切り出せるので、データを効率的 に処理できる(反対に桁数を数える時には面倒な処理になるが、その頻度は低い?)の が利点なのかと思います。 かつて私は、dBASEユーザーでしたが、dBASEではASCII文字とJIS文字を混在で扱って いました。おそらくJISコードの部分はshift JISで扱っていたのでしょう。 Accessはどうなのか詳しくは知りませんが、おそらくASCIIとshift JISの混在ではな いかと思います。これは実際に調べたわけではありませんが、元来英語文字を扱うソ フトなので、１バイトで扱えるデータまで敢て２バイトで扱っているとは思えないか らです。Accessではユニコードも扱えるとの事でしたが、各種のバイト数の文字の混 在が行える仕組みになっているのでしょうね。おそらく字種によって何バイトで１文 字とするかを判断しながら、文字処理をしているのだと思います。 これに対して、桐では全てが２バイトも字で扱われています。例えば半角の数字(数 値でなくて数字の文字)や、半角のカタカナ(ANK文字)でも、１バイトとして扱うにで なく、２バイトコードに変換して処理されます。 「桐は半角カナの領域も全て日本語フォントとしか見なさず」はこのためではないか と思われます。 ちなみに、１バイト文字と２バイト文字が混在する場合、どちらの文字であるかの判 断のために、JISコードではなくshift JISコードが使われます。 少し補足しておけば、通常のJISコードでは、２バイトコードの先頭バイトが１バイ ト文字と同じ範囲のため、先頭だけを見て１バイト文字か２バイトも自家の区別が付 きません。このためある変換演算によってJISコードを変換し、１バイト目が通常使 われる１バイト文字の範囲を外れる様にして、先頭バイトだけで２バイト文字の判断 ができる様にしたものがshift JISコードです。 付け加えれば、shift JISの先頭バイトは、元来はグラフィック文字と呼ばれる記号 の範囲でした（漢字が扱えなかったPC-8001のユーザーはご存知と思います）。 その頃の漢字の扱い方は、「ここから２バイト文字が始まる」を意味するシフトイン コードと、「終わる」の意味のシフトアウトコードでJISコードを挟む方式でした。 この方式では文字列処理が煩雑なので、シフトイン・アウトコードを必要としない shift JISコードが使われる様になりました。 話は戻りますが、桐では全てが２バイトコードなのでshift JISを使う必要がなく、 全てJISコードで処理されています。 ●制御文字 制御文字については、桐がチェックして除去しているそうです。ちなみに#JIS()関数 で制御文字を出させようとするとエラーになります。制御文字で扱いが許可されてい るのは、09(タブ)と13(復帰)だけだそうです。 「それは不便ではないか」と聞いてみた所、「表の中に改行文字が書けないだけで、 印字出力その他では１バイトコードも出せるから、特に問題がないでしょう」との答 えでした。 ●英文フォントやシンボル すみません。この意味が把握できないのですが。 桐では単に文字コードだけを記録しますから、文字列の一部にフォント情報を持たせ る事はできないと思います。文字毎に属性としてフォント情報を持たせられるワープ ロとのスペック上の違いでしょうね。 ワープロの様に部分的にフォント設定ができれば、それなりの便利性あると思います が、データ構造が全く別のものになるでしょうし、データ処理速度も重くなるのでは 。 佐田守弘(KS-00119) | |||
| 4533 | Re:桐での文字データの扱い方 | hidetake | 2000/02/08-01:22 |
| 記事番号4531へのコメント >これらは桐のデータの持ち方から推定してそうなるのでしょうね。 >善し悪しの評価は様々でしょうが、桐の特徴の１つに、「全ての文字を２バイトコー >ドで扱う」という点があります。 原因はこの辺が考えられますが、本当に無駄な事をしていない でしょうか？ 昔は、半角文字もいちいち NEC しか持たない２バイト半角文字 を使って画面表示させていた訳ですが、Windows では内部コード はどうであろうと、半角で表示される訳です。 フォントを指定できるところでは、別に指定されたフォントその まま何も変換なしに表示してくれても別におかしくないとも思い ます。 別に内部で JIS で管理し、２バイトでコードを持っていようと、 桐で半角文字を扱えない訳では無いし、そのための判断材料を 持っているのだから、そのデータを取りだし元のコードに戻した 時、素直な処理さえしてくれれば良さそうに感じます。 半角文字でも、ここからここは日本語フォント、ここからここは 英文フォントとしてチェックしている訳ですよ！ >らです。Accessではユニコードも扱えるとの事でしたが、各種のバイト数の文字の混 >在が行える仕組みになっているのでしょうね。おそらく字種によって何バイトで１文 >字とするかを判断しながら、文字処理をしているのだと思います。 これは先に書いたとおりです。Unicode で持っているそうです。 だから、半角で入力されたり表示されている文字も LenB で半角 バイト数をそのまま帰さないと... Unicode について書き出すと長くなるので省略します。 >●制御文字 >制御文字については、桐がチェックして除去しているそうです。ちなみに#JIS()関数 >で制御文字を出させようとするとエラーになります。制御文字で扱いが許可されてい >るのは、09(タブ)と13(復帰)だけだそうです。 >「それは不便ではないか」と聞いてみた所、「表の中に改行文字が書けないだけで、 >印字出力その他では１バイトコードも出せるから、特に問題がないでしょう」との答 >えでした。 この辺が昔の時代ならともかく、フォントが複数使えたり、ある いは.... な時代なのに... データベースとしても改行が持てないシステムで本当に良いの？ 日本語データベースだからといって外国語は扱えないで良いの？ このままバイナリデータは扱えなくてもよいの？ 情けない！ ;-( それでも、あなたは本当に桐と心中しますか？の境地だな... >●英文フォントやシンボル >すみません。この意味が把握できないのですが。 >桐では単に文字コードだけを記録しますから、文字列の一部にフォント情報を持たせ >る事はできないと思います。文字毎に属性としてフォント情報を持たせられるワープ >ロとのスペック上の違いでしょうね。 最初にレポートで使いたいと書きましたがフォームも同じですね。 レポートやフォームではオブジェクトごとにフォントを設定でき ます。実際は単なるラベルとかコメント用に使いたいだけですが... 別に何も難しい事は考える必要は無く、設定できるフォントその ままで出力してくれれば良いだけなのです。 英文フォントやシンボルは説明も何も、そのままフォントですね！ ps. 別のツリーで出ているフォームが印刷できないのも、機能により フォームとレポートに別れるのはわかるが、フォームを印刷でき ても良いのでは？ ちなみに Access はできますよね。ちょっと したとき便利です。 フォームでは可能なイベントやピクチャーの取込みもレポートで はできないし... | |||
| 4534 | Re:桐での文字データの扱い方 | hidetake | 2000/02/08-01:53 |
| 記事番号4533へのコメント この調子じゃ〜、桐は... 昔の日本語も取り扱えない、最新のシステムにも対応できない、 外国語にも対応できない、コンピュータ初期の頃の日本語しか 扱えない日本語データベース桐になってしまうのか... （桐は JIS83 という日本語にしか対応しておりません） :-P | |||
| 4555 | ありがとうございました。 | 向井正治 | 2000/02/08-22:17 |
| 記事番号4494へのコメント 佐田さん、Hidetakeさん色々とお教えいただきありがとうございました。 データベースソフトとしての桐では漢字人名が正しく表示されないのは現状では残念なが ら出来ないことはよく分かりました。 超漢字というＯＳでは、ＯＳレベルで漢字１０万字と言われています。 そちらも勉強してみます。 （ユニコードが使えるＡＣＣＥＳＳに切り替えることも選択肢かもしれません、先にＡＣ ＣＥＳＳかもしれません。） | |||
| 4556 | Re:ありがとうございました。 | hidetake | 2000/02/08-23:08 |
| 記事番号4555へのコメント 向井正治さん、すみません横から割り込んだ形になってしまいました。 _o_ Access も内部的には Unicode で持っていても実際にどの部分まで使えるのは 私も全く試していない状況です。 それに、「今昔文字鏡」も文字単位でフォントを指定できることが使用可能か どうかの判断材料になるようで、Access のような DB でも向井さんの要望に 叶うかどうかも全くわかりません。 Unicode 自体もシングルバイト圏の企業ベースの売らんかなの発想で出発した コードで、ダブルバイト圏のユーザーにとっては全くもって使いにくい内容の ようです。桐のような日本語に対応したソートや拡張検索などの機能を持った ソフトに取っては全くもってけしからんコード体系だと思います。 そう言っても始まらないと「今昔文字鏡」もこれに対応したようすですし... それに、超漢字も「今昔文字鏡」を元にライセンスされた OS のようですね。 | |||
| 4560 | Re:「今昔文字鏡」はユニコードですね | hidetake | 2000/02/09-09:20 |
| 記事番号4502へのコメント >Access は 95 以降に置いて、文字列は Unicode で格納されている >のでは？ >だから単純に LenB しても半角のバイト数は正しく帰さないと... これを見て Access て馬鹿だな！半角バイト数も取りだせないのか と勘違いされると困りますので書いておきますが、 LenB(StrConv(string, vbFromUnicode)) として、文字列を Unicode からシステムの既定のコード ページに 変換して計算するだけです。 あと、Windows98 以降（NT も SP を当てれば対応されるようです） で拡張されたフォントに付いて知りたければ、\WINDOWS にある GENERAL.TXT をご参照下さい。 WindowsAPI レベルでも既存の文字コードで処理するか、Unicode で 処理するかも２通りの方法がちゃんと用意されています。 ただ、既存の文字コードと Unicode では計算式による変換は不可能 なので OS 内部では変換テーブルを使って処理しているそうです。 | |||
| 4562 | Re:桐での文字データの扱い方 | hidetake | 2000/02/09-14:01 |
| 記事番号4534へのコメント 既存の隙間に新しい文字を埋め込む方向で JIS2000 は今年1月20日に 制定されていたのですね！ http://www.watch.impress.co.jp/internet/www/column/ogata/part1_4.htm に載っていました。 拡張漢字の対応や制御コードの取り扱いは単純な対応はできない部分 や難しい問題もあるでしょうが、ANK の 21h から FFh ぐらい普通に 入力できたり自由なフォントを使えるぐらいにはして下さい＞ K3 あと、桐の外部接続も気を付けなければ場合があります。 更新可能な状態で、桐で編集でもかけたものなら、桐で持てない文字 は勝手に消されるので、更新モードもそんなデータが入った項目上を 通り過ぎただけで、知らないうちに元データを書き換えていた言う事 もあり得ますので..... | |||