falls ich diesbezüglich a funktion gefunden hab, meld ich mich (es seidenn es kennt jemand die funktion schon.

Die Funktion heißt iconv. Ich weiß nicht, wie du darauf kommst, dass iconv nicht von UTF-32 in eine andere Codierung konvertieren kann. Noch weniger verstehe ich allerdings, warum du jetzt wieder von UTF-32 wegwillst. Der ganze bisherige Aufwand hatte doch das Ziel, die Strings in genau diese Codierung zu überführen.

Was ist denn das endgültige Ziel dieser Umcodierungsorgie?

gut evtl liegts an der firmenfunktion, da nämlich durch die aufgefüllte 0er er früher halt machd und zum schluss noch eine 1 in der inbuff-variable steht (sollte ja 0 stehen meines wissens). müsste für den fall wohl ne eigene kleine funktion baun, die dann das richtig machd.

die konvertierung in widechar sollte hald für das vereifnachte vergleichen von strings mit zeichen (so z.b. abfrage ob '︾' im text steht (als banalstes beispiel, da dieser 3Bytes in UTF-8 verbrauchd). Mit MB is es ja schwieriger das zu vergleichen.

was mir JETZT aufgefallen ist: die codierung der MB-zeichen ist anormal

so z.B. das Ö: dieses Zeichen schaud so aus im MB-String:

hex: BC C9

bin: 10111100 11001001

char to int: -61 -74

Jedoch aus versch. quellen hab ich erfahren, dass ein UTF-8-codiertes Zeichen bei solchen zeichen wiefolgt aussehen (binär):110XXXXX 10XXXXXX

linux sollte doch eigentlich standartmäßig UTF-8 codierte konsolenein- und ausgaben haben ... zudem werden alle symbole richtig angezeigt (das "︾" habe ich aus ner UTF-8 Tabelle über Wiki kopiert)

hab bei mir über export geschaud und LANG is bei mir "en_US.UTF8".

bezüglich der richtung (BE / LE) wird dies ja nicht bei UTF-8 Berücksichtigt, wodurch das auch nicht der grund sein sollte.

was mir JETZT aufgefallen ist: die codierung der MB-zeichen ist anormal

so z.B. das Ö: dieses Zeichen schaud so aus im MB-String:

Das ist keine gültige UTF-8-Sequenz. Selbst wenn man die Bytes vertauscht (dann wäre es gültig), kommt da kein Ö raus. Ö wäre C3 96.

Wo liest du diese Daten denn ab?

wenn ich ganz blöd war hab ich falsch umgerechned ^^ ...

ich hab einfach das charsymbol in int gecastet und die minuswerte *-1+127 (0-127 ist ja ASCII-bereich) gerechnet. somit hat man die wertigkeit 0-255 (Byte) / 00-FF ... un zwischen den system hab ich einfach KCalc genutzt ...

ou was mir grad noch auffällt: es ist ich das Ö sondern das ö! sry is mir grad erst aufgefallen >_<'

ich hab [...] die minuswerte *-1+127 gerechnet.

Das ist Unsinn. Stichwort Zweierkomplement.

-61 = 1100 0011 (0xC3)

-74 = 1011 0110 (0xB6)

Das ergibt den Code 1111 0110 = 0xF6, das ist ein kleines ö.

:upps k so wird also das ausgerechnet :/

da muss ich wohl nochmal wieder binärumrechnung anschaun ... (wissen etwas verstaubt)