Professional Web Applications Themes

Compiling for the terminal and text encoding... - Mac Programming

In article <2004072322251478971%sealfinsealfincom>, Mark Bishop <com> wrote:   I don't understand what you mean by "losing" meeroh -- If this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist>...

  1. #1

    Default Re: Compiling for the terminal and text encoding...

    In article <2004072322251478971%sealfinsealfincom>,
    Mark Bishop <com> wrote:
     

    I don't understand what you mean by "losing"

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

  2. #2

    Default Compiling for the terminal and text encoding...

    Just wondered if somebody can suggest a quick fix for this; I'm
    compiling an app for the Terminal in Xcode, and I'm losing a few of the
    non-US characters I require (particularly the '' symbol); I'm just
    wondering how and where I should change the text encoding of the
    files/project so they'll show up correctly...

    Thanks,

    Mark

    Mark Guest

  3. #3

    Default Re: Compiling for the terminal and text encoding...

    On 2004-07-23 22:41:06 +0100, Miro Jurisic <org> said:
     
    >
    > I don't understand what you mean by "losing"
    >
    > meeroh[/ref]

    By "losing", I mean that running from Xcode any instances of '' in a
    string are replaced with a character code, "\234" or similar if I
    remember correctly, whilst running from Terminal.app, the instances of
    '' are replaced with '?' instead (this occurs in the output of
    printf() and friends, including scanf().)

    Thanks,

    Mark

    Mark Guest

  4. #4

    Default Re: Compiling for the terminal and text encoding...

    In article <2004072322480212805%sealfinsealfincom>,
    Mark Bishop <com> wrote:
     
    > >
    > > I don't understand what you mean by "losing"[/ref]
    >
    > By "losing", I mean that running from Xcode any instances of '' in a
    > string are replaced with a character code, "\234" or similar if I
    > remember correctly, whilst running from Terminal.app, the instances of
    > '' are replaced with '?' instead (this occurs in the output of
    > printf() and friends, including scanf().)[/ref]

    Sounds like you are printing the character in MacRoman rather than UTF-8, which
    probably means that your source is saved in MacRoman encoding. I don't know
    where to change that in Xcode though

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

  5. #5

    Default Re: Compiling for the terminal and text encoding...

    On Fri, 23 Jul 2004, Mark Bishop wrote:
     
    >>
    >> I don't understand what you mean by "losing"
    >>
    >> meeroh[/ref]
    >
    > By "losing", I mean that running from Xcode any instances of '' in a string
    > are replaced with a character code, "\234" or similar if I remember
    > correctly, whilst running from Terminal.app, the instances of '' are
    > replaced with '?' instead (this occurs in the output of printf() and friends,
    > including scanf().)[/ref]

    I'm not sure if you can reliably put non-ASCII characters into C constant
    strings. That said, you can change your file's encoding by getting info on
    it in Xcode. The file's encoding should match the Terminal's encoding
    setting, which you can view in the Terminal Settings panel.
    Michael Guest

  6. #6

    Default Re: Compiling for the terminal and text encoding...

    Michael Ash wrote: 

    i've been putting utf-8 chars in my constant C strings for a long time
    now. for example, "\xC2\xA9" for the copyright symbol. if needed in
    cocoa, [NSString stringWithUTF8String:] can do the conversion from
    constant C string to NSString. There's probably something similar you
    could use to make a CFString. can anybody think of any problems with
    that method?
     

    that i would not do. if you ever transfer that file to some other
    computer, the file's encoding probably isn't going to follow along. any
    other ide will probably have different ways of specifying chts
    anyhow, if such a thing is even supported in the new environment. much
    better to stick with straight ascii chars in source files for maximum
    portability across time and space.
    Jhnny Guest

  7. #7

    Default Re: Compiling for the terminal and text encoding...

    In article <mit.edu>,
    Miro Jurisic <org> wrote:
     
    > >
    > > By "losing", I mean that running from Xcode any instances of '' in a
    > > string are replaced with a character code, "\234" or similar if I
    > > remember correctly, whilst running from Terminal.app, the instances of
    > > '' are replaced with '?' instead (this occurs in the output of
    > > printf() and friends, including scanf().)[/ref]
    >
    > Sounds like you are printing the character in MacRoman rather than
    > UTF-8, which probably means that your source is saved in MacRoman
    > encoding. I don't know where to change that in Xcode though[/ref]

    I think this will work if Mark ensures that the text encoding of his
    source files in Xcode matches the encoding Terminal uses to display text.

    To set the encoding for a source file in Xcode, select the file in
    Xcode, press command-I, go to the General tab, and change the File
    Encoding popup. To change the default encoding Xcode uses, open its
    preferences, go to the Text Editing pane, and change the Default
    Encoding popup.

    Step two is to make sure Terminal is using the same encoding. Open
    Terminal, go to Terminal->Window Settings, select the Display item in
    the popup menu, and change the Character Set Encoding popup. To change
    the setting for all Terminal windows and not just the current one, click
    the Use Settings as Defaults button.

    Hope this helps,
    Eric

    --
    Eric Albert stanford.edu
    http://rescomp.stanford.edu/~ejalbert/
    Eric Guest

  8. #8

    Default Re: Compiling for the terminal and text encoding...

    On 2004-07-24 08:57:51 +0100, Eric Albert <stanford.edu> said:
     
    >>
    >> Sounds like you are printing the character in MacRoman rather than
    >> UTF-8, which probably means that your source is saved in MacRoman
    >> encoding. I don't know where to change that in Xcode though[/ref]
    >
    > I think this will work if Mark ensures that the text encoding of his
    > source files in Xcode matches the encoding Terminal uses to display
    > text.
    >
    > To set the encoding for a source file in Xcode, select the file in
    > Xcode, press command-I, go to the General tab, and change the File
    > Encoding popup. To change the default encoding Xcode uses, open its
    > preferences, go to the Text Editing pane, and change the Default
    > Encoding popup.
    >
    > Step two is to make sure Terminal is using the same encoding. Open
    > Terminal, go to Terminal->Window Settings, select the Display item in
    > the popup menu, and change the Character Set Encoding popup. To change
    > the setting for all Terminal windows and not just the current one,
    > click the Use Settings as Defaults button.
    >
    > Hope this helps,
    > Eric[/ref]

    Thanks! This seems to have worked for a quick and dirty test...

    Thanks again,

    Mark

    Mark Guest

  9. #9

    Default Re: Compiling for the terminal and text encoding...

    On Fri, 23 Jul 2004, =?ISO-8859-1?Q?J=F8hnny_F=E4v=F2r=EDt=EA_=28it_means_=22halo= 2C_then_resonate=22=29?= wrote:
     
    >
    > i've been putting utf-8 chars in my constant C strings for a long time
    > now. for example, "\xC2\xA9" for the copyright symbol. if needed in
    > cocoa, [NSString stringWithUTF8String:] can do the conversion from
    > constant C string to NSString. There's probably something similar you
    > could use to make a CFString. can anybody think of any problems with
    > that method?[/ref]

    I didn't know about that approach. It seems perfectly reasonable to me. I
    was thinking of typing them directly into the C string instead of using
    escapes like that.
     
    >
    > that i would not do. if you ever transfer that file to some other
    > computer, the file's encoding probably isn't going to follow along. any
    > other ide will probably have different ways of specifying chts
    > anyhow, if such a thing is even supported in the new environment. much
    > better to stick with straight ascii chars in source files for maximum
    > portability across time and space.[/ref]

    I agree completely.
    Michael Guest

  10. #10

    Default Re: Compiling for the terminal and text encoding...

    Michael Ash wrote: 
    >
    > I didn't know about that approach. It seems perfectly reasonable to
    > me. I was thinking of typing them directly into the C string instead
    > of using escapes like that.[/ref]

    the caveat is that you have to use them in contexts where utf-8 strings
    are allowed, of course. in my experience, that's been pretty much
    everywhere. conversion to NSStrings works for anything in my user
    interface code. i read and write utf-8 text files for various purposes,
    and most tools seem happy with that. i've determined empirically that
    utf-8 strings can be passed to and from the bsd file functions without
    problems. i can't think of anything else that's pertinent.

    i don't directly type the codes into strings, of course. i've got a
    bunch of macros:

    #define UTF8_COPYRIGHT "\xC2\xA9"
    #define UTF8_ELLIPSIS "\xE2\x80\xA6"
    #define UTF8_QUOTE_DOUBLE_CLOSE "\xE2\x80\x9D"
    #define UTF8_QUOTE_DOUBLE_OPEN "\xE2\x80\x9C"
    #define UTF8_QUOTE_SINGLE_CLOSE "\xE2\x80\x99"
    #define UTF8_QUOTE_SINGLE_OPEN "\xE2\x80\x98"
    #define UTF8_REGISTERED "\xC2\xAE"
    #define UTF8_TRADEMARK "\xE2\x84\xA2"

    you can find unicode codepoints at www.unicode.org, but i have yet to
    find any utf-8 references. i've got a bunch of code that has to deal
    directly with character conversion anyway, so i wrote myself a utility
    that converts "real" unicode to utf-8. you can build strings like this:

    const char copy[] = "Copyright " UTF8_COPYRIGHT " 1999, The Author";

    i asked earlier, and matt neuberg confirmed that it's not possible to do
    the same with NSString ""-style literals, so C string literals it is.
    Jhnny Guest

  11. #11

    Default Re: Compiling for the terminal and text encoding...

    In article <nashville.comcast.net>,
    Jhnny Fvrt (it means "halo, then resonate") <com> wrote:
     

    FWIW I use the localization mechanism to handle this; the code is localized (as
    it should be), I use the key of "Copyright (c) 1999" and then give that key the
    value containing the real (c) character in my English.lproj string table.

    meeroh

    --
    If this message helped you, consider buying an item
    from my wish list: <http://web.meeroh.org/wishlist>

    Miro Guest

  12. #12

    Default Re: Compiling for the terminal and text encoding...

    On Sat, 24 Jul 2004, =?ISO-8859-1?Q?J=F8hnny_F=E4v=F2r=EDt=EA_=28it_means_=22halo= 2C_then_resonate=22=29?= wrote:
     

    Since HFS+ and Mac OS X uses UTF-8 as its official filename text encoding,
    it's not at all surprising that it works. I don't know about other unix
    systems, but as long as they don't destroy 8-bit characters in filenames,
    it should at least preserve the correct name, if not display it correctly.
    Michael Guest

Similar Threads

  1. XML text encoding
    By Aaron Brady in forum Macromedia Flash Data Integration
    Replies: 0
    Last Post: August 2nd, 08:32 PM
  2. Email text encoding
    By Jan Eden in forum PERL Beginners
    Replies: 1
    Last Post: February 11th, 03:30 PM
  3. Text encoding reversal.
    By Daniel Staal in forum PERL Beginners
    Replies: 2
    Last Post: October 18th, 09:49 PM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139