[[20130730084752]]　『バイナリ形式の内部コードSHIFTJISファイルの件』（フェンダー）　ページの最後に飛ぶ

『バイナリ形式の内部コードSHIFTJISファイルの件』（フェンダー）

 お世話になります。

 現在　
 以下の仕様でバイナリ入出力作業を行っております。

 ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
 レコード形式　固定長または可変長

 内部コード 　1byte文字EBCDIK
　 　　　　　 2byte文字KEIS

 ファイル形式　シングルファイルシングルボリューム

 レコード種別　F/FB(固定長）　V/VB（可変長）

 ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

 今後
 以下の仕様になります。

 ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊
 レコード形式　固定長または可変長

 内部コード 　1byte文字SHIFT_JISコード
 　　　　　　 2byte文字SHIFT_JISコード

 ファイル形式　シングルファイルシングルボリューム

 レコード種別　Windows形式ファイル（レコード種別なし）
 ＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

 他にも細かい参考資料は
 ありますが
 大きく違うとこは上記あたりですので
 記載させていただきました。

 ここからが質問なのですが
 今後
 以下の仕様になります。の仕様から
 どういったデータなのか
 知見ある方いらっしゃいますか？
 参考仕様だけで、実際のテストデータがないですし
 質問もまだ出来ない状態なので
 分かれば、先にシステムを導入の検討が出来るかなと
 いった感じです。
 例えば、
 こちらの仕様だけの前提で話すと固定長のテキストファイルになりますとか。
 推測でもかまいません。
 情報がありましたらお知らせください。
 どうぞよろしく願い致します。

（フェンダー）

 上記では文字コードが SJIS の Windows ファイルということしか分からないと思います。
 （シングルファイルシングルボリューム はデータ処理上あまり関係ないので。）

 レコード形式は別途（都度？）定義されるでしょうから、それをどうするかが決まってから
 のお話でしょうか。
 (Mook)

・input
Extended Binary Coded Decimal Interchange Code、つまりEBCDICコードが普通。
EBCDIKと書くのは日立のみであり、コードが通常と違う。まぁ、KEISの段階で
日立固有なわけですが。
1byte2byte共、固有コードなので、windows等が持つ変換テーブルの類は一切無し。
1byteずつ独自変換テーブルで置き換えるしかなく、面倒。

・output
1byte文字SHIFT_JISコードは有り得ない（必ず2byte）。Asciiコードの間違いか？
それにしても、本当にSHIFT_JIS？今時のRDBならば、内部コードはUTF-8だろう。

また、in/outいずれの場合も、改行コードをどうするか明確にしておくこと。
outputはWindows形式ファイルと不明確に宣言しているから、改行はCR+LFっぽい。
SHIFT_JISのテキストファイルを作成すれば、後は新RDBのコンバート機能が使えると
いうことか。

・シングルファイルシングルボリューム
ん～？日立だからデータベースはHiRDBだ、ということか。そんなものが動く環境を、
今時のPCで構築できると思えないのですが。実機はりつきで作業か？出力したファイルを
借りられるのか？

実機が古いだけで、HiRDBはwindows版も出ている模様。
実機のHiRDBに接続するためのODBC等が存在するかどうかは、先方に聞くべし。
（ファイルで渡すから、直接DBアクセスする必要はない、と言われそう）

・システム概要
おそらく、古い実機のDBを、今風のRDBに移行したい、という案件でしょう。
便利な命令は一切無いので、コード表を元に、1文字ずつ地道に変換することに
なりそう。ExcelVBAでは遅くてたまらないと思うので、.NETでも使うべし。
(???)

 >現在　
 >以下の仕様でバイナリ入出力作業を行っております。
 というファイルの内容が

[[20111009220410]]　
[[20120603002950]]

 ↑ここで扱ったようなファイルで

 >今後
 >以下の仕様になります
 というファイルが内容としては同じでコード体系が違う（S-JISになる）　ということでしょうか？

 だとしたら、元々のソフトをWinに載せるということが考えられます。

 このような前提なら、おそらくは、S-JISのほうがフェンダーさんにとっては、デバッグが楽だと思いますよ！！

 上記スレッドにあるパック型----＞アンパック（実は文字列）型変換なんて、

 EBCDICでは、F0が文字列の「0」ですが、S-JISでは、30が文字列の「0」
 この辺りは、注意しなければなりませんが・・・・。
 他は、概ね新ファイルの方が楽だと思いますよ！！

 >レコード形式は別途（都度？）定義されるでしょうから、それをどうするかが決まってから
 >のお話でしょうか。

 この通りですね、その間にプログラミンの基礎をみっちりやられては？　いかがですか？
 一連のご質問に関わった私の感想です。

 ichinose

(Mook)さん(???)さんichinoseさん
どうもありがとうございます。

レコードレイアウトはまだないのですが
もう少し詳しく記載いたします。

レコード形式(shift_jis)

固定長
バイナリ属性を含め、任意のデータ属性を格納したレコードで
使用可能なデータ部は区切りのないファイル

可変長
バイナリ属性を含め、任意のデータ属性を格納したレコードで
使用可能なデータ部はレコード毎に４byteを付与したファイル

レコード毎４byte→先頭２バイトにLL+4　後続２バイトはオールゼロ

レコード毎に４byteを付与は以前
ichinoseさんからスキップのサンプルを
提示して頂き解決して仕事が出来てます。

＞というファイルが内容としては同じでコード体系が違う（S-JISになる）　ということでしょうか？

そうだとおもいます。

レコード種別　格納ファイルはWindows形式であり、レコード種別の概念はないそうです。

＞それにしても、本当にSHIFT_JIS？

仕様書には記載されています。

現在媒体が磁気テープなのですが
メディア化することにより
このような形式になった方が
システム管理者が
管理りしやすい
もしくはそうせざるを得ないのかと思われます。

＞この通りですね、その間にプログラミンの基礎をみっちりやられては？

情報処理の本は何冊か購入して読んではいるのですが
ビットの計算方法とか、分からなくなる時があります。

レコードレイアウトやフィールド属性がまだ
分かってないので、どんなデータなのかが気になります。

（フェンダー）

 >現在媒体が磁気テープなのですが
 MTですか？　へえ、すごいですね！！

 >ビットの計算方法とか、分からなくなる
 昔は、1バイトの内、頭3ビットと残り5ビットが全く関連性のないデータなんてことがよくありました。
 それだけ容量を節約していたわけですが、VBAでは、TRUEとFALSEという二つの値しか返さない
 Boolean型データの容量が２バイトです。

 新しいファイル形式では、Bitをイメージしなくても済むかのしれませんよ！！
 いずれにせよ、今までより、理解はしやすくなるのでは？　と想像しています。
 VBAの持つファイルＩ／Ｏは、S-JISですから・・・。

 繰り返しになりますが、扱うファイルの懸念より、
 アルゴリズムが理解できたら、それをVBA化できる勉強をされることをお勧めします。

 ichinose

日立のDBという段階で、それは一流大手企業または官庁等の重要データと推測できます。
そんな重要なデータを、ビット計算も不完全な方が扱うべきではないと思います。

インターネットなど無かった頃の独自データ、独自システムであり、市販の本など
全く役に立ちませんよ。現存する仕様書とマニュアル、自分で全て調べ、作成することが
要求されます。掲示板のレベルではありませんし、質問で解決しようとするのは
間違っています。それはお金をもらってソフト開発するプロがやってはいけない事です。

実際のデータはまだ受け取っていないのですか？ならばデータと一緒に、DBとシステムの
マニュアル一式を借りるべきでしょう。答えは全てその中にあります。
(???)

(???)さん

どうもありがとうございます。
皆さんがご存知の社名だと思いますよ。

現在、参考資料をもとに
どういったシステムを導入すればよいか
大手プリンター会社に
検証してもらっているところでございます。

現在進行形ですが
CMT→CSV＋外字→プリント処理の大きな処理は
プロに任せていますのでご安心を・・・

ビット計算に関しては勉強しなければならない部分では
ありますが
現在は100万件ほどの実績はありますし
現在のKEISの日立の情報処理は
少なくとも、稼働できていますし。

まず今回の質問内容を覚えてますでしょうか？
どういったデータなのかしか質問はしていないと思います。

それと冒頭で
参考仕様だけで、実際のテストデータがないですし

 質問もまだ出来ない状態なので
と記載いたしました。
細かい質問はしてませんし・・・

 ならばデータと一緒に、DBとシステムの 
 マニュアル一式を借りるべきでしょう。答えは全てその中にあります。

この件に関してはそうだと思います。
まずは細かい仕様が決まってからでないと
動き出せないとは思います。

（フェンダー）

 ichinoseさん
 ご連絡どうもありがとうございます。
 ＞MTですか？　へえ、すごいですね！！

 そうです。
 業者によってはMTのまま印字処理出来るシステムも
 あると思いますが、
 もともとあるシステムに合わせないといけないために
 処理方法は現在面倒な方法になってます。
 すでに慣れてますし、万が一ミスしても
 印字処理できないように設定してますが・・・

 >新しいファイル形式では、Bitをイメージしなくても済むかのしれませんよ！！

 現在は、固定長のプログラムがすでに出来上がっているので
 色々な仕様に使いまわせる感じですから
 ミスはなく安心していたのですが・・・
 しいていえば、CSVになってからの仕様が変更になることが
 多いです。

 ＞アルゴリズムが理解できたら、それをVBA化できる勉強をされることをお勧めします。

 そうですね。
 この機会に、準備できればと思ってます。
 対応出来なければ、その仕様に沿ったシステムは
 導入しますが、出来る範囲の努力はしたいと思ってます。
 またご相談させて下さい。

 （フェンダー）

コメント返信：

[ 一覧(最新更新順) ]

[[20130730084752]] 『バイナリ形式の内部コードSHIFTJISファイルの件』（フェンダー） ページの最後に飛ぶ

[[20130730084752]]　『バイナリ形式の内部コードSHIFTJISファイルの件』（フェンダー）　ページの最後に飛ぶ