Ich habe eine Datei, sagen wir mal mit dem melodisch klingenden Namen
מופע הארנבות של ד''ר קספר - השיר שלי.mp3 (ich hoffe, das wird überall vernünftig angezeigt, es sind hebräische Schriftzeichen). In dieser Datei möchte ich einen String auslesen, der laut ID3-v2-Tag-Spezifikation mit dem Zeichensatz ISO-8859-1 (Latin-1, Westeuropäisch) kodiert sein
sollte. Nun ist es aufgrund des Dateinamens relativ offensichtlich, dass der verwendete Zeichensatz ISO-8859-8 (Hebräisch) ist (der Dateiname stimmt dann teilweise mit der Info unter "Titel" überein

).
Für so einen "Unsinn" ist im ID3v2-Tag eigentlich Unicode da, damit die Meta-Informationen auf jedem System vernünftig angezeigt werden können (dafür wird im Tag ein entsprechendes Flag umgesetzt). Scheinbar wird in der Regel aber das
"es sollte Latin-1 sein" (wenn der Flag "0" ist) sehr oft als
"was anderes ist auch wurscht" interpretiert, und einfach ein anderer 8Bit-Zeichensatz verwendet. Kann man machen, macht aber eine vernünftige Verarbeitung der Informationen sehr schwer, wenn man eine multikulturelle Playlist hat.
Ich möchte nun gerne meine mp3FileUtils komplett Unicode-fähig machen, sodass auch "fremde" Schriften auf Wunsch ausgelesen und angezeigt werden können. Bisher wird Unicode nach Ansi konvertiert - wobei Informationen verloren gehen können.
Es ist natürlich unschön, wenn das theoretisch mögliche Auslesen von 16Bit-Unicode-Textinformation gar nichts bringt, weil oft nur 8-Bit Zeichen in variablen Zeichensätzen verwendet werden, und beim Auslesen des ID3-Tags bei hebräischen oder russischen Stücken nur Quatsch angezeigt wird, weil meine Unit fälschlicherweise davon ausgeht, dass der Standard eingehalten wird.

, in Wahrheit aber ein anderer Zeichensatz verwendet wird.
Ich suche also eine Möglichkeit, eine Bytefolge in einen WideString zu konvertieren, und dabei als Parameter den zugrundeliegenden Zeichensatz angeben zu können. Dabei wäre es außerdem sehr sinnig, wenn der "wahrscheinlich verwendete Zeichensatz" automatisch aus dem Dateinamen (bzw. aus den dort verwendeten Unicode-Zeichen) ermittelt werden könnte.
Hat da jemand Ansatzpunkte, Funktionen, Units?
We are, we were and will not be.