When delivering images in Base64, the browser first needs to decode the Base64 encoded strings and then decode the images as well, which introduces an extra layer of unnecessary work. This not only increases your bandwidth bill, but also increases the download time. Download size increaseĪlthough Base64 is a relatively efficient way of encoding binary data it will, on average still increase the file size for more than 25%. While compression actually compresses data, encoding just defines a way how data is encoded, which brings us to the first issue. One must be careful to not mix up compression with encoding. This is useful when the storage or delivery medium does not support binary data such as when embedding an image into a database, CSS files or HTML. To put it simply, Base64 is an encoding schema used for representing binary data in a text format. To get to the answer why, we first need to establish what Base64 actually is. This works around most limits that the Base64 encoding solved and in fact means Base64 now does more bad than good. With the introduction of multiplexing that arrived with HTTP/2, web browsers have become incredibly efficient in delivering hundreds of files through a single connection. This effectively removed the need for an extra roundtrip the browser would need for each of the files. Base64 provided a way of working around that by using an already open HTTP connection to deliver images embedded directly into the HTML or CSS. This meant an image heavy website would need to queue up requests and wait for the ones before to finish. Back then, web browsers had heavy limits on the number of concurrent connections they could send to the server. In this post, I want to address why in this day and age, this is almost always a very bad idea that has been carried over from years ago. Just use with CROSS APPLY if doing a set-based operation.Unfortunately, even to this day, some optimization plugins and blogs suggest "optimizing" your images by encoding them to Base64 and including that straight into your HTML. 'T8O5IGVzdCBsZSBjYWbDqSBsZSBwbHVzIHByb2NoZT8=') This method cannot be used to convert UTF-16 into UTF-8 or some other non-SQL Server-supported encoding.īelow is an Inline-TVF encapsulating the steps shown above: GOįROM dbo.ConvertBase64EncodedUTF8ToUTF16LE( Please note that this trick only works for converting from various source encodings into UTF-16 Little Endian (as that is how the XML datatype in SQL Server stores strings internally). In a DB with a Hebrew Collation, it gets the following error:Ĭonversion of one or more characters from XML to target collation impossible specified by the default Collation of the current Database:ĬONVERT(XML, '' + In a DB with a Latin1_General Collation it works: This is to VARCHAR, but "success" will depend on the Code Page This is to NVARCHAR, which will always work:ĬONVERT(XML, '' + Où est le café le plus proche? The trick to this trick is that you need to add the declaration (typically omitted) and specify the source encoding: DECLARE NVARCHAR(500) = N'T8O5IGVzdCBsZSBjYWbDqSBsZSBwbHVzIHByb2NoZT8=' ĬONVERT(XML, VARCHAR(500) = CONVERT(VARCHAR(500), 0x4FC3B920657374206C6520636166C3A9206C6520706C75732070726F6368653F The trick is to convert the Base64 decoded bytes, in their text representation (even with incorrectly converted characters) into XML. Hence, ù is the 8-bit version of the two-byte UTF-8 sequence for ù ( 0xC3 and 0xB9).įortunately, it is possible to convert a UTF-8 encoded string into UTF-16, or even into a non-Unicode Code Page (IF the Code Page supports all characters being converted). SQL Server uses UTF-16 Little Endian only for NVARCHAR data, and even for XML. So, decoding the Base64 gives you back the original UTF-8 sequence of bytes. The problem is that you encoded a UTF-8 encoded string into Base64.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |