{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreib27tnp3msdmi3onz44ek7223kdcap7jwg5wtgwx3sehuozbmbnvm",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3mimhhrk6zqc2"
  },
  "path": "/viewtopic.php?t=33205&p=271790#p271790",
  "publishedAt": "2026-04-03T19:12:52.000Z",
  "site": "http://forum.palemoon.org",
  "textContent": "I've been looking into this problem more, and I think I managed to confirm some facts that actually snap everything into focus.\n\nThe Russian user's console encoding is CP866, but his system encoding is CP1251, just as we'd expect. The mojibake actually gives me enough info to confirm this if I look at it the right way. This... isn't a weird situation at all, and it's surprising it's not handled correctly by Python here. But after doing some local monkeypatching to force everything into CP1251, I figured out the original phrase being turned into mojibake was:\n\nПримечание: включение файла\n\nWhich I can't actually read (for obvious reasons), but can at least visually recognize the shape of as looking like proper Cyrillic character rendering.\n\nThe closest match I could reproduce by playing with Python 3 and deliberately decoding things wrong with Russian encodings was:\n\nЏаЁ¬Ґз ­ЁҐ: ўЄ«о祭ЁҐ д ©«\n\nBut on his machine, it apparently degrades a bit further with weird replacement characters and becomes:\n\n?аЁ¬Ґз -­Ё?: ўЄ<оз-­Ё? д c<\n\nMore or less.\n\nSo Python 3 is decoding CP866 as CP1251, because MSVC sees the console encoding is CP866 and outputs _that_ , but Python checks the system codepage instead of the console codepage and interprets CP866 as CP1251, resulting in the garbage the user saw. The funny thing is, MSVC is perfectly capable of outputting either CP1251 or CP866, but Python somehow isn't telling MSVC what it should be outputting here, just letting it guess wrong based on the console encoding and then taking that output and decoding based on the system encoding.\n\nSo that means... there are two basic workarounds that will probably work. One is just adding chcp 1251 to the batch file used to launch MSYS so that the terminal environment is actually 1251 like Python 3 thinks it is... and MSVC will also pick that up and get the hint that it needs to output CP1251 to avoid confusing Python. The other... is that I setup the build system on Windows to do something like:\n\nCODE:\n\n\n    encoding = \"cp%d\" % ctypes.windll.kernel32.GetConsoleCP()\n\nor similar rather than use getpreferredencoding(False).\n\nSo yes, turns out this can be fixed... the missing piece of the puzzle is that on Windows, console encoding != system encoding, and that MSVC in MSYS1 only cares about the former, while Python's encoding/locale detection only cares about the latter.\n\n* * *",
  "title": "Platform Development • Re: I created a Python 3 port of UXP out of boredom...",
  "updatedAt": "2026-04-03T19:12:52.000Z"
}