In the olden days BTM files were encoded with IBM437. When I upgraded, the encoding apparently changed. My block characters no longer display properly. What in the new encoding?
Have you checked that your current font actually includes the block graphics characters? Not all do.
Character encoding is between you, your text editor, and the CHCP command. If mojibake is an issue in your batch files, I suggest saving them as UTF-16.
Character encoding is between you, your text editor, and the CHCP command. If mojibake is an issue in your batch files, I suggest saving them as UTF-16.
This, or something similar, was reported three weeks ago. See the thread: https://jpsoft.com/forums/threads/display-text-same-as-in-cmd.7311/
https://jpsoft.com/forums/threads/display-text-same-as-in-cmd.7311/
In a nutshell, TYPE, ECHO, ... are not using the console output code page (typically 437). Rex has not commented on the issue.
https://jpsoft.com/forums/threads/display-text-same-as-in-cmd.7311/
In a nutshell, TYPE, ECHO, ... are not using the console output code page (typically 437). Rex has not commented on the issue.
Ack; I'd forgotten that one. (Saving batch files as UTF-16 is still a workaround, though.)
I don't think that helps. Here, 437 is the console output CP, and I can't see 437's upper half correctly. Compare TYPE in v16 and v19.
Code:
v:\> ver & chcp 437 & type 437.txt
TCC 16.03.55 Windows 7 [Version 6.1.7601]
Active code page: 437
íóúñѪº¿⌐¬½¼¡«»░▒▓│┤╡╢╖╕╣║╗╝╜╛┐└┴┬├─┼╞╟╚╔╩╦╠═╬╧╨╤╥╙╘╒╓╫╪┘┌█▄▌▐▀αßΓπΣσµτΦΘΩδ∞φε∩≡±≥≤⌠⌡÷≈°∙·√ⁿ²■
v:\> exit
v:\> ver & chcp 437 & type 437.txt
TCC 19.10.51 Windows 7 [Version 6.1.7601]
Active code page: 437
¡¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ
Roedy and Vincent are both correct, and I was wrong. TCC is interpreting OEM text files according to the Windows code page, also miscalled the "ANSI code page", and not per the console code page as they ought.
I apologize for confusing the issue.
It's the same with Terminal (as with Andale Mono, Lucida, and Consolas). All my tests have been with stand-alone TCC. WinDbg reveals that v19 calls MultiByteToWideChar with first argument 3 (CP_THREAD_ACP) while v16 calls the same function with first argument 437 (probably from GetConsoleOutputCP).
Code:
v:\> ver & echo %_fontinfo & chcp 437 & type 437.txt
TCC 16.03.55 Windows 7 [Version 6.1.7601]
2 8 12 400 Terminal
Active code page: 437
íóúñѪº¿⌐¬½¼¡«»░▒▓│┤╡╢╖╕╣║╗╝╜╛┐└┴┬├─┼╞╟╚╔╩╦╠═╬╧╨╤╥╙╘╒╓╫╪┘┌█▄▌▐▀αßΓπΣσµτΦΘΩδ∞φε∩≡±≥≤⌠⌡÷≈°∙·√ⁿ²■
v:\> exit
v:\> ver & echo %_fontinfo & chcp 437 & type 437.txt
TCC 19.10.51 Windows 7 [Version 6.1.7601]
2 8 12 400 Terminal
Active code page: 437
¡¢£☼¥▌§"cª«¬-r_°±²3'µ¶·,1º»¼½_¿AAAAÄÅÆÇEÉEEIIIIDÑOOOOÖxOUUUÜY_ßàáâaäåæçèéêëìíîïdñòóôoö÷oùúûüy_ÿ
v:\>No need to apologize - codepages are evil - not just related to TCC/TCMD. I had and have frequently problems too - but not so frequently that I could not forget the important things about it :-)
So, in summary, the encoding TCC echo is using now is windows-1252, was IBM437.
1252 is 8-bit with most of the high characters used by accented letters. There is not much to use
for decoration. There are some raised dots, << >>, It has 5 unassigned slots.
http://mindprod.comjgloss/encoding/windows-1252.html
1252 is 8-bit with most of the high characters used by accented letters. There is not much to use
for decoration. There are some raised dots, << >>, It has 5 unassigned slots.
http://mindprod.comjgloss/encoding/windows-1252.html
Similar threads
