Ultraedit xml1/17/2024 ![]() ![]() This is not described at all in help of UltraEdit. This setting is only important for a Unicode file if File - Conversions - UTF-8 to ASCII or one of the other Unicode to ASCII conversion commands is executed as in this case UltraEdit needs to know to which code page the Unicode file should be converted. What is selected in View - Set Code Page does not matter if the file itself is encoded with UTF-8, UTF-16 little endian, UTF-16 big endian, or ASCII Escaped Unicode. But if a Unicode encoding is selected and the file is therefore really a Unicode encoded file, the code page setting is of no importance for the display of the text or the editing. I will report this to IDM by email.įurther, View - Set Code Page is identical to code page in enhanced status bar. That is definitely not correct as selecting UTF-8 for a single byte encoded text file ( Windows-1252 is not really an ANSI standard) results in execution of conversion command ASCII to UTF-8. This merely changes the encoding used to display the file in the editor. This does not actually affect the underlying content of the file. The Encoding Type control allows users to change the encoding used to display the active file. Notepad++ has no problems with it neither oXygen 12, neither WebStorm 7. UE crashes each time if I open a certain XML file. In the meantime I already send the bug report to sourceforge for Notepad++.Īnd because it is funny as I'd to send a bug report to IDM. Ups, just saw that I still not send this. Therefore it seems that the XML-Manager takes the codepage for edit, what was UTF-8, and got in trouble because the file is just 1252.īTW, I really hate those dialog for selecting the codepage because the entries are not sorted and it is not possible to search for substrings to find the right one. One codepage for editing and one for the view. That's really something I don't like with UE. All the time the codepage selected by menu with 'View/Select codepage.' was 1252. After restart 1252 was automatically selected and the XML-Manager is working. Again I changed it to 1252 and restarted UE without saving the file. Then I restarted UE and again UTF-8 was selected and XML-Manager does not work. Therefore I changed it back from 1252 to UTF-8 and closed UE without saving the file. When it is first time loaded the codepage on the status bar is set to UTF-8. I made now some test and it seems to be the following problem: Now it is really strange! I loaded the orignal file with comments and. That it was! Though, it seems that the XML parse of XML-Manager has some problems with those XML comments because the. I looked on the last lines of shortened config.xml and could see After one more step I could see at bottom of output window the error message: So I used Ctrl+Z to undo the lines deletion, removed a smaller block at bottom of the file, and executed once again XMLlint. No problem anymore for XMLlint to parse the shortened file. To find out what is wrong with this XML file, I removed many lines at bottom with keeping structure and executed Format - XMLlint Tool. I killed XMLlint process with Windows task manager. In other words XMLlint ran into an endless loop. ![]() I opened Windows task manager and could see that XMLlint was still running and consumed complete power of 1 CPU core. ![]() But UltraEdit was not responsible anymore. Therefore I executed next Format - XMLlint Tool and I could see immediately that XMLlint did not find an error in structure as output window showed already the lines from config.xml instead of an error message. It was really interesting in solving this problem. ![]()
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |