New ancient content

This is a very brief post, which is just going to tell you that all the old content which was originally written on the b2evolution install at Planet Gentoo, and which was then imported into the WordPress install at Gentoo Blogs, have been imported into this site instead.

This basically means that Google will start indexing the old posts as well, which will then appear on the custom search’s results, which is why I went through the trouble. In particular yesterday’s post was actually linked to a very old problem which I enocuntered almost exactly seven years ago (time flies!) but finding it was a bit of a mess.

So I saved a backup of the WordPress data, and wrote a script to create articles in Typo starting from it. The result is that now there are 324 extra posts in this blog — unfortunately some of them are noise. Some of it because the original images they linked to are gone, others because at some point b2evolution went crazy and started dropping anything where UTF-8 was involved, as can be shown by the original and the truncated version from the Wayback Machine. I’ll probably import the two articles I found being truncated.

After the import completed, I also deleted the WordPress site on Gentoo’s infra. The reason is simple: I don’t want to have two copies around, with all the broken links it has (nobody set up a remapping of the old planet links to blogs links), the truncated content and so on. There are a number of things that need to cleared up with the content, and links that went from this blog to the old one need to be fixed as well, but that’ll happen over time, I don’t want to sweat it now.

I’m happy that my content is back with me.

The UTF-8 security challenge

I make no mystery of the fact I like my surname to be spelt correctly, even if that’s internationally difficult. I don’t think that’s too much to ask sincerely; if you want to refer to me and you don’t know how to spell my surname, you have a few other options, starting from my nickname (“Flameeyes”), which I keep on using everywhere, included the domain of this blog because, well, it’s a name as good as my “real” name. While I know other developers, starting from Donnie, prefer to be recognized mainly by their real name; since I know my name is difficult to type for most English speakers, I don’t usually ask that much; Flameeyes was, after all, more unique to me than “Diego Pettenò”, since of the latter there are other three just in my city.

But even without going with nicknames, that might not sound “professional”, I’m fine with being called Diego (in Gentoo I’m the only one; for what concern multimedia areas, I’m Diego #2 since “the other Diego” Biurrun takes due priority), or since a few months ago Diego Elio (I don’t pretend to be unique in the world but when I chose my new name, beside choosing my grandfather’s name, I also checked I wouldn’t step in the shoes of another developer), or, if you really really need to type my name in full, “Diego Petteno`” (yes there is an ascii character to represent my accent and it’s not the usual single quotation mark; even the quotation mark, though, works as a tentative, like for banks and credit cards . If you’re in a particular good mood and want to tease me around you could also use 炎目 (which is probably a too literal translation of “Flameeyes” in kanji); I think the only person ever using that to call me has been Chris (White), and it also does not solve the issue of UTF-8.

Turns out it’s not that easy at all. I probably have gone a little overboard the other day about one GLSA mistyping my name (it still does), because our security guys are innocent on the matter: glsa-check breaks with UTF-8 in the GLSA XML files (which is broken of glsa-check, since you should not assume anything about the encoding of XML files, each file declares its own encoding!), which makes it hard to type my name; tthe reason why I was surprised (and somewhat annoyed) is that I was expecting it to be typed right for once, py handled it and I’m sure he has the ò character on his keyboard.

Curious about this, I also wanted to confirm how the other distributions would handle my name. A good chance to do that was provided by CVE-2008-4316 (which I discussed briefly already ). The results are funny, disappointing and interesting at the same time.

The oCERT advisory has a broken encoding and shows the “unknown character” symbol (�); on the other hand, Will’s mail at SecurityFocus shows my name properly. Debian cuts my surname, while Ubuntu simply mistype it; on the other hand, Red Hat is showing it properly; score one for Red Hat.

One out of four distributions (Gentoo has no GLSA on the matter, but I know what would have happened, nor the CVE links to other distributions, just a few more security-focused sites I’m not interested about in this momet) handle my name correctly, that’s not really good. Especially, I’m surprised that the one distribution getting it right is Red Hat, since the other two are the ones I usually see called in the mix when people talk about localising Free Software packages. Gentoo at least does not pretend to be ready for internationalisation in the first place (although we have a GLEP that does ).

Okay I certainly am a nit-picker, but we’re in 2009, there are good ways to handle UTF-8, and the only obstacles I see nowadays are very old legacy software and English speakers who maintain that seven bits are enough to encode the world, which is not true by a long shot.

Locales, NLS, kernels and filesystems

One issue that is yet to be solved easily by most distribution (at least those not featuring extensive graphical configuration utilities, like Fedora and Ubuntu do), is most likely localisation.

There is an interesting blog post by Wouter Verhelst on Planet Debian that talks about setting locales variables. It’s a very interesting reading, as it clarifies pretty well the different variables.

One related issue seems to be understanding the meaning of the NLS settings that are available in the kernel configuration for Linux. Some users seem to think that you have to enable the codepages in there to be able to use a certain locale as system locale.

This is not the case, the NLS settings in there are basically only used for filesystems, and in particular only VFAT and NTFS filesystems. The reason of this lies in the fact that both filesystems are case-insensitive.

In usual Unix filesystems, like UFS, EXT2/3/4, XFS, JFS, ReiserFS and so on, file names are case sensitive, and they end up being just a string of arbitrary characters. On VFAT and NTFS, instead, the filenames are case *in*sensitive.

For case sensitivity, you need equivalence tables, and those are defined by different NLS values. For instance, for Western locale, the character ‘i’ and ‘I’ are equivalent, but in Turkish, they are not, as ‘i’ pairs with ‘İ’ and ‘I’ with ‘ı’ (if you wish to get more information about this, I’d refer you to Michael S. Kaplan’s blog on the subject).

So when you need to support VFAT or NTFS, you need to support the right NLS table, or your filesystem will end up corrupted (on Turkish charset, you can have two files called “FAIL” and “fail” as the two letters are not just the same). This is the reason why you find the NLS settings in the filesystems section.

Of course, one could say that HFS+ used by MacOS is also case-insensitive, so NLS settings should apply to that too, no? Well, no. I admit I don’t know much about historical HFS+ filesystems, as I only started using MacOS from version 10.3, but at least since then, the filenames are saved encoded in UTF-8, which has very well defined equivalence tables. So there is no need for option selections, the equivalence table is defined as part of the filesystem itself.

Knowing this, why VFAT does not work properly with UTF-8, as stated by the kernel when you mount it as iocharset=utf-8? The problem is that VFAT works on a per-character equivalence basis, and UTF-8 is a variable-size encoding, which does not suit well VFAT.

Unfortunately, make oldconfig and make xconfig seem to replace, at least on my system, the default charset with UTF-8 every time, maybe because UTF-8 is the system encoding I’m using. I guess I should look up to see if it’s worth to report a bug about this, or if I can fix it myself.

Update (2017-04-28): I feel very sad to have found out over a year and a half later that Michael died. The links in this and other posts to his blog are now linked to the archive kindly provided and set up by Jan Kučera. Thank you, Jan. And thank you, Michael.

From Gentoo/FreeBSD, some news

Lately I’ve been neglecting Gentoo/FreeBSD on my blog, mainly focusing on the description of the work-in-progress PulseAudio support (and its relation with Gentoo/FreeBSD of course).

But there are really many changes lately, mostly thanks to the help of Timothy Redaelli (drizzt) from FreeSBIE who’s helping a lot, but I don’t want to leave Javier (The_Paya) and Victor (Daijo) without their share of honour, they are working hard too and this can be seen in the quick responses to bugs and to the proceeding work on amd64-fbsd.

First of all, he ported netselect, then he also summarised the dbus patch and prepared an ebuild for hal-fbsd. I’ll be merging those to the overlay soon, leaving time to Cardoe for testing the dbus patch, and to tell me what he thinks of the whole hal-fbsd idea, before they get into main tree and thus can be used.

Even more important, at least to me for biased reasons ;), he helped making sure that UTF-8 support works correctly on Gentoo/FreeBSD (although the support in console is not available at the moment, but the same holds true for normal FreeBSD), so that finally I can see my name correctly on the FreeBSD boxes I have! :)
For this to work, you need freebsd-share-6.1-r1 that has the patch to fix the ctype, and drops the symlink patch that broke LC_COLLATION.

Now he’s working on diablo-jre and diablo-jdk support, FreeBSD Foundation’s Sun Java release that is needed for Java to work on FreeBSD, although he’s hitting the problem that I didn’t want to cope with just yet (and thus the reason I didn’t pay much attention to diablo): is not present on Gentoo/FreeBSD, it’s called because we follow upstream’s naming scheme. To avoid this, one can either use LD_LIBMAP variable or libmap.conf, by telling the loader that is, but this might be a problem with a true is present… so I’m not entirely sure about this approach, and I’d be looking if there’s a way to edit the ELFs on the fly.

Myself, instead, I worked on something yesterday, and that something is keywording of roguelike games that I could test. The reason for doing that is not strange nor silly, to my view: BSD always had rogue, but we cannot build bsd-games-non-free where rogue is (because it’s patched to build on Linux most likely), and I don’t really want to spend time right now preparing a freebsd-games ebuild… so the result is that you won’t have rogue in the base system, but you can choose between a vast series of rogue-like games, as I keyworded almost all of the textual ones a part slashem (does not build, needs fixes, is not even ported to modular X) and noegnud (haven’t tried it yet, it’s still p.masked tho).

I probably will take a look to other simple stuff to keyword too, games and multimedia, as at least we can say to provide something working and useful not only to servers (considering we’re not production ready yet).

I know I should start preparing a new stage, but the temperature here is too high to get the distcc cluster working :(

UTF-8 Forever

Ok I know I’m being quite an ass for posting so much blog entries in a short time, but I had part of them already in mind in the last days and I just hadn’t had time to actually write them.

This entry has a title that would probably be misleading at the end as I’m going to summarize a couple of things here…

Starting from the topic in the title, I’m really loving UTF-8 these days. With the surname I have (“Pettenò”) is quite important being sure that the final ò is handled correcly by computers.. it already happened that I received (snail) mails with the surname mangled with the wrong encoding, and sometime I just get mails with “Petteno” as receiver (which is completely another surname).
Luckily, using UTF-8 is possible represent my surname as well as kloeri’s (Østergaard, sorry for naming you but was the only other one with special chars in name that I had in mind) without having to mangle encodings, and at the same time also writing ?? without having to install special supports for extra encodings or force disabling latin-extended characters (for who’s wondering what is wrote there, it’s “baka” .. and if you don’t know, just google :P).
Unfortunately, UTF-8 is not a magic solution as there is also someone who fails to write ChangeLogs with my name spelt right.. eh Mike? (I am refering to late ChangeLogs from vapier where I had to fix my surname as it was using broken, nothing personal :) ).

Then I must say that lately my (real) life is being really fooled up and strange. Maybe it’s just the weather, maybe the time that’s passing, but I really feel depressed in the last days. More probable, is the knowledge that the someone I care about is happy, but with someone else, that’s making me feel strange. While I’m happy for her being happy, I’m totally sad as I know I won’t be able to be at her side for all the time we have in front of us. This feeling is really messing me up, so I don’t really know if I’ll be present or not on IRC, if I’ll look at bugs or if I’ll complete GNOME porting without pauses… I think, I hope, to remain the same as usual, also because it helps me not to think of her, but I can’t really say what I’m going to do.

On a little more happy note, after being published on NewsForge, becoming the Developer of the Week (of three weeks ago) and now becoming Deputy Lead for G/BSD project, I’m starting thinking that I’m not wasting others’ time every day all the day, so I feel relieved on the “professional” part of my life.. I just hope I’ll be able to continue like this after I find a job, as I’m have been paid yet for the translation, and I don’t have any other income. It sucks not being able to test G/FBSD 6 just because the only other machine requires a damn PC100 memory stick to work (the memory I had was faulty, I had to trash it).

Codifiche, cosa sono e come usarle

Cenni storici

Non voglio iniziare a sviscerare tutta la storia delle codifiche dei caratteri all’epoca dei primi calcolatori o dei primi sistemi di trasmissione, poiché questa interesserebbe un pubblico molto limitato, quindi direi di partire da tempi più recenti, i tempi in cui la maggior parte delle persone utilizzavano sistemi DOS o DOS compatibili.

MS-Dos e la ASCII

Nel sistema operativo MS-Dos e compatibili, la codifica dei caratteri, ovvero delle lettere, dei numeri, dei simboli e di quelli che sono chiamati semigrafici, era effettuata utilizzando un codice ad 8 bit, chiamato ASCII (American Standard Code for Information Interchange). Questo codice comprende, oltre alle due serie di lettere (maiuscole e minuscole) dell’alfabeto latino esteso, ai numeri, ai simboli matematici di base, anche una serie di «caratteri di controllo» mutuati dai sistemi di trasmissione delle telescriventi per gestire particolari situazioni.

In realtà la codifica ASCII veniva gestita con due tabelle distinte: i primi 128 caratteri formavano la lower ASCII, mentre i restanti 128 formavano la upper ASCII o ASCII estesa.
La codifica dei caratteri della lower ASCII può essere effettuata utilizzando soli 7-bit, e questa parte della tabella veniva condivisa da tutti i sistemi. Qui sono presenti i caratteri alfanumerici e i simboli matematici base.
La codifica dei successivi caratteri, che richiede 8-bit, era però gestita in modo differente. Invece che una singola tabella, sono state fornite una serie di tabelle differenti, con un set di caratteri diverso. Questo perché per esempio i caratteri accentati, che in italiano utilizziamo normalmente, non sono utilizzati in molte lingue, mentre per esempio i caratteri di lingue che utilizzano un alfabeto diverso da quello latino non sono usati in italiano.

Da qui, si è giunti ad avere i primi problemi: i sistemi americani, per esempio, utilizzavano la tabella numerata 437, che comprendeva una quantità aggiuntiva di simboli semigrafici e matematici, mentre per l’Europa occidentale, che utilizza lingue neolatine, era stata predisposta la codifica numerata 850.
Un file di testo scritto con un sistema americano e letto su una macchina italiana sarebbe stato molto probabilmente sbagliato, se fossero stati usati i simboli semigrafici e matematici aggiuntivi, e al tempo stesso, un testo italiano, contenente caratteri accentati, letto su una macchina americana sarebbe stato illeggibile perché agli accenti si sostituirebbero dei caratteri semigrafici. Anche i caratteri semigrafici comuni alle due non si trovavano nella stessa posizione.

Ovviamente i testi americani, scritti soltanto con i caratteri alfabetici latini, non avrebbero avuto problema, d’altronde era l’American Standard, non l’International Standard.

L’arrivo di Windows

Quando Windows, in particolare nella sua versione 3.1, ha iniziato a comparire sul mercato, le cose si complicarono ulteriormente. Partendo da un presupposto giusto (il fatto che i caratteri semigrafici perdessero la loro importanza in un ambiente grafico, e che quindi sarebbe stato preferibile unificare perlomeno tutte le lingue che usano l’alfabeto latino), si è arrivati ad una soluzione che ha creato problemi anche più grossi.

La codifica dei caratteri all’interno di Windows ha assunto dei comportamenti completamente diversi: invece di utilizzare l’ASCII, sono state utilizzate delle codifiche ANSI, ormai chiamate semplicemente Windows CodePages.
La codifica utilizzata, sia su sistemi americani che europei, comprendeva in un’unica tabella la maggior parte dei caratteri utili delle codifiche 437 e 850, rimuovendo i caratteri semigrafici, quindi permetteva ai file di venir letti in modo corretto in entrambi i continenti. Purtroppo però, visto che i caratteri erano loro stessi disposti in modo diverso all’interno della tabella ASCII estesa, questa codifica era a sua volta incompatibile con le varie codifiche ASCII estese.
Per non creare troppi e ovvi problemi, i primi 128 caratteri (la lower ASCII di nuovo) erano presi direttamente dalla ASCII originale, in modo da essere compatibili perlomeno i testi in inglese.


Ma quando il problema pare risolto, perché finalmente Europa e America potevano comunicare direttamente senza intoppi, è la situazione attorno che inizia a cambiare. Invece di singoli elaboratori, si arriva ad un coinvolgimento globale degli utenti di computer in un’unica, grande, immensa Rete globale… Internet.

L’arrivo su Internet di tutti i vari sistemi eterogenei (MS-Dos, Windows, Unices vari), cominciò a far capire come l’uso di tutte queste codifiche rendeva difficile lo scambio di informazioni da un sistema all’altro. Posta elettronica, gruppi di discussione, pagine web, chat, ognuno di questi servizi, usato da utenti in lingua inglese, non creava nessun problema, ma quando veniva usato da utenti di sistemi diversi, in diverse parti del mondo, in lingue che richiedono caratteri diversi dall’alfabeto base, finiva per creare problemi di comprensibilità e di lettura.

Una soluzione poteva essere quella di utilizzare la codifica Unicode, che invece di essere a soli 8 bit ne utilizza 16, riuscendo a inserire in un’unica tabella oltre 65 mila caratteri. Purtroppo però usare questa codifica significherebbe anche raddoppiare la dimensione di ogni file di testo, cosa poco pratica per una Internet in cui i più fortunati riuscivano a raggiungere i 33.6 kbps.

Si intravide la luce: far in modo che i vari computer in tutto il mondo capissero la differenza tra le codifiche, e potessero riuscire a convertire da una all’altra senza perdita di dati. Questo fu uno dei compiti assegnati al MIME (per la posta elettronica e i gruppi di discussione) e ai meta tag di HTML.

Purtroppo, ancora per qualche anno i sistemi per la gestione di questi servizi non erano in grado di gestire informazioni ad 8-bit, quindi per risolvere il problema si giunse a soluzioni distinte ed incompatibili.
Per la posta elettronica e i gruppi di discussione, la soluzione utilizzata da molti client era quella di utilizzare il quoted-printable. Praticamente invece di inviare un codice ad 8-bit, veniva inviata una stringa del tipo =FF dove FF è la rappresentazione in esadecimale del codice del carattere da inserire.
Per i protocolli di trasferimento, come HTTP, il trucco è stato simile: %FF, dove FF rappresenta la stessa cosa. Per questo capita spesso che, accedendo ad aree personali di utenti unix, indicate solitamente con ~username, questo venga codificato in %7Eusername.
Infine, in HTML, le cose furono più complesse, perché si era voluto far in modo di definire una serie di caratteri «standard» che fossero codificabili arbitrariamente. Il risultato fu l’uso delle entità come per esempio © o è, ed eventualmente l’uso dell’escape dei caratteri particolari ({).
In modo simile, anche il LaTeX utilizza delle speciali entità, come per esempio copyright, se non si specifica una codifica ben definita.

La via degli standard: ISO8859

Infine, le cose cominciarono a migliorare, con la formazione da parte dell’International Standard Organization, di una serie di codifiche ad 8-bit unificate. Questo standard definisce 16 codifiche utilizzate a seconda del tipo di alfabeto che una lingua utilizza. Per esempio, la prima parte (ISO8859-1, chiamata anche Latin1) definisce una codifica (ancora una volta incompatibile con le precedenti ASCII e WindowsCP) per le lingue occidentali moderne, – in realtà ISO8859-1, per quanto standard di fatto per la maggior parte degli usi, dovrebbe essere deprecato, visto che in questa versione mancano il simbolo dell’euro (€) e la Ÿ utilizzata in alcune lingue. Per risolvere questi problemi il (fortunatamente compatibile) successore di ISO8859-1 è ISO8859-15 chiamato appunto Latin1+Euro. – che viene utilizzata come standard per tutte le applicazioni che non definiscono una codifica differente.

L’uso di questi set di caratteri permette allo scambio di informazioni tra sistemi eterogenei di non rischiare la perdita di informazioni: sapendo la rappresentazione delle informazioni e la codifica utilizzata, è possibile convertire queste in un altra rappresentazione utilizzabile nel sistema utilizzato.

Certo, non è ancora la soluzione più sicura per comunicazioni più vaste, come per esempio i progetti di software libero, in cui gli stessi file sorgente, in testo semplice, sono modificati da moltissime persone diverse senza che sia possibile indicare in modo certo e non fraintendibile la loro codifica, oppure per le chat come IRC, dove ogni messaggio viene inviato da un sistema diverso senza che ci sia un accordo «insindacabile» su che codifica utilizzare (analizzerò più avanti questo problema).

Infine, UTF-8

Per una comunità aperta alle esigenze di tutti i linguaggi, Unicode sarebbe stata la soluzione migliore. Ma il raddoppio della dimensione di tutte le informazioni che possono essere codificate con la tabella ASCII base è un problema non facilmente sormontabile.

Per risolvere questo problema, è stato ideato UTF-8. La codifica UTF-8 è una codifica a lunghezza variabile, dove in pratica i caratteri della ASCII base sono codificati esattamente allo stesso modo, mentre tutti i caratteri estesi vengono definiti con una sequenza di più di 8-bit (16 o 24, a seconda di quanti ne siano necessari per indicare la tabella e il carattere). Il risultato è che le informazioni che sono inviate in ASCII pura non occupano un solo byte più del necessario, mentre sono solo i singoli caratteri estesi a “pesare” di più.

Purtroppo, anche UTF-8 ha i suoi svantaggi, primo tra tutti che il sistema (e il programma) utilizzato per la comunicazione deve sapere come trattare questa rappresentazione. Questo problema sta venendo col tempo risolto, ed ormai tutti i sistemi operativi, anche se non utilizzano UTF-8 principalmente, sono capaci di gestire le informazioni codificate in questo modo.

L’overhead, ovvero il peso aggiunto dai caratteri estesi, all’interno dei documenti HTML e LaTeX (giusto per fare un esempio) è tra l’altro inferiore usando UTF-8 che utilizzando le entità definite da questi linguaggi. Stessa cosa vale per i messaggi di posta elettronica codificati in quoted-printable, inoltre è possibile utilizzare gli editor di testo (che supportano UTF-8) in modo molto più naturale.

Problemi pratici e soluzioni

Voglio ora dare uno sguardo ai vari problemi pratici creati dalle diverse codifiche e al modo in cui qusti sono stati risolti nel tempo, e parlare di eventuali soluzioni alternative che possono essere più pratiche nel tempo corrente.

Newsgroups e posta elettronica

Questi sono i due più classici esempi di problema, perché classicamente i client di Microsoft hanno sempre utilizzato le loro proprie codifiche nell’invio dei messaggi, risultando quindi illeggibili per ogni altro sistema o client.

La soluzione utilizzata per più tempo è stata semplicemente quella di non utilizzare i caratteri accentati, e di utilizzare invece i simboli ' o `. Questa soluzione, per quanto valida e utilizzata ancora da molti, è a mio avviso però inutile al momento. Con la standardizzazione dei set di caratteri, e la creazione di UTF-8, la cosa più pratica da fare è semplicemente utilizzare le lettere accentate in modo normalissimo, e lasciare ai client il compito di effettuare la decodifica. Se qualcuno stesse utilizzando un client che non è capace di effettuare la decodifica dei caratteri in ISO8859-1 o -15, il problema è del suo client, esistono alternative per ogni cosa.

Questo è quindi il mio consiglio: non maltrattate l’italiano, non siamo negli anni ’80.. usate pure le accentate.

Pagine web

Il problema più grave che si può avere con le pagine web è quello che molte persone hanno scritto le proprie pagine utilizzando FrontPage o FrontPage Express, creando quindi delle pagine codificate in WindowsCP, che è una delle peggiori cose che si possa fare.

La soluzione consigliata da molti «puristi» è quella di utilizzare la codifica ASCII 7-bit anche qui, e di utilizzare le entità definite da HTML. Io sconsiglio questa soluzione, perché per quanto minimo, crea un certo overhead che può, considerato in totale, essere un problema. Per essere pratici, la cosa più semplice è quella di definire il set di caratteri utilizzato dalla pagina come ISO8859-15 e di utilizzare i caratteri ad 8-bit normalmente o, ancora migliore, utilizzare UTF-8. Il motivo per cui considero questa una soluzione migliore è che molte persone utilizzano UTF-8 come codifica principale, quindi per vedere una pagina UTF-8 non devono effettuare nessuna ricodifica. Per esempio MacOSX utilizza come unica codifica, se non diversamente specificato, UTF-8.

Ricordiamoci che se inizialmente HTTP era utilizzato solo per trasferire file ASCII, ormai viene utilizzato anche per il trasferimento di file binari, quindi non sono più problemi fornire dei file codificati ad 8 bit.

Nomi di files

I nomi di files sono una questione abbastanza complessa. Finché vengono utilizzati solo su una macchina, ognuno potrebbe essere libero di utilizzare la codifica che preferisce. In realtà, penso che la cosa migliore sia anche qui di utilizzare UTF-8 liberamente. Il motivo è che questa codifica diventerà per forza di cose lo standard negli anni futuri, proprio per la continua globalizzazione delle comunicazioni, ed è sempre meglio essere in anticipo sui tempi che in ritardo. In fondo, non crea troppi problemi.

L’unico problema che può esserci è quando i file sono pubblicati su Internet, visto che, mentre FTP pare gestirli più che bene, HTTP ha problemi a gestire nomi di file codificati in UTF-8, essendo previsto l’uso solo di ASCII a 7 bit. Per questo, se dovete pubblicare un file su un server HTTP, il mio consiglio è quello di chiamarlo in un «modo Unix», ovvero corto, senza spazi, e usando sigle.

Io ho iniziato ad utilizzare UTF-8 in locale quando mi sono reso conto che avendo una rete di sistemi eterogenei, usando UTF-8 avrei evitato qualsiasi problema di comunicazione tra le macchine, visto che in questa codifica è possibile rappresentare praticamente qualsiasi carattere esistente.

Internet Relay Chat

Questo è il problema sicuramente più grosso. IRC è un servizio nato, come ogni altro, in America, dove il problema delle codifiche è molto poco sentito, visto che un testo inglese utilizza solo ASCII 7-bit. Inoltre, molti vecchi client non avevano nessuna possibilità di utilizzare qualcosa di diverso dalla codifica di sistema.

I problemi quindi non sono facilmente risolvibili, e vanno analizzati caso per caso. Possono esserci delle richieste relative ad un singolo canale, che vuole utilizzare una sola codifica, o altre relative all’intera rete.

Per esempio, utilizzando i servizi di AzzurraNet, la codifica «standard de facto» è ISO8859-15 (o -1, visto che sono pienamente compatibili, a parte i simboli mancanti, ovvio), poiché la maggior parte degli utenti è di lingua italiana, e questa codifica è la più compatibile possibile.
Invece, su una rete più globale, come FreeNode, è richiesto l’uso di UTF-8, perché possono incontrarsi persone che parlano italiano, arabo, ebraico, giapponese e via dicendo, e non è possibile continuare a cambiare la codifica per parlare con varie persone (il protocollo IRC non definisce un modo per indicare in che codifica sia ogni singolo messaggio).

Utilizzare una codifica «fuori dal comune» può creare problemi agli altri utenti del servizio, che faranno maggior fatica a intendere i messaggi, mentre l’uso del metodo suindicato per la posta elettronica, evitando di utilizzare le accentate, è una storpiatura della lingua, oltre che una precauzione ormai inutile. Anche qui, se il client non riuscisse a decodificare una determinata codifica, la colpa è sua, poiché nel 2005 non è più possibile fermarsi a quello che si faceva negli anni ’80.


Questo testo è probabilmente pieno di errori, dovuti al fatto che la storia delle codifiche la conosco perlopiù a spanne, non sono andato a cercare in maniera precisa date, eventi, e supporti.

Il mio obiettivo era solo quello di fornire delle spiegazioni al motivo per cui i problemi delle codifiche dei caratteri sono stati posti, e indicare cosa serve fare, e cosa è superfluo, per una convivenza pacifica. Come ho già espresso in un altro mio articolo, continuare con delle precauzioni e procedure di molto tempo fa serve solo a sentirsi sulle spine e forzati a comportarsi in modo non naturale, non portando ulteriori benefici alle persone.