Differences between revisions 15 and 16
⇤ ← Revision 15 as of 2007-05-17 15:17:09 →
Size: 3224
Editor: ZoomQuiet
Comment:
← Revision 16 as of 2007-06-06 15:08:41 → ⇥
Size: 7598
Editor: ZoomQuiet
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
||'''status'''|| 草稿 || ZoomQuiet || 50%|| ||'''status'''|| 草稿 || ZoomQuiet || 80% ||
Line 47: Line 47:
Line 71: Line 70:
 * 也就是说文件没有编码之说，大家其实都是二进制格式保存在硬盘中的，仅仅是在写入读取时需要使用对应的编码进行处理，以便操作系统配合相关软件/字体绘制到屏幕中给人看
  * 所以,关键问题是得知道原先这些字串数据是使用什么编码来编译的!
  * 但是,在Unicode 之前,都是使用类似对照表的形式来组织编码的,无法从串数据流本身中统一解出不同的文字来,
  * 只有猜!

{{{猜编码函式一
}}}
 * 嗯嗯嗯,收集的音乐可是不仅仅中文的,印度,伊朗等等音乐都可能有收集,逐一去尝试,这个判定树就太可怕了!
 * 升级!使用Python 的数据对象进行集成!
{{{猜编码函式二
}}}
 * 但是....
Line 72: Line 83:
这么一项项猜,还是显的很惾哪,万一有些字的高位在不同编码中是相同的,那真的是只能撞大运了!
 * 问吧...
 * http://chardet.feedparser.org/ -- Character encoding auto-detection 自动字符探测器!
 * 呃真的有哪! 而且是 Mozilla 使用的! 立用不疑!
{{{聪明编码函式
}}}
 * 经过测试在各种情况下都可以正确识别!
 * 但是怎么尝试已经保存下来的 .cdc 文本依然是 `ASCII` 码!
Line 74: Line 94:
也许真的就是 ASCII 码呢?
Line 76: Line 97:

 * 冷静一下 -- "既然,文件没有编码都是二进制的,那么光盘文件是如何被系统认识的?!"
 * `iso9660` -- 嗯嗯嗯,所有光盘基本都是此文件格式的,同M$使用的 FAT32/ntfs,GNU/Liunx 使用的 ext2/3,Unix使用的nfs...各种文件系统都不同
 * 则必然是通过某种软件进行转换从而可以访问的
 * 咳 -- Ubuntu 中当然是标准的调用 朴实强大的`mount`命令了
 {{{
$cat /etc/mtab
...
/dev/sda3 /dos vfat rw,utf8,umask=007,gid=46 0 0
...
/dev/sda1 /windows ntfs rw,nls=utf8,umask=007,gid=46 0 0
/dev/scd0 /media/cdrom0 iso9660 ro,noexec,nosuid,nodev,user=zoomq 0 0
...
}}} 观察默认的挂接光盘的行为和挂接 dos 和 windows 分区的情况,感觉是默认的挂接行为没有使用编码处理
 * 那么通过改变挂接行为,应该可以改善读取不到正确文本的情况?!
{{{
#挂接成GBK
$ sudo mount -o ro,norock,iocharset=cp936 /dev/scd0 /media/cdrom0
#挂接成UTF8
$ sudo mount -o ro,norock,iocharset=utf8 /dev/scd0 /media/cdrom0
}}}
 * 咔咔咔!果然!果然!
 * 相对M$ 系统,安装成什么语言的系统,就永远使用什么编码强行挂接光盘的,好象似乎八成应该不是可以轻易的按照你的意愿改门厅的...
 * 以前小白对于自由软件的认识仅仅是免费,难用--这下忽然间有所顿悟,不觉写下感慨:
Line 77: Line 123:

 * 自由之所以,自由是基于对自个儿的了解,真正理解了自个儿想要什么之后,自由软件支持你的一切尝试!哈哈哈!
 * 小白可以感受到这些可以算是`小灰`了,可以稳定的向成熟的`小黑` -- 一名黑客挺进了!
 
Line 80: Line 127:

查询是可以了,但是,使用默认的列表打印格式来存储和汇报实在不乍的, 想修改就修改
{{{改进的记录格式控制片段
}}}
 * 存储下来的 .cdc 片段{{{
...
-f /media/cdrom0/RyokoHirosue/Ryoko Hirosue-files.files title.gif
======================================================================
/media/cdrom0/RyokoHirosue/成长物语
-d /media/cdrom0/RyokoHirosue/成长物语 音乐极限--成长物语.files
-f /media/cdrom0/RyokoHirosue/成长物语 RH991101.mp3
-f /media/cdrom0/RyokoHirosue/成长物语 RH991102.mp3
}}}
 * `d`代表目录;`f`代表文件
 
Line 85: Line 144:
这日,小白仅仅解决了一个问题 -- 中文搜索问题;解决尝试路途及相互关系如上图所示
但是,实际上获得了两大方面的进步:
 * 文本编码方面的知识
 * 问题解决的方法论境界提高了一个层次,开始使用系统级别的解决方案

相对Python 方面,仅仅有一对内置函式,和一个外部模块包使用的体验

'''关键词''':
 * 编码
 * unicode
 * chardet
 * mount

'''注意'''
 * 如果你使用M$ 系统,运气好的话,是不会见到笔者列出的现象的,但是不保证以后遇不到自动处理下搞不掂的光盘内容;希望那时候小白真的有个自由环境可以尝试其它方案 ;)
Line 86: Line 161:

1. 自动判定你自个儿的Blog 是什么编码的?

2. 如果是非utf-8 的,编写小程序自动将指定文章转换成utf-8 编码保存?

status

草稿

ZoomQuiet

80%

TableOfContents

1. -1 PyDay 实用化,中文!

你能够碰到的问题,99%的情况下其它人已经遇到过了,所以,最佳的解决方式就是找到那段别人解决相似问题的代码!

1.1. 回顾需求

小白已经实现的需求已经到达这般了:

  1. 可以扫描光盘内容并存储为硬盘上的文本文件
    • 存储成*.cdc 的文本文件
    • 可以快速指定保存目录
    • 可以快速指定保存的文件名
  2. 可以根据储存到硬盘上的光盘信息进行搜索
    • 可以搜索指定目录中所有*.cdc文件
    • 可以指定关键字进行搜索
      • 列出所有含有关键字的信息行

1.1.1. 进一步

回想起来一直尝试搜索的都是E文关键字,中文的没有试过;

来几下! ... 呜乎矣哉,什么也查不出来!

1.2. 查阅记录文本

attachment:badcdc-chinese.png

这种数据对嘛？

  • 当初为了简单使用文档中的基本型:{{{#'cdctools.py' 中 cdWalker(cdrom,cdcfile) 的动作

...

  • for root, dirs, files in os.walk(cdrom):
    • export+="\n %s;%s;%s" % (root,dirs,files)

... }}}就是使用 os.walk() 的天然输出组织成每一行:

/media/cdrom0/EVA/Death-Rebirth;[];['eva8-01.Mp3', 'eva8-02.Mp3',...]
    ^                          ^ ^  ^ 
    |                          | |  +- files列表，此目录的文件名 
    |                          | +- 各个数据段使用";" 分隔
    |                          +- dirs列表，子目录名，如果没有就为空
    +- 当前目录
  • 瞧着格式象，为什么到中文的地方就是问号呢？

1.3. 中文!永远的痛

不问不知道,一把辛酸泪哪...

  • 列表什么的一搜索才知道,只要是个中国人,不论整什么开发,中文!永远有问题的
  • 幸好比小白勤劳的人海了去,有关中文的Python 处理也是一搜一大堆

  • 但是!有时候,选择太多也是个问题;-)

1.3.1. 编码问题

attachment:coding.png

attachment:ipy-try-walk.png

  • 嗯嗯嗯，看着就不同,根据理解继续尝试是否理解

attachment:ipy-try-trans-utf8.png {{{ unicode(原始文本, 'utf8' ).encode('utf8') 文本 ==decode()--> [unicode] ==>encode()--> utf-8文本

  • ^ | | | | +- 最终的渴求 | | | +- 是为编码过程;可以从unicode 输出为任意编码 | | +- Python 内置支持的unicode 格式数据 | +- 是为解码过程,将已知编码的文本编译成宇宙通用的unicode数据 +- 原始文本信息,是什么编码你得知道!

}}}

  • 也就是说文件没有编码之说，大家其实都是二进制格式保存在硬盘中的，仅仅是在写入读取时需要使用对应的编码进行处理，以便操作系统配合相关软件/字体绘制到屏幕中给人看
    • 所以,关键问题是得知道原先这些字串数据是使用什么编码来编译的!
    • 但是,在Unicode 之前,都是使用类似对照表的形式来组织编码的,无法从串数据流本身中统一解出不同的文字来,
    • 只有猜!

ObpLovelyPython/CDay-1 (last edited 2012-03-03 10:28:10 by ZoomQuiet)