喫茶XRAYトップページ

[▲前のスレッド]

[2902] 「886_ChangeMojiCode-04」について。返信 削除
2010/1/4 (月) 11:16:38 Null
マスター、皆さん 明けましておめでとうございます。
今年も宜しくお願いします。

早速ですが、一つ教えて下さい。

表記の通り、「886_ChangeMojiCode-04」で自前のテキストファイルを
テストしましたら、「0」がかえって来る物が有りました。

テキストファイルの内容 (S-jisで保存)
1 ..  固定長のCSVファイル  36KB   正常に「932」が返る。
2 ..  固定長のCSVファイル  6.3MB  ???   「0」が返る。
3 ..  (2)のサブセット版    2KB    ???   「0」が返る。
      ※ 行数とレコード長を小さくしたもの
文字括(")なし、 分離符(,)

「hogehoge.csv」を「hogehoge.txt」に変更して試験しました。

考えられる要因が有りましたら教えて下さい、宜しくお願いいたします。

「備考」
「886_ChangeMojiCode-02」の変換では希望の作業が可能でした。

 Windows Vista  Delphi2007です。

失礼します。


[2903] Re:「886_ChangeMojiCode-04」について。返信 削除
2010/1/4 (月) 12:52:20 Mr.XRAY
▼ Nullさん

もう仕事バリバリで開始ですか.お疲れ様です.

> 早速ですが、一つ教えて下さい。

Delphi2007はもう古いですね.
時代はすでにUnicodeです.他のOSはとっくの昔になっています.
こんな古いのは相手にしたくないですね(笑).

と,冗談はともかく.
ファイルサイズの問題でもなさそうですね.
う〜ん.後で調べてみます.
どなたか情報がありましたらよろしく.


[2904] Re2:「886_ChangeMojiCode-04」について。返信 削除
2010/1/4 (月) 12:56:25 Mr.XRAY
> ファイルサイズの問題でもなさそうですね.

ちょっとうろ覚えなんですが,確かこのMLangでは文字コードの判定
する際,先頭から何文字かを調べていたような気がします.
その時,失敗すると0を返すのかも知れません.
間違っている可能性大です.


[2905] Re3:「886_ChangeMojiCode-04」について。返信 削除
2010/1/4 (月) 13:12:05 Null
▼ Mr.XRAYさん  お世話になります。

> もう仕事バリバリで開始ですか.お疲れ様です.

他にする事がないので!。(くやしいです(>_<))


> Delphi2007はもう古いですね.
> 時代はすでにUnicodeです.他のOSはとっくの昔になっています.
> こんな古いのは相手にしたくないですね(笑).


エ〜ッ、そうなんですか?。
そう仰らずにお願いしますよ。


> ちょっとうろ覚えなんですが,確かこのMLangでは文字コードの判定
> する際,先頭から何文字かを調べていたような気がします.


何となくそんな雰囲気もなくもない様な。
最初に疑ったのが「これ」でしたが、範囲(限界)が分からずでした。


[2906] Re4:「886_ChangeMojiCode-04」について。返信 削除
2010/1/4 (月) 19:20:48 Mr.XRAY
現状報告です.

この関数,DetectInputCodepageはMLang.dllの関数で,
ちょっと難しそうですね.Nullさんももう見ていると思いますが,

IMultiLanguage2::DetectInputCodepageの精度
http://d.hatena.ne.jp/xcaqhbaj/20090224/1235432758

どこかの記事で失敗した時は,デフォルト(多分日本でWindows)
のS-JISのコードを返すようにしている,というのを見かけました.

IEでも時々もしコードの判定失敗(MLang.dllは,IEが使用しているdll)
することがあるので,それと同様な現象かも知れません.

引き続き調査してみます.


[2907] Re5:「886_ChangeMojiCode-04」について。返信 削除
2010/1/4 (月) 19:26:05 Mr.XRAY
http://conferences.embarcadero.com/jp/article/images/39348/b4.pdf

こんなのがありました.
この15,15,18,20頁に,このDetectInputCodepage関数のことが書いてあります.
20頁のように,候補を増やせばいいのかな?


[2908] Re6:「886_ChangeMojiCode-04」について。返信 削除
2010/1/4 (月) 21:36:59 Null
▼ Mr.XRAYさん

お手数をお掛けしております。

> この関数,DetectInputCodepageはMLang.dllの関数で,
> ちょっと難しそうですね.Nullさんももう見ていると思います


はい、難しいです。

> IEでも時々もしコードの判定失敗(MLang.dllは,IEが使用しているdll)
> することがあるので,それと同様な現象かも知れません


ページを替えた瞬間にとんでもなく文字化けする事が有りますが、
これと同じ事なのでしょうか?。


> http://conferences.embarcadero.com/jp/article/images/39348/b4.pdf
> こんなのがありました.
> この15,15,18,20頁に,このDetectInputCodepage関数のことが書いてあります.
> 20頁のように,候補を増やせばいいのかな?


じっくり解析(見るだけ?)します。

変換前のデータの文字コードが確実にいつも同じで有れば、
「886_ChangeMojiCode-02」の変換のみで充分事が足りるのですが、
つい、「欲」を出して「886_ChangeMojiCode-04」の方に手を出してしまいました。

申し訳有りません。マスターの本業に差し支えない程度にお願いします。



[2909] Re7:「886_ChangeMojiCode-04」について。返信 削除
2010/1/4 (月) 21:57:14 Null
 ▼ Mr.XRAYさん

お手数をお掛けしております。

あれこれ、テストのし過ぎで混乱してしまいました。
数種類のサンプルを混同して話をしているような?。

色々触っているうちに区別が出来なくなりました。
明日、もう一度確認をやり直します。

頭を冷やして、仕切り直しです。


[2910] Re7:「886_ChangeMojiCode-04」について。返信 削除
2010/1/4 (月) 23:16:46 Mr.XRAY
▼ Nullさん

> ページを替えた瞬間にとんでもなく文字化けする事が有りますが、
> これと同じ事なのでしょうか?。


多分そうじゃないかと...  (自信なし)

> 申し訳有りません。マスターの本業に差し支えない程度にお願いします。

了解!! ありがとうごさいます.


[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