002.Python基础语法

语法"/>

002.Python基础语法

我 的 个 人 主 页：👉👉 失心疯的个人主页 👈👈
入 门 教 程 推 荐 ：👉👉 Python零基础入门教程合集 👈👈
虚 拟 环 境 搭 建 ：👉👉 Python项目虚拟环境(超详细讲解) 👈👈
PyQt5 系 列 教 程：👉👉 Python GUI(PyQt5)文章合集 👈👈
Oracle数据库教程：👉👉 Oracle数据库文章合集 👈👈
优 质 资 源 下 载 ：👉👉 资源下载合集 👈👈

Python基础语法_注释 | 中文乱码

• Python的注释
• Python的中文乱码

Python的注释

• 注释描述：一段文字性的描述
• 注释特性：当程序被处理的时候，这些注释会被自动忽略，不会被当做代码处理
• 注释应用
  • 帮助我们自己理清楚代码逻辑
  • 与别人合作开发时，添加注释，减少沟通成本
  • 开发模块的时候添加注释，减少他人的使用成本
  • 可以临时注释一些代码，方便调试
• 注释分类：
  • 单行注释：内容前面加一个#

    # print('单行注释')
    

  • 多行注释

    # 方式一：多个井号
    # print('多行注释1')
    # print('多行注释2')
    # print('多行注释3')# 方式二：三对单引号
    '''
    print('多行注释1')
    print('多行注释2')
    print('多行注释3')
    '''# 方式三：三对双引号
    """
    print('多行注释1')
    print('多行注释2')
    print('多行注释3')
    """
    

  • 特殊注释：在文件顶部添加注释

    # 在Linux系统下指定python解释器路径，使py文件可以通过 ./a.py 的方式直接运行
    #!/user/bin/python					# 真实环境的python解释器路径
    #!/user/bin/env python				# 虚拟环境的python2解释器路径
    #!/user/bin/env python3				# 虚拟环境的python3解释器路径（常用）# 解决python2的中文支持问题，python3默认支持中文
    # python2默认支持的编码是ASII码，ASII码中没有中文，所以在python2中出现中文（包括注释），就会报错
    # encoding=utf-8
    # coding=utf-8
    # _*_coding:utf-8_*_				# python正规写法
    

• 关于虚拟环境：Python项目虚拟环境(超详细讲解)

Python的中文乱码

• 在Python2中，默认编码是ASCII码，在ASCII码中并不支持中文，所以中文会变成乱码。
• 但是，在Python3中，已经支持中文了
• 在python2中可以在文件顶部通过特殊注释解决中文乱码的问题
• 接下来，我们稍微了解一下出现乱码的原因：
  • 1、我们最终的目标就是将一段文本存储到存储器中
  • 2、首先来了解一下计算机存储器
  • 3、那么接下来，我们需要将一段文本存储到存储器中
  • 4、那么问题来了，存储器中只能存储数字，文本应该怎么存储进去呢？
    • 答：将字符转换为数字，再将数字直接存储到存储器中
  • 5、按照什么规范将文本转化为数字呢？又按照怎样的方式存储数字呢？
    • 答：通过字符编码来统一规范。
    • 6、出现乱码的原因：字符编码不只一种，有很多种
      • 就会出现同一个字符码对应的字符并不一致
      • 同一个字符，有的字符编码规定在存储器中用一个字节存储，有的字符编码规定在存储器中用两个字节存储
      • 比如：我同ASCII编码存储的字符“I”，在存储器中是73，我们从存储其中读取到73，然后用其他编码解码出来的可能就变成了字符 “大”…
      • 比如：其他字符编码规定存储一个字符到存储器中是2个字节，ASCII编码规定存储一个字符到存储器中是一个字节，那么用ASCII编码对其他字符编码存储的字符进行解码，那就会出现乱码的情况了
    • 7、总体来说，以一种字符编码来存储字符，用另外一种字符编码来解码存储的字符，由于两种字符编码范的文本转化为数字和数字存储方式不同而导致出现乱码
• 那会有人说，那直接统一一种字符编码就可以了啊！确实是这样，但是这就不得不从电脑的发展史来稍微讲一讲了：
  • 1. 计算机最早发明于美国,英语中主要就包括26个字母(大小写), 10个数字,标点符号,控制符等等;所以,最终就制定了ASCII字符编码,映射了字符和学符码的关系,并使用一个字节的后七位(0 -127)来存储;
  • 2. 慢慢计算机普及到西欧其他地区,发现好多字符没法识别处理;于是对ASCII进行了扩展,叫EASCII编码;还是一个字节，从128-255;但是针对于这一块的扩充,各个厂家各有自己的标准(比如当时比较有名的CP437);最后导致互相之间没法沟通;所以,后来,由国际标准化组织(IsO)以及国际电工委员会(IEC)联合制定了一个标准ISO/8859-1(Latin-1),继承了CP437的128-159;重新定义了160-255;
  • 3. 然后到中国之后,全都懵逼了;汉字博大精深,一个字节肯定不够; so,国人自己搞了一个GB2312来存储中文,6763个汉字;(双字节，兼容ASCII),可是,一开始还很爽;后来发现还有繁体字,藏文,蒙文,维吾尔文…懵逼X2;于是一狠心，搞了一个GBK,全给他们搞进来;
  • 4. 中国是搞定了,那日本,韩国…如果到时候,各有各的字符编码,那该怎样沟通?比如666,在中国代表NB;在岛国代表SB，那就乱套了;
  • 5. 所以,统一联盟国际组织,提出了Unicode编码;涵盖了世界上所有的文字,每一个字符都有对应的唯一一个字符码，这回天家都开心了，但是,针对于每个学符码,使角儿个字节存储的问题,又存在几个不同的具体解决方案;比如utf-8, utf-16, utf-32…所以,其实,我们讨论这边编码的时候,都是指Unicode编码