I have a bunch (about 1200) of jpg/jpeg files, which have a filename pattern of: IMG-YYYYMMDD-WA####.jpg or .jpeg. None of them have any exif data. I would like to (batch) add exif dates (created, modified, ...) using the date pattern in the filename. Time doesn really matter for me.
I have searched this (and other) forums, but i cannot find anything related to ADDING these dated to jpeg files. I was hoping someone here could help me out.
EDIT: Using Linux (Mint 17,1)
This should not be difficult to write. What you need to create is a filter that:
Removes the existing JPEG file APPn header
Inserts an EXIF header with the date.
You would not need to mess with the compressed data at all. You're going to need to read a bit of the JPEG standard, just enough to get an idea of the block structure. Do a byte-by-byte copy until you hit an APPn marker.The APPn markers have byte counts so you know how much to skip over. Insert your own EXIF marker into the stream. Then copy the rest of the data.
You're need to read the EXIF standard to figure out how to format the header.
Related
I need to programmatically find the fragments that are called by each rtftemplate.
So, for example in the figure, I would need to get the "GlossaryTermsAcronyms" fragment for the H2_terms_acronyms template.
I can't seem to find any query or script solution to do this. But this should be possible, right?
Unfortunately that is (almost) impossible.
The information is stored in the t_documents.bincontent column. It is binary encoded RTF.
Somewhere in that RTF there should be a reference to the templates fragments that are used.
If you can figure out how to decode the bincontent to get to the actual RTF code of your template, you might have a chance.
Binary fields in EA are usually stored as a zipped text file.
In case the field is included in an xml file (or xml string in the database), it will be base64 encoded.
I wanted to download an image from the web. But when I 'save image', it opens as a .txt file. I figure this is some type of encoding for the image but I can't find out which.
I want to eventually automate downloading the image for further processing, specifically text recognition. I've tried to convert the .txt using some online base64 encoders/decoders with no success. However, https://convertio.co/ was able to convert the .txt to .gif but I don't know how it did what it did.
I've given a sample of the .txt file. The actual file is much bigger.
The file name beings as such (if it helps):
data:image;base64,R0lGODlhyABGAIMAAPRDNvRDNvRDNvRDNvRDNvRDNvRDNvRDNvRDNvRDNvRDNvRDNvRDNvRDNvRDNv///ywAAAAAyABGAAAE+vDB (and it goes on, its very long).
GIF89aÈ�F�ƒ��ôC6ôC6ôC6ôC6ôC6ôC6ôC6ôC6ôC6ôC6ôC6ôC6ôC6ôC6ôC6ÿÿÿ,����È�F��úðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|úðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|úðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|úðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ|ðÁ;
I can see that there are '|' characters in between. May be for separating pixels.
The entire file is here: https://pastebin.com/BPbTHMZ7
It's seems to be a GIF image encoded as a data URL:
data:image;base64,R0lGODlhyABGAIMAAPRDNvRDNvRDNvR...
This format can be used in HTML and CSS file and is handy because the image data is directly embedded in the HTML/CSS file and does not need to be loaded with a separate request.
The start of the text basically says it's data URL, containing data for an image and the image is encoded using Base 64.
To decode it:
Chop off the start of the text, namely data:image;base64,.
Run the remaining text (R0lGODlhy...) through a Base64 decoder. The result will be binary data.
Save the binary data to a file using a file name with the extension .gif.
Now you have a proper GIF image as a file.
We have uploaded a file with bad encoding now when downloading it again all the "strange" French characters are mixed up.
Example of the bad text:
R�union
Now when opening the CSV with Openoffice we tried all of the encodings in the Dropdown none of them seem to work.
Anyone have a way to fix the encoding to the correct one that we can view the chars?
Links to file https://drive.google.com/file/d/0BwgeuQK3LAFRWkJuNHd2TlF2WjQ/view?usp=sharing
Kr.
Sadly there is no way to automatically fix the linked file. Consider the two words afectación and sécurité. In the file they have been converted incorrectly to afectaci?n and s?curit?. There is no way to convert the question marks back because sometimes they're ó and other times é.
(Actually instead of question marks the file uses the unicode replacement character, but that doesn't change the problem).
Hopefully you have an earlier version of the file that has not been converted incorrectly.
Next time try to use a consistent encoding. This question gives some suggestions for how to do this.
If the original data cannot be obtained, there is one thing that could be done outside of retyping the whole thing. It is possible to use dictionary lookups to guess the missing words. However this would be a difficult project, and there would be mistakes where incorrect guesses were made. It's probably not worth it.
I am writing a game for iOS that uses .tmx map files. I am creating the maps in the application 'Tiled' and then at some point before they get to iOS, I'm parsing them with Perl.
When I save the files as straight XML, it's a cinch for perl to parse them. However, cocos2d insists that the files be base64-encoded. The 'Tiled' map editor has no problem saving files with this encoding scheme, and iOS reads them just fine, but it's presenting problems for my perl code.
For some reason, the standard MIME::Base64 decode_base64() method in perl is not cutting the mustard here- when I decode the strings, I get one or two binary characters-- question marks in diamond boxes and such.
And the vague documentation for the TMX file format makes it unclear if there is some other encoding going on before or after the base64 encoding which might be causing this problems. I looked at the cpp source for the encoder, and I saw lots of references to Latin1, but I couldn't decipher what's going on in detail.
I noticed that when I tried doing my own tests with MIME::Base64, encoding and then decoding a test string, the encoded text looks dramatically different than that which I see coming out of the TMX files-- for instance, my base64-encoded text for a short string looks like this:
aGVyZSBpcyBhIHNlbnRlbmNl
But the base64-encoded text coming from the TMX files looks like this:
9QAAAAABAAANAQAAGAEAAA==
Any suggestions on what else I might try in attempts to decode a string that looks like that?
I think this page might be what you're looking for. It suggests that first you decode_base64, then (if the compression="gzip" attribute is present) use gunzip to uncompress it, and finally use unpack('V*', $data) to extract the list of 4-byte little-endian integers.
I have written a small program which can encode/decode a text with uuencode/uudecode. The code is based on the algorithm described on Wikipedia. It works fine when I encode/decode a string. But I have found a uuencoded file which I can't decode. This website can decode the file, but when I encode it again I don't get the same file. In addition, when I decode only one line of the file I don't get readable text (neither with my program nor with the decoder I linked before). But in uuenoding all lines are independent from each other - this must be able.
Do someone know whether there are some special variations of the uuenoding, which are not described on Wikipedia? I can decode some strings so my decoder can't be totally wrong. Perhaps someone has written his own decoder, so I post the whole file:
begin 666 Restricted.zip
M4$L#!!0````(`%T[="_]<LYX`P(``'0#```.````4F5S=')I8W1E9"YT>'1M
M4\MNVT`0NQOP/TSNM#PT0!/X4N16`RE0%.GC.I9&TE;2CKH/J_K[<E;IX]"+
M'UJ20W)6^]U3)SX=]KO][D*]SD(7XHD2CX/S'26EU`L%U_6)9#E1?46NQ4,7
MR?E6P\3)J:=%#ABZY7'$P2MO"0J1GGT3Z;B1YJ#?I4ZT:!X;N#KI34)%3Y%6
MS8#>A#I-&[;E`-H%'(EY#G[/(-I',=GI;XN"H49?''YXT#LE]BNU.<!&,*(W
M0&4Y7V#,F_&11NV<-TNU-!D!>HZP5"MF91^YE0-D&H2C5CAL\T&P:#/'A*<+
M#F6(!IEXW?Q?13Q=#P[XLBHJ>L[UX,;U8+`"X3I)0S^RJX=Q+3-28)##+IK:
MEAD#AQRM7DY)ICG%BK[:(,\=L$C>20*EUCR/8BP'&'H+.OT5:+`V>,*NK$%9
MZ<;>Q1X"1WJOBZ#_8HQ+`3?K%(U<1U-:7.HI6A]_+/V[\RU,J]DW!SMV#<37
M89W+>5QCL6/"MDHTQPV&UT5-<R!=?%D)MG^AR&Y3^>]::JP0H2MZ4>3UR?F,
M[>18,L'"..I2K'.,BP8TF<K)YT_/IG1S#<#VZ^,KX$QO'[\\WC_<W;V[?_-P
MW>^`/%.?TGP^G99EJ29MCC^K6JL\G%H78CJQC[CGU=S/V_M2KEN<A0?;A5U`
M[AC.U2*6OUOE0<KD#Q#\MM_]`E!+`0(4`!0````(`%T[="_]<LYX`P(``'0#
M```.``````````$`(`"V#0````!297-T<FEC=&5D+G1X=%!+!08``````0`!
+`#P````O`#``````
`
end
I found the solution! The problem was that I did not notice the first line. This line holds information about the data encoded - a file named Restricted.zip. So the decoded data is a ZIP file which I just had to unpack.
I got a text file named Restricted.txt which contains the readable data.
The problem was so easy, but it took me days to see its solution.
That's a good change over to packing algorithms - perhaps the next thing I do is writing my own program which can pack/unpack zip files.