最近项目中涉及到了解析文件内容的需求，文件中全都是中文，由于这一过程中碰到的乱码问题实在过多，所以特地花时间研究了一下中文编码。本文中先介绍一下ASCII，GB2312，GBK和GB18030编码。
从上游Oracle数据库中导出的携带中文乱码且编码集为ISO-8859-1的数据文件，将导出的数据文件导入到Hive表，在原始表的基础上通过创建视图，按照与上游接口约定的定长的方式拆分字段时报错，异常内容如下：
1 GB18030字节数组转UTF-8字符串 public static String gB18030ByteArrayToUtf8String(byte[] bytes) { ByteBuffer byteBuffer = ByteBuffer.wrap(bytes); CharBuffer gb18030 = Charset.forName("GB18030").decode(byteBuffer); ByteBuffer utf8 = Charset.
【环境】 Windows 10 x64 Python 3.6.3 【关于 gb18030 编码】 GB 18030 wiki：https://zh.wikipedia.org/wiki/GB_18030 单字节，其值从0到0x7F。 双字节，第一个字节的值从0x81到0xFE，第二个字节的值从0x40到0xFE（不包括0x7F）。 四字节，第一个字节的值从0x81到0xFE，第二个字节的值从0x30到0x39，第三个字节从0x81到0xFE，第四个字节从0x30到0x39。 【解码错误的处理方式】 错误
在做接口联调的时候出现访问对方的时候需要把编码转成gb18030格式的，我这边默认是utf8，这个困扰了很长时间，在网上百度发现大部分字符串转编码都是使用string.getByte(“编码格式”)的方式字节转码，可事实上这样是行不通的。原因有点难说，这里我就说一下可行的方案。
使用socket通讯经常会遇到客户端、服务器端字符编码不一致的情况，如果传输的信息包含中文，这时我们可能就需要对传输的信息的按照指定的字符集进行解码
Vim有四个跟字符编码方式有关的选项，encoding、fileencoding、fileencodings、termencoding(这些选项设置请参考Vim文档中encoding-names章节)，它们的意义如下:
在很多项目里,或者一些应用上，我们经常需要把一些文件导入到SAP系统里,最经常我们使用的读取数据的方法就是使用GUI_UPLOAD这个FM.在这个FM中有个CODEPAGE,是用来指定代码页的. 如果我们导的是中文的话,我们经常使用的是8400.当然还有8401,8411等等. 主要介绍一下8400/8401.因为大家最常用的是8400.看8400的介绍上说,是based on GB2312-EUC版本,WINDOWS的代码页就是CP936.8401使用的就是GB18030 2000编码.那么他们的区别在哪里呢. 1、 GB2312 GB2312(1980年)一共收录了7445个字符，包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7，低字节从A1-FE，占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。 在windows中的代码页是CP936 2、 GBK GBK最初是由微软对GB2312的扩展，也就是CP936字码表 (Code Page 936)的扩展（原来的CP936和GB 2312-80一模一样），最初出现于Windows 95简体中文版中，由于Windows产品的流行和在大陆广泛被使用，中华人民共和国国家有关部门将其作为技术规范。注意GBK并非国家正式标准，只是国家技术监督局标准化司、电子工业部科技与质量监督司发布的“技术规范指导性文件”。虽然 GBK收录了所有Unicode 1.1及GB 13000.1-93之中的汉字，但是编码方式与Unicode 1.1及GB 13000.1-93不同。仅仅是GB 2312到GB 13000.1-93之间的过渡方案。GBK收录了21886个符号，它分为汉字区和图形符号区。汉字区包括21003个字符。 GBK作为对GB2312的扩展，在现在的windows系统中仍然使用代码页CP936表示，但是同样的936的代码页跟一开始的936的代码页只支持GB2312编码不同，现在的936代码页支持GBK的编码，GBK同时也向下兼容GB2312编码。 3、 GB18030 2000年的GB18030取代了GBK1.0的正式国家标准。该标准收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。现在的PC平台必须支持GB18030，对嵌入式产品暂不作要求。所以手机、MP3一般只支持GB2312。 GB18030在windows中的代码页是CP54936。 4、 GB13000 GB13000等同于国际标准的《通用多八位编码字符集 (UCS)》 ISO10646.1，就是等同于Unicode的标准，代码页等等的都使用UTF的一套标准。 从ASCII、GB2312、GBK到GB18030，这些编码方法是向下兼容的，即同一个字符在这些方案中总是有相同的编码，后面的标准支持更多的字符。在这些编码中，英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼，GB2312、GBK到GB18030都属于双字节字符集 (DBCS)。
| 导语 本文主要介绍了业务中常见的ASCII、GB2312、GBK、GB18030、UTF8、ANSI、Latin1中文编码。如果你在业务中也曾经被乱码搞晕过，不妨我们一起探究一下。 PS：文末有今天儿童节粉丝福利活动哦！ 最近我的业务中涉及到了包含中文文本的内容解析。业务场景是用户上传一个包含中文的文本文件，我们需要根据约定好的字段格式解析该文本，并将内容导入到数据库中。但用户所传上来的文件中文编码经常会不一样，于是我们的数据库中经常会有乱码出现。为了解决该问题，就有了这篇文章…… 1、字符编码要做
在默认情况下，也就是未自行安装新字体或者 Office 等文字处理软件的情况下，Windows 默认提供下列字体：
1、将字符串'024f'转化为unicode字符,先将字符转化为16进制整数 code = int('024f',base=16) print '%x'%code,'%04x'%code 输出结果：24f 024f,一般选择后者处理凑足偶数字节 转化unicode编码 unichr(code) 运行得到unicode编码 u'\u024f' uc = unichr(code) print uc, type(uc) 输出字符,类型，特别注意unicode类型，处理起来有点不同，两个字节算一个字符 ɏ,uni
在第6节和第7节，我们讨论了文本的二进制编码、乱码、以及恢复，第6节受到了很多读者的一致好评，但第7节有读者反馈解说的不太透彻，希望再详细一点，本文就是对第7节内容的扩展。 乱码 第6节说到乱码出现的主要原因，即在进行编码转换的时候，如果将原来的编码识别错了，并进行了转换，就会发生乱码，而且这时候无论怎么切换查看编码的方式，都是不行的。 我们来看一个这种错误转换后的乱码，还是用上节的例子，二进制是(16进制表示)：C3 80 C3 8F C3 82 C3 AD，无论按哪种编码解析看上去都是乱码： UTF-8
[这里仅仅测试addr参数为中文]接收Ascii字符时运行良好,但是接收中文字符时显示乱码,浏览器切换到GB2312编码时
8月17日，在中国电子技术标准化研究院举办的“强制性国家标准GB18030标准宣贯会暨首批通过认证测试产品发布会”上，腾讯云两款产品数据库TDSQL、操作系统TencentOS作为首批通过认证测试的产品，获得GB18030-2022《信息技术中文编码字符集》最高级（3级）认证证书，同时也获得GB18030优秀贯标企业表彰。
python 里面的编码和解码也就是 unicode 和 str 这两种形式的相互转化。编码是 unicode -> str，相反的，解码就是 str -> unicode。剩下的问题就是确定何时需要进行编码或者解码了.关于文件开头的"编码指示"，也就是 # -- coding: -- 这个语句。Python 默认脚本文件都是 UTF-8 编码的，当文件中有非 UTF-8 编码范围内的字符的时候就要使用"编码指示"来修正. 关于 sys.defaultencoding，这个在解码没有明确指明解码方式的时候使用。 比如我有如下代码：
<default-action-ref name="index"></default-action-ref> 默认的action的引用；当别人访问这个action的时候，如果找不到对应的action
8月21日，在中国电子技术标准化研究院举办的“强制性国家标准GB18030标准宣贯会暨首批通过认证测试产品发布会”上，腾讯云数据库TDSQL、操作系统TencentOS作为首批通过认证测试的产品，获得GB18030-2022《信息技术中文编码字符集》最高级（3级）认证证书，同时也获得GB18030优秀贯标企业表彰。
在机器学习中，性能度量主要体现在三个指标： 查准率（P）、查全率（R）、F1 。
python的创始人为吉多·范罗苏姆（Guido van Rossum）。1989年的圣诞节期间，吉多·范罗苏姆为了在阿姆斯特丹打发时间，决心开发一个新的脚本解释程序，作为ABC语言的一种继承。
在服务端解析客户端的编码设置（即服务器接收浏览器发送的数据），采用GB18030的方式，但是这样有一点不好，如果我有1000个页面（.jsp）需要设置需要重复写这样的语句1000条，重复工作，针对此问题的解决，下面给出了解决方案
1.一些枯燥的概念： Http定义了与服务器交互的不同方法，最基本的方法有4种，分别是GET，POST，PUT，DELETE。 URL全称是资源描述符，我们可以这样认为：一个URL地址，它用于描述一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查 ，改 ，增 ，删 4个操作。GET一般用于获取/查询资源信息，而POST一般用于更新资源信息。 2.GET是幂等的，POST是要修改更新的 通过上面概念的理解，我们很容易发现，GET是用于信息获取或查询的，这就意味着它是幂
我们在处理文件、浏览网页、编写程序时，时不时会碰到乱码的情况。乱码几乎总是令人心烦，让人困惑。希望通过本节和下节文章，你可以自信从容地面对乱码，恢复乱码。 谈乱码，我们就要谈数据的二进制表示，我们已经在前两节谈过整数和小数的二进制表示，接下了我们将讨论字符和文本的二进制表示。 由于内容比较多，我们将分两节来介绍。本节主要介绍各种编码，乱码产生的原因，以及简单乱码的恢复。下节我们介绍复杂乱码的恢复，以及Java中对字符和文本的处理。 编码和乱码听起来比较复杂，文章也比较长，但其实并不复杂，请耐心阅读，让我们
于是我们来解决一下这个问题。把日志的大小限在10240Ｋ,一共仅仅许生成30个。循环覆盖
xml文件当成struts.xml包含在struts.xml中，比如我们看到的login.xml
write方法的参数类型是str，str是二进制流（不包含编码信息），当你给出一个unicode对象时，会执行str函数转换成str类型再送给write方法。unicode转str包含一次编码，如不指定则默认使用ascii编码，而ascii编码集里汉字字符是没有对应的，所以报错。
试想你请求一个数据，却得到一堆乱码，丈二和尚摸不着头脑。有同事质疑你的数据是乱码，虽然你很确定传了 UTF-8 ，却也无法自证清白，更别说帮同事 debug 了。
utf-8 回忆上次内容 上次再次输出了大红心♥ 找到了红心对应的编码 黑红梅方都对应有编码 原来的编码叫做 ascii️ \
struts2中的路径问题是根据action的路径而不是jsp路径来确定，所以尽量不要使用相对路径。
在做B/S开发的时候，安全性是必须要考虑的问题。其中有一个问题就是url的访问控制，具体来说就是你不经过登录页面登录那么你就不能访问后面的管理页面，或者是会员进去之后才能看到的页面。 以前用C#开发ASP.NET项目的时候是在每一个页面后台代码的page_load事件中对session进行判断，if语句实现如果没有相应的session值就会跳转到login页面或者index页面。如果仅有十几个页面也就罢了，但是如果后台页面几百个呢？总不能每一个页面都写一个吧。那么在学习javaweb开发的时候有了一个很好的解决方案，那就是通过filter来解决。 这个Filter就像是web系统的一道防火墙，你要访问任何资源，都会经过它的许可才行。所以这个“防火墙”里面的规则设定尤其重要，其中一个就是对url的访问控制。 实现的基本原理就是：在实现Filter接口的类中判断当前访问的url，如果不是登录页面，那么就判断session是否为null，判断session里面指定的参数是否为null。这样就可以了。
打开matlab的安装目录（右键点matlab图标选择 show package contents（显示程序包内容））
公司最近几个项目在申请软著和专利,申请过的小伙伴都知道,申请软著的时候, 需要提交一份word代码.
1、css实现宽度是百分比的盒子为正方形 只需要保证width的百分比值和padding-bottom的百分比值一样即可 2、手机端判断是横屏还是竖屏 function checkOrient() { if (window.orientation == 0 || window.orientation == 180){ alert
只是简单的一些代码，不过我想根据大家举一反三的能力，知道这些之后其他的都不是问题了，因为JSTL本身就是为了简单方便才出现的。 首先建立一个servlet：
读写中文文件时，不需要考虑编码的情况。此时虽然可以正常从文件中读取中文，也可以正常地将中文写入文件中，但是无法正常打印中文字段到屏幕上：
这篇文章将是大猫《如何搞定头疼的编码》一文的一部分，当时本来想做一个完整的有关“R与编码”的笔记，没想到后来洋洋洒洒写了六七千字，估计一时半会也完成不了，所以先选出其中有意思的一节同大家分享。
namespace决定了action的访问路径，默认为"",可以接受所有路径的action
编码在我们日常开发过程中经常有遇到，常见的编码格式有ASCII、ISO-8859-1、GB2312、GBK、GB18030、UNICODE、UTF-8、UTF-16等，其中GB2312、GBK、GB18030、UTF-8、UTF-16都可以用来表示中文，那么哪种存储中文会比较合适呢，下面会对这几种编码一一介绍便会有结论。 为什么有编码 我们知道计算机中最小的存储单位是字节（byte），一个字节所能表示的字符数又有限，1byte=8bit，一个字节最多也只能表示255个字符，而世界上的语种又多，都有各种不
字节数 : 1;编码：GB2312 字节数 : 1;编码：GBK 字节数 : 1;编码：GB18030 字节数 : 1;编码：ISO-8859-1 字节数 : 1;编码：UTF-8 字节数 : 4;编码：UTF-16 字节数 : 2;编码：UTF-16BE 字节数 : 2;编码：UTF-16LE
这是一篇程序员写给程序员的趣味读物。所谓趣味是指可以比较轻松地了解一些原来不清楚的概念，增进知识，类似于打RPG游戏的升级。整理这篇文章的动机是两个问题：
如果要使插件开发应用能有更好的国际化支持，能够最大程度的支持中文输出，则最好让Java文件使用UTF-8编码。
输出报错: UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc4 in position 220: in 解决方案：将编码方式utf-8 修改为gb18030 例如: requests.get(url,headers).content.decode('gb18030')
UNICODE,GBK,UTF-8区别 简单来说，unicode，gbk和大五码就是编码的值，而utf-8,uft-16之类就是这个值的表现形式．而前面那三种编码是一兼容的，同一个汉字，那三个码值是完全不一样的．如＂汉＂的uncode值与gbk就是不一样的，假设uncode为a040，gbk为b030，而uft-8码，就是把那个值表现的形式．utf-8码完全只针对uncode来组织的，如果ＧＢＫ要转ＵＴＦ－８必须先转uncode码，再转utf-8就ＯＫ了． 详细的就见下面转的这篇文章． 谈谈Unicode编码，简要解释UCS、UTF、BMP、BOM等名词 这是一篇程序员写给程序员的趣味读物。所谓趣味是指可以比较轻松地了解一些原来不清楚的概念，增进知识，类似于打RPG游戏的升级。整理这篇文章的动机是两个问题： 问题一： 使用Windows记事本的“另存为”，可以在GBK、Unicode、Unicode big endian和UTF-8这几种编码方式间相互转换。同样是txt文件，Windows是怎样识别编码方式的呢？ 我很早前就发现Unicode、Unicode big endian和UTF-8编码的txt文件的开头会多出几个字节，分别是FF、FE（Unicode）,FE、FF（Unicode big endian）,EF、BB、BF（UTF-8）。但这些标记是基于什么标准呢？ 问题二： 最近在网上看到一个ConvertUTF.c，实现了UTF-32、UTF-16和UTF-8这三种编码方式的相互转换。对于Unicode(UCS2)、GBK、UTF-8这些编码方式，我原来就了解。但这个程序让我有些糊涂，想不起来UTF-16和UCS2有什么关系。 查了查相关资料，总算将这些问题弄清楚了，顺带也了解了一些Unicode的细节。写成一篇文章，送给有过类似疑问的朋友。本文在写作时尽量做到通俗易懂，但要求读者知道什么是字节，什么是十六进制。 0、big endian和little endian big endian和little endian是CPU处理多字节数的不同方式。例如“汉”字的Unicode编码是6C49。那么写到文件里时，究竟是将6C写在前面，还是将49写在前面？如果将6C写在前面，就是big endian。如果将49写在前面，就是little endian。 “endian”这个词出自《格列佛游记》。小人国的内战就源于吃鸡蛋时是究竟从大头(Big-Endian)敲开还是从小头(Little-Endian)敲开，由此曾发生过六次叛乱，一个皇帝送了命，另一个丢了王位。 我们一般将endian翻译成“字节序”，将big endian和little endian称作“大尾”和“小尾”。 1、字符编码、内码，顺带介绍汉字编码 字符必须编码后才能被计算机处理。计算机使用的缺省编码方式就是计算机的内码。早期的计算机使用7位的ASCII编码，为了处理汉字，程序员设计了用于简体中文的GB2312和用于繁体中文的big5。 GB2312(1980年)一共收录了7445个字符，包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7，低字节从A1-FE，占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。 GB2312支持的汉字太少。1995年的汉字扩展规范GBK1.0收录了21886个符号，它分为汉字区和图形符号区。汉字区包括21003个字符。 从ASCII、GB2312到GBK，这些编码方法是向下兼容的，即同一个字符在这些方案中总是有相同的编码，后面的标准支持更多的字符。在这些编码中，英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼，GB2312、GBK都属于双字节字符集 (DBCS)。 2000年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。从汉字字汇上说，GB18030在GB13000.1的20902个汉字的基础上增加了CJK扩展A的6582个汉字（Unicode码0x3400-0x4db5），一共收录了27484个汉字。 CJK就是中日韩的意思。Unicode为了节省码位，将中日韩三国语言中的文字统一编码。GB13000.1就是ISO/IEC 10646-1的中文版，相当于Unicode 1.1。 GB18030的编码采用单字节、双字节和4字节方案。其中单字节、双字节和GBK是完全兼容的。4字节编码的码位就是收录了CJK扩展A的6582个汉字。例如：UCS的0x3400在GB18030中的编码应该是8139EF30，UCS的0x3401在GB18030中的编码应该是8139EF31。 微软提供了GB18030的升级包，但这个升级包只是提供了一
我们创建类时会指出那个类的对象的外观与行为。用new 创建那个类的一个对象，只有执行了 new 后，才会正式生成数据存储空间，并可使用相应的方法。但是这带来了下面的不足之处。 1、只想用一个存储区域来保存一个特定的数据，无论要创建多少个对象，甚至根本不创建对象。 2、是我们需要一个特殊的方法，即使没有创建对象，也可以调用的方法。 为了解决上面的问题，我们使用static关键字进行修饰。
$ZMODE包含使用OPEN或USE命令为当前设备指定的参数。返回的字符串包含用于以规范形式打开当前I/O设备的参数。这些参数值由反斜杠分隔符分隔。TCP/IP IO上的开放参数(如“M”)被规范化为“PSTE”。“Y”和“K”参数值始终放在最后。
如上面代码，str\str1\str2均为字符串类型（str）,给字符串操作带来较大的复杂性。
每个 MySQL 字符集可以支持一个或者多个排序规则，用于定义每个字符的比较规则，包括是否区分大小写，是否区分重音等。
def URLtoUTF8(string): """""" g_code_type = ['utf-8', 'utf8', 'gb18030', 'gb2312', 'gbk', 'ISO-8859-2'] try: tmp = urllib.unquote(str(string)) code = chardet.detect(tmp)['encoding'] try: g_code_type.index(co
Python的requests库是一个非常好用的库，这应该已经是大多写过爬虫的人的共识了。它的简洁易用给我们带来很大方便。然而，它也并不是非常完美。今天我们就说说它在处理中文编码方面的不足。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/167832.html原文链接：https://javaforall.cn
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
