I was learning flex for a few days now and suddenly noticed that input of unicode / foreign characters on Linux into TextInput, TextArea or RichTextEditor gives you unreadable text composed of several characters (seems like utf-8 is making things bad). On the other hand, output is flawless.
I was trying hard to find anything for the same issue on the internet, but only this old blog entry could be seen. Author produced temporary solution but it is not sufficient.
So if Windows allows unicode and Linux doesn't, what should I do? Maybe the problem is on my machine only? Did anybody come up with the same problem and maybe the solution?
I have Adobe Flash 10.0.32.18 installed on my Sabayon Linux box.
Might have something to do with this bug:
Incorrect unicode input in linux
Which, apparently, will get fixed once FP 10.1 is released.
Just to further update the answer. Flex 4 components support unicode and the unicode characters can be typed into input controls using Google Chrome, Firefox 3.6+ and IE7+ .
For Java MySQL users
database.url=jdbc:mysql://localhost:3306/sampledb?useUnicode=true&characterEncoding=utf-8
To allow utf8 data-write operations.
Database table and columns must be set to utf8_* encoding to make sure the unicode data can be stored in the tables.
Related
I have searched for a setting within the mvbasic extension within VSCode but I may have hit a dead end. I am new to using VSCode with the rocket mvbasic extension and still in the learning process, so please bear with me.
Our development for the most part has always been directly on the server using the editor within it to code and develop on a Unix/Aix platform with Unidata. Some of our code has array assignments with CHAR(253)/CHAR(254) characters within them. See the link to the image that shows how its done. Now I didn't do this code, the original software developer did this many many years ago and we just aren't going to go and change it all.
How code looks on actual server
The issue is when pulling the code to edit in VSCode, the extension is changing it, and I uploaded it back and didn't pay attention and it was implemented in our production incorrectly, which created a few bugs.
ALIST="H�V�P�R�M�D"
How code looks in VSCode
How code looks after uploaded back to server from VSCode
Easy to fix, no biggie, but now to my question.
Does anyone have this issue, or has a direction to point me into that maybe I need to create a setting to keep the characters in the correct ASCII format so that this doesn't happen again by mistake?
VSCode defaults to the sane choice for character encoding in 2022: utf-8, but sometimes you have to deal with legacy stuff.
https://code.visualstudio.com/docs/editor/codebasics#_file-encoding-support
If you click on the UTF-8 in the bottom right corner you can choose "Reopen with Encoding":
After that, you can select a different encoding. I chose DOS (CP437) at a guess and literal MV characters are displayed as superscript 2 (²), and for me I can save to the server and confirm those characters remain as #VM after a round trip (though for my terminal emulator they appear as } which is useful).
You can edit preferences and set "files.encoding": "cp437". One other thing that can be helpful if your programs don't have a standard extension (like .bas) as most don't is to set the default mode to basic so most of what you're editing will identify as MVbasic, and you can do a quick CTRL-K M to switch to any other modes if you're just pasting in something else like SQL.
Some useful links - the Rocket forums are helpful and the folks there are always super nice
https://community.rocketsoftware.com/forums/multivalue?CommunityKey=521bce2e-71d5-4d32-b560-dfa95e950eb5
The MV Extensions Community extension is a good group and always has been helpful when I've had issues. I've made some small contributions - they're very open. I prefer this extension, but honestly haven't done a deep comparison.
https://github.com/mvextensions
In my Chinese properties file I have a code like :
FORGOT_YOUR_PASSWORD_TITLE =\u5fd8\u8bb0 ID/\u5bc6\u7801
I have tried with native to ASCII of java software
Now I have to modify it. I am not able to understand whether it is Unicode or other. I have used native to ascii & other tools to find it out. But I did not find. Can any one help me to understand which type of code is this??
It is unicode. I'm assuming windows - different ball game if it is linux.
Start the charmap utility that comes with windows.
Change to font to Arial Unicode MS.
Select Advanced View.
Type in each of the \u codes and click select.
You will end up with something like
忘记密码
Copy that and paste in Google translate. Change the other side to English - it will say Forgot Password.
I just downloaded brackets after hearing that it will probably be the next big editor. I know it is still in beta, but does anyone know how to display foreign characters in this editor? When I try to display a foreign character, this symbol � is displayed.
Can anyone help?
Brackets currently only supports UTF-8 encoded files.
There's an item in the feature backlog to support other encodings, so you should upvote it if that's an important use case for you.
If you're pretty certain that the file you're working with is UTF-8 encoded (bearing in mind that it's tricky to tell for sure), then it sounds like you've hit a bug. As a Brackets core contributor, I definitely encourage you to file it in our issue tracker — and please include a link to the file in question if at all possible.
I have a SQLite file, with certain pronunciations of words such as /ˈdɪkʃən(ə)ɹi/ in records. However, when I view it in any SQLite browser on a Mac, I see funny characters like /ÃËdêkÃÆÃâ¢n(Ãâ¢)ùi,ÃËdêkÃÆÃâ¢nÃâºÃ¹i/, but when I use SQLite2009 Pro on a Windows, I see the characters encoded properly.
I have also placed PRAGMA encoding = "UTF-8"; but to no avail.
What is going on here?
An old question now, but the browsers you were using were broken and can't properly display UTF-8; there was nothing wrong with your input or storage. What you got back was exactly what you'd expect to see from something that doesn't support UTF-8.
Instead, use the cross-platform SQLite Manager for FireFox
I've been testing typing inside textInput components with the Windows Japanese IME turned on. All works well out of the box, which is awesome. One (fairly specific) question I have, though, is about typing numbers. It seems from my limited experience that numbers typed in default to Zenkaku (2 bytes) which don't seem to be accepted by the textinput as committed values. One can switch to Hankaku (1 Byte) notation by pressing F10 and the commit works. My question is about what's acceptable to a user. From my uninformed standpoint it seems like having to press F10 would be super annoying for a user and thus either the textInput should accept Zenkaku values or it should default to typing Hankaku (both of which I assume may be possible with a little bit of code on focusIn or ValueCommitted). But then again, it could very well be that this is in fact the standard behavior for most web apps in Japanese and thus not annoying at all. In fact, there may be a great reason for why Zenkaku happens by default.
Would love to hear any thoughts from anyone who has dealt with localizing to Japanese, or any advice on web resources where an answer to such a question could be found.
thank you
f
I'm a Japanese web-app developer, without no skills about adobe flex. Sorry for non-flex-specific answer.
Most Japanese Windows users can switch IME on/off with "半角/全角" key. (Macintosh : "かな" key & "英数" key) It's easier than pressing F10 after typing numbers. With announcement to type numbers in Hankaku, such as "半角で入力して下さい", most Japanese users will type in Hankaku.
Other methods
Switch off IME with CSS (works only in MS-InternetExplorer.)
// IE6
ime-mode: disabled;
// IE8
-ms-ime-mode: disabled;
Convert Zenkaku numbers to Hankaku automatically.