anybody now of a fuckin tool like a HexEditor type of thing that

>>58596978
The fuck are you even asking? A hex editor literally displays the contents of the file as they are, byte-per-byte, output in the form of hexadecimal numbers (hex is more convenient, since FF = 255, meaning that all possible values of a byte fit within the range of 00-FF, and there's not a single 2-digit hex number that doesn't correspond to an appropriate byte value). Do you want to see the data in decimal form, perhaps? As in, see 250 instead of FA? Do you want to see the E-ASCII character that corresponds to the byte value? What on earth do you exactly want?

>>58597027
>A hex editor literally displays the contents of the file as they are, byte-per-byte, output in the form of hexadecimal numbers
this is exactly what i wrote

>Do you want to see the data in decimal form, perhaps?
no, i want the byte view. or ASCII for that matter.

what i want is simple:
imagine you write a program that reads in files. filestreams are usually stored in byte arrays. so the hex format gets automatically "transformed" into byte (or ASCII the hell do i know. the 0xFF type of notation disappears anyway).

what i want to see

cat file | hexdump -C

>>58597067
what the fuck are you saying

>>58597067
So, you want to convert a file to a binary array? xxd can do that for you:
>xxd -i filename
Outputs:
unsigned char file[] = {
0x61, 0x62, 0x63, 0x0a
};
unsigned int file_len = 4;

Try hexer, it's a terminal-based hex editor with an interface similar to vi. You can see the bytes as two hex digits, and the ASCII representation over on the side, in a layout similar to hexdump -C. I think ghex is a GNOME equivalent if you prefer graphical editors.

>>58597067
>>58597098
oops sorry i ended abruptly


okay, here's the thing. i MIGHT be bit confused with all these representations.

so if you open a file in a hex editor, you get its hexadecimal representation.
now, if you write a program in C, C#, C++, Java you name it, you can use "FileStream" to read in a file. you will need a byte[] to store the file in. if you log this array to the console, you will see the non-hex representation of the file.

i don't actually know what the last representation is. ASCII?

i just want to have an editor/viewer that can show me the hex-representation along with the ASCII representation.

Stop saying hex and byte if you don't know what they mean. Hexadecimal is a base, byte is 8 bits. Explain what you want properly.

FF / 255 / 11111111?

Using hexadecimal is the standard because after a short acclimation period it's easier to use for patterns. FF for 8 1s, AA for alternating 1s/0s, FA for four 1s then 1010

>>58597166
>You can see the bytes as two hex digits, and the ASCII representation over on the side,
almost every hex editor does that,
but i don't want the actual ASCII character, but the numerical value...

hex 64 61 74 61 becomes
ascii 100 97 116 97 becomes
ascii D A T A

i want the numerical ascii representation.

just as if you'd print out said byte array when you read in a file with FileStream when programming.

there has got to be an editor /viewer that does that already.

>>58597179
I'm still confused. Could you provide me an example of the representation you want to see? That would help.

>>58597251
AH. So you are looking for the *decimal* representation of the file. Unfortunately, I don't actually know a hex editor that does that, but now that this is clarified maybe someone could help. Alternatively, you could dump the array in hex format from your programming language instead, since that would be more useful:

for(size_t i = 0; i < array_len; i++) printf("%02x ", array[i]);

>>58596978
that's literally what a hexeditor does

hexidecimal is used because it's the most convinient, generic representation of bytes

most hex editors have a parallel view in ASCII or another print format alongside the hex view

for example (hexdump -C)

000343d0  cd b5 84 af 2b ca 0d f5  75 9a 63 64 a4 f2 50 ed  |....+...u.cd..P.|
000343e0  b1 13 26 c8 b2 44 be ad  fd fe fb f4 34 9a b6 49  |..&..D......4..I|
000343f0  93 7f 3b b8 d7 95 ba 62  a5 ac b1 87 50 e7 d1 9c  |..;....b....P...|
00034400  27 32 b1 12 45 78 fc 24  56 6b d7 ae 9d 35 6b 56  |'2..Ex.$Vk...5kV|
00034410  7a 7a ba 91 5b 78 7c d0  6a a1 36 a2 47 3b 73 e6  |zz..[x|.j.6.G;s.|
00034420  cc 19 35 6a 14 7d a6 96  fa f4 d3 4f af b9 e6 1a  |..5j.}.....O....|

first column is the offset, middle ones are the bytes (in hex), last is the bytes interpreted as ASCII text

>>58597359
yes, i know all this, i'm only trying to find a non-text ascii representation.

>>58597351
thanks for the patience and bearing with me and the help.

the problem i am facing is that i am trying to find the "DATA" block in files of a certain type.
most of the times, this works fine if i just read in 4 bytes of the file and check those like this (half-pseudo code):

bool b_found = false;
byte[] b = new byte[4];
... // init filestream etc.
if (b[0] == 100 && b[1] == 97 && b[2] == 116 && b[3] == 97) b_found = true;

sometimes though, even if a data block is declared and clearly visible in a hex editor, that above if-condition doesn't find it.
hence why i want the numerical ascii representation to see what's actually going on.
(i assume it must be some encoding thing, maybe each character separated by zeros...?)

i know i can do this in numerous other ways, i was just wondering why there is no editor/viewer that can actually show both representations.

>>58597444
>i'm only trying to find a non-text ascii representation.
like... hexidecimal, perhaps?

>>58597444
You can just search for hex numbers if you're doing it this way:

if(b[0] == 0x64 && b[1] == 0x61 && b[2] == 0x74 && b[3] == 0x61) b_found = true;

This should work in basically any modern programming language.

>>58597463
>hexidecimal, perhaps?
... please read the rest of my post.

>>58597478
in most cases you can specify hexidecimal by prefixing with 0x, like "0xFF" is hexidecimal "FF" (255)

File: Screenshot (2).png (323KB, 1920x1080px) Image search: [Google]

323KB, 1920x1080px

>>58596978
I found something you may want! The XVI32 hex editor has a "Data inspector" window, which allows you to show the data in various different formats. This includes a "byte" format, which is pretty much just the decimal number.

>>58597476
>>58597497
technically this works, yes, and i could switch this out with the ascii number lookup.

i know this wasn't stated in OP, but sometimes it doesn't find anything, even though "data" is clearly visible in a hex editor. i assume a different encoding, so i might have to look for more than just 0x64, 0x61, 0x74, 0x61...

and that is why i wanted the "raw" ascii numbers representation to see what's actually going on

>>58597521
interesting, i'm checking this out now. thanks!!

File: Screenshot (3).png (132KB, 1920x1080px) Image search: [Google]

132KB, 1920x1080px

>>58597560
MiTeC's hex editor seems to have a similar feature but with a better UI. Can't really seem to find anything else that'd be a free program, unfortunately. But hope at least one of these two can be useful.

File: wave-data.png (9KB, 694x135px) Image search: [Google]

9KB, 694x135px

>>58597521
neat, it works good. it shows the decimal representation. thumbs up! (unfortunately it doesn't highlight the respective hex values when you select several the ascii values)

i have this problem now. pic related.
it's a wave file with a clearly visible "data" part in the hexview, yet, when looking for these numbers with that if-condition stated further above, it doesn't find it!

>>58597653
Condition itself looks fine. Problem must be elsewhere in your code.

>>58597690
it works just fine with other wave files.
the file isn't corrupt either, it plays fine.
the "data" part is also not oddly offset or something, it's a part where i can fully read it into a 4-byte array incrementing from the beginning of the file.

either weird encoding, or something else is off...

>>58597714
Encoding is irrelevant when you're looking at binary data. It doesn't change. Encoding is relevant when working with text as if it was text, since the same character can be encoded differently depending on the encoding. Since the hex editor looks past the encodings and on the actual byte values, that's no longer relevant. Therefore,
> something else is off
but I can't tell you what.

File: fileread.png (18KB, 591x424px) Image search: [Google]

18KB, 591x424px

>>58597785
this is the crucial part.
fs.position might seem weird, but i needed to find a way to progress in the file as i read it.
and, it works fine with all wave files except this particular one.

>>58597935
>>58597935
turns out the adding to fs.position is unnecessary. fs.read does proceed in the file when reading within a loop. not sure why i decided to manually progress in the file.

i was just lucky so far with 99,9% of all wave files that this manual progress wouldn't skip the data part.

jesus christ.. fucking bugs. thanks for all your help.

>>58596978
its part of the SUS:
man 1 od

>>58598127
this is good to know for linux users. thanks.

personally i am windows though. problem has been solved - go with MiTeC hex editor on windows. it's the best

There are more characters used in programming than there are values to be referred to with a byte barring using it like a structure or an object thing, like you know totally.

So basically your file would be full squares and hashes and てみてみ.

What you might benefit from is maybe collecting words, meaningful words, and applying them to those numbers so that you can read out the code in hex to yourself with just the value. Not for like numerlogical reasons but bc you want easy to recall and process words with meanings you can care for yourself.

The reading process will ultimately be longer but this is kind of exactly how you will take on the debugging and still be able to treat it less technically, create plot, use a rhyming system or scheme. Or not.

I thought it was a good idea.

>>58598283
i think they call them primes in math. What im referring to. I guess. Maybe?

>>58597179
Oh that's easy

cat file

File: op.png (42KB, 760x501px) Image search: [Google]

42KB, 760x501px

>>58596978

>>58596978
translating in your head isnt that hard

>>58596978
>there are negros that don't use the 010 Editor
>b-but anon you have to pay for it!
If you can't even crack some extremely simple copy protection mechanism you don't belong on this board.

>>58599653
>>58599961
stop assuming you mongrels
read the thread, it's been solved hours ago

File: nonsense.jpg (127KB, 800x800px) Image search: [Google]

127KB, 800x800px

>>58596978