Trying to print unicode characters like ┌┌┝├ from QPython 3.6 (under Android on a Chromebook with Chrome OS 100) but print(u"┌┌┝├") prints nothing, and using \u doesn't work since \ is the line continuation character in QPython. Perhaps the sandwiching of Android-over-Chrome OS-over-Linux makes this impossible - it's certainly beyond my diagnostic abilities - but I was hoping that a high-level language like Python might be able to bridge that gap...
After a little more research it looks as though QPython 3.6's chr() function doesn't accept u"whatever" containing characters outside the ASCII set, ie. it isn't doing unicode at all
OK, have answer, both simple and humiliatingly ridiculous. After wasting hours reading docs and forums, I was running my Unicode test program when I noticed the 'preferences' button, at top-right corner of QPython console screen (but not of editor screen) greyed-out so as to be almost illegible. Among those preferences is a tick box 'Default to UTF-8' and ticking it instantly cured my problems. I do love QPython very much, but its documentation, help and UI design are simply appalling - it's taken me two years to find this box, and no-one has ever mentioned it.
Related
I am working on an MFC dialog based program with CTabCtrl (VS2017, W10). Everything works as expected, apart from the way tabs look (convoluted story, don't ask).
I need them to look like on the right, but when I created a new project with a CDialogEx based class and added tabs to the dialog (just the standard VS/MFC stuff, nothing fancy yet) they looked like the ones on the left. What I found after some testing and comparing with older projects is that if I switch in project defaults Character Set from Unicode to Multi-Byte Character Set I get the look I want (yes, sounds completely unrelated, but checked and rechecked several times). But that's ridiculously inconvenient, program needs to work with different languages and uses Unicode libraries for managing the data.
No idea if the problem is really MFC related, could be some deeper Windows thing.
Any idea what can be done to get the right look (pun intended), other than implementing my own OwnerDraw() or adding an additional layer of code to translate between data in Unicode and MBCS? Both approaches sound pretty off.
I have a Japanese program, but when I try to run it all the Japanese characters turn into random symbols like in the link to the picture
http://puu.sh/avcAp/04de126564.png
I've tried searching for answers but I only see ways to fix it if it shows up as blank rectangles and not the random symbols I'm getting.
You can see little bits of english just fine though, like in the link, you can see the .exe ... (I'm trying to install it but there's an error and since it's all these random symbols I have no idea what it means.)
Edit:
I'm running Windows 7 Ultimate. This is a program I downloaded online, but I'm sure it's not broken. The symbols in the picture are a screenshot from an error window (The windows default one with a red X on the left), however all the text that's related to that program that is Japanese is also random symbols, and my picture is just an example.
Edit 2:
Here is a better image
http://puu.sh/aveXV/7d15ecf2d4.png
Where you can see some Japanese characters, but some are random characters. This is when I first run the .exe to install and it's asking for what directory I want to install to
Thanks for your help in advance
It sounds like a non-Unicode program. It's not ideal, but you can change your non-Unicode program language in Region and Language settings in Control Panel to Japanese (requires reboot).
It only affects non-Unicode programs, so most modern English programs will be unaffected. I've changed mine to Chinese (PRC) and the only program I noticed affected was "cmd.exe". It allowed me to type and display Chinese at the console.
I have a text file encoded in Windows-1250. I'm using Windows 7 EN.
I would like to iterate through this file line by line in Perl code with
print. In console I cannot see the diacritic signs.
Could you give me any solution?
It depends on what you are going to do with the text, but for many cases
it's possible to code independently on encoding. Anyway, if you redirect
output to a file and the result is OK (read: can be displayed opened by
text editor in Windows 1250 mode using proper font), your code is not the
problem.
The other thing is that you want to see CE characters in your console.
For that to work you need to do:
set your console window to use font capable of displaying them (you
may need to install such font, I don't remember The Right Way in Win 7)
set your console to Windows-1250 mode using command chcp 1250
Note that this is basically the same you would need to do with your viewer
or editor to see the characters. Except that while many editors are able
to detect encoding themselves (sometimes even correctly) and pick the right
font, consoles typically need help from you.
Your problem might be similar to what has been solved here. I also
recommend reading the other post I'm referencing there.
I wrote this question and it turns out the code is correct but it doesnt display properly on my system. I dont understand! why might it do this? My system is set to united states english. I dont know what the problem can be.
This makes it difficult to develop unicode apps when it doesn't display properly on my system :(
-Edit- To be more clear. I made a winform app using .NET and the text appears incorrect on my machine but works on others. I can copy/paste text into my app but i wont know if it ran correctly since i see nonsense instead of text. However most unicode works. Special chars (like >16bits) does not.
I assume from the question you linked to that you are on a windows machine. The problem could be that windows does not have a global encoding option at all. The united states english is a language setting which as far as I know does not mean what you expect it to mean, as in it does not set all of your programs to show text in a unicode format.
The quick answer is that especially in windows, each program that displays text to the user is responsible for the character encoding. You have to make sure that the program and the environment where the problem appears are set to display text using some unicode format, such as UTF-8.
Read up on Unicode and UTF-8
There are a number of GUI hosts for Powershell (Powershell ISE, PoshConsole, etc) but I'm not aware of any purely console hosts other than powershell.exe. Are there any that offer any advantages over powershell.exe?
I'd like to be able to customise more of the host behaviour - specifically to add and customise key bindings other than TAB, and to customise error reporting. There could well be more...
If there aren't any "extended" versions of powershell.exe that offer this, how difficult would it be to write one? I have the SDK sample code, and it looks fairly accessible, but it's hard to be sure what features powershell.exe provides as opposed to the powershell "engine" (as there's no documentation I've found that focuses specifically on the host capabilities).
How about Console it can host multiple shells. Might be worth a look.
The best pure-console for PowerShell is obviously PowerShell Plus, which actually uses a fullblown "native" Windows console, but it wraps it up in candy coating and adds tons of IDE-style features. As far as I know this is the only third-party host that's capable of running "graphical" console apps like edit.com
As a sidenote, I'm honestly not sure it's worth the handicap of a true console just to keep compatibility with whatever graphical interactive console applications like Edit.com might still be around. Considering the limitations, and the amount of work that has to be done to pull off something like what PowerShell Plus has... Personally I can't wait for the day when I no longer have to worry about and can move on to console apps that are really MEF-style plugins in a console-style interface like PoshConsole :-)
I realise that this question is years old, but since I stumbled across it in search of answers, I thought I would add my findings.
I settled on Cmder, for the following reasons:
It wraps cmd and Powershell, so you get the same set of features you would find in either.
The default colour scheme is Monokai, which is not only pleasing to the eye, but actually readable. Maybe I was missing something, but the default output for most of my tasks (Git, Mocha tests etc.) had poor contrast most of the time and I found myself squinting at the screen.
Tab support - I've wanted this for a while, but until now I hadn't found a solution that provided tabs as well as everything else. Powershell IDE has some character encoding / text colour issues that I couldn't ignore.
It's portable - stick it on a USB stick and take it with you wherever you go.
It's configurable - the developer (Samuel Vasko) has done a great job here. It's not lacking for customisation.
Specifically answering the OP's requirements, you can remap key bindings and create macros. I don't see the ability to customise error reporting however.
Hopefully anyone else out there still searching for a decent command line emulator on Windows will see this answer and rejoice.
If you stick with a "Console" subsystem approach you will be saddled with all the limitations that come along with a Windows console subsystem application. Many complaints about PowerShell.exe limitations are really limitations of this feature of Windows (kbd shortcuts, line editing, etc).
What's wrong with PoshConsole? Even though it allows graphics to be displayed it is still a "console-style" UI on top of the PowerShell engine?