首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

python第二十八课——编码小常识

2.内存和硬盘: 内存:计算机硬件组成部分之一,它是一个容器,用来存储数据;处理数据速度快, 存储数据量小;断电死机数据会丢失,短暂性存储数据 硬盘:计算机硬件组成部分之一,它是一个容器,用来存储数据;处理数据速度慢, 存储数据量大,断电死机数据不会丢失,数据的持久存储 3.字节和字符 字节:计算机的存储数据的单位,底层唯一能够识别并且运算的数据 字符:人类将字节封装为另一种能直接识别的数据单位,底层还是字节 4.如何区分字节文件和字符文件 如果使用文本编辑器打开能看得懂(不会乱码)那它就是一个字符文件, 反之,它是一个字节文件 提问:常见的字节文件和字符文件有哪些?(枚举出一些) 字节文件:图片文件(.jpg、.png...)、视频文件(.avi、.mp4、.rmb...)、音频文件(.mp3...) 字符文件:.txt、.py、.java、.js、.html、.css、.php... 思考:.doc结尾的文件是字节还是字符文件? 是字节文件,因为.doc结尾的文件中既可以包含字符内容,也可以包含图片、颜色设置...操作 思考:计算机数据层面,一切皆字节,对不对? 对的;因为计算机底层唯一能够识别和运算的都是字节数据... 5.字符编码(字符集) ascii码表:U.S.A设计出来的,范围非常小;不包含很多国家的文字,英文字符占用内存1个字节 utf-8码表:现今比较通用的一张编码表,包含了世界上所有的文字内容,范围:0~65535之间, 1个汉字占用内存3个字节,1个英文字符占用内存1个字节 gbk码表:gbk属于gb2312的扩充版,兼容了gb2312中的所有字符,加入更多的一些汉字内容, 1个汉字占用内存2个字节,1个英文字符占用内存1个字节, 在我们中国环境下,大多数情况默认的都是gbk作为编码 6.编码和解码: 编码:让数据从看的懂到看不懂,就是编码 解码:让数据从看不懂到看得懂,就是解码 【注意】 编码和解码如果不一致会怎么样? 1).会出现乱码现象 2).会报错 不管是上述的1还是2都是不理想的结果,我们都需要避免 字符串的两个函数引入: encode(encoding,errors):对字符串数据进行编码操作,得到一个bytes类型的数据 decode(encoding,errors):对字符串数据进行解码操作,得到一个str类型的数据 演示eccode()和decode()函数的使用:

01

快速学习-NameNode和SecondaryNameNode

思考:NameNode中的元数据是存储在哪里的? 首先,我们做个假设,如果存储在NameNode节点的磁盘中,因为经常需要进行随机访问,还有响应客户请求,必然是效率过低。因此,元数据需要存放在内存中。但如果只存在内存中,一旦断电,元数据丢失,整个集群就无法工作了。因此产生在磁盘中备份元数据的FsImage。 这样又会带来新的问题,当在内存中的元数据更新时,如果同时更新FsImage,就会导致效率过低,但如果不更新,就会发生一致性问题,一旦NameNode节点断电,就会产生数据丢失。因此,引入Edits文件(只进行追加操作,效率很高)。每当元数据有更新或者添加元数据时,修改内存中的元数据并追加到Edits中。这样,一旦NameNode节点断电,可以通过FsImage和Edits的合并,合成元数据。 但是,如果长时间添加数据到Edits中,会导致该文件数据过大,效率降低,而且一旦断电,恢复元数据需要的时间过长。因此,需要定期进行FsImage和Edits的合并,如果这个操作由NameNode节点完成,又会效率过低。因此,引入一个新的节点SecondaryNamenode,专门用于FsImage和Edits的合并。 NN和2NN工作机制,如图3-14所示。

01

Table '.\tablename' is marked as crashed and should be repaired

具体报错如下: Table '.\tablename' is marked as crashed and should be repaired 提示说论坛的帖子表posts被标记有问题,需要修复。我记得以前也出现过类似的问题,但是只要点击Phpmyadmin上的repair按纽就自动修复了,但是这次很绝,什么都没有.于是赶快上网查找原因。最终将问题解决。解决方法如下: 找到mysql的安装目录的bin/myisamchk工具,在命令行中输入: myisamchk -c -r ../data/tablename/table.MYI 然后myisamchk 工具会帮助你恢复数据表的索引。好象也不用重新启动mysql,问题就解决了。 问题分析: 1、 错误产生原因,有网友说是频繁查询和更新dede_archives表造成的索引错误,因为我的页面没有静态生成,而是动态页面,因此比较同意这种说法。 还有说法为是MYSQL数据库因为某种原因而受到了损坏,如:数据库服务器突发性的断电、在提在数据库表提供服务时对表的原文件进行某种操作都有可能导致 MYSQL数据库表被损坏而无法读取数据。总之就是因为某些不可测的问题造成表的损坏。 2、问题解决办法。 当你试图修复一个被破坏的表的问题时,有三种修复类型。如果你得到一个错误信息指出一个临时文件不能建立,删除信息所指出的文件并再试一次--这通常是上一次修复操作遗留下来的。 这三种修复方法如下所示: % myisamchk --recover --quick /path/to/tblName % myisamchk --recover /path/to/tblName % myisamchk --safe-recover /path/to/tblName 第一种是最快的,用来修复最普通的问题;而最后一种是最慢的,用来修复一些其它方法所不能修复的问题。 检查和修复MySQL数据文件 如果上面的方法无法修复一个被损坏的表,在你放弃之前,你还可以试试下面这两个技巧: 如 果你怀疑表的索引文件(*.MYI)发生了不可修复的错误,甚至是丢失了这个文件,你可以使用数据文件(*.MYD)和数据格式文件(*.frm)重新生 成它。首先制作一个数据文件(tblName.MYD)的拷贝。重启你的MySQL服务并连接到这个服务上,使用下面的命令删除表的内容: mysql> DELETE FROM tblName; 在 删除表的内容的同时,会建立一个新的索引文件。退出登录并重新关闭服务,然后用你刚才保存的数据文件(tblName.MYD)覆盖新的(空)数据文件。 最后,使用myisamchk执行标准的修复(上面的第二种方法),根据表的数据的内容和表的格式文件重新生成索引数据。 如果你的表的 格式文件(tblName.frm)丢失了或者是发生了不可修复的错误,但是你清楚如何使用相应的CREATE TABLE语句来重新生成这张表,你可以重新生成一个新的.frm文件并和你的数据文件和索引文件(如果索引文件有问题,使用上面的方法重建一个新的)一 起使用。首先制作一个数据和索引文件的拷贝,然后删除原来的文件(删除数据目录下有关这个表的所有记录)。 启动MySQL服务并使用当初的CREATE TABLE文件建立一个新的表。新的.frm文件应该可以正常工作了,但是最好你还是执行一下标准的修复(上面的第二种方法)。

01
领券