Personal encryption / Crittografia personale

CrittografASCII.exe, the utility I implemented for me, is useful for everyone who want maintain secret its own texts. For it is based on two absolutely atypical algorithms, both different from all till now known, the encrypted texts are very difficult to be decrypted at least by people they don’t’ have this program (and the encryption code, of course).

The program can be downloaded from:

http://www.giannigiaccaglini.it/download/CrittografASCII.zip

How use it

After unzipping CrittografASCII.zip the CrittografASCII.exe can be launched in PCs with Vista/Win7 operating systems or at least Windows XP with Xpack 3.0. It is a windows Form similar to the following:

The (few) texts are in Italian, included the demo one in the multiline textbox on the left, which can be modified substituting it with every other text. Also very clear I the meaning of button ‘s text “Cripta” (Crypt it), witch becomes “Decripta”(Decrypt it) after encrypting operation.

Two word about algorytms I used

They are combined together. The former encrypts numeric characters in other numeric chars. So if an hypothetical powerful decrypting tool attempts to retrieve an original “D-day will be at 17-6 in 1234 site” from the “G-j#k p#c~ @p xy 30-2l s 2085 w§tf” my program encrypted it could find something like “D-day will be at çù?yj in èò$/% site “. Maybe a suspect arises on digit-to-digit translation? Yes but retrieving original number is about impossible, even with simple transliteration criteria used, because generally number meaning is neutral.

The latter criterion is applied to letters, by transliterations varying in pseudo-random sequence, because they depend not only by the encryption key but by the various lettere of the text itself, too.

FOR PEOPLE INTERESTED IN CUSTOMIZED VERSIONS AND/OR VB LISTING (FOR CHEAP CHARGE…):

Gianni Giaccaglini giannigiac@tin.it

LEGGETE ANCHE GLI ARTICOLI!!! L’ultimo al link:

http://blog.shareoffice.it/giannigiaccaglini/articles/10324.aspx

I bachi inattesi? Colpa della Semantica, signori miei...

Questo post, frivolo nell’esemplificazione che darò, pretende in modo alquanto serioso di discutere su un problema che affligge l’Informatica e non solo. Parlo della Semantica, disciplina linguistica che si occupa del significato di un testo, meaning in inglese. Di sfuggita cito solo un interrogativo provocatorio (che riprendo – se non ricordo male - dal ponderoso trattato di Semiotica generale di Umberto Eco): The meaning of the meaning che diavolo è?

In due parole, alla buona, la faccenda ha a che fare - nella vita o peggio ancora nella giurisprudenza - coi molti fraintendimenti derivanti dalla più o meno evitabile divaricazione fra i significati letterali e quelli intenzionali (cosiddetti). In gergo semiotico si tenta una distinzione fra denotazione e connotazione di un messaggio.

Venendo allo specifico dell’Informatica sono noti i fallimenti di certi settori avanzati. Tipicamente l’Intelligenza Artificiale (IA) o un suo figliolo, la traduzione automatica. L’IA ogni tanto viene ri-chiamata in ballo ma oggi dei tanto celebrati Sistemi Esperti quasi nessuno parla più. La seconda da qualche tempo partorisce qualche topolino non del tutto privo di utilità, però ognuno di noi ha quotidianamente modo di ridacchiare di fronte a certi risultati del pur potente traduttore di Google...

Il frivolo esempio: ruotine eliminare cifre da una stringa

Appartiene all’autobiografia recente. Volevo una routinetta volta a eliminare i caratteri numerici da una stringa. Ed ecco una serie di tentativi infruttuosi di specifiche Sub, prima in VBA poi in Visual Basic 2008, che ho corredato con istruzioni messaggistiche opportune per facilitarne l’esecuzione passo dopo passo a chi legge.

Prima versione

Sub EliminaCifre()

    Dim MiaStr As String, Car As String, i As Integer

    MiaStr = "Amba12raba2345cicci178"

    For i = 1 To Len(MiaStr)

        Car = Mid(MiaStr, i, 1)

        If IsNumeric(Car) Then

            MiaStr = Replace(MiaStr, Car, "")

        End If

        MsgBox("i = " & i & vbLf & "Car = " _

        & Car & vbLf & "MiaStr = " & MiaStr)

    Next

    MsgBox(("Stringa finale: " & MiaStr)

End Sub

Lanciando la procedurina si notano due stranezze inattese (per gente ingenua come molti di noi siamo):

• non tutte le cifre vengono eliminate e l’MsgBox conclusivo proclama “Stringa finale:  ambaraba34cicci8”;
• il ciclo va avanti fino a i = 22 (la Len iniziale della stringa), indicando caratteri vuoti (blank) negli ultimi passaggi.

Dopo riflessione mi sono reso conto che il guaio deriva dal fatto che lunghezza della MiaStr diminuisce di un’unità ad ogni rimpiazzo di una cifra con “” (Replace(MiaStr, Car, “”). La pezza (patch) è presto trovata.

Seconda versione

Sub EliminaCifreBIS()

    Dim MiaStr As String, Car As String, i As Integer

    MiaStr = "Amba12raba2345cicci178"

    For i = 1 To Len(MiaStr)

        Car = Mid(MiaStr, i, 1)

        If IsNumeric(Car) Then

            MiaStr = Replace(MiaStr, Car, "")

            i = i - 1

        End If

        MsgBox ("i = " & i & vbLf & "Car = " _

        & Car & vbLf & "MiaStr = " & MiaStr)

    Next

    MsgBox ("Stringa finale: " & MiaStr)

End Sub

L’aggiunta, evidenziata in giallo, è semplicemente la correzione i = i - 1 ogni volta che una cifra è rimpiazzata. Ci potremmo accontentare, visto che il risultato ora è corretto, anche se resta la seconda anomalia.

Da queste come da altre esperienza si evince facilmente il principio enunciato in apertura, che nel caso del software, tradurrei nella legge seguente:

In Informatica è la Semantica lo scoglio in cui s’infrangono molti prodotti, a causa della discrasia non sempre evitabile fra l’intenzionalità dell’uomo e la fredda, inesorabile logica letterale della macchina.

Visual Studio 2008: mondo nuovo, altra sorpresa

In tale ambiente ho poi testato il precedente programmetto. Funzionava, ma poi pur non essendo un benpensante ho... ben pensato di sostituire Car As String con Car As Char (non supportato in VBA o VB6) più moderno e logico, visto che si tratta di un singolo carattere. Già che c’ero, ho approfittato della possibilità di accedere con un indice a ciascun carattere di una stringa, con Car = MiaStr(i).

Terza versione (VB 2008)

Sub EliminaCifre()

    Dim MiaStr As String, Car As Char, i As Integer

    MiaStr = "Amba12raba2345cicci178"

    For i = 0 To Len(MiaStr) - 1

        Car = MiaStr(i)

        If IsNumeric(Car) Then

            Mid(MiaStr, i, 1) = Replace(MiaStr, Car, "")

            i -= 1

        End If

        MessageBox.Show("i = " & i & vbLf & "Car = " _

        & Car & vbLf & "MiaStr = " & MiaStr)

    Next

    MessageBox.Show("Stringa finale: " & MiaStr)

End Sub

Tutto bene? Macché. L’illusione semantica stavolta naufraga in modo, come sempre, inatteso. Infatti non si procede con tutti i 22 giri del loop For i = 0 To Len(MiaStr) ... Next in quanto ahimè il programma si arresta per errore a run-time sulla tanto ammirata istruzione moderna Car = MiaStr(i), con indicazione di indice fuori dai limiti.

Riflettendo adeguatamente comprendiamo che:

• il ciclo For... To Next del Visual Basic (a differenza di altri linguaggi, credo) valuta una tantum l’espressione all’inizio e ne mantiene il valore in tutto il suo corso (in altri casi questa è una virtù, ma qui ci crea un guaio);
• Mid(MiaStr, i, 1) è permissivo al punto di non dare errore se l’indice va fuori della stringa (semplicemente restituisce un blank); al contrario di Car(i), che invece considera la stringa come un vettore di caratteri.

Soluzione finale

Ne riporto il nocciolo, astenendomi dal commentare altre varianti “moderne”, dicendo solo che alla fine ho adottato un ciclo While ... End While (While... Wend in VBA/VB6) che è immune dalla persistenza della lunghezza imputabile a For... Next e, pertanto, fa sì che MiaStr.Length muti dinamicamente ad ogni giro dell’anello.

   Dim i = 0

   While i < MiaStr.Length

       Car = MiaStr(i)

       CodCar = Char.ConvertToUtf32(Car, 0)

       If Not (CodCar < 48 Or CodCar > 57) Then

           MiaStr = MiaStr.Replace(Car, "")

           i -= 1

       End If

       i += 1

   End While

Considerazioni fuori programma (rispetto alle macro e all'IT)

Sperando di non disturbare la suscettibilità o la commiserazione di chicchessia, mi permetto alcune osservazioni spicciole su tre celebri antinomie (senza pretesa di essere esaustivo né di aver fatto scoperte originali o peggio di non commettere errori).

Premetto che i vari casi mi paiono afflitti da un limite della logica, almeno “normale” (ossia degli Enunciati) quando pretende di considerare il tempo...

ACHILLE E LA TARTARUGA

Considerare unità di tempo piccole a piacere è legittimo, ma non lo è aggiungerne di sempre più piccole concludendo con MAI. Infatti nel primo caso, per quanto piccoli siano gl’intervalli temporali Achille supererà di certo la tartaruga in un numero finito di essi.

IL CRETESE

Non è possibile, per coerenza, che un perfetto mentitore dica “tutto quel che dico è falso”, potrà semmai affermare “tutto quel che dico è vero”. Dopo di che, sospettato ingiustamente di un  delitto capitale risponderà sì alla domanda “Sei tu il colpevole?”, senza la soddisfazione di poter affermare, sul patibolo, “Muoio per amore della Menzogna!”. [O forse “Muoio per amore della verità” è un’antinomia? Boh].

IL BARBIERE

L’editto “Il barbiere deve radere tutti quelli che non si fanno la barba da soli” presenta almeno un’ambiguità: è lecito farsi radere da un altro? Immaginiamo che alla specifica richiesta di chiarimento – come sempre accade nelle norme giuridiche o assimilabili che richiedono interpretazioni “autentiche” sullo spirito di una legge – il Sovrano cambi la dizione in “Tutti gli abitanti si debbono radere da soli o farsi radere dal barbiere”, che, senza chiarire esplicitamente che cosa deve fare il barbiere,  esclude la possibilità di ricorrere ad altri che non sia il barbiere. A parte il fatto che resta oscura e comunque ardua la possibilità di sanzione, esclusa la fragranza (ma se uno è sbarbato che si fa?), e tralasciando l’ipotesi di un barbiere eunuco o femmina, il punto a mio avviso è che il barbiere ha un duplice ruolo: cittadino e funzionario-barbitonsore (senza essere schizofrenico: tutti hanno ruoli molteplici in un consesso sociale). E scegliendo di radersi da solo, come cittadino, subito DOPO toglie a se stesso, cioè al barbiere, il compito di farlo.

CIRCUITI LOGICI SEQUENZIALI

Mi permetto di insistere coi Logici puri (che finora non mi hanno dato retta...). I circuiti logici sequenziali (elettronici o, persino, implementati con relè e contatti) hanno un comportamento che varia nel tempo, presentando cioè una isteresi appunto temporale. Ne sono esempi noti anche a chi ne ignora le connessioni (di tipo feedback) i circuiti memoria (come i flip-flop) o gli oscillatori. I tecnici per descriverli e progettarli adottano una particolare – ma semplice nei casi elementari - Algebra booleana, in cui sono in gioco NEGAZIONI delle uscite riportate in input. Ad esempio con un X  = not Y ove X e Y sono, rispettivamente l’input e l’output si ottiene sulla carta ma anche di fatto un oscillatore di periodo pari al tempo che separa Y e X.

Dunque “in natura” le antinomie sono di fatto risolte. O no?

Buon 2010 !

P.S. – Aggiungo che l’astrattezza della logica rispetto alla lebenswelt (mondo della vita) si fa sentire anche in altri contesti ove siano in gioco verbi riflessivi. Provare per ridere, con “sputarsi” o, peggio, con “masturbarsi”. O, in genere, con verbi che ammettono solo forma riflessiva...

ANNUNCIO AI LETTORI CHE NON LO TROVAVANO PIU':

Il libro EXCEL E OFFICE VBA è stato ristampato: http://www.hoepli.it/libro/excel-office-vba.asp?ib=9788820335373&pc=00002200

Novità Office 2010 su VBA e Ribbon personalizzabile

E ahimè perdura il BUG di FileSearch (v. in fondo al post)

Una domanda un po’ angosciante che ci poniamo tutti noi che amiamo le macro è la seguente: il linguaggio VBA verrà mantenuto? La risposta, a quanto ho potuto constatare sulla BETA che ho scaricat, è affermativa, garantendo così la compatibilità con gli attuali modelli dotati di macro. Invece si direbbe dubbia l’idea che il VBA possa essere migliorato e potenziato, magari in accordo col Visual Basic .NET...

In attesa di notizie più precise riferisco qui la curiosa avventura di un beta tester di Office 2010 (inglese), che inizia con una scoperta preoccupante, che però poi termina con un lieto fine. In due parole, il nostro amico dapprima non riesce a trovare la scheda (tab in inglese) relativa alle macro (Sviluppo, in Office 2007, peraltro anch’essa da visualizzare esplicitamente anche nel vecchio mondo) né a zompare nell’Editor Visual Basic con la familiare scorciatoia Alt+F11 [Ma qui il ns. amico si sbaglia! G.G.].

Ma niente paura!, la buona notizia è che ora la barra multifunzione (Ribbon) è personalizzabile con semplici mosse direttamente dal Ribbon stesso, col lieto fine di riscoprire la tab relativa alle macro.

Ed ecco le manovre necessarie:

1. Clic destro in qualunque punto del Ribbon, che apre varie opzioni come le precedenti Aggiungi alla barra di Accesso rapido, Riduci a icona la barra multifunzione ecc. più la nuova Personalizza la barra mutifunzione (Customize the Ribbon);
2. Scegliere quest’ultima, che a sua volta apre un elenco che comprende tutte le tab standar e pulsanti vari tra cui quelli per Aggiungere una nuova Tab, Aggiungere un nuovo Gruppo, Rinominare;
3. Le tab vecchie e nuove sono raffigurate in modo gerarchico (arborescente con icone “+“, cliccando sulle quali si aprono altri sottomenu relativi ai singoli comandi;
4. In particolare l’opzione che più interessa l’autore (e molti di noi) è Sviluppo (Developer).

Scegliendolo si ottiene, perlomeno in prima battuta, la visualizzazione della scheda Sviluppo solo un po’ diversa da quella attuale.

A questo punto qualcuno dirà “niente di nuovo sotto il sole Office...”. Così descritta la storia infatti rassomiglia molto a quella che si vive in Office 2007, agendo nelle Opzioni di Word o di Excel > Personalizzazioni... per cui la novità sembra consistere solo nella comodità del clic destro direttamente sul Ribbon. Non mi sbilancio del tutto, ma sono propenso a scommettere che si tratti di inedite possibilità di modifica in precedenza scomode se non impossibili.

La questione si può dirimere dal vivo, per farsene un’idea diretta, sulla beta di Office 2010 pro, scaricabile dai link seguenti, entrambi finora relativi all'edizione inglese:

www.microsoft.com/office/2010/en/default.aspx

www.microsoft.com/italy/office2010/index.aspx

Aggiungo ora una MIA impressione iniziale sulla beta testè caricata. Il layout del Ribbon è un po' cambiato, direi razionalizzato. In particolare l'icona Office è sparita e al suo posto si ha un (più classico) menu File. Per il resto, i comandi sembrano identici anche se a volte diversamente dislocati e raffigurati. Anche nel resto non si riscontrano innovazioni, a parte un accresciuto numero di librerie in VBA (quelle attivabili con Strumenti > Riferimenti...) quelle che, diciamolo francamente, solo utenti ultraesperti adottano. Le opzioni classiche sembrerebbero immutate - tabelle, font, cornici, forme e clipArt, classi e numero di funzioni - tutto (o quasi?) come prima... 

Ma è presto per parlare di delusione, anzi penso di sbagliare.

IL PERDURANTE BUG DI FILESEARCH 

L'ho subito segnalato su http://connect.microsoft.com scoprendo di averlo già fatto un paio di anni fa (ve n'è traccia su tale sito, con risposte che rimandano la palla a un altro team...). Non è successo nulla, visto che tale bug rimane pure in Office 2010. Ma ecco di che si tratta:

L’utile comando VBA Application.FileSearch per la ricerca di archivi, presente in Office 2003, è scomparso in Office 2007 e 2010 (beta). Con aspetti imbarazzanti se non grotteschi:

- Se si digita “Application.” “FileSearch” non compare nella lista dell’intelliusense;

- se si insiste con Application.FileSearch e relativi metodi/proprietà tutto sembra accettato ma a run-time si ha ERRORE, pertanto FileSearch non si può utilizzare e falliscono precedenti modelli creati con Office 2003.

Ecco un esempio del genere:

Sub Cercafiles()

  cartella = Range("A1").Value

  nome = Range("B1").Value

  este = Range("C1").Value

  Dim nomefile As String

  With Application.FileSearch

    .NewSearch

    .LookIn = cartella & ""

    .SearchSubFolders = True

    .Filename = "" & nome & "." & este & ""

    If .Execute(SortBy:=msoSortByFileName, _

    SortOrder:=msoSortOrderAscending) > 0 Then

      MsgBox "Ci sono " & .FoundFiles.Count & " file(s) trovati."

      For i = 1 To .FoundFiles.Count

        nomefile = .FoundFiles(I)

        ActiveCell(i) = nomefile

      Next i

    Else

      MsgBox "File(s) non trovato."

    End If

  End With

End Sub

Utile, no? Però funziona solo con Office 2003.

La cosa imbarazzante...

 ... se non ridicola è che non solo tutte le keyword predette vengono regolarmente tradotte con le maiuscole al posto giusto (es. “fiLesEArCH” => “FileSearch”, “neWseaRCh” => “NewSearch”) ma la Guida riporta una gran copia di esempi specifici, NESSUNO dei quali funziona, dopo Office 2003.

L’utile comando VBA Application.FileSearch per la ricerca di archivi, presente in Office 2003, è scomparso in Office 2007 e 2010 (beta). Con aspetti imbarazzanti se non grotteschi:

- Se si digita “Application.” “FileSearch” non compare nella lista dell’intelliusense;

- se si insiste con Application.FileSearch e relativi metodi/proprietà tutto sembra accettato ma a run-time si ha ERRORE, pertanto FileSearch non si può utilizzare e falliscono precedenti modelli creati con Office 2003.

Ecco un esempio del genere:

Sub Cercafiles()

  cartella = Range("A1").Value

  nome = Range("B1").Value

  este = Range("C1").Value

  Dim nomefile As String

  With Application.FileSearch

    .NewSearch

    .LookIn = cartella & ""

    .SearchSubFolders = True

    .Filename = "" & nome & "." & este & ""

    If .Execute(SortBy:=msoSortByFileName, _

    SortOrder:=msoSortOrderAscending) > 0 Then

      MsgBox "Ci sono " & .FoundFiles.Count & " file(s) trovati."

      For i = 1 To .FoundFiles.Count

        nomefile = .FoundFiles(I)

        ActiveCell(i) = nomefile

      Next i

    Else

      MsgBox "File(s) non trovato."

    End If

  End With

End Sub

Utile, no? Però funziona solo con Office 2003.

La cosa imbarazzante...

 ... se non ridicola è che non solo tutte le keyword predette vengono regolarmente tradotte con le maiuscole al posto giusto (es. “fiLesEArCH” => “FileSearch”, “neWseaRCh” => “NewSearch”) ma la Guida riporta una gran copia di esempi specifici, NESSUNO dei quali funziona, dopo Office 2003.

N.B. Da www.microsoft.com/office/2010/en/default.aspx  oppure www.microsoft.com/italy/office2010/index.aspx si può scaricare la beta di Office 2010 (professionale), sempre in edizione inglese.

 

Input condizionato, con e senza macro

L’adozione in un intervallo ad hoc di un foglio di lavoro Excel per l’immissione di dati può essere interessante, specie se tali valori sono molti e li si vuole assoggettare a successive elaborazioni. Un’esigenza che in tali casi sovente si presenta è l’aderenza dell’input a determinate condizioni. Facile a dirsi e anche a farsi, con opportuno codice macro, ma un tale, al riguardo, mi ha espresso il timore che l’utente finale, succube del terrorismo contro i macro virus possa aver disabilitato le macro.

Per farla breve, ho studiato il problema sviluppando il modellino esemplificativo seguente, ove Zalva vuol raffigurare un pulsante ActiveX.

Si sappia inoltre che vanno assegnati i nomi di zona seguenti (tra parentesi le coordinate):

Zona_Input (A2:C5)

Data_Salva (E6, celata da pulsante Salva)

Soluzioni senza macro VBA

La cosa che sarà subito venuta in mente a molti è l’adozione della formattazione condizionale, le cui manovre do per note. Nel modellino, per estrema semplicità, ho previsto la condizione TRA, con minimo e massimo pari a 5 e 10 inclusi. Di conseguenza le celle OK si colorano automaticamente. Se l’utente non è del tutto sprovveduto dovrebbe bastare. Comunque per i palati più esigenti ho previsto l’intervallo A8:C11 sottostante Zona_Input, contenente formule booleane di cui riporto solo quella nella cella d’angolo A8:

=E(A2>=5;A2<=10)

Tali formule creano dei valori logici VERO in tutte e sole le celle “gemelle “ di quelle in Zona_Input che soddisfano la predetta condizione. A questo punto non resta che esaminare le formule seguenti, che recano a sinistra del segno = l’indirizzo della cella di appartenenza:

E10=CONTA.SE(A8:C11;VERO)

E11=SE(E10=CONTA.VALORI(A8:C11);"Tutte celle OK";(CONTA.VALORI(A8:C11)-E10)&" celle fuori limiti!")

Come spero sia a tutti chiaro, la prima dà il numero di input corretti, la seconda messaggi alternativi di limpida semantica.

Soluzione VBA

Il clou consiste nella routine seguente, relativa all’evento BeforeSave che si scatena prima del salvataggio della cartella di lavoro, comunque effettuato, tramite il pulsante Salva o a mano. È ospitata nel modulo ThisWorkbook:

Private Sub Workbook_BeforeSave(ByVal SaveAsUI As Boolean, Cancel As Boolean)

  Dim c As Range

  For Each c In Foglio1.Range("Zona_Input")

    'If c.Interior.ColorIndex = 3 Then ' NON VA!!!

    If c < 5 Or c > 10 Then

      MsgBox "Valori fuori limiti!"

      Cancel = True

      Exit Sub

    End If

  Next

  Range("Data_Salva") = Date

End Sub

Commenti ultrarapidi.

C’è poco da dire, almeno a chi mastica un poco il VBA, dico solo a chi non lo sapesse che l’argomento booleano Cancel, per default uguale a False, con Cancel = True inibisce il salvataggio. Quando invece l’utente si comporta bene Range(“Data_Salva”) = Date inserisce nella cella denominata Data_Salva la data corrente. Tale finezza (non del tutto perfetta, a dirla tutta) mira a permettere ad un eventuale controllore di constatare se il VBA è stato o meno disabilitato. Nel qual caso Data_Salva dovrebbe essere vuota. Chiaro?

Dimenticavo una cosa, che però non sorprenderà nessuno. Al pulsante Salva è abbinata questa macro:

Private Sub btnSalva_Click()

  ThisWorkbook.Save

End Sub

Infine si potrebbe agire anche sull’evento Close, comunque si constata che la pur noiosa domanda “Salvare le modifiche?...” è di fatto ininfluente ai nostri scopi.