• (nodebb)

    "Item Description must not match last 10 passwords."

  • Smithers (unregistered)

    Paper mojibake is just what happens when you take normal mojibake and print it. Although I suppose it gets more interesting if it is, as Peter suggests, actually caused by printing instead of simply being wrong on screen before it was printed.

    It's not quite illuminated manuscript tier, but Wikimedia Commons has a nice example of a handwritten mojibake as the address on a postcard. https://commons.wikimedia.org/wiki/File:Card_with_a_cyrillic_address_in_wrong_encoding.jpeg (TRWTF is the description saying it was sent to China when the last address line says Russia.)

    I'm also sure they used to have an image where someone had hand-corrected a mojibake address directly underneath, but it seems to have vanished.

  • KeyJ (unregistered)

    The UTF-8-as-ISO8859-1 mojibake is seen quite frequently in Germany (and I guess all across Europe). Also fun: Some receipt printers or POS displays seem to use good ol' codepage 437, and show things like "Rⁿckgeld" instead of "Rückgeld" (= change).

  • Anonymous') OR 1=1; DROP TABLE wtf; -- (unregistered)

    If you google "Ode to a shipping label", there's a pretty fantastic example of a shipping label that went through about 3 levels of mojibake and then got printed out, and a nice poem to go along with it.

  • (nodebb)

    I remember ASCII mojibake back in the day between the US and UK caused by the two sides of the Atlantic using the name "pound" for different symbols. My C code ended up full of £defines whenever I printed it out...

  • KeyJ (unregistered)

    Regarding what dkf wrote about # vs. £ in ASCII: Again in Germany, we had something way worse in the form of DIN 66003 - a (standardized!) 7-bit encoding based on ASCII that replaced @ [ \ ] { | } ~ by § Ä Ö Ü ä ö ü ß. As you can imagine, this made most code unreadable:

    int foo(int* x) ä putc('Ön'); return xÄ0Ü ö ßxÄ1Ü; ü
    
  • mitch (unregistered)

    The mangled date sort might be internally comparing a string representation like "Tuesday, October 3rd 2023". Have fun debugging that (guess how I know).

    Too lazy to check if that is the cause here.

  • matt (unregistered)

    Preceded, kind submitter. Proceeded (after, from) is practically the opposite.

  • Tim (unregistered) in reply to dkf

    in 7-bit ASCII there is no £ symbol so British printers and displays used to print hex 23 (# symbol) as £

    I'm not sure if American use of the word "pound" to describe the # symbol is coincidence

  • Officer Johnny Holzkopf (unregistered) in reply to KeyJ

    Multiple-baked classic: Schlatildefacterstrasse (Schlüterstrasse / Schlüterstraße) in Berlin.

  • (nodebb) in reply to dkf

    I remember ASCII mojibake back in the day between the US and UK caused by the two sides of the Atlantic using the name "pound" for different symbols. My C code ended up full of £defines whenever I printed it out...

    How exactly does that happen? Those are normally two distinct characters. I would have thought that a printer would use the characters sent? Was this an encoding problem from the application sending the job, or a spooling problem? This just seems bizarre.

    I've been printing all sorts of things since the 80s and haven't seen that happen outside of broken drivers, misbehaving software, or just using the wrong daisy wheel.

  • MRAB (unregistered) in reply to gordonfish

    Back in those days, there were variants of ASCII.

    ASCII-UK had '£' in place of '#' (Britons need '£' but don't need '#'), ASCII-FR (France) had that change plus some other replacements for required characters, ASCII-ES (Spain) had that change plus some other replacements for required characters, and so on. (I once saw an advert in a computer magazine where the price didn't say '£', but 'Ł', basically 'L' with a slash through it!)

    Only later did code pages become a thing, with 8 bits/character, so there could be 128 standard ASCII characters plus 128 additional characters, and multiple western-European countries could use the same encoding.

  • (nodebb) in reply to gordonfish

    How exactly does that happen? Those are normally two distinct characters. I would have thought that a printer would use the characters sent? Was this an encoding problem from the application sending the job, or a spooling problem? This just seems bizarre.

    @MRAB may already have answered the question, but in essence, the printer did use the characters sent. The application sent it a '#' ("pound" in US parlance), and the printer printed a '£' ("pound" in UK parlance) because DIP(1) switch(2) 2-7 (or whatever, depending on the manufacturer and model) was set for UK usage, at a time when there wasn't a reliable way of encoding '£', which isn't a standard ASCII character.

    (1) Dual Inline Package.

    (2) See also the Dips Witch: https://mocagh.org/ea/standingstoneuk-manual.pdf

  • ecm (unregistered) in reply to Smithers

    I'm also sure they used to have an image where someone had hand-corrected a mojibake address directly underneath, but it seems to have vanished.

    In Dylan Beattie's talk "Plain Text" he presents a Russian address that got mojibaked by email transmission. Like you suggested, it shows the address corrected on the (paper) envelope.

    Time stamps are 22:00 for the story and 23:35 for the photo of the physical package. Video is at https://youtube.com/watch?v=gd5uJ7Nlvvo

  • (nodebb) in reply to MRAB

    Thanks for that historical refresher, really takes me back.

    where the price didn't say '£', but 'Ł', basically 'L' with a slash through it!)

    An 'L' with a shash through it is also a character in the Polish alphabet, which makes me wonder if they could have used the wrong encoding (perhaps unaware) and couldn't find the proper '£' symbol so they just went with the closest match.

  • (nodebb) in reply to Steve_The_Cynic

    Thanks, that makes sense. Must have been a tad annoying for any C/C++ programmers wanting to print out their code with a ton of preprocessor macros, or those writing Bourne based shell scripts and such with lots of comments, who didn't know how to adjust those DIP switches.

  • (nodebb)

    In the Azure listing, why are the dates in green not aligned with the baseline of the rest of the GUID line (except the first one for the current GUID) , and one of the gray separators is missing?

    It's as if the dates had been crudely moved around in Paint.

  • (nodebb) in reply to Ralf

    The image might also have been edited just to make the dates visible in the screenshot (maybe they were too far to the right, or only shown in a tooltip). The older versions are sorted alphabetically, and the probability of both the alphabetical and chronological sorting being the same is very low.

  • Brisbe (unregistered)

    I mean, a 0% gain in a crypto currency is out-performing the crypto market...

  • markm (unregistered)

    Historically, the British pound symbol was an L for Libra with a slash through it. This was invented in the 1600's. But in the Blackletter type that was used in English until the 1600's, capital L used to have a half-loop on top and a bent vertical stroke. When the Bank of England regularized the use of the slash-L symbol on their banknotes, they chose to use the older L to make the symbol stand out from the simplified "modern" fonts.

  • (nodebb) in reply to Steve_The_Cynic

    @MRAB may already have answered the question, but in essence, the printer did use the characters sent. The application sent it a '#' ("pound" in US parlance), and the printer printed a '£' ("pound" in UK parlance) because DIP(1) switch(2) 2-7 (or whatever, depending on the manufacturer and model) was set for UK usage, at a time when there wasn't a reliable way of encoding '£', which isn't a standard ASCII character.

    Oh Gawd. That brings back memories. Bad memories.

  • (nodebb) in reply to Smithers

    (TRWTF is the description saying it was sent to China when the last address line says Russia.)

    Fixed. (Nice thing about Wikipedia is that anyone can edit.)

Leave a comment on “Tomorrow, and tomorrow”

Log In or post as a guest

Replying to comment #:

« Return to Article