Steven D'Aprano wrote:
> glyph. He shouldn't get a UnicodeDecodeError when printing. I smell a
> bug since print shouldn't be decoding anything. (At worst, it needs to
> *encode*.)
You have correctly derived the actual traceback ;)
[Robert]
> It starts to print until it hits the wonderful charac
Robert Sjoblom wrote:
> Okay, so here's a fun one. Since I'm on a japanese locale my native
> encoding is cp932. I was thinking of writing a parser for a bunch of
> text files, but I stumbled on even printing the contents due to ...
> something. I don't know what encoding the text file uses, which
On Sat, Mar 10, 2012 at 08:03:18PM -0500, Dave Angel wrote:
> There are just 256 possible characters in cp1252, and 256 in cp932.
CP932 is also known as MS-KANJI or SHIFT-JIS (actually, one of many
variants of SHIFT-JS). It is a multi-byte encoding, which means it has
far more than 256 characte
> You can "solve" the problem by pretending the input file is also cp932 when
> you open it. That way you'll get the wrong characters, but no errors.
So I tried that:
Traceback (most recent call last):
File "C:\Users\Azaz\Desktop\CK2 Map Painter\Parser\test parser.py",
line 6, in
text = alph
On 03/10/2012 06:38 PM, Robert Sjoblom wrote:
Okay, so here's a fun one. Since I'm on a japanese locale my native
encoding is cp932. I was thinking of writing a parser for a bunch of
text files, but I stumbled on even printing the contents due to ...
something. I don't know what encoding the text
Okay, so here's a fun one. Since I'm on a japanese locale my native
encoding is cp932. I was thinking of writing a parser for a bunch of
text files, but I stumbled on even printing the contents due to ...
something. I don't know what encoding the text file uses, which isn't
helping my case either (