| 過去の桐井戸端ＢＢＳ （桐談義・その他） |
| 21100 | 桐ファイルが増えたので目的のファイルを探すのに苦労しています | 探せない男 | 2003/06/25-17:34 |
|
個人の生産性向上のために桐を使おうとしている者です。 桐のデータファイルが増えて、目的のファイルを探すのに苦労しています。 みなさんはどのようにどうなさっているのでしょうか？ １）Windows版の桐のデータの場合。 桐を起動するしかないのでしょうか。 なにかよいアイデアをお持ちの方、お教えください。 ２）過去の資産＝桐５のデータの場合 過去ログに、桐データのビューワーの話題がありました。 http://www.fuku3.com/~habata/kbbs/kakov5/00948.htm DOS窓などで、ファイラーと連動させて、さっと中身を閲覧して、 またさっと閉じる、みたいな使い方ができないかな～。 ニフティの会員でもある私は、ここで話題にのぼっていた 「RVK120B.LZH」と「こなす」 を探してみましたが、検索が下手なのかうまく見つけられませんでした。 「こなす」はPC-AT互換機用のものはベクターにありましたが、私は今なおPC-98を愛用していまして．．． どなたか、「こなす」のありかをご存じの方、お教えいただけないでしょうか？ もちろん、他のツールでもおすすめのものがあればお教えください。 現在入手可能なものは少ないのでしょうけれども。 ではよろしくお願いいたします。 | |||
| 21101 | Re:桐ファイルが多くて困っています | hidetake | 2003/06/25-18:28 |
| 記事番号21100へのコメント >「こなす」 NEC98版の「こなす」ですか・・・ 私の手元にあるのは 1994/12/28 付けのβ版ですが，DOS/V版に関しては 1995/05/07 付けで正式版が出ましたが，NEC98版の方はその後正式版は出ていないのでは無いのかなぁ～？ おそらく PC-VAN の K3UG のみでβ版テスト参加者だけに配布されたのかも？知れません。 その１つ前の Ver:2.0 は正式配布されたと思います。 ドキュメントを見ると配布自由とありますので手元にある奴を下記にアップしておきます。 一番新しい NEC98用のはメールで配布されたのか？ オリジナルのパッケージが見あたりませんが， これも圧縮しておいておきます。 1992/02/07 17:22 51,328 NASU_120.LZH 1992/08/29 11:00 52,480 NASU2&KN.LZH 1992/10/19 02:43 19,840 KAKIV100.LZH 1994/07/03 03:43 22,144 KONASU20.LZH NEC98用 Ver:2.0 桐Ｖ５対応 1994/12/28 12:39 23,945 KONASU98.LZH NEC98用 Ver:β10（β版です） 1995/05/07 11:50 26,368 KNSV25.LZH DOS/V用 Ver:2.5 http://s3.kcn-tv.ne.jp/users/hidetake/data/nasu_120.lzh http://s3.kcn-tv.ne.jp/users/hidetake/data/nasu2&kn.lzh http://s3.kcn-tv.ne.jp/users/hidetake/data/kakiv100.lzh http://s3.kcn-tv.ne.jp/users/hidetake/data/konasu20.lzh http://s3.kcn-tv.ne.jp/users/hidetake/data/konasu98.lzh http://s3.kcn-tv.ne.jp/users/hidetake/data/knsv25.lzh KAKIV100.LZH には「柿の種V1」も入っているので， 新しい桐の情報も解析して誰かビューアを作って下さい？ (^^; | |||
| 21102 | Re:桐ファイルが多くて困っています | 探せない男 | 2003/06/25-20:19 |
| 記事番号21101へのコメント hidetakeさん、こんにちは。 丁寧なご返答、そして再配布まで．．． こんなにしていただいて、恐縮しております。 さっそくダウンロードして使わせていただきます。 本当にありがとうございました。 重ねてお礼申し上げます。 >新しい桐の情報も解析して誰かビューアを作って下さい？ (^^; なるほど、Windows版の桐のビューアは登場してないのですね。 なんでしたらＫ３さんにお願いしてみましょうか（笑）。 でもWin桐のユーザーの方々には、そういうニーズがあまりなのかもしれませんが．．． ふと思いましたが、私はなんでもかんでも身の回りの情報や仕事のデータを桐のファイルにしてしまおうと思うたちで、 次々と桐ファイルを作って、かえって混乱してしまうようなのですが、これってレベルが低いからではないでしょうか。 桐の活用方法に熟練した方は、一括処理とか駆使されて、 少ないファイル数で、いろんな情報をエレガントに処理されているのかもしれないなあと思いました。 | |||
| 21106 | 桐のデータの整理方法 | 佐田 守弘 | 2003/06/26-00:02 |
| 記事番号21100へのコメント 探せない男さん かつてあった桐ファイルのビューアは、現在のバージョン用は見掛けない様ですね。 さて、桐のデータの整理方法のポイントは、次の３つだろうと思います。 ①目的別にフォルダを分類する。 他のデータファイルでも同じですが、桐の表を初めフォームやレポートなどを １式１つのフォルダに分類整理するのが基本でしょうか。 デフォルトではK3フォルダの中に記録する様に設定されていますが、 このフォルダを使う必要はありません。 私の場合、住所録や名刺管理の様な、それだけで独立したデータベースになっているものは、 tblというフォルダを作り、更にその下にサブフォルダを作っていれてあります。 それ以外に、一般的な業務と関連して作る桐のデータは、 その業務のフォルダの中にtblのサブフォルダを作って記録しています。 ポイントとしては、１つの目的のデータについて１つのフォルダを作るのが基本と思います。 ②表題をきちんと付けておく 表題に使える文字数に制限がありますが、表題をしっかり付けておけば、 桐のファイルパレットで表示できるので便利です。 その際に、「◎」常時使用中、「×」臨時作成不用、「■」永久保存などと、 記号を併用するのも１つの方法ですね。 ③メニューを作ってメニューで起動する 良く使うデータは桐でメニューを作り、メニューから起動すると便利です。 メニューの数が少なければ、フォームにコマンドボタンを並べて作れます。 膨大な表の中から目的の表を選びたいという時には、表やフォームの一覧を桐で管理する方法もあります。 表などの一覧表を作るのは簡単です。 まず、全データがc:\data直下のフォルダにあるとします。 dir c:\data\*.tbl /s /b >c:\data\dirlist.txt のコマンドを実行すれば、*.tblのフルパス名付きのファイル名が書き出されます。 これを桐の表に読み込みます。 次いで、表ファイル名や、表題名、作成日時などの項目を計算項目で作れば、桐の表の一覧表ができ上がります。 これをフォームで表示し、目的の表を選んで開く様なイベントを作る事もできるでしょう。 佐田守弘(KS-00119) | |||
| 21127 | Re:桐のデータの整理方法 | 探せない男 | 2003/06/26-21:41 |
| 記事番号21106へのコメント 佐田さま こんばんは ていねいなアドバイスありがとうございます。 >①目的別にフォルダを分類する。 耳が痛いです。 几帳面にやっていれば困ることないのですが、なかなか．．． >②表題をきちんと付けておく これもついつい急いでいると後回しにしてしまいます。 >「◎」常時使用中、「×」臨時作成不用、「■」永久保存 これは一目瞭然でよいですね。 さっそく真似てみます。 >③メニューを作ってメニューで起動する 以前に佐田さんが書かれた書籍を思い出しました。 「入門桐Ver.5一括処理編」（エーアイ出版） これにデータファイル総合管理データベースという 一括処理を載せておられましたね。 私は桐以外のツールを使おうとしてえいまあしたが、 桐ですべてやってしまうという考え方でもよいわけですねえ。 貴重なアドバイス、感謝します。 さっそく自分なりにアレンジしていきたいと思います。 | |||
| 21128 | Re:桐のデータの整理方法 | hidetake | 2003/06/26-22:09 |
| 記事番号21127へのコメント >>②表題をきちんと付けておく >表題をきちんと付けておく >dir c:\data\*.tbl /s /b >c:\data\dirlist.txt 昔，松や桐にもついていた BTYPE.COM ですが， 桐はWindows 版になっての昔の互換性だけは重んじる傾向にあるので，. WFM 以外は -T オプションをつけて BTYPE.COM -T *.* とすると(実際には > filelist.txt といったようにリダイレクトする)，桐の表題を取り 出す事ができます。 もちろん，昔の DOS のツールですので「短い名前」しか扱えません。 それでも必要であれば，dir の /x オプションと組みあわせる事により 長い名前との結合は可能だと思います。 まぁ～，そんな利用方法もあると思います。 私自身は，業務的に定型化されたものや固定的な形式の決まったデータ以外は 桐以外の，主にテキストファイルでデータは保存しています。 昔はそれを更に LZHで圧縮して保存していました。 検索する場合は grep なり LZH圧縮に対応した grep を多用する事が多かったです。 昨今は Web 上の掲示板に備忘録として記録する事も多く， ブラウザさえあれば簡単に検索できる仕組みにしてもあります。 それでも最近はデータも大きくなり検索スピードも遅くなったので， 単に Perl + TEXT での利用から昔のデータも含めて PHP + PostgreSQL に移したところです。 データの種類(不定型なもの？)によっては，何も桐にこだわらずとも，もっと気の利いた保存活用方法もあると私は思います。 例えば，10年前のデータであろうと，パソコン通信のコメントであろうと， 直ぐに取り出せる！と言うのも１つのデータベースであると私は考えています。 | |||
| 21145 | Re:桐のデータの整理方法 | 探せない男 | 2003/06/27-22:27 |
| 記事番号21128へのコメント hidetakeさま こんばんは。 示唆に富むアドバイス、ありがとうございます。 >BTYPE.COM -T *.* とすると(実際には > filelist.txt >といったようにリダイレクトする)，桐の表題を取り >出す事ができます。もちろん，昔の DOS のツールです >ので「短い名前」しか扱えません。 なるほど、そんなツールがあったのですね。 桐の表題が取り出せるとなると、いろいろ工夫できそうな気がします。 >私自身は，業務的に定型化されたものや固定的な形式 >の決まったデータ以外は桐以外の，主にテキストファ >イルでデータは保存しています。 私も同様に考える者の一人です。 （テクニックがついていかないのですけれども） でも、桐ファイルに格納された情報と、通常の雑多なテキスト情報とをまとめて スムーズに管理する方法に苦慮しています。 メールやらＷＥＢサイトやら、最近は情報の入手が楽になりましたね。 一方で自分のふとした思いつきとかアイデアとか、 ときには備忘録的なメモとかもごちゃまぜにして、 桐に入れたりテキストファイルに書き散らかしてみたり。 「蓄積」はするけれども、そこから何らかの「生産」を行おうとすると、 なかなか桐ファイルとテキストファイルをシームレスに扱えなくて困っています。 桐の「文字置換」「補集合」「整列」「絞り込み」などは、 正規表現がいつまでたっても覚えられない私なんかには、とても便利で．．． >昨今は Web 上の掲示板に備忘録として記録する事も >多く，ブラウザさえあれば簡単に検索できる仕組みに >してもあります。 便利そうですね。 >それでも最近はデータも大きくなり検索スピードも >遅くなったので，単に Perl + TEXT での利用から >昔のデータも含めて PHP + PostgreSQL に移した >ところです。 すみません、私の知識ではここ意味がわからないまま読んだのですが、 つまりhidetakeさまくらいのレベルになると、なんでもできちゃうんだな～なんて。 >データの種類(不定型なもの？)によっては，何も桐 >にこだわらずとも，もっと気の利いた保存活用方法 >もあると私は思います。 う～、その方法を会得したいと思ってから、もう何年奮闘し続けていることでしょう（笑）。 そういうノウハウって、なかなか身に付きませんね。 一介のサラリーマンには無理かなあ．．． >例えば，10年前のデータであろうと，パソコン通信 >のコメントであろうと，直ぐに取り出せる！と言う >のも１つのデータベースであると私は考えています。 まったく同感です。 さらに言わせていただければ、すぐに取り出せるだけじゃなく、その情報を組み合わせたり、分析したり、 考えるヒントにしたりして、新しいものを創り出したな～、というのが私の願いなのですが。 思わず熱くなって、長い書き込みになってしまいました、ごめんなさい。 | |||
| 21147 | 一般論としてのデータの保存と整理 | 佐田 守弘 | 2003/06/28-01:49 |
| 記事番号21145へのコメント 探せない男さん 話が面白そうな方に発展しそうなので、当初のテーマとは少しずれますが、ご容赦を。 ●テキストファイルでのデータの保存 hidetakeさんが言われるテキストファイルで記録し、それを圧縮して保存する方法は、 一般論としては正解なのだろうと思います。 その理由は、テキストファイルであれば、長い将来的なレンジで見てもアプリに拘わらず 利用できる点が挙げられるからです。 圧縮について言えば、以前は私も使う頻度が下がったものは圧縮しておく事にしておりましたが、 最近では圧縮しません。 「HDの容量を節約する必要がないのか?」に対しての答えは、 「足りなければ増設すればよい話」と割り切っております。 圧縮するなら、圧縮ファイルとしての圧縮ではなく、フォルダ単位での NTFS圧縮を使います。 ●桐の表は日本銀行の金庫 私の趣味で言えば、重要なデータは桐の表にして保存しています。 大半は表形式のデータですし、最近はCSVで取り込むケースが多いのですが、 やはり最終的には桐の表データで保存して始めて、一安心できます。 なぜ桐のデータにするか。それは単に安心できるからです。その理由は １つにはデータ破損に対して強い事、２つには古いデータでも将来に渡って 利用できる事が期待できるからです。 昔の桐ver.3(それ以前は使ってなかった)のデータでさえ、今でも使えます。 それに対して、かつてのMultiplanやMS-Chartを始め、当時のデータは 今使おうとすると、大変に苦労します。 ですから、桐のデータにしておけば、日本銀行の金庫に預けた程の安心ができるわけです。 MSアプリでは市中銀行の金庫程度ですからね。 ●グラフィックデータ 私が保有するデータを容量で見たら、多分一番多いのはグラフィックデータですね。 デジカメ写真のデータと、各種の書類を読み取ったイメージ文書のデータです。 イメージデータを保存するフォーマットは長年考えて来た課題でした。 鶴のGRP形式も使った事がありましたが、その後はSTARFAXのFAXフォーマットで保存しておりました。 いずれもBMPに変換する手段が残ってますから、今でも使えます。 現在はカラーはTIFF(jpeg)、モノクロ2値はTIFF(G4、JBIG)で保存しております。 Accessが登場した時、AccessでDBを作り、これらのイメージファイルを OLEで埋め込んだ所、とんでもない結果になりました。 これがAccess嫌いになった切っ掛けです。 イメージデータの管理も桐にさせれば良いわけで、単にファイル名を記録しておけば済みます。 私の場合で言えば、イメージデータ専用のDBは作っては下りませんが、 名刺管理システムの中で、相手先と関連づけて、カタログ、技術資料、論文 その他の書類などを保存しています。 「○○新技術の資料はどこだったけかなあ」という時には、名刺管理システムで検索して、 関連づけた資料を一発表示できる様にしてあります。 ●古いデータでもHDに保存 「古いデータはMOやCDに保存してHDからは抹消」が原則なのでしょうけど、 私は古いデータもHDに入れてあります。 先日容量が大きいドライブを購入し、今までCDやMOなどに保存しておいた 古いデータを書き戻しました。実際に行ってみると、昔のデータはそれ程ファイルサイズが大きくはありませんから、 ディスク容量をそれ程、消費する訳ではありません。 PC-9801シリーズ登場以来のデータを書き戻しましたが、容量はわずかなものです。 むしろ、これから先作成されるであろう膨大なデータで、近いうちに一杯になるでしょう。 まあ、その頃には容量が大きなドライブが出るだろうと期待しております。 個人的な欲望ではありますが、現段階でも1TB、将来的には数TB程度の安価なドライブと、 同程度の信頼できるバックアップメディアが欲しいです。 佐田守弘(KS-00119) | |||
| 21149 | Re:一般論としてのデータの保存と整理 | hidetake | 2003/06/28-08:17 |
| 記事番号21147へのコメント hidetake です。 >●テキストファイルでのデータの保存 >hidetakeさんが言われるテキストファイルで記録し、それを圧縮して >保存する方法は、一般論としては正解なのだろうと思います。 私にとってテキストファイルというのは基本的にはその方向ですが， 圧縮というのは「昔は」と書いたので，今となってある意味で当てはまりません。 実際にはテキストでおく部分と念のためのバックアップとして圧縮して別の部分に保存はしております。 それと更に付け加えるならばデータは最終的に，間違って削除したり 上書きしても，元に簡単に戻せる NetWare 上に置いていたりします。 >●桐の表は日本銀行の金庫 不定型なデータは掲示板のようなものに書くような事もしていると書きましたが， それは少し前まで Perl + TEXT で処理していました。 それを今回 PHP + PostgreSQL で処理するようにしたのですが， 過去分のデータを PostgreSQL におくにあたり，前処理は Perl で処理し カンマ区切りのファイルに加工し，一度は桐で読み込ませ再加工して， その上で「外部DB」経由で PostgreSQL に書き出すつもりでした。 そして，PostgreSQL 上にデータを置いてしまえば「桐」からも簡単に データは取り出せる(見られる)ぞと，これは便利そうなと思っていました。 でも，それは破綻しました。 まずデータを移行する段階で，桐では処理できない長さのレコードがありました。 最初は数件の事だと思ったのですが，最初移して桐で処理できなかった分は手作業で移していました。 でも，実際には桐で処理していて欠落したデータが多く， 最終的には桐を通すと処理できなくなって， 全て最初から Access で移行するハメになりました。 それと，最初に移行した段階では PostgreSQL に移したデータも桐で読めていて， 桐で今までのデータを開けるのもオツなものだと思っていました。 そして，桐で処理できなかった「長い」データを手作業で移行するにつれて， 桐で開こうとすると「桐で処理できない長いレコードを切り捨てました」と警告ができるようになり， そして，最終的に，最初から全て Access でやり直した完成版のデータになると， ついに桐からはアクセスできないようになりました！ ヽ(;´o｀)丿 結局，長い文書を含む私の不定型なデータは PHP + PostgreSQL と， 補助的にフロントエンドとして Access を使うような格好となりました。 あと，ついでに書いておきますが，PostgreSQL のデータは pg_dump と言うプログラムでバックアップを取れるのですが， それで定期的に(日毎+週毎+月毎)自動バックアップを取らせていますが， そのデータは，データベースの構造と中身のデータがテキストファイルです。 それを元に，元のサーバの PostgreSQL や違うサーバの PostgreSQLにデータベースを再構築するのも実に簡単です。 そして，そのデータの部分はタブ区切りなデータですので，普通の DB に読み込ませて使う事も可能です。 (もちろん私の場合は，長い長さのレコードも処理できる DB である必要が条件ですが・・・) それこそ PostgreSQL が無いからデータが取り出せないとかも無く， 実に汎用性のあるバックアップ形式です。（操作もコマンド一発ですし） そんなこんなで，私にとってあるデータに関しては「桐」を使う事に関しては， アクセスする事さえもできなくなった次第です。 それと，やっぱ最終的にはデータはテキストで保存されているという話でした。 | |||
| 21151 | Re:桐のデータの整理方法 | hidetake | 2003/06/28-11:38 |
| 記事番号21145へのコメント >>BTYPE.COM -T *.* とすると(実際には > filelist.txt > なるほど、そんなツールがあったのですね。 > 桐の表題が取り出せるとなると、いろいろ工夫できそ > うな気がします。 別にこれは K3 から公共の場にも公開されていたし，少し前まで ftp://ftp.vector.co.jp/pack/maker/k3/ に置いてあったような 気もします。 公開されていたファイルの添付ファイルには転載の事には 何も書かれていないので，私が公の場にアップする事はしませんが， 必要であれば次の書き込みの際にでもメールアドレスを書いて貰えば メールで送っても構いません。 別に表題だけ取り出すのだったら，こんな古いツールを使わなくとも！ VBS でも使って，長い名前や .WFM にも対応したものを 自分で作ってみるのと言うのも面白いかも？ (^^; | |||
| 21158 | Re:桐のデータの整理方法 | 探せない男 | 2003/06/28-15:26 |
| 記事番号21151へのコメント hidetakeさま こんにちは。 >別にこれは K3 から公共の場にも公開されていたし，少し前まで >ftp://ftp.vector.co.jp/pack/maker/k3/ に置いてあったような >気もします。 のぞいてみましたが、今は公開されてないみたいです。 昔の桐や松についてきていたとのこと。 ＤＯＳ版の桐と松のオリジナルディスクが実家の押入の中（笑）にありますので、 今度帰ってＦＤの中を探してみます。 >別に表題だけ取り出すのだったら，こんな古いツールを使わなく >とも！ VBS でも使って，長い名前や .WFM にも対応したものを >自分で作ってみるのと言うのも面白いかも？ (^^; やはり最後は自作、ですか～。 | |||
| 21159 | Re:一般論としてのデータの保存と整理 | 探せない男 | 2003/06/28-15:55 |
| 記事番号21149へのコメント 佐田さま、hidetakeさま こんにちは。 佐田さまのおっしゃるとおり、ＨＤは巨大化の一途をたどっていますので、 それこそ何も考えないで放り込んでおくだけでいいですよね。 大切なのは、そこから目的の情報を探し出してくる「腕」でしょうか。 私も昔のデータをいま使っているＰＣの片隅に置いています。 で、数年間にわたってあれだけ苦労して作った仕事ファイルが、 たったの２０ＭＢだったりすると、ちょっと拍子抜けします。 今から１０年以上前ですから、ＤＯＳ３．３の時代です。 ８０ＭＢの内蔵ディスクを「使い切れるのか？」なんて思ってました（笑）。 今はちょっと高画質のデジカメで撮影すると、 １枚で２ＭＢなんてサイズになってしまいますから困ったものです。 私はもっぱら画像はjpeg形式のみですが、再加工する必要があまりないので （記録として眺めるのみ）、不可逆でよしとしています。 さて、hidetakeさまのおっしゃるとおり、桐をテキスト情報の活用に使おうとすると、 やはり１レコードの文字数の制限がネックになると思います。 ２０００文字とか４０００文字ってきくと、多いようですが、 メール程度の文章でもこのくらい簡単にオーバーしませんか？ >そんなこんなで，私にとってあるデータに関しては「桐」を使う事に >関しては，アクセスする事さえもできなくなった次第です。 そんな事例もあるのですね。 短いデータでしたら、佐田さんのおっしゃるとおり日銀なみの安心感ですが、 こういうときにAccessに負けたというのは残念ですね～。 | |||
| 21172 | Re:一般論としてのデータの保存と整理 | hidetake | 2003/06/29-17:18 |
| 記事番号21159へのコメント > ２０００文字とか４０００文字ってきくと、多いようですが、メール >程度の文章でもこのくらい簡単にオーバーしませんか？ ハッキリ言って現在の状況からすると少ないです。 これからもっともっと Web との連携とか必要になってくれば制限になってくるでしょうし， 扱える文字(文字コード)の問題や制御文字などもデータベースとして取り込めないと， やはりネックになってきます。 >>そんなこんなで，私にとってあるデータに関しては「桐」を使う事に >>関しては，アクセスする事さえもできなくなった次第です。 一応，制限あり！で桐からも接続できるようにしてみました。 やり方は，サーバ側で文字数の多いデータをそぎ落として 桐に持ってくるように指定しました。 数値型や日時値型の項目あるのですが，それは使用桁数も 限られているので，取り敢えず次のように条件式として， 文字列項目だけを連結した上で 4000 文字でそぎ落としてみたところ， 一応は接続できるようになりました。 #DSQL("length(coalesce([name],'')||coalesce([mail],'')||coalesce([subject],'')||coalesce([comment],'')||coalesce([ip],''))<=4000") 今回のデータは 11,000件のうち 50件程が桐の制限を越えていたようです。 まぁ～，全部のデータとはいかないし，CR や LF ，それに TAB も含んだデータなので，桐側で弄るにも制限があるので 一応，全部のデータでは無いけれど，制限ありで見る事が できるようにはなったと言う事です。 それと，私も次の課題としてメールをどうしようかと考えていました。 私はメールとして WZ Mail を使っているのですが， その中で検索もできますし，データそのものはファイル単位だし テキストになっているので grep 等は使えるのですが， 今後これをどうしようかと・・・ 今のところ 200MB弱の容量です。 メールアドレスなどもメールソフトと住所録などで， 皆さんは一元管理できるようにされているのでしょうかね？ もちろん，私も受け渡しはできるのですが，WZ を使っている関係で， 実際には今のところ個別管理状態になっています。 (;_;) これもメールソフトとの関係で WebMail に移行すれば一発で可能になるのですが， これも使えるようにはしているものの全部 WebMail にまではいたっておりません。 出先からの時だけの使用にとどまっています。 | |||
| 21211 | Re:一般論としてのデータの保存と整理 | hidetake | 2003/07/01-17:27 |
| 記事番号21149へのコメント hidetake です。 >>●テキストファイルでのデータの保存 >>hidetakeさんが言われるテキストファイルで記録し、それを圧縮して >>保存する方法は、一般論としては正解なのだろうと思います。 少し飛躍させて，インターネット上でファイルをおく場合での意味について書いておきます。 インターネット上にテキストファイルを置く場合も多々ありますが， その場合にどのような形式でおくべきか？ と言う問題についての考証です。 先に，#21185 の「Re:コマンドクエリ on PostgreSQL」において 次のような書き込みとデータを置いております。 >一応サンプルとして，任意の SQL文を投げかけるものを作ってみました。 >http://s3.kcn-tv.ne.jp/users/hidetake/data/runsql.txt.gz これはものとのサイズ 526,883バイトのテキストファイルを GZIP で 4,521バイトに圧縮した形でおいてあります。 たった 1% 以下のデータに収まっています。 (^^; さて，次のリンクをブラウザでクリックした場合にどのような 動作になるのか？ 考えてみて下さい。 http://s3.kcn-tv.ne.jp/users/hidetake/data/runsql.txt.gz http://s3.kcn-tv.ne.jp/users/hidetake/data/runsql.txt 実際に存在するファイルは runsql.txt.gz だけであり， runsql.txt と言うのは，その中身のファイルに過ぎません。 これを通常のブラウザでクリックすると，Web サーバは， 実データとして 4,521 バイトしかインターネット上に送出しません。 そして，受け取ったブラウザは 526,883バイトの分の全データをブラウザ上に表示されるはずです。 それはブラウザが gz 圧縮に対応していて，自動的に解凍して見せてくれるからです。 そんなメリットもあります。 (^^) で，この掲示板の「補完ＢＢＳ」でも拡張子が .gz なデータをアップロードできたらいいなぁ～ なんて・・・ (^_^ゞ | |||
| 21272 | Re:桐のデータの整理方法 | hidetake | 2003/07/04-15:02 |
| 記事番号21158へのコメント >>別に表題だけ取り出すのだったら，こんな古いツールを使わなく >>とも！ VBS でも使って，長い名前や .WFM にも対応したものを >>自分で作ってみるのと言うのも面白いかも？ (^^; 一応，作ってみました！ (^^) http://s3.kcn-tv.ne.jp/users/hidetake/data/ktitle.vbs ktitle.vbs x:\path\filename.exe とすればポップアップで桐の表題が表示されますし， cscript ktitle.vbs x:\path\filename.exe とすれば標準出力に表示されるので > filename.txt といったように リダイレクトすればファイルに落とす事も可能です。 取り敢えず単体のファイルの処理ですが，必要に応じて スクリプトを改造したり，リダイレクト処理を繰り返し 呼び出しても良いでしょう・・・ (^^; #蛇足？ # 別に書き殴りやちょいと使うような一括処理は # C:\Program Files\KIRIv9\System\KIRI9.EXE /R http://s3.kcn-tv.ne.jp/users/hidetake/data/runsql.txt # なんてして，編集には普通のテキストエディタを使う # のも楽しいような？ (^^; | |||
| 21273 | Re:桐のデータの整理方法 | hidetake | 2003/07/04-15:06 |
| 記事番号21272へのコメント >http://s3.kcn-tv.ne.jp/users/hidetake/data/ktitle.vbs >ktitle.vbs x:\path\filename.exe filename.ext と書いたつもりが exe となっていました。 (^^; 勘違いされるかな？ ファイルには桐のファイルを与えて下さい！ | |||
| 21312 | Re:桐のデータの整理方法 | hidetake | 2003/07/07-20:30 |
| 記事番号21273へのコメント >http://s3.kcn-tv.ne.jp/users/hidetake/data/ktitle.vbs >ktitle.vbs x:\path\filename.exｔ >dir c:\data\*.tbl /s /b >c:\data\dirlist.txt の代わりになるものも作ってしまいました。 http://s3.kcn-tv.ne.jp/users/hidetake/data/ktitle.vbs は前のものより少し改良してあります。これは１ファイルずつを処理する基本システムです。 ワイルドカードを利用したい場合などは，コマンドプロンプトから次のように行う事も可能です。 X:\>for %f in ("C:\K3\KIRI9\Sample\例題\フォーム\*.*") do cscript x:\ktitle.vbs "%f" >> x:\outpu.txt 次に，フォルダを指定して，サブフォルダも含めてリストを作るタイプは，次の２つです。 http://s3.kcn-tv.ne.jp/users/hidetake/data/ktitle_a.vbs http://s3.kcn-tv.ne.jp/users/hidetake/data/ktitle_b.vbs 最初の a がノーマルタイプで，b がショートファイルネームも付加するものです。 cscript x:\ktitle_a.vbs "C:\K3\KIRI9\Sample" > x:\outpu.txt と言うようにフォルダを指定して使います。 何れもファイルに落とす場合は cscript 経由で vbs を起動して下さい。 また，最初から桐に取り込むのが目的なら http://www2u.biglobe.ne.jp/~s_tanaka/cgi-bin/bbs/bbs.cgi#4314 の方法を使うのが楽かも知れません。 あるいは，上記 VSB の出力を「カンマ区切り」ファイルで出力するように改造するのも手です。 | |||