-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Тимур,
On 1/16/14, 8:23 PM, Тимур Кулибаев wrote: > Hello, Chris ! Thank you for your response. Below are answers to > your questions. > > +++If the data is correctly-stored in the database (as verified by > some +++other means), does the fetched-data display correctly in > your web pages? > > Yes, data is displayed correctly in web-pages. Only problem is > that with Tomcat 7 Kazakh letters are not displayed correctly. But > with Oracle Application Server all data including Kazakh letters > are displayed correctly. So... data is displayed correctly in web pages or data is not displayed correctly in web pages? You said both above. > +++If it's not displaying correctly, please tell us what the > Content-Type +++HTTP response header is for the page (specifically, > the character +++encoding). > > For Tomcat 7: lang="ru-RU", content="Oracle UIX", > charset="UTF-8" type="text/css" inside of pages I can see that all > user data is in UTF-8 - we need force Tomcat works in > Windows-1251. If you are indeed setting the charset to UTF-8, then the page character encoding should be in UTF-8. You don't want to advertise UTF-8 and then use Windows-1251. > For Oracle AS: lang="ru", content="Oracle UIX", charset="UTF-8" > type="text/css" inside of pages I can see that all user data is in > Windows-1251 that is correct. If the server is advertising the character set as UTF-8 but using Windows-1251 then that is a big bug. I suspect you are not sure what character encoding is being used, but you know that the characters you expect to "work" are not working. > I don't know from where servlet takes charset="UTF-8" as its > web.xml Stop right there: charset=UTF-8 has nothing to do with web.xml. > sets Windows-1251 as servlet default codepage There is nothing called "servlet default codepage". > Looking through servlet source code there is not explicit > HttpServletResponse.setContentType(....). May be it comes from > UIX configuration tables residing in database, I'll ask developers > about it and let you know. You will need to check that out. UIX is an Oracle technology and can do whatever it wants to do. > +++Also, please tell us what the character encoding is for the > +++/database connection/ to Oracle (the one made from your > application +++to Oracle). > Database has CL8MSWIN1251 as default codepage and character > encoding for the database connection to Oracle is also > CL8MSWIN1251. Can you confirm that is the case? When setting user.country=kz, it causes the connection to fail to connect because the locale isn't supported. That makes me think that you will have to explicitly set the charset of the connection in order for things to work. For my money, I'd set the connection charset to UTF-8 because things just tend to work when you use UTF-8. > +++Finally, how are you connecting to Oracle? Are you using a > +++Tomcat-configured DataSource or is your web application > configuring +++things on its own? > > DataSource is not used. My web-application reads jdbc-connection > string from web.xml: <init-param> > <param-name>kz.ft.uix.app.driver</param-name> > > <param-value>jdbc:oracle:thin:@10.1.102.124:1526:fb</param-value> > </init-param> > > > +++I can see that when you attempt to use user.language=ru and > +++user.country=kz, you get this error from Oracle's driver: > > +++> org.apache.catalina.core.ApplicationContext log MESSAGE = +++> > ORA-00604: error occurred at recursive SQL level 1 ORA-12705: +++> > invalid or unknown NLS parameter value specified , ERRORCODE = 604 > > +++Can you give us the whole stack trace from that? > > First I generated list of all available locales based on java-code > given here > http://www.avajava.com/tutorials/lessons/how-do-i-display-all-available-locales.html;jsessionid=0F8CED6D22D750F6C83FD9477A3A874D > > see attached available locales list and one does not contain "kz" > so driver cannot understand this incorrect setting. If the driver is choking on that setting, I think it's clear that some character set is being set by whatever "kz.ft.uix.app.driver" does. > +++Can you give us the whole stack trace from that? > > [No, I can't give you that for some reason] > When set "-Duser.language=ru -Duser.country=RU" than no errors, > all is ok, only Kazakh letters displayed incorrectly. Tomcat 7 and > Oracle AS uses the same jdbc-driver ojdbc14.jar from Oracle AS. > Operation systems of hosts have the same configuration. > > Oracle AS works in Windows-1251, it sends user data from database > to browser in Windows-1251. Tomcat 7 works in UTF-8 , it sends user > data from database to browser in UTF-8, t's the root of the > trouble. How to make Tomcat 7 works in Windows-1251 ? The character set used between the server and the browser should not be an issue as long as: a. The characters are not already corrupted, and any java.lang.String values have correct characters b. The page's character encoding can support the character in question c. The server sends an accurate character encoding to the client in the Content-Type header d. The client honors the character encoding If any one of those things is not true, then you can have a problem. If the database driver breaks things before (a), that can be a problem, too. Can you write a Java servlet -- without any database interaction -- that generates a Kazakh character and sends it to the client using UTF-8 and verify that *that* works? Can you give me a reference to a Kazakh character online that I can find? For example, try searching on this site: http://unicodelookup.com/ I may be able to create a servlet that does it, and you can test it in your environment. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJS2JYcAAoJEBzwKT+lPKRYtKsP/3bU3ZvyQ35yhOmJktvenTmV 8BBlQb9iRs9UmNK25jZc+x8gDNa2WjorCuM94f3as/eGG1/stP5ln6CUqQPeXDn+ PKSN3U3Y62zvbbwDCRHaEW2nEk2ll/+njAsTHAPlcQqD6ar6bmVZt1c7KrBUODjq 4yP+B+AnKYZXNyshRE+cDwDTwOVbiisGTH66pewH96PoX9t8tr+j5Abh0UuIvwUZ RIxckdd+yMQyqFE8nhzEedoRX0kAuppUEyeIG1ZDj9Moo1hg52UVSAP+mf2Piika B3HpoR43PEgFRmW0/UZtWEaMeRu0f4+1Z81JnLJmguhEl+3w+UCt6LQP0M/vAbDR TfpExmxqqH+wpUHCbhJ/Z78nCFTlj7MDs+QnOjKDZBUkldGEaWOI0SHGChxEgB/M bPWYW3qZaw7pMXDHIKnHmHfEEkicl9h328PfabsN77DDT+AEDd2xhlgo8UcsobM3 UQtWs60Je4fT5ixpGlxhLVcwdYF3kLR6CWqyOKPuUzs3f4WQxG5fADF9I667ww3c 0cim/wxuVGk4KliWhgbhewPvJV8/PMQB2T5dswvsgBep5+Htk5nfOsMEeMB1E4vt +Ywa/87UPpr3F2OiuOBdSZbgSmqLY2YT1CqDabqxXpkAkSDCTQvIOKmn0wp7LOD2 ZzGDiJz9Mc3z/TnD91DZ =Aoww -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
