101010.pl

mgorny-nyan (on) :autism:🙀🚂🐧Odkryłem ciekawy bug w <a href="https://pol.social/tags/ZBar" class="mention hashtag" rel="nofollow noopener" target="_blank">#ZBar</a>, debugując błąd testów paczki <a href="https://pol.social/tags/SegNo" class="mention hashtag" rel="nofollow noopener" target="_blank">#SegNo</a> (generator <a href="https://pol.social/tags/QRCode" class="mention hashtag" rel="nofollow noopener" target="_blank">#QRCode</a> w Pythonie), na <a href="https://pol.social/tags/Gentoo" class="mention hashtag" rel="nofollow noopener" target="_blank">#Gentoo</a>, z <a href="https://pol.social/tags/musl" class="mention hashtag" rel="nofollow noopener" target="_blank">#musl</a> 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?<a href="https://bugs.gentoo.org/923233" rel="nofollow noopener" translate="no" target="_blank">https://bugs.gentoo.org/923233</a> <a href="https://github.com/heuer/segno/issues/134" rel="nofollow noopener" translate="no" target="_blank">https://github.com/heuer/segno/issues/134</a> <a href="https://github.com/mchehab/zbar/issues/281" rel="nofollow noopener" translate="no" target="_blank">https://github.com/mchehab/zbar/issues/281</a><a href="https://pol.social/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#Python</a> <a href="https://pol.social/tags/kodowanie" class="mention hashtag" rel="nofollow noopener" target="_blank">#kodowanie</a>

mgorny-nyan (he) :autism:🙀🚂🐧Fun bug in <a href="https://social.treehouse.systems/tags/ZBar" class="mention hashtag" rel="nofollow noopener" target="_blank">#ZBar</a> discovered while debugging a <a href="https://social.treehouse.systems/tags/SegNo" class="mention hashtag" rel="nofollow noopener" target="_blank">#SegNo</a> (<a href="https://social.treehouse.systems/tags/Python" class="mention hashtag" rel="nofollow noopener" target="_blank">#Python</a> <a href="https://social.treehouse.systems/tags/QRCode" class="mention hashtag" rel="nofollow noopener" target="_blank">#QRCode</a> generator library) test failure on <a href="https://social.treehouse.systems/tags/Gentoo" class="mention hashtag" rel="nofollow noopener" target="_blank">#Gentoo</a> with <a href="https://social.treehouse.systems/tags/musl" class="mention hashtag" rel="nofollow noopener" target="_blank">#musl</a> 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 <a href="https://social.treehouse.systems/tags/encoding" class="mention hashtag" rel="nofollow noopener" target="_blank">#encoding</a> 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?<a href="https://bugs.gentoo.org/923233" rel="nofollow noopener" translate="no" target="_blank">https://bugs.gentoo.org/923233</a> <a href="https://github.com/heuer/segno/issues/134" rel="nofollow noopener" translate="no" target="_blank">https://github.com/heuer/segno/issues/134</a> <a href="https://github.com/mchehab/zbar/issues/281" rel="nofollow noopener" translate="no" target="_blank">https://github.com/mchehab/zbar/issues/281</a>

Recent searches

Search options

Administered by:

Server stats:

#segno