| ホームへ戻る｜Data Base 桐 User Board｜過去ログ一覧｜検索｜プロパティ ｜ほっ！ |
| ▼過去ログ No136 |
| 書き込み数 : 6800件 |
|
|
|
||||||||||||
|
従来の桐の利用者コードとかAccessのデーターベースパスワードとかの 単に開けなくするパスワードから、 暗号化キーを使用してファイル自体を暗号化するようになった。 天と地の差です。 |
|
|
|
||||||||||||
|
> そんなことしなくても開いている表なら目で見えるだろう と言うより、目に見えても外部に簡単に抜き出せないように 書き出しや印刷、クリップボード操作を禁止するぐらいだから その他の抜け道も作ってはいけないのでは無いかと・・・ もちろん、手写しやカメラによる撮影なんて面倒な手間無しで と言う意味で？ 桐って、本当に開発の統括者が全体を把握しているのか？って 言う疑問があり、（なんか担当者によって全く違う作りがあっ たり、普通は必要ないような機能まで隠されていたりして・・・） そんな思いもよらないところで、抜け道があったりするのでは 無いかと気にはかかってます。 |
|
|
|
||||||||||||
|
>#COMMANDLINE関数 で言えば、入力の際に数値項目で >#commandline("cmd.exe /c echo "+[氏名]+">x:\file.txt") そんなことしなくても開いている表なら目で見えるだろう、と思ったのですが フォームなら制限できますね（しかし訂正できる状態だと値複写が禁止できないのでだめ？） その制限を回避される、と。。。 ファイルメーカーだとフィールド単位でアクセス権を設定できるのですが、 その辺は変わらないのですかね〜。 利用者コードってユーザ名なしのパスワードだからFMPだと2世代前のと同じレベル... |
|
|
|
||||||||||||
|
おはようございます。 >> Accessより桁違いにセキュリティが強固になった >Access が20桁に対して桐が72桁だから桁違いですか？ Access のデータベースパスワードは開けなくするだけでファイルの暗号化をしていないのです。2Bite書き換えれば開けちゃいます。 コマンドメニューにある暗号化は桐と同様で、バイナリエディタで覗けなくしているだけです。 Access のワークグループパスワードも会社からAccessファイルをコピーしてきて、自宅のＰＣで開いちゃいますし、ODBCで接続できちゃいます。 ファイルを暗号化キーで暗号化している為、 「Accessより桁違いにセキュリティが強固になった」 |
|
|
|
||||||||||||
|
> #COMMANDLINE関数 で言えば、入力の際に数値項目で これで１データが抜けたとしたら、検索の条件式に埋め込んだら どうなるか？ とか、セキュリティというのは一カ所洩れると・・・ 他にも何かあるような気もするけど、ちゃんと抜けは無いように してあるのだろうか？ なんて、心配性な私は気になるのです。 |
|
|
|
||||||||||||
|
> あと、セキュア桐状態では、一括処理の機能は一部制限されるので > しょうが、書き出し・印刷・クリップボード関係は当然として > 印字コマンドや変数書きだしコマンド(機能)なども制限されるので > しょうね！ （#COMMANDLINE関数もか！？ メール送信なども当然？) > 外部とのやり取りを全て禁止しようとすると、いろんな関数や > コマンド関係(ファイル操作などが一番危険か？)まで、結構影響が > 大きいような気がします。 #COMMANDLINE関数 で言えば、入力の際に数値項目で #commandline("cmd.exe /c echo "+[氏名]+">x:\file.txt") なんて書いて、Shift + F9 で、その時に開いている項目の内容を リダイレクトしてファイルに落とす事なんて言うのもできちゃう ので危険では？という事です。 だから、セキュア桐状態では、このような細かい抜けを無くす 必要もあるのだろうな？と・・・ |
|
|
|
||||||||||||
|
> しかも、セキュリティキーは最大72文字まで設定可能なので、 > 「偶然同じキーワードを使われる」可能性もほとんどありません。 折角だから、一般ユーザを誤解させないためには しかも、セキュリティキーは最大72文字まで設定可能です。 セキュリティキーは長ければ長いほどセキュリティ強度は あがり、「偶然同じキーワードを使われる」可能性もほと んど無くなります。 12文字以下の短い長さや、文字列に意味を持つセキュリティ キーを使うと、その安全性は低くなりデータ漏洩の危険性は 高くなります。 なんて、書き添えた方が「桐9-2006」の「セキュア桐」状態 にしただけで安全が確保できると信じ込むユーザーは多少は 少なくなるかも知れない？ |
|
|
|
||||||||||||
|
> 1024bit でも 576bit位でも そこまで使えばそうなのでしょうね！ でもパスワード方式だから いくら72文字まで使える言っても、実際に付ける人はすく無さそう？ あと、パスワードに使える文字は限られるから 8bit と言っても 実際にはその半分以下で 7bit で１文字程度でしょうか？ パスワード方式で一般的に安全と言われるのは 14文字以上でしょう から単純計算して 98bit で、RSA が破られて話題となった 56bit は超えているし、IE などが標準で備えている暗号強度の 128bit にほぼ匹敵するというところなのでしょうかね？ > Accessより桁違いにセキュリティが強固になった Access が20桁に対して桐が72桁だから桁違いですか？ 確かに仕様的には桐の方が桁数では上でしょうが、私は今までの K3 を見ていると、実際はどうかな？って、現物を見てみないと 何とも言えない状態です。 (^^; もちろん、このご時世ですからちゃんとセキュアなものが欲しい ですし、桐も更に上を行ってもらいたいと思っているのですが！！！ # Office 関係はパスワード解析ツールやサービスがあるのは # 知っています。でも、私自身の知識では解けなかった。 :-( # Windows は 127桁ものパスワードが使えろ言うのに Linux # との関係で 8桁のパスワードを未だに使い続けているのなぁ〜 (;_;) # パスワードはシステムによって変えろヨ！ orz # Linux は SSH で主に使っているし、インターネットにも # SSH は公開し外部からも使えるけど、鍵方式しか使っていな # いので別に心配はしていない！ 当然 port も変えているし |
|
|
|
||||||||||||
|
hidetake さん、戻りました既に酔っ払っているけど 1024bit でも 576bit位でも、普通は総当たり方式で生きているうちに当たりを引くことは無いでしょう。 セキュア桐のアナウンスを見て、Accessより桁違いにセキュリティが強固になった と喜んでいたところで 、hidetake さんの書込み<6778>を読んで、つい突っ込みすぎました。 私はこの議論は辞めにします。 |
|
|
|
||||||||||||
|
現在の桐だと DynamicWrapper を使えば次のような VBScript で '--------------------------------------------------- Set UserWrap = WScript.CreateObject("DynamicWrapper") Set UserWrap = WScript.CreateObject("DynamicWrapper") UserWrap.Register "USER32.DLL", "FindWindow", "i=ss", "f=s", "r=h" UserWrap.Register "USER32.DLL", "PostMessageA", "i=llll", "f=s", "r=l" hWnd = UserWrap.FindWindow( "Kiri9", vbNullString ) result = UserWrap.PostMessageA( hWnd , &H0111, &H0A330, 0 ) '--------------------------------------------------- 「利用者コード」ウインドウを開く事ができるので、あとは SendKeys で、利用者コードを次々と放り込む事もできるのですが、「セキュア 桐」はこのような処理にはどのように動作するのだろう？ (セキュア桐の状態で一括処理でのセキュリティキーの設定機能が 無いとか禁止してある状態の事を考えると) # スパイウェア／キーロガー対策と言う表現もあるので結構制限が # きつくしてあるようには感じる。 あと、セキュア桐状態では、一括処理の機能は一部制限されるので しょうが、書き出し・印刷・クリップボード関係は当然として 印字コマンドや変数書きだしコマンド(機能)なども制限されるので しょうね！ （#COMMANDLINE関数もか！？ メール送信なども当然？) 外部とのやり取りを全て禁止しようとすると、いろんな関数や コマンド関係(ファイル操作などが一番危険か？)まで、結構影響が 大きいような気がします。 パスワードさえ守れれば結構おもしろいのだろうと思う。 # ただ、セキュリティに関しては決して鵜呑みや神話は作らずに # (信頼しすぎず)ちゃんと細かいところまで、気を付けないと安全 # は確保できないと心得ておいた方が良いと思う・・・ :-p # それと、セキュリティキーとしてのパスワードに使える文字は # どうなっているだろう？ 今までと同じようにｶﾅも使えるかな？ # だと、bit長として使える文字数も増えるわけで、当然 72文字の # 制限でもセキュリティ強度は上がるわけですが・・・ |
|
|
|
||||||||||||
|
576bitって72文字のことだと思いますけど、実際には72文字のパスワードを使うユーザは ほとんどいないのでは？ （電話番号などはだめ、と書いてあるから文字数の下限はないのでしょうし） もうちょっと詳しい情報がないと何とも言えませんね〜 |
|
|
|
||||||||||||
|
だから、<6785>で書いた >で、何が言いたいかというと、 >秘密キー・公開キー方式と、単一の暗号化キー方式とで、 >その方式の違いによって暗号強度に差が出るのではないということ。 1024bit と 576bit位 の違い、 セキュア桐を1024bitにすれば同等ですが、開くの遅くなるとかライセンス関係で この位にしてるのかな。 hidetake さん、所用で外しますので、続きはまた今度、スミマセン。 |
|
|
|
||||||||||||
|
> 秘密キーを総当りで 秘密キーを総当たりでって、秘密鍵そのものを作り出すという事 ですよね！？ それ以外にパスフレーズも解析しないといけないし・・・ パスワードの72文字のレベルとは全然桁違いのレベルだと思うけど？ |
|
|
|
||||||||||||
|
うーーん、 セキュア桐の暗号化キーを総当りで調べれば解読できるって話でしょ？ 非対称鍵暗号でも秘密キーを総当りで(brute-force method)調べれば同じ。 |
|
|
|
||||||||||||
|
問題になるのは暗号の強度ではなく、パスワードの強度という事だと 思うのですが？ |
|
|
|
||||||||||||
|
で、何が言いたいかというと、 秘密キー・公開キー方式と、単一の暗号化キー方式とで、 その方式の違いによって暗号強度に差が出るのではないということ。 それから、これが最も嬉しいのですが セキュア桐ではAccessより桁違いにセキュリティが強固になった(^_^)v |
|
|
|
||||||||||||
|
> 公開鍵と秘密鍵、方式は原本の証明 > 作成者の証明やメール発信者の証明にも使える点で有用なのです。 パスワードのセキュリティと同等に簡単に突破できるのに？ > 「秘密キー」をbrute-methodで突破する事と同意では？ って、どういう意味なのだろう？ # SSH で、「パスワード認証」を禁止して「鍵交換方式」 # だけを有効にする意味って何！？ :-) |
|
|
|
||||||||||||
|
公開鍵と秘密鍵、方式は原本の証明 作成者の証明やメール発信者の証明にも使える点で有用なのです。 |
|
|
|
||||||||||||
|
> 同じように思えるのですが そうですか、だったら鍵方式を採用し、わざわざ公開鍵と秘密鍵をペアで作り、 秘密鍵はセキュリティを保つために置き場所や保存管理方法など気を付けなけ ればならないシステムなんて、そのセキュリティ強度に対しては馬鹿みたいな システムですね？・・・ # 昔登録した PGP の公開鍵 # http://keyserver.veridis.com:11371/search?q=hidetake # 一番古い奴は「秘密鍵」無くしたんで使えないや！ orz |
|
|
|
||||||||||||
|
>「鍵」方式というのは PGP や PKI 等で使われていますが、興味があれば > 調べてみて下さい。 >「公開鍵」「秘密鍵」等の鍵を生成し、暗号化は「公開鍵」で行い、復号は >「秘密鍵」で行います。 同じように思えるのですが、「秘密キー」をbrute-methodで突破する事と同意では？ セキュア桐の鍵長は576bitくらいでしょうから (ハッシュかませてあれば別でしょうが) PGPと強度は変わらないと感じます。 アルゴリズムに何を使っているか現時点で不明ですが、 |
|
|
|
||||||||||||
|
> セキュリティキーで暗号化しているのではないのでしょうか？ 当然そうでしょ！ パスワード方式というのは、パスワードさえ一致すれば、本当にその人か どうかなんてお構いなしで認証され、使用許可を与えられる仕組みです。 ですので、K3 の書いているとおり >「偶然同じキーワードを使われる」可能性もほとんどありません。 ですが、総当たり戦でいけば、必ずキーワードは一致する(させられる)の です。(ただハッキングの効率は非常に悪く時間もかかるでしょうが！) 普通ですと、認証の際に何回か失敗すればそのパスワードは使えなくする ような仕組みで、このような弱点は補われるわけですが、紛失(盗難)した パソコンであり、全くのスタンドアロン方式であれば、このような制限も なく、時間はいくらでもかけられるのでは無いでしょうか？ # いろんな(ハッキング)ツールもあるわけですし・・・ ついでに書いておけば今までの「利用者コード」と何が違うのかと言えば、 パスワード(利用者コード)を生のままでファイルの中におくのか、ハッシュ (暗号化)しておくのかの違いだと思います。 通常、セキュリティを少しでも考慮したシステムだと、パスワードを生の まま管理するなんてあり得ないわけで、今回の「桐」はこれで普通のセキュ リティ機能をもったシステムにやっとなったと言えるような気がします。 # >「利用者コードを解析され、解除してしまう」可能性がある # なんて書いてあるけど、今までの利用者コードなんて解析する必要も無く # 解除(無かったものに)する事さえも可能でしたよん！ だから、桐の(新)方式によっては、ハッシュ値の傾向を探り、パスワードを 推測する方式のアタックの可能性もあるかも知れません。 これらの危険性がパスワード方式にはあるわけですが、「桐9-2005」のキャン ペーンについてきた「カチャッとUSBパソコンロック」だと、このパスワード 方式よりも堅牢なシステムだ(パスワード方式は心配だよ！)と、ハードウェア の「鍵」を持ったシステムをおまけに付けていたわけです。 http://www.lifeboat.jp/products/pclock/pclock.html 「鍵」方式というのは PGP や PKI 等で使われていますが、興味があれば 調べてみて下さい。 「公開鍵」「秘密鍵」等の鍵を生成し、暗号化は「公開鍵」で行い、復号は 「秘密鍵」で行います。 パスワード(パスフレーズ)が一致するだけでなく、鍵を持たないと解読する 事は不可能なシステムです。 |
|
|
|
||||||||||||
|
> kthree の Webサイトの情報を見てみるかぎり、結局はパスワード方式であり > よりセキュアな鍵方式などでは無いのですよね・・・ 意味が解らないのですが、スミマセン セキュリティキーで暗号化しているのではないのでしょうか？ |
|
|
|
||||||||||||
|
なんか新しい桐がでるようですね！ 今の時期にでるので、来年でるという新しい Excel には対応していないと 思いますが(と言う事は来年も更に新製品はでる？)、時流にのってセキュリティ を考慮した製品のようですね。 今までがあんまり古くさい状態だったので、セキュリティの重要性を考慮し 新しい方式で出したのでしょうか？ ただ、気になるのは「セキュア桐」と言うわりには、『「ノートPCを落とした （パソコンを盗まれた）」といった事態を想定』と言う前提だと、どこまで セキュアなのかな？と言う事です。 kthree の Webサイトの情報を見てみるかぎり、結局はパスワード方式であり よりセキュアな鍵方式などでは無いのですよね・・・ パスワード方式で結局は MAX72 文字であれ、時間さえあれば(kthree の前提 だと時間はたっぷりある)総当たり方式で破られる可能性はあるのですよね・・・ # 鍵方式(公開鍵暗号方式)まで入れると桐の利用者としては難しすぎるの # だろうか？ そこまでは必要ないのだろうか？ でも「セキュア」と呼ぶには・・・ # SSH の世界でも、今ではサービススキャンで空いているかどうかのチェック # だけが、総当たり攻撃に転じているようで、鍵方式でなくパスワード方式は # あぶない世界になって来ているのだろうけど・・・ |
|
|
|
||||||||||||
|
>コマンドボタンだと「再生」のピクチャーでは無いの？ その通りなのですが… 私が試しに作った擬似行セレクタの場合、 コマンドボタンを透明にしたのでピクチャも透明に…(T_T) |
|
|
|
||||||||||||
|
> ▶ コマンドボタンだと「再生」のピクチャーでは無いの？ |
|
|
|
||||||||||||
|
>UNICODEだと0x25b6に黒三角の右向きがありますね（▶） なるほど！ＵＮＩＮＣＯＤＥにはあったとですか〜！ |
|
|
|
||||||||||||
| UNICODEだと0x25b6に黒三角の右向きがありますね（▶） |
|
|
|
||||||||||||
|
>行セレクタの右向き▲(以下▲)は ↑は？？？だったのでよく読んだら、 黒三角の右向き、つまり処理対象行のマークの事だったのですね。 試しに、透明なコマンドボタン＋テキストボックスで、 テキストボックスの［編集属性式］で背景色：黒＋くぼみ、 と、擬似行セレクタを作って試してみましたが、 さすがに、黒三角の右向きのキャラが無くて、格好がつきませんでした。 トホホ、杜甫ほっ！ |
|
|
|
||||||||||||
|
なるほど。色々手はありますね。 なでしこを使うと 「桐*」に「%EW^ 」をキー送信 すると、「▲が表示されてる場所と、行セレクタの反転場所が一致」させられます。（全解除して対象行を選択） でも一致しないのがメリットなんでしょうけど。 |
|
|
|
||||||||||||
|
> 任意の行セレクタを凹ませたり、解除 桐の場合は任意のキー(コード)を送るのはできないので何ですが Sendkeys が使えるならば「行ｾﾚｸﾀ」にフォーカスを移動して WScript.CreateObject("WScript.Shell").Sendkeys("^ ") すれば、凹ませたり、解除したり、行を移動して複数行の設定を 変更したりもできるのですが・・・ |
|
|
|
||||||||||||
|
任意の行セレクタを凹ませたり、解除するのは無理のようですが･･･ もしも、行セレクタが凹んでいる状態を全解除するのならば、 表示 → 訂正 → 表示 と強引に更新モードを遷移すればできるようです。 コマンドボタンでも可能ですし、次のような手続きでもＯＫだと思います。 ※入力前や入力後 etc.のイベントがある場合は、いったんoffにする必要があるでしょうけれど… 手続き定義開始 cmdTestClick( ) メソッド呼び出し @ﾌｫｰﾑ.更新モード設定( 0 ) メソッド呼び出し @ﾌｫｰﾑ.更新モード設定( 2 ) メソッド呼び出し @ﾌｫｰﾑ.更新モード設定( 0 ) 手続き定義終了 |
|
|
|
||||||||||||
|
行セレクタは会話処理で使うことしか考えられてないようで、選択状態を変更する コマンドやプロパティがありませんね。。。 元々オブジェクトは１つしかないので、選択状態なのはレコードの方なんでしょうけど、 「レコードを選択状態にする」というコマンドもないようです。 結局選択状態を使うのは会話処理の行削除か絞り込みくらいしかないようですし。 行セレクタは「指定行」で使うのが主用途なんじゃないでしょうか。 （とびとびにも選択できるので、検索条件を変えながら「これとこれと〜」と選択状態にして 最後に絞り込みできる。） |
|
|
|
||||||||||||
|
> FROMとINTOとどっちの段階でかわかりませんが、この方式だと""なしの1/2でも > 日付になりませんね。（OpenOfficeで開くと'1/2になっている） これは Jetエンジンがある程度の行数を読んで自動的に 判別して処理していたように思います。 > 書式を設定しているわけではないし、001のようなデータは頭の0がなくなっている。。。 これは、0123 では無く "0123" と "" で括れば「前ゼロ」も ついたままになると思います。数値で前ゼロを実現するには 書式設定しかないわけだし、必要であれば後から書式を設定 しても良いとは思います。 今回は面倒な事は省いて、いかに簡単に CSV の取り込みを 行うかを実現するために SELECT * INTO シート ・・・ で 書きましたが、より細かい処理を行うにはレコードセットで データを取り出し、１行１行(１項目１項目)毎に処理するよう に(処理すれば)細かい事は可能だと思います。 |
|
|
|
||||||||||||
|
ありがとうございます。 「ADOはODBCなんですね。」というのは当たった文献が悪かったようで、 ado xls で検索したらMSのサイトに色々詳しく書いたのがありました。 （ちょっと前までは翻訳ソフトそのまんまのひどいドキュメントが結構多かったような気がしましたが。。。） なでしこだとこんな感じでExcelの入ってないPC（XPSP2）でもXLSが作れました。 「Provider=Microsoft.Jet.OLEDB.4.0;Data Source="E:\book.xls";Extended Properties=Excel 8.0;」でADO開く 「SELECT * INTO シート FROM [Text;database=E:\].[text.csv];」をSQL実行 そのまんまですね＾＾； FROMとINTOとどっちの段階でかわかりませんが、この方式だと""なしの1/2でも 日付になりませんね。（OpenOfficeで開くと'1/2になっている） 書式を設定しているわけではないし、001のようなデータは頭の0がなくなっている。。。 本筋とは関係ありませんが、パスがI:だとアクセスできないという謎の現象がありました。 I:はUSBのMOです。うまくいったE:はHDです。 もう数年たったらXMLで全てOKということになりそうな気がしますが。 |
|
|
|
||||||||||||
ついでに書いておけば CSV の取り込みも DAO と同じ記述方法で
いけるようです。
' csv2xls_ado.vbs
'----------------------------------------------------------------
Set Cn = WScript.CreateObject("ADODB.Connection")
Cn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=l:\book.xls;" & _
"Extended Properties=""Excel 8.0;HDR=Yes;"""
Cn.Execute "SELECT * INTO シート FROM [Text;database=l:\].[text.csv];"
Cn.Close
Set Cn = Nothing
'----------------------------------------------------------------
|
|
|
|
||||||||||||
|
右向き▲はカーソルのある行（処理対象行）で、行セレクタは 選択した行（複数もある）みたいです。 |
|
|
|
||||||||||||
|
条件は、フォームの一覧表形式で、行セレクタが表示されてる場合です そのフォームで、項目検索を行った場合、行セレクタの右向き▲(以下▲)は、検索した 行へ移動します・・ここまで、とうぜんの話です しかし例えばその前に違う行を選んでた場合(その行の行セレクタが反転してる状態で)、 検索を実行すれば「▲」はたしかに検索された結果の行に移動しますが、行セレクタの 反転は変更ないようです つまり▲が表示されてる場所と、行セレクタの反転場所が一致しないということです これは故意にも、表示できます。 一覧表形式フォームでは項目の表示があるはずですが、 １．行セレクタをクリックして移動した場合 クリックした行セレクタが反転し、▲も移動し、その行が対象となります ２．しかし、フォーム内の項目をクリックして移動した場合 対象行の移動はしますが、▲だけ移動し、行セレクタの反転は変更ありません そこで、疑問ですが ・なぜ、行セレクタの反転と、右向き▲が、一緒に移動しないのでしょうね なにかメリットもありそうですが。 また、その反対に、検索等や、フォーム上の項目クリックで、行セレクタの反転と▲が 一緒に動く方法等はあるのでしょうか (しかし、もし一緒に動くようにすれば、２個の目印は不要かも？)と思いながらの投稿です |
|
|
|
||||||||||||
> ADO
ADO にも接続方法はいろいろあるはずですが VBScript だと
次のような感じでは！？
' CreateXLS_ADO.vbs
'----------------------------------------------------------------
Set Cn = WScript.CreateObject("ADODB.Connection")
Cn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=l:\book.xls;" & _
"Extended Properties=""Excel 8.0;HDR=Yes;"""
Cn.Execute "CREATE TABLE シート (id int, data char(255));"
Cn.Execute "INSERT INTO [シート$] (id, data) values (111, 'ABC');"
Cn.Execute "INSERT INTO [シート$] (id, data) values (222, 'XYZ');"
Cn.Execute "INSERT INTO [シート$] (id, data) values (333, '1/2');"
Cn.Close
Set Cn = Nothing
'----------------------------------------------------------------
|
|
|
|
||||||||||||
|
>1月2日になってました。 1/2が1月2日になるのは「そのまま」渡ってるからで、文字列にするには 書式を設定しないといけないわけなんですね。。。 「なでしこ」には「エクセル着色」というのがありますが書式設定はないようです。残念。 画面表示させておけば「キー送信」で設定できそうですが。 ADOはODBCなんですね。事前にデータソース定義が必要では 単なるCSV-XLS変換には向かないような。 DAOは、いきなりファイル指定するだけでデータベース扱いできるんですね。。。 |
|
|
|
||||||||||||
|
> ちなみにパソコンでは「24:00」はないのでしょうか？ これらは時間の扱いでいろいろな論点があります。 10進法の一桁は0から9までで、10に相当する一文字の数詞を使わないに相当すると思います。 2進法で2は使わないし16進法で16に相当する数詞は使いません。 24時間制では時刻の時間部分は0時から23時までで24時は桁上がりで日付を加算し0時になる。 12時間制なら0時から11時までで、午前12時や午後12時は存在しない。 拡張表示で深夜番組などは○○日26時（○○日の翌日の2時）という表現はしますが例外といえます。 時間がらみでも日付の場合は1日から月末の28,29,30,31までで表します。 月は1月から12月だし20世紀は1901年から2000年までです。 この辺は、時間は量として扱い、日付は数というか時間軸上の位置を扱うからかと個人的には考えています。 まとまりが無い話ですが、時間の単位は奥が深く色々な考えがあると言えます。 |
|
|
|
||||||||||||
|
TVの番組表などで25:00とかやってるようですが、普通は01:00になってしまいます。 表示を24:00にしたいだけなら文字列扱いにすればどうとでもなりますが。 桐も加算の結果が24:00になれば1日進みますが、入力はできませんね。。。 ちょっと違う話ですが、FreeBSDはうるう秒に対応してると聞いたような。 PCのクロックは対応してないはずなので、データベースからうるう秒のリストを 引っ張ってきて、ずらすんですかね。 |
|
|
|
||||||||||||
|
ちなみにパソコンでは「24:00」はないのでしょうか？ 桐もエクセルも・・・ ちがうかも知れませんが「１００円を１個」＋「１０円を１２個」の場合 普通は「２２０円」というように、それを「１００円１２０拾円」というような 無理なのでしょうね(また、違ったかも) |
|
|
|
||||||||||||
|
あっ。できました 単に、「10/11 00:00」と入力すればＯＫでした エクセルでドラッグして作成したファイルを桐へ変換したため 先ほどの質問でした。どうもお騒がせいたしました エクセルでは、自動的に「24:00」と入力すると、日が１日進むのですね また新しい発見をしました。 |
|
|
|
||||||||||||
|
#時間加算(#日時値("2005-10-10 21:0:0"),#連番,1) で10/11 00:00になりますが？ 桐はうるう秒には対応してませんから23:59の次は00:00にしかなりませんね。 |
|
|
|
||||||||||||
|
私もあまり詳しくわかりませんが、桐表[日時型項目]で、１時間おきの表を 作成したいのですが、24時制で「24:00」の表示がうまく行きません (00:00でもいいです) やりたいことは 10/10 22:00 10/10 23:00 10/10 24:00 10/11 01:00 10/11 02:00 できなければ 10/10 22:00 10/10 23:00 10/11 00:00 10/11 01:00 10/11 02:00 ですが、結果は 10/10 22:00 10/10 23:00 10/10 00:00 10/11 01:00 10/11 02:00 このように、ちょうど「24:00(00:00)」の場合の日付のほうの表示です 「24:00」ができれば前日で、もし「00:00」ができれば翌日にしたいのですが これは無理でしょうか ちなみに「24:00(00:00)」は、前日でしょうか？翌日でしょうか？ |
|
|
|
||||||||||||
|
だははは^^;;1月2日になってました。 >要は Excel.Application に処理させているだけですよね？ たぶんそうです。 「エクセル終了」を忘れて実行してたら戻ってこないのでコマンドプロンプトをとじちゃったら、 あとでプロセスがいっぱい残ってました。 |
|
|
|
||||||||||||
|
> なでしこ なかなかおもしろそうですね！ 桐もこれぐらいの機能はできると 楽しいだろうに！？ 取り込んでしまえば良いのに・・・ (^^; > CSVを開いてCSV取得してDATAに代入 > 「A1」へDATAをエクセル一括設定 これで 1-2 とか 1/2 と言うような値もそのまま Excel に渡される のですか？ 「エクセル一括設定」と言うのはどういう処理になって いるのか？ 要は Excel.Application に処理させているだけですよね？ |
|
|
|
||||||||||||
|
「なでしこ」でCSVをXLSに変換してみました。（エクセルがないとできませんが） まるっきり日本語なのが感動的です。AppleScriptに勝てるかも。 CSVはコマンドライン[2] XLSはCSVを「.XLS」に拡張子変更 CSVを開いてCSV取得してDATAに代入 オフでエクセル起動 エクセル新規ブック 「A1」へDATAをエクセル一括設定 XLSへエクセル保存 エクセル終了 「一括設定」が遅いみたいで2列1000行で10秒くらいかかりました。 ADOも使えるのでそっちを使えばエクセル不要かもしれません。 |
|
|
|
||||||||||||
|
> 'CSV2XLS_DAO.VBS ちなみに対象とする CSV の１行目には「項目名」を含む事が前提。 含まない場合は１行目が「項目名」扱いになるので、全て「文字列」 として読み込まれる。 |
|
|
|
||||||||||||
|
前に CSV から Excel ファイルを作る VBScript 等を書いた事があるけど、 (Excel で CSV を直接開くと思いもよらぬ変換を受ける場合の対策のため) 桐ｖ２やｖ５のデータをExcelへ変換したい http://www.fuku3.com/~habata/kbbs/kakov5/17572.htm DAO を使うと次のようになるか・・・ 正規表現なども使う必要も無いため、こっちの方が早いかな！？ 'CSV2XLS_DAO.VBS '---------------------------------------------------------------- DBPath = "l:\book.xls" Set DBE = WScript.CreateObject("DAO.DBEngine.36") '97の場合は35 Set DB = DBE.Workspaces(0).OpenDatabase(DBPath, False, False, "Excel 8.0;HDR=yes;") DB.Execute "SELECT * INTO シート FROM [Text;database=l:\].[text.csv];" DB.Close Set DB = Nothing Set DBE = Nothing '---------------------------------------------------------------- |
|
|
Copyright (C) 2000 CGI Arkadia All rights reserved. Script written by Shintaro Wakayama. BBS-TypeN Ver.2 Preview4 remodel advice by hidetake |