编码

ANSI编码 最常见的应用就是在Windows当中的记事本程序中，当新建一个记事本，默认的保存编码格式就是ANSI，ANSI应该算是一种压缩编码了，当遇到标准的 ASCII字符 时，采用单字节表示，当遇到非标准的ASCII字符（如中文）时，采用双字节表示。 Unicode编码 标准已在近年来的多种新科技当中被加以采用，包含了可扩展置标语言（XML）、Java程序语言、以及最新的操作系统中。 下面用实验的方法来进行研究这两者之间的差别： 首先要准备的软件有UltraEdit，用于对文本进行比较；其次用于分析 网络字节序 的辅助网站 http://bm.kdd.cc/index.asp 步入正题，在一个空白的文件夹下创建一个记事本文档“新建 文本文档.txt”，在里面输入“宋体ABC(回车)”（不包含引号，最后要在ABC后输入一个回车），保存并关闭该文档，将此文件选中之后直接复制、粘 贴，在相同的文件夹下就产生了“复件 新建 文本文档.txt”，再次打开“新建 文本文档.txt”，选择菜单中的“文件”->“另存为”，在另存为对话框中，最下面有 “编码” ，选择Unicode。保存，选择替换。 然 后打开UltraEdit，在菜单中选择“文件”->“比较文件”(或直接按快捷键Alt+F11)，选择第一个要比较的文件为“新建 文本文档.txt”，选择第二个要比较的文件为“复件 新建

最近在整理各种裤子，由于太大用了ntfs-3g挂载硬盘，拷贝到了centos服务器上，结果没有注意文件名的编码问题，总要修改所以说config/i18n配置文件，而且通过ssh连接要经常切换客户端的字符集，无奈，拷回硬盘上，在window上弄吧，结果，文件名出现各种乱码。。。。崩溃了。安心学习了。。。 （其中涉及到了ntfs-3g，ssh远程客户端，以及linux的/etc/sysconfig/i18n配置，没有一一测试，除了ntfs-3g不知道是否涉及字符集，其他都涉及到了，思路比较乱，想到哪写到哪了） 问题根源：由于Linux与windows采用了不同的字符集来处理中文文件名，Linux用了utf-8而windows用了gbk，进而导致文件名处理的混乱。 我的做法是： 1、利用convmv 在linux上将所有文件名编码转换为gbk，再通过ntfs-3g将文件拷到移动硬盘，最后拷回电脑，在windows上能够正常显示。 2、处理文件 3、将文件拷回linux 4、利用convmv将文件名转回utf8 由于习惯了在windows上开发， 想自己写一个py脚本实现在windows上将文件名字符编码进行转换的功能，但是马上问题就出现了。 下面请看： def conv_gbk_to_utf8(path): if os.path.exists(path): print

如果你需要在Linux 中操作windows下的文件 ，那么你可能会经常遇到文件 编码 转换的问题。Windows中默认的文件 格式是GBK(gb2312)，而Linux 一般都是UTF-8。下面介绍一下，在Linux 中如何查看文件的编码及如何进行对文件进行编码转换。 查看文件编码 在Linux 中查看 文件编码可以通过以下几种方式： 1.在Vim 中可以直接查看 文件 编码 :set fileencoding 即可显示文件编码格式。 如果你只是想查看其它编码格式的文件, 或者想解决用Vim查看文件乱码的问题，那么你可以在~/.vimrc 文件 中添加以下内容： set encoding=utf-8 fileencodings=ucs-bom,utf-8,cp936 这样，就可以让vim自动识别文件编码 （可以自动识别UTF-8或者GBK编码的文件 ），其实就是依照fileencodings提供的编码列表尝试，如果没有找到合适的编码 ，就用latin-1(ASCII)编码打开。 2. enca 查看文件编码 如果你的系统中没有安装这个命令，可以用sudo yum install -y enca 安装 $ enca filename filename: Universal transformation format 8 bits; UTF-8 CRLF line

在前面其实也谈到了ASCII了，但并没有很具体，作为一个完整系列的一部分，还是有必要谈一下，也作为后面讨论的一些基础。 ASCII 它的全称是 A merican S tandard C ode for I nformation I nterchange（美国信息交换标准代码），是一个7位字符编码方案。下面是它的一张简图（来自 http://www.asciitable.com/index/asciifull.gif ）： ASCII定义了128个字符，包括33个不可打印的 控制字符(non-printing control characters) 和95个可打印的字符。 控制字符 32以下的及最后一个127是所谓的控制字符。（0x00~0x1F以及0x7F） 即上图最左边一列的32个字符及最右边一列最后的一个字符（DEL，删除） 熟悉的有0x09（TAB，horizontal tab，水平制表符），0x0A（LF，line feed，’\n’换行符），0x0D（CR，carriage return，’\r’回车符），其它的很多现在已经是废弃不用了。 关于回车换行(‘\r\n’)，在屏幕还不普及的时代，结果输出经常是依赖于所谓的电传打印机， 打印头 沿着打印杆从左向右移动并打印出一个个字符，当碰到一个回车符时（CR，0x0D，’\r’），打印机就指示打印头重新回到最左边的位置上

不管是C还是Java、还是JavaScript，难免会遇到需要编码解码的时候，比如需要跨平台或者处理一些敏感字符。下面说道说道JavaScript中几种编解码的方法。 1. escape() 和 unescape() escape() 函数可对字符串进行编码（ Unicode格式 ）。该方法不会对 ASCII 字母和数字进行编码，也不会对下面这些 ASCII 标点符号进行编码： * @ - _ + . / 。其他所有的字符都会被转义序列替换。 unescape() 函数可对通过 escape() 编码的字符串进行解码。 unescape 方法不应用于解码“统一资源标识符”(URI)。 var str='abcABC::////!!@@我是汉子'; escape(str);// "abcABC%3A%3A////%21%21@@%u6211%u662F%u6C49%u5B50" unescape(str);// "abcABC::////!!@@我是汉子" unescape("abcABC%3A%3A////%21%21@@%u6211%u662F%u6C49%u5B50");// "abcABC::////!!@@我是汉子" 2. encodeURI() 和 decodeURI() encodeURI() 函数可把字符串作为 URI 进行编码。 该方法不会对 ASCII

Base64是最常用的编码之一，比如开发中用于传递参数、现代浏览器中的<img />标签直接通过Base64字符串来渲染图片以及用于邮件中等等。Base64编码在RFC2045中定义，它被定义为：Base64内容传送编码被设计用来把任意序列的8位字节描述为一种不易被人直接识别的形式。 我们知道，任何数据在计算机中都是以二进制的方式存储的。一个字节为8位，一个字符在计算机中存储为一个或多个字节，比如英文字母、数字以及英文标点符号就是用一个 字节来存储的，通常称为ASCII码。而简体中文、繁体中文、日文以及韩文等都是用多字节来存储的，通常称为多字节字符。因为Base64编码是对字符串的编码表示进行处理的，不同编码的字符串的Base64的结果是不同的，所以我们需要了解基本的字符编码知识。 字符编码基础 计算机最开始只支持ASCII码，一个字符用一个字节表示，只用了低7位，最高位为0，因此总共有128个ASCII码，范围为0~127。后来为了支持多种地区的语言，各大组织机构和IT厂商开始发明它们自己的编码方案，以便弥补ASCII编码的不足，如GB2312编码、GBK编码和Big5编码等。但这些编码都只是针对局部地区或少数语言文字，没有办法表达所有的语言文字。而且这些不同的编码之间并没有任何联系，它们之间的转换需要通过查表来实现。 为了提高计算机的信息处理和交换功能

在之前的文章中，我们介绍过编码格式的发展史：[文章传送门-todo]。今天我们通过几个例子，来彻底搞清楚python3中的编码格式原理，这样你之后写python脚本时碰到编码问题，才能有章可循。 我们先搞清楚几个概念： 系统默认编码 ：指python解释器默认的编码格式，在python文件头部没有声明其他编码格式时，python3默认的编码格式是utf-8。 本地默认编码 ：操作系统默认的编码，常见的Windows的默认编码是gbk，Linux的默认编码是UTF-8。 python文件头部声明编码格式 ：修改的是文件的默认编码格式，只是会影响python解释器读取python文件时的编码格式，并不会改变系统默认编码和本地默认编码。 通过python自带的库，可以查看系统默认编码和本地默认编码 Python 3.7.4 (tags/v3.7.4:e09359112e, Jul 8 2019, 20:34:20) [MSC v.1916 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.getdefaultencoding() 'utf-8' >>> import locale >>> locale

在写这边文章时，在网上扒拉了很久，发现好多博客总结的都非常好，我也是参考了很多，在文章最后会列出一些觉得不错的博客地址，大家如果有兴趣可以去看看。 本篇主要是简单介绍Java编码知识，如果已经非常了解，可以手抖了，把宝贵时间用到看其他文章上面吧。 大家都知道中文需要编码后传输才不会有乱码，但是为什么要编码呢，因为计算机的一个最基本的存储单元byte无法表示一个中文字符，所以我们必须先把中文字符经过转换，转换成计算机能够表示的字符。当需要重新读取这些字符时，按照之前的转换规则，再转换回来就可以了。 这里的转换规则就是我们的所说的编码方式了，常见的有ASCII、ISO-8859-1、GB2312、GBK、UTF-8、UTF-16等。首先我们的字符在jvm都是Unicode编码，而上面的那些编码方式就是在传输时或显示时用什么样的编码方式。比如你把字符串以UTF-8编码方式转换成Unicode编码存储，然后等再次读取的时候还是采用UTF-8编码方式来反编码，就能获取到正确的字符。因为Unicode编码采用了世界统一的码表进行编码，因此相同的字符对应不同的系统或环境对应的Unicode码是一样的。 比如一个字符串“中国”，他的Unicode码是一定的，如果通过getBytes("GBK")方法，其中的内部逻辑就是首先“中国”的Unicode码转换成GBK编码，然后用GBK编码后的数据进行传递

描述： 本教程介绍如何使用cv_bridge将ROS图像转换为OpenCV图像，反之亦然，从而实现ROS和OpenCV的交互。 包括一个示例节点，可用作您自己节点的模板。 1.概念 sensor_msgs/Image 消息格式发布图像，但许多用户会希望将图像与OpenCV结合使用。 CvBridge是一个ROS库，提供ROS和OpenCV之间的接口。 可以在 vision_opencv v堆栈的 cv_bridge 软件包中找到CvBridge。 cv::Mat t格式。 同时，您还将学习如何将OpenCV图像转换为ROS格式，以便通过ROS发布图像消息。 2. 将ROS图像消息转换为OpenCV图像 要将ROS图像消息转换为cv :: Mat，模块cv_bridge.CvBridge提供以下功能： cv_image = bridge.imgmsg_to_cv2(image_message, desired_encoding="passthrough") 输入是图像消息，以及可选的编码。 编码引用目标cv :: Mat图像。 如果给出默认值“passthrough”，则目标图像编码将与图像消息编码相同。 图像编码可以是以下任何一种OpenCV图像编码 ： 8UC[1-4] 8SC[1-4] 16UC[1-4] 16SC[1-4] 32SC[1-4] 32FC[1-4] 64FC[1

一篇文章详解python的字符编码问题 一：什么是编码 　　将明文转换为计算机可以识别的编码文本称为“编码”。反之从计算机可识别的编码文本转回为明文为“解码”。 　　那么什么是明文呢，首先我们从一段信息说起，消息以人们可以理解，易懂的表示存在，我们把这个表示为明文（plain text）。对于说英文的人，纸张上打印的或者屏幕上显示的英文都算是明文。 二：都有什么编码格式？ 1：ASCII（占一个字符，只支持英文） 　　计算机上的数据都是以二进制的形式存储的，1个字节（8比特）可以表示256种状态，英文只有26个字符，再加上一些特殊的字符，使用128个就够了，计算机就可以使用127个不同字节来表示英文文字，这就是ASCII码 2：GB2312（占两个字符，支持6700+汉字） 　　计算机进入中国后，无法显示中文，一个字节已经被占满了，我国重新制定了一个编码表，将扩展的第八位对应的拉丁文全部删掉，规定一个小于127的字符与原来的意义相同，当两个大于127的字符连接在一起的时候，就表示一个汉字，前面一个字节为高字节，后面一个字节为低字节，这样就可以表示7000多汉字，这种编码叫做GB2312。GB2312是对ASCII的中文扩展 3：GBK和GB18030（GB2312的升级版，支持21000+汉字） 　　由于汉字的数量太大，GB2312是不能满足需求