gb2312

http://www.regexlab.com/zh/encoding.htm 1. 编码问题的由来，相关概念的理解 1.1 字符与编码的发展 从计算机对多国语言的支持角度看，大致可以分为三个阶段： 　 系统内码 说明 系统 阶段一 ASCII 计算机刚开始只支持英语，其它语言不能够在计算机上存储和显示。 英文 DOS 阶段二 ANSI编码 （本地化） 为使计算机支持更多语言，通常使用 0x80~0xFF 范围的 2 个字节来表示 1 个字符。比如：汉字 '中' 在中文操作系统中，使用 [0xD6,0xD0] 这两个字节存储。 不同的国家和地区制定了不同的标准，由此产生了 GB2312, BIG5, JIS 等各自的编码标准。这些使用 2 个字节来代表一个字符的各种汉字延伸编码方式，称为 ANSI 编码 。在简体中文系统下，ANSI 编码代表 GB2312 编码，在日文操作系统下，ANSI 编码代表 JIS 编码。 不同 ANSI 编码之间互不兼容，当信息在国际间交流时，无法将属于两种语言的文字，存储在同一段 ANSI 编码 的文本中。 中文 DOS，中文 Windows 95/98，日文 Windows 95/98 阶段三 UNICODE （国际化） 为了使国际间信息交流更加方便，国际组织制定了 UNICODE 字符集 ，为各种语言中的每一个字符设定了统一并且唯一的数字编号

宋体 SimSun 黑体 SimHei 微软雅黑 Microsoft YaHei 微软正黑体 Microsoft JhengHei 新宋体 NSimSun 新细明体 PMingLiU 细明体 MingLiU 标楷体 DFKai-SB 仿宋 FangSong 楷体 KaiTi 仿宋_GB2312 FangSong_GB2312 楷体_GB2312 KaiTi_GB2312 宋体：SimSuncss中中文字体（font-family）的英文名称 Mac OS的一些： 华文细黑：STHeiti Light [STXihei] 华文黑体：STHeiti 华文楷体：STKaiti 华文宋体：STSong 华文仿宋：STFangsong 儷黑 Pro：LiHei Pro Medium 儷宋 Pro：LiSong Pro Light 標楷體：BiauKai 蘋果儷中黑：Apple LiGothic Medium 蘋果儷細宋：Apple LiSung Light Windows的一些： 新細明體：PMingLiU 細明體：MingLiU 標楷體：DFKai-SB 黑体：SimHei 新宋体：NSimSun 仿宋：FangSong 楷体：KaiTi 仿宋_GB2312：FangSong_GB2312 楷体_GB2312：KaiTi_GB2312 微軟正黑體：Microsoft JhengHei

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 最早接触到编码问题时，无非是关于『乱码』一词，当某个程序或者网页或者数据库或者IDE中一看出现了乱码，就马上知道这是字符编码与解码不匹配，改下编码就好，就因为这个事情太简单，容易解决，甚至在一段时间看到一段乱码文字形状，就知道这肯定是xxx编码转为yyy编码存储然后又用xxx来显示导致的。。。 从来没有去纠结到底为什么有这么多编码，到底为何需要转换？是怎么转换的？如何转换？为什么都通用utf-8还有很多新项目在用GBK呢？ 折腾了1个晚上，我明白了。。。以下我都用我自己理解的语言来描述下，分享下 ASCII编码 美国人发明计算机，美国人用八位表示1字节，8位的数据可以有2 8 =256 种状态描述事物。首先他添加进去了26个字母包括大小写，然后标点符号，换行符...然后用掉了128个，把这种做法取了个很吊名字叫『Ascii』，是『美国信息互换标准代码』的缩写。这也是我们小时候学习计算机的Ascii码表，当时貌似在C语言课本附录里面。 打印一个字符的Ascii码很简单 fmt.Printf("%d", 'A') GB系列编码 很明显，这个American Standard 从未考虑中国人的感受，你可以显示字母就完事了，中国的国粹汉字咋整？所以在中国的一群人开始做自己的编码，那是在1980年，做出来的是GB

最近项目中需要使用ffmpeg实现录音功能，使用的ffmpeg-3.4.4的库，根据源代码dshow.c中的定义 { "audio_device_number", "set audio device number for devices with same name (starts at 0)", OFFSET(audio_device_number), AV_OPT_TYPE_INT, {.i64 = 0}, 0, INT_MAX, DEC }, 在PC机存在两个麦克风设备的场合，添加一个[录音设备选择]对话框，可供用户选择。 打个比方：目前的PC机存在两个音频输入设备： 0：麦克风 (HD Webcam C270) 1：麦克风 (Realtek High Definition Audio) 备注： 0号采集设备可以采集音频与视频，不能播放音频；1号采集设备仅可以采集音频，可以播放音频。 PC机设备播放设备只有1个，那就是：麦克风 (Realtek High Definition Audio)，即为0号播放设备。 音频采集设备的序号与音频播放设备的序号很可能不一致。 如果指定 0号采集设备：麦克风 (HD Webcam C270)作为音频采集设备，简化代码如下： char *pchDeviceName = "麦克风 (HD Webcam C270)"; AVInputFormat

这几天在弄java读excel的问题，以前用的是jxl.jar来读的，后来发现无法读取2007的，于是研究了一下POI，在网上下了最新版的poi-bin-3.8-beta5-20111217.zip，同时也参考了网上其它人写的代码，在jboss7服务器下成功读出，发demo吧。 使用方法：jboss服务器或tomcat服务器，将下面的jsp文件保存到某个域名下，同时在此文件所在的目录中新建一个upload目录，然后将要读取的test.xls和test.xlsx放到upload目录下，然后运行jsp文件即可看到结果： （1）用poi.jar来读取excel2003 必须要用到的jar文件： poi-3.8-beta5-20111217.jar poi-ooxml-3.8-beta5-20111217.jar poi-ooxml-schemas-3.8-beta5-20111217.jar xmlbeans-2.3.0.jar dom4j-1.6.1.jar jsr173_1.0_api.jar （如果jdk是1.5版本则需要此jar，如果是1.6以上版本则不需要） 为了方便测试，代码为jsp，如下： [html] view plain copy print ? < %@ page contentType = "text/html; charset=gb2312" language =

chardet模块： --》检测编码格式 未知编码的bytes，要把它转换成str，就需要知道该bytes的编码方式 #1.直接检测bytes >>> chardet.detect(b'Hello, world!') {'encoding': 'ascii', 'confidence': 1.0, 'language': ''} 检测出的编码是ascii，confidence字段，表示检测的概率是1.0（即100%） #2.检测GBK编码的中文 >>> data = '离离原上草，一岁一枯荣'.encode('gbk') >>> chardet.detect(data) {'encoding': 'GB2312', 'confidence': 0.7407407407407407, 'language': 'Chinese'} 检测的编码是GB2312，注意到GBK是GB2312的超集，两者是同一种编码，检测正确的概率是74%，language字段指出的语言是'Chinese'。 来源： https://www.cnblogs.com/shaozheng/p/12011243.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"的页面中是空白