# UTF-8 characters interpreted as Windows 1252? **URL:** \ **Category:** Support\ **Created:** [March 26, 2020, 11:26am UTC](https://community.mp3tag.de/t/utf-8-characters-interpreted-as-windows-1252/48302 "2020-03-26T11:26:25Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![JamieF](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/e495f1/32.png) [@JamieF](https://community.mp3tag.de/u/JamieF)\ **Post date:** [March 26, 2020, 11:26am UTC](https://community.mp3tag.de/t/utf-8-characters-interpreted-as-windows-1252/48302/1 "2020-03-26T11:26:25Z")
MP3Tag v3.00 Windows 10 Hi I am having a problem with accented characters being misinterpreted when displayed in MP3Tag, matching the description found on this [page](https://www.i18nqa.com/debug/utf8-debug.html), so I see "König" instead of "König". The files have ID3v2.3 tags generated from a cue sheet during ripping. %\_id3v2\_character\_encoding% tells gives me UTF-16 as a result, but pasting the text into Notepad++ tells me the encoding is UTF-8. It is possible that this is a problem with the original cue sheet metadata, as I don't recall seeing this problem all the time. However, when I look at the cue sheet for this album in Notepad it displays correctly. In Notepad++ it also displays correctly and shows the cue sheet encoding as UTF-8-BOM. Any idea why this is happening and if there is there a simple workaround / fix? I know there have been many posts on the general topic of character encoding, but I couldn't find an answer to my questions above (sorry if I missed it). Thanks ---
**Author:** ![ryerman](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ryerman/32/5285_2.png) [@ryerman](https://community.mp3tag.de/u/ryerman)\ **Post date:** [March 26, 2020, 4:48pm UTC](https://community.mp3tag.de/t/utf-8-characters-interpreted-as-windows-1252/48302/2 "2020-03-26T16:48:07Z")
> [@JamieF](#): > > The files have ID3v2.3 tags generated from a cue sheet during ripping. If you put the cue sheet into a zip archive and upload it here, we can try and reproduce the problem. ---
**Author:** ![JamieF](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/e495f1/32.png) [@JamieF](https://community.mp3tag.de/u/JamieF)\ **Post date:** [March 27, 2020, 4:39am UTC](https://community.mp3tag.de/t/utf-8-characters-interpreted-as-windows-1252/48302/3 "2020-03-27T04:39:26Z")
Thanks. ZIP attached. Looking back at other rips I've done, I don't have so many extended characters in the tags, so it is possible that this is a consistent problem that I've lived with before. For albums like this one with 70+ tracks across 2 discs and numerous accents, it is a pain to manually correct. I didn't mention above that I also tried the Convert Codepage action (to 1252) but this had no effect. I guess I need to go in the opposite direction anyway (1252 -\> UTF) if this was going to work at all. [accents.zip](https://community.mp3tag.de/uploads/short-url/o5SJjTY47WMmAmxruTXdAhjRURD.zip) (1.7 KB) ---
**Author:** ![poster](https://community.mp3tag.de/user_avatar/community.mp3tag.de/poster/32/4881_2.png) [@poster](https://community.mp3tag.de/u/poster)\ **Post date:** [March 27, 2020, 7:39am UTC](https://community.mp3tag.de/t/utf-8-characters-interpreted-as-windows-1252/48302/4 "2020-03-27T07:39:55Z")
> [@JamieF](#): > > The files have ID3v2.3 tags generated from a cue sheet during ripping. How do you generate the tags exactly? ---
**Author:** ![JamieF](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/e495f1/32.png) [@JamieF](https://community.mp3tag.de/u/JamieF)\ **Post date:** [March 27, 2020, 10:06am UTC](https://community.mp3tag.de/t/utf-8-characters-interpreted-as-windows-1252/48302/5 "2020-03-27T10:06:57Z")
I use ISO2DSF to generate tagged DSF files from the ISO. I don't do any editing prior to loading into MP3Tag. ---
**Author:** ![dano](https://community.mp3tag.de/user_avatar/community.mp3tag.de/dano/32/6_2.png) [@dano](https://community.mp3tag.de/u/dano)\ **Post date:** [March 27, 2020, 2:55pm UTC](https://community.mp3tag.de/t/utf-8-characters-interpreted-as-windows-1252/48302/6 "2020-03-27T14:55:16Z")
To fix the tags you can load the cuesheet in Mp3tag (File\> Load Playlist/Cuesheet) and select the files and copy the tags to the clipboard (Ctrl+C) Then load the dsf files and paste the tags (Ctr+V) (make sure the file order is the same) ---
**Author:** ![ryerman](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ryerman/32/5285_2.png) [@ryerman](https://community.mp3tag.de/u/ryerman)\ **Post date:** [March 27, 2020, 4:12pm UTC](https://community.mp3tag.de/t/utf-8-characters-interpreted-as-windows-1252/48302/7 "2020-03-27T16:12:20Z")
> [@JamieF](#): > > I use ISO2DSF to generate tagged DSF files from the ISO. I don't do any editing prior to loading into MP3Tag. I used "CUE Tools" and the provided cue sheet to split a file into MP3 tracks with ID3v2.3 tags. All the metadata appears correctly in Mp3tag, the same as in the cue file. To me, that means that the cue file can be used to create unicoded metadata that will display correctly in Mp3tag. When you say "I use ISO2DSF to generate tagged DSF files from the ISO.", does that mean that the same cue file is used? If so, then it appears that ISO2DSF does not support Unicode encoded metadata. But maybe an update to ISO2DSF added unicode support or there is some other suitable software. However, dano has shown an elegant work-around for your problem. ---
**Author:** ![JamieF](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/j/e495f1/32.png) [@JamieF](https://community.mp3tag.de/u/JamieF)\ **Post date:** [March 29, 2020, 10:32am UTC](https://community.mp3tag.de/t/utf-8-characters-interpreted-as-windows-1252/48302/8 "2020-03-29T10:32:16Z")
dano - thanks for the work-around, that's just what I was looking for! To clarify, after copying the tags from the CUE you need to use "Add directory..." to load the files (as "Change directory..." clears the clipboard). ryerman - I re-extracted from the ISO to troubleshoot this further. It seems that ISO2DSF creates a correct CUE file but the metadata it embeds in the DSF files are wrong. Attached is a screen shot of the second stage of this process where you can see what it is producing. These tagged files show the same characters in MP3Tag, fb2k and in Window Explorer using the dbPowerAmp viewer. However, as the simultaneously produced CUE file is correct, dano's work-around works. So it is clear that this isn't a problem with MP3Tag. Thanks for your help, and maybe this thread can help others who run into a similar problem. [iso2dsf\_small.zip](https://community.mp3tag.de/uploads/short-url/nlaQV23c0oGsIZ1pFzgggVmFLmz.zip) (92.4 KB) ---
**Author:** ![system](https://community.mp3tag.de/uploads/default/original/2X/c/ce7035d426cb755a7916793326d23b465222a407.png) [@system](https://community.mp3tag.de/u/system)\ **Post date:** [February 9, 2026, 12:28pm UTC](https://community.mp3tag.de/t/utf-8-characters-interpreted-as-windows-1252/48302/9 "2026-02-09T12:28:29Z")