Original von Amin Negm-Awad
Aber du wirfst immer noch total String und seine Darstellung durcheinander. In deinem String existiert ein Zeichen. Nicht 2 Bytes, nicht 16 Bit der 32 Bit, sondern ein Zeichen. Alle Lösungen, die mehr als ein Zeichen enthalten, sind daher schon falsch.

Dementsprechend musst du ein Zeichen erzeugen. Oder du erzeugst dir den Index als Zahl im Unicode. Zahlen werden nicht in Hochkommata gesetzt. Dann erzeugst du aus dieser Zahl einen String, mit einem Zeichen.

Erschwerend hinzu kommt, dass es auch noch völlig willkürlich dargestellt werden kann.
Aber das ist wieder was Anderes.

Original von gritsch

Original von Amin Negm-Awad[/i
UniChar ist im Prinzip ein int. Das muss

Quellcode

1. unichar kha = 0x0F41; // klein geschrieben!

heißen.

unichar ist das selbe wie UniChar

MacTypes.h

Quellcode

1. File: CarbonCore/MacTypes.h
2. …
3. typedef UInt16 UniChar;

NSString.h

Quellcode

1. typedef unsigned short unichar;

Will er eine Carbon-Funktion nutzen oder NSString?

Original von Amin Negm-Awad

Original von gritsch

Original von Amin Negm-Awad[/i
UniChar ist im Prinzip ein int. Das muss

Quellcode

1. unichar kha = 0x0F41; // klein geschrieben!

heißen.

unichar ist das selbe wie UniChar

MacTypes.h

Quellcode

1. File: CarbonCore/MacTypes.h
2. …
3. typedef UInt16 UniChar;

NSString.h

Quellcode

1. typedef unsigned short unichar;

Will er eine Carbon-Funktion nutzen oder NSString?

ich weis, "unsigned short" bleibt aber "unsigned short" ;-)

Original von gritsch

ich weis,

Ach so, die Doku zu den Formatspecifiern von Cocoa weiß es aber genau:

%C
16-bit Unicode character (unichar), printed by NSLog() as an ASCII character, or, if not an ASCII character, in the octal format \\ddd or the Unicode hexadecimal format \\udddd, where d is a digit[/Quot]

Original von gritsch
"unsigned short" bleibt aber "unsigned short"

Das ist richtig. Da steh aber nicht

Quellcode

1. File: CarbonCore/MacTypes.h
2. …
3. typedef unsigned short UniChar;

Sondern da steht

Quellcode

1. File: CarbonCore/MacTypes.h
2. …
3. typedef UInt16 UniChar;

Original von Amin Negm-Awad

Original von gritsch

ich weis,

Ach so, die Doku zu den Formatspecifiern von Cocoa weiß es aber genau:

%C
16-bit Unicode character (unichar), printed by NSLog() as an ASCII character, or, if not an ASCII character, in the octal format \\ddd or the Unicode hexadecimal format \\udddd, where d is a digit[/Quot]

Original von gritsch
"unsigned short" bleibt aber "unsigned short"

Das ist richtig. Da steh aber nicht

Quellcode

1. File: CarbonCore/MacTypes.h
2. …
3. typedef unsigned short UniChar;

Sondern da steht

Quellcode

1. File: CarbonCore/MacTypes.h
2. …
3. typedef UInt16 UniChar;

genau so steht es in der doku und auch die typedefs sagen genau das selbe: die doku sagt dass es um 16 bit geht (unicode). UniCode ist UInt16 also 16 bit unsigned. Also genau das was die doku zu den Formatspecifiern sagt. Außerdem ist UInt16 auch ein typedef von unsigned short

Original von gritsch

Original von Amin Negm-Awad

Original von gritsch

ich weis,

Ach so, die Doku zu den Formatspecifiern von Cocoa weiß es aber genau:

%C
16-bit Unicode character (unichar), printed by NSLog() as an ASCII character, or, if not an ASCII character, in the octal format \\ddd or the Unicode hexadecimal format \\udddd, where d is a digit[/Quot]

Original von gritsch
"unsigned short" bleibt aber "unsigned short"

Das ist richtig. Da steh aber nicht

Quellcode

1. File: CarbonCore/MacTypes.h
2. …
3. typedef unsigned short UniChar;

Sondern da steht

Quellcode

1. File: CarbonCore/MacTypes.h
2. …
3. typedef UInt16 UniChar;

genau so steht es in der doku und auch die typedefs sagen genau das selbe: die doku sagt dass es um 16 bit geht (unicode). UniCode ist UInt16 also 16 bit unsigned. Also genau das was die doku zu den Formatspecifiern sagt. Außerdem ist UInt16 auch ein typedef von unsigned short

%C nimmt ein 16-Bit-Int und interpretiert ihn so. Das hat nichts damit zu tun, was unsigned short ist. Du kannst da angstfrei einen int übergeben. Mach mal solche Sachen wie &ganzzahl-Variavle und du lernst ganz schnell den Unterschied kennen.

Wie UInt16 derzeit definiert ist,ist unerheblich und Implementierungsdetail. In einer Architektur, bei der unsigned short nicht 16 Bit sind, wird es sicher nicht so definiert sein. UInt16 sind *immer* 16 Bit, unsigned short nur derzeit.

Ich muss dir diese Unterschiede doch hoffentlich nicht erklären. Das steht in jedem C-Anfängerhandbuch.

Original von Amin Negm-Awad

Original von gritsch

Original von Amin Negm-Awad

Original von gritsch

ich weis,

Ach so, die Doku zu den Formatspecifiern von Cocoa weiß es aber genau:

%C
16-bit Unicode character (unichar), printed by NSLog() as an ASCII character, or, if not an ASCII character, in the octal format \\ddd or the Unicode hexadecimal format \\udddd, where d is a digit[/Quot]

Original von gritsch
"unsigned short" bleibt aber "unsigned short"

Das ist richtig. Da steh aber nicht

Quellcode

1. File: CarbonCore/MacTypes.h
2. …
3. typedef unsigned short UniChar;

Sondern da steht

Quellcode

1. File: CarbonCore/MacTypes.h
2. …
3. typedef UInt16 UniChar;

genau so steht es in der doku und auch die typedefs sagen genau das selbe: die doku sagt dass es um 16 bit geht (unicode). UniCode ist UInt16 also 16 bit unsigned. Also genau das was die doku zu den Formatspecifiern sagt. Außerdem ist UInt16 auch ein typedef von unsigned short

%C nimmt ein 16-Bit-Int und interpretiert ihn so. Das hat nichts damit zu tun, was unsigned short ist. Du kannst da angstfrei einen int übergeben. Mach mal solche Sachen wie &ganzzahl-Variavle und du lernst ganz schnell den Unterschied kennen.

Wie UInt16 derzeit definiert ist,ist unerheblich und Implementierungsdetail. In einer Architektur, bei der unsigned short nicht 16 Bit sind, wird es sicher nicht so definiert sein. UInt16 sind *immer* 16 Bit, unsigned short nur derzeit.

Ich muss dir diese Unterschiede doch hoffentlich nicht erklären. Das steht in jedem C-Anfängerhandbuch.

nein, musst du nicht, doch wie du ja richtig schreibst wird ein 16 bit integer verwendet. UInt16 ist ja genau das. Wenn nun short nicht mehr 16 bit sind dann wird UInt16 sicher nicht mehr ein short sein, denn es wird immer noch 16 bit sein (wie der name schon sagt). Folglich ist UniChar immer noch korrekt. Man kann also schreiben was man will: unichar, UniChar, UInt16 oder auch MyUUUUNNNIIICCCHHHAAARR (typedef MyUUUUNNNIIICCCHHHAAARR UInt16; )

btw: das ist heute schon der zweite thread mit uns - wir verdienen wohl zuviel geld dass wir soviel zeit zum plaudern haben ;-))

Original von gritsch
nein, musst du nicht, doch wie du ja richtig schreibst wird ein 16 bit integer verwendet. UInt16 ist ja genau das. Wenn nun short nicht mehr 16 bit sind dann wird UInt16 sicher nicht mehr ein short sein,

Womit UInt16 und unichar verschieden wären.

Original von gritsch
denn es wird immer noch 16 bit sein (wie der name schon sagt). [/Quote|
Eben. Und unsigned short nicht.

Original von gritsch
Folglich ist UniChar immer noch korrekt.

Nein, weil NSString unsigned short dafür definiert.

Original von gritsch
Man kann also schreiben was man will: unichar, UniChar, UInt16 oder auch MyUUUUNNNIIICCCHHHAAARR (typedef MyUUUUNNNIIICCCHHHAAARR UInt16; )

Du sagst gerade, dass es unterschiedlich sein kann, man aber schreiben kann, was man will?

Original von gritsch
btw: das ist heute schon der zweite thread mit uns - wir verdienen wohl zuviel geld dass wir soviel zeit zum plaudern haben ;-))

wenn short nicht 16 bit lang wäre, dann wäre unichar nicht über short definiert. es müssen (laut doku) ja 16 bit sein. UInt16 wär also immer noch korrekt

Original von subverse
Jetzt hab ich gerafft :
Ein String "&#x...;" ist halt ein String und nix anderes.
[…]

Ja, das versuche ich dir seit einiger Zeit zu erklären.

Original von gritsch
wenn short nicht 16 bit lang wäre, dann wäre unichar nicht über short definiert. es müssen (laut doku) ja 16 bit sein. UInt16 wär also immer noch korrekt

Nein, es sind laut Doku 16 Bit. Das muss es nicht sein und ist sogar genau genommen falsch.

Original von Amin Negm-Awad

Original von zermelo
Huh? Was genau hat uns "Windoof" aufgedrückt?

Systeme, die nicht nativ mit Unicode umgehen können.

Verstehe ich nicht, was hat Windows damit zu tun, dass man nicht immer 8 Bit zur Verfügung hat? UTF-7 halte ich für sehr esoterisch. Ist doch gut, dass HTML/XML das vereinheitlicht hat. Warum "Windoof" nicht nativ mit Unicode umgehen kann ist mir auch unverständlich, ich ärger mich oft genug über das Gegenteil.

Original von Amin Negm-Awad

Original von zermeloDavon abgesehen: Sollte nicht soetwas wie "\xf\x41" für &#0f41; funktionieren? Oder in Oktal "\41\101"?

Nein, weil er dann einen String erzeugt, der @"\41\101" heißt. Ob nun &# oder \x oder \ – das sind Darstellungen, um von ASCII auf Unicode zu kommen. Die müssen interpretiert werden. Wer interpretiert einen fertigen String? Richtig: Niemand. Das wird bei der Stringerstellung, etwa mit -stringWithFormat: interpretiert.

Falsch, der Compiler interpretiert das. Auch in Objective-C ist "\" im String ein "Escape-Zeichen". Welche Lektüre benutzt Du, die so ein Bockmist behauptet?

Übrigens:
funktioniert bei mir Problemlos und macht schön UTF-8.

Original von zermelo

Original von Amin Negm-Awad

Original von zermelo
Huh? Was genau hat uns "Windoof" aufgedrückt?

Systeme, die nicht nativ mit Unicode umgehen können.

Verstehe ich nicht, was hat Windows damit zu tun, dass man nicht immer 8 Bit zur Verfügung hat? UTF-7 halte ich für sehr esoterisch. Ist doch gut, dass HTML/XML das vereinheitlicht hat. Warum "Windoof" nicht nativ mit Unicode umgehen kann ist mir auch unverständlich, ich ärger mich oft genug über das Gegenteil.

Zwischenzeitlich ja. Eine systemweite native Unterstützung ist bei Windows erst sehr spät entstanden.

Original von zermelo

Original von Amin Negm-Awad

Original von zermeloDavon abgesehen: Sollte nicht soetwas wie "\xf\x41" für &#0f41; funktionieren? Oder in Oktal "\41\101"?

Nein, weil er dann einen String erzeugt, der @"\41\101" heißt. Ob nun &# oder \x oder \ – das sind Darstellungen, um von ASCII auf Unicode zu kommen. Die müssen interpretiert werden. Wer interpretiert einen fertigen String? Richtig: Niemand. Das wird bei der Stringerstellung, etwa mit -stringWithFormat: interpretiert.

Falsch, der Compiler interpretiert das. Auch in Objective-C ist "\" im String ein "Escape-Zeichen". Welche Lektüre benutzt Du, die so ein Bockmist behauptet?

[/Quote]
Was sollte dir es bringen, Lektüre zu lesen, wenn du nicht einmal meine Beiträge liest. Hatte ich wirklich gesagt, dass es nicht interpertriert wird?

Original von Amin Negm-Awad
Das wird bei der Stringerstellung, etwa mit -stringWithFormat: interpretiert.

Und was machst du da gerade? Hmmm, du erstellst eine String-Instanz?

Original von zermelo
Übrigens:

Quellcode

1. NSLog(@"Hallo\xE2\x93\xBA");

funktioniert bei mir Problemlos und macht schön UTF-8.

Und was hast du gerade gemacht? Hmmmmm …?

Ich verstehe wieder einmal Deine Argumentation überhaupt nicht. Ich vermutete, dass @"\xDE\xAD" funktionieren könnte, Du widersprichst. Ich probiere es aus, Du sagst, ich hätte was anderes gemacht?
Achso, Du meinst, in meinem NSString stehen irgendwelche Bytes und jetzt kommt es drauf an, wer das wie darstellt? Nagut, dann hoff ich mal, das der Darsteller aus einem "A" auch ein "A" macht. Man weiss ja nie. 0x41 könnte ja auch sonst was bedeuten, wer weiss das schon...Oder wieder nicht richtig verstanden?

Weder \x noch \ hat etwas mit ASCII zu tun, woher hast Du diesen Unfug? Damit fügt man Bytes direkt in ein String ein, was offensichtlich auch (wie gezeigt) problemlos mit Objective-C funktioniert. \n mag jetz vielleicht ASCII sein, zufälligerweise ist es in Unicode aber gleich.

Andererseits gibt es scheinbar für Objective-C keine allgemeingültige Spezifikation, von daher ist es wohl Sache des Compilers, mit einem @"..." zu machen, was er für richtig hält.
Ich geh mal lieber wieder verliebt über meine C++ Specs blättern und Bjarnes Namen preisen

Original von zermelo
Ich verstehe wieder einmal Deine Argumentation überhaupt nicht. Ich vermutete, dass @"\xDE\xAD" funktionieren könnte, Du widersprichst.

Ja, weil du seinen Beitrag nicht gelesen hast. Er generiert den String. Er hängt da Zeichen an, Nummern die er als Codes interpretiert haben will. Das hat nichts mit dem Eintippen in die Source gemein.

Original von zermelo
Ich probiere es aus, Du sagst, ich hätte was anderes gemacht?

Ja, weil du den String nicht generiert hast.
Zeig mir doch einfach Code, der in Strings Codes generiert und dessen Codes dann interpretiert werden.

Original von zermelo
Achso, Du meinst, in meinem NSString stehen irgendwelche Bytes und jetzt kommt es drauf an, wer das wie darstellt?

Nein, das meine ich nicht.

Original von zermelo
Nagut, dann hoff ich mal, das der Darsteller aus einem "A" auch ein "A" macht. Man weiss ja nie. 0x41 könnte ja auch sonst was bedeuten, wer weiss das schon...Oder wieder nicht richtig verstanden?

Lies einfach noch einmal den OP. Mich musst du gar nicht verstehen.

Original von zermelo
Weder \x noch \ hat etwas mit ASCII zu tun, woher hast Du diesen Unfug? Damit fügt man Bytes direkt in ein String ein, was offensichtlich auch (wie gezeigt) problemlos mit Objective-C funktioniert. \n mag jetz vielleicht ASCII sein, zufälligerweise ist es in Unicode aber gleich.

Da hast du Recht. Es könnte auch EBCDIC sein. So viel zur Relevanz.

Original von zermelo
Andererseits gibt es scheinbar für Objective-C keine allgemeingültige Spezifikation, von daher ist es wohl Sache des Compilers, mit einem @"..." zu machen, was er für richtig hält.

Das ist falsch. Es gibt eine Apple-Spezifkation.

Original von zermelo
Ich geh mal lieber wieder verliebt über meine C++ Specs blättern und Bjarnes Namen preisen

Das hilft dir nicht beim verständnis des OP.

Ich habe versucht, mich der Diskussion anzuschliessen. Ich denke, für das ursprüngliche Problem, &#...; in ein Unicode-String umzuwandeln gibt es nur die eine, bereits genannte Lösung.

Meine Antwort bezog sich darum quasi auf

Original von Lucas de Vil
Mal ne blöde Frage:
wie bekomme ich denn [Zwei Zeichen, die hier nicht angezeigt werden können] in den String gepackt, wenn meine Tastatur das gar nicht her gibt?
Copy'n'Paste von tibetanischen Wörterbüchern? Den Zifferncode in der UTF-Tabelle suchen und als Char ausgeben lassen?

Ich hab da keine Ahnung.

und die darauf folgende Beiträge.

Ich weiss auch nicht, was Du jetzt willst:

Original von Amin Negm-Awad
Ja, weil du den String nicht generiert hast.
Zeig mir doch einfach Code, der in Strings Codes generiert und dessen Codes dann interpretiert werden.

Mit meinem Vorschlag dachte ich an etwas wie (Pseudo-Code!):

Original von Amin Negm-Awad

Original von zermelo
Andererseits gibt es scheinbar für Objective-C keine allgemeingültige Spezifikation, von daher ist es wohl Sache des Compilers, mit einem @"..." zu machen, was er für richtig hält.

Das ist falsch. Es gibt eine Apple-Spezifkation.

Dann bin ich eindeutig zu blöde. Zeigst Du mir bitte, wo genau das Verhalten von etwas wie definiert ist? Bekomme ich dadurch nun einen legalen unicode string, sofern \xDE\xAD unicode ist? Wo ist das verhalten von "\" in NSString-Konstanten definiert? Wo ist das Encoding von @"..." definiert? Alles, was ich finde, ist "you can also use UTF-16 encoded strings". Was soll das heissen?

Original von zermelo
Ich habe versucht, mich der Diskussion anzuschliessen. Ich denke, für das ursprüngliche Problem, &#...; in ein Unicode-String umzuwandeln gibt es nur die eine, bereits genannte Lösung.

Jo und zwar seit Ewigkeiten genannt.

Original von zermelo
Meine Antwort bezog sich darum quasi auf

Original von Lucas de Vil
Mal ne blöde Frage:
wie bekomme ich denn [Zwei Zeichen, die hier nicht angezeigt werden können] in den String gepackt, wenn meine Tastatur das gar nicht her gibt?
Copy'n'Paste von tibetanischen Wörterbüchern? Den Zifferncode in der UTF-Tabelle suchen und als Char ausgeben lassen?

Ich hab da keine Ahnung.

und die darauf folgende Beiträge.

Klang gestern um 17:29 ganz anders. Auch noch um 22:50, als ich explizit darauf hinwies, dass es so nicht geht.

Original von zermelo
Ich weiss auch nicht, was Du jetzt willst:

Original von Amin Negm-Awad
Ja, weil du den String nicht generiert hast.
Zeig mir doch einfach Code, der in Strings Codes generiert und dessen Codes dann interpretiert werden.

Das ist das, was im OP steht und von Anfang gewollt war:

Habe einen Algorithmus der asiatische Schriftzeichen produziert, er generiert unicode in folgender Form : བ་

Ich hatte das später auch noch einmal zitiert.

Original von zermelo
Mit meinem Vorschlag dachte ich an etwas wie (Pseudo-Code!):

Quellcode

1. NSString *tibet_a = @"\xDE\xAD";
2. NSString *tibet_b = @"\xBE\xEF";
3. NSMutableString *generierter_satzt = [...tibet_a...tibet_b...]'

Das ist immer noch nicht generiert, sondern fest kodiert.

Original von zermelo

Original von Amin Negm-Awad

Original von zermelo
Andererseits gibt es scheinbar für Objective-C keine allgemeingültige Spezifikation, von daher ist es wohl Sache des Compilers, mit einem @"..." zu machen, was er für richtig hält.

Das ist falsch. Es gibt eine Apple-Spezifkation.

Dann bin ich eindeutig zu blöde. Zeigst Du mir bitte, wo genau das Verhalten von etwas wie

Quellcode

1. NSSting *str = @"\xDE\xAD";

definiert ist?

Deine Behauptung war, dass der Compiler bei @"…" machen darf, was er will. Soll ich es dir noch einmal heraussuchen? Von dem, was dazwischen steht, war gar nicht die Rede, sondern von dir ausgelassen.

Das ist definiert:

@"string"
Defines a constant NSString object in the current module and initializes the object with the specified string.
On Mac OS X v10.4 and earlier, the string must be 7-bit ASCII-encoded. On Mac OS X v10.5 and later (with Xcode 3.0 and later), you can also use UTF-16 encoded strings. (The runtime from Mac OS X v10.2 and later supports UTF-16 encoded strings, so if you use Mac OS X v10.5 to compile an application for Mac OS X v10.2 and later, you can use UTF-16 encoded strings.)

Übrigens steht da ganz am Rande, dass er früher 7-Bit-ASCII sein musste. Aber egal.

Was zwischen den "" ist, ist nicht anders als bei C, mit der zusätzlichen Festlegung, dass es 7-Bit-ASCII sein musste und jetzt UTF-16 verwendet werden muss.

Original von zermelo
Bekomme ich dadurch nun einen legalen unicode string, sofern \xDE\xAD unicode ist? Wo ist das verhalten von "\" in NSString-Konstanten definiert?

Ja, siehe oben.

Original von zermelo
Wo ist das Encoding von @"..." definiert? Alles, was ich finde, ist "you can also use UTF-16 encoded strings". Was soll das heissen?

Es heißt, dass a) mit @"" immer eine String-Instanz erzeugt wird und b) das dazwischen der Text als ASCII bzw. jetzt als UTF-16 interpretiert wird.

Was gibt es daran nicht zu verstehen?

Könnten die Armeen von Bjarne und Alan bitte mal den Klappstuhl wieder einbuddeln und die Friedenspfeife auspacken? Danke.

Ich verstehe die Sache so:
Wird ein NSString erzeugt, dann wird die Eingabe interpretiert und umgewandelt.
Deshalb funktioniert zum Beispiel @"\xDE\xAD" und [NSString stringWithFormat:@"%C%C", \xDE, \xAD] wunderbar.

Es gibt aber vielleicht auch Methoden, bei denen Strings nicht interpretiert und umgewandelt werden, sondern so genutzt werden, wie sie sind. Eventuell hängt [NSMutableString appendString:aString] einfach nur Zeichen an während [NSMutableString appendFormat:aFormat] die Daten neu interpretiert und anhängt.
("The string to append to the receiver. aString must not be nil." vs. "The appended string is formed using NSString's stringWithFormat: method with the arguments listed.")
Vermutlich ist NSStrings stringWithString: ähnlich gestrickt.

Bleibt die Frage nach dem Erstellungsalgorithmus. Vermutlich gibt der einen lesbaren &#xDE oder \xDE aus, was genau genommen @"\&\#xDE" oder @"\\xDE" entsprechen sollte.
Diesen kleinen entscheidenden Hinweis auf den Algorithmus habe ich tatsächlich übersehen...

Immer noch nicht ganz richtig.

Erst einmal gibt es zwei "Stufen" der Interpretation. Einmals die Escape-Interpretation mit \. Diese wird vom Compiler vorgenommen. Mir ist kein Fall bekannt, dass dies zur Laufzeit funktionieren würde So etwas wie

NSString* text = [NSString stringWithFormat:@"%c%d", '\\', 65];

funktioniert nicht. Es führt zu \65 (nicht der Ersatz von \65 = 'A'), weil der Compiler das nie sieht. Vorschläge, die bei der Generierung darauf basieren können daher nicht funktionieren. Übrigens auch bei Stoßtrupp nicht. Schon bei Dennis 1972 funktionierte entsprechendes nicht. Man müsste den String durch den Compiler jagen.

Dann gibt es den Formatstring. Der wird zur Laufzeit interpretiert. Daher funktioniert ein %C mit anschließendem Code. Diese Interpretation wird von bestimmten Methoden gemacht, die das spezifizieren. Und diese Methoden erwarten eine Ganzzahl als Parameter, keinen String mit einer Zahl. Daher kann das mit @"1234"m @"\1234", @"&#1234" usw. immer noch nicht funktionieren.

Das ist eigentlich ganz einfach und stand schon vor 14 Stunden in diesem Thread. Aber dann kamen diejenigen, die es besser wissen …