Done Working UTF-8 Support

[krischik]

Yes, a tall order. I develop a lot of Java software with lots of UTF-8 console output. Same goes for subversion when codepage 65001 is active.

But output looks never looks right.

So my suggestion: Please add UTF-8 output to your

Martin

 

[Charles Dye]

Are you aware of OPTION //UTF8OUTPUT=YES ?

 

[krischik]

Let me check. Does it make a difference when it is set in the TCMD.INI?

[4NT]
…
UTF8Output=yes
…

Martin

 

[Steve Fabian]

TCMD.INI is handled when you start a new instance of TCC.EXE. However, since you can use
option //UnicodeOutput=yes
and
option //UnicodeOutput=no
at any time (e.g., in a batch file) it can probably be done at any time, too. Test it!

 

[nickles]

Try TYPE with a file containing Unicode (UTF-8) characters. OPTION //Unicode=Yes has no influence on the (incorrect) output. However: CHCP 65001 will do what you want.

BUT: Try this (with CHCP 65001 set) on the TCC command line: REN test töst

So, here the input is the problem. In conclusion: No working Unicode support in TCC (I haven't tested this with TCmd as I don't use it...).

 

[Charles Dye]

Try TYPE with a file containing Unicode (UTF-8) characters.

Hence UTYPE in TextUtils.

 

[nickles]

That would solve the input problem for TYPE (but not for any other tools that I use frequently), but not the output problem...

 

[AnrDaemon]

Try TYPE with a file containing Unicode (UTF-8) characters. OPTION //Unicode=Yes has no influence on the (incorrect) output. However: CHCP 65001 will do what you want.

BUT: Try this (with CHCP 65001 set) on the TCC command line: REN test töst

So, here the input is the problem. In conclusion: No working Unicode support in TCC (I haven't tested this with TCmd as I don't use it...).

Internal UNICODE support ("OPTION //Unicode=Yes") of application has very little relevance to the UNICODE support of the terminal you're working in ("chcp 65001").

 

[krischik]

Hence UTYPE in TextUtils.

But that won't help for Maven and Subversion output. But it does show that there is still a problem with Unicode output in TakeCommand. And so my Suggestion for JP still stands: Do test unicode output more thorough and fix all bugs encountered.

 

[rconn]

So, here the input is the problem. In conclusion: No working Unicode support in TCC (I haven't tested this with TCmd as I don't use it...).

That's a bit of a misstatement. TCMD and TCC fully support Unicode the (only) way Windows supports it, as UTF-16. The Windows file system and internal Windows APIs do not support UTF-8. The UTF-8 support that TCC does include -- which is way more than CMD (i.e., none at all) -- requires converting everything before passing it to & from Windows. Including UTF-8 support everywhere would (1) substantially slow down TCC and TCMD for everybody, including the 99.99% who never use UTF-8, and (2) require several thousand lines of additional code (probably in the 10,000-20,000 range).

So it comes down to priorities -- would all the users rather have no new features & slower execution in the next version of TCC / TCMD in exchange for full UTF-8 support?

 

[krischik]

Including UTF-8 support everywhere would

Can't speak for others but I don't need UTF-8 everywhere. I just need UTF-8 console output to print out properly.

 

[nickles]

And this:

BUT: Try this (with CHCP 65001 set) on the TCC command line: REN test töst