小熏的编程日记

3月5日利用青春18车票沿东海道线前往名古屋，3月6日返回东京。本科时代的同鞋中，在日本工作学习的含余共3人（其实算不算不少了呢）。在名古屋的是班长，毕业后立刻来了日本，都已经买车了，现在丰田工作。三年多没见过面，去探访一下他。

乘坐电车从东京到名古屋，同事说日本人都不会这样做，余虽然一来是为了省钱，但也为了体验一下。车程6个小时，去时换乘4次，回来少一次，但基本不会站着，只是真的坐到屁股疼。刚开始时很兴奋，但很快就开始发困，回程时更是觉得劳累。

富士山

不过要在电车上拍一张较好的照片，不是那么容易呢，要避开电线、屋顶

手机拍的这张还勉强

到达名古屋。受姬玩得太狠，打了电话说是在樱通出口然后没电了，同鞋找余找了一个小时，原来他一直在lobby找，余则在改札处不敢动（掩面，下次再也不能这样了）。坐上同鞋的车

去到名古屋城已经关门了

名古屋市内也没啥地方好去的，于是在名古屋城绕了一圈

有鸭子（鸭子！

天守阁

阅读全文…

今天和同事去伊豆半島（いずはんとう）旅行。说到伊豆，不得不提起的是川端康成的《伊豆的舞女》，估计很多人知道伊豆这个名字也是因为这部小说，但余实在还没拜读过。从东京出发的旅行电车还有踊り子号（舞女号），可以直到最南端的下田。

但余利用的是青春十八的最后两次机会。
东海道线到热海之后沿伊東（いとう）線接续伊豆急行線到伊豆高原（いずこうげん）。早上下着小雨，下午时天放晴。只在伊豆半岛的东边活动，没有去西边。

先在伊豆高原赏完三公里长的桜並木（さくらなみき）。然后坐巴士到海洋公园，沿着城ケ崎海岸（じょがさきかいがん）的小路一直步行到富戸（ふと），坐电车回到伊东泡温泉最后返回东京。来日本后玩得最尽兴的一次。

因为电力供应不足的缘故，伊豆急行线只有2/3程度的车次，要等半个小时才有一趟车。在伊东等前往伊豆高原的电车时，在周围溜达了一下。

见到一只三色猫。这个猫非常怕生人，一走近她便会躲起来。据主人介绍，这只猫是被扔掉的7只小猫中唯一幸存下来的，当时这群猫被遗弃在店的门前，似乎是被喂了毒馒头，已经奄奄一息。这只猫因此心理受到创伤，自此不再相信人类。日本有见到三色公猫表示运气真好的说法（见到三只黑猫代表厄运），因为三色公猫非常罕见。略微可惜，这只三色猫是母的

伊东这边的海岸基本没有沙滩，这个勉强算沙滩了，但砂子是很罕见的黑色

开始在伊豆高原的三公里长的樱花道赏樱花。下着小雨，很影响拍照

路上遇到一个橱窗，很可爱的兔偶

看完樱花返回伊豆高原站一点多，本想沿步行道一直沿着海岸到富户，但仔细看看地图，距离实在太恐怖，于是折回伊豆高原坐公交到海洋公园，以节省一半的路程

等车的时候玩微距

阅读全文…

以前很讨厌Oracle数据库，做DML（insert/update/delete）操作还要commit，但深入理解Oracle数据库的锁机制后，才认识到Oracle数据库的优秀和commit/rollback的合理性。Oracle数据库对并发操作的支持做得非常好，但如果不合理利用，后果同样很严重。

Oracle数据库的锁粒度上分为表级锁和行级锁，但实际上通常考虑行级锁就可以了。表级锁应用在建立表，修改表结构，建立索引，删除表等操作上，这是重大操作，一般的后台不会提供这样的权限。因此本文只谈行级锁。

行级锁仅有一个锁类型，就是TX锁。TX锁的T代表transaction，表面上一个TX锁对应一条记录，但实际上整个DML操作无论做多少遍，只要没commit，加在记录上的TX锁状态就不会改变。X代表排斥（exclusive），表级锁X不允许没持有权限的session（会话）进行任何相关表（包括表中记录）的读和写操作，但TX锁允许没持有权限的session读取记录，这涉及到Oracle副本机制，实际上session读取到的是原始记录，而非副本中的修改记录。

TX锁权限的获得方法有：
1.DML操作（insert/update/delete）
2.使用SQL语句：select *** from TableName (where ***) for update nowait;
不要小看第二种方法。

session释放当前持有的全部TX锁权限的方法有：commit和rollback。commit是合并副本到本体，rollback是抛弃副本。

启动两个Oracle SQL Plus窗口，这将是两个不同的session，可以用来模拟两个客户的行为。用这两个窗口做下面的实验，将会得出一些重要的认识。

Oracle数据库的副本机制
1.表的操作create/drop不会产生副本，倘若操作成功，作用是立刻反映到本体上。因此create和drop操作事实上无需补上commit
session甲：
create table test(
id number(5) primary key,
value NVARCHAR2(10));
session乙：select * from test;
session乙没有错误产生。

session甲：drop table test;
session乙：select * from test;
session乙将发生错误。

重新在session甲创建test表，继续下面的实验。

Oracle数据库的sequence
Oracle中的主键不会自动递增，需要手动创建sequence，插入新记录时使用sequence的nextval
2.sequence和事务无关，不需要锁。
session甲：create sequence test_seq increment by 1 start with 1 maxvalue 99999;
session甲：commit;
session甲：insert into test values(test_seq.nextval, 'test');
session甲：select * from test;
ID VALUE
---------- --------------------
1 test
session乙：insert into test values(test_seq.nextval, 'test2');
session乙：select * from test;
ID VALUE
---------- --------------------
2 test2
session甲和session乙都commit后，select * from test的结果是
ID VALUE
---------- --------------------
1 test
2 test2

Oracle数据库的TX锁机制和副本机制
3.Oracle数据库的记录差异会保存到副本中（借用一下网游的名词），每个session对记录的修改都会产生各自的副本，只有在commit后，副本才会合并到本体中。
session乙：delete from test where id=2;
session乙：select * from test;
ID VALUE
---------- --------------------
1 test
session甲：select * from test;
ID VALUE
---------- --------------------
1 test
2 test2
session乙：commit;
session甲：select * from test;
ID VALUE
---------- --------------------
1 test

4.仅有差异化会保存到副本，也即只有持有TX权限的记录的修改结果会保存到副本。一个session commit后，差异化合并到本体，另外的session的select仍然会发生变化，也即session对记录的select是同时根据本体和当前持有的副本。
session乙：insert into test values(test_seq.nextval, 'test3');
session甲：update test set value='test111' where id=1;
session乙：select * from test;
ID VALUE
---------- --------------------
1 test
3 test3
session甲：commit;
session乙：select * from test;
ID VALUE
---------- --------------------
1 test111
3 test3
session甲：insert into test values(test_seq.nextval, 'test4');
session甲：commit;
session乙：select * from test;
ID VALUE
---------- --------------------
1 test111
3 test3
4 test4
session甲：select * from test;
ID VALUE
---------- --------------------
1 test111
4 test4
session乙：commit;
session甲：select * from test;
ID VALUE
---------- --------------------
1 test111
3 test3
4 test4

5.一个记录的TX权限被session乙取得后，session甲对这个记录的DML操作会进入等待状态，直到TX锁被释放，session甲才能获得这个记录的TX权限，这是Oracle数据库解决操作冲突的机制。
session乙：update test set value='test1' where id=1;
session甲：update test set value='test1111' where id=1;
session甲会进入等待状态
session乙：commit;
session甲会执行SQL语句（同时获得了TX锁权限）
session甲：commit;
session乙：delete from test where id=1;
session甲：update test set value='test' where id=1;
session甲会进入等待状态
session乙：commit;
session甲会执行SQL语句，但要修改的记录已经不存在，所以影响了0条记录
session甲：commit; （是否执行commit已经没所谓，但在商业程序中，在DML操作后一定要commit，不管是否记录数为0，DML操作如果失败，则执行rollback）

6.第5条中的DML操作包括insert，对存在primary key insert具有相同key值的记录，同样会产生TX权限冲突。
session乙：insert into test values(0, 'test0');
session甲：insert into test values(0, 'test000');
session甲会进入等待状态
session乙：commit;
session甲会执行SQL语句，但产生了错误
session甲：rollback;

7.程序设计不合理将会产生死锁
下面的操作请谨慎进行，余不负责解决导致的后果
session甲：update test set value='test33' where id=3;
session乙：update test set value='test44' where id=4;
session甲：update test set value='test444' where id=4;
session乙：update test set value='test333' where id=3;
因为都没执行commit，session甲和session乙都将进入等待对方释放锁权限的状态，是为死锁
终止这两个session都不能释放id=3和id=4这两条记录的锁状态，因为锁状态是保存在Oracle数据库的数据表中（请搜索Google大神解决也同时学习一下）

合理使用Oracle数据库的锁权限，解决锁冲突
因为DML操作是自动获得TX权限，很多人会被这表面蒙蔽，从而写程序时不留意导致死锁。
如何合理解决锁冲突？

8.不能滥用高等级锁
TX锁的粒度是单条记录，是粒度很细的锁，倘若如果觉得解决锁冲突很麻烦而使用高等级的锁，如表级锁X（X是完全排斥的锁，不允许没持有权限的session做任何操作），死锁是没有了，但这是滥用。越高级的锁，所影响的范围越大，虽然拿使用X来做比喻，但使用X是极端的行为，普通的后台管理严禁使用X锁，后台管理之间的完全排斥不说，前台比如一个购物系统，顾客就不能购买任何东西。

9.那是否应该在一条DML操作后立刻进行commit？
这还是不值得推荐的做法。因为DML/commit操作会在数据库服务器产生和注销副本，商业系统面临的并发数不是小数目，频繁产生和注销副本会加重服务器负担。

10.将DML操作缓存在本地程序内存中是一个很好的做法，批量执行之后才commit，可以节省服务器开销。

11.但缓存方法的执行时间间隔就算再小，如果并发度很高，还是有死锁的危险。因此后台管理程序应该提供终止长时间没响应的锁的功能。

12.如何在缓存方法的基础上彻底泯灭死锁的危险？答案就是使用select for update nowait;
for update nowait仅对select操作有效，DML无法使用for update nowait。虽然DML操作会自动申请TX锁，但倘若锁已经被别人获得，DML操作会进行等待状态，这是死锁的根源所在。在DML操作前，首先使用select *** from TableName (where ***) for update nowait申请TX权限，如果申请失败，会返回异常，不会进入等待状态，只要select语句中的where条件子句和DML的条件子句一样，就能保证所影响的记录范围不会扩大。使用try…catch…语句捕捉异常，可以确保事务执行的正确性。事实上select for update nowait如果成功，已经为session建立了相关记录的副本，这对服务器的开销影响不大，因为DML最终还是要使用副本中的这些记录。
注意：insert操作倘若可能造成冲突，比如第6条，在操作前也应当使用select for update nowait（session甲就不会进入等待状态），倘若没有冲突危险，比如使用sequence.nextval作为primary key的值，不需要在操作前select for update nowait。

最后请思考一下下面的问题（深入理解select for update nowait)：
session甲：select * from test where id=4 for update nowait;
session乙：update test set value='test44' where id=4;
session乙仍然会进入等待状态。为什么？

後楽園的樱花开得比较早，东京的樱花普遍要晚一周

后乐园的枝垂樱，但从花瓣构成来看这个品种应该接近染井吉野

近观

远观

后乐园的樱花其实不是很多，这应该还是染井吉野

染井吉野樱盛开时，刚开始是粉红色，然后越来越白，到极盛时全白，风过处花瓣飞舞，正所谓樱吹雪
染井吉野虽然花的构造简单，但胜在规模，别的樱花品种是没有开得这么疯狂的

7分咲く，远观一片绯红，还是挺好看的

这不知啥品种了

好像是一种水仙

那天接着去了皇居外苑

大手町高楼林立，包围着皇居

二重桥

樱田门

きっぷ（切符），票的意思

日本真是一个什么都来“放題”的国家，飲み放題、食べ放題，还有乗り放題，这青春１８きっぷ就是24小时内任意乘坐JR（全国范围）普通列车的车票，共可使用5次，或5人同时使用，11500日元。每次的车费仅相当于2300日元。

东京坐到藤泽的普通车票要900多，坐到热海估计就要两千多了，坐到名古屋居然要6000多，相比起来青春１８非常实惠了。
和同事聊起的时候，都基本在当学生时利用过青春１８来周游日本。一是没钱，二是时间多。
同事还说起一个蹭特急（非新干线）列车的窍门，特急列车都是需要买指定席票（车上会查票），但仍然和普通列车停靠同样的站台，上车后就躲进厕所，停靠下一站时下来，就可以躲避查票XD（事实上在过青森海峡时，因为不开行普通列车，这一区间持青春１８是允许坐特急的，这样的区间全日本只有两个）

明天利用它去名古屋，虽然只是坐6个小时，但2300日元比坐巴士的一半还要便宜，物超所值了

材料：白粥，瘦肉，皮蛋（这不是废话么
如果还要什么的，随便加吧，比如火腿，炸豆腐，蔬菜之类的
注意锅的大小，材料如果太多的话会拌不动的

第一次做的时候材料就放太多了

要点：
1、材料一定要切得很碎，否则会拌不动
2、要时刻用勺子搅拌，否则底部会煮焦
3、材料的加入先后顺序按容易煮熟的难易程度

第二次。这个色泽好诡异，果然还是材料放太多了么，但味道非常好（唔唔～余都可以去开粤菜馆了

炒菜的话……
中国同事的手艺

余的手艺（掩面）（虽然味道还可以啦

今天下午去了横滨，主要逛了下中华街和港未來21(みなとみらい21)，港未來的夜景很有名，但没时间逗留到晚上
有个同事住在横滨，邀请余去玩说了几次，今天却没空。春节（日本叫旧正月）期间横滨有很多节目，但因为没案内，只能作罢
中华街的中国物产价格很坑爹，比新大久保的物产店贵很多

碰上踩高跷的关公（？）出游，接受游人的合影请求哦

关帝庙（里面居然有赛钱箱！）

路上遇到了很多可爱的狗

中华街的小吃很多，这家店的生意特别红火

横滨大世界

内部，灯笼很有气氛

Cotton Bear，卖熊公仔（手工缝制）的店，门口放着等身大的公仔，欢迎合影（唔唔～余也好想上前去抱一抱

天后宫（妈祖庙）

向海边方向走去

回过头来（这才是正门啊

又遇到狗狗，一黑一白，非常可爱

横滨港

海水好干净（天津、珠海不惭愧一下吗

遥望港未來

去港未來的路上回过头来一张

那是横滨的最高楼，横滨地标大厦

一个非常强悍的停车楼，车可以一层层的开上去

摩天轮，港未來的标志物之一

临港公园（臨港パーク），遥望对岸

拉近镜头看风车

拉近镜头看大桥

港未来的街景

去的时候是从东京坐东海道线，之后坐みなとみらい线到中华街
回来的时候直接みなとみらい线+东急东横线到涉谷，车票还便宜一点

不太想闷在家里于是出去走走
昨天下雪，今天下雨，好仆街的天气。明天按天气预报是天晴

结果去浅草寺（せんそうじ）附近转了一圈（在新年初诣的时候同事就已经介绍过了，只不过去了明治神宫）
从银座线浅草站出来，在吾妻桥就看到了建设中的东京天空树，为了拍张好点的照片，又前去溜达溜达

玩了下黑白模式。東武伊勢崎線跨越隅田川（可以到日光，余也要泡温泉呜呜

墨田区役所遥望天空树（東武鉄道出资建造）

这张拍得还勉强

浅草寺（供奉的是观世音），雷门

仲见世通（雷门参道），非常热闹

主殿

五重塔

这鲤鱼太肥了

浅草神社，供奉的是浅草寺的三位创始人，现在和寺庙独立，为不同的财团法人管理

相比浅草寺的热闹，挺冷清的

絵馬（えま），幸运星的高良みゆきOrz

挺诡异的佛像

在浅草寺买的人形焼（にんぎょうやき），很好吃～

名字来由：Uni代表Unicode，Cue为cuesheet，意为将各种编码的cue文件转换到unicode编码
本意是写一个foobar2000的插件实现编码的转换，但最后变成一堆杂七杂八程序的集合

项目开源，放在Github上托管
https://github.com/kuyur/unicue

目前包括的程序有：
Unicue（主要的编码转换工具）
Unicue Traveller（批量转换工具）
ChineseConverter（简繁繁简转换程序）
Traveller Ext（将Traveller注册到右键菜单的系统扩展）
ExtractAkaiito（PS2游戏アカイイト游戏脚本提取，不提供二进制程序，需自行编译）

各转换工具使用到的编码转换通用库（c4-lib）以及制作字符映射表的工程地址为
https://github.com/kuyur/c4

Unicue最新版本为1.4。
程序下载地址：
https://kuyur.github.io/unicue/Unicue_1.4.zip

bug反馈或特性提出可直接在blog回复或前往https://github.com/kuyur/unicue/issues

Unicue Traveller使用注意事项：

• 自动检测得到的编码还不能更改，因此有可能会使用错误的编码进行转换
• 因此不建议覆盖而不备份
• 目前手动更改选中状态还是会被无视
• 卸载Unicue Traveller扩展菜单后，需要杀掉explorer.exe进程并重新启动explorer (或者简单地，重启系统) 才能移动或删除TravellerExt.dll文件

Unicue Traveller使用里・注意事项：

• Vista以上系统请留意权限问题
• ShellExecute中的参数长度有2048个字符的限制，因此一次选中太多的文件夹/文件会使得参数过长从而导致启动Traveller.exe失败
• Windows7以上系统有对选中文件夹/文件的数量限制，最多只会返回16个给扩展菜单
• 由于DragQueryFile的超低效率，xp系统在启动【选中大量文件夹/文件的】右键菜单时会卡住
• 因此不推荐一次选中太多的文件夹/文件
• 这种情况下可以选择在空白处点击右键

更新日志：

Unicue

1.3

• 增加拉丁文字母支持(CP1252)
• 一键转换
• 可调整界面大小
• 记忆最后使用的界面大小
• 修正Linux平台下通过Wine运行时菜单不能正常显示的问题
• 支持Ctrl+A快捷键

1.2

• 允许选择输出编码(UTF-8/UTF-8无BOM/UTF-16LE/UTF-16BE)
• 增强CUE文件的自动修正功能
• 修正Win7以上版本在某种情况下注册到右键菜单却没有生效的Bug
• 修正GBK映射表中欧元符号没有正确转换的Bug
• 使用WTL取代MFC，静态编译解决库依赖问题（传说不需要任何第三方dll）
• 更换新名字 (ANSI2Unicode -> Unicue)
• 多语言界面 （简中，繁中，英，日）
  1. 感谢小海对繁体中文界面提出的修改建议/Thanks for 小海’s suggestions about Traditional Chinese GUI
  2. 感谢lemphek对英文界面提出的修改建议/Thanks for lemphek’s suggestions about English GUI
• 增加西里尔字母支持(CP1251)，涵括斯拉夫语族包括俄语，塞尔维亚语，保加利亚语等一大堆乱七八糟的语言
• Linux平台下通过Wine（1.4.1）能稳定运行（菜单不能正常显示）

1.1

注： 1.1以前版本程序名字为Ansi2Unicode

• 移除自身的转换函数
• 使用c4-lib通用字符转换环境
• 支持用户添加自定义字符映射表并设定转换规则
• 修正图标

1.0.3

• 完整的Unicode支持，不必为文档路径中的特殊字符担心
• 修复Unicode补不完计划造成的丢字问题
  –内建基于UAO 2.50的Big5→Unicode字符映射表
  –Big5→Unicode单向转换，解决没有安装Unicode补完计划的win平台上显示Big5文档时的字符（日文假名/日文汉字/简体汉字）丢失问题
• 转换结果保存为utf-8编码的文本
• 自动检测文本编码
• 支持文件拖放操作及命令行打开文档
• 自动修正cue中的File行音频文件扩展名
• 自动修正cue中的File行旧式“The True Audio”标签为“WAVE”
• 不改变默认打开程序的txt/log/cue右键菜单关联
• 提取tak/flac/ape的内嵌cue，并自动修正cue中的音频文件名
• 转换字符串功能
• 转换字符串模式下，支持拖放乱码文件名进行转换

Unicue Traveller

1.2

• 基于WTL，无需安装任何运行库
• 完整的Unicode支持
• 修复Unicode补不完计划造成的丢字问题
• 转换结果保存为utf-8编码的文本
• 自动检测文本编码
• 自动修正cue中的File行音频文件名
• 自动修正cue中的File行旧式“The True Audio”标签为“WAVE”
• 批量修改文本文件
  1. 任意的文件夹和文件组合的右键菜单
  2. 文件夹的空白菜单
• 可指定文件类型
• 两种保存方式
  1. 覆盖（备份可选）
  2. 另存为（可指定命名模板）

Chinese Converter

1.3

• 保存配置
• 可调整窗口大小并记忆最后使用的窗口尺寸
• 添加菜单
• 添加覆盖文件的保存按钮

1.2

• 支持Unicode LE/BE以及UTF-8格式的文本读取和写入
• 停止使用MFC，转用WTL并静态编译（传说无需任何第三方dll）
• 更换图标
• Linux平台下通过Wine（1.4.1）能稳定运行

1.0

• 简繁繁简转换
• 仅支持Unicode（LE）输入和Unicode（LE）保存转换结果
• 采用维基简繁繁简一对一映射表，如有问题找维基
• 不支持词组转换

开发Unicue的历史缘由

IE转换Unicode补完计划下创建的Big5文本会造成日文假名字符丢失（所有调用win32 api函数MultiByteToWideChar的转换程序都有此问题，原因是Unicode补完计划动用了Big5的自定义造字区，但并非所有人都会去安装Unicode补完计划，在没有安装Unicode补完计划的win平台的CP950中，这些字符是没有定义的）

于是使用自定义的映射表b2u-little-endian.map及自定义的转换函数，绕过CP950以及MultiByteToWideChar

Ansi2Unicode 1.0.3 简明Readme：

选项说明
选项会从配置文件Config.xml读取，如果配置文件不存在或解析错误，会重新生成配置文件

另存文件的命名模板：填写随意，如果留空，则会覆盖原来的文件

自动修正cue文件中的音频扩展名：勾选会依据cue中的音频文件名（不含扩展名）去查找同目录下的音频档案来自动修正cue文件，同时“替换cue文件FILE行的The True Audio为WAVE”会默认生效（无论此选项是否勾选）

提取音频文档(flac/tak/ape)的内嵌cue：勾选后在打开flac/tak/ape文件会提取内嵌cue，否则会视为文本文件打开

注册右键菜单关联：会写如下注册表项

HKEY_CLASSES_ROOT\.uni
@=”UniCue.UNI”

HKEY_CLASSES_ROOT\UniCue.UNI
@=”UniCue 文件”

HKEY_CLASSES_ROOT\UniCue.UNI\shell
@=”Open”

HKEY_CLASSES_ROOT\UniCue.UNI\shell\Open
@=”使用 UniCue 打开”

‘AppPathName为程序路径，如E:\\Program Files (x86)\\UniCue\\Ansi2Unicode.exe
HKEY_CLASSES_ROOT\UniCue.UNI\shell\Open\command
@=”\”AppPathName\” \”%1\””

HKEY_CLASSES_ROOT\UniCue.UNI\shell\unicue
@=”使用 UniCue 转换编码”

HKEY_CLASSES_ROOT\UniCue.UNI\shell\unicue\command
@=”\”AppPathName\” \”%1\””

HKEY_CLASSES_ROOT\txtfile\shell\unicue
@=”使用 UniCue 转换编码”

HKEY_CLASSES_ROOT\txtfile\shell\unicue\command
@=”\”AppPathName\” \”%1\””

‘程序会查找cue文件的注册表信息，假定cue已经关联到foobar2000.CUE
‘如果cue文件类型的信息不存在，会将cue关联到UniCue.UNI
HKEY_CLASSES_ROOT\foobar2000.CUE\shell\unicue
@=”使用 UniCue 转换编码”

HKEY_CLASSES_ROOT\foobar2000.CUE\shell\unicue\command
@=”\”AppPathName\” \”%1\””

HKEY_CLASSES_ROOT\Applications\notepad.exe\shell\unicue
@=”使用 UniCue 转换编码”

HKEY_CLASSES_ROOT\Applications\notepad.exe\shell\unicue\command
@=”\”AppPathName\” \”%1\””

HKEY_CLASSES_ROOT\Applications\ANSI2Unicode.exe\shell\open\command
@=”\”AppPathName\” \”%1\””

‘AppFolder为程序目录，如E:\\Program Files (x86)\\UniCue
HKEY_CLASSES_ROOT\UniCue.UNI\DefaultIcon
@=”AppFolder\\icons\\file.ico”

简单的说，在cue文件已经被关联到某种程序（例如foobar2000）的情况下，会在cue文件的右键菜单添加“使用 UniCue 转换编码”
如果cue文件默认打开方式还不存在，则默认打开方式会变更为ANSI2Unicode.exe
会在txt/log类型的文件（实际上为记事本notepad.exe的关联文件类型）的右键菜单添加“使用 UniCue 转换编码”的选项

卸载右键菜单：还原为原来的状态

新建utf-8编码的文本文件：会更改如下注册表项

删除HKEY_CLASSES_ROOT\.txt\ShellNew下的 NullFile 键值

写键值：（AppFolder为程序所在目录）
HKEY_CLASSES_ROOT\.txt\ShellNew
“FileName”=”AppFolder\\null.uni”

在新建文本文件时会使用utf-8类型的空白模板，编辑此txt文档时直接ctrl+s即可，无需另存为时选择utf-8

还原为默认的新建文本文档：还原为原始状态

转换文件编码的方法
1.启动程序，拖曳文本文件到程序窗体释放
2.启动程序，从菜单打开
3.在注册右键菜单关联后，从右键菜单选择“使用 UniCue 转换编码”
4.命令行窗口：命令行方式（第三方工具可通过此方法传递参数调用Ansi2Unicode）

E:\Program Files (x86)\UniCue>ansi2unicode “F:\downloads\EAC\[EAC][110126]真理絵
_Works_Best_II「Sing_Up！」(wav+cue)\Sing Up.cue”

转换乱码文本或乱码文件名的方法
切换到“转换字符串”模式，拖曳文件（支持多个文件）到程序窗体释放，或者直接在左边窗体粘贴乱码文本，点击按钮“>>”
（不会自动替换原来的乱码文件名）

使用技巧
在使用ANSI2Unicode打开一次文件之后，可以从右键菜单的“打开方式”快速使用ANSI2Unicode打开

相关博文：

tinyXml输出utf-8文档
一个线性时间复杂度的字符编码转换算法
UTF-8到Unicode的转换以及UTF-8编码的检测
GBK、Shift-JIS、BIG5编码检测算法
アカイイト 游戏脚本文件分析及脚本提取
tinyXml处理UTF-8编码详解——写入和读取
tak的内嵌cue提取
flac的内嵌cue提取
动态加载字符映射表的字符转换环境方案

一宿没睡。白天在C79战了一天，晚上又熬了一夜，真应该12点就去明治神宫参拜然后回去睡觉好了

早上7点多到达JR代代木站，前往明治神宫，7点45分已经又返回代代木站，三十多分钟就结束了新年初詣

早上比较冷，人还是不多的。卖炒面、章鱼烧等的店都还没开张

围了起来只能往池子里投钱，坑爹啊，余要摇绳啊～

北参道方向的高楼，但好像不是东京都厅