喫茶XRAYトップページ

[スレッド全体
]

[2911] Re:追加のテスト。返信 削除
2010/1/6 (水) 14:28:28 Null
「886_ChangeMojiCode-04」で
追加の判定テストを実施しましたので、話のネタに報告します。

何れのファイルも「固定長のCSV」ファイルです。
文字括(")なし、 分離符(,)
テストしたファイルの本数            =  24本

結果
(A群)  正常に「932」を返した本数                   = 10本
(B群)  「0」を返した本数                           = 9本
(C群)  文字コード'20127'(US-ASCII)を返した本数   = 5本
(D群)  (B群)のスペース(空白部)を削除して、「可変長」にしたら「932」を返した本数  = 2本

ファイルの傾向(構成)
(A群)  比較的(半角英数字)が多いが、カナ・漢字・倍角英数字でそれなりに構成されている。
        「空白部」も比較的少ない。
        レコード長は、150〜300文字(半角換算)程度

(B群)  全体の80%以上の割合で(半角英数)で構成。  半角英字が偶に存在する。
        レコード長は、150〜300文字(半角換算)程度
 
(C群)  全体の90%以上の割合で(半角英数)で構成。  半角英字が偶に存在する。
        比較的、「空白部」が多い事もある。
        レコード長は、短め50〜100文字(半角換算)程度

(D群)  (A群)と類似する。

(D群)以外のファイルもスペース(空白部)を削除して、「可変長」でテストをしたが結果は変わらす。

備考」
「886_ChangeMojiCode-02」の変換では、全ての固定長ファイルで希望の作業が可能でした。

失礼しました。


[2912] Re2:何故、CSVに拘るのか?。 余談ですが。返信 削除
2010/1/6 (水) 19:34:51 Null
話が前後しましたが、小生がCSVファイルでテストをした理由をご説明します。

それは、言うまでもなく、他言語や外部とのデータの受け渡しに一番(私なりに)適した
ファイル形式だからです。

私の勤務する会社では、顧客のサーバーへアクセスして、各種重要データをDLする
仕組みに成って居ります。 其のファイル形式が「CSV」形式です。

仮に、自社の基幹システムをUnicode対応に切替えた場合DLしたCSVファイルを
何処かで一度UNICODEへ変換する必要が有ります。
今回は、そのための事前テストを目的に実施しました。

両者が同時期・同時にUnicodeへ移行出来れば問題ないのですが。...

従いまして、マスターが公開されているサンプルプログラムに「けち」を付けたり
貶める為に行った訳では有りません。  勘違いの無きようお願いいたします。

そのような方は、此所にはいらっしゃらないと思いますが。
何のためです。


[2916] Re3:何故、CSVに拘るのか?。 余談ですが。返信 削除
2010/1/7 (木) 00:09:09 Mr.XRAY
▼ Nullさん

> 話が前後しましたが、小生がCSVファイルでテストをした理由をご説明します。

ありがとうございます.
こういう話は参考になります.
確かに,Unicode化の際のデータ移行には確実かも知れませんね.

Delphi2010でしたら,コード変換の関数等も用意されているようです.
Unicode化は大変でしょうけど,業務アプリの開発者は,
いつかは通らなければならない道ではないでしょうか.


[2915] Re2:追加のテスト。返信 削除
2010/1/6 (水) 23:58:11 Mr.XRAY
▼ Nullさん〜,

すごいですね.
これを見る限り,あまり成績よくないですね.
小生がテストしたのは,残念ながら添付のテキストファイルのみです.

スペースは関係なさそうですね.
う〜む.

>備考」
>「886_ChangeMojiCode-02」の変換では、全ての固定長ファイルで希望の作業が可能でした。


なんか謎めいていますね.
同じMLang.dddを使用しているのに.
ConvertFunction関数は,内部でなんか別の処理なんでしょか.


[▼次のスレッド]
INCM/CMT
Cyclamen v3.82