-
Notifications
You must be signed in to change notification settings - Fork 35
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Displaying Russian letters (encoding problems) #152
Comments
This looks like some UTF-8 encoding issue. I will investigate it. |
I'm a bit puzzled here. This was an issue before the first release which I fixed at that time. Everything works in UTF-8. |
When I do an
and
and
I think paint.net is not writing utf-8 encoded data to your images. |
https://www.getpaint.net/ ??? |
So it is JTG. I will look further. |
I uploaded a windows 20210903 build. Please try. |
Please type in a command box (dosbox) the following command I am wondering whether it is: |
866 |
<frustration start>Stupid Windows. Only system in the world that does not use UTF-8.<frustration end> This requires code adaptations and a possible setting. Somewhere on startup I should check on Windows platform which code page is being used and use that one for reading and writing. Exiftool does support this as Windows requires it. For a user only looking at his/her own data, it doesn't make a difference, but even uploading to photo sites (Flickr, Piwigio, GPhotos) etcetera might already break this as these all run on Unix platforms. As microsoft understands that this limits international use, they now support applications to use (force) use of UTF-8 codepage since build 1907. This will take some time to implement I'm afraid. |
If anything, then I have this version: Thank you for your work, in solving this problem and in general developing this program in general! |
I really didn't expect such an answer. |
For some more info on how exiftool deals with this, please read answer 10 and 18 of the faq: https://exiftool.org/faq.html#Q10 and https://exiftool.org/faq.html#Q18 In this case I also have to deal with java as UI app, and exiftool, the console app, that I call from java. |
And another windows 20210904 build now using the "-use mwg" feature. Edit: This will not work on existing images (I think) as the strings are already saved with the Russian codepage, but should work on new images |
This is for newly written tags? |
A totally different approach: Reading and writing with default system codepage instead of trying to read and write in utf-8. On my linux machines that is utf-8 anyway. Same for macOS. build jExifToolGUI-1.9.0.0_beta-20210904_2-win-x86_64_with-jre.zip |
Good. Thanks for the feedback. |
I am not surprised. And that also remembers me why I alsways read UTF-8. All ExifTool internal strings are utf-8 (of course), so if I read tag strings and values, I did read those as utf8 meaning that the translated strings from Exiftool itself were correctly displayed. |
In Spanish use words with all accents [á, é, í, ó, ú, ñ]. pirámide |
And it's so nice to see that Windows displays utf-8 by default in their browsers and internet IIS servers. They must of course otherwise they had a world-wide issue and nobody would use Microsoft anymore. Why not be consequent and use it in your entire OS. <I will stop my frustration here 😉> |
I already explained earlier, that exiftool is prepared for windows, but just to show you I did below.
When using the correct characterset (and note that characterset is different from codepage 866/851. Let's not make it too easy 😉):
and when using the correct characterset and language
Of course that works differently in java coding handing it over to and getting it back from a commandline tool, but I hope I get that to work for both reading and writing as I found some coding that "should" do that (of course I am not the first running into this multi-platform issue) Your 3rd image is just a black "empty" jpg. |
It is getting worse. So in post 7 you state for the exif values in the OS codepage that it works, but please check for that "jExifToolGUI-1.9.0.0_beta-20210904_2-win-x86_64_with-jre.zip" also the File tags/values The point is that the "western" codepages miss some of the most exotic characters but all cover the "standard" strange characters in western latin languages. Of course Cyrillic and Asian languages are completely different. Edit: Even if I now start to "force write" everything in utf-8 (get string in OS code page, convert to byte array, convert to utf8 string, write to file), you will still get issues with older editied files, or files from programs that did write in the OS codepage. |
I am afraid that I will never get this to work. I really don't know how to solve this with exiftool. 😞 I think I might write a PM to Phil and ask him if I overlook something (hopefully) |
Unfortunately that is not possible. |
The other day I thought and searched a lot - other applications that use exif information and that are programmed in Java. But it has the same problem: One can try to find how JOSM works with exif information, because this is also a project, mostly programmed in Java... |
I also checked FastFotoTagger, but that has the same issues (actually even more) |
I think I finally made it work. Please check the jExifToolGUI-1.9.0.0-beta-20210923-win-x86_64_with-jre.zip on megaNZ. See also https://exiftool.org/forum/index.php?topic=12864.0 This will work for future images, but still not for older images written with the original windows codepage. |
2021-09-25.16-06-49-705.mp4 |
I can't reproduce this. |
In build
the problem is really solved. 2021-10-05.23-55-29-202.mp4(The problem that I wrote about a little above was resolved by itself ...) |
Great! |
exif:
![image](https://user-images.githubusercontent.com/36500228/131709461-2989938a-8144-4fe4-bd50-748838ce70f5.png)
Russian letters look like this: ����
xmp:
![image](https://user-images.githubusercontent.com/36500228/131709623-ac8b3fe2-ef01-46a5-900d-b3c5bcae63ec.png)
Russian letters look like this: ????
The text was updated successfully, but these errors were encountered: