稀疏编码什么是chunked编码？

户户通8位编码是属于什么区域？

属于新疆地区。

首先，户户通接收机的位置锁定模块有两种制式，一种是GSM,另一种是CDMA。

GSM制式要用中国移动的手机卡激活，CDMA制式需要用中国电信的手机卡激活。

GSM制式被大部分省份所采用，也就是说我们现在手里的机器都是GSM制式的，而CDMA制式目前只是在青海使用。

1.那么机顶盒是依据什么来定位的呢。

有些人以为是根据手机卡或者手机号码来定位，以为用个农村的手机号码就可以解除定位，这是误解。

其实和手机号码一点关系都没有！！！只要是相应制式的任何一个开通了上网功能的手机卡都可以。

其实户户通接收机的位置锁定模块是根据机器安装位置所搜索的手机基站的代码来区分和比对的，不是根据手机号码来比对。

举例说：如果安装地搜索的基站分别有A、B、C、D、E五个基站，户户通用户管理系统里面基本上有全国的手机基站代码（每个基站的代码都是唯一的不重复）。

而这些代码在户户通用户管理系统的数据库里也分了类，有的分在“城市”这类，有的不是。

?当接收机搜索并保存了这5个基站信息时，机器里面的位置锁定模块通过你开通了上网功能的手机卡上网，连接到户户通用户管理系统的接收服务器，同时把5个基站代码上传到户户通的用户管理系统。

这时，户户通用户管理系统会根据机器上传上来的基站代码去数据库里面对比，如果这5个基站的代码是分类在“城市”基站数据库里面，那么就不发送授权指令，并在用户管理系统中显示客户状态为“进城安装”，这时在机器安装现场，等半天机器也看不了节目，界面显示“安装过程中，请等待”，你等一天也是这种显示，因为系统不发授权指令给机器，机器就解不了节目。

如果上传的基站代码和户户通用户管理系统里面的基站代码数据库对比，不是属于“城市”的基站代码，也不是跨省的。

则户户通用户管理系统会即时发送授权指令，接收机收到授权指令后，马上就可以解出节目来。

?如果你安装地搜索上传的基站信息不属于户户通用户管理系统里面“城市”数据库的，即使是在城市，也会发授权指令给机器，这样就可以正常接收。

而户户通系统的基站信息“城市”数据库和实际的城市，有重叠的地方，但又不完全一致！ 如果把某个农村的基站代码放到“城市”数据库里面，则系统照样提示是进城安装，只是和数据库对比而已。

2.如果在农村激活，拿到城市或者其它地方： 在某个地方激活授权后，机器就存储了激活的时候搜索到的基站代码，过段时间，机器的模块会自动搜索周边的基站代码，如果和原来存储的基站代码完全不同，则机器停止解码，这时就看不到节目了，机器菜单会提示“位置信息异常”。

如果最少还有一个基站代码和原来的基站代码相同，则还是可以正常解码。

从这点就应该清楚了解到：安装的时候尽量多搜索出一些基站信息并保存是多么的重要，如果你安装的时候搜索到3个基站信息，和搜索到5个以上的基站信息对比，肯定是3个基站信息出现位置信息异常的几率更大。

如果你在一个地方安装激活，拿到另外一个地方用，但还没有超出你激活时候存储的手机基站范围（新的地方最少有一个基站代码和原来激活时一样），则可以正常收看。

如果新的地方基站代码和原来激活时存储的基站代码完全不同，则不能看。

对于小城市（或大城市的郊区），有可能会出现这种情况：就是你在城里装的时候，户户通用户管理系统里提示进城安装。

但拿到附近乡下再重新激活，可以正常看节目，然后又拿到城里，也能正常使用。

这是什么原因呢？就是你在激活的时候存储的基站信息有部分基站代码在户户通系统“城市”数据库里面，但又有些基站代码不在这个“城市”数据库里面。

当你在城市用的时候，新搜索的基站代码还最少有一个原来存储的基站代码一样，所以还可以看。

这就解释了论坛里有朋友说户户通的机子在市区里开卡成功的原因。

从这里，可能你会想到一个办法，激活的时候，外接一个做工程用的手机基站信号接收天线，把方圆几十公里的手机基站代码都搜下来并激活上传到户户通管理系统服务器上，也许这样在城市郊区或者城市也能用。

3.定位后最大移动距离 所谓最大移动距离没有一个标准，各地区也有差别，主要取决于基站密度和强度。

平均1公里左右。

参考资料 地理网.地理网[引用时间2017-12-19]

汽车导航仪表上的src是指什么

采样率，我们直每看到的一副画面都是上亿像素的，我们的大脑很难像电脑那样直接存储。

研究表明，我们将每一副图像都提取出很少的信息用于存储是可行的。

我们把它叫做稀疏编码，即Sparse Coding.把稀疏编码的方法运用到分类中的机器学习方法，就叫做SRC.即采样率，采样率越高分辨率也越高，保真度越高，但数据量也越大，所以根据需要取适当值即可。

为什么稀疏自编码器很少见到多层的

Ivan Goodfellow, Yoshua Bengio, Aaron Courville的Deep Learning中14.3节描述了深度自编码器像其他深度神经网络一样能够指数级减少训练数据和计算资源需求。

在实践中，深度自编码器比浅层自编码器有更好的压缩性能。

我们之所以很少看到深度自编码器，是因为一般训练深度自编码器的方法是采取贪心策略，逐层训练浅层自编码器。

什么是chunked编码？

chunked编码的基本方法是将大块数据分解成多块小数据，每块都可以自指定长度，其具体格式如下（BNF文法）: Chunked-Body = *chunk //0至多个chunk last-chunk //最后一个chunk trailer //尾部 CRLF //结束标记符 chunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLF chunk-size = 1*HEX last-chunk = 1*("0") [ chunk-extension ] CRLF chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] ) chunk-ext-name = token chunk-ext-val = token | quoted-string chunk-data = chunk-size(OCTET) trailer = *(entity-header CRLF) 解释： Chunked-Body表示经过chunked编码后的报文体。

报文体可以分为chunk, last-chunk，trailer和结束符四部分。

chunk的数量在报文体中最少可以为0，无上限；每个chunk的长度是自指定的，即，起始的数据必然是16进制数字的字符串，代表后面chunk-data的长度（字节数）。

这个16进制的字符串第一个字符如果是“0”，则表示chunk-size为0，该chunk为last-chunk,无chunk-data部分。

可选的chunk-extension由通信双方自行确定，如果接收者不理解它的意义，可以忽略。

trailer是附加的在尾部的额外头域，通常包含一些元数据（metadata, meta means "about information"），这些头域可以在解码后附加在现有头域之后。

实例分析： 下面分析用ethereal抓包使用Firefox与某网站通信的结果（从头域结束符后开始）： Address 0.......................... f 000c0 31 000d0 66 66 63 0d 0a ............... // ASCII码:1ffc , chunk-data数据起始地址为000d5 很明显，“1ffc”为第一个chunk的chunk-size,转换为int为8188.由于1ffc后马上就是 CRLF,因此没有chunk-extension.chunk-data的起始地址为000d5, 计算可知下一块chunk的起始 地址为000d5+1ffc + 2=020d3,如下： 020d0 .. 0d 0a 31 66 66 63 0d 0a .... // ASCII码: 1ffc 前一个0d0a是上一个chunk的结束标记符，后一个0d0a则是chunk-size和chunk-data的分隔符。

此块chunk的长度同样为8188, 依次类推，直到最后一块 100e0 0d 0a 31 100f0 65 61 39 0d 0a...... //ASII码： 1ea9 此块长度为0x1ea9 = 7849, 下一块起始为100f5 + 1ea9 + 2 = 11fa0,如下： 100a0 30 0d 0a 0d 0a //ASCII码：0 “0”说明当前chunk为last-chunk, 第一个0d 0a为chunk结束符。

第二个0d0a说明没有trailer部分，整个Chunk-body结束。

解码流程： 对chunked编码进行解码的目的是将分块的chunk-data整合恢复成一块作为报文体，同时记录此块体的长度。

RFC2616中附带的解码流程如下：(伪代码） length := 0 //长度计数器置0 read chunk-size, chunk-extension (if any) and CRLF //读取chunk-size, chunk-extension //和CRLF while(chunk-size > 0 ) { //表明不是last-chunk read chunk-data and CRLF //读chunk-size大小的chunk-data,skip CRLF append chunk-data to entity-body //将此块chunk-data追加到entity-body后 read chunk-size and CRLF //读取新chunk的chunk-size 和 CRLF } read entity-header //entity-header的格式为name:valueCRLF,如果为空即只有CRLF while （entity-header not empty) //即，不是只有CRLF的空行 { append entity-header to existing header fields read entity-header } Content-Length:=length //将整个解码流程结束后计算得到的新报文体length //作为Content-Length域的值写入报文中 Remove "chunked" from Transfer-Encoding //同时从Transfer-Encoding中域值去除chunked这个标记 length最后的值实际为所有chunk的chunk-size之和，在上面的抓包实例中，一共有八块chunk-size为0x1ffc(8188)的chunk,剩下一块为0x1ea9(7849),加起来一共73353字节。

注：对于上面例子中前几个chunk的大小都是8188,可能是因为:"1ffc" 4字节，" "2字节，加上块尾一个" "2字节一共8字节，因此一个chunk整体为8196,正好可能是发送端一次TCP发送的缓存大小。