Unicode output on Windows command line? - unicode

I wrote a small Java application which output includes Unicode characters. When I use Eclipse to run it—I see all the output as expected.
The people who are supposed to use the application will run it as a jar file. I thought they could use standard cmd window, but in this window the Unicode appear as Gibberish.
Is there a way to make "cmd window" recognize the Unicode chars and display them properly?
Or, is there any tool to easily run the jar file and get the correct output?
BTW - redirecting the output to a file works okay, but the program is interactive, so this will not be a good solution.
Edit: Thanks everybody for the suggestions.
It seems that the cmd fonts don't have the specific characters I need, and this is why changing the code page did not solve my problem.
I found a way to add more monospaced fonts to the console, but after I add them any change that I want to do regarding the fonts (even choosing one of the original fonts in a different size) - is ignored.
I think that I will simply try with another tool, which supports chhosing a differnt font more easily.

Reference: Java Unicode on Windows Command Line
Try chcp 1252 or chcp 65001 from the command line. With Lucida Console or other font support.

try CMD /c /U java your.jar

The problem is the font with which the windows console is displaying output. Unfortunately for you, this is a user setting.
I recommend you suggest that your users set their windows console font to Lucida Console. That font should be able to handle wide/unicode characters.

In C++/C just use this: system("chcp 65001");
Don't forget to change the console's font to Lucida Console

For any answers, check it first. This is a simple console program, which verifies that changing the font actually does not work.
using System;
namespace ConsoleApplication1
{
class Program
{
static void Main( string[] args )
{
Console.OutputEncoding = System.Text.Encoding.UTF8;
Console.WriteLine( "日本語です" );
Console.Write( "Finished. Press a key. " );
Console.ReadLine();
return;
}
}
}
I will check to see if the answer is concretely "Cannot be done". Other avenues to check: use a different shell. i.e. Powershell? I'll see if that works.
However, you could do:
ConsoleApplication1.exe > output.txt
notepad.exe output.txt
Disclaimer: My example is C#, but the console application should still work as such.
And view the results like that, in the meanwhile.

UTF-16 on cmd.exe
Open/run cmd.exe
Click on the icon at the top-left corner
Select properties
Then "Font" bar
Select "Lucida Console" and OK.
Write Chcp 10000 at the prompt
Finally dir /b
Also from
Is there a Windows command shell that will display Unicode characters?
CHCP 65001
DIR > UTF8.TXT
TYPE UTF8.TXT

Related

How to hide "PS C:\>" in powershell?

So you know how in powershell if you enter a command infront of it there will always be "PS (directory)>".
I know its possible in cmd with a simple command but how do you do this in powershell?
so:
Hide the text(PS C:>) thats infront of commands
If possible through a command
If any of you know the fix please let me know.
If i find it first i will self anwser.
(I later found this dup):Windows PowerShell: changing the command prompt
Just like Calculuswhiz mentioned, the following should work:
Function Prompt {" "}
Simply change it by adding anything else inside the double quotes.
Abraham Zinala's helpful answer shows that it is the prompt function - described in the about_Prompts conceptual help topic - that determines the string that PowerShell prints in interactive sessions when prompting the user for commands.
As Calculuswhiz notes, outputting the empty string ('') is not an option for not printing a prompt string at all, because PowerShell then defaults to PS>.
Printing a single space is one way to work around the problem, but that space does print. To prevent that, Dabombber proposes workarounds in a comment on Abraham's question, but the simplest solution as of Windows 10 is:
function prompt { "`0" } # Fully HIDES the prompt string.
"`0" outputs a NUL (null character), which effectively hides the prompt string, without side effects, including in Windows Terminal and ConEmu.[1]
On Windows 7, the NUL prints as a space, in which case Dabombber's alternative helps:
# A space followed by a backspace char. in effect amounts to the empty string.
function prompt { " `b" }
Add this function to your $PROFILE file to hide the prompt string in all future sessions.
[1] Verified on version v20.11.24.0. Dabombber mentions that ConEmu prints NUL characters as a space, but, given that ConEmu is conhost.exe-based, just like regular console windows, that applies only up to Windows 7.

How to fix some tmux things (screen instead of xterm; function keys)?

Why does tmux change the terminal from xterm to screen, and how can I fix the resulting text color change in emacs? I think the easiest way would be to prevent it from changing to screen in the first place.
I can use TERM=xterm emacs file.ext to do it temporarily, but that's just a workaround that doesn't solve the root of the problem.
Furthermore, the function keys no longer work in emacs when using tmux. Instead of F3 and F4 being macro shortcuts, they just print a tilde as they would in the shell. This seems unrelated to xterm/screen mentioned above. What is happening here, and how I can fix this?
tmux sets TERM to screen because that terminal description is limited to things that tmux knows how to work with. Like screen, tmux translates features from the outer terminal description to the inner.
If a special key (function-key, cursor-key, etc) does not have an exact match in the terminal description, tmux will ignore it.
The default configuration for PuTTY sends different escape sequences for F1-F4. The sequences which PuTTY sends are not in the terminal description for xterm.
Here's a comparison of the two (as a CSV file, but readable enough):
NAME,putty,xterm
kf1,\E[11~,\EOP
kf2,\E[12~,\EOQ
kf3,\E[13~,\EOR
kf4,\E[14~,\EOS
kf5,\E[15~,\E[15~
kf6,\E[17~,\E[17~
kf7,\E[18~,\E[18~
kf8,\E[19~,\E[19~
kf9,\E[20~,\E[20~
kf10,\E[21~,\E[21~
kf11,\E[23~,\E[23~
kf12,\E[24~,\E[24~
kf13,\E[25~,\E[1;2P
kf14,\E[26~,\E[1;2Q
kf15,\E[28~,\E[1;2R
kf16,\E[29~,\E[1;2S
kf17,\E[31~,\E[15;2~
kf18,\E[32~,\E[17;2~
kf19,\E[33~,\E[18;2~
kf20,\E[34~,\E[19;2~
You'd have trouble getting PuTTY to send F13-F20, but will certainly run into trouble using PuTTY and tmux with TERM=xterm.
Regarding colors, the same issue applies. The screen terminal description tells applications that the terminal can support 8 colors, and tells how to display those eight colors. If your external terminal can do more, then tmux and screen hide that.
The conversion is not perfect. GNU screen has a feature where it looks for a corresponding screen.$TERM terminal description (i.e., concatenating the outer TERM value to screen). tmux does not do that: it makes assumptions regarding xterm. But PuTTY is not xterm...
ncurses has several of those concatenated terminal-names for terminal descriptions, but no one has suggested a way for tmux to use them automatically.

How achieve a two line Prompt?

In the batch language of Microsoft's CMD.EXE console window, I never liked having my command start at the far right, after a long display of the directory path. So in my Control Panel → System → Advanced System Settings → Environment Variables I saved the following assignment, where $_ is like a Soft Return:
PROMPT=[$P\]$_$+$G$S
The displayed prompt was two lines like this:
[C:\Temp\]
>
(The $+ tracks pushd and popd, the fancier than chdir commands. $S is space. By the way, the ^ character a line wrap/continuation character in batch, just as backtick ` is in PowerShell.)
Now I want the same-ish two line prompt in PowerShell. There is good news and bad news.
The good news is I can achieve that in my open PowerShell window by typing at the > prompt:
function prompt {'[' + $(get-location) + '\] SHIFTENTER > '
(By SHIFTENTER I mean press Shift+Enter, what I think might be called a "soft return"?)
....... BAD NEWS, PROBLEM ......
I want to put the above function prompt ... line into my profile PowerShell script, namely Microsoft.PowerShell_profile.ps1 (at path $Profile). But how?
Notepad.exe has no support for Shift+Enter.
MS Word understands Shift+Enter, but when I SaveAs .txt, and then examine with Notepad++, I see a plain CR-LF (meaning \r\n, 0x0d 0x0a).
Notepad++ menu Edit → Character Panel enables me to insert special ASCII characters into my .txt / .ps1 file, such as 0x0b called VT (for "vertical tab"). But despite some claims on websites, VT is not behaving like a Soft Return when I use it in my function prompt ... profile .ps1 file (I also run the profile .ps1 script to retest).
Can the prompt I want be established by a profile .ps1 script?
The PowerShell equivalent of your batch-prompt is:
function prompt { "[$(Get-Location)\]`r`n$("+"*(Get-Location -Stack).Count)>" }
#`r`n is just a shorter way of writing [System.Environment]::NewLine
Add it to the profile to suits your needs:
AllUsersAllHosts:
C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1
AllUsersPowerShell:
C:\Windows\System32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1
AllUsersISE:
C:\Windows\System32\WindowsPowerShell\v1.0\Microsoft.PowerShellISE_profile.ps1
CurrentUserAllHosts:
C:\Users\username\Documents\WindowsPowerShell\profile.ps1
CurrentUserPowerShell:
C:\Users\username\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
CurrentUserISE:
C:\Users\username\Documents\WindowsPowerShell\Microsoft.PowerShellISE_profile.ps1

Using vim as default editor for matlab

I want to use gvim as the standard editor for Matlab. It used to work on Linux but now I am forced to use windows and I can't seem to figure out how to set the editor such that files are opened in gvim in a new tab.
In the preferences there is a field which allows to pass a command that points to the prefered text editor. That works, but things fail when I try to give additional options, in my case that would be "--remote-tab-silent" to tell gvim to open the file in a running instance in a new tab. More specifically, the following line in the matlab preferences works:
C:\pathtovim\gvim.exe
while this one fails
C:\pathtovim\gvim.exe --remote-tab-silent
A command line opens with the following error message (my own translation from German):
The command ""C:\pathtovim\gvim.exe --remote-tab-silent"" is either spelled incorrectly or could not be found.
My guess is that it has something to do with the additional quotes, I have no idea why the command is issued with quotes, even though in the field I put it without. The follwing commands work when typed into the command line directly:
"C:\pathtovim\gvim.exe"
C:\pathtovim\gvim.exe --remote-tab-silent file.m
and this one fails:
"C:\pathtovim\gvim.exe --remote-tab-silent file.m"
I'd really appreciate any help! Thanks!
I can't find a good way to hack around it through the MATLAB settings; it looks like MATLAB is stupidly expecting the text editor to take only file names as arguments.
I think your best option, is to create a .bat script that simply passes any arguments it receives on to Vim, inserting the --remote-tab-silent.
I.e. create a .bat file with these contents:
"C:\pathtovim\gvim.exe" --remote-tab-silent %*
Then set up your MATLAB preferences to invoke the .bat file rather than Vim.

Windows notepad not supporting newline character '\n'

From my iPhone application I'm outputting data from text to a file. When opened with windows notepad, the data is all on one line and where there should be a new line a block character is present (showing that it's an unrecognized character or something). When opened with windows wordpad, it displays just fine. Would there be something wrong in my code? I'm simply output '\n' when i want a new line.
NOTE : It's working fine with other editors like textedit, MS Word on mac as well as on windows.
Windows default is to use \r\n as end-of-line marker. Notepad only recognises that, other text editors may know about other line-end styles and render correctly.
EDIT
As VonC answers Notepad had an update (in 2018) where it now can recognize non-Windows end-of-line sequences.
I'm simply output '\n' when i want a new line.
And starting May 2018 (6 years later), you will get a newline!
See "Introducing extended line endings support in Notepad" by Michel Lopez (and his tweet)
For many years, Windows Notepad only supported text documents containing Windows End of Line (EOL) characters - Carriage Return (CR) & Line Feed (LF). This means that Notepad was unable to correctly display the contents of text files created in Unix, Linux and macOS.
Today, we’re excited to announce that we have fixed this issue!
Starting with the current Windows 10 Insider build, Notepad will support Unix/Linux line endings (LF), Macintosh line endings (CR), and Windows Line endings (CRLF) as usual.
New files created within Notepad will use Windows line ending (CRLF) by default, but it will now be possible to view, edit, and print existing files, correctly maintaining the file’s current line ending format.
Also note that the status bar indicates the detected EOL format of the currently open file.
See an .bashrc finally displayed correctly!
This is because \n does not represent a full line break in Windows. Using \n is "the Unix" way of doing line breaks.
On Windows, there are text-editors like Notepad++ which handle both, but Notepad is really dumb in that respect.
I suggest you create a setting in your iPhone application where the user can choose between Windows and Unix line endings - then it's his responsibility :-)
Recently ran into this issue and I was convinced that it was my code which is doing this but turns out Notepad has problems rendering the file in the right format.
How do we fix this?
There is no fix available of this behavior of notepad but here is a list of workarounds that can be performed in order to read the contents correctly.
Workaround
You can use Windows WordPad to open the file or just paste the contents of the file into WordPad and back into Notepad . This should fix the problem .
You can also use Notepad++ to open the files which is a third-party text reader and can be installed on a windows system.
Microsoft recently (October 2018) announced that Notepad has been fixed in Windows 10 version 1809 so updating your system to windows 10 should resolve this issue (Windows versions before 1809 are impacted)
Microsoft fixed this after 33 years !!! Gee thats a long time to fix the issue aint it ?