Announcement

Collapse
No announcement yet.

10554 Corrupt display of accented zipped filename char

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • 10554 Corrupt display of accented zipped filename char

    Here an accented char in a zipped filename shows fine in Windows Explorer but corrupt in BC:



    Ideas?

  • #2
    Until recently the zip spec didn't talk about the character encoding to use for filenames, so different programs use different methods to store extended characters. v3.1.4 should match WinZip 12, which occassionally differs from how Windows' built-in support works. If you want you're welcome to send in a copy of the zip and I can take a look to say for certain; you should be able to use the zip stripper program I've mentioned previously.
    ZoŽ P Scooter Software

    Comment


    • #3
      > different programs use different methods to store extended characters.
      > v3.1.4 should match WinZip 12, which occassionally differs from how
      > Windows' built-in support works.

      The issue is not about what BC3 uses to store, it is about BC3 interpreting what Windows uses to store. Are you saying BC3 is not designed to be compatible with Windows in this respect?

      Comment


      • #4
        Yes, that's exactly what I'm saying. We could be compatible with Windows or WinZip, and I chose the latter. It should still be compatible with Windows for most extended characters, and I actually don't see anything in the screenshot that would indicate why it doesn't handle that case, which is why I offered to take a look at the zip.
        ZoŽ P Scooter Software

        Comment


        • #5
          > Yes, that's exactly what I'm saying.

          Do you have plans to fix this?

          Comment


          • #6
            I've looked into it further and I'm not really sure what's going on right now. A US/Western European install of Windows should not be able to store a file who's name contains a Ń character, and my tests here confirm that. Please send me the zip and let me know what the ANSI/OEM code pages are on your system (the "Language for non-Unicode programs" option in the "Regional and Language Options" control panel).

            Barring a bug or obvious enhancement, no, I'm not going to change the behavior. I've studied the issue in depth and I agree with the reasons behind WinZip's behavior. We started matching WinZip's before Windows even had built-in zip handling, and changing it now would also break zips created in previous versions of BC.
            ZoŽ P Scooter Software

            Comment


            • #7
              > Barring a bug or obvious enhancement, no, I'm not
              > going to change the behavior.

              Since the behaviour is in doubt, please could you simply confirm the design intent. Is BC intended to be compatible with the ZIP format of its host OS, or not?

              Comment


              • #8
                Beyond Compare is compatible with WinZip. You're welcome to buy a license to it and convince them to change their behavior. If they do we will too.
                ZoŽ P Scooter Software

                Comment


                • #9
                  > Beyond Compare is compatible with WinZip.
                  > You're welcome to buy a license to it and convince them to change their behavior.

                  I don't know why you keep going on about WinZip. My issue is not with WinZip and I never ever mentioned it. I am using Windows XP Explorer zip.

                  Is BC intended to be compatible with the ZIP format of its host OS, or not?

                  Comment


                  • #10
                    BC is compatible with the official zip specification.

                    Storing filenames with extended characters is not documented in that spec, and there is considerable disagreement on the best way to do so, so you will get inconsistent results with different programs. The method that BC uses for both reading and writing those filenames is the same as what WinZip does, and was decided early in BC2's development, before Windows had built-in zip support. Unfortunately Windows' uses a different method of storing those filenames and it isn't possible to detect which method is used. Changing which method we use now would break any files encoded using a previous version of BC.

                    The zip spec recently documented the official way to support those filenames and BC is compatible with it. Windows' built-in support is not.

                    Whether you take that to mean that BC is incompatible with the "zip format of the host OS" is up to you, but it is what it is, and it isn't changing. You could just as easily ask Microsoft to update their zip support so it uses the new spec, which would also solve the issue.
                    ZoŽ P Scooter Software

                    Comment


                    • #11
                      For the third time, I ask, is BC intended to be compatible with the ZIP format of its host OS, or not? A straight Yes or No answer would be appreciated.

                      Comment


                      • #12
                        Hello Chrisjj,

                        Beyond Compare 3 is a multiplatform program. We run on a variety of Windows OS (some of which do *not* include zip support) and several Linux-based OS. We do not use Host specific calls to make zips since that would make zips incompatible as you upgrade your Host OS or between OS installs of Beyond Compare 3.

                        We adhere to the standard spec that Zips are supposed to follow. Microsoft does not always follow this (Internet Explorer 6), but have shown that then usually come around to the spec later (Internet Explorer 7,8).

                        We will investigate incorporating other behavior to help with legacy support. We are still fully compatible with any archives our software has created.
                        Aaron P Scooter Software

                        Comment


                        • #13
                          Chris,

                          I'm not trying to be difficult, but your question, as phrased, doesn't have a yes/no answer.

                          There was a regression in 3.1.4 on non-US systems, and it will be fixed in the next release. Once it's fixed BC will display your zip correctly.

                          As to why I can't answer your question: The "host OS" does not define the way zip filenames are stored, the applications do. On Linux all the applications agree, and BC is fully compatible with them. On Windows there are two ways to store the filenames and there are large numbers of applications and zips that use each. BC3 tries to support both cases, but can't guarantee either 100%.

                          As a concrete example, Explorer and BC2 use different methods. If you create a file named "╠", Explorer will store that as 0xCC. BC2 can't store that character, but if you create a file named "Ő" it also stores it as 0xCC. So, in BC3 we get a zip containing 0xCC and have to decide whether that means "╠" or "Ő", and in that case we'll go with "Ő". Most of the characters will be detected and handled correctly, so "ń" should work regardless of which application created it. Neither method is more correct than the other. Explorer's approach is probably more wide-spread, but BC2's supports more useful characters. BC3 will use the Explorer method when possible.

                          If you want to define "host OS" as "Explorer" then no, BC won't always match it, but the situation is complex, and I don't think that makes us wrong.
                          ZoŽ P Scooter Software

                          Comment


                          • #14
                            I'll take that as a No.

                            Comment


                            • #15
                              > I'm not really sure what's going on right now. A US/Western European install of Windows
                              > should not be able to store a file who's name contains a Ń character, and my tests here
                              > confirm that.

                              My tests results differ. On this Windows XP Home SP2 (territory unidentifiied on My Computer, General), in Explorer I select a file, press F2, and type SHIFT+AltGr+A, ENTER. The file is renamed to Ń.

                              > Please send me the zip

                              Attached. The steps to reproduce the problem are:

                              1 Create a file named Ń
                              2 Copy it into a .ZIP
                              3 Compare the original and ZIP folders in BC3 10554

                              BC shows the ZIP version as named differently and hence shows a false mismatch:

                              http://img513.imageshack.us/img513/8240/58126361.gif

                              > and let me know what the ANSI/OEM code pages are on your system
                              > (the "Language for non-Unicode programs" option in the "Regional and
                              > Language Options" control panel)

                              English (United Kingdom)
                              Last edited by chrisjj; 03-Aug-2009, 01:08 PM.

                              Comment

                              Working...
                              X