Convert binary data from URL to an image file - image

I read several articles on StackOverflow, but none of them seems to work in my case so here is the situation.
I have a webpage that is not under my control. It contains an image that is referenced in the markup as something like <img src="getimage.asp?pic=4c54aae0ea..." />. Given the URL of that image, I would like to download it, save it to disk and do something with it.
When I enter the URL directly in my browser I get a binary stream. This is the first load of characters.
ÿØÿàJFIFHHÿþLEAD Technologies Inc. V1.01ÿÛ„ÿÄ¢ }!1AQa"q2‘¡#B±ÁRÑð$3br‚ %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyzƒ„…†‡ˆ‰Š’“”•–—˜™š¢£¤¥¦§¨©ª²³´µ¶·¸¹ºÂÃÄÅÆÇÈÉÊÒÓÔÕÖ×ØÙÚáâãäåæçèéêñòóôõö÷øùúw!1AQaq"2B‘¡±Á #
How do I convert that data to an image using e.g. C# or any other language. Since I do not control the page I have no idea of how the data is encoded - so can I still decode it?
As can be seen from the first couple of characters, the string "LEAD Technologies Inc." is included in the data so I guess its not all image data. But at least, Chrome obviously knows how to decode it. A quick Google check reveals that "LEAD technologies" is an imaging SDK, but their website doesn't seem to offer much information about it's use and Im also not proficient in image manipulation. Any ideas would be appreciated.

The first couple of characters indicate that the response is probably an jpeg file interpreted as ASCII text. I guess the Content-Type header in the HTTP response has the wrong value, probably something like text/plain or text/html instead of image\jpeg. This makes Chrome display the image as plain text.
I don't think you have to convert the data. Just save the response stream to a file and you will have a proper jpeg file:
string url = "http://my-domain/getimage.asp?pic=4c54aae0ea...";
string fileLocation = #"C:\MyImage.jpg";
var client = new WebClient();
client.DownloadFile(url, fileLocation);
The reason I think that the response is probably jpeg, is that a jpeg file begins with 0xFFD8FFE0 which looks like ÿØÿà when displayed as ISO 8859-1 encoded text.

Related

AppleScript: renaming PDF with content of PDF

I am trying to do exactly what is described in the following thread:
AppleScript/Automator: renaming PDF with extracted text content of this PDF
So I am using the Chino22's version and there are two issues with it:
First, instead of the contents of the pdf, theFileContentsText gets some metadata stuff.
Second, althought the script runs to the end, I get the following error for the last step:
error "The variable thisFile is not defined." number -2753 from "thisFile"
So, how do I get the text contents instead, and how do I define thisFile to the current pdf that is being processed in the loop?
Thanks in advance!
I would not expect the linked script to work.
Except for document metadata, extracting text content from PDF is notoriously difficult and unreliable, and not a road you want to go down if you can possibly avoid it. Adobe’s PDF file format is designed for printing, not for data processing. PDF files contain blocks of Postscript-like page drawing instructions, typically compressed, and while it’s possible for PDFs also to include the original plain text for accessibility use, most PDF generators do not do this so the only way to get the original text is by reconstructing it from those low-level drawing instructions—not a trivial job.
AppleScript’s read command only reads that raw file data; it does not parse it into drawing instructions, never mind translating those drawing instructions back into plain text. Change a PDF file’s extension to .txt and open it in a plain text editor, and you’ll see what I mean. Nasty.
If you need to work with the PDF’s original content (text, images, whatever), your best solution is to get those files before they were converted into a PDF.
If you must extract content from a PDF file, use an existing tool that knows how to do it.
For instance, if you’re lucky enough to have PDFs that contain XFDF (XML form) or accessibility data, there are 3rd-party apps and libraries to extract that content in readable form. I can’t think offhand of any that are AppleScriptable (Adobe Acrobat has only minimal AS support) so you’ll probably need to find one you can run from command line (do shell script in AS).
Or, if the PDFs have a consistent visual structure, a 3rd-party library such as Python’s PDFMiner (which I’ve used in the past) can identify blocks of characters by position and convert those back into strings with varying degrees of reliability (it has to convert font glyphs back into Unicode characters, guess at which characters are close enough to constitute a word, and where to insert space and return characters between those words). You’ll have to write some Python code to extract the bits you want, so look for tutorials to get started (or pay someone to write it for you).
But again, if you can possibly avoid having to extract text from PDF, you should. You will save yourself a lot of trouble.

Part of Image Missing From Data URL

Backstory to the below issue:
I'm using the jQuery plugin Cropit to produce an image which I get in data URL form (the user uploads an image and Cropit allows them to manipulate it, when the user is happy, Cropit exports the final image).
This data URL is attached to the product (this is a Shopify website) via Shopify properties (in a similar way you would attach text for an engraved product) and then when the order is created, I have an app listening for new orders and I pull the data URL from the order.
From testing, I can confirm that the data URL is wrong / corrupted / broken at the time the order is placed and not being broken in transit.
Original Question
I have a bit of a weird situation and I can't find any similar situations online.
I'm being sent an image in data URL format (from Shopify if it's relevant, I have written a private app and their webhook is sending me an image)
The image is in a data URL format that starts with, as an example,
data:image/png;base64,iVBORw0KGgoAAAANSU.....
The problem I am having is sometimes (and it's maybe less than 10% of the time) when I get the image and try to print it, it's missing the bottom chunk of the image. In a PDF, it considers the image corrupt, and in a web browser, it just sees the bottom of the image as transparent, however much is missing.
This is what it looks like in Inspect Element on Google Chrome when you hover over the image URL (image has been purpled out for anonymity)
My question is, does anyone know why?
We can't find a correlation with browser or device type. And I'm not sure if it's because part of the data URL is somehow missing (maybe a character limit, because it's a really long string!) or if it's the type of image. Might possibly be something going wrong in the upload process?
Is anyone able to shed any light? It's such a weird issue I'm not even sure what to google!
And just to confirm, the image absolutely has to be sent in this format for a whole series of reasons, mainly Shopify restrictions so I can't send the image in file format.

I want to batch extract gps data (exif) then convert to address and save that text to a jpg

I have 1500 pictures that need the address where they were taken to be shown in the corner of the picture. I have the pictures geo-tagged.
I need help extracting the GPS data and converting that to an address.
Then getting that address and saving it into the picture in the bottom right corner. Can anyone help or point me in the right direction please?
You're going to need two things. First you need an application that will extract the EXIF data that you are interested in. You should be able to write this yourself as it is fairly simple to do. You will need the JPEG standard and just need enough of it to identify the markers; specifically the APPn markers. You are also going to need the EXIF and (possibly the) TIFF standards to figure out how to extract the data you need form the EXIF APPn marker.
Writing the information to the corner of the image is the tough part. There are probably command line applications that will allow you to do that already. If worst comes to worst, there are various language API's that will allow you to read a JPEG stream into a buffer; draw text to the buffer; then write the buffer back to a JPEG stream.
You will most likely need to use a programming language for this; I think Python would be suitable as it's easy to get started and has libraries needed for your task.
For example, in order to extract the location (coordinates) from the JPEG files you can use pyexiv2.
To transform those coordinates to addresses you need to use a geocoding service such as Google's Geocoding API - you can use their Python library directly or code your own using something like requests.
Now that you have the address data you can overlay that data onto images using Python's pillow library.
If you're looking for some code to get started let me shamelessly plug my own project called photomap; you can find code to read GPS information from images here: https://github.com/iticus/photomap/blob/master/handlers.py#L170

Why it is possible to show a base64 encoded PNG with an "image/jpeg" data URL?

Here's as an example of a base64 encoded PNG data URL (using "image/png" data type, of course):
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABIAAAASCAYAAABWzo5XAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAZdEVYdFNvZnR3YXJlAHBhaW50Lm5ldCA0LjAuMTczbp9jAAAA1UlEQVQ4T62SsQ0CMQxFUzAEA1BQMgIlI1zJCIxAT0HJCBSUlFdQMAQlJWOE78hnObYDIuJLTzr/+/5FkpRz/guh2UM9pLQBWzDXvgVacG4lngncAH08QFgGLcEL0LAX34ROHCBcGaRLiEH+meAMXDhESBlkS3bVrh6KEZetQbOk7FmjmL5M40rKTmQSEJVdeXlCDtcSmgRkz4Ro32Zo+pK7+g7LqqEYjduBjsrzT6Mavl3xhzIJcXDkEBHfTl3WfNln8ARhyQR0sDkX6iU0ewjN38npDdYczGIKuRnZAAAAAElFTkSuQmCC
I noticed that (in Firefox and Chrome) things work even if data type is set to "image/jpeg" (and leaving all the rest untouched) like this:
data:image/jpeg;base64,iVBORw0KGgoAAAANSUhEUgAAABIAAAASCAYAAABWzo5XAAAAAXNSR0IArs4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAAAZdEVYdFNvZnR3YXJlAHBhaW50Lm5ldCA0LjAuMTczbp9jAAAA1UlEQVQ4T62SsQ0CMQxFUzAEA1BQMgIlI1zJCIxAT0HJCBSUlFdQMAQlJWOE78hnObYDIuJLTzr/+/5FkpRz/guh2UM9pLQBWzDXvgVacG4lngncAH08QFgGLcEL0LAX34ROHCBcGaRLiEH+meAMXDhESBlkS3bVrh6KEZetQbOk7FmjmL5M40rKTmQSEJVdeXlCDtcSmgRkz4Ro32Zo+pK7+g7LqqEYjduBjsrzT6Mavl3xhzIJcXDkEBHfTl3WfNln8ARhyQR0sDkX6iU0ewjN38npDdYczGIKuRnZAAAAAElFTkSuQmCC
But... Why?
They're both using the image handling subsystem, which ignores the mime type and just goes with the actual format of the image.
Specifically, most browsers will translate the viewing of an image into the viewing of an HTML webpage with an <img> tag in them. Since servers lie and browsers are supposed to be able to show even badly-configured websites, the part of the browser that deals with images will in most cases completely ignore any extensions or MIME types. There was no point programming in an exception for data: URIs.

What exactly is going on with this image URL

I was copying image links from google and I'm seeing more and more urls like this. What exactly is going on here and why are developers doing this? Heres a example.
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAO0AAADVCAMAAACMuod9AAAAXVBMVEX///9Twd5Kv91AvNxNv91Fvtyi2uvq9vr6/f7L6vPP6/Tk9Pk8vNvE5/Lw+fz1+/1ox+FexOCQ1Oh/zuV1y+Pa8Pey4O664/Cc2Oqq3e2W1ul7zeSH0eav3+7e8fh0dubVAAATFElEQVR4nO1d6baqOgzellZlUEFFnN//Ma+gTdIBOoi4zl1+/87ZAh3SzEn//n744Ycffvjhhx9++OGHH0bBMq+zrM43Y75zU68Ot9OhqddjvvVtpNtZIjokbD9Px5hyfriyxztZC5HMjvcR3jkGNkch+AzAmSjKw+KtV+bzWcHIOx9vTcpspPG+hUPCZjo4S8om+o1NVZivfMx3txxx2FFY7oU5sG5wQhxjjtuDUtRdpWuYjz7+sLHNekbWghXbUIJen23bCtMt6o/MwhPL/pG9hrcN2d/lsRhYvBbJN3e3dAyune/c+20HMbCvr9fx753dozI6zhjn5vQZW3m97F6ZHODxylYI0f/Zf3hO/eNLcBBCXI6n0/FaJSaTEaXH8d3qRMxZwa+nJs1Wp32CfxN+azc+kI5Zlcr/XNbzypBJxcnxqoxpj7Bi3+Aabba4sOxT0xlGCpQnjupfFnMu1J0S1eD2bgt1W8XspnG3FKbLXCv3GVRyQsLCiNJSm0Bx6H1RPlPPf1Km5o9SeN9XNreWn+cX+9/paWvXZN/DThvlxHLRoyICSxTxWlo8tnKMSZ8RUJcKl+XcqtnvlB+xmWVfn5CKDC9HGX8Y5EFiAwJ1xRUatVDzulLkS3EbeJlcluQ9kyMGGXx7UN7PFTIVV/0tCrUXu0FbEfZ/YEk+hPNrmEyfgIaFQs6sUuZzoKyMs14ifuLGvkbKsF1Os/OmbC+1Y84J+YNwGnRr+fNiavURv+z+7UI5mwUsz4XsOk88OK1UZ9wrPDLg2NrFj4YzpdjkxatKsgZsWPt4Yf56YnIF4xT24YzqVknLxTd0wxPH4Ye3vAhh98bIY3BlYUSlSBqx/VsrvNhTX9jAOY8feBTkEUq8rfUrOaXiSnweXHh7JORDHsxiVIC09X/kRA4v9VFW/u6NvVytaV0Yy0QONeChVDUUXgc/xDw/f4cpL+QJ8mLJErnpTTS0q0FI/cLTHTIW7pI7boMeW+suyuQc9HwjZ9tvPn4CIAuO7t9SLCtlukmg4JQOhCFL5AOAzwbL+T2ZLgu1VOvIRX4Tq+jZUqds8NORB+hdwGxDD5DqgfZRjinyf2u2e821WDiMPA0w2yBO/jZgtmGG9dYIBhRBcdkvzTaOS50s8UAREij6EiVnMaJghboURlD4LMA0/xKXihEFNU5WHFHuhvhd4LNhSsm7iFjkNZIxu/6t8QQz/3dEkdT7iNCTyW62hkCOPqnEm7HHi/m3IO1qfzK84GSfdlOGhJ34GrigJ08cLgDfuefvj0DHEHBucHd9GbP0D00d1oRt8fs5MW3R009WwNNMltEYf2/HOJDKvV+UYoHbSBNFLsCqXD54+YCkhYnTL8JWGc1aVTOuev6/D5X89cTu81MIv9hhEF+VNkQqFT7bJUlERI05His5Ww/Jd8DzqbNw1Di4h9d0HSwJRkLt78i+44zM/B+yEu43yY96nvLxEODIRovWRq1X4FTumHvzrcjInxykk2HgobWHBJBTOY/uUbLGybOIwJHtYMoNkGqPPrz2P7pS7InJk5Xnfkx5gXNB1rLsIP+VudYD4JcO8AlIpuywgohHtSwrJpIiQRSFYLNqD7+YJYOOG9BRQgIU4yAfZFPLPGtO20ulBAfsKaBKaiSb7a/HQ3q35l+svsWS/whZKSNb3lenbfmsCOBDyct94G0dgSiK8jpf1eqk59+JFHQANiUjUPlqfmmLKZglkTVi1m3+asL2x+YuT2n5JZugxYloU/fmXBbCnV4cM2smimrbtBP8WpLJH2Gl1b4YaT97Z/yYclJKQyQoijoWlkROTgFYz4mDQE/k0aNGRL1g+lS4dMt6KmNs82NdFViRdOK1Ksty/8BD/FYzLlqx2/5ZT8cemq64hgVU3sJql4iAbeG7ZpXV+XrTw1yW68U9SxsaSHDt+mORdpPoytm1GJ5qy1GK2ZX8h+eb57C7/FK2alZfFdRrwsX1w9kXiznrFzMd52wFZLZA97rqiBoGaJmtNrquV/PdLBni9o+xzD+XvJvu+wqxniLi3KDyA4w6IBKQA5dP5K4t781xSMCxYv+ZI3yY9fIlXp0b1TYlVBnwiWPPU/nq2F9nJfhhbG1jeRpSlIz0pYW5S15AijDcXfv+Q8zEfMwi5+XcWiIKQsMwSkr4TZi5gk65QjuQYPNzG+9iyXG0/b1Z9vXBEncraePqHk+oAJiJwEFAacZMcytKlxSv0qtN/rGAesEhaJUQT9IR245C5aw0Ug5wrGlY4qOqPJXntnPAZQ/dxpgwGyEUppYFdKvLUNBdrQ4MZDbhfl8kCyWeBoScvFxSNrEvqjf9VXM9EZMrJeJQ3EaDX4vew+cD8NswqvwfYAHx/1Zlos2XF+/E7NWCgHYEyVmVNHJigkg9HG/MUbKvFRCy8sr8qHMUxqMt/YNaJMrFzHCRACmjox/rC0NELQJENSm1Bf+bUVvdzDSCLiLtQbXkjIvKooenptMTZOawA7Ef6E0H3je3ELLEqlLny8oI4auWnD30KLvNIWcLDBEDO/1p1ot6qOsJMCp0UsBMrCGRVKvKDvdb5cqC9XN3mQ0ufeNLtAbsLOo+L4uu70nCrz1GGxx8KcCwiq6H7a3UmtYk0BqsaRUWHzgLNQzkeaJA+jDrM6uK9Ch5WKlH2w7neqktcId+iXZSCwKD3Bs1FTzDZe8wsG5268Ga4Huly0hmzcc+c+Wl4AEb0h82F7pBIWnepPz/IWCHfdUn2Mz2XxCftGlRc1s3C1Ga+TTkOLR/BGE7HP9ZKRVW3rtL8gPcJWcgH1tVD2jQ5gXt6/FiSRkBVtdZFdLKd5kYSheZwvfskkhV4rbFJU9pxSPwF4uhp6cmk30wFT4QY0WOrMHNa2nJkVciB42We5WckZJn5G2m9NkN2ccGMadEjl3l1npkZtRIzT4/b8udcbJepjjoPnOwuM0c68OgQ9ake/BVCFhNr2DXAn06XqFAQsZ+UhqEDnrzjYSRta3Mi2yuwUKRTIAm/GLUpCuSh/8PeKznzlI9Hp40ONvOwo2VJwy5e9Gf8E0O3uCiuwNGQHH+9Rx757jy4a21pVcba+hdgYBphs5slKbX19SPVDuT5kZtHVtrI1PtmYCMMLDCnM8Adwgx19SBW3TGZOaCuQ3aUQ/JGsLGI8NSCKggKCXpoOrkxtZm7giZRXM4q91rAsYDupgjjWw1YEgOvJ3unWVr5wOyFh4zntoobw0rxfHrjCGzzQJjpGeqoZpmjYsjd4+Z6jJtTRaWIuXZnwLSncO8d4SB2iy9ymO2FrVwSeqHAt1r8ovFYAo/FP8Her1JMqPFYvUJRNuKw/EEhHovZQnd8K7JNQko/u+QKUaLDp8wvm22C3gwNLEECuwH1Sm5t7YdGgIKR2ahCp9Avm22yA5CXU3SkhguQJAUGdh0gLBPG/N0t3200hxlyoGNDeVjw+045EkJ5ApUxFhy/q8eB9fCKSin97RWX8j9ypXg/IXVKSgtpMzNPfiwKeOpjdJ8KqgqEzyhw4V36PAKiWo0ChsyF+ru1hwtxHRW6D+Ek4C4dYX9wNDyb0Cjy1PL5rp31mQUmp4csvzoVXBMAu0Zf5uj1rbOPIInJymbarBuN/m3cQRScxDyH0198A4fXfVxGU8uXaRsemEM+9Y78o0VOW7nyyrYnN8YprqpKrvsAnNrDd3aN3UVVRIfsYXC0dMlezL9UiYDHU50NR2ydzND1s9NtkY3nI+6SbwqftOFYW1hoczvDLJlSwYZvqqG9/t4U0ibIz++RtIrB1rFAkBEF3k2wB6a/ularNCMeKaBdjyEEHEP++rWJBHLI1YgD1h7rmBHLFR36puu7UCCTHvoUKBAui16GivwrddekkPmjHRvaACuHvJ/9eyusPCSRjGpkOc7xk3jQN61+ErYS0kgsQADcO2/MNBsOfK1mXnV0wUe7dp2g+DMD9sqKU3o9g56/SntGdpmi0OmPQTgOpo3As0qjloGIS9Km7aPIe+z+o0BPrW80jH79kx8Iqehbj7Qhi3X0rZAA7JzxE2b4Pz8CeeiuFjJDXXGV+Jg4w7gNkocPGyyesM6se8zuOQ2SFaDNmmfol2fdlWRJKw8r3pYAujq0he4dGn5tZpnEtjH6a/NqVFNkK19aEwbGNE1gtoBEhApIv8LSoGsynuu9hyPu47koqwXT+YWMkJhCzuJuk9k2j9IBOSPmMtiqkf5TjOWYvKl/lTpNeuSgPsDPChGMN0prlvqDYiDbCSMQRe5ei/56Fy4VmSob2LJViMSCEEQPgYqRlR5O9oY1DlzsscwVpUmwzl/p47kqr8tUaoWkJAJlZNiiIgLgiBjQTEtMNERnXVtAYsWByzerMzNdI2ACzaHRQfuoQTjgbwjrkBBFqWmretJrMumNO73YLP3S1XNO3tYUh6euwbZUYpAxnSn0BQ8yqJUYaMmKKe7xCgv4KGNP+1Y6Iygyz9vLyoDVqkFl0gfhMBvYbquZiqAxiFqa2Ed7xOR4ciMjL12wkm1txLyH415h7WrI6nYujMdk2wsRSO82I1Z9JVa5ou+CkOzREYVdhPXwCo1/b6ex1zH7sCUGln8CLbSmS8JvQZ8A0+AVlmzyU691U8Rd6X5oL703qfGEr47ZfSj6C/xj7GgqCUsap3drjPLhVKvbRXsNOpllgQL9VZF9btMJKLc3tK82xZgYAG0vFclV54dzqUoeq/n64TDZ6twV2UxUBbb1mqKgu+3pxSPoC8to2+Xn8/7WeHoJcEF/2A9qsTiNLPcJalPmiwJ297zRV9hdYdndTWjLxj+QHtr2naqrhd341JP19Bk0XxXMr974tLVzj/I8VU57/2+hxDaTtvUPr/5hKCNeXd9EKAhQmRbhHcL2KLgyl38GEKTQsYAuso/0rFFw4Pjy/aGX+lTA0kLx/p0Ya4WBtFo2XwhLvNsjddNfaMHkZKQ0ioBVdKrBcTO87Gj11P6EjRSRE3cB7wD2NdEl8nTw3nPi0TYLxD1m+TzrtCE7VtVhX4RbIa4csh3AC3ILVGcRb06nXclTxyNQEywRFQP3aTJcpt8Brfy5HeUe/WFWy+on1YUXS+4ArrCFV1ruFmFkx12oUVmc40AyHYddsuj7fdUfpebNeKlYCERO4KQ0MBrcjYFTMohDrA0ps8agnYRzvbEMgVm4pb2f+hbdbYtQ8PU7qVCU9iZRyI9j5N3nZV+InfuBzZ1sO4dds32aDsLciBqzPGo/WUfTRgx/kj7+rtzov2SrMdHSLtbTOQwHcyk56yHPnj1ZBZjQ+qNXrUlWLclNE5F+gn7eIODvjoiYJW9rK++vuc3ZNheYYUv3euFSepeJ4jmYBEiJBc0mF2zbYi9TuxdKLklbqxsNzGs8T89i/S+dD8QmvKevz8jp5JX5JBEJeFJmSD3wsNp7yD8s6hksJdugK4e/wrJmCse30cESeFOsk6NIMUG/mMHf0n4kN9AxLVEJOG4lUNzVCuEv7cfQl8xg45GzKWH9O6nE0kDDAmMSeNw2itho+5sIzMkSXpBd/JB5V3ogN9CnJg/WjzkIkh0xtYZvofIS5jMphcsLIfsn5qtUeMWaqn+W7PVSoeCLuOjj3/p3AY3bFS3NtROBdYW+Nx7iLxH86/NmSaHNtiUUdo7TYbo235rhS2H3giLrSQCn3sPsVc8ZlpgMKylGWRmTOyGizS9zEKKsJRT+KzbYTcm1lGLPLdUjQRdwZ5+yZoPvWuxxdWabODno3ni9iVPDQg+b/tlU1JuTIs0Zt5yaPulQNAu1Nd5p0pjki1I9I97Dx5uH/x86pCC0Lt6DpQZt326FnR7Cz9BBgUp0xp8JE7uxx1pB1v+9MpuaJGq2PuokMCkpnVL0dZMHj9W6hM4f5HhslTywTyOhDy2E19t/Ed8Ju5RHikVsxJ3UanB8ZC8kOo+ebQaSgpcsdS70ppYKJR/VlpIVY4sY2vf8WmQ+gVwl1ulLEFnR43SwcOxvdAVdFpNqgPU3Q7x00a59odb6uOVlCM2G6jAw8LUyS+WpO10exWMTC0mZJVFjVCUjgeR9tZHksLtcSYQBKij7nMtZaWaP9RXlX5W7aLialcdsN76nTb90QCnizX0qjdf5/012qnWpr24WmJg2FQh5haE94G54oYqlB/1ojOxH1CoN1prZW5m0KMX4Bv3SrZAj5rYE6lbzyu93IK5nBS64dveY5Uis18SW3HqnAsJEurgYnY+rFbNbVtaMjuTndNSWhuds3l3m1Ra19lhR1Zvej1KQumm2eZiMlvdA5t5qT4r8446/rzbTjEPv3HR4gse2fbM3/V0tnWB18nkKyzqiY3z4rwi5FKmxcWVvR9bnT4O1oPTZck5sBDrbtaDKpP9ghZFoalCdFsFi7lc7L7rrZ/z7tb9QVjvXOCs2Mfuw9qoEH+tnuUeh+mxuKq70TYpKW9vjSy7Ck2O8b5LbKbH5rDvLqrurpxOqt4mJSGou7tm2POlxdTFXS7kaXO4HZpszLrfxztP8+PpkH5R7Pzwww8//PDDDz/88MMP/yv8B1Phw+igFbidAAAAAElFTkSuQmCC
That is the image, stored as a base64 encoded string.
So they're not giving you a link to the image, and are instead giving you the image data directly.
Copy and paste everything after the first comma into e.g. https://www.base64decode.org/ and you'll see the picture.
This article gives a very detailed breakdown on why someone might choose to do so. One of the main reasons is to cut down the number of requests to your webserver. (clicking that link did not make a request to google, as you had already downloaded the data)
this image is just encoded using base64.
why people do this ? depend on the project. This way your page will be a bit heavier, but your image will be inside the page. If you use an URL, to load your image the browser will need to make a call.
Maybe the best call to do that, is this way you don't depend on another website to save and keep your image

Resources