Odkryłem ciekawy bug w #ZBar, debugując błąd testów paczki #SegNo (generator #QRCode w Pythonie), na #Gentoo, z #musl libc.
SegNo domyślnie próbuje kodować ciągi znaków jako ISO-8859-1, jeżeli jest to możliwe. ZBar domyślnie próbuje w pierwszej kolejności dekodować je jako Big5. Zazwyczaj wszystko działa.
Weźmy przykładowy ciąg znaków z testów ZBar: "Märchenbücher". Kiedy kodujemy go jako ISO-8859-1, otrzymamy dwie sekwencje kodowe (wysoki bajt, niski bajt): E4 72 dla "är", i FC 63 dla "üc". Ta druga wchodzi na "zdefiniowany przez użytkownika" znak w Big5, i glibc odmawia konwersji. Natomiast musl radośnie to konwertuje. Tak więc, ZBar dekoduje ciąg znaków jako Big5, "M酺chenb𡡷her".
Można tu argumentować, że musl działa niepoprawnie. Ale należy zwrócić uwagę, że pierwsza sekwencja jest poprawnym kodowaniem Big5. Tak więc jeśli skrócimy ciąg do "Märchen", glibc radośnie zdekoduje nasze ISO-8859-1 jako Big5, i da nam "M酺chen". I tak, po wstawieniu takiego ciągu znaków w SegNo, dostaję QRCode, przy pomocy którego mogę odtworzyć ten problem na glibc.
Czy ZBar działa niepoprawnie? Czy może SegNo powinno unikać kodowania ISO-8859-1, i zamiast tego pójść w bezpieczniejsze UTF-8?
https://bugs.gentoo.org/923233
https://github.com/heuer/segno/issues/134
https://github.com/mchehab/zbar/issues/281