gbk

任务要求 对大量txt格式的小说删除其中网址 解决思路: 列出目录下的全部文件 读取文件 将文件中网址替换(全为中文小说，可直接替换掉英文) 写入新文件 删除旧文件 源码 import re import os txtlist=os.listdir("C:\\Users\SAMSUNG\PycharmProjects\LoadBaiDu\\txt\\novel") #列出目录下的全部文件 for d in txtlist: if(d.endswith("t")): file=open("novel\\"+d,"r",encoding="gbk",errors="ignore") #编码问题 file1=open("novel\\ "+d,"w") for i in file.readlines(): file1.write(re.sub(r"[a-zA-z]","",i)) #正则表达式匹配字母 file1.close() file.close() print(d) os.remove("novel\\"+d) 问题解决 用python的时候经常会遇到文本的编码与解码问题，其中很常见的一种解码错误如题目所示，下面介绍该错误的解决方法，将‘gbk’换成‘utf-8’也适用。 （1）、首先在打开文本的时候，设置其编码格式，如：open(‘1.txt’,encoding=’gbk’)；

1.这是python的语言特性，python先创建对象，在给变量赋值时，不需要定义变量的名称和类型，它实际是用变量引用对象。变量类型在给变量赋值时自动声明 2.原因类似变量无须声明类型 3.python用下划线作为变量前缀和后缀指定特殊变量，对解释器有特殊意义，也是内建标识符所使用的特殊符号，故一般避免用下划线作为变量的开头和结尾 4.python一行可以书写多个语句，多个语句间用";"分隔。但是为了良好的编程风格，不推荐这么做 5.python可以将一个语句分成多行书写，行的末尾用反斜杠"\"标识。python一行语句最好不超过80字符，所以若一个语句过长，可以分成多行书写。其他情况下，还是保持一个物理行写一个逻辑行吧 6.变量赋值 (a)赋值语句 x, y, z = 1, 2, 3 在x中赋值1，y中赋值2，z中赋值3 (b)执行在z, x, y = y, z, x后，x值是3，y的值是1，z的值是2 7.标识符 int32 printf print _print this self __name__ bool true type thisIsAVar R_U_ready Int True if do access 是合法的python标识符 其中，print;if是python关键字。 8. #!/user/bin/env python # -*- coding:utf-8

出现此问题的几种解决办法： 　　1、cmd下使用javac编译java文件 　　　　如： javac test.java 　　　解决办法：编译时加上encoding选项 　　　　　　 javac -encoding UTF-8 test.java or javac -encoding UTF-8 -d . test.java 　　2、IntelliJ IDEA 导入单独的java文件时编译出现此错误 　　　 解决办法：由于IDEA不具有自动转换字符编码类型，所以需要先点击右下角的UTF-8保存为GBK类型保存，再次点击点击GBK保存为UTF-8即可。 　　3、使用Notepad++打开java文件，点击编码-->转为ANSI编码 ， 保存即可。 来源： https://www.cnblogs.com/jiaqinbi/p/12010361.html

一个带标签，一个没有标签。 BOM是Byte Order Mark（定义字节顺序），因为在网络传输中分两种顺序：大头和小头。 由于兼容性，带BOM的utf-8在一些browser中显示为乱码。 网上搜索了关于Byte Order Mark的信息： 在UCS 编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建 议我们在传输字节流前，先传输字符"ZERO WIDTH NO-BREAK SPACE"。这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这 个字节流是Little- Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。 UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF。所以如果接收者收到以EF BB BF 开头的字节流，就知道这是UTF-8编码了。 Windows就是使用BOM来标记文本文件的编码方式的。 带BOM的UTF-8，所有PHP无法识别，直接将EF BB BF输出，在charset="utf-8"的页面中是空白

UTF-8：Unicode TransformationFormat-8bit，允许含BOM，但通常不含BOM。是用以解决国际上字符的一种多字节编码，它对英文使用8位（即一个字节），中文使用24为（三个字节）来编码。UTF-8包含全世界所有国家需要用到的字符，是国际编码，通用性强。UTF-8编码的文字可以在各国支持UTF8字符集的浏览器上显示。如，如果是UTF8编码，则在外国人的英文IE上也能显示中文，他们无需下载IE的中文语言支持包。 　　GBK是国家标准GB2312基础上扩容后兼容GB2312的标准。GBK的文字编码是用双字节来表示的，即不论中、英文字符均使用双字节来表示，为了区分中文，将其最高位都设定成1。GBK包含全部中文字符，是国家编码，通用性比UTF8差，不过UTF8占用的数据库比GBD大。 　　GBK、GB2312等与UTF8之间都必须通过Unicode编码才能相互转换： 　　GBK、GB2312－－Unicode－－UTF8 　　UTF8－－Unicode－－GBK、GB2312 　　对于一个网站、论坛来说，如果英文字符较多，则建议使用UTF－8节省空间。不过现在很多论坛的插件一般只支持GBK。 　　个编码的区别详细解释 　　简单来说，unicode，gbk和大五码就是编码的值，而utf-8,uft-16之类就是这个值的表现形式．而前面那三种编码是一兼容的

前言 其实这是个老生常谈的问题了,相信大家在第一次遇到Unicode编码问题时,都会在网上搜索一通, 找到几个解释,虽然有点杂乱,但还是感觉自己明白了些什么,然后就继续忙别的事情. 而我之所以就这个问题专门写一篇文章,原因是前两天在与公司一位有十几年工作经验的JAVA程序员对接 API时, 我问他返回的汉字是什么编码的, 而他回答说"直接返回unicode". 一个如此有经验的老程序员 对这种基本问题都不甚清楚, 因此我觉得还是有必要好好说一下这个问题的. 字符集 在介绍他们之间的区别时, 我们先讲下什么是Unicode. 简单来说,Unicode是一个字符集(character set), 和ASCII一样, 其作用是用一系列数字来表示字符(character), 这些数字有时也称为码点(code points). 在PC刚出来的时候,使用英文的几位先驱认为计算机需要表示的字符不多,26个英文字母加几个回车换行等 特殊符号,总共一百个字符顶天了,于是就有了ASCII. ASCII码的大小为1个字节,定义了128个字符, 分别表示为0-127. 比如字符'A'的码点为65,回车符'\n'的码点为10, 如下所示: >>> ord('A') 65 >>> ord('0') 48 >>> ord('\n') 10 当然, 后来人们发现, 世界上的字符远远不止128个,

从Linux往windows拷贝文件或者从windows往Linux拷贝文件，有时会出现中文文件名乱码的情况，出现这种问题的原因是因为，windows的文件名中文编码默认为GBK,而Linux中默认文件名编码为UTF8,由于编码不一致，所以导致了文件名乱码的问题，解决这个问题需要对文件名进行转码。 方法一： 使用允许指定字符编码格式的上传工具，如使用xshell5的xftp5工具上传文件时，注意修改配置，让窗口显示中文文件名能以Linux默认的UTF-8作为编码上传： 方法二： 对于本来已经存在于Linux上的文件，在Linux中专门提供了一种工具进行文件名编码的转换，可以将文件名从GBK转换成UTF-8编码，或者从UTF-8转换到GBK。 服务器是centos，安装 convmv：yum -y installconvmv。 下面看一下convmv的具体用法： convmv -f 源编码 -t 新编码 [选项] 文件名 常用参数： -r 递归处理子文件夹 -r 递归处理子文件夹 --notest真正进行操作，请注意在默认情况下是不对文件进行真实操作的，而只是试验。 --list 显示所有支持的编码 --unescap 可以做一下转义，比如把%20变成空格 比如我们有一个utf8编码的文件名，转换成GBK编码，命令如下： convmv -f UTF-8 -t GBK -

1、UnicodeDecodeError: 'gbk' codec can't decode byte 0xaa in position 32: illegal multibyte sequence UnicodeDecodeError: 'gbk' codec can't decode byte 0xaa in position 132: illegal multibyte sequence 解决方案：尚未有 推测： 字符集合（   ） 问题出在“gbk"和”utf-8"都不能读取上面的那些（红色标注）字符，目前解决方法是找到文本中的这个字符，对其进行删除，再读取文本，或者使用try ……except 结构，凡是遇到读取失败的文本，continue 跳过，读取下一个文件。 2、SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in position 16-17: malformed \N character escape 解决方案：初步确认是文件路径的格式不对，filename应该为：E:/Python/Corpus/News/Environment/001.txt 这里是斜杆，而不是反斜杠 3、UnicodeDecodeError: 'utf-8' codec can't decode

昨天一个大学的同学问了一个关于utf-8转码gbk的问题，所以两个人一起讨论了一下关于utf-8转码成为GBK的乱码原因。 正常情况下如果我们需要将UTF-8格式转码为GBK，我们会需要经过这样一个中转： 通常情况下如果直接转码会出现一种情况就是GBK转码UFT-8出现乱码后乱码可以在转码回去变为原来的GBK中文。 但是UTF-8转码为GBK则会出现两种情况，在中文字符长度为偶数时是可以直接将乱码还原回去的，但是奇数情况下是无法全部转码回去的 究竟什么原因呢？ 这和UTF-8的编码字节数和GBK的编码字节数有关，我们知道UTF-8的字符集是以三个字节数来存储的，而GBK则是两个字节数，所以就存在以下问题 当“你好好”三个字转码为字符集表示的时候，一共得到九个字节，当然这九个字节转码为gbk的时候会被两两分组，所以第九个字节就会被抛弃无法识别转化为有标记的乱码符号，当我们再把乱码转回去的时候，自然就无法还原为原来的UTF-8了。如下图 所以在UTF-8转gbk的基数情况下就会出现最后一个字转码为乱码后无法还原的情况。 来源： CSDN 作者： Tealar 链接： https://blog.csdn.net/u013130920/article/details/53304165

locale的设定及其LANG、LC_ALL、LANGUAGE环境变量的区别 （转自： http://hi.baidu.com/edeed/item/c23752f36abdd916ce9f3289 ） 例如zh_CN.GB2312、zh_CN.GB18030或者zh_CN.UTF-8。很多人都不明白这些古里古怪的表达方式。这个外星表达式规定了什么东西呢？这个问题稍后详述，现在只需要知道，这是locale的表达方式就可以了。 locale这个单词中文翻译成地区或者地域，其实这个单词包含的意义要宽泛很多。Locale是根据计算机用户所使用的语言，所在国家或者地区，以及当地的文化传统所定义的一个软件运行时的语言环境。 [oracle @game ~]$ locale LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC