#zbar — Public Fediverse posts

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

#Python #kodowanie

Fun bug in #ZBar discovered while debugging a #SegNo (#Python #QRCode generator library) test failure on #Gentoo with #musl libc.

SegNo defaults to attempting to encode strings as ISO-8859-1 if possible. ZBar defaults to trying to decode them as Big5 first. Most of the time everything works fine.

Let's take a test string from ZBar: "Märchenbücher". When we encode it as ISO-8859-1, we're going to get two high-byte, low-byte sequences: E4 72 for "är" and FC 63 for "üc". The latter sequence maps to a "user defined" character in Big5, and therefore glibc refuses to convert it. However, musl converts it just fine. As a result, ZBar decodes the string as Big5, to "M酺chenb𡡷her".

You could argue that musl behaves wrong. However, note that the former sequence is valid in Big5. So if you shorten the string to just "Märchen", glibc would happily decode its ISO-8859-1 #encoding as Big5, giving you "M酺chen". And yes, if I put that test string into SegNo, I get a QRCode that reproduces the problem on a glibc system.

Does ZBar behave wrong here? Or perhaps SegNo should avoid ISO-8859-1 altogether, and use safer UTF-8 encoding?

https://bugs.gentoo.org/923233
https://github.com/heuer/segno/issues/134
https://github.com/mchehab/zbar/issues/281

#ZBar is a #barcode reader suite.

ZBar can read many forms of barcodes, including #ISBN, #EAN, #UPC, and #QR codes. ZBar features two programs which can detect and decode barcodes, one that operates on images, and another which operates on video4linux streams like webcams. The results of both are printed to stdout, allowing them to be piped into other programs easily.

Website 🔗️: https://github.com/mchehab/zbar (fork)

apt 📦️: zbar-tools

#free #opensource #foss #fossmendations