I can convert a binary file to an ASCII base 64 representation in a way such as the following:
base64 piglet_squid.jpg > piglet_squid.txt
A small segment of the resulting file could be something like the following:
LY61c8T1LeF+GsbJ2FhEjnNW0NoXFS0qi2MEKKyPErh13jSWFU+Xp8uRxu6Cqxzcn8cfCJxrYrwj
wx9PYNy+ZvXfUzHmsH7XKNBaTULLsXAHtXqbmtSze8knfeHKL0+a8R9qn13iniFuwilbK8x9K+9d
PMUXGvsxxX2sufZnxO9rrTK5221Bk9jWppTa8T8R3Ok6e3/hjox715M+KabSrb8M0jejC3bg6/Fe
How could I convert that same file to a base 2 representation? A small segment of the resulting file could be something like the following:
0101000111001011101010001010010110101001010010110111110101001000101010010100
0001010101001010101010010010011010101011101010110101001101110000000110011010
0100111010111111010100100010100001011010101010111010111010000101010010110101
My preference is to do this using very standard Linux utilities.
(echo obase=2; hexdump -ve'/1 "%u\n"' piglet_squid.jpg)|bc|xargs printf %08i|fold -w64
This line converts the file piglet_squid.jpg to a base 2 representation on standard output; the line length can be altered by specifying another width with fold -w.
Related
i have a file which contain some binary number in each line .
I have to convert each binary number the line into hexadecimal
file is like
10101010101010101111
11010101010111110011
11011111110000000000
10010101111110010010
convert this numbers into hexadecimal no.
if there is any gvim command it is also useful
thank you
When you get down to the bare metal, all data is stored in bits, which are binary (1 or 0). However, I sometimes see terms like "binary file" which implies the existence of files that aren't binary. Also, for things like base64 encoding, which Wikipedia describes as a "binary-to-text encoding scheme". But if I'm not mistaken, text is also stored in a binary format on the hardware, so isn't base64 encoding ultimately converting binary to binary? Is there some other definition of "binary" I am unaware of?
You are right that deep down, everything is a binary file. However at its base, a binary file is intended to be read as an array of bytes, where each byte has a value between 0 and 255. A text file is intended to be read as an array of characters.
When, in Python, I open a file with open("myfile", "r"), I am telling it that I expect the underlying file to contain characters, and that Python just do the necessary processing to give me characters. It may convert multiple bytes into a single characters. It may canonicalize all possible newline combinations into just a single newline character. Some characters have multiple byte representations, but all will give me the same character.
When I open a file with open("myfile", "rb"), I literally want the file read byte by byte, with no interpretation of what it is seeing.
How would you stick a string of hexcode into a .bin file? Like this, \x45\x67\x89 for example. I've seen the long examples where you use bash to strip it then add it to the .bin, but there must be a quicker and simpler way?
Also, I am not too familiar with .bin's, are they a program in themselves?
printf is function wide supported function. C, cpp, php, python, bash...
so classic implementation in C would be:
FILE *fp =fopen('binfilename.bin', 'w');
fprintf(fp, "\x45\x67\x89"); fclose(fp);
all other languages have similar usage.
you mention bash, and i think there is no simpler way than bash itself:
printf "\x45\x67\x89" > binfilename.bin
Every file is binary file. If it contains just printable bytes, we call it textual file. If it is generated by compiler and have bytes meaningfull to cpu, not to human, than we say it is 'binary', program. But both textual and binary contains bytes and are binaries. Difference is after, when we/some app interprets it's contents.
I'm having an enforced introduction to idl trying to debug some old code.
I have a binary image file that has an ascii header (It's a THEMIS IR BTR image of Mars, if that is of interest). The code opens the file as unit 1 using OPENR, then reads the first 256 bytes of it using ASSOC(1,BYTARR(256)). The return from that is 256 ascii character dex values, but they are mostly high or low numbers that do not correspond to alpha-numeric characters, and are not related to the header that I know is on the file.
One thing that may help with diagnostics: the original file is a g-zipped version of the file. If I try to open it directly (using less, for example) it allows me to read the header. But if I unzip it first (gzip -c filename.IMG.gz > filename.IMG) and then try to read it again I get binary gobbledegook. (less gives me a warning before opening: "filename.IMG may be a binary file. See it anyway?").
Any suggestions?
Here's the IDL code:
CLOSE,1
OPEN,1,FILENAME
A = ASSOC(1,BYTARR(256))
B = A[0]
print,'B - ',B
H = STRING(B)
print,'H - ',H
And this is what it gives me:
B - 31 139 8 8 7 17 238 79 0 3 ... (and on for 256 characters)
H - [Some weird symbol]
I've tried it on a purely ascii test file and it works as expected.
31 139 8 is the beginning of a GZIP header for a "deflated" file.
http://www.gzip.org/zlib/rfc-gzip.html#file-format
So yes, the file looks like it needs to be decompressed first.
Try decompressing the file with gunzip, and check the header again. If it is 31 139 08... again, it looks like it has been compressed twice.
Otherwise, whatever it is, it is likely that it's been finally decompressed. It remains to be seen why the uncompressed file isn't being decoded.
Try the COMPRESS keyword to OPEN:
openr, 1, filename, /compress
The COMPRESS keyword refers to a compressed file, so it is both for reading and writing compressed files.
The output we need to produce is a standard delimited file but instead of ascii content we need binary. Is this possible using SAS?
Is there a specific Binary Format you need? Or just something non-ascii? If you're using proc export, you're probably limited to whatever formats are available. However, you can always create the csv manually.
If anything will do, you could simply zip the csv file.
Running on a *nix system, for example, you'd use something like:
filename outfile pipe "gzip -c > myfile.csv.gz";
Then create the csv manually:
data _null_;
set mydata;
file outfile;
put var1 "," var2 "," var3;
run;
If this is PC/Windows SAS, I'm not as familiar, but you'll probably need to install a command-line zip utility.
This link from SAS suggests using winzip, which has a freely downloadable version. Otherwise, the code is similar.
http://support.sas.com/kb/26/011.html
You can actually make a CSV file as a SAS catalog entry; CSV is a valid SAS Catalog entry type.
Here's an example:
filename of catalog "sasuser.test.class.csv";
proc export data=sashelp.class
outfile=of
dbms=dlm;
delimiter=',';
run;
filename of clear;
This little piece of code exports SASHELP.CLASS to a SAS Catalog entry of entry type CSV.
This way you get a binary format you can move between SAS installations on different platforms with PROC CPORT/CIMPORT, not having to worry if the used binary package format is available to your SAS session, since it's an internal SAS format.
Are you saying you have binary data that you want to output to csv?
If so, I don't think there is necessarily a defined standard for how this should be handled.
I suggest trying it (proc export comes to mind) and seeing if the results match your expectations.
Using SAS, output a .csv file; Open it in Excel and Save As whichever format your client wants. You can automate this process with a little bit of scripting in ### as well. (Substitute ### with your favorite scripting language.)