BTM file encoding

[Roedy]

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?

 

[Charles Dye]

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.

 

[vefatica]

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.

 

[vefatica]

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.

I took Roedy to mean when he RUNS the batch files.

 

[Charles Dye]

This, or something similar, was reported three weeks ago. See the thread: 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.)

 

[vefatica]

Ack; I'd forgotten that one. (Saving batch files as UTF-16 is still a workaround, though.)

That doesn't bring back compatibility with CMD (and a long history).

 

[Charles Dye]

That doesn't bring back compatibility with CMD (and a long history).

I quite agree. A workaround, not a fix.

 

[Charles Dye]

Or else add

CHCP 437

to your TCSTART.BTM file. That'd be another workaround.

 

[vefatica]

Or else add

CHCP 437

to your TCSTART.BTM file. That'd be another workaround.

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.

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
¡¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ

 

[Alpengreis]

@vefatica

Vince, what is, if you make your test above with the TERMINAL font (in TCC, NOT in TCMD)? Would be interesting to know (if you have the time for) ...

Regards

 

[Charles Dye]

Vince, what is, if you make your test above with the TERMINAL font (in TCC, NOT in TCMD)? Would be interesting to know (if you have the time for) ...

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.

 

[vefatica]

@vefatica

Vince, what is, if you make your test above with the TERMINAL font (in TCC, NOT in TCMD)? Would be interesting to know (if you have the time for) ...

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).

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:\>

 

[Alpengreis]

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.

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 :-)

 

[Roedy]

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