编码 on ZRJ | 学习笔记

怎么样快速预览一个 SQL Server 的 bak 文件

Mon, 14 Oct 2013 20:51:06 +0800

今天拿到一个 sql server 的 bak 文件，然而文件比较大，有 7G 多，而我手边又没有现成的 SQL Server 可以导入，而且，我眼下的需求也只是快速的预览一下文件的内容，确定一下真实性和正确性而已，就算有 Server，导入估计也要花上好几个小时吧。

在这种背景下，开始寻找一种简单的方式，可以让我快速的预览一个 sql Server 的 bak 文件，由于是在 Windows 平台，所以以下的故事都没用 linux 上的那一套。

首先想到的自然是 python，其实我也是通过 python 才知道这个文件是 sql server 的文件的，不然根据文件名还真没法判断。

但是只可惜 python 的作用也就仅仅到这一步，在交互的终端下，f = open(‘path/to/file’) 然后调用几次 f.readline() 除了看到一些 sql server 的版权信息之外，其余的都是乱码，python 的库么，没去尝试和考虑。

于是上网一阵搜，看到这里，http://stackoverflow.com/questions/8496737/opening-a-sql-server-bak-file-not-restoring，虽然有一些讨论，但是其实没多大帮助，继续自己鼓捣。

那么试试 winhex？由于 winhex 只解码 ascii，所以对于 bak 文件中的中文，依然是一片乱码，但是，我们细心点观察，可以发现其中有类似这样的片段：

看到那个「ID3770」啥啥啥然后「X」结尾的，看到后面对应的「19」啥啥啥然后「704」，嗯，可以反应过来，这个文件是明文的，嘿嘿，那就好说了，其实，想想也可以理解，这么大的文件，要是加密的话，计算量还不小的。

那么就把这段字节拷出来，用 winhex 新建一个文件，扔进去，保存，百来个字节，剩下的问题就是他的编码方式了，考虑到 notepad++ 的编码自动判断还不错，拿 notepad++ 开来看，咦，悲催了，还是乱码。

那改一下后缀，改成 html，丢给 google chrome 试试？chrome 还真不赖，自动识别虽然没有把编码识别出来，不过手工尝试过几个编码之后很快就找到是 unicode UTF16-LE 了，嗯，到此 human readable 的字符就出来了，大概看了看，没啥问题，于是我们本节的旅程就愉快的结束了。

历史评论

asdf (2014-09-30 02:15:35):

一看大小就知道楼主弄到的是什么东西。。呵呵

ZRJ (2014-09-30 14:17:08):

嘿嘿

再次折腾专辑封面

Mon, 03 Dec 2012 23:54:09 +0800

最近 itunes 升级，于是重新在整理音乐文件，看到那些没有专辑封面的 mp3，于是骨子里的不折腾不舒服斯基又发作了，手贱准备再次开始写一个自动工具来搞，上次的折腾记录在这里，根据 ID3 自动补充专辑封面和歌词

上次的失败是因为那个库对于中文的编码支持不是很好，于是最后就出现一些乱码问题，等等，于是这次准备换 python 搞，搜了一下，看到这几篇文章，http://hackerszone.diandian.com/post/2011-08-14/3887967，http://www.gracecode.com/posts/3009.html，http://www.fuchaoqun.com/2010/01/python-mp3-id3v2-lyrics-attached_picture/，http://pipitu.org/2010/05/14/mp3-id3-embed-cover/，于是我知道手贱的不止我一个，呵呵

他们用的 py 库是http://eyed3.nicfit.net，这次不搞图形界面，于是一通查资料，重新理清了 mp3 tag 的文件格式，按照我的理解，简单来说，是这样的

首先有一个不太成熟的 id3v1，这个东西的做法是把 title，album，artist 这些信息放到文件末尾，格式简单，编码是 ascii，所以不支持中文，而且有一个很大的问题是定长，30 个 char，于是后来演变出另外一种， id3v2，而这个 id3v2 还分为 id3v2.3，这个是目前最多的，也是兼容性最好的，他把这些信息放到文件头部，而且不定长，而且字段不定，所以灵活性很高，可扩展性很强，字符的编码可以是 ascii，或者 utf-8，但是 windows 对于 utf-8 的支持不好，所以如果是用 utf-8 的话，在资源管理器里面是看不出来的，所以 qq 音乐，千千静听这些，默认都是 id3v2.3 的 iso-8859-1，说是 iso-8859-1，其实本质上是 gbk，而 itunes 对于 gbk 和 utf-8 的解码都是没有问题的，所以最皆大欢喜的做法就是用 id3v2.3 的 iso-8859-1(gbk) 来编码，然后嵌入图形文件当作封面，这个 id3v2 还有一个 id3v2.4，这个比较新，所以不怎么广泛，他的优势是标签信息可以在文件头，也可以在文件尾，在文件头的劣势显而易见，每次改写都要重写整个文件，磁盘读写量很大，除了 id3v2，还有一种格式叫做 apev2，这个也比较先进，可惜的是普及率也不高。

方针路线定了，接下来就是实干了，照着前面几篇博客的代码，敲敲打打的得到下面这个代码

#!/usr/bin/env python
# -*- coding:utf-8 -*-
# 2012.12.3

'''根据豆瓣自动补全专辑封面'''

import os, sys, re, time, urllib, eyeD3

import logging
logging.basicConfig(filename = 'log%s.txt' % time.time(), 
                    filemode = 'w', 
                    format = '[%(levelname)s] [%(asctime)s] %(message)s', 
                    level = logging.DEBUG)

def fillCover(filename):
    logging.info('processing %s' % filename)
    t = eyeD3.Tag()

    try:
        t.link(filename)
    except:
        logging.error('can not open file')
        return False

    images = t.getImages()
    if len(images) > 0:
        logging.info('alreay has cover images')
        return True

    title = t.getTitle()
    album = t.getAlbum()
    artist = t.getArtist()
    logging.debug('title is %s' % title)
    logging.debug('album is %s' % album)
    logging.debug('artist is %s' % artist)

    if title and artist:
        keyword = ' '.join([title, artist])
        keyword = keyword.encode('utf-8')
    else:
        logging.debug('no id3 tags')
        keyword = filename.split('\')[-1].split('.')[0]
        keyword = keyword.encode('gbk')
    logging.debug('keyword is %s' % keyword)

    doubanSearchAPI = 'http://api.douban.com/v2/music/search?q={0}'
    request = doubanSearchAPI.format(urllib.quote(keyword))
    logging.debug('request is %s' % request)
    result = urllib.urlopen(request).read()
    logging.debug('result is %s' % result)

    # 豆瓣 API 限制是每分钟 10 次请求
    # http://developers.douban.com/wiki/?title=api_v2
    #logging.warn('sleep for 6 sec')
    #time.sleep(6)

    if not result:
        return False
    doubanCoverPattern = 's(d+).jpg'
    doubanCoverURL = 'http://img3.douban.com/lpic/s{0}.jpg'
    match = re.search(doubanCoverPattern, result, re.IGNORECASE)
    if match:
        coverFileURL = doubanCoverURL.format(match.groups()[0])
        logging.debug('cover image url is %s' % coverFileURL)
    else:
        logging.debug('no cover image url matched')
        return False

    try:
        logging.debug('downloading cover image file')
        coverFileName = ' - '.join([artist, album])+'.jpg'
        f = file(coverFileName, 'wb')
        f.write(urllib.urlopen(coverFileURL).read())
        f.close()
        logging.debug('download finished')
    except:
        logging.error('download error')

    try:
        logging.debug('adding image')
        t.addImage(3, coverFileName, u'')
        t.update()
        logging.info('successfully add image')
        return True
    except:
        logging.error('add image error')
        return False


def main():
    if len(sys.argv) < 2:
        print 'usage: %s /path/to/your/music/folder/' % __file__
        return False
    for i in os.listdir(sys.argv[1]):
        fillCover(os.path.join(sys.argv[1], i))

if __name__ == '__main__':
    main()

这份代码在英文歌曲下，基本没有问题，可以比较顺利的跑，但是，中文，又是恶心的编码问题，由于现有的歌曲中，id3v2.3 的编码方式有些是 gbk ，有些是 utf-8，这个就比较麻烦了，不过千千静听有一个批量编辑文件属性的功能，可以在那里面，把所有文件的编码方式统一，可惜的是，这个 py 库到目前我发现他只支持 utf-8，对于 gbk 会乱码，于是我现在对于中文歌曲的处理方法是，全部拖进千千静听，转成 id3v2.3 的 utf-8，然后用这份代码去跑，跑完了，事实上图片已经钱嵌进去了，但是在 windows 的资源管理器中看不到，在 itunes 中可以，在 airplay 中也可以，但是如果这个时候再用千千静听把所有的编码都转换回 gbk，就会丢失了专辑封面，这个就很麻烦，目前就卡在这里

接下来的话，最理想的情况当然是研究清楚这个 py 库，然后让他可以处理 gbk 的标签，然后用千千静听把所有的标签转成 gbk，再用这份代码去下载封面，这样就你好我好大家好了

历史评论

Python eyeD3 库的乱码问题初步 | ZRJ (2012-12-07 13:04:26):

[…] 文章导航 ← 上一篇 […]

Taglib 读取中文 ID3 标签时乱码

Wed, 29 Aug 2012 23:41:44 +0800

在读取中文的标签的时候，有时候会出现乱码的问题，一开始以为是文件中内嵌标签本来就有编码问题，类似 gbk 和 utf8 那样，后来折腾着发现貌似是类库本身的问题，同样的问题在这里也有人提到，http://blog.sina.com.cn/s/blog_69dcb20701014pmj.html

不过，似乎TagLib-Sharp对utf8编码的中文不是非常的兼容，读取的时候很容易出现乱码，对于中文字符串的处理似乎需要而外的解码处理，需要在日后查阅资料来解决这个问题，郁闷纠结中。。。

也是，毕竟是外国友人写的，对 cjk 这类的字符自然没有顾虑那么周全，于是 google 搜，看到这里，http://gphone.tgbus.com/jc/syjc/200812/172339.shtml，有一个好软件叫做 convertz ，下载回来，重新编码了一下文件之后，果然能够争取读取了。

历史评论

根据 ID3 自动补充专辑封面和歌词 | ZRJ (2012-08-30 10:17:37):

[…] 文章导航 ← 上一篇 […]

浏览器对编码的确定

Mon, 16 Jul 2012 21:50:30 +0800

我们知道，在一次 HTTP 请求中，浏览器向 HTTP 服务器发起 HTTP request，然后服务器返回 response header，到目前为止，字符的编码都是 ANCII 的，所以都还好，不需要考虑什么解码问题，但是服务器紧跟着传回来的 response body 本质上就是一个字节流了，于是自然而然的就面临一个解码的问题，怎么处理这个问题是我一直以来疑惑已久的。

对于这个问题，如果服务器比较规范，那么应该在 response header 中指明 charset ，这种情况当然是最好的，浏览器直接就可以按照给定的 charset 去解码正文，但是如果没有给出呢？很自然的会想到，HTML 正文里面，是有一个 meta 标签的，在那个 meta 标签中，我们可以指明 charset ，但是，我一直想不通的问题就在这里了：既然正文本身的编码方式就是未知的，而指明编码方式的 meta 又位于正文中，所以这不是一个自我循环的无解问题吗？

在这之前，我记得我曾经在网络上看到一些文章说，这种时候，对于 meta 标签的位置就很重要了，一定要写在 title 之前，给出的原因是说，title 中可能含有非 ANCII 字符，所以如果 meta 在 title 之前的话，就可以让浏览器顺利把 meta 找到并看懂，而如果 meta 在 title 之后，那么 title 中的多字节文本就可能影响了 meta 的被发现。这种轮调，甚至知道今天，（刚刚我搜了一下），还十分流行，见这里，http://touya.iteye.com/blog/265949，还有这里，http://www.jb51.net/article/16138.htm，不可否认，他们的这个思路确实有一定的道理，甚至有人还做了十分详尽的对比测试，例如这里，http://epie.blogbus.com/logs/23927589.html，但是，我依然不理解，我的疑惑是，如果说把 meta 放在 title 之前可以解决问题，那么应该是建立在那个编码是 ANCII 兼容的基础上的，也就是说，需要是 ANCII 的超集，例如变长的 UTF-8 ，如果遇到定长的非兼容编码，不是一样不行吗，例如 16 位定长的 Unicode ，虽然我也自己动手试过，例如这段代码：

<html>
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=utf-16">
		<title>中文</title>
	</head>
	<body>
		<p>中文</p>
	</body>
</html>

把这段代码以 16 位定长 Unicode 保存再浏览，虽然是可以正常解码，但是按照我的理解，应该是不行的啊。

直到今天，才看到一篇博文，介绍的是 Gecko 的解码方案，终于解决了这个疑惑，原来，渲染引擎是会对字节流做一定程度的智能判断的，再在这个基础上，决定解码页面使用的解码方式，博文来自百度搜索研发部，很不错的一个博客：

http://stblog.baidu-tech.com/?p=1909

这篇文章讲的十分清楚，我也就不再多言了，强烈建议仔细读一读，最后附上两篇遇到的讲字符编码比较好的文章：

这个，中文编码杂谈，不知道为什么没了，要看 google cache，还有这个，http://www.fmddlmyy.cn/text16.html

历史评论

从点击到呈现 — 详解一次HTTP请求（4） | ZRJ (2012-10-11 22:11:58):

[…] 当浏览得到一个正确的 200 响应之后，接下来面临的一个问题就是多国语言的编码解析了，响应头是一个 ascii 的标准字符集的文本，这个还好办，但是响应的正文本质上就是一个字节流，对于这一坨字节流，浏览器要怎么去处理呢，首先浏览器会去看响应头里面指定的 encoding 域，如果有了这个东西，那么就按照指定的 encoding 去解析字符，如果没有的话，那么浏览器会使用一些比较智能的方式，去猜测和判断这一坨字节流应该使用什么字符集去解码。相关的笔记可以看这里，浏览器对编码的确定 […]