Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla 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

23 Kwi 2009 11:00 2403 14
  • 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
    Darmowe szkolenie: Ethernet w przemyśle dziś i jutro. Zarejestruj się za darmo.
  • 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ę.
  • Użytkownik usunął konto  
  • 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
  • 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.

  • Poziom 37  
    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ć.
  • 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 ;)
  • 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
  • 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.

  • Poziom 37  
    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 ...)
  • 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.

  • Poziom 37  
    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.
  • 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.
  • 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 ?