Comment 14 for bug 1031679

Okay, got it. The problem is that even though it appears to get the encoding right afterwards, it gives the wrong number of bytes/characters in the 'data' command. Example:

    M 120000 inline ssl/certs/3b2716e5.0
    data 47
    EBG_Elektronik_Sertifika_Hizmet_Sağlayıcısı.pem

as you'll hopefully agree first sight suggests 47 characters. For a latinized version

    EBG_Elektronik_Sertifika_Hizmet_Saglayicisi.pem

this would even be true. But due to the code points in UTF-8 this actually becomes 51 byte in length:

    0000000: 45 42 47 5f 45 6c 65 6b 74 72 6f 6e 69 6b 5f 53 EBG_Elektronik_S
    0000010: 65 72 74 69 66 69 6b 61 5f 48 69 7a 6d 65 74 5f ertifika_Hizmet_
    0000020: 53 61 c4 9f 6c 61 79 c4 b1 63 c4 b1 73 c4 b1 2e Sa..lay..c..s...
    0000030: 70 65 6d pem

This means that a code change is also needed down in the nethers of bzr-fastimport. I.e. my workaround fixes/d only part of the problem.