stringa per mod_rewrite

[daniele_dll]

mmm, due cose però:
- lanciare un htmlentities è un trucchetto interessante, ma poi ti tocca lanciare una espressione regolare apposta e ti rimangono per altro varie robe poco carine (la è viene convertita in è e con la seconda espressione regolare diventa -egrave- )
- cosi ti ritrovi a lanciare due espressioni regolari, una delle due può essere tranquillamente sostituita da una str_replace che pesa molto meno sul processore

[Enoa]

Originariamente inviato da daniele_dll
mmm, due cose però:
- lanciare un htmlentities è un trucchetto interessante, ma poi ti tocca lanciare una espressione regolare apposta e ti rimangono per altro varie robe poco carine (la è viene convertita in è e con la seconda espressione regolare diventa -egrave- )
- cosi ti ritrovi a lanciare due espressioni regolari, una delle due può essere tranquillamente sostituita da una str_replace che pesa molto meno sul processore

La è diventa & e grave;, con la preg prendo solo la e. In genere preferisco le whitelist, ma dimentico sempre qualcosa (santa pigrizia ).
Sulle prestazioni di str_replace rispetto alla preg, sono d'accordo, ma la uso "onInsert" e basta.

[k.b]

C'e' anche iconv() per questo mestiere:

$string = 'àèéìòù';
echo iconv('UTF-8', 'ASCII//TRANSLIT', $string);

// output: aeeiou 

[Luke70]

Originariamente inviato da k.b
C'e' anche iconv() per questo mestiere:

$string = 'àèéìòù';
echo iconv('UTF-8', 'ASCII//TRANSLIT', $string);

// output: aeeiou 

Torniamo quindi alla proposta che avevo fatto prima.
Ha ragione daniele_dll a dire che utilizza funzioni più lente, ma è anche vero che non si genera uno slug in frontoffice, ma in backoffice e solo nella creazione dell'articolo. Quindi possiamo tollerare qualche millisecondo in più.

[k.b]

Ah scusa Luke mi ero perso il link che avevi postato.

Il discorso sulla maggior pesantezza di alcune funzioni ha senso se si parla di trattare grosse quantita' di dati, per trasformare una stringa di pochi caratteri la differenza e' irrilevante.

[daniele_dll]

si, infatti come dicevo è indifferente in questo specifico caso perché non è un problema di performance, però comunque se si può ottimizzare perché non farlo?

[Enoa]

Mi son messo a fare dei test con iconv e ho riscontrato problemi in locale e 6 server differenti (tutti linux, dedicati e shared).
Eseguendo semplicemente:

$string = 'àèéìòù';
echo iconv('UTF-8', 'ASCII//TRANSLIT', $string);

ottengo: ??????

Eseguendo invece:

setlocale(LC_CTYPE, 'it_IT.utf8'); //in accordo con quando installato sul sitema
$string = 'àèéìòù';
echo iconv('UTF-8', 'ASCII//TRANSLIT', $string);

// output: aeeiou

A voi funziona correttamente senza setlocale?

[daniele_dll]

senza setlocale non sa qual'è la codifica di partenza

più che altro mi stranizza che l'ultimo esempio che hai scritto ti sia funzionato, hai salvato il file in utf8?

[Enoa]

Originariamente inviato da daniele_dll
senza setlocale non sa qual'è la codifica di partenza

più che altro mi stranizza che l'ultimo esempio che hai scritto ti sia funzionato, hai salvato il file in utf8?

Si il file è utf8, tu cosa ottieni se lo esegui?
Il discorso del setlocale lo ho trovato in un commento alla funzione sul manuale di php e copia/incollato pari pari

Scusa, ma ad iconv cosa interessa del setlocale in presenza di UTF8 e ASCII?

non mi funziona nemmeno da riga di comando (Ubuntu 11.04):

$ iconv -f UTF-8 -t ASCII <~/Scrivania/utf8 >~/Scrivania/ascii
iconv: sequenza di input non consentita alla posizione 0

il contenuto di utf8 è:

ìèàùò

se do

$ file utf8
//utf8: UTF-8 Unicode text

e in /etc/default/locale sono presenti i seguenti valori:

LANG="it_IT.UTF-8"

[daniele_dll]

è una combinazione di situazione

innanzi tutto per poter gestire correttamente l'UTF8 devi avere tra i locales abilitati nel sistema un it_IT.UTF-8 (o comunque quello che specifichi nelle variabili LC_xxx).

Su ubuntu/debian l'elenco dei locales installati ed abilitati lo prendi da
/etc/locale.gen

Puoi guardare il locale attuale tramite il comando
locale

(lancialo sul server che ti fa casino con la translitterazione)

Se li in mezzo non compare la riga che indica l'UTF-8 significa che non sono abilitati e quindi iconv non saprà come effettuare la conversione facendo un gran casino

Il motivo per il quale su uno dei server potrebbe non funzionarti potrebbe dipendere da questo fattore.

Detto questo, mi pare di capire che iconv legga da LC_COLLATE cosa usare per la traslitterazione (la collation, un pò come su mysql), qui ci sono maggiori info su LC_COLLATE
http://publib.boulder.ibm.com/iserie...tecategory.htm

Tra l'altro su windows potrebbe essere fonte di guai (ammesso che la funzione iconv funzioni, non ho provato) perché l'unica collation presente è quella relativa alla lingua impostata nel sistema che non è utf8 ... insomma succede un gran casino