Newsgroup: it.comp.macintosh
Titolo: [X] Che fine a fatto php.ini?

Ieri discutendo con gomi in chat abbiamo notato che la funzione php
htmlentites() non funzionava correttamente, nel senso che le lettere
accentate non venivano trasformate nelle relative entita' html.
Cercando di capire dove fosse il problema mi sono reso conto che il file
php.ini (che secondo la funzione phpinfo() dovrebbe essere in /usr/lib)
non esiste. Ho provato una ricerca sull'hd ma senza successo. Temo che
questo possa essere un bug dell'ultimo aggiornamento Apple del php e
volevo avere conferme da qualcun'altro a tale proposito
-- 
Outside of a dog a book is a man's best friend.
Inside of a dog is too dark to read  (Groucho Marx)
"ab_bar" is ROT13 encoded

 conferme da qualcun'altro a tale proposito
non c'e' neanche q'ui, stasera me ne scarico uno e vediamo
-- 
siamo tutti sovversivi

 mi sto facendo orora la tabella a mano... :_(
Poiche sulla RH con PHP 4.1.2 htmlentites mi funziona, credo che il prob
sia collegato alla mancanza del file .ini, o comunque ad un
malfunzionamento della versione Apple del PHP.
IMHO rifarti la tabella a mano mi sa di lavoro inutle.. :-/


 non esiste. 
Io sull'iBook non ce l'ho (quindi PHP applica i suoi default) e l'output 
di htmlentities() e' corretto, per i file in ISO-8859-1.

 di htmlentities() e' corretto, per i file in ISO-8859-1.
Gli passo direttamente la stringa da convertire. Il File ha nell'header
la specifica del charset iso-8859-1


 Anche il PHP di Lynage ha lo stesso problema?
Non so. Io ho su quello Apple.


 IMHO rifarti la tabella a mano mi sa di lavoro inutle.. :-/
devo farlo comunque: non converto tutto
-- 
siamo tutti sovversivi

 la specifica del charset iso-8859-1
Se lo script invia un header ma il file e' salvato in un altro modo, 
l'header non serve...

 Ma la stringa da dove viene? File? DB?
htmlentities("איטלעש"); ritorna caratteri strani, e piu' su c'ho messo
<META HTTP-EQUIV="content-type" CONTENT="text/html; charset=iso-8859-1">
-- 
siamo tutti sovversivi

 <META HTTP-EQUIV="content-type" CONTENT="text/html; charset=iso-8859-1">
Ah, ok.
Beh, il meta e' irrilevante (e' inutile a prescindere, ma in questo caso 
lo e' tanto quanto una intestazione HTTP), perche' al momento in cui il 
parser del PHP cerca di trasformare la stringa "איטלעש" in entita', 
quello che conta effettivamente e' il set di caratteri con cui e' stato 
salvato il file.
Inoltre un entita' rappresenta un singolo carattere con posizione 
maggiore di 128 (eg.: "א") con piu' caratteri con posizione < 128 
(caratteri ASCII, quindi, eg.: "&agrave;"). Una volta che i caratteri 
sono stati convertiti in entita', l'encoding usato per trasferire i file 
dal server al client (quello specificato nel meta, o meglio via 
intestazione HTTP), non ha particolare importanza perche' sia' 
ISO-8859-1, sia UTF8 sono superset di ASCII.
Tornando al problema, ho provato ora a usare quella stringa con 
htmlentities in un file salvato come UTF8 (da TextEdit). Il risultato e' 
questo:
&Atilde;&nbsp;&Atilde;&copy;&Atilde;&uml;&Atilde;&not;&Atilde;&sup2;&Atil
de;&sup1;
Sono 12 entita', per 6 caratteri. Perche' in UTF8 i caratteri con 
posizione maggiore di 128 sono rappresentati con 2 byte (anche di piu', 
dipende). Il parser PHP in quella stringa incontra 12 byte e tratta 
ognuno di questi come un byte ISO-8859-1; il risulta e' ... il pasticcio 
indicato sopra.
Se il tuo problema e' questo, allora hai due soluzioni: salvare i file 
in ISO-8859-1 (se usi BBEdit 7 e scopri come si fa, fammello sapere :), 
oppure converti la stringa usando utf8_decode() *prima* di darla "in 
pasto" a htmlentities():
echo htmlentities(utf8_decode("איטלעש"))
Se il problema e' dovuto alla codifica dei file in MacRoman, allora non 
so se c'e' una soluzione che non sia riconvertire i file.

 Sono 12 entita', per 6 caratteri.
il risultato non erano entita', ma altri caratteri (:-?). cmq ho risolto
cosi':
$tabella = array(
        'ç' => '&ccedil;',
        '£' => '&pound;',
        'à' => '&agrave;',
        'â' => '&acirc;',
[SNIP]
$testo = nl2br(strtr($testo, $tabella));
in questo modo la tabella e' definita sicuramente nello stesso charset
del testo da convertire, quindi funziona
-- 
siamo tutti sovversivi

 in ISO-8859-1 (se usi BBEdit 7 e scopri come si fa, fammello sapere :),
uh ? se da save as -> options non spunti save as unicode non dovrebbe
salvare in ISO-8859-1 ?
-- 
siamo tutti sovversivi

 salvare in ISO-8859-1 ?
Boh quando l'ho usato appena rilasciata la v.7 non mi pare ci fosse 
quell'opzione. Domani riprovo.

 Domani riprovo.
Ho provato subito: se non uso l'opzione "Save as Unicode" salvo un 
documento MacRoman. Domani provo con la 7.1.

 del testo da convertire, quindi funziona
Attento pero' che cosi' quello che converti in entita' non e' davvero il 
carattere 'à' ma un altro (che ti viene mostrato come 'à' dall'editor 
che usi). A lungo andare, e se i file verranno anche modificati su 
un'altra piattaforma che non sia Mac, rischi di avere dei problemi.
Meglio piuttosto una conversione dei file, magari in automatico con 
programmi come questo:
http://versiontracker.com/moreinfo.fcgi?id=1115&db=mac

 
http://versiontracker.com/moreinfo.fcgi?id=1115&db=mac
ottimo, funziona
-- 
siamo tutti sovversivi

 HIGH-ASCII in entita` HTML, intendo prima di passarli al PHP? 
non li scrivo io i testi
-- 
siamo tutti sovversivi

 Intendi la 7.0.1? Si comporta allo stesso modo, vero?
Si', 7.0.1, era un typo.
Se salvo con l'opzione Unicode mi ritrovo, appunto con un file Unicode 
(quindi devo/posso usare htmlentities(utf8_decode($stringa))) mentre se 
non la attivo, mi ritrovo un file MacRoman (o meglio, non so se e' 
davvero MacRoman, pero' di certo non e' Latin1).
Nelle preferenze non c'e' nulla al riguardo, mi pare.

 HIGH-ASCII in entita` HTML, intendo prima di passarli al PHP? 
Beh quello puo' essere utile, soprattutto se si modificano i file su 
piu' piattaforme diverse. Pero' cosi' si perde la comodita' di farlo 
fare a PHP :)

 salvato il file.
E si, hai proprio ragione. Ed ho capito anche perche' il file generato
su Mac mi funge sulla RH: Fetch si incarica di eseguire la traduzione
dei caretteri ISO (c'e' un'opzione ad hoc nelle preferenze).
Ed il fatto che abbia sempre funzionato in locale e' legato al fatto che
i dati contenenti lettere accentate sono contenuti in database sql la
cui lettura/scrittura viene fatta diretamente via browser.
resta il mstero di che fine abbia fatto il file php.ini. A me sembrava
che prima ci fosse.. :-?
Tnx


 che prima ci fosse.. :-?
Dunque, il php.ini m'e' capitato di cercarlo un paio di volte, sul 10.2
e su un 10.1.non_ricordo (Server, pero'). In entrambi i casi phpinfo()
sosteneva che il file doveva essere in /url/lib/php.ini. Non c'era in
entrambi i casi.
Pero' e' bastato crearne uno e riavviare Apache perche' i setting
specificati nel nuovo venissero applicati.
Il php.ini che ho ora sul 10.2.2 e' stato creato a partire da questo:
http://cvs.php.net/co.php/php4/php.ini-dist

 Jaguar non c'e` mai stato.
q'ui c'era, ma con l'orgia di installazioni che ho fatto (sorgenti,
binari vari, entropy, apple) non saprei da dove venisse fuori :)
-- 
siamo tutti sovversivi

 MySQL funziona. Dove ho sbagliato? Come rimedio?
Cioe' c'e' il demone (mysqld) in esecuzione sul tuo computer ma non
trovi i programmi per manipolare i database (mysql, mysqladmin,
mysqldump, eccetera)? 
Se e' cosi', quei programmi dovrebbero essere installati in
/usr/local/bin, prova ad eseguire: /usr/local/bin/mysql e a vedere se
cosi' va...

 scrivendo "mysql", ma non si puo` sempre capire tutto. :-)
colpa di jaguar (faq 178)
-- 
siamo tutti sovversivi

 scrivendo "mysql", ma non si puo` sempre capire tutto. :-)
Perche' la directory /usr/local/bin/ non e' nel percorso di ricerca,
puoi aggiungerla con:
echo 'setenv PATH /usr/local/bin/:$PATH' >> .tcshrc

 Non eri un fan di NewsWatcher?
Tutto sommato lo sono ancora, fan di MT-NewsWatcher, ma avro' bisogno di
un newsreader che mi permetta di leggere i post anche off-line,
prossimamente, e MT funziona solo on-line. L'alternativa poteva essere
Thoth ma non mi piacciono troppo le differenze con l'interfaccia di MT e
la gestione del killfile. Halime invece mi pare ancora immaturo.
Di MT, rispetto a MacSoup, preferisco ancora la gestione dei
filtri/killfile, e l'interfaccia. Di MacSoup apprezzo pero' gia' il
fatto che mi segnala i follow up ai miei post prima che io apra l'elenco
dei messaggi :) 

 HIGH-ASCII in entita` HTML, intendo prima di passarli al PHP?
A tal proposito:
http://versiontracker.com/moreinfo.fcgi?id=8214&db=mac

 scarichi e non trovi pallini ci rimani male.
Oh, beh quella ce l'ho gia' :)
(non solo per i followup, pero' anche con MT avevo una lunga lista di
'autori preferiti' che tra l'altro ora dovro' reimportare a mano, sob).

 Io p.e. lo uso senza mouse.
Anche io, la possibilita' di poterlo usare senza necessariamente
rincorrere il mouse e' un 'must', per me.

 Halime invece mi pare ancora immaturo.
E soprattutto le prestazioni calano in maniera vertigionosa al crescere
del numero dei post. Davvero inutilizzabile. Peccato.. :-(
