python字符串编码及编码错误

http://blog.csdn.net/pipisorry/article/details/44136297

Introduction to编码



文本，他们通常指显示在屏幕上的字符或者其他的记号；但是计算机不能直接处理这些字符和标记；它们只认识位(bit)和字节(byte)。实际上，从屏幕上的每一块文本都是以某种字符编码(character encoding)的方式保存的。粗略地说就是，字符编码提供一种映射，使屏幕上显示的内容和内存、磁盘内存储的内容对应起来。有许多种不同的字符编码，有一些是为特定的语言，比如俄语、中文或者英语，设计、优化的，另外一些则可以用于多种语言的编码。

在实际操作中则会比上边描述的更复杂一些。许多字符在几种编码里是共用的，但是在实际的内存或者磁盘上，不同的编码方式可能会使用不同的字节序列来存储他们。所以，你可以把字符编码当做一种解码密钥。当有人给你一个字节序列 -- 文件，网页，或者别的什么 -- 并且告诉你它们是文本时，就需要知道他们使用了何种编码方式，然后才能将这些字节序列解码成字符。如果他们给的是错误的密钥或者根本没有给你密钥，那就得自己来破解这段编码，这可是一个艰难的任务。有可能你使用了错误的解码方式，然后出现一些莫名其妙的结果。
你肯定见过这样的网页，在撇号(

"

)该出现的地方被奇怪的像问号的字符替代了。这种情况通常意味着页面的作者没有正确的声明其使用的编码方式，浏览器只能自己来猜测，结果就是一些正确的和意料之外的字符的混合体。如果原文是英语，那只是不方便阅读而已；在其他的语言环境下，结果可能是完全不可读的。
现有的字符编码各类给世界上每种主要的语言都提供了编码方案。由于每种语言的各不相同，而且在以前内存和硬盘都很昂贵，所以每种字符编码都为特定的语言做了优化。上边这句话的意思是，每种编码都使用数字(0–255)来代表这种语言的字符。比如，你也许熟悉ASCII编码，它将英语中的字符都当做从0–127的数字来存储。（65表示大写的A，97表示小写的a，&c。）英语的字母表很简单，所以它能用不到128个数字表达出来。如果你懂得2进制计数的话，它只使用了一个字节内的7位。
西欧的一些语言，比如法语，西班牙语和德语等，比英语有更多的字母。或者，更准确的说，这些语言含有与变音符号(diacritical marks)组合起来的字母，像西班牙语里的

ñ

。这些语言最常用的编码方式是CP-1252，又叫做windows-1252，因为它在微软的视窗操作系统上被广泛使用。CP-1252和ASCII在0–127这个范围内的字符是一样的，但是CP-1252为

ñ

(n-with-a-tilde-over-it,
241)，

Ü

(u-with-two-dots-over-it, 252)这类字符而扩展到了128–255这个范围。然而，它仍然是一种单字节的编码方式；可能的最大数字为255，这仍然可以用一个字节来表示。
然而，像中文，日语和韩语等语言，他们的字符如此之多而不得不需要多字节编码的字符集。即，使用两个字节的数字(0–255)代表每个字符。但是就跟不同的单字节编码方式一样，多字节编码方式之间也有同样的问题，即他们使用的数字是相同的，但是表达的内容却不同。相对于单字节编码方式它们只是使用的数字范围更广一些，因为有更多的字符需要表示。
在没有网络的时代，文本由自己输入，偶尔才会打印出来，大多数情况下使用以上的编码方案是可行的。那时没有太多的纯文本。源代码使用ASCII编码，其他人也都使用字处理器，这些字处理器定义了他们自己的格式（非文本的），这些格式会连同字符编码信息和风格样式一起记录其中，&c。人们使用与原作者相同的字处理软件读取这些文档，所以或多或少地能够使用。
现在，我们考虑一下像email和web这样的全球网络的出现。大量的“纯文本”文件在全球范围内流转，它们在一台电脑上被撰写出来，通过第二台电脑进行传输，最后在另外一台电脑上显示。计算机只能识别数字，但是这些数字可能表达的是其他的东西。Oh no! 怎么办呢。。好吧，那么系统必须被设计成在每一段“纯文本”上都搭载编码信息。记住，编码方式是将计算机可读的数字映射***类可读的字符的解码密钥。失去解码密钥则意味着混乱不清的，莫名其妙的信息，或者更糟。
现在我们考虑尝试把多段文本存储在同一个地方，比如放置所有收到邮件的数据库。这仍然需要对每段文本存储其相关的字符编码信息，只有这样才能正确地显示它们。这很困难吗？试试搜索你的email数据库，这意味着需要在运行时进行编码之间的转换。很有趣是吧…
现在我们来分析另外一种可能性，即多语言文档，同一篇文档里来自几种不同语言的字符混在一起。（提示：处理这样文档的程序通常使用转义符在不同的模式(modes)之间切换。噗！现在是俄语 koi8-r 模式，所以241代表 Я；噗噗！现在到了Mac Greek模式，所以241代表 ώ。）当然，你也会想要搜索这些文档。根本就没有所谓的纯文本。
皮皮Blog

Unicode

Unicode编码系统为表达任意语言的任意字符而设计。它使用4字节的数字来表达每个字母、符号，或者表意文字(ideograph)。每个数字代表唯一的至少在某种语言中使用的符号。（并不是所有的数字都用上了，但是总数已经超过了65535，所以2个字节的数字是不够用的。）被几种语言共用的字符通常使用相同的数字来编码，除非存在一个在理的语源学(etymological)理由使不这样做。不考虑这种情况的话，每个字符对应一个数字，每个数字对应一个字符。即不存在二义性。不再需要记录模式了。

U+0041

总是代表

"A"

，即使这种语言没有

"A"

这个字符。
初次面对这个创想，它看起来似乎很伟大。一种编码方式即可解决所有问题。文档可包含多种语言。不再需要在各种编码方式之间进行模式转换。但是很快，一个明显的问题跳到我们面前。4个字节？只为了单独一个字符 这似乎太浪费了，特别是对像英语和西语这样的语言，他们只需要不到1个字节即可以表达所需的字符。事实上，对于以象形为基础的语言（比如中文）这种方法也有浪费，因为这些语言的字符也从来不需要超过2个字节即可表达。
有一种Unicode编码方式每1个字符使用4个字节。它叫做UTF-32，因为32位 = 4字节。UTF-32是一种直观的编码方式；它收录每一个Unicode字符（4字节数字）然后就以那个数字代表该字符。这种方法有其优点，最重要的一点就是可以在常数时间内定位字符串里的第N个字符，因为第N个字符从第4×Nth个字节开始。另外，它也有其缺点，最明显的就是它使用4个诡异的字节来存储每个诡异的字符…
尽管有Unicode字符非常多，但是实际上大多数人不会用到超过前65535个以外的字符。因此，就有了另外一种Unicode编码方式，叫做UTF-16(因为16位 = 2字节)。UTF-16将0–65535范围内的字符编码成2个字节，如果真的需要表达那些很少使用的星芒层(astral
plane)内超过这65535范围的Unicode字符，则需要使用一些诡异的技巧来实现。UTF-16编码最明显的优点是它在空间效率上比UTF-32高两倍，因为每个字符只需要2个字节来存储（除去65535范围以外的），而不是UTF-32中的4个字节。并且，如果我们假设某个字符串不包含任何星芒层中的字符，那么我们依然可以在常数时间内找到其中的第N个字符，直到它不成立为止这总是一个不错的推断…
但是对于UTF-32和UTF-16编码方式还有一些其他不明显的缺点。不同的计算机系统会以不同的顺序保存字节。这意味着字符

U+4E2D

在UTF-16编码方式下可能被保存为

4E 2D

或者

2D 4E

，这取决于该系统使用的是大尾端(big-endian)还是小尾端(little-endian)。（对于UTF-32编码方式，则有更多种可能的字节排列。）只要文档没有离开你的计算机，它还是安全的
-- 同一台电脑上的不同程序使用相同的字节顺序(byte order)。但是当我们需要在系统之间传输这个文档的时候，也许在万维网中，我们就需要一种方法来指示当前我们的字节是怎样存储的。不然的话，接收文档的计算机就无法知道这两个字节

4E 2D

表达的到底是

U+4E2D

还是

U+2D4E

。
为了解决这个问题，多字节的Unicode编码方式定义了一个字节顺序标记(Byte Order Mark)，它是一个特殊的非打印字符，你可以把它包含在文档的开头来指示你所使用的字节顺序。对于UTF-16，字节顺序标记是

U+FEFF

。如果收到一个以字节

FF FE

开头的UTF-16编码的文档，你就能确定它的字节顺序是单向的(one way)的了；如果它以

FE FF

开头，则可以确定字节顺序反向了。
不过，UTF-16还不够完美，特别是要处理许多ASCII字符时。如果仔细想想的话，甚至一个中文网页也会包含许多的ASCII字符 -- 所有包围在可打印中文字符周围的元素(element)和属性(attribute)。能够在常数时间内找到第Nth个字符当然非常好，但是依然存在着纠缠不休的星芒层字符的问题，这意味着你不能保证每个字符都是2个字节长，所以，除非你维护着另外一个索引，不然就不能真正意义上的在常数时间内定位第N个字符。另外，朋友，世界上肯定还存在很多的ASCII文本…
另外一些人琢磨着这些问题，他们找到了一种解决方法：
UTF-8
UTF-8是一种为Unicode设计的变长(variable-length)编码系统。即，不同的字符可使用不同数量的字节编码。对于ASCII字符(A-Z,&c.)UTF-8仅使用1个字节来编码。事实上，UTF-8中前128个字符(0–127)使用的是跟ASCII一样的编码方式。像ñ和ö这样的扩展拉丁字符(Extended
Latin)则使用2个字节来编码。（这里的字节并不是像UTF-16中那样简单的Unicode编码点(unicode code point)；它使用了一些位变换(bit-twiddling)。）中文字符比如则占用了3个字节。很少使用的星芒层字符则占用4个字节。
缺点：因为每个字符使用不同数量的字节编码，所以寻找串中第N个字符是一个O(N)复杂度的操作 -- 即，串越长，则需要更多的时间来定位特定的字符。同时，还需要位变换来把字符编码成字节，把字节解码成字符。
优点：在处理经常会用到的ASCII字符方面非常有效。在处理扩展的拉丁字符集方面也不比UTF-16差。对于中文字符来说，比UTF-32要好。同时，（在这一条上你得相信我，因为我不打算给你展示它的数学原理。）由位操作的天性使然，使用UTF-8不再存在字节顺序的问题了。一份以UTF-8编码的文档在不同的计算机之间是一样的比特流。
[字符编码ASCII，Unicode和UTF-8]

皮皮Blog

Python源码的编码方式

str与字节码

s = "人生苦短"

s是个字符串，它本身存储的就是字节码。那么这个字节码是什么格式的？

如果这段代码是在解释器上输入的，那么这个s的格式就是解释器的编码格式，对于windows的cmd而言，就是gbk。

如果将段代码是保存后才执行的，比如存储为utf-8，那么在解释器载入这段程序的时候，就会将s初始化为utf-8编码。

unicode与str

我们知道unicode是一种编码标准，具体的实现标准可能是utf-8，utf-16，gbk ......

python 在内部使用两个字节来存储一个unicode，使用unicode对象而不是str的好处，就是unicode方便于跨平台。

你可以用如下两种方式定义一个unicode:（在python2中）

1 s1 = u"人生苦短"
2 s2 = unicode("人生苦短", "utf-8")

python 2.x和3.x中的字符串编码区别

2.x中字符串有str和unicode两种类型，str有各种编码区别，unicode是没有编码的标准形式。unicode通过编码转化成str，str通过解码转化成unicode。

3.x中将字符串和字节序列做了区别，字符串str是字符串标准形式与2.x中unicode类似，bytes类似2.x中的str有各种编码区别。bytes通过解码转化成str，str通过编码转化成bytes。。

2.x中可以查看unicode字节序列，3.x中不能。

Python 2：
Python 2的源码.py文件默认的编码方式为ASCII
如果想使用一种不同的编码方式来保存Python代码，我们可以在每个文件的第一行放置编码声明(encoding declaration)。
以下声明定义

.py

文件使用windows-1252编码方式：# -*- coding: windows-1252 -*-
Note: 1. 从技术上说，字符编码的重载声明也可以放在第二行，如果第一行被类UNIX系统中的hash-bang命令占用了。
2. 了解更多信息，请参阅PEP263: 指定Python源码的编码方式。
Python 3：Python 3的源码.py文件 的默认编码方式为UTF-8
Python 3.x中的Unicode

在Python 3.0之后的版本中，所有的字符串都是使用Unicode编码的字符串序列，同时还有以下几个改进：

1、默认编码格式改为unicode

2、所有的Python内置模块都支持unicode

3、不再支持u中文的语法格式

所以，对于Python 3.x来说，编码问题已经不再是个大的问题，基本上很少遇到编码异常。

在Python 3，所有的字符串都是使用Unicode编码的字符序列。不再存在以UTF-8或者CP-1252编码的情况。也就是说，这个字符串是以UTF-8编码的吗？不再是一个有效问题。UTF-8是一种将字符编码成字节序列的方式。如果需要将字符串转换成特定编码的字节序列，Python 3可以为你做到。如果需要将一个字节序列转换成字符串，Python 3也能为你做到。字节即字节，并非字符。字符在计算机内只是一种抽象。字符串则是一种抽象的序列。

>>> s = "深入 Python"
>>> len(s)
9
>>> s[0]
"深"
>>> s + " 3"
"深入 Python 3"

Python中，字符串可以想像成由字符组成的元组。

Just like getting individual items out of a list, you can get individual characters out of a string using index notation.

与取得列表中的元素一样，也可以通过下标记号取得字符串中的某个字符。

皮皮Blog



设置defaultencoding(python2中才需要)

设置defaultencoding的代码如下：

1 reload(sys)
2 sys.setdefaultencoding('utf-8')

如果你在python中进行编码和解码的时候，不指定编码方式，那么python就会使用defaultencoding。

比如上一节例子中将str编码为另一种格式，就会使用defaultencoding。

s.encode("utf-8") 等价于 s.decode(defaultencoding).encode("utf-8")

Note: 这个过程是s先通过defaultencoding解码为unicode，再编码为utf-8类型的编码。

再比如你使用str创建unicode对象时，如果不说明这个str的编码格式，那么程序也会使用defaultencoding。

u = unicode("人生苦短") 等价于 u = unicode("人生苦短",defaultencoding)

默认的defaultcoding ascii是许多错误的原因，所以早早的设置defaultencoding是一个好习惯。

文件头声明编码的作用

关于python文件头部分知识的讲解

顶部的:

# -*- coding: utf-8 -*-

目前看来有三个作用。

如果代码中有中文注释，就需要此声明
比较高级的编辑器（比如我的emacs），会根据头部声明，将此作为代码文件的格式。
程序会通过头部声明，解码初始化 u"人生苦短"，这样的unicode对象，（所以头部声明和代码的存储格式要一致）


Example1:

1 # -*- coding:utf-8 -*-
2 su = "人生苦短"
3 # ： su是一个utf-8格式的字节串
4 u  = s.decode("utf-8")
5 # ： s被解码为unicode对象，赋给u
6 sg = u.encode("gbk")
7 # ： u被编码为gbk格式的字节串，赋给sg
8 print sg
9 # 打印sg

但是事实情况要比这个复杂，比如看如下代码：

1 s = "人生苦短"
2 s.encode('gbk')

看！str也能编码，(事实上unicode对象也能解码，但是意义不大)

Note:原理，当对str进行编码时，会先用默认编码将自己解码为unicode，然后在将unicode编码为你指定编码。

这就引出了python2.x中在处理中文时，大多数出现错误的原因所在：

python的默认编码，defaultencoding是ascii

看这个例子：

1 # -*- coding: utf-8 -*-
2 s = "人生苦短"
3 s.encode('gbk')

上面的代码会报错，错误信息：

UnicodeDecodeError: 'ascii' codec can't decode byte ......

因为你没有指定defaultencoding,所以它其实在做这样的事情:

1 # -*- coding: utf-8 -*-
2 s = "人生苦短"
3 s.decode('ascii').encode('gbk')

[b]Example2:

[/b]

python2.x示例：

[python]
view plaincopyprint?

>>> ss = '北京市'
>>> type(ss)
<type 'str'>
>>> us = ss.decode('gbk')
>>> us
u'\u5317\u4eac\u5e02'
>>> type(us)
<type 'unicode'>
>>> nus = u'北京市'
>>> nus
u'\u5317\u4eac\u5e02'
>>> ss
'\xb1\xb1\xbe\xa9\xca\xd0'
>>> gbks = nus.encode('gbk')
>>> gbks
'\xb1\xb1\xbe\xa9\xca\xd0'
>>> print(gbks)
北京市
>>> utfs = nus.encode('utf-8')
>>> utfs
'\xe5\x8c\x97\xe4\xba\xac\xe5\xb8\x82'
>>> print(utfs)
鍖椾含甯
>>> xx = utfs.decode('utf-8')
>>> type(xx)
<type 'unicode'>

ss = '北京市' 采用终端默认的编码形式，windows命名行窗口默认是gbk编码，所以通过ss.decode('gbk')转化成unicode的序列。最后utf-8编码的utfs输出乱码也是因为cmd终端是gdk编码的。

该示例中可以看到“北京市”的三种编码序列：

unicode序列：u'\u5317\u4eac\u5e02'

gbk序列：'\xb1\xb1\xbe\xa9\xca\xd0'

utf-8序列：'\xe5\x8c\x97\xe4\xba\xac\xe5\xb8\x82'

python3.x示例：

[python]
view plaincopyprint?





Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600 32 bit (In
tel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> ss = '北京市'
>>> type(ss)
<class 'str'>
>>> us = ss.encode('gbk')
>>> type(us)
<class 'bytes'>
>>> us
b'\xb1\xb1\xbe\xa9\xca\xd0'
>>> utfs = ss.encode('utf-8')
>>> print(utfs)
b'\xe5\x8c\x97\xe4\xba\xac\xe5\xb8\x82'
>>> type(utfs)
<class 'bytes'>
>>> xx = utfs.decode('utf-8')
>>> type(xx)
<class 'str'>
>>> print(xx)
北京市
>>> import urllib.parse
>>> res = urllib.parse.quote(utfs)
>>> res
'%E5%8C%97%E4%BA%AC%E5%B8%82'

3.x 想要查看字符串各种编码序列，只能通过encode转化成bytes类型，然后输出。str是标准形式没办法直接查看其字节序列。。
通过urllib.parse.quote 将字节序列转化成url的中文编码形式，逆过程是unquote函数。

皮皮Blog

python编码错误及解决方法

字符串是Python中最常用的数据类型，而且很多时候你会用到一些不属于标准ASCII字符集的字符，这时候代码就很可能抛出UnicodeDecodeError: ascii codec cant decode byte 0xc4 in position 10: ordinal not in range(128)异常。这种异常在Python中很容易遇到，尤其是在Python2.x中。

字符串在Python内部的表示是unicode编码，因此，在做编码转换时，通常需要以unicode作为中间编码，即先将其他编码的字符串解码（decode）成unicode，再从unicode编码（encode）成另一种编码。但是，Python 2.x的默认编码格式是ASCII，就是说，在没有指定Python源码编码格式的情况下，源码中的所有字符都会被默认为ASCII码。也因为这个根本原因，在Python 2.x中经常会遇UnicodeDecodeError或者UnicodeEncodeError的异常。

Unicode为了能够处理Unicode数据，同时兼容Python某些内部模块，Python 2.x中提供了Unicode这种数据类型，通过decode和encode方法可以将其它编码和Unicode编码相互转化，但同时也引入了UnicodeDecodeError和UnicodeEncodeError异常。

python常见编码异常（几乎都只存在于python2中）

Python中常见的几种编码异常有SyntaxError: Non-ASCII character、UnicodeDecodeError和UnicodeEncodeError等。

1、SyntaxError: Non-ASCII character

这种异常最不容易出现，也最容易处理，主要原因是Python源码文件中有非ASCII字符，而且同时没有声明源码编码格式，例如：

s = 中文

print s

# 抛出异常

2、UnicodeDecodeError

这个异常有时候会在调用decode方法时出现，原因是Python打算将其他编码的字符转化为Unicode编码，但是字符本身的编码格式和decode方法传入的编码格式不一致，例如：

#!/usr/bin/python

# -*- coding: utf-8 -*-

s = 中文

s.decode(gb2312)

# UnicodeDecodeError: gb2312 codec cant decode bytes in position 2-3: illegal multibyte sequenceprint s

Note:上面这段代码中字符串s的编码格式是utf-8(# -*- coding: utf-8 -*-声明的意思是：当前.py文件中所有的字符串是utf-8编码的)，但是在使用decode方法转化为Unicode编码时传入的参数是‘gb2312’，因此在转化的时候抛出UnicodeDecodeError异常。

还有一种情况是在encode的时候：

#!/usr/bin/python

# -*- coding: utf-8 -*-

s = 中文

s.encode(gb2312)

# UnicodeDecodeError: ascii codec cant decode byte 0xe4 in position 0: ordinal not in range(128)print s

Note:这里的s是utf-8编码的，直接使用s.encode(gb2312)实际使用了系统默认defalutencoding来解码，等价于s.decode(defaultencoding).encode(gb2312),而s的实际编码与defaultencoding不同。

3、UnicodeEncodeError

错误的使用decode和encode方法会出现这种异常，比如：使用decode方法将Unicode字符串转化的时候：

#!/usr/bin/python

# -*- coding: utf-8 -*-

s = u中文

s.decode(utf-8)

# UnicodeEncodeError: ascii codec cant encode characters in position 0-1: ordinal not in range(128)print s

[b]python编码异常解决方法：[/b]

1、遵循PEP0263原则，声明编码格式

在PEP 0263 Defining Python Source Code Encodings中提出了对Python编码问题的最基本的解决方法：在Python源码文件中声明编码格式，最常见的声明方式如下：

#!/usr/bin/python

# -*- coding: <encoding name> -*-

Note:其中<encoding name>是代码所需要的编码格式，它可以是任意一种Python支持的格式，一般都会使用utf-8的编码格式。# -*- coding: utf-8 -*-是Python文件声明,意思是：当前.py文件中所有的字符串是utf-8编码的，不是读取的文件是用utf-8编码读取的！

2、使用u中文替代中文

str1 = 中文编码

str2 = u中文编码

Python中有以上两种声明字符串变量的方式，它们的主要区别是编码格式的不同，其中，str1的编码格式和Python文件声明的编码格式一致，而str2的编码格式则是Unicode。如果你要声明的字符串变量中存在非ASCII的字符，那么最好使用str2的声明格式，这样你就可以不需要执行decode，直接对字符串进行操作，可以避免一些出现异常的情况。

Note:python3不支持u的声明方式。

3、Reset默认编码

Python中出现这么多编码问题的根本原因是Python 2.x的默认编码格式是ASCII，所以你也可以通过以下的方式修改默认的编码格式：

import sys

sys.setdefaultencoding(utf-8)

这种方法是可以解决部分编码问题，但是同时也会引入很多其他问题，得不偿失，不建议使用这种方式。

4、终极原则：decode early, unicode everywhere, encode late

即：在输入或者声明字符串的时候，尽早地使用decode方法将字符串转化成unicode编码格式；然后在程序内使用字符串的时候统一使用unicode格式进行处理，比如字符串拼接、字符串替换、获取字符串的长度等操作；最后，在输出字符串的时候（控制台/网页/文件），通过encode方法将字符串转化为你所想要的编码格式，比如utf-8等。按照这个原则处理Python的字符串，基本上可以解决所有的编码问题（只要你的代码和Python环境没有问题）。

5、升级Python 2.x到3.x

主要是因为Python 2.x的编码设计问题。当然，升级到Python 3.x肯定可以解决大部分因为编码产生的异常问题。毕竟Python 3.x版本对字符串这部分还是做了相当大的改进的。

原因参见前面关于python2.x和3.x的区别。

皮皮Blog

python读取文件编码错误出现乱码

首先用notepad++等文本查看器查看读取文件的编码，如文件编码为utf-8则使用utf-8编码方式打开{其它格式还有gbk, gb2312,ansi等等}

file = open(filename, encoding='UTF-8')

基本没有编码错误，还是出现某几个字符错误也可以用‘ignore’忽略掉

file = open(filename, encoding='UTF-8', errors='ignore')

[java中文乱码解决之道]

from:/article/1480579.html


ref:字符编码ASCII，Unicode和UTF-8

python中的str与unicode处理方法
http://mp.weixin.qq.com/s?__biz=MjM5NzU0MzU0Nw==&mid=204655326&idx=1&sn=cbe436b2ecf1bb7f4f11992756d407c7&from=singlemessage&isappinstalled=0#rd