编码

01、喷泉码简介喷泉码（Fountain Code）是一种在无线通信、数据传输和网络编码畛域中应用的谬误纠正技术。它与传统的纠错码和编码方法有所不同，喷泉码被设计用于在不确定信道条件下的高效数据传输。传统的纠错码（如海明码、RS码等）通常须要在发送方对数据进行编码，接管方则应用雷同的编码进行解码和纠错。这些办法个别具备固定的码率（Code Rate），即针对肯定长度的原始数据，编码后的长度是固定的，这些办法在面对不稳固的信道或重大的信道失落时可能成果不佳。相比之下，喷泉码通过在发送方生成随机的冗余数据，而后将其注入到原始数据中，以发明出一个“喷泉”流——相应的码率也也就不固定了。接管方能够从这个流中采样任意数量的数据包，并将它们合并以复原原始数据。喷泉码的一种常见利用是在无线传感器网络中，其中网络节点之间的通信可能受到弱信号、烦扰和多径流传等因素的影响。通过应用喷泉码，节点能够在较差的通信条件下实现牢靠的数据传输。喷泉码另外一个罕用的场景是大量文件或者数据的播送，这种时候每位接受者的丢包率是不确定的，因而固定码率的编码就不实用，喷泉码却能够解决该场景下的问题——丢包率高的接受者多收一些包，丢包率少的接受者则少收一些包。本文会介绍最常见的两种喷泉码实现，LT 编码 和 Raptor 编码。通过这两种编码的介绍和比拟能够比拟好的理解喷泉码的个性和根本的实现原理。 02、LT 编码LT 编码 是第一个被实现的具备实用价值的喷泉码，该编码在 2002 年被提出，实现记的基本原理也非常简单，即位运算中的 xor 操作。Xor 操作有如下的个性： 两个雷同的数据块 M，它们 Xor 的后果是 0。即 M ^ M = 0。对一块数据块 M，Xor 两次雷同的数据块 N，最终后果依然为 M。即 M ^ N ^ N = M。假如两个等长的数据块 M 和 N，M ^ N = L。那么 L ^ M = N 并且 L ^ N = M。基于上述的个性，LT 编码的形式就能够形容为下列的步骤： 对于长度为 N 的等宽数据块序列，随机选取一个 degree (d)，1 ≤ d ≤ N。从上述的数据块中选取随机 d 个数据块，将所有选取的数据块进行 xor 操作，最终失去一个编码的数据块。反复上述步骤 1 和 2，咱们能够失去源源不断的编码数据块，如同“喷泉”一样水流一直。编码过程很简略，惟一须要留神一下的问题是如何取得等款的数据块。如果总数长度不可能凑巧分成 N 等分，咱们能够通过在后续加 padding 的形式来实现能够 N 等分。解码绝对比较复杂， 形容如下： ...

一 前言对于一个类别特色，如果这个特色的取值十分多，则称它为高基数（high-cardinality）类别特色。在深度学习场景中，对于类别特色咱们个别采纳Embedding的形式，通过预训练或间接训练的形式将类别特征值编码成向量。在经典机器学习场景中，对于有序类别特色，咱们能够应用LabelEncoder进行编码解决，对于低基数无序类别特色（在lightgbm中，默认取值个数小于等于4的类别特色），能够采纳OneHotEncoder的形式进行编码，然而对于高基数无序类别特色，若间接采纳OneHotEncoder的形式编码，在目前成果比拟好的GBDT、Xgboost、lightgbm等树模型中，会呈现特色稠密性的问题，造成维度劫难， 若先对类别取值进行聚类分组，而后再进行OneHot编码，尽管能够升高特色的维度，然而聚类分组过程须要借助较强的业务教训常识。本文介绍一种针对高基数无序类别特色十分无效的预处理办法：平均数编码（Mean Encoding）。在很多数据挖掘类比赛中，有许多人应用这种办法获得了十分优异的问题。 二 原理平均数编码，有些中央也称之为指标编码（Target Encoding），是一种基于指标变量统计（Target Statistics）的有监督编码方式。该办法基于贝叶斯思维，用先验概率和后验概率的加权平均值作为类别特征值的编码值，实用于分类和回归场景。平均数编码的公式如下所示： 其中： 1. prior为先验概率，在分类场景中示意样本属于某一个\_y\_\_i_的概率 其中\_n\_\_y\_\_i\_示意y =\_y\_\_i_时的样本数量，\_n\_\_y_示意y的总数量；在回归场景下，先验概率为指标变量均值： 2. posterior为后验概率，在分类场景中示意类别特色为k时样本属于某一个\_y\_\_i_的概率 在回归场景下示意 类别特色为k时对应指标变量的均值。 3. __为权重函数，本文中的权重函数公式相较于原论文做了变换，是一个枯燥递加函数，函数公式： 其中 输出是特色类别在训练集中呈现的次数n，权重函数有两个参数： ① k：最小阈值，当n = k时，__= 0.5，先验概率和后验概率的权重雷同；当n < k时，__\> 0.5, 先验概率所占的权重更大。 ② f：平滑因子，控制权重函数在拐点处的斜率，f越大，曲线坡度越缓。上面是k=1时，不同f对于权重函数的影响： 由图可知，f越大，权重函数S型曲线越缓，正则效应越强。 对于分类问题，在计算后验概率时，指标变量有C个类别，就有C个后验概率，且满足 一个 \_y\_\_i_ 的概率值必然和其余 \_y\_\_i_ 的概率值线性相关，因而为了防止多重共线性问题，采纳平均数编码后数据集将减少C-1列特色。对于回归问题，采纳平均数编码后数据集将减少1列特色。 三 实际平均数编码不仅能够对单个类别特色编码，也能够对具备层次结构的类别特色进行编码。比方地区特色，国家蕴含了省，省蕴含了市，市蕴含了街区，对于街区特色，每个街区特色对应的样本数量很少，以至于每个街区特色的编码值靠近于先验概率。平均数编码通过退出不同档次的先验概率信息解决该问题。上面将以分类问题对这两个场景进行开展： 1. 单个类别特色编码： 在具体实际时能够借助category_encoders包，代码如下： import pandas as pdfrom category_encoders import TargetEncoderdf = pd.DataFrame({'cat': ['a', 'b', 'a', 'b', 'a', 'a', 'b', 'c', 'c', 'd'], 'target': [1, 0, 0, 1, 0, 0, 1, 1, 0, 1]})te = TargetEncoder(cols=["cat"], min_samples_leaf=2, smoothing=1)df["cat_encode"] = te.transform(df)["cat"]print(df)# 后果如下： cat target cat_encode0 a 1 0.2798011 b 0 0.6218432 a 0 0.2798013 b 1 0.6218434 a 0 0.2798015 a 0 0.2798016 b 1 0.6218437 c 1 0.5000008 c 0 0.5000009 d 1 0.6344712. 层次结构类别特色编码： ...

编码的重要作用计算机只能解决数字，如果想让计算机解决人类语言，则须要将字符转换为数字，而计算机编码就是将字符转换为数字的过程。 编码还能够用于压缩数据，以便更无效地存储和传输数据。常见的编码方式ASCII 码ASCII 码，能够示意 128 个字符，用一个字节的低 7 位示意，0 ～ 31 是控制字符，比方 换行、回车、删除 等；32~126 是打印字符，能够通过键盘输入并且可能显示进去。 ISO-8859-1128 个字符显然是不够用的，于是 ISO 组织在 ASCII 码根底上又制订了一些列规范用来扩大 ASCII 编码，它们是 ISO-8859-1 ~ ISO-8859-15，其中 ISO-8859-1 涵盖了大多数西欧语言字符，所以利用的最宽泛。ISO-8859-1 依然是单字节编码，它总共能示意 256 个字符。 GB2312全称是《信息替换用汉字编码字符集 根本集》，它是双字节编码，总的编码范畴是 A1-F7，其中从 A1-A9 是符号区，总共蕴含 682 个符号，从 B0-F7 是汉字区，蕴含 6763 个汉字。 GBK全称是《汉字内码扩大标准》，是国家技术监督局为 windows95 所制订的新的汉字内码标准，它的呈现是为了扩大 GB2312，退出更多的汉字，它的编码范畴是 8140~FEFE（去掉 XX7F）总共有 23940 个码位，它能示意 21003 个汉字。 GBK 兼容 GB2312，也就是说用 GB2312 编码的汉字能够用 GBK 来解码，并且不会有乱码。GB18030全称是《信息替换用汉字编码字符集》，是我国的强制规范，它可能是单字节、双字节或者四字节编码。 尽管是国家标准，然而理论利用零碎中应用的并不宽泛。 GB18030 兼容 GB2312。UTF-16说到 UTF 必须要提到 Unicode（Universal Code 对立码），ISO 试图想创立一个全新的超语言字典，世界上所有的语言都能够通过这本字典来互相翻译。Unicode 能够表白的字符十分多，须要用多个字节来存储。 ...

sjmj 《数据密集型利用零碎设计》 - 数据编码和演变前言本章的前半部分提到的编码框架目前在GO畛域蛟龙得水，并且有不少成熟的产品诞生，如果是GO工作者必然会接触，如果仅仅是试图理解该畛域设计的一些技术架构，这一章更多的是扫盲和拓展眼界。 本章节的后半局部探讨的RPC和SOAP，以及基于WebService服务跨语言通信服务，和RPC通信协议，然而WebService这货色当初用的人越来越少，反观微服务才是以后的支流。 尽管须要住的是尽管HTTP/2曾经进去不少年头的了，然而RPC仍然占有重要的比重，所以也是值得关注的，最为典型的当然是Dubbo框架。 为什么HTTP2.0都进去了，RPC还在持续倒退呢？因为HTTP2.0 刚刚公布的时候，RPC曾经具备相当的倒退，技术也绝对成熟，另外很多我的项目零碎架构曾经齐全搭建，换回HTTP2费劲不讨好，自身也没有必要，因为RPC协定没有特地大的缺点。并且领有不错的个性 。章节介绍从历史的演变的角度来看，尽管过来呈现过许多尝试代替HTTP协定的WEB通信框架，然而市场总是须要稳固成熟的架构，这些新兴通信协议最终都默默黯淡在历史的长河之中。 零碎的演进除了数据结构和数据模型自身的演变之外，数据编码和数据之间的交互模式也在一直的进行演变，数据模式和格局扭转的时候，通常须要应用程序的对应扭转，而利用零碎的痛点如下： 新版本的部署须要滚动降级（分阶段下线节点而后有序上线），通过这样的形式能够对于大规模降级的零碎能够实现不暂停降级。客户端应用程序须要依赖用户自行进行更新，或者应用强制更新伎俩强制降级。这样的应用程序调整不可避免的带来关键性问题：前后兼容。 什么是前后兼容？ 向后兼容：较新的代码由旧代码编写的数据。 向前兼容：比拟旧的代码能够读取新编写的数据。 向后兼容不是难事，因为在原有的根底上扩大。向前兼容比拟难，须要对于旧代码疏忽新代码的增加。 尽管当初支流的传输构造是应用JSON，然而在这一章节将会扩大更多的数据编码格局介绍，后面两种无需过多介绍，这一章节次要介绍了前面三种针对数据编码而存在相似中间件的框架： JSONXMLProtocol BufferThriftAvro数据编码格局数据表现形式无非两种： 内存中数据保留对象，构造体、列表、数组、哈希表和树结构等等，传统的数据结构对于CPU高效拜访优化。数据写入文件通过网络发送，必须要编码为某种字节序列，然而因为一些虚构字节比方指针的存在所以和内存的表现形式有可能不一样。术语问题，这里的编码其实就是指的“序列化”，然而序列化在不同的构造中意义不同，所以书中用了编码解释这一概念。语言特定格局通常有不少的编程语言反对把内存的对象编码为字节序列码，比方经典的Java.io.Serializable，Ruby的 Marshal，Python的 picle ，还有一些第三方库比方 Kryo。 然而语言的特定格局带来上面的一些问题： 编码和特定语言绑定，无奈实现不同编程语言互通。复原数据的时候须要解码并且实例化对应实现类，序列化存在序列化攻打隐患，比方通过实例化异样对象的形式找到零碎的破绽攻打伎俩。简略疾速编码在编程语言经常导致前后兼容问题。JAVA的官网序列化低效被人诟病等。JSON、XML以及二进制二进制编码目前零碎较为支流的模式是JSON， 而过来XML也风行过一段时间，然而起初很快被更为轻便的JSON取代，JSON最早是呈现在JS上的一种数据结构，起初被宽泛采纳在不同零碎之间的通信格局，至今仍然流行。 XML和JSON的最大益处是应用字符串进行传输，并且JSON是JS内置的浏览器反对，具备很强的兼容性。 然而XML和JSON也暴露出不少问题： 数字编码问题：JSON中无奈辨别数字和碰巧是数字的字符串，尽管JSON能辨认出数字和字符串，然而无奈辨别数字的精度，也就是浮点数。针对浮点数问题，IEEE 754 双精度浮点数在JS上精度不佳。在推特中已经有精度失落的例子，2的53次方会导致一部分数据失落而产生数据不精确问题，基本问题是应用了64位的数字去示意推文内容在JS中产生溢出！为了解决此问题推特最终应用了拆分小数位和整数位，以及应用字符串代替数字的形式示意一个数字，避开了JS语言的缺点问题。JSON和XML对于文本反对较好，可浏览性很强，BASE64编码之后能够解除数据传输失落的危险，然而与此同时也会带来数据大小收缩问题。XML和JSON都有模式可选反对，通常状况下大部分的编程语言能够通用编解码形式，然而对于不应用这两种编码格局的则须要本人编写。CSV没有模式，他只是介于二进制和文本之间的一种非凡状态，每一次数据改变都须要手动改变文件。上面来探讨二进制编码问题。 二进制编码的劣势在于数据体积小并且传输快，然而二进制真的和JSON文本的差别很大么？ 咱们能够看到上面的编码案例： 原始字符串内容如下，如果是传统的编码格局，上面的JSON字符串去掉空格须要80多个字节 在书中的案例中，通过二进制编码的数据仅仅比JSON编码格局放大了10几个字节，比方上面的编码格局，仅仅比下面的原始JSON缩短了10多个字节，是否意味着在较小文本传输的时候优化编码大小的性价比是很低的？ 通过二进制编码框架解决之后，能够精简到32个字节甚至更小，约等于压缩了50%甚至更高的内容。 二进制编码框架定位为了解决二进制编码的性能远不如文本JSON的问题，在数据编码和模式呈现了演进和深入研究。要更好地了解二进制编码框架，咱们须要理解他们的定位。 模式框架的设计了解根本和TCP/IP协定面对的问题相似，在差别不同的利用零碎之间如何实现对立格局通信，并且在不同利用系统升级之后能以最小的老本实现向前兼容。 为了更加透彻的理解Thirft以及一系列数据编码框架的设计定位，咱们来看看Thrift的设计思维： Thrift软件栈分层从下向上别离为：传输层(Transport Layer)、协定层(Protocol Layer)、解决层(Processor Layer)和服务层(Server Layer)。 传输层(Transport Layer)：传输层负责间接从网络中读取和写入数据，它定义了具体的网络传输协定；比如说TCP/IP传输等。协定层(Protocol Layer)：协定层定义了数据传输格局，负责网络传输数据的序列化和反序列化；比如说JSON、XML、二进制数据等。解决层(Processor Layer)：解决层是由具体的IDL（接口描述语言）生成的，封装了具体的底层网络传输和序列化形式，并委托给用户实现的Handler进行解决。服务层(Server Layer)：整合上述组件，提供具体的网络线程/IO服务模型，造成最终的服务。Thrift 和 Protocol BufferApache Thrift 和 Protocol Buffer 基于雷同原理二进制编码，而Protocol 最开始由谷歌开发， Thrift 最后由 Facbook 开发，前面被 Apach 引进并且成为顶级我的项目。（老接盘侠了） Thrift是Facebook于2007年开发的跨语言的rpc服框架，提供多语言的编译性能，并提供多种服务器工作模式；用户通过Thrift的IDL（接口定义语言）来形容接口函数及数据类型，而后通过Thrift的编译环境生成各种语言类型的接口文件，用户能够依据本人的须要采纳不同的语言开发客户端代码和服务器端代码。两者的共同点是都须要应用模式进行编码，所谓模式就是指如果通过语法来形容数据结构，须要依照指定的标准。 另外通过模式定义之后两者都能够通过代码生成器生成相干的对象代码，反对多种编程语言，利用代码生成器生成的代码能够实现对应的编码和解码操作。 在Thirft 介绍一句话能够看到它最为根本的限度： To generate the source from a thrift file run有时候编码框架可能具备多种编码方式，比方Thrift 分为BinaryProtocol和 CompareProtocol。 ...

请点赞关注，你的反对对我意义重大。 Hi，我是小彭。本文已收录到 GitHub · Android-NoteBook 中。这里有 Android 进阶成长常识体系，有气味相投的敌人，关注公众号 [彭旭锐] 带你建设外围竞争力。 前言在日常开发过程中，Unicode & UTF-8 并不是很受关注的常识，但在浏览源码或文章时，呈现频率很高。如果你没有了解分明 Unicode、UTF-8、UTF-16 和 UTF-32 之前的关系，会带来阅读障碍。在这篇文章里，我将带你了解 Unicode 字符集的原理，心愿能帮上忙。 1. 什么是字符编码1.1 什么是字符？字符（Character） 是对文字和符号的总称，例如汉字、拉丁字母、emoji 都是字符。在计算机中，一个字符由 2 局部组成： 1、用户看到的图画2、字符的编码你常常会在很多词语上看到 “编码” 这个单词，对初学者来说很容易混同。明天我列举出 “编码” 常见的 3 层解释，心愿能帮忙你当前在阅读文章时疾速了解作者的意思。 含意 1 - 作为动词： 示意把一个字符转换为一个二进制机器数的过程，这个机器数才是字符在计算机中实在存储/传输的格局。例如把 A 转换为 65(ASCII) 的动作，就是一个编码动作；含意 2 - 作为名词： 示意通过编码动作后失去的那个机器数，对于 A 来说，65(ASCII) 就是 A 的编码(值)，有时会称为编号；含意 3 - 作为名词： 示意把字符转换为机器数的编码方案，例如 ASCII 编码、GBK 编码、UTF-8 编码。1.2 什么是字符集字符集（Character Set） 是多个字符与字符编码组成的零碎，因为历史的起因，已经倒退出多种字符集，例如： 字符集一多起来，就容易呈现兼容问题： 即同一个字符在不同字符集上对应不同的字符编码。 例如，最早的 emoji 在日本的一些手机厂商发明并流行起来，使得 emoji 在不同厂商的设施间无奈兼容。要想正确解析一个字符编码，就须要先晓得它应用的字符编码集，否则用谬误的字符集解读，就会呈现乱码。设想以下，你发送的一个在女朋友的手机上看到的是另一个 emoji，是一件如许可怕的事件。 ...

作者：Ravi Malhotra 2022年5月3日 用于在更大、更高分辨率设施上播放的高清视频内容的增长，推动了对 H.265 等更高效视频编解码器的需要。尽管带宽效率是较旧的 H.264 编解码器的两倍，但 H.265 须要耗费更高的计算资源来提供这种效率。管制老本（例如，带宽应用）当初是视频开发人员提到的头等挑战[1]，这使得 H.265 具备吸引力。然而，如果较低的带宽老本被较高的计算和电力老本所取代，视频开发人员相当于在原地踏步。他们须要的是一个解决方案，该解决方案能够提供 H.265 效率，而仅仅破费较少的计算和电力代价。本博客认为基于 Arm Neoverse 的 Ampere Altra Max 服务器正是视频开发人员编码 H.265 视频流所需的解决方案。 背景介绍在过来的几年里，因为更好的相机和更大、更高分辨率的设施，高分辨率视频内容的产生和生产都在稳步增长。与 H.264 等传统编解码器相比，H.265/HEVC、VP9 或 AV1 等更先进的编解码器在压缩更高分辨率内容方面的效率晋升超过 50%。最近的市场钻研表明，这种增长转化为这些编解码器的使用量的显著减少，其中 H.265 处于当先的地位。 图 1:Bitmovin 2021 对于生产畛域应用的视频编解码器报告（2020 年与 2021） Netflix 和 Amazon Prime 等流媒体服务的风行也推动了对高分辨率视频内容的需要。吸引和留住客户只会减少这种需要。因而，视频上传和接管（带宽需要）以及视频转码和解决（计算需要）在视频解决平台中占据最大份额也就难能可贵了[2]。 图 2：2020 年按利用划分的视频解决平台市场份额 H.265 的改良压缩带来了更高计算复杂度，这可能比 H.264 高出一个数量级（10 倍）。尽管基于云的编码的应用正在增长，但大多数视频编码依然是一项预处理工作[1]。因而，H.265 编码减少的计算需要（资本收入老本）和功耗（经营老本）对大多数视频开发人员来说是一个挑战。因而，在性能更高、能效更高的服务器上进行编码是很重要的。 技术媒体曾经在 SPECrate®2017 Integer 等通用基准上验证了 Ampere Altra Max 绝对于传统架构的性能和能效劣势[3]。Ampere Altra Max 领有128 个 Arm Neoverse N1 内核 @3.0Ghz，性能优于英特尔至强“Ice-Lake”和 AMD EPYC“Milan”CPU，后者的功耗（TDP）要高得多。在这个博客中，咱们展现了 Ampere Altra Max 的这些性能和能效劣势也扩大到了 H.265 等视频编码利用中。 ...

视频编码的目标是为了压缩原始视频，压缩的次要思路是从空间、工夫、编码、视觉等几个次要角度去除冗余信息。因为 H.264 杰出的数据压缩比率和视频品质，成为以后市场上最为风行的编解码规范。而 H.265 是在 H.264 的根底上，保障雷同视频品质的同时，视频流的码率还能够缩小50%。随着H.265编码格局越来越风行，本文将次要介绍 H.265 的编码原理，以下是 H.265 的编码框架流程图。 01 编码构造H.265在编码构造上分为视频编码层（VCL）和网络提取层（NAL）。 VCL：Video Coding Layer，次要包含视频压缩引擎和图像分块的语法定义，原始视频在 VCL 层，被编码成视频数据。简略版本的编码过程如下：将每一帧的图像分块，将块信息增加到码流中；对单元块进行预测编码，帧内预测生成残差，帧间预测进行静止预计和静止弥补；对残差进行变换，对变换系数进行量化、扫描。对量化后的变换系数、静止信息、预测信息等进行熵编码，造成压缩的视频码流输入。NAL：Network Abstraction Layer，次要定义数据的封装格局，把 VCL 产生的视频数据封装成一个个 NAL 单元的数据包，适配不同的网络环境并传输。02 分块从编码程序和构造上讲，H.265首先将一个视频划分成若干个序列，一个序列划分成若干个图像组（GOP），每一个GOP代表一组间断的视频帧。H.265 在对图像做预测编码和变换编码时，会先对图像进行划分，划分形式是四叉树。在划分四叉树时，会将整个视频帧划分成若干个正方形的编码树块（CTB），CTB 能够持续划分成编码块（CB），CB 还能够划分为预测块（PB）和变换块（TB）。因而，H.265对视频的构造划分如下图所示： 同一地位处的一个亮度 CB 和两个色度 CB ，加上一些相应的语法元素，组成一个编码单元（CU）。CU 是决定进行帧内预测、帧间预测、Skip/Merge模式的单元。 同一地位处的一个亮度 CTB 和两个色度 CTB ，加上一些相应的语法元素，和蕴含的 CU ，组成一个编码树单元（CTU）。CTU 相当于 H.264 中的宏块，区别是 CTU 的尺寸是由编码器制订，最大能够反对到 64x64，最小能够反对到 16x16。而宏块的大小固定为 16x16。 一个 CTU 在进行编码时，依照深度优先的程序进行 CU 编码，像数据结构中的四叉树一样，一个大的方块代表父节点，外面有四个小方块别离代表四个子节点。 03 预测视频的实质是由一系列间断的视频帧组成，在单个视频帧外部和多个视频帧之间都存在大量的冗余。从空间的角度看，单个视频帧外部的像素点之间的像素值相差很小。从工夫的角度看，两个间断的视频帧之间也有很多雷同的像素点。预测编码就是基于图像统计个性进行数据压缩的一种办法，利用了图像在工夫和空间上的相关性，通过曾经重建的像素数据预测以后正在编码的像素。 3.1 帧内预测 帧内预测是指用于预测的像素和以后正在编码的像素都在同一个视频帧内，并且个别都在邻近的区域内。因为邻近的像素之间有很强的相关性，像素值个别都十分靠近，产生渐变的概率十分小，差值都是0或者十分小的数。所以，帧内预测编码后传输的是预测值和实在值之间的差值，即0左近的值，叫做预测误差或残差，这样就用较少的比特传输，达到压缩的成果。 H.265帧内预测编码以块为单位，应用相邻曾经重建的块的重建值对正在编码的块进行预测。预测重量分为亮度和色度两个，对应的预测块别离是亮度预测块和色度预测块。为了适应高清视频的内容特色，进步预测精度，H.265采纳了更加丰盛的预测块尺寸和预测模式。 H.265亮度预测块的尺寸在4*4到32*32之间，所有尺寸的预测块都有35种预测模式，这些预测模式能够分为3类：立体（Planar）模式、直流（DC）模式和角度（Angular）模式。 Planar模式：亮度模式0，实用于像素值变换迟缓的区域，例如像素突变的场景。对预测块中的每个像素都应用不同的预测值。预测值等于：该像素在程度和垂直两个方向线性插值的平均值。DC模式：亮度模式1，实用于图像的大面积平坦区域，该模式对预测块中的所有像素都应用雷同的预测值。如果预测块是正方形，预测值等于右边和上边的参考像素的平均值；如果预测块是长方形，预测值等于长的那一边的平均值；角度模式：亮度模式2~34，总共33个预测方向，其中模式10是程度方向，模式26是垂直方向。角度模式每个像素的预测值都是从对应预测方向前曾经重建的像素集的样值进行程度或垂直方向偏移角度预测。 因为黑白视频中，雷同地位的色度信号和亮度信号的特色相似，因而色度预测块和亮度预测块的预测模式也相似。H.265中色度预测块的预测模式有Planar模式、垂直模式、程度模式、DC模式和导出模式5种： Planar模式：色度模式0，和亮度模式0一样。垂直模式：色度模式1，和亮度模式26一样。程度模式：色度模式2，和亮度模式10一样。DC模式：色度模式3，和亮度模式1一样。导出模式：色度模式4，采纳和对应亮度预测块雷同的预测模式。如果对应的亮度预测块模式是0、1、10、26中的一种，则替换为模式34。3.2 帧间预测 ...

简介：相似于“防御性驾驶”对驾驶平安的重要性，防御性编码目标概括起来就一条：将代码品质问题毁灭于萌芽。要做到“防御性编码”，就要求咱们充分认识到代码品质的严肃性，也就是“一旦你感觉这个中央可能出问题，那根本它就会（在某个时刻）出问题”。当然，理论状况比这个更严厉。因为大家的编码教训和格调差别，导致大家的意识边界是大小不一的，那些埋伏在意识边界之外的“危险”更加荫蔽和不可推敲。在意识层面上，咱们当然要摒弃“想当然”和“差不多”的思维，庄重评估这些问题产生的可能性，认真对待这些危险。但如若话题止步于此，那其实还是不足执行层面的指导意义的，激不起半点“涟漪”的。这个文章目标也更多是关注到“实操层面”的疏导 作者 | 字白起源 | 阿里开发者公众号 一 防御性编码的意义相似于“防御性驾驶”对驾驶平安的重要性，防御性编码目标概括起来就一条：将代码品质问题毁灭于萌芽。要做到“防御性编码”，就要求咱们充分认识到代码品质的严肃性，也就是“一旦你感觉这个中央可能出问题，那根本它就会（在某个时刻）出问题”。当然，理论状况比这个更严厉。因为大家的编码教训和格调差别，导致大家的意识边界是大小不一的，那些埋伏在意识边界之外的“危险”更加荫蔽和不可推敲。 在意识层面上，咱们当然要摒弃“想当然”和“差不多”的思维，庄重评估这些问题产生的可能性，认真对待这些危险。但如若话题止步于此，那其实还是不足执行层面的指导意义的，激不起半点“涟漪”的。 这个文章目标也更多是关注到“实操层面”的疏导。 二 如何防御性编码？以下需关注的具体方面更多来自于我的习惯和察看，并且对立用伪代码作问题示例。 欢送大家把本人的“防御性编码心得”在评论区分享进去。 1 并发抵触问题这个问题在理论我的项目中，被谬误地漠视的比例相当高。它的外在表现形式形形色色，但关键点是：“当你的代码被并发调用时，它会怎么体现？” 咱们心里要有个运行时的世界观，代码运行的Context是这样的：多线程 -> 多过程 -> 多机器 -> 多集群。咱们编码时，要充分考虑代码在上述世界观多点并发的可能性，及相应的潜在结果。 举几个具体的问题例子)： 存在共享变量 或者 数据。（不限于堆内存，也可能是缓存、DB、文件等） 例子1： 有线程 A 和线程 B 两个线程，须要更新「同一条」数据，会产生这样的场景：1、线程 A 更新数据库（X = 1）2、线程 B 更新数据库（X = 2）3、线程 B 更新缓存（X = 2）4、线程 A 更新缓存（X = 1）最终 X 的值在缓存中是 1，在数据库中是 2，产生不统一。例子2： // 某个 Spring singleton Bean 'aService' 存在一个调用起源标记，记录调用起源是HSF还是HTTP。// 先 记录起源标记。aService.setSource(source);// 再联合source执行其余逻辑。例如将下面记录的source 和 其余参数 插入数据库.aService.doSomethings(params);如果这个代码被 HSF和 HTTP 同时调用就会产生问题。 ...

在开始之前，让咱们回顾一下万恶之源： 把大象装进冰箱须要几步？应该有很多计算机系的敌人对这个问题印象粗浅吧，它是大部分大学在传授面向对象这门课程时用来抛砖引玉的第一问。 而咱们通常会失去两个答案： 须要三步，先关上冰箱门，而后把大象放进冰箱，而后关上冰箱门。须要三步，冰箱打开门，大象走进冰箱，冰箱关上门。上述两种答案，实质上是思维的不同，第一种答复是站在第一人称的视角来扫视问题，这种思考形式咱们称其为 过程事务脚本 。 而第二种答复则是别离站在不同 事物 的视角上对待问题，这种思考形式咱们称其为 面向对象思维 。 过程事务脚本，其实就是对问题解决流程的列举，益处是有的，例如不须要额定的思考老本，写起来简略，入门门槛低等等等等。但从复杂度和事务倒退的客观规律来看，它不是最合适的。 注：‘事物倒退的客观规律’ 就是指事物往简单、熵增的方向倒退。 为什么这么说，让咱们来看一个理论的问题。 从问题登程假如咱们要开发一个商城零碎，在设计初期，产品给出了上面需要： 用户提交订单后，后盾计算订单商品总金额，保留订单商品条目快照，锁定库存而后生成订单并回显。于是研发部依据需要写出了第一版程序： class OrderService is method createOrder(createOrderInputDto): Order is // 从订单创建对象中解构所须要的数据 // 计算订单总金额 // 保留订单商品条目快照 // 锁定库存 // 创立订单并返回程序上线后，因为用户激增，单体式利用很快便满足不了宏大的用户量的需要，于是产品部要求研发部进行服务拆分，进一步晋升零碎并发申请量，而后第二版程序就进去了： class OrderService is method createOrder(createOrderInputDto): Order is // 从订单创建对象中解构所须要的数据 // + 调用近程服务获取商品数据 // 计算订单总金额 // 保留订单商品条目快照 // - 锁定库存 // + 调用仓储服务锁定库存 // 创立订单并返回忽然有一天，经营一拍大腿，决定搞一个优惠活动： 用户生产时，依据用户会员等级和单笔生产金额进行返利，返利间接补贴进单笔生产订单总金额中，并且容许用户能够应用优惠券叠加计算优惠金额。繁忙的程序猿们再次扛起键盘筹备战斗，于是最新的程序又进去了： class OrderService is method createOrder(createOrderInputDto): Order is // 从订单创建对象中解构所须要的数据 // 调用近程服务获取商品数据 // + 调用近程服务获取用户会员等级权利信息 // 计算订单总金额 // + 计算会员等级优惠及返利 // + 再次计算订单总金额 // + 计算叠加优惠券后的金额 // 保留订单商品条目快照 // 锁定库存 // 调用仓储服务锁定库存 // 创立订单并返回在这之后，脑洞大开的经营时不时会想到一些离奇的创意，研发部门充斥了高兴的空气... ...

阿里云智能编码插件（Alibaba Cloud AI Coding Assistant）是一款AI编程助手，它提供代码智能补全和代码示例搜寻能力，帮忙你更快更高效地写出高质量代码，让你的开发过程既高效又轻松。 点击立刻体验 阿里云智能编码 你是否还在为从天而降的需要焦头烂额？ 你是否还在为写不完的业务代码熬灯苦做？ 我懂你啊，我看到下面这两行字曾经开始PTSD了……）（表情包是家猫，请哂纳） ———————————跑题了，拉回来——————————— 好消息！好消息！阿里云AI智能编码助手 aka Alibaba Cloud AI Coding Assistant（小名儿Cosy）横空出世！ (IntelliJ插件市场中搜两个英文名字都能够找到哦⬆️)只愿能做你漫漫开发长路上踏着七彩祥云的霸王防脱，你就只管沉迷在IDE里，你想要的其余信息都由它来搞定。 阿里云智能编码插件性能介绍1、代码智能补全 基于世界领先的深度学习模型，为你提供智能、精确的行级代码补全，让编码如行云流水般天然和高效。代码补全齐全运行在本地，你能够在任何状况下无忧应用。 理解更多 2、代码示例搜寻 提供API代码示例搜寻性能，让你在面对不相熟的API时，无需跳出到浏览器中，在IDE内即可参考海量高质量的开源API代码示例，为你打造沉迷式编码体验。 理解更多 阿里云智能编码插件产品个性1、晋升编码效率 阿里云智能编码插件所应用的弱小的深度学习模型由海量优质且通过许可的开源代码训练而成，其中蕴含社区积淀多年的最佳实际和编程范式，能够帮你更快更高效地写出更好的代码。 2、沉迷式开发 阿里云智能编码插件能帮忙你在代码编辑器外部搜寻代码示例文档，免于页面切换之苦，沉迷在编码的心流之中。 3、低资源耗费 仅需轻量的系统资源耗费，即可享受弱小的AI引擎带来的智能编码体验。 4、隐衷爱护 用户的隐衷高于一切。代码智能补全所应用的深度学习模型只在你本地的机器上运行，不会分享或向其余设施上传你的代码或个人信息等数据。即便你的设施处于未联网的状态，也不会影响代码智能补全的失常应用。 理解隐衷政策 你兴许会问，“我写个代码罢了，整这么多花里胡哨的干啥？” “代码补全有什么稀奇的，IDE自带的也能补全啊。” nonono，事件并没有这么简略。让我来王婆卖瓜一下子： 首先，Cosy它名字虽短，补进去的代码却很长。 20MB左右的大小能够说是小小的身材大大的能量了www 其次，它可不只有“更懂你的后半句代码”这一个长处。 作为一名一年香且仍然在茁壮成长的新晋小算法，回顾一下这些年的开发过程，总是要免不了接触新的语言新的工具最后那段陌生艰涩的工夫，只能一边开着IDE一边停下开发去找文档读文档找文档读文档找文档读文档…… （小声bb：我这一年从学生时代的Java/Python/C#变成了Golang/Nodejs/Rust，家人们，谁懂_(:_」∠)_而当初你只须要右键选中你不是那么相熟的API，或点击IDE右侧边栏中的【代码示例搜寻】，海量开源代码示例尽收你眼，从此与“在IDE和浏览器之间重复横跳”的日常说拜拜 阿里云智能编码插件Cosy在这条【做你开发过程中的阿拉丁神灯】的幻想长路上也只能算得上是初长成，现诚邀各路Java开发英雄好汉领先来体验，仅需在IntelliJ中装置插件即可～ 点击导航栏IntelliJ IDEA—> Preferences —> Plugins —> Marketplace —> 搜寻Cosy或者Alibaba Cloud AI Coding Assistant均可找到；点击装置后重启IDE即可开始体验～帮忙文档、离线包装置渠道和问题反馈戳这里：https://github.com/alibaba-cloud-toolkit/cosy/wiki/%E5%BF%AB%E9%80%9F%E5%BC%80%E5%A7%8B当然也能够间接回帖或钉钉分割咱们！非Java开发的各位也不必放心，咱们曾经在反对更多语言和IDE的路上全力奔跑了～还请大家只管在回复中留下你对咱们的期待和需要，2、4、8、16、32、64、128、256、512、1024、2048楼（哎呀幻想还是要有的） 阿里云智能编码插件（Alibaba Cloud AI Coding Assistant）是一款AI编程助手，它提供代码智能补全和代码示例搜寻能力，帮忙你更快更高效地写出高质量代码，让你的开发过程既高效又轻松。 点击：装置IntelliJ IDEA插件

2020年如果问什么技术畛域最火？毫无疑问：音视频。2020年近程办公和在线教育的强势倒退，都离不开音视频的身影，视频会议、在线教学、娱乐直播等都是音视频的典型利用场景。 更加丰盛的应用场景更须要咱们思考如何提供更多的可配置能力项，比方分辨率、帧率、码率等，以实现更好的用户体验。本文将次要从“分辨率”开展具体分享。 如何实现自定义编码分辨率咱们先来看看“分辨率”的定义。分辨率：是度量图像内像素数据量多少的一个参数，是掂量一帧图像或视频品质的要害指标。分辨率越高，图像体积（字节数）越大，画质越好。对于一个YUV i420 格局、分辨率 1080p 的视频流来说，一帧图像的体积为 1920x1080x1.5x8/1024/1024≈23.73Mbit，帧率 30，则 1s 的大小是 30x23.73≈711.9Mbit。可见数据量之大，对码率要求之高，所以在理论传输过程中就须要对视频进行压缩编码。因而，视频采集设施采集出的原始数据分辨率咱们称采集分辨率，理论送进编码器的数据分辨率咱们就称之为编码分辨率。 视频画面是否清晰、比例是否适合，这些都会间接影响用户体验。摄像头采集分辨率的抉择是无限的，有时咱们想要的分辨率并不能间接通过摄像头采集到。那么，依据场景配置适合编码分辨率的能力就至关重要了。如何将采集到的视频转换成咱们想要的编码分辨率去发送？这就是咱们明天的次要分享的内容。 WebRTC 是 Google 开源的，功能强大的实时音视频我的项目，市面上大多开发者都是基于 WebRTC 构建实时音视频通信的解决方案。在 WebRTC 中各个模块都有很好的形象解耦解决, 对咱们进行二次开发十分敌对。在咱们构建实时音视频通信解决方案时，须要去理解和学习 WebRTC 的设计思维及代码模块，并具备二次开发和扩大的能力。本文咱们基于 WebRTC Release 72 版本，聊聊如何实现自定义编码分辨率。 首先，咱们思考上面几个问题： 视频数据从采集到编码发送，其 Pipeline 是怎么的？怎么依据设置的编码分辨率抉择适合的采集分辨率？怎么能失去想要的编码分辨率？本文内容也将从以上三点开展具体分享。 视频数据的 Pipeline首先，咱们来理解一下视频数据的 Pipeline。视频数据由 VideoCapturer 产生，VideoCapturer 采集数据后通过 VideoAdapter 解决，而后经由 VideoSource 的 VideoBroadcaster 分发给注册的 VideoSink ，VideoSink 即编码器 Encoder Sink 和本地预览 Preview Sink。 对视频分辨率来说，流程是：将想要的分辨率设置给 VideoCapturer，VideoCapturer 抉择适合的分辨率去采集，原始的采集分辨率数据再通过 VideoAdapter 计算，不合乎预期后再进行缩放裁剪失去编码分辨率的视频数据，将数据再送进编码器编码后发送。 这里就有两个关键性问题： VideoCapturer 如何抉择适合的采集分辨率？VideoAdapter 如何将采集分辨率转换成编码分辨率？如何抉择适合的采集分辨率采集分辨率的抉择WebRTC 中对视频采集形象出一个 Base 类：videocapturer.cc，咱们把形象称为 VideoCapturer，在 VideoCapturer 中设置参数属性，比方视频分辨率、帧率、反对的像素格局等，VideoCapturer 将依据设置的参数，计算出最佳的采集格局，再用这个采集格局去调用各个平台的 VDM（Video Device Module，视频硬件设施模块）。具体的设置如下： ...

在最近的一周,我维护的业务系统出现了很多坏毛病,一周七天crash掉了4次,每次都需要都是因为一点很小的问题,触发了蝴蝶效应,导致整个系统全盘崩溃,于是产生除了叙述本篇的想法,当然这并不是为了掩盖我在Coding上的一些细节处理和职责疏忽，只是为了从根本的细节上去分析这些问题。 (一、)为什么会产生BUG首先我们需要尝试理解一下什么Bug? 关于bug的解释 bug 是指任何计算机程序或硬件系统中的错误，故障或缺陷。错误会产生意外结果或导致系统意外运行简单来说:bug就是程序出了问题,产生了意外的结果,没有按照预期的结果去运行。 产生Bug的原因有很多种: 开发者水平太低不同的编译及运行环境与需求方沟通不到位马虎大意、考虑不周放飞自我,Coding全靠自嗨选择了错误的或者运行不稳定的第三方库以上原因总结,主观和客观因素都会影响到Bug的产生,正如误差不可避免一般,我们应该对自己写出的代码进行测试、分析、"沟通". (二、)如何尽量避免Bug鉴于以上bug产出的原因,我们可以通过这些一些对策来避免Bug的产生,下面是一些常见原因分析和处理对策。 1.开发者水平太低 在进行系统的构建中,部分开发者可能通常因为开发经验过少,或者语言不熟悉,会编写错误的代码,然后未经过代码测试和审计,便进行提交和上线操作,导致了异常的引发 解决方案: 如果是语法错误,可通过一些ide的代码检测器,或者语法检查来检测代码可否正常运行.如果是PHP等弱类型语言,可使用静态代码扫描工具来发现程序中明显的语法错误.编写足够的测试用例,覆盖整个模块的语句请求你的伙伴进行CodeReview(代码审计),来改善代码的质量和发现代码中的缺陷2.不同的编译及运行环境 因为业务的拓展和服务支持,需要部署多个不同的运行环境中,如:转账系统，你在测试环境中转账了1000元给用户小明,小明却在生产环境中收到了这1000元,并成功进行提现,往往因为没有环境判断,导致了失误的操作! 解决方案: 1.在代码中多进行注释说明,标明哪些函数会在其他环境中操作和运行 2.加强环境逻辑判断 以下是我在使用的一些标注和说明,其他开发者或我本人再次阅览该代码时,就会得到一个清晰的运行结果. /** * 执行该函数时,会根据env环境进行处理,详细如下 * prod(生产环境):会启动队列对视频进行转码、截图、写入到生产数据库中操作. * staging(预演环境):不会启动队列,但会写入staging数据库中 * test(测试环境):会启动队列对视频进行转码、截图、写入到测试数据库中操作. */$video = $this->uploadVideo($file);$queue = $this->videoQueue($video);3.与需求方沟通不到位 这是经常程序员与产品对撕的一个很重要原因,TA想要A,而你却做出了B,于是你们产生了很大的争论 解决方案: 多进行沟通,需求进行反复确认,不要上手就进行编码,先进行分析。通过PM系统,留存需求规划与变更记录,以便每一次业务更改,都得能与系统中的问题对上号.4.马虎大意、考虑不周 编码时以为问题很小,修改代码,不走调试与测试流程,直接上线. 解决方案: 不要盲目过于自信,相信自己的主观判断,一定走测试流程,确保改动无误!(这是我之前经常犯的错,然后系统出了问题,我的fix commit从1变成了N....)CodeReview(代码审计),这是一个最好的办法,当然需要耗费不少的人力,但是能最大的去降低缺陷和错误.5.放飞自我,Coding全靠自嗨 解决方案:无 这类朋友不适合做开发者,适合去做创造者!6.选择了错误的或者运行不稳定的第三方库 有时候为了省略接入时间,往往会忽略掉一些大型库,因为业务的支持只用到了一小部分,所以我们有时候会去选择一些mini库,最后由于不稳定或方案不成熟,出现错误的运行结果 解决方案: 如果业务级别比较高的话,不建议采用冷门或者无人问津的mini库使用,因为出现问题的损失会更大.进行反复测试,开发人员对核心代码进行阅览,确保正常无误.自我组织编写或实现,但是学习和开发成本比较高,小型规模不建议采取.(三、)多与代码进行"沟通"“橡皮鸭调试法”是我在阅读《编写可读代码》一书中看到的一个技巧,我在一个人开发的时候会使用这个技巧,我认为是一个不错的选择. (四、)总结我们为什么会编写BUG,如果没有BUG?开发和测试不就失业了吗?当然这只是一句玩笑话。在此引用知乎上一句很有意思的话. 编码也亦如此,因为很多主观和客观的因素,导致程序执行了错误的逻辑,产生了不如预期的结果,作为一个合格的开发人员,我们应该尽力确保程序稳妥运行,减少失误和异常。 正如CZG提到的"你写的每一行代码，都是你的名片",我们每个人都义务去维护好这张名片,让其他人对这张名片充满敬畏之心,而不是"what shit code",诸君共勉！

截止目前，HDR视频生态圈已经产生了巨大的变化。本文将更新旧有的HDR生态圈范围，并更清晰地描述当前HDR视频生态圈。本文译自The HDR video ecosystem tracker，原作者为 Yoeri Geutskens.由于现在的HDR生态圈更为复杂，如果使用一张图表进行描述会显得过于杂乱，如图2，同时也会引起不必要的误解，因此作者将HDR生态圈从8个不同的方面进行整理，并利用8幅 图表展示当前最新的HDR视频生态圈。 图1：《HDR支持状态》 日本通讯技术标准（CES）2017年发 图2：HDR生态圈追踪-2018年9月 这8个方面分别为： 电视品牌与制造商（TV brands and manufacturers）周边设备（Peripherals）流媒体服务（Streaming services）广播与运营商（Broadcasters / operators）电影制造商（Movie studios）电影制作商：家庭娱乐影院（Movie studios’ Home Entertainment divisions）芯片制造商（Chipset makers）编码供应商（Encoding vendors）本文只关注HDR视频，因为HDR这个概念在静态摄影领域表示的是另外一类技术。静态摄影领域的HDR技术生成的仍旧是在SDR显示设备上显示的SDR图像。这些技术通常基于多曝光度合成，然后利用一些专利技术进行图像增强，典型的代表有Apple Smart HDR以及Google HDR+。注意这里的“HDR+”，其他一些公司也使用“HDR+”这个名称，但表达的却是非常不同的含义。真正意义上的图像HDR技术是Dolby‘s JEPG-HDR以及technology Netflix提出的应用于屏幕选项的HDR图像技术。静态HDR的内容到此为止，接下来将是关于HDR视频的内容。 HDR格式简介后面的大多数图表都基于五种不同的HDR格式： 四种基于Dolby的PQ[1]（Perceptual Quantizer）曲线• HDR10[2]• Dolby Vision[3]• Philips/Technicolor HDR[4]• HDR10plus[5]• HLG[6]此外还有第六种这里没有提到的标准，PQ10。这里没有提到的原因是在HDR视频生态圈中，大多数公司并不会考虑PQ10。据作者所知，目前并没有一家电视品牌宣布设备支持PQ10标准。那么，什么是PQ10标准呢？PQ10就是没有元数据的HDR10。PQ10可以正常工作吗？当然。并且PQ10是一种非常实用的标准，特别是在广播领域。HDR10存在的问题是它定义了静态元数据的形式与标准，但是却没有定义如何去操作静态元数据。因此一些电视可能完全忽略HDR10的静态元数据。更多关于这方面的内容请见[7]。在前述的8项指标中，仅有一种指标中单独列出了PQ10，即第8项编码供应商，这也是那幅图表中有6个圈的原因。 图3：HDR格式标准 更多关于HDR标准的介绍请见[8]。同时作者强调，在他看来，HDR视频领域目前并没有标准战争。一个广播台需要选择支持一种标准，但是在整个内容供给链的其他群体中，支持多种HDR格式标准是可行的。消费者并不需要决定支持哪一种标准，因为消费者一侧取决于电视支持哪一种标准，而电视制造厂商应当支持尽可能多的标准-最好是全部支持。电视品牌由于两个原因，生态圈的这一部分需要更多解释。最主要的地方是要解释清楚电视品牌和电视制造商之间的区别。这个图表在一定程度上混合了两者。许多品牌的电视设备不再是由这个品牌的公司制造的。电视制造业的竞争十分残酷，利润微薄，因此很多传统的消费电子公司都将其外包。这种情况下，他们完全退出电视制造业，仅通过品牌许可协议收取版税。使这一情况更加混乱的是，来自不同地区的同一品牌的电视机可能由完全不同的公司制造。 美国的飞利浦电视由P＆F USA（Philips & Funai）制造。除了印度由Videocon制造和投影仪由Sagemcom制造之外，欧洲和世界上其余大部分国家的飞利浦电视由TP Vision制造。因此就有了下面这张表： 图4：各大品牌不同地区电视制造商 这里避免使用“OEM”（原始设备制造商）一词，因为它会引起混淆，它可能表示品牌许可人，也可能表示被许可人。品牌的所有权和许可在不断改变。收购日本公司夏普的富士康正在起诉海信，因为在被富士康收购之前，夏普曾向其出售其美国子公司和品牌权。这张图表提到了Vestel，它代表了欧洲的Vestel品牌和东芝品牌。这张图中的“东芝”意味着日本的母公司东芝。您不会在此图表中找到飞利浦，只有P＆F USA和TP Vision。夏普在这张图表中的情况给出了他们在美国的现状，在美国，夏普的部分设备支持HDR10和Dolby Vision，电视的制造商是海信，但海信本身也以海信品牌发布产品。在欧洲，夏普在电视市场很少出现。欧洲的Sharps设备（实际上主要在英国）似乎只支持HDR10。在日本，他们的产品支持HDR10和HLG。对于仅在一个地区使用的所有品牌，下面图里使用的是品牌而不是制造商的徽标，例如： Grundig，RCA，Westinghouse，宝丽来，柯达。未来更新的一个更优雅的解决方案是为每个关键市场提供单独版本的电视品牌图表。此图中首次新增的包括Insignia（百思买品牌），Westinghouse，RCA（美国），JVC电视（前身为HDR10和HLG反射投影仪，此处不再包括），夏普，日立，船井（日本），Electriq（英国），康佳（中国），宝丽来，柯达（印度）。注意，例如，当某个电视品牌同时出现在HDR10和Dolby Vision范围内时，并不意味着他们所有的电视机都必须支持这些功能。 图5：世界主要HDR电视制造商与品牌生态图 显然，HDR10是最广泛支持的格式，杜比视界也很受欢迎。相对较少的品牌（声称）支持HLG，更少的品牌支持HDR10plus或Technicolor 'Advanced HDR'。三星从未正式声明支持HLG，但有用户处有足够的证据表明他们确实支持HLG。HDR10plus的椭圆特意被放在HDR10内部，以确定每台支持HDR10plus的电视都必须支持HDR10。此图表还表明支持Dolby Vision的每款产品都支持HDR10。实际上，现在就是这种情况，但早期的Vizio电视机和Vudu流媒体服务仅在Dolby Vision中使用。这里同样值得关注的是，目前还没有支持所有五种格式的电视品牌（飞利浦可能会如此，如果我们将TP Vision和P＆F USA结合的话）。LG支持最多的HDR格式，但有人想知道他们是否会支持主要竞争对手三星的HDR10plus。虽然普遍的HDR支持将是一个强大的卖点，但尚未有这样的电视产品公布。也许CES 2019会给我们带来这样的消息。正如后面将会提到的，支持所有格式的芯片组已经存在。据芯片组制造商称，阻碍电视机普及HDR的原因在于等待HDMI 2.1的发布。现在每个电视品牌都出售HDR电视吗？几乎看起来，但仍有些廉价品牌没有，例如Sceptre。 电视周边电视周边设备是指源设备，特别是流媒体播放器，游戏机和超高清蓝光播放器（Oppo，Pioneer，LG，松下）。这里可能还会添加除了Arris之外机顶盒。机顶盒制造商例如Technicolor，Amino和Kaon支持的HDR的格式（HDR10，HLG和Dolby Vision）目前还有待理清。这里一些需要注意的事情有：Roku的平台可以处理Dolby Vision，但由于某种原因，他们没有在任何独立产品（电视盒子和电视流媒体棒）中实现这一点，他们只有基于Roku的TCL，海信，夏普和飞利浦等品牌的电视机，，您可以在电视品牌图表中找到它们。并非所有基于Roku的电视都具有Dolby Vision功能。例如RCA，日立和Insignia仅支持于HDR10。 Insignia的最新电视基于亚马逊的Fire TV平台。根据固件信息的泄漏，Apple TV 4K将兼容HLG，但在Apple公布之前这里并不会讨论具体细节。注意Panasonic在这里的特殊位置：与他们的电视机不同，他们的顶级UHD BD播放器确实支持Dolby Vision。很显然，他们认识到，如果没有DV，你就无法销售可信的高端光盘微调器。虽然Ultra HD蓝光光盘格式没有将HLG作为其支持的格式之一（仅支持HDR10，Dolby Vision，HDR10plus和Philips HDR），但Oppo和Panasonic的设备对来自例如USB传输设备的流媒体信息支持HLG格式。Xbox One X最近添加了Dolby Vision，但在超高清蓝光播放上会有多深入尚不清楚。与HDR不兼容的产品在这里没有包含，也许应该在圈子之外标注。 例如：Nintendo Switch。 ...

语音聊天室孵化一起KTV、众人大合唱、语音开黑、狼人杀、剧本杀、多人配音、观影、语音电台、相亲联谊社交等，一般都是在语音聊天室中进行，那么语音聊天室产品如此火热的原因有哪些呢？ 一对一社交适用于朋友、家人之间，而更多的社交场景需要多人参与，聊天室的多人属性，正好满足此需求，用户按照自己的兴趣去交友聊天，也让社交更加多样化、娱乐化。对于有视频社交压力的用户来讲，实时展示自己的画面会是一个高压场景，压力也会明显大于文字、图片、语音等。另外，文字、图片社交不能携带太多用户的情绪和态度。语音社交不仅可以解决视频社交压力用户的痛点，也可以通过感知对方音量、音色等，感受到一个“真实”的对话者，让用户在轻松氛围中交友聊天。语音聊天室原型越来越多的产品提供语音聊天室，在语音聊天室的基础上创建多种玩法，那么一个标准的语音聊天室原型是怎样的呢？ 语音聊天室应该有如下角色：创建者、管理员、普通成员。房间创建者拥有聊天室所有权限；管理员应该具有拉黑、禁言、踢人、设置普通成员权限、设置房间属性：如设置背景音乐、背景图、房间密码等；普通成员可以加入房间，申请连麦，参与语音聊天互动等。语音聊天室的技术关键点语音聊天室需要为用户提供长时间、高频次语音连麦互动功能，在网络抖动时保证语音通话流畅、延迟小、卡顿低、音质好。因此开发语音聊天室，一些技术关键点需要关注，如： 频繁麦位切换：抢麦、跳麦、麦位排序、抱麦、上麦、下麦等是典型场景，复杂的麦位逻辑需要详细设计，否则影响会产品体验；高并发：应用高峰一般会出现在午休时刻、晚上或者周末，音视频通话发起、接听数会瞬间爆发增长，如果音视频架构不能支持海量并发，那么通话发起或者接听不成功、丢包、卡顿、延时等现象出现几率极高；卡顿：通常是由丢包引起，涉及到音视频编解码性能质量，以及端到端的传输链路设计都会对卡顿造成影响；时延：通话延时大于150ms时，就会影响通话质量通话连续性影响，当最大时延大于400ms，基本听不到对方讲话；音质：噪声、回声、听不清、无声等音质问题，特别影响用户体验，提高音质，适配机型、适配音频编解码、调优性能等工作需要重视。网易云信语音聊天室方案根据语音聊天室用户的需求，以及需要考虑的核心要点，网易云信提出两种语音聊天室方案，让客户迅速搭建语音聊天室。在介绍方案之前先介绍几个概念：房间：用户进行多人实时音视频通话的地方房主：音视频房间的创建者或者管理员连麦者：在多人通话时参与语音互动，发言的人，可以发送语音，接收其他连麦者、房主语音观众：只可以收听的人，没有发言的权限，其中连麦者和观众身份可以随时切换。 方案A，实时音视频方案方案A的连麦互动基于多人实时音视频通话架构实现，选择纯音频模式，多人连麦进行实时音频通话，观众只可以听连麦者、房主的声音，不可以发言。要强调的是方案A的优点是观众听到声音延时小，但是支持观众人数有上限。 方案B，互动直播方案方案B是基于音视频直播与实时互动开发架构实现，互动直播由连麦互动和直播两部分组成，其中连麦互动基于音频通话实现，房主、连麦者互动合并直播，普通观众拉流观看语音聊天室的直播。要强调的是方案B支持观众人数无上限，但是拉流延时相对方案A有点大。介绍完语音聊天室的架构之后，接下来重点介绍一下核心模块实现，如多人语音互动、麦位管理以及成员权限管理等。• 语音互动语言聊天室多人语音互动是基于自研的音视频通话开发框架实现，流程如图所示 多人语音互动流程• 麦位管理麦位管理是聊天室常用功能之一，麦位管理分类主要有：上麦 、下麦、跳麦、抱麦、抢麦、禁麦、解禁等，网易云信麦位管理方案基于自研的聊天室队列实现。 • 权限管理语音聊天室不同成员具有不同权限，按照不同角色进行分类： 语音聊天室权限网易云信的语音聊天室权限管理方案基于自研的IM以及聊天室自定义消息、系统消息实现。 网易语音聊天室方案特点丰富灵活的API：实现场景自由切换与角色灵活设置，连麦者、观众观战轻松掌控、群聊/私聊切换；音质清晰：音频独家48kHz超宽屏音质，支持全频带编解码，PLC丢包补偿算法，自适应音频模式提供复杂音频环境解决方案，满足音质要求的痛点；抗抖动、丢包：智能网络探测，智能Qos保障，音视频码率自适应，多种核心算法保障弱网环境音频体验，可抗800ms网络抖动，30%丢包；低延时：端到端平均延时低于200ms，实时连麦互动无压力；易集成、扩展：集成稳定IM、音视频服务，满足即时通信聊天场景，高度灵活可扩展，不仅支持多人语音连麦，还支持多人视频连麦；麦位管理方便：IM、聊天室自定义消息、聊天室队列接口，便捷实现频繁麦位管理需求，优化麦位管理逻辑；高可用：服务器使用高可用的架构部署，对于服务器宕机、网络切断，使用了相应的恢复和切换策略。 网易云信已经为诸多专注语音社交的客户提供优质音视频服务，语音聊天室方案的功能与服务也会越来越全面，满足更广泛场景需求，让用户快速搭建，抓住语音社交的风口。 想要阅读更多行业洞察和技术干货，请关注网易云信博客。

只要涉及编程工作，编码是永远绕不开的问题。只有彻底理解编码，遇到编码问题才知道问题的根源在哪里，并找到对应的解决办法。花一点时间去彻底消化并理解他，长远来看，对以后工作效率的提升是非常值得的。下面是我对编码的一些总结和理解，有不对之处还望指正。 1. 什么是编码？为什么会有编码（可参考这里）？从根本上来说，计算机只能处理0和1，也就是说只能处理由0和1组成的一串串数字。让人直接用01数字给计算机下达指令或传输字符显然是很困难的；但其实，早期计算机刚兴起时，那时的程序员就是写好01代码传给机器执行的。 人用自然语言沟通，而计算机只处理01代码。为了人与计算机更友好的交互，有人想了办法，将自然语言的每个字符都用一串01数字串来表示，也就是对每个字符用01串来编码，比如A用0100 0001来表示，这样就可以制定一个字符与01数字串的对应表，也即编码表，人只需要输入自然语言（如：Hello），计算机通过查编码表就可以转换为01串，这样机器就可以理解并处理了。 2. 为什么会有多种编码？众所周知，世界上第一台计算机是在美国诞生的，因此，第一种编码自然是解决英文和01串的对应关系，这就促生了ASCII编码的出台，ASCII编码表用一个字节（8位）包含大小字母、数字、标点符号以及控制字符。 随着计算机的普及，世界上开始有越来越多的国家使用计算机，然而，每个国家都有自己的一套语言，加起来的字符成千上万。而ASCII最多只能编码256个字符，已经不能满足这么多的需求。于是，各国就制定了自己国家的编码表。比如中国就制定了GB2312、GBK、GB18030等编码规范。每个国家都有自己的一套编码，这就导致同一串01数字可能代表两个国家不同的字符，或者同一个字符A，在两个国家分别用不同的01数字串表示。这就导致不同编码的系统互相传输信息时无法正确识别，比如中国用GBK编码的字符传输给美国的服务器，而美国服务器只有ASCII编码表，这就很糟糕。 于是，Unicode编码出现了。Unicode编码将世界上各个国家所有的字符全部收录进去，每个字符都用唯一的01字符串表示，这样的话就做到了全世界所有字符的统一编码，各个国家传输信息都用Unicode编码，根据Unicode编码表就可以识别了。 常用的编码ASCII：1个字节，实际使用7位，第8位保留，表示英文字符ISO-8859-1：1个字节，ASCII的升级版，在ASCII的基础上添加了欧洲国家的字符，不能表示中文,常用于Java服务的网络传输GB2312：2个字节，收录6763个汉字，只能表示简体字GBK：GB2312的升级版，1个或2个字节，收录21003个汉字，可以表示简体字和繁体字Unicode（即UCS）：原始的Unicode是定长的4个字节，比如字母A，用Unicode表示需要4个字节，比ASCII多了3个字节，由于这样做太浪费空间，因此经过优化制定了变长表示字符的UTF编码。 UTF-8：用1-6个字节表示所有字符，此处使用变长字节表示，优先使用短字节。UTF-16：用2、4个字节表示所有字符，此处使用变长字节表示，优先使用短字节。UTF-32：用4个字节表示。编码和解码编码：将字符转为二进制（或unicode）。解码：将二进制（或unicode）转为字符。不同编码转换首先应该知道，内存统一用Unicode编码，编码转换都统一转到Unicode，再从Unicode转为其他编码。比如ISO-8859-1和UTF-8之间转换，流程如下： 先知道字符"u"是用ISO-8859-1编码获取字符"u"的二进制，java可通过getByte("ISO-8859-1")正确解析出该字符的二进制，也可以用十六进制表示，比如AF8U根据某种规则，将ISO-8859-1的AF8U转化Unicode,再转化为UTF-8的4E2Djava编译的编码问题（可参考这里）：JDK先检查源文件的编码类型，如果没有指定编码类型则用系统的编码读取源文件，如果指定了编码类型则用指定的编码类型打开源文件。打开源文件后，在内存中编译为.class文件，此时，.class文件是Unicode编码将内存中的.class文件存入硬盘，此时，.class文件仍然是Unicode编码浏览器编码问题看浏览器使用的是什么编码，则显示的页面就是使用什么编码。发送post请求时，看浏览器用的什么编码，则发送过去的数据就是用什么编码一般可以查看headers里ContentType，charset是什么编码服务器编码问题（可参考这里）服务器收到请求后，经过正确的编码规则解析，服务器才可以正常识别服务器发送请求时，经过正确的编码规则编码，浏览器才可以正常显示。浏览器也可以自定义编码去解析记住： 不管是爬虫获取的，浏览器收到的还是从本地硬盘读取的，都是二进制，选择正确的编码类型，才能把二进制或者说01序列解析为正确的字符。也就是用何种方式解析01数字。

Base64 是基于 64 个可打印字符 A-Z、a-z、0-9、+、/ 来表示二进制数据的表示方法，常用于数据在网络中的传输。本篇将分别介绍其编码、解码以及实际运用。 Base64 编码Base64 本质是一种将二进制转为文本的方案。基本规则如下： 编码时候选用 64 (大小写英文字母，数字，+ /)个字符以及用作补位的=来表示在编码的时候，将3个字节变为4个字节，4个字节的高两位都用 00 来填充，后 6 位来表示 64 个字符。以一个实际的例子 "YOU" 为例，其编码过程如下： 由上表格可知 "YOU"对应的 Base64 编码为："WU9V"。 对于要待编码的字符数如果不是 3 的倍数时候，会用 0 去填充，编码出来后用 = 号表示，如： "ME" 其编码如下： Base64 解码将 4 个字节变为 3 个字节； 将 24 bit 左移 16 位，与 255 进行与操作，获得第一个字符，将 24 bit 左移 8 位，与 255 进行与操作，获得第二个字符，将 24 bit 与 255 进行与操作，获取第三个字符Base64 实现与运用场景在 Node 中提供 Buffer 模块，可以进行二进制或者字符与 Base64 的想换转换，其代码如下： ...

一份Java开发者的技术图谱　, 近期主要侧重点在 Java | Docker | 并发与分布式.

1.字符串字符串在Go语言中以原生数据类型出现,使用字符串就像使用其他原生数据类型(int、bool、 float32、foat64等)一样。 字符串的值为双引号中的内容,可以在Go语言的源码中直接添加非ASCⅡ码字符 Go语言的字符串常见转义符包含回车、换行、单双引号、制表符等,如下所示 转移符 含义 \r 回车符(返回行首)\n 换行符(直接跳到下一行的同列位置)\t 制表符\' 单引号\" 双引号\\ 反斜杠2.字符串实现基于UTF-8编码 go 语言里的字符串的内部实现使用UTF8编码. 通过rune类型,可以方便地对每个UTF-8字符进行访问。 当然,Go语言也支持按传统的ASCII码方式进行逐字符访问。 3.字符 字符串中的每一个元素叫做“字符”,在遍历或者单个获取字符非元素时可以获得字符。 Go语言的字符有以下两种： 一种是uint8类型,或者叫byte型,代表了ASCII码的一个字符。另一种是rune类型,代表一个UTF-8字符。当需要处理中文、日文或者其他复合字符时,则需要用到rune类型。rune类型实际是一个int32。使用 fmt.Printf中的“%T”动词可以输出变量的实际类型,使用这个方法可以查看byte和rune的本来类型,代码如下: var a byte = 'a'fmt.Printf("%d %T\n", a, a)var b rune='你'fmt.Printf("%d %T\n", b, b)输出如下97 uint820320 int324.UTF-8和 Unicode有何区别? Unicode是字符集。ASCⅡ也是一种字符集。 字符集为每个字符分配一个唯一的ID,我们使用到的所有字符在 Unicode字符集中都有唯一的一个ID对应,例如上面例子中的a在 Unicode与ASCII中的编码都是97。 “你“在 Unicode中的编码为20320,但是在不同国家的字符集中,“你”的ID会不同。而无论任何情况下, Unicode中的字符的ID都是不会变化的。 UTF-8是编码规则,将 Unicode中字符的ID以某种方式进行编码。UTF-8的是一种变长编码规则,从1到4个字节不等。 5.计算字符串长度 tip := "genji is a ninja"fmt.Println(len(tip))tip2 := "认真"fmt.Println(len(tip2))结果：166len 表示字符串的ASCII 字符个数或字节长度 所以:ASCII 字符串长度使用len() 长度Unicode 字符串长度使用utf8.RuneCountInString() 5.字符串遍历1.遍历每一个 ASCII 字符直接使用for 2.按Unicode 字符遍历字符串使用 range ...

什么是链表？链表是一种数据结构，由许多称为“节点”的迷你数据结构组成。节点链接在一起形成一个列表。 整个链表，由3个节点链接在一起组成。 每个节点包含2个属性它的价值。这可以是任何东西：整数，字符，字符串，对象等。指向序列中下一个节点的指针。一些定义头节点：头节点只是链表中的第一个节点。从上面的例子可以看出，包含'5'的节点是第一个节点，因此是头部。 '尾节点：尾节点是序列中的最后一个节点。由于它是最后一个节点，因此它指向null，因为序列中没有下一个节点。在上面的示例中，包含“3”的节点将是尾节点。 单身联系与双重联系在链接列表方面，有两种主要类型。 那些“单独”联系的，以及那些“双重”联系的。 单独链接意味着每个节点仅指向最多1个其他节点，即其前面的节点。这在上面的例子中展示。 双重链接意味着每个节点可以指向其他2个节点，前面的节点和它后面的节点。正如我们从下面的例子中可以看到的那样，由于头节点之前没有节点（即5），因此其中一个指针指向null。 代码是如何工作的呢？编码链接列表可能是4行问题或400行问题。这取决于你想要如何接近它。 在最简单的层面上，就像我们讨论的那样，链表只是一堆连接的节点。 因此，我们真正需要创建此结构的只是一个节点对象。 class linkedListNode: def __init__(self, value, nextNode=None): self.value = value self.nextNode = nextNode在这里我们可以看到我们只是创建了一个具有value和nextNode属性的类。 要创建节点，我们只需传入一个值。 node1 = linkedListNode("3") # "3"node2 = linkedListNode("7") # "7"node3 = linkedListNode("10") # "10"在这里，我们创建了3个单独的节点。 下一步就是将它们连接在一起。 node1.nextNode = node2 node2.nextNode = node3 上面的第一行使node1指向node2： “3”→“7” 上面的第二行使node2指向node3： “7”→” 10" 总之，我们留下了一个链接列表，如下所示： “3”→” 7" →” 10" →null 注意：“10”指向null，因为没有为node3分配nextNode，并且默认的nextNode为Null。 就像我之前提到的，有很多不同的方法可以做到这一点。这只是最简单的。 遍历链接列表如果您正在进行编程访谈，并且您会收到链接列表问题，那么您将无法获得所有节点。 所有你得到的是头节点。 从该头节点，您必须获得列表的其余部分。 首先让我们了解如何从Python中的节点获取值和nextNode。 假设我们有一个名为'node'的节点。 ...

内存数据结构这个就太多了。。略 IO:json/xml(无类型，unicode支持不好等),二进制编码JSON演化mmessagePack不流行，因为需要在编码数据中包含对象名称.只是删除空白和标点的感觉thrift BinaryProtocal 字段名替换为序号 { "userName": "Martin", "favoriteNumber": 1337, "interests": ["daydreaming", "hacking"]} pb(thrift的compactProtocal和这个一样) field和type在单个字节。数据的优化数据最高位标识是否还有后续，这个1337有错误，是下面的 Avro 数据变更兼容：thrift和protocal可以换换名字。但是不能换编号，可以增加编号，旧的编号删了也不能再用，后加的向前兼容不能设为必选。模式和数据编码分别传送，一个传一个模式，大批数据，无编号，读者模式与作者模式匹配，读者解析作者模式 只能添加或删除有默认值的字段以上数字的转变全是基于VLQ可变长二进制数字编码的变体。最低位加0表示整数，1表示负数，然后7位一个分割。从最后开始，每个后面有第一位是1，否则是0. 压缩压缩算法对比 https://catchchallenger.first-world.info/wiki/Quick_Benchmark:_Gzip_vs_Bzip2_vs_LZMA_vs_XZ_vs_LZ4_vs_LZOhttps://www.percona.com/blog/2016/04/13/evaluating-database-compression-methods-update/snappy/LZ77/LZSSDC动态词典编码：用它在词典中的位置号码代替。静态需要实现知道词典，讲下动态的前向缓冲区（数据流将要处理的所有字符）的开始字符串与滑动窗口中的字符串进行最长匹配，无移动窗口，若找到<匹配字符串在滑动窗口的位置，长度，移除前置缓冲区中匹配部分移除后续第一个字符>,LZSS增加匹配长读限制如何快速最长匹配字符串：简单的将窗口中所有字符顺序组合存入hash，也可以存固定长度，比如2，匹配多个后再继续向后比较这多个。snappy 将整个数据切割为32k一个大小的块，块只见那无关联，2个字节就可表示匹配字符串的相对位置，匹配长度至少为4，hash字符串长度也固定为4.输出字符串的压缩形式为 编码方案，匹配字符串起始位置差值，匹配字符串长度 EC编码：N个数据块和校验，可以任意丢k个相互恢复因为我们都是多副本，N个Data块，生成K个Parity块，N+K中可任意丢K个可靠性相同时比多副本冗余度低只有一份数据可读，修复较复杂提高可靠性：增加K，增加N和K，提高修复速度https://blog.csdn.net/shelldo...

使用自动编码器检测信用卡欺诈来源 | 愿码(ChainDesk.CN)内容编辑愿码Slogan | 连接每个程序员的故事网站 | http://chaindesk.cn愿码愿景 | 打造全学科IT系统免费课程，助力小白用户、初级工程师0成本免费系统学习、低成本进阶，帮助BAT一线资深工程师成长并利用自身优势创造睡后收入。官方公众号 | 愿码 | 愿码服务号 | 区块链部落免费加入愿码全思维工程师社群 | 任一公众号回复“愿码”两个字获取入群二维码本文阅读时间：11min自动编码器是重要的生成模型类型之一，具有一些有趣的特性，可以用于检测信用卡欺诈等应用。在本文中，我们将使用Autoencoders来检测信用卡欺诈。我们将使用一个新的数据集，其中包含具有匿名功能的实际信用卡交易记录。数据集不适用于很多特征工程。我们将不得不依靠端到端的学习方法来构建一个好的欺诈检测器。从数据集加载数据像往常一样，我们首先加载数据。时间特征显示了交易的绝对时间，这使得在这里处理起来有点困难。所以我们将放弃它。df = pd.read_csv(’../input/creditcard.csv’)df = df.drop(‘Time’,axis=1)我们将事务的X数据与事务的分类分开，并提取作为pandas数据帧基础的numpy数组。X = df.drop(‘Class’,axis=1).valuesy = df[‘Class’].values功能缩放现在我们需要扩展功能。特征缩放使我们的模型更容易学习数据的良好表示。对于特征缩放，我们将所有特征缩放为介于0和1之间。这可确保数据集中没有非常高或非常低的值。但要注意，这种方法容易受到影响结果的异常值的影响。对于每列，我们首先减去最小值，以使新的最小值变为零。然后我们除以最大值，使新的最大值变为1。通过指定axis = 0，我们执行缩放列。X -= X.min(axis=0)X /= X.max(axis=0)最后，我们分割了我们的数据：from sklearn.model_selection import train_test_splitX_train, X_test, y_train,y_test = train_test_split(X,y,test_size=0.1)我们的编码器输入现在有29个尺寸，我们压缩到12个尺寸，然后再恢复原始的29维输出。from keras.models import Modelfrom keras.layers import Input, Dense您会注意到我们最终使用的是sigmoid激活函数。这是唯一可能的，因为我们将数据缩放为0到1之间的值。我们还使用编码层的tanh激活。这只是一种在实验中运行良好的样式选择，并确保编码值在-1和1之间。您可以根据需要使用不同的激活功能。如果您正在处理图像或更深层次的网络，则重新激活通常是一个不错的选择。如果您正在使用比我们在这里更浅的网络，那么tanh激活通常很有效。data_in = Input(shape=(29,))encoded = Dense(12,activation=‘tanh’)(data_in)decoded = Dense(29,activation=‘sigmoid’)(encoded)autoencoder = Model(data_in,decoded)我们使用均方误差损失。这首先是一个不寻常的选择，使用sigmoid激活和均方误差丢失，但它是有道理的。大多数人认为乙状结肠激活必须与交叉熵损失一起使用。但是交叉熵损失会使值为零或一，并且在这种情况下适用于分类任务。但在我们的信用卡示例中，大多数值约为0.5。均值误差在处理目标不是二进制的值时更好，但在频谱上更好。autoencoder.compile(optimizer=‘adam’,loss=‘mean_squared_error’)训练后，自动编码器收敛到低损耗。autoencoder.fit(X_train, X_train, epochs = 20, batch_size=128,validation_data=(X_test,X_test))重建损失很低，但我们怎么知道我们的自动编码器是否运行良好？再次，检查。人类非常善于视觉判断事物，但不善于判断抽象数字。我们将首先进行一些预测，其中我们通过自动编码器运行测试集的子集。pred = autoencoder.predict(X_test[0:10])然后我们可以绘制单个样本。下面的代码生成一个重叠的条形图，将原始交易数据与重建的交易数据进行比较。import matplotlib.pyplot as pltimport numpy as npwidth = 0.8prediction = pred[9]true_value = X_test[9]indices = np.arange(len(prediction))fig = plt.figure(figsize=(10,7))plt.bar(indices, prediction, width=width, color=‘b’, label=‘Predicted Value’)plt.bar([i+0.25width for i in indices], true_value, width=0.5width, color=‘r’, alpha=0.5, label=‘True Value’)plt.xticks(indices+width/2., [‘V{}’.format(i) for i in range(len(prediction))] )plt.legend()plt.show()用t-SNE可视化潜在空间我们现在有一个神经网络，它接受信用卡交易并输出看起来或多或少相同的信用卡交易。但这当然不是我们构建自动编码器的原因。自动编码器的主要优点是我们现在可以将事务编码为较低维度的表示，该表示捕获事务的主要元素。要创建编码器模型，我们所要做的就是定义一个新的Keras模型，它从输入映射到编码状态：encoder = Model(data_in,encoded)请注意，您无需再次训练此模型。这些层保留了我们之前训练过的自动编码器的权重。为了编码我们的数据，我们现在使用编码器模型：enc = encoder.predict(X_test)但是，我们如何知道这些编码是否包含有关欺诈的任何有意义的信息？再一次，视觉表现是关键。虽然我们的编码尺寸低于输入数据，但它们仍然具有十二个维度。人类不可能考虑12维空间，因此我们需要在较低维度的空间中绘制我们的编码，同时仍然保留我们关心的特征。在我们的例子中，我们关心的特征是接近度。我们希望在二维图中，在12维空间中彼此接近的点彼此接近。更确切地说，我们关心邻域，我们希望在高维空间中彼此最接近的点在低维空间中也彼此最接近。保留邻居是相关的，因为我们想要找到欺诈集群。如果我们发现欺诈性交易在我们的高维编码中形成一个集群，我们可以使用一个简单的检查来判断一个新的交易是否属于欺诈集群，以便将交易标记为欺诈。将高维数据投影到低维图中同时保留邻域的流行方法称为t分布随机邻域嵌入或t-SNE。简而言之，t-SNE旨在忠实地表示在所有点的随机样本中两个点是邻居的概率。也就是说，它试图找到数据的低维表示，其中随机样本中的点具有与高维数据中相同的最接近邻居的概率。t-SNE算法遵循以下步骤：计算所有点之间的高斯相似度。这是通过计算点之间的欧几里德（空间）距离然后计算该距离处的高斯曲线的值来完成的，参见图形。来自该点的所有点的高斯相似度可以计算为：’ sigma ‘是高斯分布的方差？我们将在稍后讨论如何确定这种差异。注意，由于点i和j之间的相似性通过所有其他点之间的距离之和（表示为k）来缩放，因此i，j，pi|j之间的相似性可以与j和i之间的相似性不同，pj|i 。因此，我们平均两个相似点以获得我们继续工作的最终相似性，其中n是数据点的数量。随机地将数据点定位在较低维空间中。计算较低维空间中所有点之间的t-相似度。就像训练神经网络一样，我们将通过遵循损失函数的梯度来优化较低维空间中的数据点的位置。在这种情况下，损失函数是较高和较低维空间中相似性之间的Kullback-Leibler（KL）差异。我们将在变分自动编码器部分详细介绍KL分歧。现在，只需将其视为衡量两种分布之间差异的方法。损失函数相对于 较低维空间中的数据点i的位置yi的导数是：使用梯度下降调整较低维空间中的数据点。高维数据中靠近的移动点靠近在一起，并且移动点彼此远离更远。您会将此识别为具有动量的梯度下降形式，因为先前的渐变已合并到位置更新中。使用的t分布总是具有一个自由度。一个自由度的选择导致更简单的公式以及一些不错的数值属性，从而导致更快的计算和更有用的图表。具有困惑超参数的用户可以影响高斯分布的标准偏差。困惑可以解释为我们期望得到的邻居的数量。低茫然值强调局部邻近，而大茫然值强调全局茫然值。在数学上，困惑可以计算为：其中Pi是数据集中所有数据点位置的概率分布，H（Pi）是此分布的Shannon熵，计算公式如下：虽然该公式的细节与使用t-SNE不是非常相关，但重要的是要知道t-SNE执行对标准偏差’ sigma ‘的值的搜索，以便它找到其上的熵的全局分布Pi。我们的数据是我们所希望的困惑。换句话说，您需要手动指定困惑，但这种困惑对数据集的意义也取决于数据集。t-SNE的发明者Van Maarten和Hinton报告说，该算法对于5到50之间的困惑选择相对稳健。大多数库中的默认值是30，这对于大多数数据集来说是一个很好的值。如果你发现你的可视化效果不理想，那么调整困惑度值可能是你想要做的第一件事。对于所涉及的所有数学，使用t-SNE非常简单。scikit-learn有一个方便的t-SNE 实现，我们可以像scikit中的任何算法一样使用它。我们首先导入TSNE类。然后我们创建一个新的TSNE实例。我们定义我们想要训练5000个时期，使用30的默认困惑和200的默认学习率。我们还指定我们希望在训练过程中输出。然后我们只需调用fit_transform，它将我们的12维编码转换为二维投影。from sklearn.manifold import TSNEtsne = TSNE(verbose=1,n_iter=5000)res = tsne.fit_transform(enc)作为警告，t-SNE非常慢，因为它需要计算所有点之间的距离。默认情况下，sklearn使用称为Barnes Hut近似的更快版本的t-SNE，它不是那么精确但已经快得多。有一个更快的python实现t-SNE，可以用来代替sklearn的实现。然而，它没有得到很好的记录，并且具有较少的功能。我们可以将t-SNE结果绘制为散点图。例如，我们将通过颜色区分欺诈与非欺诈，欺诈以红色绘制，非欺诈以蓝色绘制。由于t-SNE的实际值无关紧要，我们将隐藏轴。fig = plt.figure(figsize=(10,7))scatter =plt.scatter(res[:,0],res[:,1],c=y_test, cmap=‘coolwarm’, s=0.6)scatter.axes.get_xaxis().set_visible(False)scatter.axes.get_yaxis().set_visible(False)为了便于定位，包含大多数欺诈的群集标有圆圈。您可以看到欺诈与其他交易完全分开。显然，我们的自动编码器已经找到了一种方法，可以在不给出标签的情况下将欺诈与真实交易区分开来。这是一种无监督学习的形式。事实上，普通自动编码器执行PCA的近似，这对于无监督学习很有用。在图表中，您可以看到一些明显与其他交易分开但不是欺诈的集群。使用自动编码器和无监督学习，可以以我们之前没有考虑过的方式分离和分组我们的数据。 ...

字符集是什么字符集 Charset ：是一个系统支持的所有字符的集合，包括各国家文字、标点符号、图形符号、数字等。——看的是不是想打人（举个栗子，现在这张表你把红色的盖住，只看蓝色的，他就是个ASCII字符集。不过现在是10进制的，真正的存储到电脑中是要转成二进制的。有的同学可能要问了，我只看蓝色的，全都是数字，我怎么知道你那个数字要表达的是什么意思。现在你在把盖住的红色的内容打开，他就变成了ascii码对照表。它就表示了ascii字符集与计算机二进制之间的对应关系。这种自然语言的字符与二进制数之间的对应规则叫做字符编码。）编码是什么编码是信息从一种形式或格式转换为另一种形式的过程，也称为计算机编程语言的代码简称编码。用预先规定的方法将文字、数字或其它对象编成数码，或将信息、数据转换成规定的电脉冲信号。–来自百度百科解码是一种用特定方法，把数码还原成它所代表的内容或将电脉冲信号、光信号、无线电波等转换成它所代表的信息、数据等的过程。–来自百度百科（继续上边的例子，现在ascii字符集与计算机语言之间的对应关系已经存在了。计算机中把从其他字符翻译成计算机中的二进制叫做编码（例如：ASCII码对照表中，a对应的是73，人类输入a，保存到计算机中，被翻译成了二进制的97，这个过程叫编码）。反过来计算机保存的"0110 0001"也就是十进制的97，显示在你的显示屏幕上的时候是根据ASCII码对照表反向翻译过的，这个过程叫解码。如果按照A规则存储，同样按照A规则解析，那么就能显示正确的文本符号。反之，按照A规则存储，再按照B规则解析，就会导致乱码现象。（A规则可以理解成ASCII对应关系，b规则理解为utf-编码））字符集的发展史ASCII字符集 ：ASCII（American Standard Code for Information Interchange，美国信息交换标准代码）是基于拉丁字母的一套电脑编码系统，用于显示现代英语，主要包括控制字符（回车键、退格、换行键等）和可显示字符（英文大小写字符、阿拉伯数字和西文符号）。基本的ASCII字符集，使用7位（bits）表示一个字符，共128字符。ASCII的扩展字符集使用8位（bits）表示一个字符，共256字符，方便支持欧洲常用字符。ISO-8859-1字符集：拉丁码表，别名Latin-1，用于显示欧洲使用的语言，包括荷兰、丹麦、德语、意大利语、西班牙语等。ISO-5559-1使用单字节编码，兼容ASCII编码。GBxxx字符集：GB就是国标的意思，是为了显示中文而设计的一套字符集。GB2312：简体中文码表。一个小于127的字符的意义与原来相同。但两个大于127的字符连在一起时，就表示一个汉字，这样大约可以组合了包含7000多个简体汉字，此外数学符号、罗马希腊的字母、日文的假名们都编进去了，连在ASCII里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的"全角"字符，而原来在127号以下的那些就叫"半角"字符了。GBK：最常用的中文码表。是在GB2312标准基础上的扩展规范，使用了双字节编码方案，共收录了21003个汉字，完全兼容GB2312标准，同时支持繁体汉字以及日韩汉字等。GB18030：最新的中文码表。收录汉字70244个，采用多字节编码，每个字可以由1个、2个或4个字节组成。支持中国国内少数民族的文字，同时支持繁体汉字以及日韩汉字等。Unicode字符集 ：Unicode编码系统为表达任意语言的任意字符而设计，是业界的一种标准，也称为统一码、标准万国码。它最多使用4个字节的数字来表达每个字母、符号，或者文字。有三种编码方案，UTF-8、UTF-16和UTF-32。最为常用的UTF-8编码。 1. 128个US-ASCII字符，只需一个字节编码。 2. 拉丁文等字符，需要二个字节编码。 3. 大部分常用字（含中文），使用三个字节编码。 4. 其他极少使用的Unicode辅助字符，使用四字节编码。（ASCII：简单的说就是美国发明了计算机之后，用7位（bits）表示一个字符，来表达自己语言的文字，一个字节是8位，还空了一位，最高位被置为0。然后国际商业机器公司又加入了一些扩展，比如音标什么的，这下把8位全用上了。ISO-8859-1：欧洲其他国家用电脑的时候发现全是英语，你让我们这些母语不是英语的人怎么办,于是制定了ISO-8859-1字符集，兼容ASCII编码（比如ASCII中97表达的是是小写的a，ISO-8859-1中97依然是小写的a，ISO-8859-1没有修改ASCII原来的字符集，只是在你的基础上扩展）。GBxxx:GB2312：终于，计算机传到中国了。美国人发明的ascii码，只要表达大小写26个字母，加上些字符就行了，但是中国的汉字很多，无法用1字节也就是八位标识，所以当时就制定了GB2312，规定了每个字占据2bytes。由于要和ASCII兼容，那这2bytes最高位不可以为0了（否则和ASCII会有冲突）。GBK：之前只知道中国汉字多，但是没有想到这么多啊，原来规定汉子和计算机语言对应关系的时候，漏掉了好多汉字，所以在GB2312的基础上做了个扩展。GB18030：后来发现中国的汉字确实很多，上次的GBK依然有漏掉的汉字。那就继续加吧，不过这次扩展的时候又遇到了新的问题：2字节一共才16位，最多才能表达65535个汉字，为了不跟ASCII冲突最高位又不能用，这下最多只能规定3万多了。因此GB18030多出来的汉字使用4bytes编码。当然，为了兼容GBK，这个四字节的前两位显然不能与GBK冲突。Unicode:统一各个国家所有文字的编码，Unicode应运而生，最多使用4个字节的数字来表达每个字符。）字符集和字符编码那点事计算机要准确的存储和识别各种字符集符号，需要进行字符编码，一套字符集必然至少有一套字符编码。等等，一套字符集必然至少有一套字符编码，那岂不是……没错，每套字符集可能会有多个字符编码，就像这样这是什么意思哪，其实也很好理解，就是字符集是固定的，比如现在有一套字符集，只有小写的26个字母。A在编写对应规则的时候把97对应a（ascii），但是B在编写的时候非要把计算机中的98对应a。这就是同样的字符集，我用不同的对应规则去翻译成计算机的语言，翻译成的计算机序言肯定不是一样的。但是utf-8和utf-16、utf-32，并没有改变对应规则，只是改变了在计算机中的存储长度。还记得上边说过的Unicode最多只能存四个字节吗，这就意味着，Unicode中不同的字符可以用1个、2个、3个或者4个字节保存。UTF-16就是任何字符对应的数字都用两个字节来保存。UTF-8时表示一个字符是可变的,有可能是用一个字节表示一个字符,也可能是两个,三个.当然最多不能超过3个字节。UTF-32就是把所有的字符都用32bit也就是4个字节来表示。当指定了编码，它所对应的字符集自然就指定了