Encoding charset to use card suits ASCII characters

I'm coding this game in Linux and I need to know how can I use the following characters in my code:
♠
♣
♦
♥

I can save the .c file in UTF-8 and it works but when I try it in the console using the same encoding, it does not display correctly... Anyway to make it show correctly?

Are you sure your console can handle UTF-8? Konsole appears to output garbage until I switch to UTF-8.

Are you sure you're outputting the correct bytes? Show the board some code so we can check for ourselves. Your topic's title "use card suits ASCII characters" differs from your post (UTF-8 card characters). ASCII, to my knowledge, has no card characters.

Neither UTF-8 or DOS have the card characters. I checked the character map. You can see what the available characters are by going to start > run > "charmap.exe" without the quotes > OK button. Place a check in "Advanced view" if one is not already present then choose "DOS: Region" where region is your region. Only if using Unicode will they be seen (about 4/5 of the way down).

I can't do that as I'm using linux.

The console I use is the GNOME Terminal, I think it supports UTF-8, I selected that encoding for my terminal... I'll change the title...

EDIT: It seems I can't edit the title...

You might be able to use Unicode characters. See this: http://forum.java.sun.com/thread.jsp...sageID=3033440

That's a thread about Java, but the same principles apply. See this page for information about using Unicode in C: http://cprogramming.com/tutorial/unicode.html

Alternatively, you could just use S, C, D, and H for the suits on systems that don't support the non-Unicode versions that you'd use on DOS systems; or you could just use S, C, D, and H all of the time.

In C++ with Windows:

static_cast<char>(5);
static_cast<char>(4);
static_cast<char>(3);
static_cast<char>(6);

Quote:

---

Originally Posted by ulillillia

Neither UTF-8 ... have the card characters. I checked the character map.

---

You did? Did you check this character map? U+2660 through U+2667 are all playing card symbols. These were the characters I tested printing before I posted originally.
I'm not exactly sure how charmap decides which characters to display, but it only shows a very small subset of Unicode.

dwks: I saw that article when I google'd for the unicode for card symbols today. One post seems to say they're 226x, which appears to be math symbols... slight typo I think.

Here's what I ran a test with, which, on Linux using Konsole set to UTF-8 works. A kludge, no doubt, for a single character.

Code:

---

#include <stdio.h>

int main()
{
        char unicode[4] = {0};
        // Encode U+2600 as UTF-8
        unicode[0] = 0xE2;
        unicode[1] = 0x99;
        unicode[2] = 0xA0;
       
        // Prints a spade if you have the font for it, and you're unicode.
        // Prints garbage otherwise.
        printf("%s\n", unicode);

        // Added this part during this post.
        // Works, but I only get the black characters.
        // That, and according to gcc's warnings, \u only works for C99 and C++.
        printf("\u2660 \u2661 \u2662 \u2663 \u2664 \u2665 \u2666 \u2667\n");
       
        return 0;
}

---

Quote:

---

Originally Posted by Cactus_Hugger

You did? Did you check this character map? U+2660 through U+2667 are all playing card symbols. These were the characters I tested printing before I posted originally.
I'm not exactly sure how charmap decides which characters to display, but it only shows a very small subset of Unicode.

---

Windows Character Map, at least in Windows XP, has the option to choose the group of characters. Using "Windows: Western" and "DOS: United States" does not contain these card characters. These are the 8-bit characters used. By choosing "Unicode" from the list, you'll see the card characters 4/5 of the way down from the top, but since these are only available on the 16-bit character set, either 16-bit strings are needed or some special notation.

@Cactus_Hugger
Your example worked fine, however, I have a few questions...

a) instead of this:

Code:

---

char unicode[4] = {0};
// Encode U+2600 as UTF-8
unicode[0] = 0xE2;
unicode[1] = 0x99;
unicode[2] = 0xA0;

---

Is it possible to add it to one line only?

b) I normally use ISO-8859-15 on my .c files and on the GNOME Terminal because I need to use letters like &#231; &#225; &#245; &#233; &#234;, etc... How can I use those letters with UTF-8? Is it possible? If not, how can I use both those letters and the card suits symbols?

Quote:

---

Originally Posted by Nazgulled

@Cactus_Hugger
Your example worked fine, however, I have a few questions...

a) instead of this:

Code:

---

char unicode[4] = {0};
// Encode U+2600 as UTF-8
unicode[0] = 0xE2;
unicode[1] = 0x99;
unicode[2] = 0xA0;

---

Is it possible to add it to one line only?

---

Sure.

Code:

---

char unicode[] = {0xe2, 0x99, 0xa0, 0};

---

You can add the 4 in if you want, but it's optional.

Quote:

---

b) I normally use ISO-8859-15 on my .c files and on the GNOME Terminal because I need to use letters like &#231; &#225; &#245; &#233; &#234;, etc... How can I use those letters with UTF-8? Is it possible? If not, how can I use both those letters and the card suits symbols?

---

You'd have to check a UTF-8 chart.

Here's what I have now:

Code:

---

#include <stdio.h>

int main(void) {
        // Card suits in black
        char clubs[]    = {0xE2, 0x99, 0xA7, 0};
        char diamonds[] = {0xE2, 0x99, 0xA2, 0};
        char hearts[]  = {0xE2, 0x99, 0xA1, 0};
        char spades[]  = {0xE2, 0x99, 0xA4, 0};
       
        printf("\n&#37;s\n%s\n%s\n%s\n", clubs, diamonds, hearts, spades);
        printf("\n&#225;&#224;&#226;&#227;&#233;&#232;&#234;&#237;&#236;&#238;ĩ&#243;&#242;&#244;&#245;&#250;&#249;&#251;ũ&#231;\n\n");
        printf("\n&#193;&#192;&#194;&#195;&#201;&#200;&#202;&#205;&#204;&#206;Ĩ&#211;&#210;&#212;&#213;&#218;&#217;&#219;Ũ&#199;\n\n");
       
        return 0;
}

---

After setting GNOME Terminal to UTF-8, it works fine and it's simple enough for me to use it on my project. However, and as you can see on the code, there's a couple of printfs to check if I could save .c the file and change the terminal to UTF-8 and have everything I need to be outputted correctly. And it worked fine until another problem.

The thing is, I'm using the ncurses library and the above code in the curses mode outputs garbage in the first and third printfs (which are printws actually), the second one outputs fine, but not the others and I can't have that. I searched a bit and found something about ncursesw and tried to use that on the above code, but wasn't able to make it work.

Any ideas?

Quote:

---

I searched a bit and found something about ncursesw and tried to use that on the above code, but wasn't able to make it work.

---

So you linked with libncursesw.a instead of libncurses.a?

Quote:

---

--enable-widec
The configure script renames the library and (if the --disable-overwrite option is used) puts the header files in a different subdirectory. All of the library names have a "w" appended to them, i.e., instead of

-lncurses

you link with

-lncursesw

You must also define _XOPEN_SOURCE_EXTENDED when compiling for the wide-character library to use the extended (wide-character) functions. The curses.h file which is installed for the wide-character library is designed to be compatible with the normal library's header. Only the size of the WINDOW structure differs, and very few applications require more than a pointer to WINDOWs. If the headers are installed allowing overwrite, the wide-character library's headers should be installed last, to allow applications to be built using either library from the same set of headers.

---

yes, I used -lncursesw in the gcc command...

Well, what happened? Did you get a linker error because you don't have libncursesw.a? Did it compile and link but print weird characters?

If you don't have ncursesw, you can download it: http://www.google.ca/search?q=download+ncursesw

It happened the same as using normal ncurses... the card suits and the é õ and so on chars in capital letters didn't print correctly, the others did. Both of them compile, but both of them outputted the same thing...