I print messages with diacritics in my console application. I tried to set multiple encoding commonly used for my language (CZECH) but non of them is giving me the desired result. I tried UTF-8, Windows(CP1250), ISO 8859-2...
Is there a way how to force console to use some specific encoding?
Or at least where can I find which encoding does my console use?
Thanks in advance.
EDIT: Using Windows 7 - basic command line console ( cmd.exe )
To display the current codepage in cmd.exe:
chcp
To change the current codepage, e.g., to CP-1250:
chcp 1250
By default, the Windows console uses the OEM encoding. There are three encodings for APIs in Windows OEM, ANSI and Unicode. CMD.exe when normally executed uses OEM.
UTF8 seems to be possible, but needs
starting the console with "cmd /u" (create a shortcut)
setting the codepage to chcp 65001
choosing a unicode capable font (e.g. Consolas 20) in the settings of the shortcut
Related
I've had trouble using Julia in Windows Terminal for the last few releases because the ANSI escapes refuse to render properly unless I enable Legacy Console Mode which helps in CMD prompts, but not in Windows Terminal.
When launched in Terminal, it looks like this:
When launched with --color=no, it looks like this:
Which is marginally more useful, but both the inputs and outputs are muddled by the ANSI escapes, which makes the REPL effectively useless.
My workaround has been to enable the "Legacy Console" and use an alias to launch julia in a separate CMD-based window when I need REPL functionality, but this is disruptive.
I have tried various combinations of (multiple releases of) Windows Terminal (stable and dev), Powershell (stable and dev), and Legacy Console mode. There must be a configuration issue on my machine that I just can't nail down because no one else seems to have this issue.
What am I missing?
Can you file this over at https://github.com/microsoft/terminal/issues?
By all accounts, this should work. Seeing the literal escapes in the buffer like that makes me think that Julia isn't enabling ENABLE_VIRTUAL_TERMINAL_PROCESSING, which they would need for escape sequences to work. Though, if you're on a version of julia from 2021, I would presume that they're aware of that and would be setting that mode by now. (That flag was added in like, 2016)
Hopefully we can help diagnose more over at the Terminal repo ☺️
I am having trouble read my csv file containing simplified Chinese character into my r. I have tried the encoding=utf-8,gb18130,gb2130 etc. The Chinese character could be not displayed.
I also tried change the encoding by excel to utf8 csv, no luck.
I also
tried using Chinese windows and set the locale to China. No luck.
After I change to Chinese windows. The excel can open my csv (English
windows cannot open it correctly). The r studio can open it in the
View() but the R console console could not read my csv even if I
reinstall the r as Chinese version.
I tried the Ubuntu, Ubuntu could not even read my csv at all. At least in Windows, the R studio can read my data well.
I tried google sheet. But my file is so big that Google sheet would
not even open it
I tired Cals in Ubuntu and convert it GB* since GB is
working fine in Windows R studio. No luck. And it takes more than 10
minutes to convert my 200Mb-750Mb data to gb18013
The Ubuntu use UTF-8 as default Chinese Encoding. So you should encode it as UTF-8 instead GB18130 or other GB starting encoding.
(1) Download Open Office (free and fast to install, have have higher
file size than Cals in Ubuntu).
(2) Detect your CSV encoding. Simply open your csv using Open office and choose an encoding method that display your Chinese character.
(3) Save your csv to the correct encoding according to your
operation system. Default Windows encoding is GBK for Chinese and Ubuntu is UTF8.
This should solve your file size problem and encoding problem. You do not even have to force the encoding. Normal read.csv would work.
I moved a text file from windows to unix. The content in windows file had some special characters like ®,ä which I needed. However after moving it to linux, all my special characters where prepended by Ã. For example if the string was äbcd# it was converted to ÃabcdÃ#. Also some special characters were totally replaced by either - or `. Please let me know how can I protect my special characters from being modified or corrupted.
Update1:
I tried using binary transfer in WinScp. I am still getting the same problem.
Update2:
I tried using dos2unix. It also dint work either.
The problem is caused by the fact that Windows and Unix use different text encoding. Your file on Windows is probably in an ANSI encoding (not ASCII). Unix (Linux?) expects most likely UTF-8.
In notepad save your file in UTF-8 format. Then run the file through dos2unix to fix the line breaks.
Is there some way to access the Windows version of a helpfile on a Linux computer within R?
I write a decent amount of R code on my Linux machine, but I do have to make sure the code will run on a Windows machine for collaborators.
I've been burned a number of times by reading a help file on my Linux machine, writing my code, and then spending hours wondering why it's not working on the Windows machine until I check the helpfile on that machine and realise that it is different to the one on the Linux machine.
It'll usually have a "NOTE: On Windows, xxxx behaves differently...", and I wish I knew that while I was writing the code on my Linux machine!
I do realise that many help files are system-specific (for example ?system), but sometimes I would like to read the Windows version on my Linux computer. Today I found myself wanting to read ?windows but had to boot up my Windows laptop just to read that helpfile, because that function isn't available on Linux and so there's no help file.
cheers.
You can always look at the source which gives you clear conditionals -- this is from man/system.Rd:
#ifdef windows
Only double quotes are allowed on Windows: see the examples. (Note: a
Windows path name cannot contain a double quote, so we do not need to
worry about escaping embedded quotes.)
[...]
#endif
#ifdef unix
Unix-alikes pass the command line to a shell (normally \file{/bin/sh},
and POSIX requires that shell), so \code{command} can be anything the
shell regards as executable, including shell scripts, and it can
contain multiple commands separated by \code{;}.
[...]
#endif
I am sending files from a windows system to a Unix SFTP server using JSCAPE ftp client.
However, I am experiencing the following issue:
When uploading a text file from windows to UNiX, each line of text files transferred contains Control-M characters. I did some search and found out that If I use the "ASCII" transfer mode it should solve the issue. But the Ctrl-M is still appearing on the files.
Can anyone throw some light in this issue?
thanks in advance
FTP supports switching between Binary and ASCII transfer mode and converting data on the fly but SFTP does not support that feature and it always transfers files unchanged (at least for the most popular version 3 of the protocol).
The utility dos2unix can be used to convert files from DOS to Unix.
That's the newline character from windows files showing up on UNIX system.
Convert the line endings prior to uploading or find a different FTP server package that can do it for you.
Some text editors have this functionality built in. For instance, Notepad++
Do you have cygwin? You can use the dos2unix utility.