JSF/Facelets utilizza per impostazione predefinita UTF-8 per decodificare i parametri di richiesta HTTP. GlassFish stesso usa di default ISO-8859-1 per decodificare i parametri di richiesta HTTP. I parametri di richiesta HTTP possono essere analizzati e decodificati solo una volta e ciò accade ogni volta che un parametro di richiesta viene richiesto dal codice per la prima volta, ad esempio request.getParameter("name"). Pertanto, se un parametro di richiesta viene richiesto per la prima volta prima di, JSF ha impostato la codifica del parametro di richiesta su UTF-8, quindi verrà analizzato (erroneamente) mediante ISO-8859-1.
Quando JSF deve impostare il parametro di richiesta codifica durante il ripristino fase vista come segue,
request.setCharacterEncoding("UTF-8");
mentre i parametri di richiesta sono già analizzati, quindi GlassFish mostrerà esattamente questo avviso.
La conseguenza indesiderata è che tutti i parametri di richiesta HTTP potrebbero finire nello Mojibake. I dati del modulo sono originariamente inviati e codificati utilizzando UTF-8. Se decodifichi i dati UTF-8 utilizzando un set di caratteri diverso come ISO-8859-1, i caratteri nell'intervallo di 8 bit e oltre (di solito sono quei "caratteri speciali" come é, à, ö, ecc. e finiscono in é, à , ö, ecc
Tecnicamente, la soluzione giusta è quella di non richiesta di un parametro di richiesta HTTP prima JSF è impostare la codifica a destra. che, fondamentalmente bisogno di controllare tutto il codice che viene eseguito prima della fase di visualizzazione di ripristino di JSF, ad esempio filtri di servlet, listener di fase, ecc., se non lo fanno.
Se non riesci a trovarlo, o il codice è fuori dal tuo controllo, puoi dire a GlassFish di usare UTF-8 invece di decodificare i parametri di richiesta HTTP, in modo che non debba essere cambiato quando JSF vuole per averli. Potete farlo aggiungendo la seguente voce al <glassfish-web-app> del /WEB-INF/glassfish-web.xml del file:
<parameter-encoding default-charset="UTF-8"/>
(nota: il file e voce principale è precedentemente chiamata sun-web.xml e <sun-web-app> rispettivamente)
Celebre deve essere quella questo è specifico per GlassFish e tutto questo non funzionerà quando si distribuisce la webapp su un altro server.L'approccio indipendente dal server canonica è quello di creare un servlet filter che fa in sostanza il seguente lavoro in doFilter() metodo:
request.setCharacterEncoding("UTF-8");
chain.doFilter(request, response);
e assicurarsi che è stato mappato prima di ogni altro filtro che ha bisogno di raccogliere eventuali parametri di richiesta HTTP.
Aggiornamento: il motivo per cui GlassFish ha fissato in anticipo, è forse causato da primefaces. Vedi anche questa domanda correlata: Unicode input retrieved via PrimeFaces input components become corrupted.
Dalla mia esperienza questo famoso messaggio si perde dopo l'aggiornamento di versione mojarra . Quale stai usando? – Osw
@Osw: c'era effettivamente un bug correlato in una delle prime versioni di Mojarra 2.0.x, ma questo era causato da un leggero problema e riguardava solo le richieste Ajax. OP sta comunque utilizzando GF 3.1 che raggruppa JSF 2.1. – BalusC
@osw: in particolare sto usando GF 3.1.1 Build 12. Probabilmente non dovrei, ma lascio che sia Netbeans che GF scarichino tutti gli aggiornamenti non appena diventano disponibili. Ricordo questo problema a quasi tutti i livelli di versione, comunque. È appena arrivato al punto in cui stavo testando molte pagine, generando un numero sufficiente di quei messaggi di errore nel processo, che mi è stato stimolato a intraprendere un'azione su di esso. A proposito la versione di Mojarra in questo pacchetto è 2.1.3 (FCS b02). – AlanObject