Umlaute in einem Character machen Probleme

5cript

Ich habe zahlreiche Verschlüsselungsalgorithmen geschrieben die alle das selbe Problem haben:

Sobald ein Umlaut im Text ist machts boom ähhh dööf und es kommt müll raus:

char Zeichen = Text[i];
int Zahl = int(Zeichen);

schlägt Fehl:
Input unverschlüsselt:

Warum ein Unternehmen gründen? :
Mehr Selbstständigkeit

Warum ein Unternehmen gr nden? :
Mehr Selbstst￤ndigkeit

Wie soll ich diesem Problem entgegentreten ?

SeppJ

Tim06TR schrieb:

Wie soll ich diesem Problem entgegentreten ?

Mit einem Debugger.

hustbaer

char ist meistens "signed".
Umlaute haben Werte > 127.
Rest sollte klar sein.

5cript

wenn ich unsigned benutzte bleibt char(i) // i ist ein int
eine ZAHL ! (ist das eine Borland eigenart ?)

EDIT: Ausgabe: 90101105991041011101021111081031013210110511010310198101110322521081081051310

unsigned char CH;
int New = (StrToInt(Availables[i-1].c_str())-StrToInt(Code[i-1].c_str()));
CH = char(New);
Ret += CH;

EDIT 2: Ich frag mich wie sowas geht ?

5cript

Ist signed to unsigned, ohne einen speziellen cast durchzuführen, legitim ?
Mir scheint, ich mach etwas falsch (warum nur ?). Folgende Fehler könnt ich mir vorstellen:

signed int -> unsigned char => nicht gut (was ich nicht für logisch halte)
unsigned char X = char(i) => nicht gut

freaky

Warum nutzt du überhaupt char?

5cript

warum nicht ?
damit kann ich ganz einfach Zeichen umwandeln und das nach ASCII.
Was denn sonst ? (std::string ???)
(wenn vorschlag, dann bitte mit beispiel typ <> int)

EDIT: ja std::string hab ich ausprobiert und wär ne möglichkeit

i++;
std::string CH;
int New = (StrToInt(Availables[i-1].c_str())-StrToInt(Code[i-1].c_str()));
CH = static_cast<unsigned char> (New);
Ret += CH.c_str()

berniebutt

char cc,text[10];
int  ci,len,i;
strcpy(text,"ärmel");
len = strlen(text);
for(i=0;i<len;i++)
{
   cc = text[i];
   ci = text[i];
}

Characters sind intern Integers (ASCCI 0-255). Man kann bei der Auswertung entweder auf char zuweisen (Zeichen) oder auf Integer (ASCCI-Wert). Den Rest sollte der Compiler machen. Ggfs. ist unsigned int zu nehmen.

pumuckl

berniebutt schrieb:

Characters sind intern Integers (ASCCI 0-255).

Doppelt falsch. char ist ein Datentyp der Größe 1 Byte, kein int. Das Bitmuster entspricht einem signed oder unsigned char mit einem Wert zwischen 0 und 127. Der Standard definiert nur diesen Bereich, alles weitere ist nicht spezifiziert und compilerabhängig. chars mit einem Wert größer 127 bzw. kleiner 0 (je nachdem ob als signed oder unsigned betrachtet) entsprechen nicht dem vom Standard definierten Zeichensatz. Dazu gehören auch Umlaute.[c]

5cript

Mir ist aufgefallen, dass ASCII nicht reicht.
Dateien benutzen mehr Zeichen (eig Zahlen die nur als Zeichen dargestellt werden ?). Ich vermute das Unicode hier mehr hilft.
Ich bin recht ratlos, was ich bei Dateien jetzt machen soll.
(nur Texte ist langweilig :p ), das prog muss ja auch was bieten.

Ich gönn mir jetzt eine lange denkpause ... schnirch

berniebutt

pumuckl schrieb:

char ist ein Datentyp der Größe 1 Byte, kein int.

Definition meines Compilers: BYTE = 8-bit unsigned integer. Also kann man Zeichen jederzeit auch als integer betrachten und damit im Programm arbeiten.
Da es in C++ keinen Datentyp byte gibt, wird das compilerabhängig über ein MACRO geregelt.

Tim06TR: Was sind das für Dateien?

pumuckl

berniebutt schrieb:

Definition meines Compilers: BYTE = 8-bit unsigned integer. Also kann man Zeichen jederzeit auch als integer betrachten und damit im Programm arbeiten.

BYTE ist wiederum ein weiterer Datentyp oder eine Typdefinition, den dein Compiler da hat. Ist relativ verbreitet und entspricht einem unsigned char, ist meist ein einfaches Typedef darauf. Der Typ BYTE ist aber im Standard nicht festgelegt.
Meine Aussage bezog sich aber nicht auf diesen Datentyp sondern auf das was der Standard als byte definiert, nämlich eine implementationsspezifische Anzahl von Bits. Laut Definition hat der Datentyp char die Größe ein byte, alle anderen Datentypen haben eine ganzzahlige Anzahl von bytes als Größe, die von sizeof zurückgegeben wird. Wenn ein byte also ein byte 10 Bit enthält (was durchaus erlaubt ist), dann haben alle Datentypen eine durch 10 teilbare Anzahl an Bits. Die einzige weitere Anforderung die der Standard stellt ist die Menge der Zeichen, die ein char aufnehmen können muss, und das sind 2^7. Die mindestgröße für ein byte muss also 7 bit sein. Wenn ein Compiler auf einer Plattform den byte als 8 Bit definiert ist das schön für ihn, der definierte char-Zeichensatz umfasst trotzdem nur 128 verschiedene Zeichen.
char kann als integraler Datentyp interpretiert werden. Jedes Bitmuster kann das. Aus Kompatibilitätsgründen zu C kann man mit char auch addieren oder subtrahieren. Der Standard definiert nicht, ob ein char jetzt signed oder unsigned sein soll, weil das nur auf 8-Bit-Systemem (oder höher) Sinn macht. Auf einem 7-Bit System müsste es immer unsigned sein, weil char die ASCII-Werte von 0-127 annehmen können muss, ein signed char auf einem 7-Bit System aber nur von -64 bis 63 geht.

berniebutt

pumuckl: Alles klar, die Sache mit den Zeichensätzen bleibt implementationsabhängig in der Anzahl der bits. Darüberhinaus hat Unicode auch noch keine richtige Ordnung hineingebracht - leider. Zum Glück sind ASCCI 0 bis 127 fest. Für den Rest gibt es noch weiteren Standardisierungsbedarf. Kann man sich heute darauf verlassen, dass nationale Sonderzeichen unabhängig vom früher extra zu ladenden Zeichensatz im Programm eindeutig sind? Da ging die Frage doch wohl hin!

Zusatzfragen: Wieviele bits - also 2^n - braucht man? Ursprünglich n = 7 oder n = 8 scheint zu wenig für Zeichensätze. Machen kann man alles, denn intern im Prozessor hat man es ja nur mit bits zu tun. Und wieviele bits soll ein byte haben? Auch das ist eine willkürliche Festlegung.

pumuckl

berniebutt schrieb:

Zusatzfragen: Wieviele bits - also 2^n - braucht man?

Wofür brauchen? Ich kommt mit 7 Bit wunderbar zurecht, wenn ich alle Textein- und -ausgaben auf Englisch mache. Mit deutschen Umlauten, griechischen, kyrillischen und ähnlichen Schriften und den ganzen lustigen "C mit schlängelchen, i mit zwei Punkten" etc. reicht das schon nichtmehr, wie wir ja gesehn haben. Da müssten dann so größenordnung 10 Bit hinhauen.
Will ich möglicherweise japanische und/oder chinesische Textverarbeitung ermöglichen stellt sich erstmal die Frage was überhaupt ein Zeichen ist, bevor ich mich dann auf irgendwas im Bereich 16-24 Bit festlege. Unicode praktiziert ja schon die Zeichenzerlegung, á la "Ü = U + Tüddelchen". Wenn ich dann meinen Bit-Eimer für die fernöstlichen Sprachen gefüllt hab kommen Tolkien & Co an und denken sich Phantasiesprachen aus. Sollen Elbisch, Klingonisch & Co. mit in die möglichen Zeichensätze? Zu Glück wächst der mögliche Umfang exponentiell. Man hat gemeint, 16 bit pro Zeichen für Unicode seien ausreichend. Durch die zusammensetzungen hat man jetzt die Qual mit Zeichen, kombinierten zeichen und was weiß ich nicht alles. IIRC kann man in Java mit der entsprechenden Unicode-Unterstützung sich von jedem String drei verschiedene Längen ausgeben lassen.
Ich werd mich jetzt nicht festlegen und behaupten dass man alle Alphabete in 24 bit pressen kann. Vielleicht 32? Weiß mans?

berniebutt schrieb:

Kann man sich heute darauf verlassen, dass nationale Sonderzeichen unabhängig vom früher extra zu ladenden Zeichensatz im Programm eindeutig sind?

Nein. Stichwort Codepages.

hustbaer

Tim06TR schrieb:

Mir ist aufgefallen, dass ASCII nicht reicht.
Dateien benutzen mehr Zeichen

Dateien benutzen gar keine Zeichen. In Dateien stehen BYTES drin. BYTES haben nichts mit Zeichen zu tun. So lange man sie nicht als Zeichen interpretiert natürlich.

Beim Verschlüsseln solltest du dir auch KEINE Gedanken darüber machen wie man etwas einfach ausgeben könnte oder dergleichen. Sondern darüber, wie du korrekt ver- & entschlüsseln kannst.