User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; de; rv:126.96.36.199) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729) Build Identifier: certdata.txt,v $ $Revision: 1.58 $ nss 3.12.6 AC_Ra\xC3\xADz_Certic\xC3\xA1mara_S.A..crt T\xc3\x9c\x42\xC4\xB0TAK_UEKAE_K\xC3\xB6k_Sertifika_Hizmet_Sa\xC4\x9Flay\xc4\xb1\x63\xc4\xb1s\xc4\xb1_-_S\xC3\xBCr\xC3\xBCm_3.crt EBG_Elektronik_Sertifika_Hizmet_Sa\xC4\x9Flay\xc4\xb1\x63\xc4\xb1s\xc4\xb1.crt Here are the correct and decoded filenames: CKA_LABEL UTF8 "TÜBİTAK UEKA Kök Sertifika Hizmet Sağlayıcısı - Sürüm 3" CKA_LABEL UTF8 "AC Raíz Certicámara S.A." CKA_LABEL UTF8 "EBG Elektronik Sertifika Hizmet Sağlayıcısı" As this is not correctly encoded, my local system do not find the files. Reproducible: Always
The characters shown above (with the \x's in them) are UTF8, not UCS2. Although UTF8 is a multi-byte character set, those UTF8 characters are encoded as single-byte characters in the c source code, because the c language does not accept multi-byte UTF8 characters as source. The characters are correctly compiled and appear correctly in Firefox.
hi and thanks for your response. The problem in my case is, that i'm just using the certdata.txt as input for generating the root-ca's for a debian package. unfortunately, i was forced to recode the characters as some local programms (md5sum) for example is not able to handle the filenames in it's raw source. Anyway, i'm just wondering why only 3 out of 160 certs are coded this way.
> wondering why only 3 out of 160 certs are coded this way. Because only 3 certs have non-ASCII characters in their nicknames. Some of the NSS developers have expressed the desire to have all nicknames be ASCII only, because of the difficulty of entering UTF8 nicknames on some systems. I think it may be the case that, going forward, we will not put any more non-ASCII characters into these nicknames, but for backwards compatibility, I believe we will keep these three.