Konverter: Textdatei - Tag (Zeichensalat)

Ich stecke mal wieder im Gestrüpp des Zeichensalats und zwar diesmal bei der Funktion
Konvertieren Textdatei - > Tag

Es liegt eine Textdatei zum Importieren vor.
Ich schaue mir die zunächst in Notepad++ an. Notepad++ steht bei mir auf automatischer Erkennung der Codierung und zeigt für die betreffende Datei "UTF-8 ohne BOM" an. Alle Zeichen sind so wie sie sein sollten.
Meine MP3Tag-Einstellung bei den Tags zum Schreiben: ID3v2.3-UTF16.

Wenn ich jetzt das Textfile über Konvertieren Textdatei > Tag importiere bekomme ich Zeichensalat:
Beispiel:
"Gilbert Bécaud" wird zu "Gilbert Bécaud"

Die Mp3Tag-Previewfunktion des Konvertierungsmenüs verwendet bei mir auch Notepad++.
Notepad++ zeigt mir als Codierung für die erzeugte preview.txt "UTF-8" an.

Änderungen bei den Optionen von MP3Tag zum Schreiben (UTF-8, ISO8859-1) bringen kein anderes Ergebnis.

Ein korrektes Ergebnis bekomme ich auf folgendem Weg:

Konvertieren der zu importierenden Textdatei mit Notepad++ in die Codierung "ANSI" - alle Zeichen werden weiterhin richtig angezeigt.
Nach dem Import haben die Tags bzw. die preview.txt korrekte Sonderzeichen an.
Als Codierung meldet Notepadd++ bei der preview.txt "UTF-8".

Dieser Lösungsweg ist natürlich etwas umständlich und ich frage mich, ob sich da MP3Tag richtig verhält. Für mich sieht es so aus, als ob Mp3Tag eine UTF-8 codierte Datei nicht korrekt importiert und als Quelle eine ANSI-codierte Datei erwartet.

Du könntest mal in
Extras>Optionen>Export die Option "Exportdatei mit BOM" checken und ob das je nach Einstellung einen Unterschied macht.

Tut es nicht und hätte mich an dieser Stelle bei den Einstellungen für den Export
auch gewundert.

Also ich habe jetzt mal Gilbert Bécaud als String in 3 unterschiedlich codierten Textdateien untergebracht:
ANSI: 47 69 6C 62 65 72 74 20 42 E9 63 61 75 64: Gilbert Bécaud
Unicode: FF FE 47 00 69 00 6C 00 62 00 65 00 72 00 74 00 20 00 42 00 E9 00 63 00 61 00 75 00 64 00: G.i.l.b.e.r.t. .B.é.c.a.u.d
UTF-8: EF BB BF 47 69 6C 62 65 72 74 20 42 C3 A9 63 61 75 64: ...Gilber Bécaud

jeweils geschrieben mit dem stinknormalen Notepad von Windows.
Dadurch, dass alle nicht-ANSI-Dateien einen Header haben, werden sie auch von MP3tag richtig erkannt. Anscheinend ist da ein Fehler im Arbeitsgang mit Notepad++

Hallo
Ich selber habe die Arbeit mit Np++ schon lange aufgegeben, das stinknormale Editor-tools v. Win doof, macht was es soll - richtig importen.

Gruß

Naja, dieser "stinknormale Editor" kann ja nur einen Bruchteil der Features, die ich am Notepad++ schätze und auch benötige.

Allerdings liegt hier ein wohl Missverständnis des geschilderten Sachverhalts bei Ohrenkino und Dir vor, denn Notepad++ ist ja an dem geschilderten Problem überhaupt nicht beteiligt und es importiert ja auch nichts. Ich habe es nur erwähnt, weil es mir die Codierung der vorliegenden Textdatei und der preview.txt anzeigt. Die zu importierende Datei wurde nicht mit Notepad++ erstellt und ihr Ursprungsformat liegt auch außerhalb meines Einflussbereichs.
Problem war, dass das Importieren dieser Textdatei bei Mp3Tag zu falschen Zeichen führte (obwohl Notepad++ den Text beim Öffnen der Textdatei korrekt anzeigte).

Ich habe das Problem inzwischen jedoch wohl eingekreist.
Die Ursprungsdatei lag in "UTF-8 ohne BOM" vor. Notepad++ erkennt das korrekt und zeigt auch korrekte Zeichen an.
MP3Tag kommt aber wohl mit "UTF-8 ohne BOM" nicht zurecht.
Nach Konvertieren der Datei mit Notepad++ in "UTF-8 (mit BOM)" oder in "ANSI" importiert auch MP3Tag korrekt.

Hallo

Da lag ich schon richtig - ergo - gleiche Problematik
Gruß

Wozu gleich?

Hallo, wenn auch spät von mir gelesen

geschildert hast du das Problem hier was ich ebenfalls hatte
Gruß