Qual è l'utilità di mb_http_output() dato che la codifica di output è in genere risolta con altri mezzi?

Question

In Internet, incluso nello stackoverflow, si consiglia di utilizzare mb_http_input ('utf-8') per far funzionare PHP nella codifica UTF-8. Ad esempio, vedere PHP/MySQL encoding problems. â�� instead of certain characters. D'altra parte, il manuale PHP dice che non possiamo correggere la codifica di input nello script PHP e che mb_http_input è solo un modo per interrogare che cos'è, non un modo per impostarlo. Vedi http://www.php.net/manual/en/mbstring.http.php e http://php.net/manual/en/function.mb-httpetinput.php. Ok, questo era solo un chiarimento del contesto prima della domanda. Mi sembra che ci siano molti comandi ridondanti in Apache + PHP + HTML per controllare la conversione dalla codifica in ingresso alla codifica interna e infine alla codifica dell'output. Non capisco l'utilità di questo. Ad esempio, se la codifica di input originale di un client HTTP esterno è EUC-JP e ho impostato la codifica interna su UTF-8, PHP dovrebbe effettuare la conversione. Ho ragione? Se ho ragione, perché dovrei impostare una codifica in ingresso in php.ini (invece di passare solo quella originale) dato che sarebbe immediatamente convertito nella codifica interna utf-8? Una domanda simile vale per l'output. In tutti i miei file htpp, utilizzo un meta tag con charset = utf-8. Quindi, la codifica HTTP in uscita è fissa. Inoltre, in PHP.ini, posso impostare il default_charset che apparirà nell'intestazione HTTP a utf-8. Perché dovrei preoccuparmi di usare mb_http_output ('uft-8') quando la codifica dell'output finale è già stata riparata. Per riassumere, qualcuno può darmi un esempio pratico concreto in cui mb_http_output ('uft-8') è chiaramente necessario e non può essere sostituito da comandi più comuni che vengono spesso inseriti di default in editor come Dreamweaver?

Answer 1

Queste due opzioni sono quasi l'idea peggiore che i progettisti PHP abbiano mai avuto e hanno avuto molte cattive idee quando si tratta di codifiche.

Per convertire le stringhe - una codifica specifica, si deve sapere che cosa codifica si sta convertendo da. I dati in arrivo sono spesso in una codifica non dichiarata; il server riceve solo alcuni dati binari, non sa quale codifica rappresenta. Devi dichiarare quale codifica ti aspetti che il browser invii impostando l'attributo accept-charset sui moduli; non è una garanzia che il browser lo farà e non fa sapere a PHP quale codifica aspettarsi.

Lo stesso vale per l'output; Le stringhe PHP sono solo array di byte, non hanno una codifica associata. Non ho idea di come PHP pensi di sapere come convertire stringhe arbitrarie in una specifica codifica sull'ingresso o.

Si dovrebbe gestire questa operazione manualmente, ed è davvero facile da fare in ogni caso: dichiarare ai clienti ciò che codifica che ci si aspetta, controllo se l'input è nella codifica corretta utilizzando mb_check_encoding (non _detect encoding o qualcosa di simile, solo controllo) , rifiutare l'input non valido, fare in modo di mantenere tutto nella stessa codifica all'interno dell'intero flusso dell'applicazione. Ad esempio, idealmente hai nessuna conversione nella tua app.

Se fai necessità di convertire in qualsiasi punto, ne fanno un panino Unicode: la conversione in ingresso dalla codifica atteso a UTF-8 o un'altra codifica Unicode su input, riconvertirlo alla codifica di output desiderato su di uscita. Ogni volta che devi convertire, assicurati di sapere cosa stai convertendo da. Non puoi magicamente "rendere tutte le stringhe UTF-8" con una dichiarazione.