ファイルのチェックサムを改行コードを除き取得したい。

Windowsマシンから unix マシンへ巨大なテキストファイルを ftp をした後、両者の内容が同じである事を確認したいと思っています。
ただし「同じ」といっても Windowsは改行コードが CrLfで unixの改行コードは Lfなのでただ、それぞれのファイル全体のチェックサムを「同じ結果か出るツール」を使っても相違が出てしまいます。
なので「改行コード部分を除いた」実テキスト内容についてのチェックサムを、出力できるツールまたは c言語のソースプログラムを探しています。
そうすれば Windows側 と unix側のチェックサムは一致するはずです。
ファイルが巨大なのでいったん改行を除くなどのフィルターを通すと、数時間の処理時間がかかってしまうので、一回の読み込みでチェックサムを出力したいです。
c言語で自作も考えていますが、ゼロから考えると大変なのでサンプルプログラムでも良いので教えてください。
(セキュリティ上、実行環境がネットから遮断されているので、手で打ち込める短めのソースが良いです)

No.5 ベストアンサー 回答者： kmee 回答日時： 2016/12/14 20:41

md5sumとか

https://en.wikipedia.org/wiki/Md5sum
sha1sumとか
https://ja.wikipedia.org/wiki/Sha1sum
がUnix側にあれば、Windowsに用意して、
・Windowsでtextモードでハッシュを計算→Unix上で確認
という使い方でいいはずです。


あとは、運用次第なんですが

Unixでは、パイプで継ぐと、ほぼ並列に実行される上、中間ファイルを経由しないので、
「あらかじめCRLF→LFに変換したファイルを読み込み処理」
するとの
「CRLFのファイルをLFに変換して標準出力 | 標準入力から読み込み処理」
するのとで、致命的なパフォーマンス低下は無いはずです。


200GB一気に保存しないとならないのでしょうか?
適当な長さで分割して保存すれば、もう少しいろいろ楽ができると思うのですが。

この回答へのお礼

ご回答ありがとうございます。
弊社では 200GB以上のファイルを毎月2000回、全件検索処理をしています。
いわゆるビッグデータの処理ですが単なる傾向分析ではなく、正確な数値が求められています。
(なので標本化、少ないデータで(サンプリング処理)が出来ない)
何のために正確さが必要かと言われると「あまり意味がない」と私個人は思っていますが、会社の方針なので仕方ありません。

過去に再処理データの取違い (間違って古いデータを使ってしまった) があり、責任問題となった事があり 200GBのファイルを分割もしくは正規化する案は、私もアイデアとしては持っていますが、危険を感じるのでやりたくないところです。

パイプ利用のアイデアは実験をしてみたいと思います。
パフォーマンステストを、これからテストマシンで行う予定です。
ただ、将来は unixマシンを Windows化するアイデアもあり、効果があっても実装するかどうかはわかりません。
(Windowsは実質、マルチプロセスにならない ?)

余談ですが 3年後には、合計20テラバイトのSSDディスクシステムを買ってもらおうと、提案していますがまだまだ高いので却下されそうです。

お礼日時：2016/12/15 08:23

No.4 回答者： Wr5 回答日時： 2016/12/14 16:52

>ファイルサイズが 数百GB 単位なので、変換処理だけでも小一時間かかってしまいます。

コレでちゃんと動作するかは不明ですけど……。


>c言語で自作も考えていますが、ゼロから考えると大変なのでサンプルプログラムでも良いので教えてください。
>(セキュリティ上、実行環境がネットから遮断されているので、手で打ち込める短めのソースが良いです)

手打ちもチト厳しいところですが…
https://www.ipa.go.jp/security/rfc/RFC1321JA.html
辺りでMD5チェックサムのサンプルが入手できます。

で、MD5Init()で初期化しておいてfopen()でテキストモードでオープンし、
fgets()で1行読み込んではMD5Update()で1行分のデータをハッシュに通して、
全行読み込み終わったらMD5Final()でダイジェストを取得する。

というのでどうですかね？
Windows側もfopen()のテキストモードであれば、改行は'\n'に変換されることになるかと。

数百GBのファイルをfopen()で開けるか？という問題は残りますけど。

この回答へのお礼

回答ありがとうございます。
全部を打ち込むのは大変ですが、教えて頂いたサンプルを応用すれば何とかなりそうです。
c言語はできますので大丈夫です。
数百GBのファイルを、fopen()で開く事ができました。

お礼日時：2016/12/15 10:54

No.3 回答者： yambejp 回答日時： 2016/12/14 16:49

＞ftpで転送時に改行コードを変換しながら、後でチェックサムをとるときに違いを吸収するのが最短

本当にそうでしょうか？実測しましたか？
転送時に変換がかかるということは転送時にオーバーヘッドは発生しています
論理的には、変化して転送も、転送しながら変換も、変換後転送もほぼおなじ時間に
なるはずでは？

この回答へのお礼

回答ありがとうございます。
実測するとディスク I/Oに時間がかかっているようです。
なので JOB ステップを分けると、時間が倍かかります。
しかし他の方の回答で「パイプ処理なら時間が増えないかも」とのご指摘がありましたので試してみる予定です。

お礼日時：2016/12/15 10:50

No.2 回答者： yambejp 回答日時： 2016/12/14 15:58

ftpで転送時に改行コードを変換しているならやめて、

windows側で変換して転送するかunix側で転送されてきたデータを変換するかの
どちらかで対応すればよいのでは?

この回答へのお礼

ご回答ありがとうございます。
ファイルサイズが 数百GB 単位なので、変換処理だけでも小一時間かかってしまいます。
ファイル数もたくさんあります。
なので、ftpで転送時に改行コードを変換しながら、後でチェックサムをとるときに違いを吸収するのが最短の処理時間になるのです。

お礼日時：2016/12/14 16:19

No.1 回答者： 銀鱗 回答日時： 2016/12/14 13:18

＞Windowsマシンから unix マシンへ巨大なテキストファイルを ftp をした後、

これが逆なら、Internet Explorerでできるんだけどなあ。

UNIX/Linuxの２バイト文字を含んだテキストファイルを変換するときによく使う技なんですけど…。

Windowsパソコンの上で、ファイルの拡張子を「.TXT」から「.TXT0」のようにIEがテキストファイルと認識できないものに変えたのちに
開いているIEのウインドウへ「.TXT0」ファイルをドロップすると、IEの中で普通にファイルが開かれます。（←これ、意外と知られていなかったりするんです）
続いてIEで「ファイル名を付けて保存」し直すんです。TEXTファイルとして。
その時、エンコードをShift JISとすればJISコードはShift JISコードに置き換わり、改行コードはLfからCr+Lfに置き換わります。

これでWindowsのメモ帳などで文字化けを起こしていたテキストファイルをこれで文字化けさせることなく表示ができるようになる。

…と言う事なんですが、
これを逆にエンコードをJISにして保存し直しても改行コードまでは変わらなかったと思うんですよ。たしか...。

・・・
そんなわけで、UNIXのファイルを一度Windowsへ移して、IEでShift JISで保存し直した後のファイルでUNIXシステム上で比較するという
面倒なことになりますね。

このやり方なら別途プログラムを用意することなく実施できるので、多少の手間を問わないならお勧めできます。


・・・余談・・・
このやり方、実は結構古くて知っている人は知っているんです。
（自分はUNIX系システムをいじっていた2000年頃、IE5とIE6でこのやり方を確認しています）
IE11にも同じオプションがあるので機能は変わらないと思います。
ただ、エンコードをJISにしたときに改行コードがLfになるかは分かりません。

この回答へのお礼

ご回答ありがとうごさいます。
残念ながら仕事場のサーバーWindows機はセキュリティが厳しくて IE を起動できません。
しかし、ご回答は自宅での趣味の別の操作で役に立ちそうです。
ありがとうございました。

お礼日時：2016/12/14 13:41