Po prostu pytasz, jak przechowywać znaki UTF-8/16 w DB? w mysql to tylko kwestia upewnienia się, że budujesz z obsługą UTF8 i ustawiasz ją jako domyślną lub określasz ją na poziomie kolumny lub tabeli. Robiłem to wcześniej w Oracle i MySQL. Stwórz tabelę i wycinaj i wklejaj dane i18n do niej i zobacz, co się stanie ... możesz już ustawić.
lub czy całkowicie pomijam twój punkt widzenia?
edit:
być bardziej wyraźny ... Ja zwykle realizować trzy kolumny tabeli ... język, klucz, wartość ... gdzie „wartość” zawiera słowa lub wyrażenia języka obcego potencjalnie ... " język "zawiera jakiś klucz języka, a" klucz "jest angielskim kluczem (tzn. login.error.password.dup) ... język i klucz są indeksowane ...
Zbudowałem interfejsy na takiej strukturze który pokazuje każdy klucz wraz ze wszystkimi jego tłumaczeniami (wartościami) ... może się wydawać fantazyjny i zawierać ścieżki audytu i "brudne" znaczniki oraz wszystkie inne rzeczy, które są potrzebne, aby umożliwić tłumaczom i ludziom wprowadzającym dane do korzystania z nich ..
Edit 2:
Teraz, po dodaniu informacji o znacznikach JSTL, rozumiem trochę więcej ... Nigdy nie robiłem to sam .. ale znalazłem ten stary info o theserverside ...
HttpSession session = .. [get hold of the session]
ResourceBundle bundle = new PropertyResourceBundle(toInputStream(myOwnProperties)) [toInputStream just stores the properties into an inputstream]
Locale locale = .. [get hold of the locale]
javax.servlet.jsp.jstl.core.Config.set(session, Config.FMT_LOCALIZATION_CONTEXT, new LocalizationContext(bundle ,locale));
Zgadzam się, że ładowanie wszystkich tłumaczeń w większych aplikacjach może powodować problemy. W naszym przypadku to nie był problem i spełnił naszą potrzebę. Mój kod można zmodyfikować tak, aby korzystał z mechanizmu buforowania, który utrzymywał tylko podzbiór tłumaczeń w pamięci w danym momencie. Kod był tylko przykładem tego, co zadziałało, a nie tym, co byłoby najlepsze we wszystkich sytuacjach. – ScArcher2