i'm using this portion of code
char encrypted_text[1024];
RSA_public_encrypt(sizeof(message), message, encrypted_text, rsa, RSA_PKCS1_OAEP_PADDING);
printf("encrypted text: %s\n", encrypted_text);
and the optput is something like this:
�v0��뷾��s�E�Z��N\����6~��:�&���� /����~ͯ���L��d�Ǡ��
E��[�h�U.vH2F1Qb^)�g� ,a�Ҩ�x vU|�>�ˢ=W�ő��
�\��g
it's possible to eliminate � symbols??
The string isn't printing well because it's binary data, not text. It's not meant to be human readable.
A common way to make binary data text-friendly is to base64 encode it. Base64 encoding converts binary data into a string of ASCII characters. The encoded text still isn't human readable, so it'll still look like gobbledygook when you print it, but it'll at least be easy on the eyes, easy to paste into text files, easy to e-mail around.
See this Stack Overflow question for ways to do base64 encoding/decoding in C.
Related
I have some wave files (.wav) and I need to convert them in base64 encoded strings. Could you guide me how to do that in Python/C/C++ ?
#ForceBru's answer
import base64
enc=base64.b64encode(open("file.wav").read())
has one problem. I noticed for some WAV files that I encoded the string generated was shorter than expected.
Python docs for "open()" say
If mode is omitted, it defaults to 'r'.
The default is to use text mode, which may convert '\n' characters to a platform-specific representation on writing and back on reading. Thus, when opening a binary file, you should append 'b' to the mode value to open the file in binary mode, which will improve portability.
Hence, the code snippet doesn't read in binary. So, the below code should be used for better output.
import base64
enc = base64.b64encode(open("file.wav", "rb").read())
Python
The easiest way
from base64 import b64encode
f=open("file.wav")
enc=b64encode(f.read())
f.close()
Now enc contains the encoded value.
You can use a bit simplified version:
import base64
enc=base64.b64encode(open("file.wav").read())
C
See this file for an example of base64 encoding of a file.
C++
Here you can see the base64 conversion of strings. I think it wouldn't be too difficult to do the same for files.
I want to write a string as binary data to a file.
This is my code:
FILE *ptr;
ptr = fopen("test.dat","wb"); // w for write, b for binary
fprintf(ptr,"this is a test");
fclose(ptr);
After i run the program and open the file test.dat, i read "this is a test" but not the binary data i want. Anyone can help me?
You seem to be somewhat confused; all data in typical computers is binary. The fact that you opened the file for binary access means it will have e.g. end-of-line conversions done, it doesn't change the interpretation of the data you write.
You're just looking at binary data whose representation is a bunch of human-readable characters. Not sure what you expected to find, that is after all what you put into the file.
The letter 't' is represented by the binary sequence 01110100 (assuming an ASCII-compatible encoding), but many programs will show that as 't' instead.
Notepad decodes the binary data and shows ASCII equivalent code for it.
If you need to see the binary equivalent of the stored data then use hex viewer softwares and open your file in it.e.g. WinHex.
I have a file file.dat which has CNBC: America¿s Gun: The Rise of the AR–15
Unfortunately i got some special characters which dint converted properly in iconv function in unix.
$ file -bi file.dat
text/plain; charset=utf-8
$ cat file.dat | cut -c14 | od -x
0000000 bfc2 000a
0000003
Can you please help me out to convert the special character?
Thanks in advance
-Praveen
Your file is basically fine, it's in proper UTF-8 and the character you are looking at is an INVERTED QUESTION MARK (U+00BF) (though you seem to be using some legacy 8-bit character set to view the file, and the output of od -x is word-oriented little-endian, so you get the hex backwards -- the sequence is 0xC2 0xBF, not the other way around).
This article explains that when Oracle tries to export to an unknown character set, it will replace characters it cannot convert with upside-down question marks. So I guess that's what happened here. The only proper fix is to go back to your Oracle database and export in a proper format where curly apostrophes are representable (which I imagine the character really should be).
If the file came from somebody else's Oracle database, ask them to do the export again, or ask them what the character should be, or ignore the problem, or guess what character to put there, and use your editor. If there are just a few problem characters, just do it manually. If there are lots, maybe you can use context-sensitive substitution rules like
it¿s => it’s
dog¿s => dog’s
¿problem¿ => ‘‘problem’’
na¿ve => naïve
¿yri¿ispy¿rykk¿ => äyriäispyörykkä (obviously!)
The use of ¿ as a placeholder for "I don't know" is problematic, but Unicode actually has a solution: the REPLACEMENT CHARACTER (U+FFFD). I guess you're not going to like this, but the only valid (context-free) replacement you can perform programmatically is s/\u{00BF}/\u{FFFD}/g (this is Perl-ish pseudocode, but use whatever you like).
Suppose I write the following C program and save it in a text file called Hello.c
#include<stdio.h>
int main()
{
printf("Hello there");
return 0;
}
The Hello.c file will probably get saved in a UTF8 encoded format.
Now, I compile this file to create a binary file called Hello
Now, this binary file should in some way store the text "Hello there". The question is what encoding is used to store this text?
As far as I'm aware, vanilla C doesn't have any concept of encoding, although if you correctly keep track of multi-byte characters, you can probably use an encoding. By default, ASCII is used to map characters to single-byte characters.
You are correct about the string "Hello there" being stored in the executable itself. The string literal is put into global memory and replaced with a pointer in the call to printf, so you can see the string literal in the data segment of the binary.
If you have access to a hex editor, try compiling your program and opening the binary in the editor. Here is a screenshot from when I did this. You can see that each character of the string literal is represented by a single byte, followed by a 0 (NULL). This is ASCII.
I am interested in writing utf-8 encoded strings to a file.
I did this with low level functions open() and write().
In the first place I set the locale to a utf-8 aware character set with
setlocale("LC_ALL", "de_DE.utf8").
But the resulting file does not contain utf-8 characters, only iso8859 encoded umlauts. What am I doing wrong?
Addendum: I don't know if my strings are really utf-8 encoded in the first place. I just keep them in the source file in this form: char *msg = "Rote Grütze";
See screenshot for content of the textfile:
alt text http://img19.imageshack.us/img19/9791/picture1jh9.png
Changing the locale won't change the actual data written to the file using write(). You have to actually produce UTF-8 characters to write them to a file. For that purpose you can use libraries as ICU.
Edit after your edit of the question: UTF-8 characters are only different from ISO-8859 in the "special" symbols (ümlauts, áccénts, etc.). So, for all the text that doesn't have any of this symbols, both are equivalent. However, if you include in your program strings with those symbols, you have to make sure your text editor treats the data as UTF-8. Sometimes you just have to tell it to.
To sum up, the text you produce will be in UTF-8 if the strings within the source code are in UTF-8.
Another edit: Just to be sure, you can convert your source code to UTF-8 using iconv:
iconv -f latin1 -t utf8 file.c
This will convert all your latin-1 strings to utf8, and when you print them they will be definitely in UTF-8. If iconv encounters a strange character, or you see the output strings with strange characters, then your strings were in UTF-8 already.
Regards,
Yes, you can do it with glibc. They call it multibyte instead of UTF-8, because it can handle more than one encoding type. Check out this part of the manual.
Look for functions that start with the prefix mb, and also function with wc prefix, for converting from multibyte to wide char. You'll have to set the locale first with setlocale() to UTF-8 so it chooses this implementation of multibyte support.
If you are coming from an Unicode file I believe the function you looking for is wcstombs().
Can you open up the file in a hex editor and verify, with a simple input example, that the written bytes are not the values of Unicode characters that you passed to write(). Sometimes, there is no way for a text editor to determine character set and your text editor may have assumed an ISO8859-1 character set.
Once you have done this, could you edit your original post to add the pertinent information?