binary로 검색하니 FileStream.Read(buff,Length(buff)); 을 사용하라기에
해보려고 했는데 제가 취급하려는파일이 다른 프로그램에서 생긴 파일이라 구조를
몰라서 buff size를 얼마로 해야할지 어떤식으로 끊어읽어야 할 지 막막합니다.
원본파일은 확장자가 *.DAQ이고 프로그램에서 일부분씩 텍스트로 저장하는기능이
있어서 그걸로 저장해서 보니 다음과 같습니다.
Copyright 2003,MapsiSoft Inc.
DaqFile T20070330-172532.daq
Time 2007-03-30 17:25:32
Rate 100
Channels 6
Time 풍속 풍향 W X Y Z
0.00000000000000E+0000 7.31809437274933E-0002 3.34449243545532E+0000 2.49369502067566E+0000 -2.89358079433441E-0001 -1.48968994617462E-0001 -2.28768512606621E-0002
1.00000000000000E-0002 7.25277513265610E-0002 3.34579420089722E+0000 2.49397444725037E+0000 -2.90094763040543E-0001 -1.48642972111702E-0001 -2.26718969643116E-0002
2.00000000000000E-0002 7.22541958093643E-0002 3.35097289085388E+0000 2.49403643608093E+0000 -2.89789587259293E-0001 -1.48616150021553E-0001 -2.23638694733381E-0002
3.00000000000000E-0002 7.22535997629166E-0002 3.34230685234070E+0000 2.49400019645691E+0000 -2.89925485849380E-0001 -1.48387864232063E-0001 -2.22500730305910E-0002
4.00000000000000E-0002 7.22232013940811E-0002 3.35190916061401E+0000 2.49401688575745E+0000 -2.89591699838638E-0001 -1.47991508245468E-0001 -2.23400387912989E-0002
5.00000000000000E-0002 7.21653923392296E-0002 3.34504318237305E+0000 2.49403166770935E+0000 -2.89768725633621E-0001 -1.47639259696007E-0001 -2.19730269163847E-0002
6.00000000000000E-0002 7.17601254582405E-0002 3.34587097167969E+0000 2.49405980110168E+0000 -2.90063768625259E-0001 -1.47195816040039E-0001 -2.22619883716106E-0002
7.00000000000000E-0002 7.15670287609100E-0002 3.35098481178284E+0000 2.49404311180115E+0000 -2.90132910013199E-0001 -1.47033095359802E-0001 -2.25616749376059E-0002
8.00000000000000E-0002 7.15598762035370E-0002 3.34253501892090E+0000 2.49401450157166E+0000 -2.89427816867828E-0001 -1.47446140646935E-0001 -2.21327003091574E-0002
9.00000000000000E-0002 7.15503394603729E-0002 3.35165476799011E+0000 2.49402403831482E+0000 -2.89594680070877E-0001 -1.47927731275558E-0001 -2.20921859145164E-0002
1.00000000000000E-0001 7.14931264519691E-0002 3.34447813034058E+0000 2.49407887458801E+0000 -2.89926081895828E-0001 -1.48175686597824E-0001 -2.20594163984060E-0002
근데 원본을 한 문자씩 읽어봐도 어떤식으로 끊어야 이런 텍스트 파일을 얻을 수 있는지 통 모르겟습니다.
질문이 좀 애메하죠? 감을 못 잡아서...
아뭏튼 아시는 분 도움 좀 주세요.
새로운 일 할 때마다 모르는거 투성이네요.
스트림저장되었을거니까 정확한 구조파악에 약간 시간이 걸리겠네요.
참고 자료는 6개 채널로 rate 100(?) 으로 획득된 자료 같습니다.
버퍼사이즈는 구조와는 관계없구 레코드 사이즈가 자료 획득 기준이겠죠.
데이타 파일 구조가 보통 헤드부(head_length)와 실제 자료가 저장되는 몸통부가 있을 겁니다.
하나의 데이타 파일로는 구조 파악이 힘들고 두개이상이 있어야 저장조건을 찾을 수 있습니다.
같은 6개의 체널과 rate 100으로 획득되었으나 전체 자료갯수가 틀린 다른 파일이 있으면
간단한 이차방정식으로 헤드부의 크기와 몸통부의 레코드 길이를 파악할 수 있읍니다.
이런식으로 바이너리파일의 구조를 파악하였어도 다 성공하는 것은 아닙니다.
데이타 파일을 만들어낸 프로그램이 특이한 구조의 데이타 형식을 사용했다면 컨버팅이 힘들어지죠.
컴파일러 따라서 실수 저장형식이 틀려질 수 있기 때문입니다.
간단히 예를 들어보겠습니다.
1번파일 : 파일크기 11K 레코드 20개
2번파일 : 파일크기 12K 레코드 22개
라면
이 형식의 데이타 파일에는 파일헤드는 1K, 레코드 2개당 1K라는 구조가 파악되겠죠.
그러면 파일 컨버팅에서는 처음 1K 는 넘어가시고 그 다음부터 읽어들여서 변환시키면 됩니다.
레코드당 길이가 512바이트로 예상되니까 데이타 형식을 고려하여 적절히 레코드의 필드를 예측합니다.
일반적으로 정수형식은 2, 4바이트, 불린형식은 1바이트, 바이트는 물론 1바이트,
실수형식은 4,6,8,... 등입니다. 문자형은 대충 2의 배수로 하지만...
레코드 구분자가 혹시 있다면 바이너리 뷰어로 레코드 길이를 확인할 수도 있습니다.
실수형식은 저장방식이 컴파일러에 따라서 틀릴 수 있습니다. 실수저장방식은 기저가 사용되어서
실제로 기저를 16으로 하는지 아니면 다른 수를 사용한 것인지 또 지수부와 수치부(?)의 비트수를
어떻게 할당하였는지에 따라서 서로 틀려서... 이게 복잡은 하죠.
즉 쉽게 말하면 컨버팅 안될수도 있다는 겁니다.
근데 일반적인 컴파일로로 일반적으로 사용되는 실수형 구조를 사용하였다면 컨버팅되겠죠.
자료 컨버팅에 고생이 많으신데 성공하십시요.
자료구조 찾아내는 것도 필요한 작업이죠...