Maison  >  Article  >  développement back-end  >  Introduction détaillée au codage de caractères Python

Introduction détaillée au codage de caractères Python

高洛峰
高洛峰original
2017-03-28 17:19:581426parcourir

1. Codage des caractèresIntroduction

1.1. ASCII

ASCII (American Standard Code pour Information Interchange) est un codage sur un seul octet. Au début, il n'y avait que l'anglais dans le monde informatique, et un seul octet peut représenter 256 caractères différents. tous les caractères anglais et de nombreux symboles de contrôle, mais l'ASCII n'en utilise que la moitié (en dessous de x80), ce qui constitue également la base de la réalisation du MBCS

Cependant, dans le monde informatique, il y eut bientôt d'autres langages. Dans le monde, l'ASCII à un octet ne pouvait plus répondre à la demande. Plus tard, chaque langage a développé son propre codage car il y avait trop peu de caractères pouvant être représentés par un seul octet et il fallait également qu'il soit compatible avec l'ASCII. encoding. , donc ces encodages utilisent plusieurs octets pour représenter des caractères, tels que GBxxx, BIGxxx, etc. Leur règle est que si le premier octet est inférieur à x80, il représente toujours des caractères ASCII et s'il est supérieur à x80, il suit The ; l'octet suivant ensemble (deux octets au total) représente un caractère, puis saute l'octet suivant et continue à juger

Ici, IBM a inventé un concept appelé Code Page pour les coder. Tous sont inclus dans le sac et attribués. les numéros de page. GBK est la page 936, qui est CP936. Par conséquent, CP936 peut également être utilisé pour représenter GBK (Multi-Byte Character

Set

). Jusqu'à présent, tout le monde a utilisé le double octet. il est donc parfois appelé DBCS (Double-Byte Character Set). Il doit être clair que MBCS n'est pas un encodage spécifique. Il est défini selon vous dans les différentes régions de Windows, MBCS fait référence à différents encodages et MBCS ne peut pas être utilisé comme. l'encodage sous

Linux

. Sous Windows, vous ne pouvez pas voir les caractères MBCS car Microsoft utilise ANSI pour effrayer les gens afin d'être plus à la mode, l'encodage ANSI dans la boîte de dialogue Enregistrer sous du Bloc-notes est MBCS. en même temps, dans les paramètres régionaux par défaut de Windows en chinois simplifié, il fait référence à GBK Plus tard, quelqu'un a commencé à penser que trop de codes avaient rendu le monde trop complexe et m'avaient fait mal à la tête, alors. nous nous sommes tous assis ensemble et avons réfléchi et avons trouvé une méthode : les caractères de toutes les langues doivent être représentés par le même jeu de caractères Il s'agit de

La norme Unicode originale UCS-. 2 utilise deux octets pour représenter un caractère, vous pouvez donc souvent entendre qu'Unicode utilise deux octets pour représenter un caractère. Mais peu de temps après, certains ont estimé que 256*256 était trop peu, et ce n'était toujours pas suffisant, alors est apparu le standard UCS-4, qui utilise 4 octets pour représenter un caractère, mais celui que nous utilisons le plus est toujours UCS-2. .

UCS (Unicode Character Set) n'est qu'un tableau de points de code correspondant aux caractères. Par exemple, le point de code du mot "汉" est 6C49. UTF (UCS Transformation Format) est responsable de la transmission spécifique et du stockage des caractères. C'est très simple au début, utilisez simplement le point de code UCS pour enregistrer directement, qui est UTF-16. Par exemple, "Han" peut être enregistré directement en utilisant x6Cx49 (UTF-16-BE), ou. dans l'autre sens. Sauvegarde x49x6C (UTF-16-LE). Mais les Américains ont le sentiment qu'ils ont subi une grosse perte après l'avoir utilisé. Dans le passé, les lettres anglaises n'avaient besoin que d'un octet pour être sauvegardées, mais maintenant cela devient deux octets après avoir mangé un gros pot, et la consommation d'espace a doublé... Donc UTF -8 Sorti de nulle part.

UTF-8 est un codage très délicat, plus précisément, il est de longueur variable et compatible avec les caractères ASCII représentés par 1 octet. Cependant, ce qui est omis ici doit être extrait d'autres endroits. Vous devez avoir entendu dire que les caractères chinois en UTF-8 utilisent 3 octets pour être sauvegardés, n'est-ce pas ? Les caractères enregistrés sur 4 octets sont encore plus larmoyants... (Veuillez rechercher des détails sur la façon dont UCS-2 est devenu UTF-8)

Une autre chose qui mérite d'être mentionnée est la BOM (Byte Order Mark). Lorsque nous enregistrons le fichier, l'encodage utilisé dans le fichier n'est pas enregistré. Lorsque nous l'ouvrons, nous devons nous souvenir de l'encodage utilisé lors de l'enregistrement et l'ouvrir en utilisant cet encodage. (Vous voudrez peut-être dire que le Bloc-notes ne vous permet pas de sélectionner l'encodage lors de l'ouverture du fichier ? Vous pourriez aussi bien ouvrir le Bloc-notes d'abord, puis utiliser Fichier-> Ouvrir pour voir) UTF introduit la nomenclature pour représenter son propre encodage. l'un d'eux, ce qui signifie que l'encodage utilisé pour le texte à lire ensuite est l'encodage correspondant :

BOM_UTF8 'xefxbbxbf'

BOM_UTF16_LE 'xffxfe'

BOM_UTF16_BE 'xfexff'

Tous les

éditeurs

n'écriveront pas la BOM, mais même sans BOM, Unicode peut toujours être lu, mais comme l'encodage MBCS, l'encodage spécifique doit être spécifié séparément, sinon le décodage échouera.

Vous avez peut-être entendu dire que l'UTF-8 ne nécessite pas de nomenclature. Ce n'est pas vrai, mais la plupart des éditeurs lisent UTF-8 comme encodage par défaut lorsqu'il n'y a pas de nomenclature. Même le Bloc-notes, qui utilise ANSI (MBCS) par défaut lors de l'enregistrement, utilise d'abord le codage de test UTF-8 lorsque lit le fichier S'il peut être décodé avec succès, UTF-8 est utilisé pour le décodage. Cette approche maladroite du Bloc-notes a provoqué un BUG : si vous créez un nouveau fichier texte et entrez "姹姧" puis l'enregistrez en utilisant ANSI (MBCS), il deviendra "Han a" lorsque vous l'ouvrirez à nouveau. essayez-le :)

2. Problèmes d'encodage en Python2.x

2.1 str et unicode

Str et unicode sont tous deux des sous-classes de basestring. . À proprement parler, str est en fait une chaîne d'octets, qui est une séquence d'octets codés en Unicode. Lorsque vous utilisez la fonction len() pour la chaîne '汉' encodée en UTF-8, le résultat est 3, car en fait, '汉' encodée en UTF-8 == 'xE6xB1x89'.

unicode est la vraie chaîne, qui est obtenue en décodant la chaîne d'octets str en utilisant le codage de caractères correct, et len(u'汉') == 1.

Jetons un coup d'œil aux deux méthodes d'instance de chaîne de base encode() et decode() Après avoir compris la différence entre str et unicode, ces deux méthodes ne seront plus confondues :

# coding: UTF-8
 
u = u'汉'
print repr(u) # u'\u6c49'
s = u.encode('UTF-8')
print repr(s) # '\xe6\xb1\x89'
u2 = s.decode('UTF-8')
print repr(u2) # u'\u6c49'
 
# 对unicode进行解码是错误的
# s2 = u.decode('UTF-8')
# 同样,对str进行编码也是错误的
# u2 = s.encode('UTF-8')
Il convient de noter que bien qu'il soit erroné d'appeler la méthode encode() sur str, en fait Python ne

lancera pas d'exception, mais renverra une autre str avec le même contenu mais un identifiant différent pour ; unicode Il en va de même pour l'appel de la méthode decode(). Je ne comprends vraiment pas pourquoi encode() et decode() ne sont pas placés respectivement en unicode et str mais les deux sont placés en basestring. Mais puisque c'est le cas, faisons attention à ne pas faire d'erreurs.

2.2. Déclaration d'encodage de caractères

Si des caractères non-ASCII sont utilisés dans le fichier de code source, une déclaration d'encodage de caractères doit être faite en tête du fichier, comme suit :

#-*- coding: UTF-8 -*-
En fait, Python vérifie uniquement le #, le codage et la chaîne d'encodage, d'autres caractères sont ajoutés pour l'apparence. De plus, il existe de nombreux codages de caractères disponibles en Python et de nombreux alias qui ne sont pas sensibles à la casse. Par exemple, UTF-8 peut être écrit sous la forme u8. Voir http://docs.python.org/library/codecs.html#standard-encodings.

Une autre chose à noter est que l'encodage déclaré doit être cohérent avec l'encodage utilisé lors de l'enregistrement réel du fichier, sinon il y a de fortes chances que des exceptions d'analyse du code se produisent. Les IDE d'aujourd'hui gèrent généralement cette situation automatiquement. Après avoir modifié la déclaration, elle sera enregistrée dans l'encodage déclaré, mais les contrôles de l'éditeur de texte doivent être prudents :)

2.3 Lire et écrire des fichiers

Intégré Lorsque la méthode open() ouvre un fichier, read() lit str Après la lecture, vous devez utiliser le format d'encodage correct pour décoder(). Lors de l'écriture de (), si le paramètre est Unicode, vous devez utiliser l'encodage que vous souhaitez écrire dans encode(). S'il s'agit d'une chaîne dans d'autres formats d'encodage, vous devez d'abord utiliser l'encodage de la chaîne pour decode(). et convertissez-le en Unicode. Utilisez ensuite l'encodage écrit pour encode(). Si vous transmettez Unicode directement en tant que paramètre à la méthode write(), Python encodera d'abord en utilisant l'encodage de caractères déclaré dans le fichier de code source, puis écrira.

De plus, le module codecs fournit une méthode open(), qui peut spécifier un encodage pour ouvrir le fichier. Le fichier ouvert à l'aide de cette méthode lira et renverra l'unicode. Lors de l'écriture, si le paramètre est unicode, il sera encodé selon l'encodage spécifié lors de open() puis écrit s'il est str, il sera décodé en unicode selon l'encodage de caractères déclaré dans le fichier de code source avant d'effectuer l'exécution ; opération précitée. Par rapport à l'open() intégré, cette méthode est moins sujette aux problèmes de codage.
# coding: UTF-8
 
f = open('test.txt')
s = f.read()
f.close()
print type(s) # <type &#39;str&#39;>
# 已知是GBK编码,解码成unicode
u = s.decode('GBK')
 
f = open('test.txt', 'w')
# 编码成UTF-8编码的str
s = u.encode('UTF-8')
f.write(s)
f.close()

2.4. Méthodes liées à l'encodage
# coding: GBK
 
import codecs
 
f = codecs.open('test.txt', encoding='UTF-8')
u = f.read()
f.close()
print type(u) # <type &#39;unicode&#39;>
 
f = codecs.open('test.txt', 'a', encoding='UTF-8')
# 写入unicode
f.write(u)
 
# 写入str,自动进行解码编码操作
# GBK编码的str
s = '汉'
print repr(s) # '\xba\xba'
# 这里会先将GBK编码的str解码为unicode再编码为UTF-8写入
f.write(s)
f.close()

Le module sys/locale fournit quelques méthodes pour obtenir l'encodage par défaut dans l'environnement actuel.

3. Quelques suggestions
# coding:gbk
 
import sys
import locale
 
def p(f):
    print '%s.%s(): %s' % (f.module, f.name, f())
 
# 返回当前系统所使用的默认字符编码
p(sys.getdefaultencoding)
 
# 返回用于转换Unicode文件名至系统文件名所使用的编码
p(sys.getfilesystemencoding)
 
# 获取默认的区域设置并返回元祖(语言, 编码)
p(locale.getdefaultlocale)
 
# 返回用户设定的文本数据编码
# 文档提到this function only returns a guess
p(locale.getpreferredencoding)
 
# \xba\xba是'汉'的GBK编码
# mbcs是不推荐使用的编码,这里仅作测试表明为什么不应该用
print r"'\xba\xba'.decode('mbcs'):", repr('\xba\xba'.decode('mbcs'))
 
#在笔者的Windows上的结果(区域设置为中文(简体, 中国))
#sys.getdefaultencoding(): gbk
#sys.getfilesystemencoding(): mbcs
#locale.getdefaultlocale(): ('zh_CN', 'cp936')
#locale.getpreferredencoding(): cp936
#'\xba\xba'.decode('mbcs'): u'\u6c49'

3.1. Utilisez la déclaration de codage de caractères, et tous les fichiers de code source du même projet utilisent la même déclaration de codage de caractères.

Cela doit être fait.

3.2. Abandonnez str et utilisez Unicode pour tous.

Appuyez sur u avant d'appuyer sur les guillemets. Il est vraiment difficile de s'habituer à cela au début, et vous oubliez souvent de revenir en arrière et de le réparer, mais si vous faites cela, vous pouvez réduire de 90 % problèmes de codage. Si le problème d’encodage n’est pas grave, vous n’avez pas besoin de vous référer à cet article.

3.3. Utilisez codecs.open() au lieu de open() intégré.

Si le problème d’encodage n’est pas grave, vous n’avez pas besoin de vous référer à cet article.

3.4. Encodages de caractères à éviter absolument : MBCS/DBCS et UTF-16.

Le MBCS mentionné ici ne signifie pas que GBK ou quoi que ce soit d'autre ne peut pas être utilisé, mais que vous ne devez pas utiliser l'encodage appelé 'MBCS' en Python à moins que le programme ne soit pas du tout portable.

Les codages 'MBCS' et 'DBCS' en Python sont des synonymes, faisant référence à l'encodage auquel MBCS fait référence dans l'

environnement Windows

actuel. Il n’existe pas de codage de ce type dans l’implémentation Linux de Python, donc des exceptions se produiront certainement une fois portées sur Linux ! De plus, tant que la région système Windows définie est différente, le codage auquel fait référence MBCS est également différent. Le résultat de la définition de différentes zones et de l'exécution du code dans la section 2.4 :

#中文(简体, 中国)
#sys.getdefaultencoding(): gbk
#sys.getfilesystemencoding(): mbcs
#locale.getdefaultlocale(): ('zh_CN', 'cp936')
#locale.getpreferredencoding(): cp936
#'\xba\xba'.decode('mbcs'): u'\u6c49'
 
#英语(美国)
#sys.getdefaultencoding(): UTF-8
#sys.getfilesystemencoding(): mbcs
#locale.getdefaultlocale(): ('zh_CN', 'cp1252')
#locale.getpreferredencoding(): cp1252
#'\xba\xba'.decode('mbcs'): u'\xba\xba'
 
#德语(德国)
#sys.getdefaultencoding(): gbk
#sys.getfilesystemencoding(): mbcs
#locale.getdefaultlocale(): ('zh_CN', 'cp1252')
#locale.getpreferredencoding(): cp1252
#'\xba\xba'.decode('mbcs'): u'\xba\xba'
 
#日语(日本)
#sys.getdefaultencoding(): gbk
#sys.getfilesystemencoding(): mbcs
#locale.getdefaultlocale(): ('zh_CN', 'cp932')
#locale.getpreferredencoding(): cp932
#'\xba\xba'.decode('mbcs'): u'\uff7a\uff7a'

可见,更改区域后,使用mbcs解码得到了不正确的结果,所以,当我们需要使用'GBK'时,应该直接写'GBK',不要写成'MBCS'。

UTF-16同理,虽然绝大多数操作系统中'UTF-16'是'UTF-16-LE'的同义词,但直接写'UTF-16-LE'只是多写3个字符而已,而万一某个操作系统中'UTF-16'变成了'UTF-16-BE'的同义词,就会有错误的结果。实际上,UTF-16用的相当少,但用到的时候还是需要注意。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn