Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

[delphi 7] hexedytor głownie procedura zapisu hexu

studencik22 23 Kwi 2009 11:00 2322 14
  • #1 23 Kwi 2009 11:00
    studencik22
    Poziom 12  

    Hej
    Szukałem i nie znalazłem tego czego potrzebuje.
    Chce stworzyć coś co otwiera plik i odczytuje go hexowo - takie procedury znalazłem, ale nie wiem jak zapisać to z powrotem do pliku. Czyli np jak otworze plik mp3 i tam coś zmienie to chce to potem znowu zapisać, żeby to nadal był plik mp3.

    Dodam, że tak faktycznie chce zrobić coś, co będzie np kodowało dany plik... ale w tym celu muszę poznać wymienione procedury - w tym tą zapisu.
    Czy samo hextobin wystarczy? jak to zastosowac?
    Pozdro

    0 14
  • #2 23 Kwi 2009 18:09
    Dżyszla
    Poziom 42  

    Sposób szesnastkowy służy wyłącznie rodzajowi prezentacji danych. Nie jest to żaden inny zapis, niż ten znajdujący się na dysku - to po prostu tablica bajtów (w najprostszym przypadku).

    BTW - ot tak sobie MP3 nie wyedytujesz ze względu na istniejącą tam kompresję.

    0
  • #4 27 Kwi 2009 12:12
    studencik22
    Poziom 12  

    Dzieki za odzew
    No to może być plik jpg, albo dowolny inny exe lub txt.
    Chodzi o to, by otworzyć plik, przedstawic jako hex jak w hex edytorze a potem zapisac - nie mam procedury zapisu :( a jej wlasnie szukam, albo bym stworzyl, ale nie wiem jak, bo zapisanie z memo na razie daje mi zapis ale szestnastkowy do pliku...

    czyli "a" odczytana jest jako 61h i zapisauje mi sie do pliku "61" a chce żeby się zapisalo "a". Jak to zrobić? Powinno to byc banalne.

    To jest w postaci pliku txt.
    A co zrobić gdy chce np modyfikować plik exe?
    Czyli wczytuje i mam wartosci powiedzmy D4 FF 81 3F. Jak sprawić, żeby zmieniając D4 na DE np, żebo to się zapisało jak za pomocą HIEW np... - chce napisać własny hexedytorek zapisujacy zmiany.

    Pozdro

    0
  • #5 27 Kwi 2009 17:29
    Dżyszla
    Poziom 42  

    Powtarzam - prezentacja hex służy wyłącznie do celów PREZENTACYJNYCH. Chcą wyświetlić plik, wczytujesz go i prezentujesz w takim formacie, lecz właściwą treść trzymasz albo w tablicy bajtów, albo też sam plik trzymasz otwarty. Konwersja na hex na potrzeby zmiany by zapisać spowrotem jest procesem czasochłonnym i niepotrzebnym.

    Notabene są gotowe komponenty do wyświetlania strumieni/stringów/tablic w postaci szesnastkowej, realizujące edycję i odczyt/zapis z/do pliku.

    0
  • #6 28 Kwi 2009 13:53
    Chris_W
    Poziom 36  

    Nie wiem co chcesz osiągnąć - najstarszi szamani czejenów mają problemy ze zrozumieniem...

    Każdy bajt pliku to liczba (0...255) i teraz różne programy różnie wyświetlają te bajty. Notatnik wyświetla te liczby jako literki, hex edytor wyświetla je jako liczby szesnastkowe (podwójne cyfroliterki). Jeszcze ktoś inny może sobie przypisać każdej liczbie piktogramy, lub obrazki (właściwie to literki są piktogramami). Można każdej z liczb nadać dźwięk i też tak to wyświetlić (odtworzyć). Ale na miłość boską to dalej są w tym pliku liczby 0...255 - nieważne jak je sobie będziesz traktował i interpretował (jako literki, jako obrazki, jako dźwięki, jako godziny czy dni, jako poziom dźwięku, czy kolor piksela - mogą mieć wiele wiele innych znaczeń). To od Ciebie zależy jak traktujesz te liczby.
    Najprostrze podejście to traktować te liczby jako liczby i to te liczby edytować.

    0
  • #7 29 Kwi 2009 20:24
    BABCIA ADHD
    Poziom 10  

    Temat chyba jeszcze aktualny ;)

    Tak jak mówili poprzednicy w pliku zapisuje się bajty czyli liczba od 0 do 255.

    Jeśli każdej literce przypiszemy liczbę (np. tablica ASCII) np. "a" = 97 a "b"= 98. To np. taki notatnik po wczytaniu pliku *.txt odczytuje liczby nie litery ! :) Gdy napotka na 97 to wyświetla jako "a" i analogicznie...

    Ty chcesz zamiast liter wyświetlać liczby. Czyli musisz zamienić liczby na liczby szesnastkowe. Gdy wczytasz jeden bajt to masz liczbę z przedziału 0..255 i jak ci się wczyta liczba 97 to nie wypisujesz "a" tylko "61" (w hex'ie).

    To czego szukasz to strumienie. One pozwalają wczytywać bajty z pliku. Piszesz np. :

    Code:

    var
      fs: TFileStream;
    begin
      fs:=TFileStream.Create('cos.txt',fmOpenRead );  //do zapisu fmOpenWrite   
      fs.Read(x,1); 


    To pozwala wczytać z pliku bajty. Polecenie fs.Read wczytuje do zmiennej x jeden bajt odczytany. Jeśli zamiast 1 wpisałbyś 3 to wczytało by 3 kolejne bajty... Więcej o strumieniach w google albo 4programers czy gdzieś indziej.

    -Wczytujesz plik
    -Dajesz pętle
    -Wczytujesz po bajcie
    -I zapisujesz w tablicy
    -Wyświetlasz użytkownikowi odpowiednio w hexie. On edytuje, a w procedurze zapisu zamieniasz hex z powrotem na liczby dziesiętne (czyli np. FF --> 255)
    -Wczytujesz plik do zapisu
    -I zapisujesz te bajty

    Więcej jak zapisywać i odczytywać ze strumieni będzie w google i powinieneś rozwiązać problem ;)

    0
  • #8 30 Kwi 2009 07:55
    studencik22
    Poziom 12  

    Dzieki baba ADHD i reszta siopaków ;-)
    Dzisiaj sie pobawie tymi strumieniami. Jak mi sie uda, to kliknę pomógł :).
    Ja chce stworzyć właśnie hexedytor... ale nie taki zwykły tylko z możliwością kodowania danych :). Czyli przechodzimy do hexa, kodujemy, zapisujemy pliczek...
    Kodowanie np za pomocą XOR.
    Potem otwieramy zmodyfikowany pliczek, odXORowujemy, zapisuejmy i mamy to co na poczatku.
    zaraz się pobawie...
    Tylko czy ta tablica nie bedzie za długa??
    Dzieki i pozdro

    0
  • #9 30 Kwi 2009 09:36
    elektryk
    Poziom 42  

    BABCIA ADHD napisał:
    To czego szukasz to strumienie. One pozwalają wczytywać bajty z pliku. Piszesz np. :
    Code:

    var
      fs: TFileStream;
    begin
      fs:=TFileStream.Create('cos.txt',fmOpenRead );  //do zapisu fmOpenWrite   
      fs.Read(x,1); 
    To już bez strumieni nie da się tego zrobić? To dość dziwne bo zawsze przy normalnym otwieraniu przez uchwyt u mnie działały odczyty nawet 1 bajtowe. Poza tym odczyt pliku po 1B na raz przy rozmiarze kilka MB będzie trwał kilkaminut, natomiast odczyt blokowy ułamki sekund.

    0
  • #10 30 Kwi 2009 09:42
    Chris_W
    Poziom 36  

    Zakładam że pliki będą małe - choćby z racji potrzeby ręcznego edytowania ich (jak tu szukać wsród milionów tej jedynej ...)

    0
  • #12 30 Kwi 2009 11:48
    elektryk
    Poziom 42  

    Chris_W napisał:
    Zakładam że pliki będą małe - choćby z racji potrzeby ręcznego edytowania ich (jak tu szukać wsród milionów tej jedynej ...)
    Błędne założenie, choćby przypadkiem wybierzesz plik o dużym rozmiarze i będziesz musiał czekać kilka minut na to żeby się wczytał (w tym czasie program będzie prawdopodobnie zablokowany). Poza tym małe zmiany w plikach można robić nawet w plikach dużych objętościowo.

    0
  • #13 30 Kwi 2009 13:27
    Chris_W
    Poziom 36  

    Założenie jest poprawne tylko nieprzewiduje wszystkich okoliczności. A żeby wyszukiwać pojedyńcze bajty z tych milionów to trzeba operować adresami a te adresy trzeba wcześniej znać - a ich poznać nie można, nie znając wcześniej pliku itd.
    Może autor ma jakieś 'plany' automatyzacji - ale z tego co pisał to wynika że ręcznie będzie zmieniał określone bajty w dowolnych plikach - trochę to mi przypomina tą igłę w stogu siana...
    A to że plik - z filmem na przykład - będzie mu się wczytywał godzinę to jest brak przewidzenia wszystkich skutków takiego programowania/oprogramowania.

    0
  • #14 30 Kwi 2009 13:39
    Jarosx9
    Poziom 35  

    Ależ nikt normalny nie wczytuje całego pliku (zwłaszcza > 50 MB) do edycji hex, niech sobie czytuje bezpośrednio do bufora jakiś kawałeczek, dajmy na to 1 kB i go edytuje i zapisuje po edycji w tym samym miejscu.
    Albo można zrobić coś takiego jak np. tablica dwuwymiarowa zmian (podpatrzone) i tam zapisać zmienione wartości (adres, nowa wartość bajtu) i niech ta tablica ma 100 kB, bo ręcznie w życiu tego nie zapisze. Po edycji program się może zapytać czy zapisać zmiany i aktualizuje plik.

    A jak będziemy wczytywali całe pliki do pamięci to się może okazać że RAID0 i Core 2 Quad się nie wyrabia.

    0
  • #15 30 Kwi 2009 17:15
    BABCIA ADHD
    Poziom 10  

    Ja ze strumieniami dałem tylko przykład. Strumienie to klasa napisana dla ułatwienia rzeczy programistą. Są inne sposoby i zwykle każdy problem można rozwiązać kilkoma sposobobami.

    Tylko trzeba brać siły na zamiary. Jeśli autor poradzi sobie z takim wczytywaniem, jak wspomniane (bardzo trafne) wczytywanie na segmenty to i lepiej. Tylko nie zawsze trzeba odkrywać koło od nowa. Ja osobiście napisałem pewną klasę (do zapisu kilku zdjęć w jednym pliku) z użyciem strumieni i pliki ~5mb wczytywał od razu, bez widocznych problemów. A autor mówi o plikach exe czy res lub podobnych, które rzadko są większe niż 10 mb. Jeśli zależy na uniwersalności programu to oczywiście można zrobić to inaczej, szybszą (w wykonywaniu) metodą.

    Wybór techniki programowania zależy od postawionych celów. Jeśli programujemy "dla ogółu" to nikt nie napisze takiego program w konsoli (tj. np w turbo pascalu). Strumienie nie są najprostszym i najszybszym sposobem, ale chyba jednym z wygodniejszych.
    Myślą w ten sposób to powinniśmy zacząć od tego, że program trzeba napisać w assemblerze - będzie chodził jeszcze szybciej. Tylko po co ?

    0