如何在python magic编码说明符行中指定扩展ascii（即范围（256））？

我正在使用mako模板生成专门的配置文件。其中一些文件包含扩展ASCII字符（>127），但mako哽住说，当我使用时，字符超出范围：

## -*- coding: ascii -*-

所以我想知道是否有这样的事情：

## -*- coding: eascii -*-

我可以使用它，范围为（128256）个字符

编辑：

以下是文件中有问题部分的转储：

000001b0  39 c0 c1 c2 c3 c4 c5 c6  c7 c8 c9 ca cb cc cd ce  |9...............|
000001c0  cf d0 d1 d2 d3 d4 d5 d6  d7 d8 d9 da db dc dd de  |................|
000001d0  df e0 e1 e2 e3 e4 e5 e6  e7 e8 e9 ea eb ec ed ee  |................|
000001e0  ef f0 f1 f2 f3 f4 f5 f6  f7 f8 f9 fa fb fc fd fe  |................|
000001f0  ff 5d 2b 28 27 73 29 3f  22 0a 20 20 20 20 20 20  |.]+('s)?".      |
00000200  20 20 74 6f 6b 65 6e 3a  20 57 4f 52 44 20 20 20  |  token: WORD   |
00000210  20 20 22 5b 41 2d 5a 61  2d 7a 30 2d 39 c0 c1 c2  |  "[A-Za-z0-9...|
00000220  c3 c4 c5 c6 c7 c8 c9 ca  cb cc cd ce cf d0 d1 d2  |................|
00000230  d3 d4 d5 d6 d7 d8 d9 da  db dc dd de df e0 e1 e2  |................|
00000240  e3 e4 e5 e6 e7 e8 e9 ea  eb ec ed ee ef f0 f1 f2  |................|
00000250  f3 f4 f5 f6 f7 f8 f9 fa  fb fc fd fe ff 5d 2b 28  |.............]+(|

mako抱怨的第一个字符是000001b4。如果我删除此部分，一切正常。插入该部分后，mako抱怨：

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 19: ordinal not in range(128)

无论我在魔术评论行中使用“ascii”还是“latin-1”，都是同样的抱怨

谢谢

格雷格

试试看

## -*- coding: UTF-8 -*-

或

或

取决于你真正需要什么。后两种情况相似，只是：

Windows-1252代码页与ISO-8859-1的所有代码一致，但128到159（十六进制80到9F）范围除外，其中很少使用的C1控件被替换为其他字符。Windows-28591是实际的ISO-8859-1代码页

---

其中，

ISO-8859-1

是

拉丁语-1

的正式名称

简短回答

使用cp437作为一些复古DOS乐趣的编码。所有大于或等于32位小数的字节值（127位除外）都映射到此编码中的可显示字符。然后使用cp037作为真正的trippy时间编码。然后问你自己，你如何真正知道其中哪一个是“正确的”

长答案

有一点你必须忘记：字节值和字符的绝对等价性

如今，许多基本的文本编辑器和调试工具，以及Python语言规范，都意味着字节和字符之间的绝对等价性，而实际上并不存在。

74 6f 6b 65 6e

不是“令牌”。此对应关系仅对ASCII兼容字符编码有效。在EBCDIC中，“令牌”对应于字节值

a39698595

因此，虽然Python 2.6解释器愉快地将

'text'==u'text'

计算为

True

，但它不应该这样做，因为它们仅在ASCII或兼容编码的假设下是等效的，即使这样，它们也不应该被视为相等的。（至少

'\xfd'==u'\xfd'

为

False

并为您的尝试提供警告。）Python 3.1将

'text'==b'text'

计算为

False

。但是，即使解释器接受这个表达式，也意味着字节值和字符的绝对等价，因为表达式

b'text'

被解释器理解为“当您将ASCII编码应用于

'text'

时得到的字节字符串”

据我所知，当今广泛使用的每种编程语言在其设计中都隐含着ASCII或ISO-8859-1（拉丁语-1）字符编码。在C语言中，

char

数据类型实际上是一个字节。我看到一个Java1.4VM，其中构造函数

Java.lang.String（byte[]data）

采用ISO-8859-1编码。大多数编译器和解释器假定源代码采用ASCII或ISO-8859-1编码（有些允许您更改）。在Java中，字符串长度实际上是UTF-16代码单位长度，这对于

U+10000

及以上的字符来说是错误的。在Unix中，文件名是根据终端设置解释的字节字符串，允许

打开（'a\x08b'，'w'）。写入（'Say my name！'）

因此，我们都接受过训练，并受到我们学会信任的工具的制约，相信“A”是0x41。但事实并非如此'是一个字符，0x41是一个字节，它们根本不相等

一旦你在这一点上变得开明，你将不会有问题解决你的问题。您只需确定软件中的哪个组件对这些字节值采用ASCII编码，以及如何更改该行为或确保出现不同的字节值

---

注：“扩展ASCII”和“ANSI字符集”这两个短语用词不当。

试着用挑剔的眼光检查数据：

000001b0 39c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce9 000001c0cf d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de 000001d0df e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee 000001e0ef f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe 000001f0ff5d 2b 28 27 73 29 3f 22 0a 20 20 20 |]+（'s）？” 00000200 20 74 6f 6b 65 6e 3a 20 57 4f 52 44 20 20 20 20 |标记：单词|
00000210 20 22 5b 41 2d 5a 61 2d 7a 30 2d 39c0 c1 c2|“[A-Za-z0-9…|
00000220c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf d0 d1 d2 00000230d3 d4 d5 d6 d7 d8 d9 da db dc dd de df e0 e1 e2 00000240e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef f0 f1 f2 00000250f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff5d 2b 28 | | | | |

粗体字的内容是两个批次（从0xc0到0xff的每个字节都包括在内）。您似乎有一个二进制文件（可能是一个已编译的正则表达式转储），而不是文本文件。我建议您将其作为二进制文件读取，而不是将其粘贴到Python源文件中。您还应该阅读mako文档以了解它所期望的内容

在查看转储文件的文本部分后更新：您很可能能够用仅ASCII正则表达式来表达这一点，例如，您将有一行包含

token: WORD "[A-Za-z0-9\xc0-\xff]+(etc)etc"

---

扩展ASCII没有标准化（这就是为什么它被称为“扩展”）。

## -*- coding: cp1252 -*-

token: WORD "[A-Za-z0-9\xc0-\xff]+(etc)etc"