小熏的编程日记

实在忍受不了用记事本编辑Dewplayer的播放列表，于是用JavaScript写了一个生成器，顺便练一下JavaScript 使用地址： http://go.kuyur.info/playlist-creator/ 将几个文件（index.html/make.js/style.css）下载回本地也可以运行 支持IE6～IE9，Firefox，Chrome，应该也支持Opera 话说，IE8以下真的和别人格格不入啊，IE9在标准JavaScript支持上改善了不少，但还不够 用法简单说明： 必填： Track titles：歌曲标题列表 Track URLs： 在选中Pattern模式时，请在单行文本框输入URL模式字符串，形如http://example.com/{##}.mp3。{##}会被替换，从1开始，单位递增1，#的位数是生成数字的位数。 {#}.mp3会产生1.mp3，2.mp3，…，9.mp3，10.mp3，… {##}.mp3会产生01.mp3，02.mp3,…，09.mp3，10.mp3，… 在选中List模式时，请在多行文本框输入歌曲的URL列表，行数必须和曲目标题列表的行数相同 选填： (Optional) Album Title：专辑名 (Optional) Album Cover URL：专辑封面图片URL 点击Generate按钮就可以生成支持Dewplayer的xml播放列表。 Save按钮现在无效 有时间大概会做成一个wordpress插件 参考资料： 播放列表xml化的命名空间：http://xspf.org/ns/0/ xml文本的格式化： http://www.cnblogs.com/evlon/archive/2009/01/09/1372283.html

JavaScript Style Rules 2.1 Naming 命名 通常地，像下面一样命名: 函数名、变量名、方法名：首字母小写 类名、枚举名：首字母大写 常量：恒大写，下划线分割 2.1.1 属性和方法 私有属性、变量和方法应该以下划线结尾 受保护属性、变量和方法不应当以下划线结尾（和公有一样） 关于私有、受保护，参考visibility一节 2.1.2 方法和函数的参数 可选的参数以「opt_」开头 如果函数接受不定参数，应当将此参数放在参数列表的最后，并且以var_args命名 但在函数体内不应使用var_args。使用arguments数组来代替。 2.1.3 属性的Getters和Setters ECMAScript5的Getters和Setters不建议使用。 如果使用了，那么Getters中不应该修改可见的状态 错误的用法： 2.1.4 存取函数 属性的Getters和Setters不是必需的。 但是，如果要写，那么Getters必须写成getFoo()、Setters必须写成setFoo(value)的形式。 布尔型的Getters可以写成isFoo()，并且通常看起来更自然。 2.1.5 命名空间 JavaScript没有原生的包或命名空间机制。 全局的命名冲突很难debug，而且在两个工程合并时会导致棘手的问题。 我们采取约定俗成的方式来防止冲突来实现代码重用。 2.1.5.1 为全局的代码使用命名空间 总是使用和工程名或类库名相同的词作为（伪）命名空间的前缀。 例如，如果你正在写一个叫”Sloth”的工程，合理的（伪）命名空间应该是sloth.* ： 许多JavaScript类库提供创建命名空间的高级函数，如the Closure Library和Dojo toolkit： 2.1.5.2 明晰命名空间的所有权 当创建子命名空间时，确保父命名空间的所有人知道你在干什么。 例如，当你开始一个为sloths创建hats的工程时，确保Sloth团队知道你在使用sloth.hats命名空间 2.1.5.3 内部代码不能使用和外部代码相同的命名空间 外部代码是指不在你的代码库中的代码，它们独立地编译（通常是引入的第三方类库，但也有可能是别的团队写的类库）。 内部代码和外部代码的命名空间要严格分离。 比如，一个外部库定义了foo.hats的命名空间，foo.hats.*变得可用， 但你的代码不能在foo.hats下面定义任何符号。 错误的写法： [...]

组内计划依照Google的JavaScript编程规约来进行开发。非常认真的学习了一下，于是顺手简单地翻译成了中文。 Style Rules部分等有空再翻。因为是原创，虽然可能别人也翻译过了，但转载时仍请注明出处。 余刚学习JavaScript不久，不可避免对原文的理解有错误，如有错误或不当地方请指出。 Google JavaScript Style Guide 中文简要翻译 1. Language Rules部分 1.1 var 总是使用var声明变量。（理由不多说了） 1.2 Constants 使用大写字母和下划线『_』来声明常量。可以在注释中适当使用@const标签。 但不要使用const限定词来修饰变量。IE浏览器不会解析const。 例如，对于简单的类型，命名规则已经足够： 对于复杂类型，使用@const标签： 这允许编译器强制检查是否有改变。 1.3 Semicolons 总是使用分号『;』来结束语句。（理由也不多说了） 1.4 Nested functions 嵌套函数（函数体内定义的函数）：可以使用。 嵌套函数有时候非常有用，自己决定在需要时使用。 1.5 Function Declarations Within Blocks 在块中定义函数：不要这样干。 虽然大多数JS解析器支持，但这不是ECMAScript标准。 ECMAScript标准只允许在脚本的全局环境或者函数体内定义函数。 请使用匿名函数并赋值给一个变量来替代。 错误的用法： 正确的用法： 1.6 Exceptions 应当使用异常处理。异常是不可避免的。 1.7 Custom exceptions 自定义异常：可以使用。自己决定在需要时使用。 1.8 Standards features 为了保持最大兼容，使用标准特性而不要使用非标准特性。 例如使用string.charAt(3)而不是使用string[3]。 又如使用DOM的函数来操作HTML元素而不是使用特定的省略记法。 1.9 [...]

工作后干的活有点乱七八糟，被折磨死 每一段时间就要学新的语言。2011下半年是C#，2012年，轮换到了JavaScript 最近的任务是用ExtJS设计前端，这玩意强大到足以取代Silverlight，非常适合配合RESTful API使用，使用AJAX获取JSON或XML类型的数据，前端页面的生成完全不需要PHP/JSP，仅HTML+JS已经足够。这种情况下，前端可以和API所在服务端完全分离，部署在不同的服务器上，甚至前端可以放在用户本地运行 第一个任务是攻克多语言化(老大乃将这种任务扔给素人情何以堪) 网上搜索了一下，还有人专门写了插件（ext-locale-loader），但这种需要给每一自设计的页面弄一份语言拷贝的方式让余菊花一紧 后来阅读ExtJS的自带文档，发现有本地化的详细指引（$EXTJS_FOLDER/docs/index.html#!/guide/localization） 一步步来就实现了ExtJS自身的UI元件在用户选择不同语言时的本地化 实现后的效果 演示页面：extlocalize.html ExtJS语言列表RawData：languages.js（仅保留4个语言） 逻辑+UI：extlocalize.js 切换语言的逻辑其实非常简单，判断页面的传入参数（没错，静态页面也可以有参数），利用AJAX加载语言文件，然后执行语言文件中的代码，更新字符串 extlocalize.html languages.js extlocalize.js 以上仅是ExtJS UI自身的本地化。 自己系统中的文字如何本地化呢？ 余的做法基本是沿着ExtJS本地化的思路，将系统用到的字符串集中在单个文件中，这也有利于后期扩展更多的语言 像Date picker/Email Field/Month Browser/Month of the year就是系统自身的语言，不应该硬编码到UI中 在加载ExtJS语言文件的时候，同时也加载系统自身的语言文件进行刷新 系统语言文件也必须使用和ExtJS语言文件相同的后缀，如en/ja/zh_CN/zh_TW 效果： 演示页面：multiplelanguages.html 逻辑+UI：multiplelanguages.js 语言列表RawData：languages.js（和上面一样） 系统默认语言文件（必须）：myproject-js/myproject-lang.js（余将默认语言弄成了日文） 系统的本地化语言文件（可选）：（没有参数时会保留默认语言文件中的设定） locale/myproject-lang-en.js locale/myproject-lang-ja.js locale/myproject-lang-zh_CN.js locale/myproject-lang-zh_TW.js multiplelanguages.html multiplelanguages.js 将UI的生成全部集中到setup函数里了 myproject-js/myproject-lang.js locale/myproject-lang-en.js locale/myproject-lang-ja.js locale/myproject-lang-zh_CN.js locale/myproject-lang-zh_TW.js 注意事项： 1.ExtJS库的解压目录名要一致，代码中的为ext 2.由于AJAX的本地请求会因为安全问题被浏览器禁止，需要将文件放到服务器才能测试 源文件下载：localize.rar

大概文字编码处理得多了，连同事遇到这方面问题，都跑过来问余了。 今晚同事遇到获取网卡接口名称乱码，无论怎么转都无法解决。 果然最好的方法还是查看字符串的二进制内容，乱猜是无用的。 平台是日文正版xp NetworkInterface的getDisplayName()方法返回值是String，那确定就是一个Unicode字符串了 直接打印这个名称，最后一个”-”之后的字符串都不正常 使用String的getBytes(“UTF-16″)方法取出字串的二进制内容，全部打印出来，前几个以及最后几个的值如下 首两个字符是-2，-1，也即0xFE，0xFF，大尾的BOM（Java你到底有多变态），每个字符都是高位在前 ASCII部分的字符高位为0，毫无疑问开头的几个字符就是Intel 来看最后几个字符 去掉0之后，序列是-125 80 -125 87，也即0×83 0×50 0×83 0×57，酷似多字节编码 打开WinHex（D版UltraEdit是不能装的），新建一个四字节文件，多字节编码在文本中都是先高位后低位， 于是按顺序写入16进制值，保存为txt文件 用记事本打开txt，结果是”ケジ”（日文版xp） 还可以用Ansi2Unicode打开，选择其他编码查看转换结果，Shift-JIS是最正常的了 于是终于可以下结论，这个字符串的原始编码就是Shift-JIS，但被分开成一个个byte，高位填充0，暴力转换为Unicode字符串。 这样的字符串非常的不正常，难怪怎么转都不对了 还原方法：去掉头部的BOM，去掉所有的0，得到二进制数组，在new一个String的同时，指定这个二进制数组的编码是Shift-JIS 猜测是JDK调用了win32 api，却没有处理返回来的字符串编码 同事说Win7平台上没有问题，不需要转换，可能是因为win7系统的api返回的是Unicode字符串 这个修正方法和平台相关，很不通用

稍微花了一点时间写了这个简繁繁简字符转换程序。主要为了验证通用库的扩展能力，程序功能不是目的，因此以后基本不会更新。 程序界面： 特性： –简繁繁简转换 –仅支持Unicode（LE）输入和Unicode（LE）保存转换结果 –采用维基简繁繁简一对一映射表，如有问题找维基 –不支持词组转换 使用方法很简单，拖曳单个文本到程序窗口，就会自动转换。左上的下拉框可以选择恰当的映射表。 程序下载地址：http://code.google.com/p/unicue/downloads/detail?name=ChineseConverter_1.0.zip

蛋疼写了三种UTF-16到UTF-8的转换方法。其中一个不出所料果然很慢，但另外的两个测试结果让余跌了一下眼镜。 直接在内存上操作速度当然快，因此converMethod中convert2utf8毫无疑问是最快的 剩下的 convert2utf8_pushback convert2utf8_copy convert2utf8_allocate 都是返回STL中的string对象，哪个最快，哪个最慢，大家来猜一下吧 convertMethod.h 测试程序：在VC新建一个工程把代码覆盖进去，并导入convertMethod.h 测试文件的路径需要更改一下，推荐用大文本测试，更能显示出性能的差异 测试文件只能是Unicode编码的文本文件 提供测试样品：bungakusyoujyo-unicode

余去年写Ansi2Unicode的时候，不使用win32 api进行字符转换，使用了自定义转换函数。几个不同编码的转换函数，写起来大同小异。特别是GBK和Big5，可以说是完全一样。于是很早就想开发一个动态加载字符映射表的字符转换环境，当添加新的编码时，不需要改动程序。 现在考虑到的一些特征： 1.独立于平台。Ansi2Unicode的转换函数（toUnicode.h)严重依赖MFC，通用性很差，余一直不太满意 2.字符映射表的信息保存在配置文件（charmap.xml文件），由环境动态加载。环境是一个通用环境，普适各种多字节编码 3.用户制作映射表和添加新的映射表信息遵循一定的规则 4.平台即使在运行时都可以重新载入映射表 5.字符映射表使用优先顺序由在配置文件中出现的顺序决定。用户可调整顺序 这个平台的扩展性非常强。制作映射表，修改charmap.xml，一种新的编码转换方法就添加了，有别于以前需要多写一个函数。 另外，用户还可以替换映射表，随着字符编码的升级而升级。 初步的charmap.xml配置文件

名字来由：Uni代表Unicode，Cue为cuesheet，意为将各种编码的cue文件转换到unicode编码 本意是写一个foobar2000的插件实现编码的转换，但最后变成一堆杂七杂八程序的集合 项目开源，放在Google code上托管 http://code.google.com/p/unicue/ 目前包括的程序有： ANSI2Unicode（主要的编码转换程序） MakeB2Umap（自定义的Big5到Unicode映射表文件b2u-little-endian.map生成） MakeGB2Umap（自定义的GBK到Unicode映射表文件gb2u-little-endian.map生成） MakeJIS2Umap（自定义的Shift-JIS到Unicode映射表文件jis2u-little-endian.map生成） ExtractAkaiito（PS2游戏アカイイト游戏脚本提取） ANSI2Unicode最新版本1.0.3，功能特性包括： –完整的Unicode支持，不必为文档路径中的特殊字符担心 –自定义BIG5 to Unicode的映射表，取代微软自身的CP950，解决日文假名丢失问题 –实现3种常用编码（GBK、Big5、Shift-JIS）到utf-8的转换 –转换结果保存为utf-8编码的文本 –自动检测文本编码 –支持文件拖放操作及命令行打开文档 –自动修正cue中的File行音频文件扩展名 –自动修正cue中的File行旧式“The True Audio”标签为“WAVE” –不改变默认打开程序的txt/log/cue右键菜单关联 –提取tak/flac/ape的内嵌cue，并自动修正cue中的音频文件名 –转换字符串功能 –转换字符串模式下，支持拖放乱码文件名进行转换 IE转换Big5文本会造成日文假名字符丢失（所有调用win32 api函数MultiByteToWideChar的转换程序都有此问题，根本原因在于win系统的映射表CP950不完整） 使用ANSI2Unicode转换（使用自定义的映射表b2u-little-endian.map及自定义的转换函数） ANSI2Unicode简明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 [...]

ANSI2Unicode是开源项目UniCue的组成部分。ANSI2Unicode致力于文档编码的转换，通过自定义编码映射表，目前支持Shift-JIS、GBK、BIG5三种编码到utf-8的转换。 ANSI2Unicode 1.0.3 功能特性： –完整的Unicode支持，不必为文档路径中的特殊字符担心 –自定义BIG5 to Unicode的映射表，取代微软自身的CP950，解决日文假名丢失问题 –转换结果保存为utf-8编码的文本 –自动检测文本编码 –支持文件拖放操作及命令行打开文档 –自动修正cue中的File行音频文件扩展名 –自动修正cue中的File行旧式“The True Audio”标签为“WAVE” –不改变默认打开程序的txt/log/cue右键菜单关联 –提取tak/flac/ape的内嵌cue，并自动修正cue中的音频文件名 –转换字符串功能 –转换字符串模式下，支持拖放乱码文件名进行转换 下载：http://code.google.com/p/unicue/ 源码：http://unicue.googlecode.com/svn/trunk/ bug反馈或特性提出可直接在blog回复或前往http://code.google.com/p/unicue/issues/list 转载扩散大欢迎