take it from someone who has made systems like this - storing your files in the database really is a bad idea.
Also is your application running on a client and connecting to a mysql server directly? If so that is also a really really bad idea because then everyone will have the login info you used and will be able to connect to your db with whatever user rights your program has and do whatever they want.
Here's a better idea...
from your client program, use libcurl to talk http to a php script, something like:
http://www.mydomain.com/index.php?function=uploadfile
send your file data as a POST argument, and base 64 encode it (cause its way smaller than HEX!)
have your php handle the file... write the file to disk with a unique id such as "1.dat" and store information about that file in your database where "1" is the primary key of your file information table.
if you want to download a file you can hit a url like this...
http://www.mydomain.com/index.php?function=download&fileid=1
if you want to, you can add username / password parameters to your php file to make sure the user is valid.
there is more security stuff you can do but this is a whole world better than what you are planning.
no offense, just want to inform!
Store Binary File Into a String? (C++)
Author
Well actually, mysql is connected to my server application, for the user to do ANYTHING they have to always supply a username and password for things like file upload, downloads, user account checking, etc and by the server the user is automatically logged off the server after a command is done. So it doesn't stay connected all the time. Plus if I used mysql it saves me a lot of time making back ups for clients or removing a user with the database on my PC.
Plus the thing is if I did use my web service, yes I would get more traffic, but I would still have a disadvantage of speed and a risk of loosing my account because most hosting company's frown files that aren't being used for your website.. It's kinda stupid I know, but I'm not going to write a blog about it...
Anyways, the client application stores the login and when ever it gives the password it will be always encrypted.
And don't worry I think it's great your taking your time to inform me the risks and I appreciate it and not intending to kill my hopes and dreams, hehe.
On the other end...
Also I figured out why I was getting only a short part of my binary string!
When the buffer passes through anything using strlen() it kinda tells my code to only copy that small part to send to the server.
I'm sure because of garabage collection isn't included with most C++ compilers by default they added a check for a "0" function in the strlen(). Then say the string ends there! Instead I used ".length" with a std::string for my buffer.
It works pretty well for large binary files it appears! Thank you guys!
Plus the thing is if I did use my web service, yes I would get more traffic, but I would still have a disadvantage of speed and a risk of loosing my account because most hosting company's frown files that aren't being used for your website.. It's kinda stupid I know, but I'm not going to write a blog about it...
Anyways, the client application stores the login and when ever it gives the password it will be always encrypted.
And don't worry I think it's great your taking your time to inform me the risks and I appreciate it and not intending to kill my hopes and dreams, hehe.
On the other end...
Also I figured out why I was getting only a short part of my binary string!
When the buffer passes through anything using strlen() it kinda tells my code to only copy that small part to send to the server.
I'm sure because of garabage collection isn't included with most C++ compilers by default they added a check for a "0" function in the strlen(). Then say the string ends there! Instead I used ".length" with a std::string for my buffer.
It works pretty well for large binary files it appears! Thank you guys!
ok well i wanted to give you warnings but if you are set in going that way (especially if you have technical reasons why you need to!) then so be it (:
good luck man, and im glad you got your string thing working.
good luck man, and im glad you got your string thing working.
EDIT: sorry, I posted the stuff below in haste and didn't see your most recent post. However, this has nothing to do with garbage collection. strlen determines the length of a string by looking for a 0 byte. That's just what it does. It might be prudent to get hold of a good tutorial text and brush up on your C++ fundamentals.
Do you mean you're looking at it in a debugger, or you're compiling your code with debug settings? Which ever method you're using to look at the data, make sure it really is looking at all the data and not stopping at the first '\0' byte.
For example, if you look at a char* in your common or garden variety debugger, it will only show you the data up until the first '\0'. Similarly, using strlen to determine the amount of binary data a char* points at is incorrect.
In binary files '\0' bytes (having numeric value 0) are extremely common. Since you're only seeing 4 characters, I'm guessing the 5th byte of your file is actually equal to 0. Is this the case? Get a hex/binary editor and check.
So, my code again with a couple of amendments (reading in to a vector now, to move away from the binary/text confusion):
Quote:Original post by ajm113
@Zipster and edd, sorry I forgot to mention! I tried that I get the same effect pretty much. I'm just looking at what VS2008 gives me in debug mode. I'm guesting what VS2008 isn't as always accurate in debug with strings that has binary data.
Do you mean you're looking at it in a debugger, or you're compiling your code with debug settings? Which ever method you're using to look at the data, make sure it really is looking at all the data and not stopping at the first '\0' byte.
For example, if you look at a char* in your common or garden variety debugger, it will only show you the data up until the first '\0'. Similarly, using strlen to determine the amount of binary data a char* points at is incorrect.
In binary files '\0' bytes (having numeric value 0) are extremely common. Since you're only seeing 4 characters, I'm guessing the 5th byte of your file is actually equal to 0. Is this the case? Get a hex/binary editor and check.
So, my code again with a couple of amendments (reading in to a vector now, to move away from the binary/text confusion):
std::ifstream file("filename.txt", std::ios::binary);std::istreambuf_iterator<char> b(file), e;std::vector<char> content(b, e);// The correct way to tell how much data was read:std::cout << "read " << content.size() << " bytes from file\n"; // try this!
Have you actually examined the contents of the file?
Are you opening the file in binary mode?
And again, why are you putting it in a string? When you call the file a binary file, you are basically saying that you don't want to treat its contents as "text". When you put it in a string, you say that you do want to treat it that way. Which is it?
Are you opening the file in binary mode?
And again, why are you putting it in a string? When you call the file a binary file, you are basically saying that you don't want to treat its contents as "text". When you put it in a string, you say that you do want to treat it that way. Which is it?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement