I'd have some blob data such as:
0x3333332c2044e963617269652c20356520e9746167650d0a53742d4c617572656e7420285175e9626563292048344e20334d390d0a
that I'd like to convert to text because the new database has text field instead of blobs and now it makes trouble with some accentuated characters.
Is there somekind of blob to string converter somewhere?
Thanks a lot!
Try:
CONVERT(blobname USING latin1)
It depends on what the blob is. For example, I've dealt with some blobs that could be represented as basic XML files. Those would have been relatively easy to convert. However, I dealt with other blobs that were image files. If you tried to represent them as text you'd lose data.
What are in your blobs?
Create your new database with your export, once done create your text column on the table, update that using a CONVERT drop the old column, renaming the old one if required.
However if the data contains simple byte stream (that is, unstructured data, files, audio, video, whatever) and you need to represent them as pure ASCII you could change into a Base64 string.
If using phpmyadmin, tick the box that says "Dump binary columns in hexadecimal notation (for example, "abc" becomes 0x616263)" at the bottom of the export page.
Related
Description of the issue:
I have an Insert script contains the binary data (image file) which used to be stored in Mysql DB as a blob, and the requirement is to convert the blob data to base64 and store it in SQL Server. I tried inserting the blob data directly to SQL Server as Image and varbinary data type and converted them to base64, however, both methods failed to display the image on the web.
I tried exporting the image file from Mysql db and try to view it, but the format looks invalid.
I'm not sure what format the image file stored in Mysql DB and its hard to decode. Can anyone help me?
Sample file:
0xa15b8a9e56c2a7f9b56c4015a0eaf6abaf9f39575c028b39ffea32c35dad471522babf9f5abfeaea7eafaebafadf2d596
Where is the problem? MariaDB BLOB? SQL Server? Displaying Base64 as an image? Something else?
Here are some tips:
In MariaDB (at least) you can use UNHEX(some 8-bit data) as the expression to insert into a BLOB column.
In MariaDB (at least) you can use BASE64(some 8-bit data) to produce a text string that could be put into either TEXT or BLOB.
To display Base64 as an image in a <img> in HTML, you need to say that it is encoded that way. (The details are a bit obscure, but it works, and the string is part of the html.)
To display an image (from any of many locations), you need a separate program that runs in the web server, has the suitable "Header" and writes the binary (not Base64) bytes of the image. In this case, use, or example, <img src=foo.php?...> where foo.php uses its paramters ($_GET) to fetch the image (and, if neccesary, convert from Base64), then echo the Header the the image type and the binary of the image.
I need to store HTML data in a MySQL database. I read about this and found that the best method is to use NVARCHAR or VARCHAR. Furthermore I'd like to compress the input to make it less space consuming. I use PHP's gzdeflate() function for deflating the HTML input, but in this case what MySQL data type should I use?
EDIT: Since I need to store quite big HTML sources I decided to go with the TEXT data type but the question: Is MySQL's TEXT field compatible with a deflated HTML string?
Use BLOB type instead of TEXT to use it for binary data.
Here's the type of text my encryption function throws out:
I generated several strings and they're never bigger than 50 characters, but I would like to give it 75 characters in mysql. I tried using varchar, but the string gets cut off because it doesn't like some characters. Any idea what data type I should use?
If it's binary data (it looks like it is), you probably should store it in a BLOB.
You can use a blob, but for short data, that will make your selects slow.
Use binary(75) or varbinary(75).
I was wondering about the best way to tackle this. I'm trying to save a user-drawn image on a HTML5 canvas to my database so I can retrieve it later.
I got as far as creating the base64 data string for the image with the following code, hooked to a simple button clickhandler:
var image_data = $("#drawing_canvas").get(0).toDataURL('image/png');
I was planning on saving that data to my database and then retrieving it later on with something like this:
var myImage = new Image();
myImage.src = imgData;
ctx.drawImage(myImage, 0, 0);
However, these base64 'strings' seem to contain a lot of data. I was wondering if there's a better way to save these images to my database? I have yet to figure out a way to save the actual image as a .png. I could get it to open as a png in a new browser tab, but that's where I'm stuck at the moment.
Or would it be fine to store these base64 data strings in my database (in, I suppose, a 'text' column)?
Thanks in advance.
You want to use a BLOB type. Here's what the MySQL docs say about it:
BLOB values are treated as binary strings (byte strings). They have no character set, and sorting and comparison are based on the numeric values of the bytes in column values. TEXT values are treated as nonbinary strings (character strings). They have a character set, and values are sorted and compared based on the collation of the character set.
http://dev.mysql.com/doc/refman/5.0/en/blob.html
I've got a database where for efficiency, i've put the data into the db in html encoded formats.
I do maintenance on the data, and then move it into production via an 'into outfile', so it ends up in a text file.
The special characters don't make it across cleanly, and it comes out as all messed up code.
Is there a way to maintain the format for the txt file?
Or should I be using another format?
The 'outfile' , and 'import'I find very efficient for doing a bulk transfer.
If i can't use that, any suggestions on the best way to find special characters in mysql?
The only thing I've found seems to find fields that ONLY contain non-ascii characters
SELECT * FROM tableName WHERE NOT columnToCheck REGEXP '[A-Za-z0-9]';
Is there a reason you're storing HTML encoded text in the database? As discussed in episode 58 of the Stack Overflow podcast, you should always try to store raw data at the highest level of precision possible.