41–50 of 71 posts
I'm looking for an efficient encoding that is guaranteed to not contain certain substrings, such as improper language.
It's an interesting technical exercise, but I don't think this is the right approach for optimizing HTML load times. If the goal is to reduce latency for small images, wouldn't it make it more sense to extend data URIs so the same base64 string can be referenced in multiple places? Actually, as HTTP2 can effectively return multiple resurces in the answer of one request, do we still need embedded images for latency re…
Compression takes care of exactly this.
Also, there are still cases where compression cannot be applied, e.g. if a script naively queries innerHTML. (This wouldn't affect loading time but it could inflate the page's RAM unnecessarily)
meanwhile the Unicode consortium has been hard at work since 1991 to make it possible to encode up to 2.8 MB -- more than enough for most images, short videos, or many PDF files -- in a single character.
Earlier quoted context omitted.
Compression takes care of exactly this.
Unless compression cannot be used: https://news.ycombinator.com/item?id=13049898 Also, there are still cases where compression cannot be applied, e.g. if a script naively queries innerHTML. (This wouldn't affect loading time but it could inflate the page's RAM unnecessarily)
A lot of people have experimented with a lot of different ways of encoding binary data as printable text. Wikipedia has a list of different encoding schemes[0]. The most efficient one is yEnc[1]. Still the simplest ones such as base64 or good old hex may actually work better once compression comes into the picture. [0]: https://en.wikipedia.org/wiki/Binary-to-text_encoding [1]: https://en.wikipedia.org/wiki/YEnc
Does anyone else find it odd that both Base-122 was created with the web in mind. And As §3 shows, base-122 is not recommended to be used on gzip compressed pages, which is the majority of served web pages. Occur in just a few lines from each other? I get there's more use cases like email and such but if you're going to create something for the web but it can't be used on the majority of web pages that seems like a f…
> Base-122 encoded strings contain characters which did not seem to play well with copy-pasting.
A very important part of web development is being able to manipulate text documents. It seems that using UTF-8 in more places can reveal cracks in implementations for browsers/DE's/editors/terminals/etc.
Base85 is between base64 and base122, while using printable characters. Any statistics of compressed base85?
I'm looking for an efficient encoding that is guaranteed to not contain certain substrings, such as improper language.
The use of codepoints below 32 (space, start of what's usually considered "printable") makes me a bit hesitant. A lot of systems won't preserve those characters. Base85 is a more efficient alternative to base64, and doesn't use that lower range: https://en.wikipedia.org/wiki/Ascii85
Stick with the characters that nearly everyone assumes could legitimately come up in a document and your chances of running afoul of some "creative genius" who decided "Hey its unprintable so no one will try to print it, but when I do print it I want this thing to happen..."
[1] http://grepcode.com/file/repository.grepcode.com/java/root/j...