[RISOLTO] For ... Do ... Begin ... End

[AlexLazarus]

La stringa Caratteri_Validi contiene tutti i caratteri alfabetici minuscoli, comprese le vocali accentate: 'qwertyuiopèéòàùìasdfghjklzxcvbnm'
La stringa Elemento contiene alcuni di quei caratteri alfabetici, oltre alla presenza di qualche carattere numerico: 'pa5ro8la'

Lo scopo è quello di esaminare, uno alla volta, i caratteri di Elemento e confrontarli con (uno alla volta) i caratteri della stringa Caratteri_Validi.
Se c'è una corrispondenza, "riempe" la Stringa_valida un carattere valla volta, altrimenmti esclude il carattere estraneo.

In parole povere, quindi, da ''pa5ro8la'' si dovrebbe arrivare a 'parola', che verrebbe finalmente aggiunta a ListBox1.

Però non appena il conteggio parte...
For Conta_Caratteri:= 1 to Length(Caratteri_Validi) do;
...immediatamente Conta_Caratteri, invece che a 1, viene inizializzato con 38 (la lunghezza di Caratteri_Validi).
La stessa cosa, ovviamente(!) succede con...
For Conteggio_Stringa:= 1 To Length(Elemento) do;

Perché i conteggi non partono da 1, come dovrebbero?

Codice: [Seleziona]

procedure TForm1.Button1Click(Sender: TObject);
Var Elemento, Caratteri_Validi, Stringa_valida, Carattere_selezionato: string;
Var Conta_Caratteri, Conteggio_Stringa: integer;
begin
       Stringa_valida:='';
       Conteggio_Stringa:=0;
       Elemento:='pa5ro8la';
       Caratteri_Validi:='qwertyuiopèéòàùìasdfghjklzxcvbnm'; // Intero alfabeto minuscolo, comprese vocali accentate
       Begin
          // DOVREBBE(!) leggere un carattere alla volta, partendo DAL PRIMO di "Caratteri_Validi"
          // INVECE "Conta_Caratteri" invece di 1 inizia subito dalla lunghezza di "Caratteri_Validi" (38)
          For Conta_Caratteri:= 1 to Length(Caratteri_Validi) do;
             Begin
                For Conteggio_Stringa:= 1 To Length(Elemento) do;
                // La stessa cosa con  "Conteggio_Stringa". Perché?
                    Begin
                       Carattere_selezionato:= Copy(Elemento,Conteggio_Stringa,1);
                         If Pos(Carattere_selezionato,Caratteri_Validi) > 0  Then
                             Begin
                                  Stringa_valida:=Stringa_valida + Carattere_selezionato;
                             End;
                    End;
             end;
        End;
                  ListBox1.Items.Add(Stringa_valida);
                  Refresh;
End; 

[bonmario]

Mettendo il "punto e virgola" dopo ogni "do", stai facendo finire lì i 2 cicli for.
Prova a cancellare quei 2 "punto e virgola", e vedrai che parte da 1.

Ciao, Mario

[AlexLazarus]

Mettendo il "punto e virgola" dopo ogni "do", stai facendo finire lì i 2 cicli for.
Prova a cancellare quei 2 "punto e virgola", e vedrai che parte da 1.

Malediz, porc, dannaz... ho perso tutta la mattinata, la soluzione era proprio davanti ai miei occhi e non me ne sono accorto!

P.S. Grazie!

[giacomarko]

In questo modo rifai il loop di controllo del carattere da testare, partendo dal primo fino all'ultimo carattere ammesso, moltiplicato per tutti i caratteri stringa da controllare ... funziona ma...

In alternativa a due loop, si può utilizzare per la parte controllo un Set con la keyword In

il Set è la sequenza di lettere corrette,
al posto della ShowMessage:
componi la stringa quando il valore è vero,
viceversa non fai nulla

Chiaramente il Set lo puoi/devi definire ad un livello superiore di chiamata, in modo da non doverlo inizializzare ogni volta

Codice: [Seleziona]

// Test if a character is a letter
procedure TForm1.IsLetter(Letter : char);
var
  Alphabet : set of 'A'..'Z';
begin
  Alphabet := ['A'..'Z'];

  if Letter In Alphabet then
    ShowMessage(Letter+' is in the alphabet')
  else
    ShowMessage(Letter+' is NOT in the alphabet');
end;

[brunello]

oppure così

Codice: [Seleziona]

var
  Elemento, Caratteri_Validi, Stringa_valida: string;
  i: integer;
begin
  Stringa_valida := '';
  Conteggio_Stringa := 0;
  Elemento := 'pa5ro8la';
  Caratteri_Validi := 'qwertyuiopèéòàùìasdfghjklzxcvbnm'; // Intero alfabeto minuscolo, comprese vocali accentate
  for i := 1 to Length(Elemento) do
    if Pos(Elemento[i], Caratteri_Validi) > 0 then
      Stringa_valida := Stringa_Valida + Elemento[i]
  ListBox1.Items.Add(Stringa_valida);
  Refresh;

[DragoRosso]

Fate attenzione che le stringhe che contengono caratteri UTF8 (quelli accentati per intenderci) devono essere confrontati con le funzioni equivalenti UTF8 (quindi non con POS())....

Guardate una recente discussione su questo argomento (di cui non ricordo il link).

Ciao

[AlexLazarus]

Fate attenzione che le stringhe che contengono caratteri UTF8 (quelli accentati per intenderci) devono essere confrontati con le funzioni equivalenti UTF8 (quindi non con POS())....

...uhmm... utilizzando POS() individuo tutte le vocali accentate (àèéìòù). Ho infatti appena completato un Video Tutorial che (spero) pubblicherò oggi pomeriggio.
Piuttosto, sarebbe certamente utile approfondire la gestione dei caratteri UTF8 per andare "oltre" il valore 127.
Esempio banalissimo (vedi anche screenshot) nel progetto qui di seguito indicato: il carattere ä viene individuato (ma davvero corrisponde a 195?) ma il viceversa produce un risultato... nullo.
P.S. La variabile s non c'entra nulla: è un rimasuglio di un test precedente.

Codice: [Seleziona]

procedure TForm1.Button1Click(Sender: TObject);
Var Valore:  Integer;
Var Carattere: string;
begin
  If Length(Edit1.text)> 0 then
  Begin
    Carattere:= LeftStr(Edit1.Text,1);
    Valore:= integer(Ord(Edit1.text[1]));
    ShowMessage(Carattere);
    Label2.Caption:= ('Il valore ASCII di ' + Carattere + ' è: ' +  IntToStr(Valore));
  end;
end;

procedure TForm1.Button2Click( Sender: TObject);
Var Numero: Byte;
Var Carattere, S: String;

Begin
  Numero:= StrToInt(Edit2.Text);
  Carattere:= Chr(Numero);
  Label4.Caption:= ('Il carattere ASCII corrispondente è: ' + Carattere);
end; 
[/]

[bonmario]

Occhio, che stai facendo confusione !!!
Con UTF8, alcuni caratteri occupano 2 bytes. Dall'ultima immagine che hai postato, vedi che c'è qualcosa che non va, perché invece di emettere il carattere, emette il punto di domanda. Probabilmente, quel carattere è dato dal valore ascii 195, + quello successivo.

Provo a piegarmi con un esempio:

Codice: [Seleziona]

ShowMessage(IntToStr(Length('à')));

Il codice qui sopra, ti emetterà 2, e non 1 !!!

Ciao, Mario

[DragoRosso]

L'uso dei caratteri (conversione, ricerca, comparazione) è stato sempre un problema, che se fino agli anni 2007 circa  veniva gestito con la funzionalità detta codepage (praticamente un set di caratteri standardizzati per ogni lingua) ed era relativamente semplice eseguire le operazioni standard, dopo quell'anno l'avvento dell'unicode come nuovo standard (ad esempio Windows è un sistema unicode) ha creato ancora più "caos".

Prima 2007 (ANSI su tabelle codepage): caratteri di 8 bit tabellati per ogni lingua, idioma, etc ...
Pos, chr, ord: funzioni sempre esistite senza alcun problema. L'unica vera spina del fianco era che il caricamento di un codepage specifico (tedesco ad esempio) non ti consentiva di usare i caratteri italiani e gli scambi testuali semplici erano impossibili (una stringa scritta in tedesco con le dieresi venivano rappresentate solo con il codepage tedesco, e se usavi un software con il codepage italiano venivano rappresentati "caratteri strani".

La standardizzazione di più idiomi ha portato alla adozione universale dello standard Unicode (tra i più noti UTF8 e UTF16).

Dopo 2007, Unicode: i caratteri non sono più formati da 8 bit ma da almeno 16 bit, fatto salvo che solo in UTF8 la rappresentazione dei primi 127 caratteri ASCII viene fatta a 8 bit, in pratica lettere, numeri, caratteri speciali e di punteggiatura occidentali standard (definiti secondo lo standard ASCII) vengono ancora rappresentati come 8 bit in UTF8, mentre qualsiasi altro carattere avrà una lunghezza di almeno 2 byte (sino ad arrivare a 7 byte con il recente inserimento dei caratteri emoticons). In UTF16 i caratteri vengono rappresentati sempre con 16 bit o 32 bit e attualmente sono "mappati" circa 128000 caratteri in tutte le lingue. SOLO I primi 128 caratteri di UTF8 e UTF16 vengono rappresentati in maniera simile ($xx per UTF8 e $00xx x UTF16)

Dopo 2007: caratteri rappresentati genericamente da due byte (eccetto per i caratteri chiamiamoli  "base" in UTF8), e relativamente semplice gestione delle stringhe, che però diventano totalmente incompatibili con la vecchia gestione pre UNICODE. Il software deve prevedere che i caratteri hanno una lunghezza variabile e non più di un byte. Impossibile anche effettuare una conversione corretta "misciando" codice ANSI e UNICODE, codice carattere e valore numerico non possono essere convertiti tra loro senza sapere che codifica si stà usando (ANSI, UTF8, UTF16 ?). La conversione Maiuscolo/Minuscolo e viceversa rappresenta un problema perchè non esiste nello standard un parametro di conversione di questo tipo.

...uhmm... utilizzando POS() individuo tutte le vocali accentate (àèéìòù). Ho infatti appena completato un Video Tutorial che (spero) pubblicherò oggi pomeriggio.
Piuttosto, sarebbe certamente utile approfondire la gestione dei caratteri UTF8 per andare "oltre" il valore 127.
Esempio banalissimo (vedi anche screenshot) nel progetto qui di seguito indicato: il carattere ä viene individuato (ma davvero corrisponde a 195?) ma il viceversa produce un risultato... nullo.

Ecco perchè quel carattere non viene rappresentato dal tuo software .... il codice di "ä" non è semplicemente "195" ma bensì "$c3a4", il tuo codice prende erroneamente solo il primo byte del carattere "$c3" che corrisponde a 195.

Mentre prima le ricerche, comparazioni, etc..., venivano effettuate a "byte" ora si devono usare tramite i "codepoint" cioè marcatori che definiscono la lunghezza del carattere (... di ogni singolo carattere ....) all'interno di una stringa. I "codepoint" sono implementati genericamente solo nella funzioni abilitate per le operazioni UNICODE, non per quelle standard.

Se si usano solo ed esclusivamente i caratteri inglesi tuttavia non si riscontreranno genericamente problemi, in quanto come si diceva UTF8 ha i primi 128 caratteri a solo 8 bit (che guarda caso corrispondono ai classici caratteri inglesi delle tastiere internazionali).

Perchè UTF8? Perchè molti ambienti di programmazione si sono concentrati molto su questa codifica in quanto usata per diversi aspetti universali. Qualsiasi carattere proveniente da un sito web è codifica in UTF8, alcuni database gestiscono i caratteri in UTF8, alcuni sistemi operativi gestiscono nativamente i caratteri in UTF8 (le api WINDOWS li gestiscono SOLO in UTF16, o meglio un sottoinsieme di UTF16).

Lazarus è uno di questi ambienti, Delphi invece usa principalmente UTF16 per compatibilità storica con Windows anche se il listato del programma viene salvato in UTF8 

Questo un link per divertivi a vedere la codifica dei vari caratteri, potete usare un programma tipo word o un qualsiasi sito web in una lingua nazionale (l'arabo ad esempio) per copiare / incollare il carattere che vi interessa e vedere la codifica o viceversa:
https://onlineutf8tools.com/convert-utf8-to-hexadecimal

Qui ulteriori riferimenti: https://it.wikipedia.org/wiki/Unicode.

Qui riferimenti x Lazarus e FPC: https://wiki.freepascal.org/Unicode_Support_in_Lazarus

Ci sono diversi Topic e POST su questi argomenti nel nostro forum, anche ben approfonditi e con esempi. Effettuate una ricerca per approfondire l'argomento.

P.S.: tanto per curiosità solo la lingua cinese ha un "set" documentato di oltre 80000 caratteri (di cui moltissimi di usa rarissimo) di cui implementati in unicode sembra ce ne siano circa 40000 (non c'è un dato ufficiale su questo perchè i caratteri Unicode sono asettici rispetto alla lingua, quindi ad esempio "caratteri" giapponesi e cinesi identici hanno una sola codifica).

Ciao

[giacomarko]

Grazie DragoRosso per la dettagliatissima spiegazione !!

curiosità personale...

nell'uso di In come nel mio suggerimento, questo problema si pone ancora ?

m

[DragoRosso]

Grazie DragoRosso per la dettagliatissima spiegazione !!
curiosità personale...
nell'uso di In come nel mio suggerimento, questo problema si pone ancora ?
m

Da quel che sò, però in Lazarus non conosco precisamente l'implementazione, IN può essere usato in un set di al massimo 256 elementi, ossia un set non può contenere più di 256 elementi, quindi qualsiasi implementazione deve rispecchiare tale limite.

L'elemento di un set deve essere omogeneo, non si possono "misciare" numeri, caratteri od altro.

Secondo mè l'implementazione di un SET (e quindi di un IN) nel caso di caratteri UTF8 non appartenenti ai primi 128 caratteri di base provoca problemi (tempo fà avevo fatto un prova in Delphi, ma funzionava solo per caratteri con codifica a 16 bit, con caratteri misti 16 / 32 bit mi dava errore in compilazione ad esempio).

Occorrerebbe effettuare diverse prove, tenendo conto anche dei modificatori ($DEFINE) che possono essere inseriti per modificare il comportamento di Lazarus nei confronti della gestione UNICODE / ANSI.

Bisogna poi ricordarsi che FPC supporta solo parzialmente la funzionalità nativa UNICODE e che il supporto maggiore deriva da Lazarus. Questo implica principalmente problematica di "velocità" del codice e alcune attenzioni per le dovute conversione da fare a "mano".

Ciao