From gdo at leader.it Sat Feb 3 01:21:14 2018 From: gdo at leader.it (Guido Brugnara) Date: Sat, 3 Feb 2018 10:21:14 +0100 (CET) Subject: [Italia-pm] Microservizi e disintegrazione In-Reply-To: References: <1516742881.41242.1245731952.5B1D4EF9@webmail.messagingengine.com> Message-ID: <1194642751.952.1517649674647.JavaMail.zimbra@leader.it> Sempre che nel corso dell'anno non si cambi nuovamente, dal 1 gen 2019 entrer? in vigore la Web Tax che tasser? le transazioni Web B2B con il 3% dell'importo transato. Questa gabella andr? applicata a ciascuna transazione, quindi per coloro che creano valore aggiunto erogando servizi ed utilizzando a loro volta dei servizi di terzi, la tassa peser? pi? volte nella determinazione del prezzo al committente finale. Nel calcolo della convenienza all'uso dei Microservizi in Italia, egogati da terzi, a fine anno ci sar? anche questa variabile da considerare. bye gdo From nonsolosoft at diff.org Sat Feb 3 02:08:18 2018 From: nonsolosoft at diff.org (Ferruccio Zamuner) Date: Sat, 3 Feb 2018 11:08:18 +0100 Subject: [Italia-pm] servizi B2B e crypto valute (Was: Re: Microservizi e disintegrazione) In-Reply-To: <1194642751.952.1517649674647.JavaMail.zimbra@leader.it> References: <1516742881.41242.1245731952.5B1D4EF9@webmail.messagingengine.com> <1194642751.952.1517649674647.JavaMail.zimbra@leader.it> Message-ID: <40041825-34bc-3c84-7204-aad7deb879a7@diff.org> Ciao Guido, grazie della notizia di cui non ero informato. Da essa deduco la corsa che stanno facendo sulle cripto valute in ambito pubblicitario ad esempio sugli AdToken. Transando in AdToken durante gli scambi B2B potrebbero lecitamente repilogare l'importo mensile e dichiararlo come una sola transazione monetaria in euro o dollari mensile. Oppure evaderlo se rimane tutto contabilizzato all'interno di crypto valute. Ciao, \ferz On 03/02/2018 10:21, Guido Brugnara wrote: > Sempre che nel corso dell'anno non si cambi nuovamente, dal 1 gen 2019 entrer? in vigore la Web Tax che tasser? le transazioni Web B2B con il 3% dell'importo transato. > Questa gabella andr? applicata a ciascuna transazione, quindi per coloro che creano valore aggiunto erogando servizi ed utilizzando a loro volta dei servizi di terzi, la tassa peser? pi? volte nella determinazione del prezzo al committente finale. > > Nel calcolo della convenienza all'uso dei Microservizi in Italia, egogati da terzi, a fine anno ci sar? anche questa variabile da considerare. > > bye > gdo From gdo at leader.it Sat Feb 24 12:08:11 2018 From: gdo at leader.it (Guido Brugnara) Date: Sat, 24 Feb 2018 21:08:11 +0100 (CET) Subject: [Italia-pm] Bug nel modulo Encode::GSM0338 ? Message-ID: <294320590.1331.1519502891211.JavaMail.zimbra@leader.it> Nell'utilizzare il modulo Encode::GSM0338 ho riscontrato che se si codifica il carattere "@" (code 0x00) la conversione da "gsm0338" non ? corretta. Nella documentazione infatti c'? scritto: "Mapping \x00 to '@' causes too much pain everywhere" Quale alternativa potrei utilizzare che non sia bacata come Encode::GSM0338? bye gdo NOTE: Usando questo codice di esempio ___________________________________________ #!/usr/bin/perl use Encode qw/encode decode/; sub Ord { my $str = shift; my @list; for my $c (split //, $str) { push @list, ord($c); } return join ' ', @list; } sub Test { my($mess, $str) = @_; my $gsm0338 = encode('gsm0338', $str); print "$mess\nencode('gsm0338', '$str') --> ".Ord($gsm0338)."\n"; print "decode('gsm0338', encode('gsm0338', '$str')) --> '".decode('gsm0338', $gsm0338)."'\n\n"; } Test 'Con il solo carattere @ tutto ok:', '@'; Test 'Con due caratteri @, ritorna una stringa vuota', '@@'; Test 'Se dopo il singolo carattere @ segue un carattere normale tutto ok', 'a at b'; Test 'Se dopo il singolo carattere @ segue un carattere speciale la riconversione ? errata', 'a@|?'; ___________________________________________ ... ottengo l'output: ___________________________________________ Con il solo carattere @ tutto ok: encode('gsm0338', '@') --> 0 decode('gsm0338', encode('gsm0338', '@')) --> '@' Con due caratteri @, ritorna una stringa vuota encode('gsm0338', '@@') --> 0 0 decode('gsm0338', encode('gsm0338', '@@')) --> '' Se dopo il singolo carattere @ segue un carattere normale tutto ok encode('gsm0338', 'a at b') --> 97 0 98 decode('gsm0338', encode('gsm0338', 'a at b')) --> 'a at b' Se dopo il singolo carattere @ segue un carattere speciale la riconversione ? errata encode('gsm0338', 'a@|?') --> 97 0 27 64 27 101 Wide character in print at test.pl line 17. decode('gsm0338', encode('gsm0338', 'a@|?')) --> 'a@ ??' ___________________________________________ Da cui si vede bene che la codifica inversa non funziona. From gdo at leader.it Sun Feb 25 02:43:31 2018 From: gdo at leader.it (Guido Brugnara) Date: Sun, 25 Feb 2018 11:43:31 +0100 (CET) Subject: [Italia-pm] Bug nel modulo Encode::GSM0338 ? In-Reply-To: <294320590.1331.1519502891211.JavaMail.zimbra@leader.it> References: <294320590.1331.1519502891211.JavaMail.zimbra@leader.it> Message-ID: <1610340162.677.1519555411880.JavaMail.zimbra@leader.it> ----- Il 24-feb-18, alle 21:08, Guido Brugnara gdo at leader.it ha scritto: > Nell'utilizzare il modulo Encode::GSM0338 ho riscontrato che se si codifica il > carattere "@" (code 0x00) la conversione da "gsm0338" non ? corretta. > Nella documentazione infatti c'? scritto: > "Mapping \x00 to '@' causes too much pain everywhere" > > Quale alternativa potrei utilizzare che non sia bacata come Encode::GSM0338? In attesa di una soluzione pi? pulita ho escogitato un work-around: use utf8; my $gsm0338 = 'test ..@@@?..'; my $out; while(1){ my $zpos = index $gsm0338, "\0"; if($zpos == -1){ $out .= decode('gsm0338', $gsm0338); last; }else{ my $left = substr $gsm0338, 0, $zpos; $out .= decode('gsm0338', $left).'@'; $gsm0338 = substr $gsm0338, $zpos + 1; } length($gsm0338) || last; } print $out,"\n"; bye gdo > > bye > gdo > > NOTE: Usando questo codice di esempio > ___________________________________________ > #!/usr/bin/perl > > use Encode qw/encode decode/; > > sub Ord { > my $str = shift; > my @list; > for my $c (split //, $str) { push @list, ord($c); } > return join ' ', @list; > } > > sub Test { > my($mess, $str) = @_; > my $gsm0338 = encode('gsm0338', $str); > print "$mess\nencode('gsm0338', '$str') --> ".Ord($gsm0338)."\n"; > print "decode('gsm0338', encode('gsm0338', '$str')) --> '".decode('gsm0338', > $gsm0338)."'\n\n"; > } > > Test 'Con il solo carattere @ tutto ok:', '@'; > > Test 'Con due caratteri @, ritorna una stringa vuota', '@@'; > > Test 'Se dopo il singolo carattere @ segue un carattere normale tutto ok', > 'a at b'; > > Test 'Se dopo il singolo carattere @ segue un carattere speciale la > riconversione ? errata', 'a@|?'; > ___________________________________________ > > ... ottengo l'output: > ___________________________________________ > Con il solo carattere @ tutto ok: > encode('gsm0338', '@') --> 0 > decode('gsm0338', encode('gsm0338', '@')) --> '@' > > Con due caratteri @, ritorna una stringa vuota > encode('gsm0338', '@@') --> 0 0 > decode('gsm0338', encode('gsm0338', '@@')) --> '' > > Se dopo il singolo carattere @ segue un carattere normale tutto ok > encode('gsm0338', 'a at b') --> 97 0 98 > decode('gsm0338', encode('gsm0338', 'a at b')) --> 'a at b' > > Se dopo il singolo carattere @ segue un carattere speciale la riconversione ? > errata > encode('gsm0338', 'a@|?') --> 97 0 27 64 27 101 > Wide character in print at test.pl line 17. > decode('gsm0338', encode('gsm0338', 'a@|?')) --> 'a@ ??' > ___________________________________________ > > Da cui si vede bene che la codifica inversa non funziona. From polettix at gmail.com Sun Feb 25 07:55:32 2018 From: polettix at gmail.com (Flavio Poletti) Date: Sun, 25 Feb 2018 16:55:32 +0100 Subject: [Italia-pm] Bug nel modulo Encode::GSM0338 ? In-Reply-To: <1610340162.677.1519555411880.JavaMail.zimbra@leader.it> References: <294320590.1331.1519502891211.JavaMail.zimbra@leader.it> <1610340162.677.1519555411880.JavaMail.zimbra@leader.it> Message-ID: Il giorno 25 febbraio 2018 11:43, Guido Brugnara ha scritto: > > ----- Il 24-feb-18, alle 21:08, Guido Brugnara gdo at leader.it ha scritto: > > > Nell'utilizzare il modulo Encode::GSM0338 ho riscontrato che se si codifica il > > carattere "@" (code 0x00) la conversione da "gsm0338" non ? corretta. > > Nella documentazione infatti c'? scritto: > > "Mapping \x00 to '@' causes too much pain everywhere" > > > > Quale alternativa potrei utilizzare che non sia bacata come Encode::GSM0338? > > In attesa di una soluzione pi? pulita ho escogitato un work-around: Guardando il modulo e lo standard mi sembra che facciano due cose piuttosto differenti. Ad esempio, il GSM 03.38 prevede che ciascun carattere consentito sia codificato con 7 bit, ma che poi vengano trasmessi ottetti (il che consente di ottenere i famosi 160 caratteri da un pezzo di canale in grado di mandare 140 ottetti). Se stai leggendo SMS direttamente da un dispositivo, o li devi mandare ad un dispositivo, probabilmente quel modulo non ? quello giusto. Cosimo ha pubblicato Device::GSM dove forse puoi trovare qualcosa pi? in linea con lo standard (https://metacpan.org/pod/Device::Gsm). Ciao, Flavio. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdo at leader.it Sun Feb 25 08:32:47 2018 From: gdo at leader.it (Guido Brugnara) Date: Sun, 25 Feb 2018 17:32:47 +0100 (CET) Subject: [Italia-pm] Bug nel modulo Encode::GSM0338 ? In-Reply-To: References: <294320590.1331.1519502891211.JavaMail.zimbra@leader.it> <1610340162.677.1519555411880.JavaMail.zimbra@leader.it> Message-ID: <19026101.1272.1519576367193.JavaMail.zimbra@leader.it> ----- Il 25-feb-18, alle 16:55, Flavio Poletti ha scritto: > Il giorno 25 febbraio 2018 11:43, Guido Brugnara < gdo at leader.it > ha scritto: > > ----- Il 24-feb-18, alle 21:08, Guido Brugnara gdo at leader.it ha scritto: > > > Nell'utilizzare il modulo Encode::GSM0338 ho riscontrato che se si codifica il > > > carattere "@" (code 0x00) la conversione da "gsm0338" non ? corretta. > > > Nella documentazione infatti c'? scritto: > > > "Mapping \x00 to '@' causes too much pain everywhere" > > > Quale alternativa potrei utilizzare che non sia bacata come Encode::GSM0338? > > In attesa di una soluzione pi? pulita ho escogitato un work-around: > Guardando il modulo e lo standard mi sembra che facciano due cose piuttosto > differenti. > Ad esempio, il GSM 03.38 prevede che ciascun carattere consentito sia codificato > con 7 bit, ma che poi vengano trasmessi ottetti (il che consente di ottenere i > famosi 160 caratteri da un pezzo di canale in grado di mandare 140 ottetti). Se > stai leggendo SMS direttamente da un dispositivo, o li devi mandare ad un > dispositivo, probabilmente quel modulo non ? quello giusto. Quel che devo fare ? inviare ad un provider dei messaggi contenenti soltanto caratteri ammessi dal charset GSM 03.38 ma li devo comunque inviare UTF8. Devo anche calcolare il costo (quindi il numero di SMS necessari) e perci? devo calcolare quanto sar? lungo il messaggio codificato. Guardando il codice in Device::Gsm c'? annotato "content => 'text-only for now'" e infatti nell'implementazione di Device::Gsm::Charset non c'? traccia di tutti i caratteri speciali codificati in due byte utilizzando ESC; manca ad esempio il simbolo ? (Euro). Purtroppo per questo non lo posso utilizzare. La tabella a cui mi devo attenere ? questa: https://en.wikipedia.org/wiki/GSM_03.38#Spanish_language_(Latin_script) Il moduloEncode::GSM0338 converte i caratteri usando proprio questa codifica e funziona a parte il problema riscontrato con il carattere @, che aggiro con il codice che ho mostrato nella mail precedente. bye gdo > Cosimo ha pubblicato Device::GSM dove forse puoi trovare qualcosa pi? in linea > con lo standard ( https://metacpan.org/pod/Device::Gsm ). > Ciao, > Flavio. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdo at leader.it Sun Feb 25 08:42:29 2018 From: gdo at leader.it (Guido Brugnara) Date: Sun, 25 Feb 2018 17:42:29 +0100 (CET) Subject: [Italia-pm] Bug nel modulo Encode::GSM0338 ? In-Reply-To: <19026101.1272.1519576367193.JavaMail.zimbra@leader.it> References: <294320590.1331.1519502891211.JavaMail.zimbra@leader.it> <1610340162.677.1519555411880.JavaMail.zimbra@leader.it> <19026101.1272.1519576367193.JavaMail.zimbra@leader.it> Message-ID: <1968206171.1302.1519576949738.JavaMail.zimbra@leader.it> ----- Il 25-feb-18, alle 17:32, Guido Brugnara ha scritto: > ........................ > La tabella a cui mi devo attenere ? questa: > https://en.wikipedia.org/wiki/GSM_03.38#Spanish_language_(Latin_script) Oops; una rettifica del link. Quello corretto ? questo: https://en.wikipedia.org/wiki/GSM_03.38#GSM_7-bit_default_alphabet_and_extension_table_of_3GPP_TS_23.038_/_GSM_03.38 bye gdo -------------- next part -------------- An HTML attachment was scrubbed... URL: From cosimo+perl at streppone.it Sun Feb 25 08:45:45 2018 From: cosimo+perl at streppone.it (Cosimo Streppone) Date: Sun, 25 Feb 2018 17:45:45 +0100 Subject: [Italia-pm] Bug nel modulo Encode::GSM0338 ? In-Reply-To: References: <294320590.1331.1519502891211.JavaMail.zimbra@leader.it> <1610340162.677.1519555411880.JavaMail.zimbra@leader.it> Message-ID: <1519577145.1820899.1282731728.0E66FFFA@webmail.messagingengine.com> On Sun, Feb 25, 2018, at 16:55, Flavio Poletti wrote: > Ad esempio, il GSM 03.38 prevede che ciascun carattere consentito sia > codificato con 7 bit, ma che poi vengano trasmessi ottetti (il che > consente di ottenere i famosi 160 caratteri da un pezzo di canale in > grado di mandare 140 ottetti). Se stai leggendo SMS direttamente da un > dispositivo, o li devi mandare ad un dispositivo, probabilmente quel > modulo non ? quello giusto. In realta', la situazione e' molto piu' intricata. Da quel che ricordo, ogni produttore ha la sua idea di GSM-0338 e sono stati inventate diverse estensioni incompatibili, una sorta di DOS codepage in versione moderna. > Cosimo ha pubblicato Device::GSM dove forse puoi trovare qualcosa pi? > in linea con lo standard (https://metacpan.org/pod/Device::Gsm). Eh, magari. Ci ho provato, ma gia' allora avevo problemi a trovare una codifica che funzionasse decentemente con almeno due modelli diversi di telefono... -- Cosimo -------------- next part -------------- An HTML attachment was scrubbed... URL: