We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
IndexProgramming Questions & HelpSyntax Questions › special chars fine on screen but in the console
Page Index Toggle Pages: 1
special chars fine on screen but ? in the console (Read 1721 times)
special chars fine on screen but ? in the console
Oct 10th, 2009, 4:00pm
 
I have saved a text file as UTF-8, and all special characters come out fine when i write them with text (String, x, y) to the screen. But in the console they are shown as question marks, which means some of my methods don't work as they should do. Does anybody know what could be the reason?
Re: special chars fine on screen but ? in the console
Reply #1 - Oct 10th, 2009, 5:53pm
 
Just what you already described: console can't handle those special characters.  The console's generally just for developer feedback...sounds like your program works fine (?)
Re: special chars fine on screen but ? in the console
Reply #2 - Oct 11th, 2009, 2:25am
 
You don't tell us which kind of console. Java console? WinXP? MacOS? Other Unix?
I think on the last two at least you can set the encoding.
Re: special chars fine on screen but ? in the console
Reply #3 - Oct 11th, 2009, 5:46am
 
Just working in Processing on a Mac. My program works partially, its fine drawing characters to the screen from the loaded textfile. But when i use them in a method to compare them to other chars it doesn't recognise them and leaves them out completely. Which makes it work only half as well as it should do. Is the solution then to integrate my processing sketches into another platform? And which is best?
Re: special chars fine on screen but ? in the console
Reply #4 - Oct 11th, 2009, 5:50pm
 
Odd, seems to work here:

Quote:
String test="é";
char testchar='é';
if (test.equals("é")) println("String worked");
if (testchar == 'é') println("Char worked");
exit();
Re: special chars fine on screen but ? in the console
Reply #5 - Oct 11th, 2009, 5:55pm
 
Oh, I think I see what's happening.  The default save setting for TextEdit is "Western (Mac OS Roman)."  You may need to re-save your .txt file as "UTF-8."  My loadstrings() check failed until I did that.

--Ben
Re: special chars fine on screen but ? in the console
Reply #6 - Oct 12th, 2009, 3:05pm
 
I saved my files in jedit with UTF8 encoding. Yes,  the processing console recognizes the more common diacritis, like accents é, á  and ü for example, but less common ones, from czech, turkish or polish it doesn't, e.g. ă, ğ, ė, ż, ã, ñ, õ. Why is that?
Re: special chars fine on screen but ? in the console
Reply #7 - Oct 12th, 2009, 7:28pm
 
oh, those characters don't seem to be supported in UTF-8.  When I try to save a file with that string, "ă, ğ, ė, ż, ã, ñ, õ," it requires UTF-16...
Re: special chars fine on screen but ? in the console
Reply #8 - Oct 13th, 2009, 6:12am
 
ben_hem wrote on Oct 12th, 2009, 7:28pm:
oh, those characters don't seem to be supported in UTF-8.

I doubt it... Smiley It might be a quirk from your editor.
Re: special chars fine on screen but ? in the console
Reply #9 - Oct 13th, 2009, 10:56am
 
Stranger and stranger:

I should have been more precise, TextEdit (OSX default text editor) does save the string: "ă, ğ, ė, ż, ã, ñ, õ" in UTF-8 ... but, as: "ƒÉ, ƒü, ƒó, ≈º, √£, √±, √µ".

When I load that garbled version and check it against the proper version in P5, the strings *do* register as equal, surprisingly...

So, from wiki article on "UTF-8" :
Quote:
UTF-8 often takes more space than an encoding made for one or a few languages. Latin letters with diacritics and characters from other alphabetic scripts typically take one byte per character in the appropriate multi-byte encoding but take two in UTF-8.


I think what this means is that when a text editor saves those characters, it's actually always saving that garbled version (each special char requires a char-pair) and then parsing it back on load.  TextEdit doesn't parse back.  But as long as you use string.equals() and not == or something, it should work.  Console output in P5 is still limited, but it doesn't affect functioning.

edit -- OSX console, which contains the output from P5 as well, also has ? marks.
Page Index Toggle Pages: 1