Misc on chai2010 的博客

用ASCII画图

Wed, 15 Nov 2017 00:00:00 +0000

作为一个严肃的码农，用ASCII画图是一门艺术。

MonoDraw - ASCII 画图界的PS

当然，我们并不是要像用小刀刻硬盘那样一个一个字符来画图，在ASCII画图领用也有类似PhotoShop那样的软件，那就是大名鼎鼎的 MonoDraw ！

要注意的是这个软件只有 macOS 版本，而且是收费软件(100+RMB)。

比如我们用 MonoDraw 画一个 iPhone, 然后在窗口显示一个文本:

Ditaa - ASCII 图像打印机

Ditaa 是 Java 写的一个开源小工具，它可以将ASCII码图打印为漂亮的png格式图片。

比如有以下样式的ASCII码图：

渲染后的效果是这样的:

这里是打包好的 Docker 镜像(也有很多例子)： https://github.com/chai2010/ditaa-docker

其它工具

还有很多其它知名度很高小工具，这里只是简单列举几个：

Graphviz: 通过自定义的DOT语言脚本描述图形，然后渲染为图像文件
PlantUML: 通过自定义的脚本语言描述UML图，然后渲染为图像文件
Gnuplot: 一个生成图标的小工具(它和GNU项目没关系)

TIFF6.0格式简介

Mon, 02 Sep 2013 00:00:00 +0000

作者: chai2010 (chaishushan{AT}gmail.com) (整理)

标签图像文件格式(Tagged Image File Format, 简写为TIFF)是一种主要用来存储包括照片和艺术图在内的图像的文件格式. 它最初由Aldus公司与微软公司一起为PostScript打印开发.

TIFF最初的设计目的是为了1980年代中期桌面扫描仪厂商达成一个公用的扫描图像文件格式, 而不是每个厂商使用自己专有的格式. 在刚开始的时候, TIFF只是一个二值图像格式, 因为当时的桌面扫描仪只能处理这种格式. 随着扫描仪的功能愈来愈强大, 并且桌面计算机的磁盘空间越来越大, TIFF逐渐支持灰阶图像和彩色图像.

目前最新的 TIFF6.0规范在1992年公布.

结构概述

TIFF文件以.tif或.tiff为扩展名. 其数据格式是一种3级体系结构, 从高到低依次为: 文件头IFH(Image File Header), 一个或多个称为IFD(Image File Directory)的包含标记指针的目录和数据. 一个文件中可以包含多个IFD, 每个IFD对应一个图像.

图像头(IFH)/图像目录(IFD)/标签入口(IFDEntry)的逻辑结构如下:

+------------------------------------------------------------------------------+
|                           TIFF Structure                                     |
|  IFH                                                                         |
| +------------------+                                                         |
| | II/MM            |                                                         |
| +------------------+                                                         |
| | 42               |      IFD                                                |
| +------------------+    +------------------+                                 |
| | Next IFD Address |--->| IFD Entry Num    |                                 |
| +------------------+    +------------------+                                 |
|                         | IFD Entry 1      |                                 |
|                         +------------------+                                 |
|                         | IFD Entry 2      |                                 |
|                         +------------------+                                 |
|                         |                  |      IFD                        |
|                         +------------------+    +------------------+         |
|     IFD Entry           | Next IFD Address |--->| IFD Entry Num    |         |
|    +---------+           +------------------+   +------------------+         |
|    | Tag     |                                  | IFD Entry 1      |         |
|    +---------+                                  +------------------+         |
|    | Type    |                                  | IFD Entry 2      |         |
|    +---------+                                  +------------------+         |
|    | Count   |                                  |                  |         |
|    +---------+                                  +------------------+         |
|    | Offset  |--->Value                         | Next IFD Address |--->NULL |
|    +---------+                                  +------------------+         |
|                                                                              |
+------------------------------------------------------------------------------+

其中, TIFF中的版本号为42, 包含生命宇宙以及任何事情的终极答案(这也说明了TIFF格式为何这么强大). 文件中的数据指针(offset)最大对应4个字节, 因此一个文件不能超过4GB. 如果需要大于4GB的图像支持, 可以参考基于TIFF的变种格式 BigTiff.

图像基本信息

基本信息为图像的大小, 图像的颜色模型(黑白图像/灰度图像/调色板图像/真彩色等), 每个像素的大小和单位等信息.

每个图像必须包含的标签有(含压缩类型):

ImageWidth 256 SHORT or LONG
ImageLength 257 SHORT or LONG
XResolution 282 RATIONAL
YResolution 283 RATIONAL
ResolutionUnit 128 SHORT 1, 2 or 3
Compression 259 SHORT 1, 2 or 32773

其中颜色模型由几个标签组合判断:

PhotometricInterpretation 262 106 SHORT 0/1/2/3
BitsPerSample 258 SHORT 4 or 8
SamplesPerPixel 277 SHORT default(1)
ColorMap 320 SHORT 3 * (2**BitsPerSample)

色彩模型

TIFF基础部分定义了4种色彩模型(这里不讨论掩码图像和扩展色彩模型), 主要有: 二值图像, 灰度图像, 调色板图像, 真彩色图像.

二值图像

如果没有 BitsPerSample 则为二值图
颜色模型 PhotometricInterpretation 必须为 0(0为白色) 或 1(1为白色)
压缩类型 Compression 1, 2 or 32773, 支持 Huffman 编码

灰度图像

有 BitsPerSample, 且 PhotometricInterpretation 为 0 或 1
压缩类型 Compression 1 or 32773, 不支持 Huffman 编码

调色板图像

PhotometricInterpretation 为 3
必需包含 ColorMap
BitsPerSample 为 4 或 8
Compression 为 1 or 32773, 不支持 Huffman 编码

真彩色图像

PhotometricInterpretation 为 2
必须含 SamplesPerPixel 波段数信息, 值为 3
BitsPerSample 必须为 8,8,8
Compression 为 1 or 32773, 不支持 Huffman 编码

其他模型

TIFF 的扩展特性中还包含 CMYK 和 YCbCr 等其他色彩模型. 详细信息请参考TIFF6.0规范.

条带和分片

其中数据的组织方式有条带和分片两种, 默认为条带方式存储.

条带图像必要的标签有:

RowsPerStrip 278 SHORT or LONG
StripOffsets 273 SHORT or LONG
StripByteCounts 279 SHORT or LONG

其中 RowsPerStrip 缺省值为 2^32-1, 图像将只有1个条带. 如果条带数据不足的话, 末尾并不需要数据填充.

分片图像必要的标签有:

TileWidth 322 SHORT or LONG
TileLength 323 SHORT or LONG
TileOffsets 324 SHORT or LONG
TileByteCounts 325 SHORT or LONG

每个片的大小必须是16的倍数, 每个片的长和宽可以不同. 如果片数据不足的话, 需要填充(填充数据没有要求).

位平面

位平面由 PlanarConfiguration 标签确定, 缺省时为1表示按像素组织(比如RGBRGB). 当 PlanarConfiguration 为2时, 为按通道存储(比如RRGGBB).

当只有1个通道时(SamplesPerPixel), 位平面信息可以忽略.

压缩方式

压缩方式由 Compression 标签确定.

基本算法:

1 = No compression
2 = CCITT modified Huffman RLE
32773 = PackBits compression, aka Macintosh RLE

扩展特性:

3 = CCITT Group 3 fax encoding
4 = CCITT Group 4 fax encoding
5 = LZW
6 = JPEG ('old-style' JPEG, later overriden in Technote2)
7 = JPEG ('new-style' JPEG)
8 = Deflate ('Adobe-style')

常见标签

ImageDescription 270 ASCII

CellLength 265 SHORT
CellWidth 264 SHORT

Software 305 ASCII
DateTime 306 ASCII
Artist 315 ASCII
HostComputer 316 ASCII

Copyright 33432 ASCII

空闲空间

当创建或更新TIFF文件时, 文件中会有一些空闲的空间(类似malloc/free导致的内存碎片). TIFF规范中有 FreeByteCounts 和 FreeOffsets 两个标签用于记录文件中的空闲空间.

但是由于不同标签之间的弱引用关系, FreeByteCounts 和 FreeOffsets 记录的信息可能并不可靠. 因此, 并不能完全依赖这个信息.

忽略特性

文件中含多个图像(多IFD)
扩展的压缩算法
扩展的色彩模型
多通道数大于4

文件实例

这是一个二值图像的片段(来自TIFF6.0规范文档):

Header:
0000 Byte Order                  4D4D
0002 42                          002A
0004 1st IFD offset              00000014

IFD:
0014 Number of Directory Entries 000C
0016 NewSubfileType              00FE 0004 00000001 00000000
0022 ImageWidth                  0100 0004 00000001 000007D0
002E ImageLength                 0101 0004 00000001 00000BB8
003A Compression                 0103 0003 00000001 8005 0000
0046 PhotometricInterpretation   0106 0003 00000001 0001 0000
0052 StripOffsets                0111 0004 000000BC 000000B6
005E RowsPerStrip                0116 0004 00000001 00000010
006A StripByteCounts             0117 0003 000000BC 000003A6
0076 XResolution                 011A 0005 00000001 00000696
0082 YResolution                 011B 0005 00000001 0000069E
008E Software                    0131 0002 0000000E 000006A6
009A DateTime                    0132 0002 00000014 000006B6
00A6 Next IFD offset             00000000

Values longer than 4 bytes:
00B6 StripOffsets                Offset0, Offset1, ... Offset187
03A6 StripByteCounts             Count0, Count1, ... Count187
0696 XResolution                 0000012C 00000001
069E YResolution                 0000012C 00000001
06A6 Software                    “PageMaker 4.0”
06B6 DateTime                    “1988:02:18 13:59:59”

Image Data:
00000700                         Compressed data for strip 10
xxxxxxxx                         Compressed data for strip 179
xxxxxxxx                         Compressed data for strip 53
xxxxxxxx                         Compressed data for strip 160

参考信息

ASCII码中大小写字母转换

Mon, 06 May 2013 00:00:00 +0000

ASCII中消息字母比大写字母大32, 比如: ‘a’对应97, ‘A’对应65(97-32=65).

ASCII中大小写字母都是排列有序的, 一般在转换大小写字母时都会基于这个特性.

下边是中转换函数的一种实现:

int tolower(int c) {return ( c -'A'+'a');}
int toupper(int c) {return ( c -'a'+'A');}

其实'a'-'A'对应的32刚好是2的幂, 二进制表示为: 00010 0000. ASCII中大小写字母转换只是将32的二进制中唯一的bit为1的数置0或置1. 置0对应减32转换为大写字母, 置1对应加32转换为小写字母.

我们可以用位运算重新实现上面的函数:

int tolower(int c) {return (c ^ 32);}
int toupper(int c) {return (c ^ 32);}

继续观察可以发现32刚好对应ASCII中的空格’ ‘, 因此代码调整为:

int tolower(int c) {return (c ^ ' ');}
int toupper(int c) {return (c ^ ' ');}

在转换单个字母时这样就可以了: c ^= ' '.

VC2010下Qt5的中文乱码问题

Thu, 04 Apr 2013 00:00:00 +0000

要搞清楚这个问题，先要弄明白编码。但是编码问题实在太复杂，这里肯定讲不开。

我先找一个例子，比如：”中文” 的 Unicode 码点/UTF8编码/GBK 分别是多少。

先去这个网站，输入 “中文” 查询对应的 Unicode 码点/UTF8编码：

http://www.mytju.com/classcode/tools/encode_utf8.asp

Unicode的码点分别是(十进制)：中(20013)，文(25991)。对应的UTF8编码分别(16进制): 中(E4B8AD)，文(E69687)。

然后再去下面这个网站，输入 “中文” 查询对应的 GBK 编码： http://www.mytju.com/classcode/tools/encode_gb2312.asp

GBK编码16进制(GBK内码)分别是：中(D6D0)，文(CEC4)。

现在已经知道了”中文”的UTF8和GBK编码的具体值。我们再看看VC2010是怎么处理的。

1. 先看无 BOM 的 UTF8 编码的代码 (utf8_no_bom.cpp)

// utf8 no bom
// 文件中包含不能在当前代码页（936）中表示的字符
#include <stdio.h>

int main() {
    const char* str = "中文";
    for(int i = 0; i < sizeof(str); ++i) {
        printf("0x%x ", str[i]&0xFF);
    }
    return 0;
    // Output:
    // 0xe4 0xb8 0xad 0xe6
}

输出是：0xe4 0xb8 0xad 0xe6。感觉好像是对的。

但是，先别急：VC编译时输出了一条警告信息： utf8_no_bom.cpp : warning C4819: 该文件包含不能在当前代码页(936)中表示的字符。请将该文件保存为 Unicode 格式以防止数据丢失。

潜台词就是，你这个代码有GBK不能表示的字符，请用Unicode方式保存。 VC根本就没把代码(utf8_no_bom.cpp) 当作UTF8，VC只是把它作为GBK处理罢了。

那为什么又输出了正确的结果呢？

因为 VC 把 (utf8_no_bom.cpp) 当作 GBK，而编译时也要转换为本地编码(也是GBK)。因此，UTF8编码的 “中文”，被VC当作编码为 “0xe4 0xb8 0xad 0xe6” 的其他中文处理了。 VC已经不知道 “0xe4 0xb8 0xad 0xe6” 是对应 “中文” 字面值了。

但是在GBK(实际是无BOM的UTF8)转GBK的过程中，发现了一些UTF8编码的字符并不是 GBK能表达的合理方式，因此就出现了那个C4819编译警告。

2. 再看带BOM的UTF8是怎么处理的 (utf8_with_bom.cpp)

// utf8 with bom
#include <stdio.h>

int main() {
    const char* str = "中文";
    for(int i = 0; i < sizeof(str); ++i) {
        printf("0x%x ", str[i]&0xFF);
    }
    return 0;
    // Output:
    // 0xd6 0xd0 0xce 0xc4
}

编译没有警告，但是输出有问题：0xd6 0xd0 0xce 0xc4。

源文件明明是 UTF8 编码的格式”0xe4 0xb8 0xad 0xe6”，怎么变成了 “0xd6 0xd0 0xce 0xc4” (这个是GBK编码)？

这就是VC私下干的好事：它自作聪明的将UTF8源代码转换为GBK处理了！

VC为何要做这样蠢事？

原因是为了兼容老的VC版本。因为以前的VC不能处理UTF8，都是用本地编码处理的。

3. 在看看真的GBK是怎么处理的 (gbk.cpp)

// gbk
#include <stdio.h>

int main() {
    const char* str = "中文";
    for(int i = 0; i < sizeof(str); ++i) {
        printf("0x%x ", str[i]&0xFF);
    }
    return 0;
    // Output:
    // 0xd6 0xd0 0xce 0xc4
}

没有编译错误，输出也和源代码一致：”0xd6 0xd0 0xce 0xc4”。

因为源文件就是GBK，cl在编译时GBK转化为GBK，没有改变字符串。

只是，现在很多人不想用GBK了（因为只能在中国地区用，不能表示全球字符）。

到这里，可以初步小结一下：

VC编辑器和VC编译器是2个概念，VC编辑器支持UTF8并不能表示VC编译器也支持UTF8
VC编辑器从2008?开始支持带BOM的UTF8(不带BOM的暂时没戏，因为会本地编码冲突)
VC编译器从2010开始重要可以支持UTF8了(虽然支持方式很不优雅)

4. 看看VC2010是怎么处理带BOM的UTF8的 (utf8_with_bom_2010.cpp)

VC2010重要增加了UTF8的编译支持(#pragma execution_character_set("utf-8")), 具体查看:

http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/2f328917-4e99-40be-adfa-35cc17c9cdec

// utf8 with bom (VC2010), 这句是重点！
#pragma execution_character_set("utf-8")

#include <stdio.h>

int main() {
    const char* str = "中文";
    for(int i = 0; i < sizeof(str); ++i) {
        printf("0x%x ", str[i]&0xFF);
    }
    return 0;
    // Output:
    // 0xe4 0xb8 0xad 0xe6
}

没有编译错误，输出也和源代码一致：”0xe4 0xb8 0xad 0xe6”。

UTF8编码，UTF8输出。完美!

回到 Qt5 的中文输出问题。

Qt默认支持 VS2010/MinGW/Gcc 等编译器，而它们现在都已经真正支持UTF8了。

当然，VS2010 对UTF8的支持会入侵代码(#pragma execution_character_set("utf-8"))。

看看Qt官方论坛别人是怎么说的： http://qt-project.org/forums/viewthread/17617

Nothing special need to do, it will works by default. If the exec-charset of your your compiler is UTF-8.

简单的说，从Qt5开始，源代码就是默认UTF8编码的。

当然，VC2010编辑器对带BOM的UTF8也是认识，只可惜VC2010编译器根本承认它是UTF8！

在继续看官方论坛的回复：

You can write a simple example like this

  #include <QApplication>
  #include <QLabel>

  #if _MSC_VER >= 1600
  #pragma execution_character_set("utf-8")
  #endif

  int main(int argc, char *argv[])
  {
      QApplication a(argc, argv);
      QLabel label("ąśćółęńżź");
      label.show();

      return a.exec();
  }

If other people can reproduce your problem, you can file a bug.

教完整的解决方案(增加了Qt4/Qt5和非VC环境的判断):

// Coding: UTF-8(BOM)
#if defined(_MSC_VER) && (_MSC_VER >= 1600)
# pragma execution_character_set("utf-8")
#endif

#include <QApplication>
#include <QTextCodec>
#include <QLabel>

int main(int argc, char* argv[])
{
    QApplication app(argc, argv);

#if QT_VERSION < QT_VERSION_CHECK(5,0,0)
#if defined(_MSC_VER) && (_MSC_VER < 1600)
    QTextCodec::setCodecForTr(QTextCodec::codecForName("GB18030-0"));
#else
    QTextCodec::setCodecForTr(QTextCodec::codecForName("UTF-8"));
#endif
#endif

    QLabel *label = new QLabel(QObject::tr("你好！"));
    label->show();

    return app.exec();
}

有以下几种类型(源代码必须是带BOM的UTF8):

Qt5+/VC2010+: 包含了 # pragma execution_character_set("utf-8") 已经支持中文
Qt5/VC2008-: 这个暂时误解(我还没找到方法)
Qt4+/VC2008-: 采用以前老的方式, 指定代码为 “GB18030-0” 编码
Qt4/Qt5/Linux: 只要是默认的UTF8环境, 应该都没问题

其实这个问题不是Qt特有的, 追根溯源还是C/C++和编译器的问题.

即使是支持UTF16的Java也同样难逃此问题.

不过还好, Go语言算是彻底了解决了这个问题. 以后转向 Go语言了 !

PwdGen - 用Go语言实现的密码生成工具

Wed, 27 Mar 2013 00:00:00 +0000

针对CSDN等各大网站私自保存密码的问题, 尝试用Go语言写了个密码生成工具.

pwdgen 是 password generator 的缩写, 支持生成KeePass格式.

下面是生成算法和实现的代码:

// base58(sha512(md5hex(encrypt_key+encrypt_salt)+site_id+site_salt)[0:16]
func pwdgen(site_id, site_salt, encrypt_key, encrypt_salt string) string {
    md5 := md5.New()
    md5.Write([]byte(encrypt_key + encrypt_salt))
    md5Hex := fmt.Sprintf("%x", md5.Sum(nil))

    sha := sha512.New()
    sha.Write([]byte(md5Hex + site_id + site_salt))
    shaSum := sha.Sum(nil)

    pwd := base58.EncodeBase58(shaSum)[0:16]
    return string(pwd)
}

完整的程序请访问: https://bitbucket.org/chai2010/pwdgen/wiki/Home

在线文档请访问: