昨晚微信群里的朋友发来 Utopian.io 提示大家移除对utopian.app以及其它app授权并建议修改密码的通知。然后知道了不少添加了utopian.app授权的用户账户被用来差评 haejin 的帖子以及随机(?)点赞一些帖子。

(图源 ：pixabay)

Utopian.io 被黑

今早 @utopian-io 发了个帖子 Utopian.io Hack - May 3rd - May 4th 2018. No Wallets Or Keys Compromised.说明了这个事件。大致是Utopian.io系统漏洞被发现，然后先是导致Utopian.io服务终止，然后黑客删掉了Utopian.io主服务器的数据，删掉了Utopian.io CDN的数据。

服务中止和数据被删其实对用户影响并不大，但是接下来的事情就严重了，Utopian.io数据库中保存的SteemConnect Tokens被黑客拿到，黑客利用Tokens差评haejin的帖子以及点赞一些其它的帖子。所以如果你是 Utopian.io 用户，在 https://steemd.com/@yourid 上浏览你近期操作，你可能会发现类似如下记录：

Utopian.io 的用户有不少是steem上的知名用户，还好这个黑客不太过分，如果他再利用用户账户发一些钓鱼的帖子或者回复，那么后果将难以想象。

授权机制

@utopian-io的 帖子中说到，用户钱包以及私钥不会受此次被黑事件的影响。这是因为无论是Utopian.io还是SteemConnect 都不存储用户私钥的，而是通过steem的授权体系实现用户对app的授权。

以上边这个我随便找出的用户为例，用户在Posting处添加了utopian.app以及其它app的授权，这些app就可以用自己的私钥以用户的名义去做Posting相关的事情（发帖、回复、点赞、差评等等）

实际上这些app再次授权给 @steemconnect，最终操作的执行者为 @steemconnect 。昨天事件发生时，我写了个脚本，通过transaction的签名数据来判断对应操作的实际操作者。比如这个差评操作：

其它问题

@utopian-io 的 帖子中提到：

这个应该取决于你选取的授权范围（我不确定这些app站点是否提供转账等授权）

@utopian-io的 帖子中提到：

“you are totally safe to use SteemConnect in the future.” 我觉得这么说是相当不负责任的，没有那个站点可以保证永远不被黑，只能说看黑客的手段是否高明，况且即便没有黑客，内部出问题呢？所以正确的说法应该是： SteemConnect 以及其它app 暂时不受此次事件的影响。

其它的关于所有相关tokens都已经移除，用户不用改密码这些应该是这样的。至少按此次事件情况以及当前披露的信息，对用户的影响（可能用来发帖、点赞、差评等）已经不存在了。

其它的，比如撤除对某人的差评等，大家就自己看着办吧。

移除授权

另外关于如何移除对第三方app的授权，会操作steempy的，可以使用steempy disallow命令来实现。不会操作steempy的可以使用如下链接操作：
https://v2.steemconnect.com/revoke/@utopian.app

如果需要移除其它账户，将@utopian.app 换成对应账户即可。

另外，从这次事件来看，steemconnect 的拥有所有第三方app（通过steemconnect授权）的用户的对应权限，这有点让人😵。这贴就不继续讨论了。

相关链接

• Utopian.io Hack - May 3rd - May 4th 2018. No Wallets Or Keys Compromised.

This page is synchronized from the post: ⚠️ Utopian.io 被黑，你可能关心的一些问题 / 如何移除授权

今天是五月四日，青年节，一个对我而言似乎很久远的节日，中老年人也不好意思庆祝青年节不是嘛。

但是他们青年过节，我们中老年人回忆一下过去，总是可以的。比如我们年轻时候的那些甜蜜的爱情、那些秘密的约会…….于是我又想起了普希金诗选里的一首当年特别喜欢的诗《 题纪念册》

题纪念册全文如下：

爱情会过去，感情会死亡，
冰冷的社会将把我们分离，天各一方；
谁又记得那些秘密的约会，
往日年华的狂喜和幻想?……
只是在记忆的篇页里，
请留下那些短暂相思的字行。

因为太喜欢这个题纪念册了，所以在学生时代，我没少在同学们的纪念册上写这首诗，当然了，我都表明了作者是普希金，剽窃别人作品的事情我是没脸做的。

说到普希金，其实我当年最喜欢的是他的那首《假如 生 活 欺骗了你》，因为是名作，所以当然有好几个译本，以下是查良铮翻译的版本：

假如生活欺骗了你，
不要忧郁，也不要愤慨！
不顺心时暂且克制自己，
相信吧，快乐之日就会到来。

我们的心儿憧憬着未来，
现今总是令人悲哀，
一切都是暂时的，转瞬既逝，
而那逝去的将变为可爱。

这感觉，是不是有点像读汪国真的诗选呢？（不小心又暴露年龄了，哎，也不怕暴露了，反正都说没法过青年节了😭）

说到普希金，不得不提一下普希金之死了。普希金的妻子娜塔丽娅·尼古拉耶夫娜·冈察洛娃是个美女（额，起这么长的名字他们自己能记住吗？）18岁嫁给了普希金。可是有句话咋说的来着好看的皮囊千篇一律，有趣的灵魂万里挑一，说白了，就是大诗人和大美女之间没有共同语言。当然了，要我选，还是选好看的皮囊。

大诗人喜欢诗歌，大美女却喜欢社交，流连于上流社会的各种舞会之间，大美女太美了，甚至的沙皇尼古拉一世都为之倾心。虽然喜欢普希金的妻子娜塔丽娅，但是沙皇要脸，还不好太过。但是后来一位追求者乔治·查理·丹特士就没那么多顾忌了，对娜塔丽娅展开了疯狂的追求，然后诗人就呵呵了。

是可忍孰不可忍，于是普希金最终选择了决斗来解决这件事，结果腹部中枪，两日后不幸身亡。俄国诗歌的太阳这这么委屈地沉落了。再回头看《题纪念册》，爱情真的过去了，感情真的死亡了，甚至诗人自己也早逝了。再回头看《假如生活欺骗了你》，诗人所憧憬的美好未来终究没能到来，忍不住一声叹息！

This page is synchronized from the post: 读书 & 《题纪念册》与《假如生活欺骗了你》

之前用两篇文章复习了字符串编码的相关知识并做了一些验证。但是我们学习知识的目的是为了更好地使用，否则除了占用脑细胞就没啥其它意义了（好像占不到我的脑细胞，因为我会很快地忘掉）。

(图源 ：pixabay)

因为有不同编码的存在，所以在编程解决问题的过程中难免会遇到编码转换的问题。比如说我的程序设置使用Unicode编码，但是程序中读取到一段文字却使用了GB2312编码，然后我们要将这段文字POST给某个网页处理，这时候又要使用UTF-8编码，这真是让人头晕甚至头大的问题。

幸好，微软给我们提供了很多函数，让我们可以很方便的处理诸如此类的转换。最常见的函数莫过于WideCharToMultiByte以及MultiByteToWideChar两个函数，前者将宽字节字符串转换成多字节字符串，后者做相反的工作。

WideCharToMultiByte

以WideCharToMultiByte为例，它的语法（函数声明）如下：

咔咔，是不是头更大了？其实也没多复杂，有关参数的说明，参考此处即可.aspx)（良心呢？良心疼不疼？）

但是有一个要注意的问题，_Out_opt_ LPSTR lpMultiByteStr,这个参数用于接收转后的字符串，但是很多时候我们很难预估转换后的字符串会占用多少字节，这时候定义一个固定长的buf，或者使用内存分配函数分配固定长度的内存空间，都是不适当的。

一般的做法是先调用一遍WideCharToMultiByte这函数，但是把输出字符的指针以及输出字串的长度分别设置为NULL和0，这样调用会返回目标字串的长度。我们根据这个返回的长度分配内存，然后再次调用转换函数就会得到目标字串。需要注意的使用完目标字串后，要记得释放内存。

MultiByteToWideChar这个函数的用法和需要注意的内容与WideCharToMultiByte大同小异，就不额外介绍了。

CW2A & CA2W

尽管WideCharToMultiByte与MultiByteToWideChar 可以很好地处理不同编码之间的字符串转换，但是用起来还是非常麻烦的。先要调用一遍来测试目标串长度，然后再分配内存，再调用函数进行转换，用完还是记得释放内存，更不用说还有一堆参数要填。

CW2A & CA2W的出现彻底将我们从这些繁重的劳动中解放出来。

你可能很好奇，它是怎么实现的呢？答案是，尽管CW2A & CA2W看起来很简单，实际上它内部去做上述繁复的工作😵。

以上是CW2AEX类的部分代码，可见它也是使用了WideCharToMultiByte这个函数。

另外代码中，AtlConvAllocMemory(&m_psz,nLengthA,m_szBuffer,t_nBufferLength);这个函数很有意思。结合CW2AEX类，大致思路是提供一个字节数组，如果目标字串的长度大于字节数组的长度，那么重新分配内存，否则使用这个字节数组作为接收区。

CW2A & CA2W 作用域

因为在CW2AEX类的析构函数中会释放内存，所以使用CW2A & CA2W 等函数时要注意作用域的问题。假设我们用类似：LPTSTR p = CA2W(str1);来保存结果，那么再次使用p的时候，因为p对应的内存已经被释放，所以可能得到一些垃圾数据或者意想不到的结果。这里就不再赘述了。

参考资料

• WideCharToMultiByte function.aspx)
• MultiByteToWideChar function.aspx)
• Unicode and Character Set Functions.aspx)
• CW2AEX Class
• CA2WEX Class
• 温故而知新：复习一下字符编码(ASCII、GB2312、Unicode、UTF-8、区位码)
• 纸上得来终觉浅：来验证一下编码的问题

This page is synchronized from the post: 每天进步一点点：VC中不同编码间字符串转换

之前往微信公众号上搬刘美女的Steemit Weekly for CNers - Issue 27 / 《社區”週”邊事》 - 第 27 期的时候，随便翻了一下微信公众号的后台，结果发现一些很有意思的数据。

因为这个公众号大部分都是STEEMIT #cn(中文区)朋友在用，所以大致能反映STEEMIT中文区的用户的一些状况。

首先是性别分布，我是比较关心STEEMIT上有多少萌妹子的，还好还好，关注我微信公众号的993个用户中竟然有224个萌妹子，男女比例约为1:3.4。这充分说明玩STEEMIT的妹子还是比较多的，不像其它一些虚拟币都是一些抠脚大汉在玩。不过话说性别未知的3位是咋回事？细思恐极啊。😱

从语言分布上，简体中文用户还是挺多的。所以STEEMIT 中文区大部分用户应该是来自中国大陆喽，当然了港澳台以为海外也可能使用简体中文，但是从语言分布比例大致可以看出用户的分布情况以及语言偏好。英语用户也比较说，说明有很多海外用户在STEEMIT 中文玩耍呢。

人员的省份分布，颜色越深的对应的人员越多，其中排名前十的省份用户分布如下：

城市分布，北上广深遥遥领先，我估计数据和城市发达程度以及人口密度有关，越是发达的城市接受新鲜事物越快，当然，人口密度和基数同样决定了参与人数。

终端分布，看来现在移动设备不是苹果就是安卓了，不过苹果占了近一半的比例还是让我挺惊讶的，看来玩STEEMIT的果粉挺多的，就是不知道有多少用土豪金的呢？😀

是不是一组很有意思的数据？当然了，有很多中文区用户可能还没关注这个公众号，或者关注了又取消掉，所以这组数据仅供参考。顺便再安利一下微信公众号，添加方法如下：

• 方式一：
  进入微信通讯录->点击公众号->点右上角加号->搜索steemit，关注即可。

• 方式二：
  直接扫描以下二维码：
  

This page is synchronized from the post: 从公共号数据看STEEMIT中文区

之前文章读书 & 《贺新郎•别友》提到了《贺新郎•别友》、《与妻书》以及《蝶恋花·答李淑一》，最后一首应该算是悼念亡妻之作。说到悼亡诗，最著名的莫过于“曾经沧海难为水”了。

(图源 ：pixabay)

曾经沧海难为水

“曾经沧海难为水”出自《离思五首》，是其中的第四首，《离思五首》是唐代诗人元稹创作的一组悼亡绝句。其中第四首全文如下：

曾经沧海难为水，除却巫山不是云。
取次花丛懒回顾，半缘修道半缘君。

大意就是看过至大至美的沧海，其它地方的水，就算不得水了。看过至柔至善的巫山之云，其它的云彩都黯然失色了。我在美女从中打滚，却片叶不沾，一半是因为修道，一半就是因为你啊。

其中沧海在古代指东海，比如曹操就曾写下“东临碣石，以观沧海”，当然了，现在一般指大海，这不重要。重要的是巫山之云，这里边是有典故的，咔咔，以下内容少儿不宜：

据说楚怀王在巫山那嘎达溜达，晚上睡觉梦见一美女，自称巫山之女，然后呢，就是做一些爱做的事情啦。神女临走前说自己：“旦为朝云，暮为行雨”。所以此后“巫山神女”常用于形容美女，“巫山云雨”就用来形容色情词汇已被屏蔽啦。哎，人家一春梦都这么文艺。

总之全诗的意思就是你太好了，你走了之后，别的女人我看不上啦。，是不是好痴情，好感人？泪飞顿作倾盆雨啊。

韦丛、崔莺莺 & 薛涛

然而，我们不能被诗人的花言巧语所迷惑，尤其是那些萌妹子们，千万不要上当。为何呢？听我慢慢道来：

元稹的妻子是谁呢？在这之前呢，元稹曾和一朋友的女儿相恋，这个女人也是响当当的人物——崔莺莺。后来元稹赴京应试，巴结上了大官韦夏卿，然后为了攀上高枝，抛弃了才貌双全崔莺莺，娶了韦夏卿之女韦丛。

韦丛如何善良贤惠，如何温柔体贴，如何陪元稹一起过清贫的日子姑且不表，韦丛和元稹在一起之后7年就不幸早逝也暂且不提，我想说的是，元稹后来以自己的初恋崔莺莺为原型，创作了小说《莺莺传》，再后来被王实甫改编成了《西厢记》，这你总该知道崔莺莺是谁了吧？用一句歌词咋唱的来着：难忘的初恋情人。

好吧，后来又扯出来一个大了元稹很多岁的唐代才女薛涛，又演绎出一段经典爱情故事，具体细情就不多表了。只是这时候你还相信他的：取次花丛懒回顾吗？

遣悲怀三首

不过不能否认作者对亡妻的爱情以及思念，除了《离思五首》以外，元稹还曾写下《遣悲怀三首》来悼念亡妻，诚知此恨人人有，贫贱夫妻百事哀以及惟将终夜长开眼，报答平生未展眉都是其中的名句。不得不说写诗的时候还是一片真情的，否则如何能写出这些千古佳句呢？

This page is synchronized from the post: 读书 & 曾经沧海难为水

在之前的文章《温故而知新：复习一下字符编码(ASCII、GB2312、Unicode、UTF-8、区位码)》，我复习了一下字符编码相关的问题。但是理论归理论，总要实践一下才会觉得靠谱一些嘛。

先来秀一下我以前测试汉字库的效果图

其中一个我显示反了😳，真的没有其它含义，我不想造反的。

当初流行愤怒的小鸟，但是我因为计算有误导致字库显示的不正常，不过效果倒是比正常的好看多了呢，我曾戏言是把小鸟关到笼子里。

终于把字显示正常了，哎，好想念婉儿表妹，不知道表妹是否还记得我？

其实从GB2312到区位码再到取字模出来还是比较简单的事情，毕竟就是加加减减乘乘除除的事情。现在很多液晶模块里边都自带字库，给相应的指令去显示即可。不过如果要显示特殊的尺寸规格以及特殊的字体，还是要用到自定义字库的。

扯远了，当初开发单片机程序的时候，因为时常要处理字符编码，所以我写了个超简单的工具给大家查询编码用。这里我用来验证一下之前学习编码那篇文章里涉及的问题。

可见对ASCII字符而言，Unicode（UCS-2）直接在ASCII字节前加上0x00，UTF-8编码出来的字节长度是一个字节和ASCII保持一致。

对于常见汉字（GB2312编码方案范畴内的），Unicode和ASCII方式都占用两个字节，但是两者内容是不同的，并且有不同的叫法，前者叫宽字符（WideChar）后者叫多字节字符（MultiByte）。而UTF-8编码出来占用三个字节，也就是说常见汉字编码成UTF-8反而多占用一个字节。

𐍈一个好特殊的字符，这个字符Unicode（UCS-4）存储占用了四个字节，UTF-8编码出来也是四个字节。因为我系统中设置的Unicode之外的默认编码为GB2312，它支持的范围就是两个字节，所以转换成GB2312多字节字符后会缺失内容。（哦，或者我程序界面上应该用GB2312而不是ASCII更好一些，懒得改了）

𤭢一个好神奇的汉字，据说收录在康熙字典，音义均同“碎”。这个字打破我一直以来都认为汉字Unicode表示只占两个字节的认知。以前听说什么公安局户口录入系统经常遇到敲不出来的汉字，这次我也长见识了。其它方面到和𐍈没啥区别了。

好了，就到这吧，至于什么UTF-16、UTF-32，我就不去学习了，累啊，有了这几把板斧，应该足够我愉快的玩耍了。

相关链接

• 温故而知新：复习一下字符编码(ASCII、GB2312、Unicode、UTF-8、区位码)

This page is synchronized from the post: 纸上得来终觉浅：来验证一下编码的问题