upvote

points

by cwizou2 hours ago |
comments
upvoteby wvbdmp2 hours ago|
next
[-]
Yikes, mojibake in 2021.

edit: actually, how did that happen? The apostrophes show up correctly, they’re just all preceded by a  that doesn’t seem to represent anything?

reply
upvoteby layer82 hours ago|
parent|
next
[-]
The page is declared as ISO 8859-1, but the actual bytes of the text appear to be UTF-8. In UTF-8, characters from U+0080 to U+00AF happen to be encoded as C2 <codepoint value>. For example, U+0092 is encoded as C2 92.

C2 in ISO 8859-1 is ””. U+0092 is the control code Private Use 2 in Unicode, and 92 is the same in ISO 8859-1. However, the standard Western Windows code page 1252 extends ISO 8859-1 by assigning “’” (right single quotation mark) to 92.

HTML5/WHATWG requires an ISO 8859-1 charset declaration to be interpreted as Windows-1252 (https://blog.whatwg.org/the-road-to-html-5-character-encodin...), hence the displayed result is “Â’”.

The original Windows-1252 content must have previously been converted to UTF-8 under the assumption that the source is ISO 8859-1, i.e. mapping 92 to U+0092 (Private Use 2) instead of to U+2019 (Right Single Quotation Mark). The resulting UTF-8 encoding was placed in the web page, which however is declared as ISO 8859-1.

reply
upvoteby wvbdmp1 hours ago|
parent|
next
[-]
Delicious, thank you!
reply
upvoteby layer81 hours ago|
parent|
[-]
I edited my post after verifying the actual bytes, it turned out to be slightly more complicated.
reply
upvoteby well_actulily1 hours ago|
parent|
[-]
The double-encoding path gets you there too: the original UTF-8 \xE2 \x80 \x99 mis-decoded as iso-8859-1 or Windows-1252 and saved back as UTF-8 gives \xC3 \xA2 \xC2 \x80 \xC2 \x99, which in Windows-1252 renders as ’. A WYSIWYG cleanup replacing that mojibake with the Windows-1252 ' (byte 0x92) and saving back as UTF-8 gets you to \xC2 \x92 on disk.

Edit: Although maybe that's not the most parsimonious explanation.

reply
upvoteby root-parent1 hours ago|
parent|
prev|
[-]
this one does g11n....
reply
upvoteby 1 hours ago|
parent|
prev|
next
[-]
deleted
reply
upvoteby netsharc2 hours ago|
parent|
prev|
[-]
They're probably Microsoft's "Smart Quotes", which are Unicode. They were presumably stored in UTF-8 but retrieved as ASCII (or ISO-8859-1).
reply
upvoteby stefan_2 hours ago|
prev|
next
[-]
The report on that incident says there was a hardware modification to make this impossible, to be incorporated before Jan 2023.

(It also says this happened to Boeing in 2018 and they ignored it, of course)

reply
upvoteby cwizou2 hours ago|
parent|
next
[-]
I missed that part, and since it's a newly delivered plane (this January), it's safe to assume the mitigation was in place. Preliminary report will be interesting here.
reply
upvoteby dheera57 minutes ago|
parent|
prev|
[-]
Wonder why they don't just grab a huge permanent Sharpie and write in huge letters "Do not insert pin here" on one hole and "Insert pin here" on the other hole.

I'm actually serious, it seems to me they resist these kind of short-term helpers that would save lots of injuries.

reply
upvoteby stefan_55 minutes ago|
parent|
[-]
I think the report says they just put a little cover on the hole where the pin shouldn't go (but can).
reply
upvoteby dheera31 minutes ago|
parent|
[-]
Sure, but they probably took 3 years to have a design review, an executive review, some firings and layoffs, re-hire, orientation, a sprint planning meeting, a sprint retro, a post mortem, an OKR meeting, a KPI meeting, an all-hands, and then the cover probably got stuck in customs with tariffs, and then the tolerances probably weren't correct.

Meanwhile the sharpie would take 1 minute.

reply
upvoteby netsharc2 hours ago|
prev|
[-]
The aircraft is 1 year old and was delivered in January...

But, fucking hell, apparently Boeing "engineers" are so dumb they never learned about Murphy's law.

reply
upvoteby 866-RON-0-FEZ27 minutes ago|
parent|
[-]
I bet you would blame the automotive engineers too after reversing your car through the garage door.
reply