481–490 of 559 posts
Earlier quoted context omitted.
As late as 2020 I encountered a European shop that couldn't handle my Swedish address that had an å in it. That is, it accepted the address on the website, but then it got screwed in the delivery. I'm still in awe.
UPS sent me a parcel and replaced ä with ae
Earlier quoted context omitted.
IDNA has been a standard for 20 years. You can already do this. However, they are IRI, not URI, and IRI support is sparse because of its dubious broader value.
Note that the second link is a table of Internationalized ccTLDs and .jp is not yet on it. So you can't do it yet.
Earlier quoted context omitted.
IDNA has been a standard for 20 years. You can already do this. However, they are IRI, not URI, and IRI support is sparse because of its dubious broader value.
“Dubious broader value” is a great way to tell you’re United-Statesian without saying you’re United-Statesian.
I think there's a security problem with this command. The command does not verify it's called as [xn--ts9h], it really needs to verify args[0] equals the name of the command, otherwise you could call it though a link or mapping, etc. The article states that the name is important for security, so I'm submitting this bug as critical.
https://github.com/Xe/xn--ts9h/commit/861f8fa86ef58cdc371b0e... I will make a new set of packages tomorrow because I am tired
Earlier quoted context omitted.
Care to elaborate? Are you suggesting that a better version of Unicode does not allow combining characters? [1] Some languages have an explosive amount of characters if you regard each possible modifier in combination with each base character, some of which aren't practically used. By allowing the composition of modifiers and base letters, all the historically used ones are available, and all the odd ones are technic…
One solution to allow combination characters, but only in a normalised way is to only allow one of the same modifiers, and only allow modifiers in the normal order. This makes parsing Unicode quite complex. If you allow for non-normalised Unicode and write a post-processor that normalises, you get to status quo. So either you are suggesting to disallow non-normalised Unicode with the current definition, or something…
The point would be to have only one canonical binary representation. A representation that is also free of all kinds of "compromises" which are only there for legacy reasons…
Additionally the whole madness should be resolved that Unicode mixes content, representation, and layout (especially as it fails miserably at all of them).
Than there are the problems that Unicode is actually incapable of representing all kinds of scripts. (Just think for example about stuff written top-to-bottom, and not LTR / RTL). Some "unimportant" things like Math can't be represented in Unicode also…
And I won't even talk about the issue that the committee was taken over by some political movement, namely the woke fraction.
I think it's actually a kind of joke that we still didn't mange to invent some sane text format for computers. Unicode doesn't cut it.
But frankly I admit that we won't get anywhere — as even Unicode is full of madness it works "good enough" by now through even more layers of madness on top, so we won't get rid of it ever again. That ship sailed I fear. Still I can't stop banging my head when I hear about things like issues with normalization, something that shouldn't exist in the first place in a sane world.
[flagged]
Earlier quoted context omitted.
I worked at a place that did this, case-insensitive passwords and all. The worst part? They had unencrypted production database backups on all of their dev laptops, the majority of which left the premises after every night. I couldn't get a figure of how many laptops were lost but statistically speaking there had to have been at least 3 lost laptops with unencrypted production database backups per year using industry…
I have former employers who still didn't fix the security bugs I uncovered years after. I don't know what makes a manager turn off snooze on open PRs for fixing blatant holes. But if you've got that skill, it can take you far!
The first time I saw perfectly valid Unicode take down an RSS reader (in ~2003), it was an ü that did it. I have taken to calling that the kaboomlaut in unit tests.
Umlauts are in Latin1, so it’s pretty shoddy software that couldn’t deal with that.
> They wrote the program in C They wrote it in 1980 for unix; what exactly would you like them to have used? > (as far as I can tell) have no intention of rewriting it in Rust Since it will be less than a paragraph before you start ranting about how "obscure targets that nobody uses won't be able to leech off of the rest of the ecosystem by holding back any chance to let us have a modicum of nice things", I trust you…
Pascal