240 words on earthlingsoft
It’s been a year since the previous UnicodeChecker update. That’s quite a long time and still only half the time we needed for the one before that. Unfortunately all Unicode-related features we could think of are built into the application already (any more ideas?), so updates are mostly triggered by updates of the underlying standards these days.
The ‘star’ new feature of UnicodeChecker 1.15 is that it ships with files for the newly available Unicode 6 standard. It finally brings us emoticons (say hello to 😁: U+1F601
GRINNING FACE WITH SMILING EYES [interesting note: something in the blogging software decides to truncate the post at that character, escaping it seems mandatory]) and other, more serious, new codepoints. It’s highly unlikely that these codepoints are supported by any font on your Mac right now, but that’s the pleasure of living on the cutting edge.
The other major update is the IDNA. As the recently RFCified IDNA 2008 is quite a different beast in specification, implementation details, terminology and – potentially – also results than IDNA 2003, UnicodeChecker’s Utility now supports both versions (with the AppleScript interface defaulting to the new one). I’m curious where this development is going but the changes suggest that IDNA 2003 wasn’t the most precise and reasonable standard.
A further, technical, change is that UnicodeChecker now ships as a 64bit binary. Mac OS X.3 compatibility had to be dropped to make that possible. Crazy, I know…
Hi, long time user and fan of UnicodeChecker. Reinstalling a new mac the other day made me realize that it would be super useful to have UnicodeChecker in the Mac App Store, for easy install. I bet you could actually also put a price on it :)
Hello! I installed UnicodeChecker 1.15.1 on my Lion (OS X 10.7) MacBook Pro. It works fine; however, several other users say that I should be seeing it show up in my right-click menus, and that in System Preferences > Keyboard > Services > Text I should have some options like “Display Character Information” and “HTML Entities → Unicode”. Those parts aren’t showing up for me though. I’ve tried logging out and back in to no avail, and there don’t seem to be any Preferences settings that would apply.
Any thoughts on how I can get the right-click menu part to show up? I would love to highlight a character and immediately run UnicodeChecker on it. Thank you!
good to hear that UnicodeChecker is working for you generally.
Your friends are totally right to say that you should see (and thus be able to enable) UnicodeChecker’s services in the Keyboard Preferences.
Unfortunately I can’t reliably tell what is causing the problem for you. In principle Mac OS X should register these services as soon as you’ve launched the application for the first time. My best guess in your situation would be to either try and run the lsregister tool on UnicodeChecker to re-do the registration process (you’ll need the Terminal, the command is located at /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister possibly using it with the -f option). A cruder way would be to delete (Trash and empty Trash) the application, redownload it, launch it and hope the OS picks up the Services after that.
I hope this helps in some way.
It’s a great application. Thanks at first.
My question is how to use latest data, for example the Unicode 6.1.0 and latest UniHan data etc. Please give some hint.
You can download the latest Unicode Data files and place them in a Library/Application Support/UnicodeChecker/Unicode Data Folder and UnicodeChecker will use those files as described in the Unicode Data Files section of the Help.
Please note that Apple decided to make the Library folder in your home folder invisible in MacOS X.7. So you’ll have to use the ‘Go to Folder’ (Command-Shift-F) command in your home folder and type in ‘Library’ to get there.
Exactly what Unicode Data Files should we use to get 6.1.0 support? I downloaded UCD.zip from the public data directory but it includes way more data files than the Unicode Data shipped within the application bundle. Does UnicodeChecker really need all those files?
Hi! UnicodeChecker a tool I use almost every day! To look up or to do some conversion etc.
But a question regarding its URL escaping feature. What does «escape all code points» really mean? Could you explain by an example? The reason I ask you to provide an example is that I suspect that it has a bug. You see, I would have expected that when it is enabled, then even characters like the «/» (solidus) would be escaped. However, it does nothing when I serve it a solidus — it just leaves it unescaped.
Is this a bug or have not understood what hte «escape all code points» feature is supposed to do?
Great that you are finding UnicodeChecker useful!
I just checked the URL-escape command in the Utilities window and agree that the solidus should be escaped when the »Escape all codepoints« option is turned on. So I guess this is a bug of some sort and will check with Steffen when he is back from his holidays.
If you don’t mind using AppleScript, you can still invoke this feature through UnicodeChecker’s AppleScript support in the current version using a script like
tell application "UnicodeChecker" to escape "ä/b" to URL without preserving default set
This returns “%C3%A4%2F%62” which I suppose to be the result you expected.
Love this tool, It saves a lot of time. Than you!
Received data seems to be invalid. The wanted file does probably not exist or the guys at last.fm changed something.