做了个LRC歌词日文汉字注音小工具

作者:V君 发布于:2019-2-21 13:04 Thursday 分类:我的应用

TL;DR

本体 ][ 源代码 ]

点击查看原图

效果: 在LRC歌词中的日文汉字后面自动加上平假名注音,用括号括起来
限制: 仅处理 [mm:ss.ff] 格式时间轴前缀的行,其他文字会直接追加到输出
环境: 只需要 .NET 2.0 就能运行,依赖MSIME.Japan 对于精简掉日文输入法的系统可能会挂
技巧: 左边窗格支持把文件拖放进去, 默认情况下以ANSI编码读取文本, 可以按住shift换utf8

扯扯:

自从发现了K米可以自动关联MP3旁边的LRC文件之后(之前只知道可以自己传,没想到还能带歌词),开始自己做时间轴歌词去练习K歌了. 最开始的时候是一个个汉字查字典找平假名注音,然后编辑本文. 多了就会烦,受不的时候才想起可以写个小工具来实现自动处理(真是码农失格!)

尽管已经把源代码放出来,但也可以扯扯实现过程的经历.

在动手之前,首先确认可行性,比如看看如何获取日文汉字的平假名注音,把想法拿去喂狗,然后咕狗吐出一篇博客文章详细地讲解了如何用MSIME.Japan实现获取日文汉字平假名.

但这是一整句转换,距离达成目的还差挺远.接着停下来想办法,或许用正则进一步处理可以实现.又去咕狗,找到了另一篇文章,讲解了如何使用正则判定日文平假名.

我去! 原来正则还有内置的字符集标识

  • \p{IsHiragana}判定日文平假名
  • \p{IsCJKUnifiedIdeographs}判定汉字

到目前为止,技术上的可行性已经确定,只需要把一个个[汉字+平假名]的组合分别喂给MSIME然后再抓出想要的部分,塞进括号并插入汉字后面就OK.

总结下来这个东西似乎并不太具备技术含量.. 嘛!问题解决了就好 _(:з」∠)_

接下来可以挑战一下卡拉OK视频字幕,虽然以前有做过,但那是手工操作的,那就让它自动化吧!

标签: 正则表达式 软件开发 C# Interop Winform

评论(2) 引用(0) 浏览(2355)

做了个小工具:锁屏后立即关闭显示器

作者:V君 发布于:2018-7-15 9:17 Sunday 分类:我的应用

点击查看原图

TL;DR

 [ 本体 ][ 源代码 ]


效果:


用法: 打开之后放一边, 最小化会缩小到托盘, 加入任意参数可以自动最小化, 方便自启动

环境: 只需要 .NET 2.0 ,Win7以上无需考虑兼容性.


闲话时间:

当显示器超过两个的时候, 需要一个个关掉太麻烦了.

尽管可以设置锁频1分钟之后自动关闭但还是不爽, 这货就诞生了.

依旧是强迫症的风格, 图标只留Win32资源, 启动之后用API读取并应用到主窗体和托盘图标.

标签: Interop Winform 小工具

评论(0) 引用(0) 浏览(994)

Winform小技巧:让窗体直接使用exe图标(PE资源),避免重复嵌入图标资源

作者:V君 发布于:2018-3-20 17:52 Tuesday 分类:挖坑经验

TL;DR

用CodeProject上的帖子的实现, 传入主程序路径, 检查图标个数, 将首个图标给需要的主窗体。这里有个例子把代码搬进去就能用

扯一扯:

有点.net开发经验的人都应该知道:Winform窗口图标和exe文件图标不是同一个东西。假如有需要使用同一个图标的情况, 那将会保存两份数据, 令有强迫症的人(比如我)抓狂。之前有折腾过Windows图标相关的操作, 这次也轻松提取主程序图标然后应用到主窗体上。

PS. 这种方式可以支持多尺寸图标, 简单调用系统API的ExtractIcon不支持。

偷偷更新一个极端案例,顺便吐槽一下 TalAloni 酱。因为 ta 给每个窗体都使用了重复的图标,导致最终文件体积骤增,若不把是 ilmerge 换成 ilrepack 之后成功打包,还没发现居然超过了 3MB!回来检查体积来源就发现了每个窗体的 resx 文件都有 500KB ,接着发现了重复的图标文件。

点击查看原图

标签: 软件开发 C# Interop Winform

评论(0) 引用(0) 浏览(1540)

尝试在Windows NT6+上免驱实现FUSE

作者:V君 发布于:2017-9-22 20:18 Friday 分类:折腾手记

■前言  (这次不是解决问题,因此没有TLDR(´∀((☆ミつ)


首先简单解释一下 FUSE 的定义:

在用户空间实现的虚拟文件系统, 能够让标准文件系统API访问,

只是某个路径在应用程序的控制之下, 还没到达虚拟块设备的级别.


FUSE 能够实现许多有趣的功能, 比如挂载压缩包, FTP, MTP, 甚至 Ramdisk 都能实现.

在 linux 实现 FUSE 可以说是相当容易,

由于 linux 可以把 FUSE 功能集成到内核, 随便 mount 就可以了.

然而 Windows 内核并没有这样的功能,

只能以虚拟设备来创建虚拟盘符或挂载到 NTFS 装入点亦或者建立目录符号链接.

 

现状


在 Windows 实现 FUSE 通常需要虚拟驱动器来实现, 这需要驱动程序来支持.

现成的软件有

1)免费的 WinMount(生死未卜)

2)收费的 NetDrive.

它们都是封装好的产品, 用户不能定制自己的功能.

可以自己实现接口的驱动组件有

1)开源的 Dokan(貌似不太稳定)

2)开源的 WinFsp(没用过,无法评论)

3)死贵死贵的 CBFS.

早些年把玩过Dokan, 虽然提供了.NET的接口, 且实现难度还不算高.

假如接口实现得不稳定, 没妥善处理好异常就可能会引发蓝屏, 这也就是本文的初衷.

-- 不使用驱动来实现 FUSE , 就算接口实现得再糟糕也不会把系统搞崩溃.

 

摸索


稍稍有点经验的 Windows 用户都知道,

资源管理器可以直接访问FTP或多媒体设备存储(MTP/PTP)

可以把路径以文件夹的形式图形化呈现, 

然而这些路径并不能够使用标准文件系统 API 来放访问,

不能用 WindirStat 来统计 MTP 上的文件夹占用情况.

尽管资源管理器双击能打开这些路径中的文件,

其实背地里还是先复制到临时文件再调用关联的应用程序去打开.

 

其实 Windows 还是可以不依赖驱动就能实现 FUSE 的.

目前发现了两种方法, 尽管都是利用网络共享绕一圈, 还蛮折腾的:

1)基于 HTTP 的WebDAV 协议

 在一次折腾如何在安桌手机 USB 的 MTP 模式使用 WinDirstat 的过程中

 发现了 WebDAV 共享 APP.

 安装并启动之后, 按照步骤创建映射盘符, 能被 WinDirstat 访问了.

 咕狗了解到是基于 HTTP 的共享协议.

 (这是WebDAV over WIFI, 这已经和 MTP 没关系了, 不过下文还是会和MTP有关系)

 这才发现 Windows 还有这种共享方式, 支持标准文件系统 API, 

 只是实现机制略坑, 性能略糟糕.

2)Samba 局域网共享

 不解释太多也不会被打 (´∀((☆ミつ

 需要实现一个 SMB 服务端, 还要战 445 端口. 战? 不是占? YES, 稍后娓娓道来.

 

尝(zhe)试(teng)


□WebDAV -- 这货是真FUSE, 只是 Windows 实现机制太坑人


知道这货基于 HTTP 之后, 当然就是去找找看有没有人已经做成类库, 而不是先自己啃RFC.

放狗出去找到两个类库, 分别是 SF 上的 WebDAV.NET 服务框架 和 GitHub 上的 WebDAVSharp.

这次选择了后者, 只要按接口做实现, 就可以达到目的, 咋一看还挺完善的, 只是性能有点慢.

即使用内存来实现后端文件存储, 访问速度也和硬盘差不多,

监视性能才发现, 原来 Windows 在背后依然用临时文件的方式暂存 WebDAV 上面的文件, 

只是重定向了一下文件系统. 难怪这么慢, 这 FUSE 虽然是真货, 但却掺了水.

你可以把它的临时目录(↓)链接到 RAMDISK 以提升性能, 此目录必须存在才能正常操作文件.

C:\Windows\ServiceProfiles\LocalService\AppData\Local\Temp\TfsStore\Tfs_DAV\

只不过这样就失去了用 WebDAV 实现 RAMDISK 的意义, 只能用作简单 FUSE 玩玩.

顺便再贴一个之前还没了过背后原理, 仍未知性能坑时, 实现MTP2DAV

 

Samba -- 战445端口要不要太折磨人?


非常幸运地找到最近 TalAloni 用 .net 实现且一直在维护的 Samba 服务端的库 SMBLibrary.

看了下介绍, 确实有提到可以实现虚拟文件系统. -- 只是 445 被 Windows 锁死, 需要一战.

除非禁用 Server 服务, 否则全部适配器的 445 端口将不可用...见爆栈.

尝试了许多诸如增加虚拟适配器的 trick 做法, 然而并没有设么卯月...

停止 Server 服务之后还不行, 445 仍然会被 System 占用, 需要重启...

那就只能彻底禁用了.禁用了 Server 服务并重启之后, 445 端口总算可用.

把内置的目录共享跑起来, 效果还挺理想, 性能相当不错, 看了一下接口并不是很复杂.

就简单做了个后端用内存支撑的 RamDisk 实现, 然而并不是很理想.

-- 非常不稳定, 常规操作下会出现各种错误, 看来是接口适配的不太妥哇...

总之, 这种 Samba 的方式是可行的.

只是稍稍麻烦点, 无论是从禁用 Server 服务还是实现接口上来看...


■结论


WebDAV 可以用来实现简单的 FUSE, 无法考虑性能.可以用 RamDisk 稍稍提升一下.

Samba 性能相当好, 接口略复杂, 目前还没啃透 (´∀((☆ミつ

标签: C# Winform NAS HTTP 传输协议 FUSE VFS Windows

评论(0) 引用(0) 浏览(2727)

[update2]批量重命名文件/垂直编辑/数字对齐 - 自制小工具

作者:V君 发布于:2016-3-13 2:17 Sunday 分类:我的应用

TL;DR

[ 本体 ][ 源代码 ]

效果:批量修改文件名;

用法:

1)双击打开, 把要处理的单个文件夹拖进窗口

2)按住alt键在需要对齐的地方拖下来,按需要进行删除/补齐或批量更改,剪切粘贴.

 注意:垂直选中文字块剪切后,需要在贴上的地方拖一个长光标才能跨行粘贴. update:可以直接用左右箭头来移动长光标.

3)点击工具栏Go!执行, 这时候可以点Reset来进行下一轮处理;

环境:需要.net4, win8以上可以直接使用. win7需要安装.net4.5才能用

点击查看原图


隐藏秘籍:

alt+鼠标拖放 块状选择
●alt+shift+方向键━开始/改变块状选择
●块状选择时 左右箭头左右移动选择块
●块状选择时 ctrl+左右箭头增减选择块宽度
●块状选择时 shift+左右箭头左右移动选中内容
▲块状选择时不要按ctrl+别的键(包括ctrl+Z)



[~闲话时间~]

这就是前段时间的文章提到的做法, 终于把自动化做出来了.

虽然用了NootePad++的文本编辑器组件,但是这货自己并不带纵向编辑.

在自己实现纵向编辑上花了好大功夫.

看来NPP也不仅仅是个包着文本编辑器组件的壳(笑)


不要吐槽源码为啥这么手打.

自从出来工作之后大部分是Web, 习惯手打界面布局.

作为一个牛逼的软件开发人员, 应该对使用设计器感到羞愧(笑)

整天从早到晚打字,设计器什么的经一去不复返喽!!


update:

上一个版本是关闭窗口时提示要不要执行, 现在改成工具栏了

本想在标题栏加按钮, 但是发现很难实现, 玻璃效果和经典主题的处理方式还不同...


update2:

修正包含全角数字文件名时拖入失效的BUG

标签: 软件开发 C# 字符串处理 Winform 小工具 纯文本 纵向编辑 批命令

评论(4) 引用(0) 浏览(2417)

Powered by emlog 去你妹的备案 sitemap