In my previous IDE which I used for my website's files there was a very useful option to configure key replacements. Particularly I would like to make sure that extended characters which are to be printed on the web page are added in their respective HTML-code and not as UTF-8 characters or so, because only then I'm on the safe side that the display is proper. So, that old IDE used to put ä into the text where I entered "ä", and so on.
Is there a way to do this in Eclipse as well? I found that many things are configurable, but I didn't find anything like this key replacement. It's kind of a makro thing, but not really, and is only needed within the editor.
Thanks for any suggestions/help.
The AnyEdit Tools plug-in can be used to convert special characters and umlauts into HTML entities:
Select the text to convert and hit Ctrl+Alt+E (or right-click and choose Convert > Chars to Html Entities)
Related
Edit: My assumptions about encoding were incorrect. I'm leaving the question as originally asked in case others come here with the same misunderstanding.
When I include a link in some text in the editor that includes a querystring, then view the source code, I can see that it's converted any & characters in the href to &, which breaks the links.
A link
becomes
A link
and if I change it back to just & in the source, click Ok on the view source dialog, then immediately view source again, it's already worked its charms and encoded the & once again.
Is there a way to cue the editor to go ahead and convert those outside tag attributes, but not mess with those in attributes?
Using an older version (4.0.12), but I see the behavior on the current live sample right on tinymce.com, so if it's a bug it looks like it hasn't been fixed. But I am wondering if it's just a setting I'm missing.
Relevant questions:
Do I encode ampersands in <a href...>?
Do ampersands still need to be encoded in URLs in HTML5?
The HTML spec actually states that ampersands in HTML attributes have to be encoded so TinyMCE is working 100% as it should. If your server side code is not handling that correctly that is an issue with the server side code.
I saved the face "savouring delicious food emoji" to database, and read it in php json_encode which show "uD83D\uDE0B"。 but usually we use one <img /> label to replace it .
however,usually I just find this format '\uE056' not "uD83D\uDE0B",to replace with pic E056.png .
I don't know how to get the pic accroding to 'uD83D\uDE0B'.someone know ?
What the relation between 'uD83D\uDE0B' and '\uE056'， they both represent emoji "savouring delicious food"?
The Unicode character U+1F60B FACE SAVOURING DELICIOUS FOOD is a so-called Plane 1 character, which means that its UTF-16 encoded form consists of two 16-bit code units, namely 0xD83D 0xDE0B. Generally, Plane 1 characters cause considerable problems because many programs are not prepared to deal with them, and few fonts contain them.
According to http://www.fileformat.info/info/unicode/char/1f60b/fontsupport.htm this particular character only exists in DejaVu fonts and in Symbola, but the versions of DejaVu I’m using don’t contain it.
Instead of dealing with the problems of encodings (which are not that difficult, but require extra information), you can use the character reference 😈 in HTML. But this does not solve the font problem. I don’t know about iPhone fonts, but in general in web browsing, the odds of a computer having any font capable of rendering the character are probably less than 1%. So you may need to use downloadable fonts. Using an image is obviously much simpler and mostly more reliable.
U+E056 is a Private Use codepoint, which means that anybody can make an agreement about its meaning with his brother or with himself, without asking anyone else’s mind. A font designer may assign any glyph to it.
IMPORTANT: As of this posting, the only browser that doesn't automatically support emojis is chrome.
FOR CHROME:
Depending on what server side language you are using, you should be able to find a library that converts emojis for you. I recently needed to solve this issue with php and used this library:
https://github.com/iamcal/php-emoji
The creator essentially created a sprite and adjusts the css according to the unicode of the emoji. It isnt pretty, but luckily he/she did all the grunt work for you. If you're using a different language you should be able to find something similar.
how do I put those little boxes into a php file?
Same way as any other Unicode character. Just paste them and make sure you're saving the PHP file and serving the PHP page as UTF-8.
When I put it into a php file, it turns into question marks and what not
Then you have an encoding problem. Work it out with Unicode characters you can actually see properly first, for example ąαд™日本, before worrying about the emoji.
Your PHP file should be saved as UTF-8; the page it produces should be served as Content-Type: text/html;charset:UTF-8 (or with similar meta tag); the MySQL database should be using a UTF-8 collation to store data and PHP should be talking to MySQL using UTF-8.
However. Even handling everything correctly like this, PCs will still not show the emoji. That's because:
they don't have fonts that include shapes for those characters, and
emoji are still completely unstandardised. Those characters you posted are in the Unicode Private Use Area, which means they don't have any official meaning at all.
Each network in Japan uses different character codes for their emoji, mapped to different areas in the PUA. So even on another mobile phone, it probably won't display the correct character, unless you spend ages manually converting emoji codes for different networks. I'm guessing the ones you posted above are from SoftBank (iPhone?).
There is an ongoing proposal led by Google and Apple to collate the different networks' emoji and give them a proper standardised place in Unicode. Until then, getting emoji to display consistently across networks is an exercise in unhappiness. See the character overview from the standardisation work to see how much converting you would have to do.
God, I hate emoji. All that pain for such a load of useless twee rubbish.
I see with some apps like Toodledo they use checkmarks for their revision history. How can you show/use special characters in an App Store product description? Does it allow HTML or do you just have to use ascii character codes?
Any tips/tricks for better presentation of our app's product information?
Thank you.
I think Apple just made the rule stricter on the App Store. I have been using special characters in my metadatas for a very long time but got a bad surprise today when trying to submit a new version:
Got this error message on iTunes Connect:
What's New In This Version must not contain the following characters: ★, ❤
Simply enter the characters using the character table in OS X.
To show it, go to OS X System Preferences -> International and select "Show Input Sources in Menu Bar". You should get a flag symbol next to the clock in the menu bar. Clicking on it results in a menu where you can open the character table, in which you can select and paste pretty much any character.
I am the author of the Toodledo app. Here is how I did it. I found the character I wanted on the internet by searching for "unicode symbols". I found it on wikipedia
I then copy and pasted the checkmark ✓ into my app description. And every time I need to make a new checkmark, I go and copy and paste it again since I don't know how to type it. There are lots of interesting symbols to choose from. I also use a star★
UnicodeChecker is an excellent Mac app that contains a database of over 100,000 characters defined in Unicode. You can search for characters by their assigned English names. For example, search for "check" to find several kinds of checkmark characters. Once found, you can copy a character and paste into your description.
UnicodeChecker is free of cost.
I want to add some comments to my mp3s but my comments all are in non-latin characters like arabic.
I have written a shell program to get the comments from user in windows but since LAME.exe is a console program I don't know how to convert these non-latin character to something meaningful for LAME.
so is there any way to add these kind of comments using LAME.exe?
regards.
I think you're going to have real trouble doing it on the Windows command line, as everything will be working in the system default code page (ANSI) and not Unicode. You won't be able to use Arabic at all unless you're on an Arabic Windows install (ANSI=code page 1256; settable in the region options), and even then I'm not sure it'll actually use the right encoding.
In any case lame.exe is not a good choice for editing tags, as it's an audio encoder, which will decode and re-encode the MP3, causing quality loss.
There are many graphical apps that will batch re-tag MP3s. If you want a scriptable solution you're probably better off with a higher-level language/library that supports Unicode better than the Windows command line/bat files (eg Python + Mutagen, but there are many possibilities depending on what languages you're familiar with).
So I started developing my firefox addon.
Most of the work is performed by a referenced javascript file.
Problem is that when I edit some of the html elements on the page and say, set their text it's written as pure giberish. I am writing the text in hebrew. Can't for the life of me figure the reason.
Any ideas?
Javascript strings are already Unicode at runtime. However, you have to make sure that your files are encoded correctly.
Always use utf-8 (without BOM) file encoding for all your js, XUL, DTD, properties files to be sure.
Firefox might try to guess the file character set incorrectly otherwise, and even worse some stuff might not even try guessing the encoding and instead simply always assume utf-8.
Better yet, do not hard-code strings in js/xul, but use DTD/properties files for localization (XUL tutorial, XUL School).
This, e.g. snippet works pretty well for me (on this very page):
document.getElementsByTagName("h1")[0].textContent="русский язык";
(Just fire up the Firefox Web Console)
"Inline" hewbrew embedded in js files might create additional problems because it is right-to-left and bidi sucks, so the localization approach should be preferred.