strings und sonderzeichen

darthdespotism

mugglemaster schrieb:

Ich habe dem VC8 vom Visual Studio 2005.
Wenn du den Debugger startest und dann auf das erste Zeichenelement schaust, falls das beim g++-Debugger geht - siehst du dann für ä, ö, ü überall die -61?

m.

Ich tippe mal blindlings auf UTF-8 als locale. Dann hat man auch IMO mehrere Chars im string als Zeichen

mugglemaster

Also jetzt habe ich es zumindestens für mein System:
Zum Kodieren in einen std::string verwendet der Compiler wohl die CodePage 1252 bzw. ISO8591-1, sind nahezu indentisch:
http://www.microsoft.com/globaldev/reference/sbcs/1252.mspx
http://www.microsoft.com/globaldev/reference/iso/28591.mspx
=> ein ä wird zu einem 0xe4=228 im char-array des strings (dort ein -28 wegen signed)

Bei der Ausgabe verwendet die run-time die sogenannte "C"-locale die sich von der system-default ANSI-CodePage unterscheidet. Auf meinem XP-System hatte ich als 'language for non-unicode software' in Regional Settings - Advanced ein US-Encoding -> dies führt zu einer Ausgabe mit der (DOS) OEM-Codepage 437 -> aus einem 0xe4 wird ∑.
http://www.microsoft.com/globaldev/reference/oem/437.mspx

Wenn ich diese Einstellung auf Germany umsetze wird von Windows die (DOS) OEM-Codepage 850 verwendet -> aus einem 0xe4 wird hier nun ein o mit Schlange drauf.
http://www.microsoft.com/globaldev/reference/oem/850.mspx

Damit die Ausgabe korrekt ist muss ich nun per

setlocale( LC_ALL, "" );

das Programm nun noch anweisen für die Ausgabe die richtige system-default CodePage zu verwenden und schon ist es OK.

=> Kein Unicode etc. Die strings sind alle 1 Zeichen groß, keine UTF-8-Kodierung.

Warum beim g++ hier eine 61 steht, keine Ahnung was der für CodePages verwendet.

Sehr interessant zu diesem Thema finde ich übrigens
http://www.joelonsoftware.com/articles/Unicode.html
http://www.i18nguy.com/unicode/codepages.html#msftiso

m.

*D*Evil

C++ hat auch locales ... es gibt std::wstring hmm usw. ...

mugglemaster

(D)Evil schrieb:

C++ hat auch locales ... es gibt std::wstring hmm usw. ...

Das Problem bleibt auch bei Verwendung von wstring und wcout identisch, man bekommt lediglich keine negativen Werte mehr für die ausgegebenen Zahlen, weil ein wchar_t ein unsigned short ist.
Ein C++-string kann übrignes auch kein UTF-8, denn entweder der String ist 8Bit oder 16Bit lang. UTF-8 kannst du nur beim Speichern/Lesen mit Dateien verwenden.
UTF-16 kann er direkt auch nicht, dass was ein wstring ist könnte man noch als ucs2 bezeichnen.

m.

darthdespotism

GCC 4.2.1 auf Debian Gnu/Linux Produziert aus Umlauten in Quelltexten in std::basic_string<char> s UTF-8.

Macht halt ein

char string[] = "äüö";

ein Array von 7 char.

Umlaute im Quellcode ist sowieso schwachsinn (außer vll in den Kommentaren ... )

mugglemaster

darthdespotism schrieb:

GCC 4.2.1 auf Debian Gnu/Linux Produziert aus Umlauten in Quelltexten in std::basic_string<char> s UTF-8.
Macht halt ein
char string[] = "äüö";
ein Array von 7 char.
)

Nö, bei mir nicht:

char str[] = "äüö";
  int cnt = sizeof( str ); // liefert 4

m.

*D*Evil

ist ja auch korrekt:

str = {'ä', 'ü', 'ö', 0 }

Stromberg

Man kann doch auch die hier einsetzen für Umlaute:

Ä = \x8e
ä = \x84
Ö = \x99
ö = \x94
Ü = \x9a
ü = \x81
ß = \xe1

MfG
Stromberg

Bashar

darthdespotism schrieb:

GCC 4.2.1 auf Debian Gnu/Linux Produziert aus Umlauten in Quelltexten in std::basic_string<char> s UTF-8.

Sicher, dass das nicht daran liegt, dass dein Editor das als UTF-8 abspeichert? Ich meine der Compiler darf das nicht einfach so machen.

darthdespotism

Bashar schrieb:

darthdespotism schrieb:

GCC 4.2.1 auf Debian Gnu/Linux Produziert aus Umlauten in Quelltexten in std::basic_string<char> s UTF-8.

Sicher, dass das nicht daran liegt, dass dein Editor das als UTF-8 abspeichert? Ich meine der Compiler darf das nicht einfach so machen.

Wäre eine möglichkeit probier ich nachher mal aus.

*john 0

stringer schrieb:

wieso steht in Temp der wert -61?

Deine Plattform hat für den Datentyp char den Wertebereich -128 .. 127 andere 0..255. Die Norm garantiert, daß man char sowohl in "unsigend char" wie auch "signed char" konvertieren kann.

Wenn Du nun Werte im Beriech 0..255 haben willst, mußt Du als Datentyp "unsigned char" verwenden.

LordJaxom

Bashar schrieb:

Sicher, dass das nicht daran liegt, dass dein Editor das als UTF-8 abspeichert? Ich meine der Compiler darf das nicht einfach so machen.

Der Compiler darf den String Byte für Byte aus der Quelldatei holen, das ist mit Sicherheit der Editor gewesen.

hi,
sorry das ich jetzt erst wieder antworte, aber ich war die letzte woche nicht zuhause.
richtig durchsteigen tue ich immer noch nicht. ich benutze ubuntu 7.10 als os, anjuta 2.2.0 als ide und g++ 4.1.3 als compiler. was muss ich machen damit ich das nun endlich hinbekomme? ich hab bei anjuta mit den verschiedenen kodierungen rumgespielt, aber nix hat bis jetzt funktioniert.

für noch ein bisschen hilfe wäre ich sehr dankbar

*john 0

stringer schrieb:

was muss ich machen damit ich das nun endlich hinbekomme?

Das macht es noch nicht ganz wie es soll, aber das verdeutlicht, daß Problem mit "unsigned" vs. "signed" char.

#include <ostream>
#include <iostream>
#include <string>

int main () {
        std::string Test = "ä";
        int Temp = static_cast<unsigned char>(Test[0]);

        std::cout << Test << std::endl;                // gibt das ä ordentlich aus
        std::cout << Test[0] << ", " << Temp << "\n";    // gibt ein falsches zeichen und -61 aus
}

queer_boy

Bashar schrieb:

darthdespotism schrieb:

GCC 4.2.1 auf Debian Gnu/Linux Produziert aus Umlauten in Quelltexten in std::basic_string<char> s UTF-8.

Sicher, dass das nicht daran liegt, dass dein Editor das als UTF-8 abspeichert? Ich meine der Compiler darf das nicht einfach so machen.

Ich glaube nicht, dass es verboten ist. Zumal es mit dem neuen Standard ja auch explizit erlaubt sein wird, UTF-8-Strings in normalen String-Literalen (char const*) abzulegen. Im Moment ist es wahrscheinlich nur nicht sonderlich portabel.

Bashar

queer_boy schrieb:

Bashar schrieb:

Sicher, dass das nicht daran liegt, dass dein Editor das als UTF-8 abspeichert? Ich meine der Compiler darf das nicht einfach so machen.

Ich glaube nicht, dass es verboten ist. Zumal es mit dem neuen Standard ja auch explizit erlaubt sein wird, UTF-8-Strings in normalen String-Literalen (char const*) abzulegen. Im Moment ist es wahrscheinlich nur nicht sonderlich portabel.

UTF8-Strings in String-Literalen abzulegen ist überhaupt kein größeres Problem und IMHO was vollkommen anderes, als ungefragt aus Latin1-Umlauten UTF8 zu machen.