It's a simple solution. Sure, it is still possible for something to slip through that looks similar to something bad. But the potential to strongly offend is greatly reduced.
1,355 karma · joined September 30, 2013
It's a simple solution. Sure, it is still possible for something to slip through that looks similar to something bad. But the potential to strongly offend is greatly reduced.
https://manishearth.github.io/blog/2017/01/14/stop-ascribing...
Here is a short list of MySQL magic numbers for column types.
Space efficiency and performance:
- VARBINARY(255) / VARCHAR(255) with single-byte character sets: 255 is the biggest size that requires only 1 byte of storage overhead.
- VARCHAR(63) with utf8mb4: 63 is the biggest size that requires only 1 byte of storage overhead because 64 × 4 > 255.
- VARBINARY(512) / VARCHAR(512): the largest columns of their types that are compatible with in-memory temporary tables when UNION or UNION ALL is used. Larger columns will use on-disk tables instead.
Limitations of 3072-byte index keys (innodb_large_prefix enabled; default for MySQL >= 5.7.7):
- VARBINARY(3072) / VARCHAR(3072) with single-byte character sets: 3072 is the biggest size that can be fully indexed.
- VARCHAR(768) with utf8mb4: 768 is the biggest size that can be fully indexed because 769 × 4 > 3072.
Limitations of 767-byte index keys (innodb_large_prefix disabled; default for MySQL <= 5.7.6):
- VARBINARY(767) / VARCHAR(767) with single-byte character sets: 767 is the biggest size that can be fully indexed without enabling innodb_large_prefix.
- VARCHAR(191) with utf8mb4: 191 is the biggest size that can be fully indexed without enabling innodb_large_prefix because 192 × 4 > 767. This is what the OP is about. VARCHAR(768), mentioned above, should be more relevant nowadays.
Different magic numbers come in if you are using VARCHAR with utf8 (the MySQL character set, not the real UTF-8). I'll let you work out the details, but the magic numbers are 85, 255, 1024.
The most useful knowledge I've acquired about building things on the internet came not from framework/library/API docs, but from RFCs published by the IETF.
Industries that are more reliant on non-free standards are surely worse off because of it.
New artistic styles often come from the limitations of their mediums. I expect the limitations of color e-ink to be no different.
> Check out https://example.com/thing . They've got...
Let's say we were serious about solving this problem (without adopting a strategy like mine above). We would need a set of rules for plaintext-safe URLs. It would comprise:
- An extension to the URL syntax to specify the subset of URLs that are plaintext safe. It might be as simple as a list of punctuation characters that cannot appear at the end of a URL (unless they are percent encoded).
- Guidelines and test vectors for implementers of URL identification algorithms.
- Guidelines for content authors. E.g., "The only characters that may immediately follow a URL are..."
- A recommendation for web developers to ensure plaintext safefy when creating new URLs.
I agree, but browsers should use console warnings to report when they resort to font synthesis or weight substitution. That would go a long way to help web developers understand this problem.
Similarly, console warnings to report character substitution when a needed character is not present in the font-family list would be useful.
In general, I want more transparency from text rendering engines when they encounter something that may not be what a professional designer or typesetter would want. The opacity of today's engines breeds ignorance among their users (web developers).
> Investigators said that because the pilots flew the second circuit at 1500ft, the Electronic Centralised Aircraft Monitor (ECAM) had not reset on the second approach and it did not display a landing memo at 950ft.
“The absence of the landing memo should have prompted the flight crew to perform the items of the landing checklist as a ‘read-and-do’ checklist,” it said.
Like the lock icon in a browser’s address bar, it is not effective to rely on the user to notice the absence of an indicator.
Yesterday I had to go through an inconvenient password reset because my bank no longer allows spaces in passwords. The password input inconspicuously removes spaces after you type them. It took several failed attempts before I realized what was happening.
https://webmasters.googleblog.com/2019/07/a-note-on-unsuppor...
Since the CGI "protocol variables" are actually environment variables, it creates a namespace collision and an injection opportunity for environment variables beginning with "HTTP_".
It's visually more distinct than libcrurl while retaining an appropriate resemblance to libcurl.
One could argue that some resemblance in name is a good thing for curl. But libcrurl is too close and likely to cause confusion.
https://splinternews.com/how-an-internet-mapping-glitch-turn...
In those cases there were negative consequences because low-precision markers were not displaced.
You can still have this with encodings as data types.
Encoding is definitely a concern at the boundary, but to say that it is a concern only at the boundary is too simplistic. What if you want to save the cost of converting encodings from that which was input at the boundary? And at some point data will have to leave your application, and this often requires munging text in a number of encodings.
> So using a type system to specify encodings isn't really helpful
Imagine an error at compile time when you accidentally try to append an ISO-8859-1 string to a UTF-8 string.
Strings as they commonly work are leaky abstractions which for decades have bred confusion among programmers over how to handle text properly.
Text/character encoding bugs are a matter of type safety. I believe most of the text encoding bugs in the history of software could have been avoided if we used our type systems to handle text encodings explicitly.
UTF-8, UTF-16, UTF-32, Windows-1252, ISO-8859-1, US-ASCII, et al.; these should be our essential concrete data types. The concept of a string should just be an abstraction over them for polymorphism.
At no point in the lifecycle of a piece of textual data should there ever be any question over how it is encoded. So why don't we let our type systems do this bookkeeping for us?
The most important thing that could happen would be for a popular auto-correct tool to start substituting it for '?!' and '!?'. MS Word would be ideal.
People would start to get familiar with it when reading other's works. And when authoring, people tend to treat auto-correct like an authority and learn from it. I suspect something similar happened with the ellipsis character in place of three periods.
I have a hunch it would catch on easier in the non-English markets, which may be slightly more accustomed to the inconvenience of using glyphs that aren't always available on every keyboard.
Next, it needs to be included in mobile keyboards. I don't know about iOS, but I can't find it in Gboard for Android.
We could start logging requests and submitting pull requests along those lines.
Now we may not want a viral event. No hashtag campaigns, lest we awaken a louder dissenting crowd. I think the Trojan Horse is a better strategy at first.
You can test the difference yourself by toggling JavaScript in your browser.
I played it with a coworker during breaks in an environment that IT had locked down, but they didn't block Excel.