编码转换

Qt中文显示

╄→гoц情女王★ 提交于 2019-12-25 07:30:58
来自 http://lwr0312.blog.163.com/blog/static/483368072010103001811552/ QT默认的编码(unicode)是不能显示中文的,可能由于windows的默认编码的问题,windows默认使用(GBK/GB2312/GB18030),所以需要来更改QT程序的编码来解决中文显示的问题。 QT中有专门的一个类来处理编码的问题(QTextCodec)。 在QT3中,QApplication可以设置程序的默认编码,但是在QT4中已经没有了该成员函数。 可以以下的这些方法来设置编码。 1. 设置QObject的成员函数tr()的编码。 QTextCodec::setCodecForTr(QTextCodec::codecForName("GBK")); 其中的codecForName函数是根据参数中的编码名称,在系统已经安装的编码方案中需找最佳的匹配编码类型,该查找是大小写不敏感的。如果没有找到,就返回0。 具体的转换代码看下面: #include <QApplication> #include <QTextCodec> #include <QLabel> int main(int argc,char *argv[]) { QApplication app(argc,argv); QTextCodec::setCodecForTr

关于Redis中的字符串对象

北战南征 提交于 2019-12-25 04:50:01
一、SDS redis中定义Object types有5种 /* Object types */ #define REDIS_STRING 0 #define REDIS_LIST 1 #define REDIS_SET 2 #define REDIS_ZSET 3 #define REDIS_HASH 4 Objects encoding有9种  #define REDIS_ENCODING_RAW 0 /* Raw representation */ #define REDIS_ENCODING_INT 1 /* Encoded as integer */ #define REDIS_ENCODING_HT 2 /* Encoded as hash table */ #define REDIS_ENCODING_ZIPMAP 3 /* Encoded as zipmap */ #define REDIS_ENCODING_LINKEDLIST 4 /* Encoded as regular linked list */ #define REDIS_ENCODING_ZIPLIST 5 /* Encoded as ziplist */ #define REDIS_ENCODING_INTSET 6 /* Encoded as intset */ #define REDIS

【NOI2015】荷马史诗

Deadly 提交于 2019-12-25 00:44:42
   题目链接 https://www.luogu.org/problem/P2168    题目大意 是给定 n 个单词 的出现次数 wi ,求用 k 进制的前缀码转换后得到的最小总长度,以及在保证总长度最小时的最长串 si 的长度最短。   这题现在来看算是NOI里很简单的了(我竟然凹出来了w),但是据说当时这题可是难倒一大片。首先是因为这题题干太长不怎么容易看懂,另外可能是因为当时哈弗曼树还没有那么常见,几乎没人想到有哈弗曼树这么一个东西。   好,来看题。题目很明确,目标是要使编码之后的总长度最小,那么现在就要想着,怎样把出现次数多的编码长度尽可能的缩小。但是题目里有个限制:任意一个k进制编码都不是其它编码的前缀。这样一来,题目的做法就指向了哈弗曼树。    哈弗曼树与哈夫曼编码    这里简单重复一下 ——(证明过程引用自耿国华主编的《数据结构——C语言描述》)   哈夫曼树特性:从根结点到所有叶子结点的带权路径长度最短(就是权大的放靠近树根的地方)   做法:挑选序列里最小的2个点合并作为子节点,根节点的权值为他们的和,把根节点加入原序列,重复上述操作。   哈夫曼编码特性:1.它是前缀码。前缀码就是题目里给的那种,任何一个编码都不是其它编码的前 t 项。 证明:哈夫曼编码是根到叶子路径上的边的编码序列,也就是等价边序列,而由树的特点可知

音视频技术之直播架构

时光毁灭记忆、已成空白 提交于 2019-12-24 18:07:03
直播相关知识之一 基本架构 一. 引子-直播基本架构 下面是服务器的整体架构图: 上面上整体流程 相信一个开发者应该可以看的懂并理解吧! 主要分为四部分东西吧: 推流端SDK 负责 采集视频音频进行编码传输到服务端(某云), 服务端SDK负责 直播流的创建,分发到各个cdn节点,加快流的解析,以及各种流的管理统计等等 拉流端SDK负责 拉取流 进行解码解析 进行播放 本业务端负责 相关业务操作 比如授权地址 查询直播列表 等等 直播名词解释 1.推流 将直播内容推送至服务器的过程。 2.拉流 服务器已有直播内容,用指定地址进行拉取的过程。 3.RTMP协议 Real Time Messaging Protocol(实时消息传输协议)的首字母缩写。该协议基于TCP,是一个协议族,包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP是一种设计用来进行实时数据通信的网络协议,主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。 4.编码: H.264编码 是 高性能的视频编码技术,最大的优势是具有很高的数据压缩比率,能以较低的数据速率传送基于联网协议(IP)的视频流. 5.码率: 码率就是数据传输时单位时间传送的数据位数,一般我们用的单位是kbps即千位每秒。 6.FPS: 帧率(Frame rate

特征工程

百般思念 提交于 2019-12-24 17:51:42
转至博文:http://www.cnblogs.com/jasonfreak/p/5448385.html 知乎问答:https://www.zhihu.com/question/29316149 归一化,正则化:http://blog.csdn.net/u012102306/article/details/51940147 卡方检验:http://blog.csdn.net/sunshine_in_moon/article/details/45155803 目录 1 特征工程是什么? 2 数据预处理   2.1 无量纲化     2.1.1 标准化     2.1.2 区间缩放法     2.1.3 标准化与归一化的区别   2.2 对定量特征二值化   2.3 对定性特征哑编码   2.4 缺失值计算   2.5 数据变换 3 特征选择   3.1 Filter     3.1.1 方差选择法     3.1.2 相关系数法     3.1.3 卡方检验     3.1.4 互信息法   3.2 Wrapper     3.2.1 递归特征消除法   3.3 Embedded     3.3.1 基于惩罚项的特征选择法     3.3.2 基于树模型的特征选择法 4 降维   4.1 主成分分析法(PCA)   4.2 线性判别分析法(LDA) 5 总结 6 参考资料 1

setlocale与编码转换那些事

一笑奈何 提交于 2019-12-24 13:02:59
最近项目上调查printf语句不能正常格式化字符串的问题,做下总结。 以sprintf_s函数来说明问题的现象。 int sprintf_s( char *buffer, size_t sizeOfBuffer, const char *format [, argument] ... ); View Code 问题发生的条件 使用了setlocale format参数是utf8编码 format的%是非ASC字符,已locale编码来解释的话,刚好%与前面的编码结合,被当初了一个新的文字。 例如我们出问题时,locale是".ACP",也就是ANSI(CP932),format参数是"日付%04d/%02d/%02d 時刻%02d:%02d:%02d.%03d",UTF编码如下: 00000003h: E6 97 A5 E4 BB 98 25 30 34 64 2F 25 30 32 64 2F ; 譌・莉・04d/%02d/ 00000013h: 25 30 32 64 20 E6 99 82 E5 88 BB 25 30 32 64 3A ; %02d 譎ょ綾%02d: 00000023h: 25 30 32 64 3A 25 30 32 64 2E 25 30 33 64 ; %02d:%02d.%03d 其中日付对应的UTF8编码是 E6 97 A5 E4 BB 98

JavaScript 字符串处理详解

走远了吗. 提交于 2019-12-24 10:40:16
一、创建字符串 创建一个字符串,将一组字符串用引号包起来,将其赋值给一个字符串变量。 var JsStr="Hello,JavaScript String!"; 二、字符串查找方法 1.字符方法charAt(),charCodeAt(),fromCharCode() (1)charAt()函数 功能:返回字符串中指定位置的字符; 语法:String.charAt(n); 参数:n--字符在字符串中的位置(字符串第一个字符的位置为0); 返回值:返回n位置的字符,如果n不在0到(string.length-1)之间,将返回空字符串。 示例: (2)charCodeAt()函数 功能:返回指定位置的字符的Unicode编码; 语法:String.charCodeAt(n); 参数:n--字符在字符串中的位置(字符串第一个字符的位置为0); 返回值:返回n位置的Unicode编码(此编码为16位,在0-65536之间),如果n不在0到(string.length-1)之间,将返回NaN。 示例: (3)fromCharCode()函数 功能:接受指定的Unicode值,然后返回一个字符串; 语法:String.fromCharCode(numX,numX...); 参数:numX--必须值,一个或多个Unicode值,通过fromCharCode函数得到Unicode值得字符串; 返回值

python 编码问题 u'汉字'

本小妞迷上赌 提交于 2019-12-24 00:18:12
中文编码问题是用中文的程序员经常头大的问题,在python下也是如此,那么应该怎么理解和解决python的编码问题呢? python内部使用的是unicode编码,而外部却要面对千奇百怪的各种编码,比如作为中国程序经常要面对的gbk,gb2312,utf8等,那这些编码是怎么转换成内部的unicode呢? 首先我们先看一下源代码文件中使用字符串的情况。源代码文件作为文本文件就必然是以某种编码形式存储代码的,python默认会认为源代码文件是asci编码,比如说代码中有一个变量赋值: s1=’a’ print s1 python认为这个’a'就是一个asci编码的字符。在仅仅使用英文字符的情况下一切正常,但是如果用了中文,比如: s1=’哈’ print s1 这个代码文件被执行时就会出错,就是编码出了问题。python默认将代码文件内容当作asci编码处理,但asci编码中不存在中文,因此抛出异常。 解决问题之道就是要让python知道文件中使用的是什么编码形式,对于中文,可以用的常见编码有utf-8,gbk和gb2312等。只需在代码文件的最前端添加如下: # -*- coding: utf-8 -*- 这就是告知python我这个文件里的文本是用utf-8编码的,这样,python就会依照utf-8的编码形式解读其中的字符,然后转换成unicode编码内部处理使用。 不过

连接不同字符集编码Oracle问题处理过程

丶灬走出姿态 提交于 2019-12-23 20:14:06
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 近日某项目中碰到接口方Oracle字符集编码为US7ASCII,而我们自身Oracle字符集是ZHS16GBK. 此时我们的服务端连接接口取回来的数据显示为乱码. 接口方是不愿意修改Oracle字符集的. 我们使用的是ATL的Ole DB方式,另外使用的是Oralce Provider for OLE DB驱动. 以上为背景. Oracle字符编码涉及到Oracle客户端的字符编码有关 Oracle客户端编码与Oracle服务端编码一致时不会进行编码转换( Features of OraOLEDB ) 做了如下尝试: 0.修改连接串属性,增加 Auto Translate=False属性 ,无效 ( 因为原来有碰到过SQL Server乱码问题, 修改数据库连接串即可. Provider=SQLOLEDB.1;Password="xxx";Persist Security Info=True;User ID=xxx;Initial Catalog=xxx;Data Source=xxx; Auto Translate=False 参看链接如下: Character data is represented incorrectly when the code page of the client computer

POST 和 GET 区别

不想你离开。 提交于 2019-12-23 19:55:11
1 接口的作用和是否幂等 缓存 GET 读取“一个资源 反复读取不应该对访问的数据有副作用,没有副作用被称为“幂等“(Idempotent)。 因为GET因为是读取,就可以对GET请求的数据做缓存。这个缓存可以做到浏览器本身上(彻底避免浏览器发请求),也可以做到代理上(如nginx),或者做到server端(用Etag,至少可以减少带宽消耗) POST 修改一个资源 往往是有副作用的,不幂等的。 不幂等也就意味着不能随意多次执行。因此也就不能缓存。 后台服务处理的时候 应该把post接口特殊处理成 接口幂等,以避免重复提交的问题。 2 GET和POST携带数据的格式有区别 POST用body传输数据,而GET用url传输 3 安全性 我们常听到GET不如POST安全,因为POST用body传输数据,而GET用url传输,更加容易看到。但是从攻击的角度,无论是GET还是POST都不够安全,因为HTTP本身是 明文协议 。 每个HTTP请求和返回的每个byte都会在网络上明文传播,不管是url,header还是body 。这完全不是一个“是否容易在浏览器地址栏上看到“的问题。 为了避免传输中数据被窃取, 必须做从客户端到服务器的端端加密。业界的通行做法就是https ——即用SSL协议协商出的密钥加密明文的http数据。这个加密的协议和HTTP协议本身相互独立