【杂谈与乱码】操作系统和二进制
本人（ID：蒸发杰作）旗下所有文章均放弃版权，请任意使用。只是如果您觉得，看了我的文章，有所收获的话，不妨点个赞，写个评论。这是对我最大的支持。
——杂谈与乱码，都是戏言。
要当个好程序员，首先也当个好的哲学家。
首先，谈谈两个东西。
数据结构？
第一个是广为人知的，频繁出现于C语言考题的万能公式：程序=数据结构+算法。新手一般都看不懂这句话，或是自以为看懂了这句话。等到他们学到数据结构的时候，感慨数据结构的强大之后，又会感慨这个公式的强大。然后就想当然的认为这个公式中的数据结构说的就是每个计算机学院在大二开设要挂上不少人的那个数据结构。
答案当然是——WBNT(wrong，but not too|错了但不离谱)
数据结构就像是程序语言的数学一样，特化部分结构，抽象这些过程，并为每种结构提供对应的算法。之后每个二流的程序设计师也可以在公开场合宣称自己是研究过各类排序，树/图结构的API斗士了。
这种特化带来了好处。
使你多掌握了几个拗口，但厉害的名词。
也带来了坏处，忽略了一般特性。
例如，最基本的都不需要用图，或树进行任何抽象的结构。——线性结构。例如最常见的用二进制字节流表示图片。
同样的，我们也完全可以来自定义我们的结构。如，用二进制字节流来表示成语。来存储特定的消息流。反应到操作系统上，就加一个特定的后缀，如成语，我就加一个中文的 *.成语 后缀。
操作系统
打开文件的时候，操作系统干了什么？
打开文本文件的时候，操作系统，将二进制码翻译成了对应文字。图片文件的时候，操作系统将二进制码翻译成了对应图片。
这一切靠识别文件的后缀名来完成。你可以将一个图片用记事本打开，显示的结果是有趣的，你会得到中文汉字。这说明关于图片的哪些个二进制码被记事本翻译成对应的汉字了。
这便是最简单封装。
现在很多人会打开文件，读取文件，而一到图片或者是视频或者是什么其他文件就一下傻的要命，就啥也不会干了。
windows系统下是不提供直接基于二进制修改文件的方法的，伟大的不朽的全能的微软公司认为这是不好的。但一些简单的编程处理使我们可以完成这点。
例如我们可以打开VS或者类似的软件。打开文件，打开方式选择以二进制方式打开。(百度一下你就知道)
得到如下的截图:
当时我们学习C语言的时候，各种进制学的欢腾，但最大的败笔就在于完全不用。纯粹为了学而学习，学的就是一堆占用我们思考空间的垃圾。被垃圾填满的是什么，当然也是垃圾场，仅此而已。你和我，都是。
一个1或者0构成一个bit；2^8=256,可以表示ASCII码对应下对英文友好的所有字符；因而定8bit=1byte字节;
这个txt的内容就是123，信息内容占三个字节。（占用空间为0我实在不知道什么原因，推测可能是系统自动塞在了其他程序的缝隙之间吧）由此可见，.txt的是没有用额外的信息来记录这串文字用什么编码的。因而，编码只能靠记事本来猜测。
碰到有多种编码方式的中文的时候，他经常猜错。这时候就需要我们认为的去设置编码方式了。
而对于另外一些文档，其本身是自描述的。既用一部分空间存储编码或者结构组织方式，又用一部分空间存储信息。耗费更多空间，但解决很多兼容性问题。
下次我们可以谈谈那些个常用的编码方式和他们的历史，在我不醉的时候。
回到上上图，123是显示的信息，00000000是地址位置。每一位都是进制的，8（个位置）*8（一个字节8bit）=64位。如果一个64位放不下的话的话。就是像下边这样的。
至于后边的数字，就是十六进制而已。
打开一个图像不也打开的都是这些么？
学会对bit进行操作的程序员才是好的而程序员。在过去的时代，C语言擅长做这点，但在现在这种底层封装原来越完善，分工越来越明确的年代。很多开发成员完全不碰底层。
而结果一般是很明显的，不碰底层，就只能做API斗士。希望我能避免写程序=用函数的局面。
最后的最后
好了。我发完我的牢骚了。也到了该安息的时候了。
我如此总结道今天的内容：封装提高效率，但扼杀更好的封装。
你觉得上面那句话太玄了也没关系，可能下面这句话更加适合你。
计算机=协议（或者叫API）+二进制
请记住，只会处理文本的各位大师们啊，处理图像和处理视频以及其他一切事物的方法都是一致的，本质就是理解其结构（而这个是由其设计者给出的，本质上就是一份协议），然后操作二进制，罢了。
也许明天我酒醒后会补一份PYTHON做图像转换的程序的。