codifica del testo

[karrygun]

ho notato su internet che diversi siti hanno delle codifiche diverse. inoltre mi par di capire che sono pure cryptati.

inoltre può capitare che ogni tanto si va in certi siti e spuntano tante lettere strane.

vorrei capirne un po di piu e vorrei inoltre capire come poterle convertire in modo adeguato

[fano]

La storia dell'encoding del testo è lunga praticamente: è un problema che esiste da quando esistono i computer (40 anni cioè!).

Tagliamo i primi 30 anni in cui i computer erano grossi come armadi e con HDD da 3 MB grossi come lavatrici e lasciamo riposare nella sua tomba il C=64 e gli altri Home Computer e parliamo solamente dei PC...

Quando IBM creò il Personal Computer lo fece "parlare" solo in Inglese e quindi prese la strada più semplice: associò ogni carattere ad un byte (le più piccola unità di dato rappresentabile in ASSEMBLER, i bit non sono "rappresentabili") e visto che 127 combinazioni bastavano ed avanzavano poteva usare 7 Bit con 1 bit Bit in "avanzo" che magari poteva essere usato come flag per chissà quali turpi scopi!
Questo codifica è oggi conosciuta come ASCII: http://www.asciitable.com.

Quando poi il PC fu portato in Europa non fummo affatto soddisfatti che un PC fiammante da 3'000 $ (costavano anche di più se si aggiorna al valore di oggi) manco si poteva scrivere il carattere 'è' e quindi IBM (e talvolta pure i clonatori) inventarono le codepages: l'idea era semplice usiamo gli altri 127 byte per rappresentare le altre lettere banale no?
Nasce CP437: https://en.wikipedia.org/wiki/Code_page_437.

Ci sono alcune lettere accentate dell'alfabeto latino esteso (ma NON tutte), strani caratteri "semi-grafici", ecc...

Bello vero? Il problema è risolto? Manco per nulla se sei per esempio greco! No il carattere che sembra "Beta" è l'Ess-Zed tedesco e poi ti mancherebbero un sacco di lettere quindi? Quindi usiamo di nuovi i 127 byte in più (gli stessi di prima ma con "significato" diverso) per le lettere greche: https://en.wikipedia.org/wiki/ISO/IEC_8859-7.

Ben presto ne nacquero centinaia di code page talvolta per lo stesso alfabeto, ma con sottili differenze (ma a volte lo stesso nome!), Apple e Commodore estesero ASCII in maniera totalmente incompatibile insomma un disastro!

Disastro totale sì perché dato uno stream di byte se non conosci l'encoding a priori i byte > 127 non sai cosa sono! Quindi? Quindi spesso ci si riduce a tirare ad indovinare!

XML / HTML e i formati "testuali" serii preverrebbero che la codepage sia indicata, ma per quanto riguarda XML / HTML il testo poi lo puoi scrivere anche in un altra encoding in ogni caso ed ecco appunto gli strani caratteri che vedi! Che non sono cifrati, ma sono chiamati "replacement characters" quando il "decoder" non sa che pesci pigliare ti mostra un quadratino con dentro dei numerini e via
L'altro problema è che per risparmiare spazio (i primi HDD avevano pochi MegaByte a disposizione se avevano un HDD alcuni PC usavano solo il floppy) o solo la tua code page o poche altre erano installate quindi alla fine rischiavi di vedere comunque "replacement characters" lo stesso!

La soluzione è stata in teoria trovata 15 anni fa (!) si chiama unicode... hanno dovuto farne 3 versioni perché alla prima non gli è venuto (a 32 bit, 16 bit che non supporta "inutili" ideogrammi cino-giapponesi se non con dei kludge e 8 bit che però occupa più spazio ed è un incubo da decodificare).

Questa è la mia opinione personale: ma il formato giusto è UFT-16 (infatti è usato da Windows e da MacOS) gli ideogrammi o alfabeto "giocattolo" tipo Tolkien o Klingon NON sono caratteri, ma immagini
UTF-8 è stato creato per retro-compatibilità con il C cercando "a forza" di rappresentarlo dentro il tipo 'char *' così ora si ha il doppio casino:

1. Le stringhe in C continuano a non esistere ed in più un for di ogni carattere nella stringa potrebbe mostrarti "mezzo" carattere
2. La funzione strlen() non torna la "vera" lunghezza della stringa

il risultato alla fine è che poi su Linux non riescono a decodificare nemmeno una semplice "è" e la sostituiscono con il replacement character, imbarazzante

Per convertine da un encoding all'altro in C potresti usare iconv, ma devi quasi sempre ricompilarti la libreria (!) visto che di default contiene solo ASCII, hanno anche fatto un bel pasticcio visto che l'hanno unita con la libc (che non c'entra ovviamente nulla), io l'ultima volta dovendo convertire da UTF-8 a CP864 https://en.wikipedia.org/wiki/Code_page_864 (alfabeto arabo) mi sono dovuto rassegnare a farmi una mia libreria, ma in C / Linux è cosa normale che le libreria "core" non funzionino a quanto pare

In C# è ovviamente integrato nelle classi basi e funziona pure ovviamente:
https://msdn.microsoft.com/en-us/lib...vs.110%29.aspx

[karrygun]

e quindi mi par di capire che hanno fatto tanto lavoro di decodifica ma che ancora non è perfetto?

mi ritrovo alcuni siti in italiano con delle lettere strane e in siti stranieri (cliccati occasionalmente) con simboli tipo un quadrato bianco , un simbolo che sembra un immagine e dei diamanti col punto interrogativo.

[fano]

Il problema è che molte cose nel nostro settore sono state fatte un po' alla membro di segugio, il mercato PC si è sviluppato quasi più per evoluzione / selezione naturale che per cose studiate a tavolino e quando ci hanno provato (tipo VBE) hanno fatto pure un gran casino

Unicode funzione ed anche perfettamente, ma se ancora oggi il terminale di Linux di fatto supporta solo caratteri ASCII (!) e Windows 10 invece di default ha la code page dell'Italiano solo perché il mio SO è in Italiano... non se ne esce!

Il vero problema (irrisolvibile!) è che dato un array di byte tipo questo (numeri a caso è):

byte[] arr = { 0xFA, 0x80, 0x42,  0x69 }

come fai a sapere come decodificarlo? Se fai il "finto" UTF-8 di Linux (ASCII di fatto) solo 0x42 ('A') ha senso il resto cos'è? Magari invece era davvero UTF-8 e i primi tre byte erano la lettera 'è'? O era UFT-16 (quindi sono 2 caratteri!)? E se invece era una sola f*ttuta lettera nella code page del giapponese? Chi lo sa?

come ti ho detto se è HTML/XML o un .doc l'encoding c'è scritto (ma in HTML/XML poi ci sbatti dentro quello che vuoi: è solo un "hint"), ma se è un .txt o byte che leggi dal cavo e non sai a priori che codifica usare sei fritto!

A questo problema dell'encoding se ne aggiunge un altro quello dei font quelli gratuiti (quindi usabili in Open Source OS come Linux e Cosmos) spesso disegnano nemmeno 50 - 60 dei 4'000'000'000 di font che esistono
Per esempio:
https://fonts.google.com/specimen/Noto+Sans

[karrygun]

nonostante tutte queste difficoltà , ho trovato siti con il utf-8 ma con strani simboli. ho provato a decifrarli e pare che abbia una seconda codifica (è possibile?) e le lettere sono asiatiche. va a capire di quale lingua...

[fano]

Se sono cose tipo questa '' quelle che vedi è semplice forse riesci a decodificare l'UTF-8, ma poi i tuoi font non hanno modo per rappresentare il carattere! I numerini che vedi all'interno sono la codifica unicode del carattere...

Ma sei su Linux che hai tutti sti problemi? Su Windows / Mac OSX è molto raro avere sti casini con cose del genere...

[pabloski]

Originariamente inviato da karrygun

nonostante tutte queste difficoltà , ho trovato siti con il utf-8 ma con strani simboli. ho provato a decifrarli e pare che abbia una seconda codifica (è possibile?) e le lettere sono asiatiche. va a capire di quale lingua...

No no fermo. UTF-8 supporta tutto il set di caratteri Unicode. Se escono i quadrati bianchi con i punti interrogativi, allora e' il font usato dal browser che non implementa i glifi per quei code point.