textarea e UTF8

[kairos2020]

Buonasera, mi sto scontrando con un problema per me nuovo, ho un form con un textarea e un input tipo text, se nell'input di tipo testo inserisco caratteri 'strani' tipo ççççç non ho alcun problema a passarne il valore al database, se faccio lo stesso con il textarea ricevo un errore collegato all'encoding dei caratteri, a quanto pare il textarea non gestisce UTF-8, utilizzando la funzione (peraltro deprecata) utf8_encode()il problema viene parzialmente risolto, parzialmente perchè non ho l'errore in PDO ma nel database sono salvati caratteri diversi da quelli inseriti.
Ho poi scritto una funzione che elimina i caratteri indesiderati dal POST del textbox ma benchè efficace non credo sia efficiente. Qualcuno conosce il problema ? Grazie

[dreadnaut]

Visto che l'<input> non da problemi, ma <textarea> si, la cosa mi fa pensare che il problema non sia nella pagina, ma nella tabella del database. Magari una colonna è definita in modo sbagliato, o qualcosa di simile.

- Qual'era l'errore PDO?
- Come è fatta la tabella?

Per la seconda domanda, può esserti utile la query SHOW CREATE TABLE `tabella`, dove siamo interessati al charset delle colonne di testo ed della tabella stessa.

Ad esempio:

CREATE TABLE `articles` (
  `title` varchar(250) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `content` longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  [...]
) ENGINE=MyISAM DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

qua vedi che sia titolo e contenuto possono contenere utf8mb4 (le emoji funzionano!), e questo corrisponde al charset della tabella.

[kairos2020]

Grazie per la cortese risposta, in effetti verificato che in text non avevo problemi ho provato come prima cosa a cercare in internet se trovavo qualcosa, ed in effetti in stack overflow ho trovato evidenza di altri problemi simili al mio, dopo ore di ricerca (si sono molto lento) ho realizzato che text e texarea differiscono molto tra loro.

Ho avuto anche io il dubbio che il problema fosse nella tabella, o nel campo collegato al textarea, ho ricontrollato in phpAdmin - struttura tabella e ho visto che il charset era, per entrambi i campi, correttamente settato a : utf8mb4_unicode_ci, non ancora sicuro sono andato nel tab OPERAZIONI - OPZIONI TABELLA ho selezionato : Cambia tutte le collation dei campi e ho agggiornato.

Ho comunque eseguito la query che mi hai indicato

CREATE TABLE `articles` (
  `title` varchar(250) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `content` longtext CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL)

in struttura i charset sono gli stessi della mia tabella.

Purtroppo non mi sono segnato l'errore, domani però tolgo la 'pezza' che ho inserito, non una funzione con regex, ma semplicemente htmlentities(sil POST), e te li mando.
La 'pezza' efficace però mi crea un problema non del tutto inaspettato, sul quale tempo fa mi eri stato molto utile (grazie ancora), PDO Prepared statements filtra i dati prima di salvarli nel database,utilizzando anche htmlentities 'faccio il pane doppio' ovvero filtro il filtrato, risultato :
nel textarea inserivo <br> per andare a capo quando mi serviva, con il doppio filtraggio non funziona più.
Se controllo la lunghezza del POST prima e dopo htmlentities verifico che è diversa, ovviamente più lunga dopo l'escaping (si dice così?)
Per il momento grazie, ti terrò al corrente degli sviluppi.

.. edit ... ero troppo curioso e ho fatto una prova rapida, fermo restando che la tabella già risultava correttamente settata come charset e collazione (prima o poi scoprirò che è ) ho provato a cancellarla e a ricrearla da query, e non da strumento visuale di phpAdmin, ho tolto la pezza di cui sopra e ... magia tutto funziona.
E' possibile che la tabella fosse corrotta ?

[kairos2020]

... seguito
Ho controllato meglio il database.
Con phpAdmin dal tab operazioni ho settato il database e le tabelle a CODIFICA CARATTERI a utf8mb4_unicode_ci e, dopo aver selezionato Cambia tutte le collation dei campi, ho aggiornato il database e tutte le tabelle.

Ho poi esportato il database in formato SQL per poter controllare se tutto era a posto.
Sorpresa ... alcune tabelle avevano i campi varchar ancora settati a utf8mb4_general_ci, brutalmente ho sostituito tutte le ricorrenze utf8mb4_general_ci con utf8mb4_unicode_ci.
Importato e ricontrollato, finalmente tutto a posto.

Sebbene ormai sia chiaro ormai anche a me che la differenza tra le due collazioni sia unicamente di tipo prestazionale mi pare comuque evidente che myPhp non riesca, non sia riuscito, a correggere le anomalie con gli strumenti di cui è dotato, di positivo in tutta questa storia è che finalmente mi sono fatto un'idea della funzione delle collazioni.

Mi sono dimenticato di dire che utilizzo ENGINE=InnoDB, per le transazioni e per l'integrità referenziale, magari ci sono altri motori che funzionano meglio ma per le mie necessità (fino ad ora) InnoDb ha funzionato egregiamente.
Grazie per la pazienza