devel.cz

Takze mne sa to podarilo "hacknut". Podotykam, ze "konecne", vid datum predchadzajuceho prispevku :( (3 roky dozadu ...)

Aby sa dalo tu specifikaciu pochopit, je este potrebne stiahnut schemu: https://www.bsqr.co/schema/

Idea spociva v tom, ze ta schema specifikuje pozicie jednotlivych poloziek (bsqr:order pricom bsqr je namespace "http://www.bysquare.com/bysquare"), cisluje sa to od 1. V pripade, ze na danej pozicii je "komplexny typ" (zaznam), obsah daneho komplexneho typu sa vlozi na prislusne miesto. V pripade ze tam je zoznam jednej alebo viacerych rovnakych poloziek alebo polozka ktora tam moze a nemusi byt, najprv sa vlozi cislo oznamujuce pocet poloziek (moze byt 0) a az potom prislusny pocet poloziek. Oddelovace su tabulatory a v kazdej polozke typu string sa tabulatory nahradia medzerami. Je to dost "confusing".

Priklad jednoduchej platby (v {} su moje komentare, v konecnom stringu nie su a "[tab]" je tabulator):

PAYMENT{identifikator ktory si mozete dat aky chcete, sluzi na identifikaciu platby}[tab]1{1 platba}[tab]1{obycajny platobny prikaz}[tab]19.99{kolko zaplatit}[tab]EUR{v akej mene zaplatit}[tab]20180529{datum odoslania platby je 29. maj 2018}[tab]1234567890{variabilny symbol, 10 cislic}[tab]1188{konstantny symbol podla ciselnika, 4 cislice}[tab]2323{specificky symbol podla ciselnika}[tab]{predosle 3 udaje v SEPA formate, v tomto pripade sa neuvadzaju pretoze uz su v predoslych 3 polozkach}[tab]Sprava pre prijimatela{text ktory sa objavi prijimatelovi v poli "popis transakcie" (myslim)}[tab]1{1 ucet}[tab]SK5111000000002922782343{cislo uctu v IBAN formate}[tab]TATRSKBX{SWIFT kod, inak nazyvany aj BIC, musi sediet s bankovym kodom v IBAN ucte}[tab]0{nie je trvaly pracovny prikaz}[tab]0{nie je inkaso}[tab]Nazov prijemcu[tab]Adresa prijemcu, riadok 1[tab]Adresa prijemcu riadok 2

Po zoserializovani tychto dat treba spocitat CRC32 vysledneho retazca a prependnut ako 4 binarne bajty pred tento string (takze vysledok bude ). Potom treba vytvorit LZMA1 kompresor (v tej specifikacii je chyba, hovoria, ze "algoritmus je LZMA" a v "encoding process overview" je uvedene "value sequence compressed by LZMA2" spravne to ma byt LZMA1; LZMA sice moze byt iba iny nazov pre LZMA1 ale to LZMA2 v tom obrazku je urcite zle), v RAW formate s tymito parametrami: LC=3, LP=0, PB=2, DICT_SIZE=128*1024 (128 KB). Pouzitie XZ by teda vyzeralo asi takto xz -F raw --lzma1=dict=128KiB,lc=3,lp=0,pb=2 preprocessed-string.dat -c >preprocessed-string.out. Z vyslednej skomprimovanej verzie treba odrezat EOF data (robi sa to tak, ze do LZMA1 dekodera sa sukaju bajty az pokym nam z neho nevylezie cely povodny string, bajty ktore sme sukat nemuseli (moj odhad je, ze tak 6-7 bajtov zostane) sa zahodia (toto je dovod preco ten algoritmus MUSI byt LZMA1, LZMA2 takyto typ "skracovania skomprimovanych dat" nepodporuje).

K takto skomprimovanemu stringu sa prida predpona skladajuca sa zo 4 bajtov. Prve 2 bajty oznacuju typ dokumentu, verziu atd (je popisane v tej specifikacii) a zvysne 2 bajty obsahuju dlzku povodneho stringu v little endian formate (nizsi byte prvy). Tento vysledny binarny string sa potom rozseka na 5-bitove kusky, ktore sa podla tabulky (Table 9 v 3.13) skonvertuju na znaky. Vysledok je "binarny slovensky string na zakodovanie do QR kodu".

Dekodovanie sa potom robi tak, ze sa vytvori RAW LZMA1 dekoder s uvedenymi parametrami (-F raw --lzma1=dict=128KiB,lc=3,lp=0,pb=2) a sukaju sa donho skomprimovane data az kym z neho nevylezie prislusny pocet bajtov (kolko ich ma byt sa dozvieme z tretieho a stvrteho bajtu). Potom sa podla CRC32 z dekomprimovanych dat skontroluje, ci to co vyliezlo je naozaj to co do kodera vliezlo a ak ano, "bizarny serializacny format" sa skonvertuje do strukturovanych platobnych dat pre pouzitie kde treba. No obvykle asi nebudete chciet dekodovanie riesit (teda pokial nechcete robit nejaky internet banking app alebo nieco podobne).

Mam podozrenie, ze ten "EOF chvost" tych komprimovanych dat v skutocnosti zahadzovat netreba ale vysledny string moze byt tak dlhy, ze sa nam "kompletny LZMA1 stream" to kodu nevopcha, ten "EOF chvost" je totiz dost dlhy, podstatne dlhsi ako tie 2 bajty dlzky.