We try to convert the source files of a TCL/TK application to UTF-8, because this is the default charset of the plattforms we use for development (Linux and OSX).
Our problem is now that windows uses "cp1252" as system encoding, and because of this displays labels and buttons with (for example) german umlauts wrong.
The only solution we found yet would be to add "-encoding UTF-8" to all "wish" calls and "source" commands.
(There is also "encoding system UTF-8", but the documentation says that you shouldn't use it because of problems with system calls)
Is there a way to tell TCL that it should use UTF-8 as default encoding for all source files, or maybe another solution for this problem?
The solution suggested in the TCL chat:
Create and use your own versions of "open" und "source" (like "my_open" and "my_source") which then call the original commands with "-encoding utf-8"
Related
Both in Cygwin (minnty) and Git Bash I have set font to pl_PL/ISO-8859-2. It results (in both cases) in:
$ locale
LANG=pl_PL.ISO-8859-2
LC_CTYPE="pl_PL.ISO-8859-2"
LC_NUMERIC="pl_PL.ISO-8859-2"
LC_TIME="pl_PL.ISO-8859-2"
LC_COLLATE="pl_PL.ISO-8859-2"
LC_MONETARY="pl_PL.ISO-8859-2"
LC_MESSAGES="pl_PL.ISO-8859-2"
LC_ALL=
But in Cygwin, when I display Git commits’ comments - diacritical characters are not displayed properly (regardless of the font I use - e.g., Consolas, Lucida Console). The same commits’ comments are properly displayed in Git Bash. The comments have been UTF-8 encoded while saving.
I didn’t have this issue before, but once I reinstalled the OS now it occurs. Unfortunately I can’t tell what I have done differently.
Is it possible to fix that? I use Windows 7 32-bit.
In general, you're better off using UTF-8 and setting your locale to pl_PL.UTF-8. UTF-8 is capable of supporting all languages, including Polish. If that doesn't work, then there's a different issue which should be addressed independently. Git by default uses UTF-8 in most cases, and so does pretty much everything else on a Unix or Cygwin system.
If you really, absolutely insist upon using ISO-8859-2, then you'll need to set the i18n.logOutputEncoding to ISO-8859-2 so that it will render things in the proper character set. Note that if you have this set in one Git configuration (the Git Bash one) and not in the other (the Cygwin one), that will explain why you're seeing different behavior.
You may also want to set your system code page to UTF-8 by using chcp 65001 in a CMD window.
I have two notepad files.
One created in Windows 7 and another in Windows 10.
But both have different size (even same content) and somehow different 'format' that make my other program read both differently.
How do I check the differences? How can I make notepad that same regardless the Windows version?
Both file just have the word DATA
It looks like Encoding.
Windows 7 is saving as ANSI, while 10 is saving as Unicode (UCS-2 LE BOM), probably.
May help you: Changing the Default Ansi to UTF-8
I haven't found any answer or clarification on this subject in the internet.
I have a very old program (over a decade old) for windows (portable executable exe). It displays data in my language (hebrew) and uses cp1255 encoding (old, today is obsolete due to UTF-8). now, the thing is - it only displays data on specific types of computers, so long I've only been able to run it on:
x32 bit windows 7
My question is whether I can get it to work on x64 bit windows 7 encoding. On the x64, the program actually launches, but it displays a whole lot of question marks and jibrish instead of hebrew. I conclude this is due to the encoding.
Sidenote: The program loads info to display from unidentified files (their extensions are fabricated and I have tried to recover and types but so long not very successful). They too, have data in hebrew using the old CP1255 encoding and also has some machine code in it (opened it with a notepad, weird symbols along with text)
I've come up with 2 possible solutions for now:
Either somehow make the program support UTF-8, translate the exe to UTF-8 (probably requires special programs or reverse engineering)
OR
make my OS support the old encoding (cp1255 / windows-1255)
I haven't been able to execute either of them.
If you have any more solutions to tackle this problem or know how to solve it with one of the possible solutions, I'd be glad!
-yuval.
Edit: By the way - I have the language installed. I am using hebrew as one of the keyboard languages and I surf the web with it.
You may have already gone down this path, but have you given a try to running in compatibility mode on your x64 machine? Right click on the executable or shortcut, open properties, and go to the compatibility tab. There is a troubleshooter there that could help.
Not entirely sure how to best explain, but would it be possible to use certain Unicode symbols, not supported by the Windows Command Prompt, in Git for Windows? Preferably without using Cygwin.
The git-bash.exe packaged with git-for-windows does support those unicode characters. (it uses minTTY)
But the cmd.exe console does not does (as pointed out by kostix in the comments) with a Unicode (TrueType) font set, although those ones (✔', '✖', '★') are not included in the TrueType fond like Lucida Consola.
when I try to install something over Putty, it looks like this:
so really buggy :).
Has anyone a suggestion for this?
It's probably something to do with UTF-8 handling on different terminal types.
You could try this solution I found on linux.debian.user:
What release of PuTTY are you using? I'm using PuTTY 0.63, which is
the latest release. In this version, the default value for the terminal
type string is xterm. At least it is for me. I have to explicitly change
it to putty, even after setting the remote character set to UTF-8. Make
sure the terminal type string is all lower case. Terminal type strings
are case sensitive. They have to match the terminal type definition in
ncurses. The putty terminal type definition in ncurses can be found in
/usr/share/terminfo/p. You can also try a terminal type string of
xterm-utf8. This terminal type definition in ncurses is found in
/usr/share/terminfo/x. The latest version of PuTTY can be downloaded
here:
http://www.chiark.greenend.org.uk/~sgtatham/putty
https://groups.google.com/forum/#!topic/linux.debian.user/Yy-kQu1RC44
It's indirectly related to UTF-8: the PuTTY developers chose to ignore VT100 line-drawing control sequences when UTF-8 encoding is used. Doing that requires any application that uses line-drawing to do some workaround.
You can work around this by one of these methods:
setting the NCURSES_NO_UTF8_ACS environment variable, as noted in the manual page, or
using a correct terminal description such as putty, which happens to have a special capability U8 defined, telling ncurses the same thing as the environment variable.