Я подозреваю, что у вас есть несколько проблем.
На самом деле существует несколько распространенных способов представления текста на японском и китайском языках с использованием устаревших кодировок (Shift_JIS, EUC-JP и JIS-вариантов для японского и нескольких других для китайского) или Unicode (UTF-8 или UTF-16). , Для многоязычного приложения предпочтительным решением является передача содержимого страницы в UTF-8; Сама Windows предпочитает хранить контент в UTF-16 (именно это NTEXT и NVARCHAR используют в MS SQL Server).
Для того, чтобы японский контент отображался правильно, вам нужно убедиться, что на каждом этапе вашего конвейера данных происходят правильные преобразования. Давайте предположим, что вы собираетесь использовать Unicode ради здравомыслия, но ответ будет аналогичным, если вы намеренно решили использовать Shift-JIS, big5, gb2312 или что-то еще, только более сложное.
Если ваши данные в основном поступают из веб-форм, вам необходимо убедиться, что для вашей кодовой страницы установлено значение 65001, обычно с помощью директивы <% @ codepage = 65001%> в верхней части каждого файла ASP.
Кроме того, вы должны предоставить подсказку вашим пользовательским агентам (веб-браузеру), которые вы используете UTF-8. Есть два метода, один с использованием заголовка HTTP; другой вариант - подделать заголовок HTTP с метатегом.
Решение метатега:
Решение для HTTP-заголовка, использующее мои ржавые навыки ASP (предполагая javascript, но вы, вероятно, используете vbscript, который потребует от вас отказаться от точек с запятой)
Response.ContentType = "текст / html";
Response.Charset = "UTF-8";
Если вы берете данные в MSSQL в виде каналов, а не веб-форм, вам также необходимо убедиться, что данные преобразованы правильно. В зависимости от вашего механизма импорта способ указания исходной кодировки может быть разным, поэтому мне придется оставить это как «упражнение для читателя».
Далее, при отправке данных на сервер SQL вам необходимо убедиться, что вы используете правильный механизм ввода SQL. Если вы не параметризуете свои запросы (и должны это делать), вам нужно не забывать использовать форму N'MyText 'вместо «MyText» при вводе текстовых параметров в запросе. Если вы настраиваете свой текст, когда вы используете adVarChar, вы должны использовать вместо него adVarWChar. (Для каждого типа данных ADO существуют соответствующие типы "W").
Кроме того, некоторые браузеры используют атрибут HTML LANG в качестве подсказки для отображения текста подходящим шрифтом для языка контента. Если вы знаете, на каком языке находится ваш контент, вы можете добавить LANG = "ja-jp" к любому элементу HTML (включая BODY). Затем браузер должен использовать разумный шрифт по умолчанию для этого языка (но вы можете явно указать его, если хотите). Большинство браузеров, созданных за последние 5 лет, используют магию связывания шрифтов, даже если вы выбрали неподходящий шрифт по умолчанию для определенного языка, но вы получите более надежные результаты и немного лучшую производительность рендеринга, если будете использовать подходящий шрифт.
В качестве дополнительной заметки
Если вы получаете почти правильные результаты при ручном принудительном кодировании в браузере как shift-jis, это означает, что вы, вероятно, используете windows-1252 в качестве набора символов <% @ codepage = 1252%> и вам повезло что содержание не было испорчено полностью. Есть пара хаков, которые могут восстановить шланг Shift-Jis-in-1252 или iso-8859-1, но они не на 100% надежны.
Что касается сортировки на сервере SQL, это имеет два последствия. В полях NVARCHAR и NTEXT это влияет только на сортировку и запросы (включая регистр, акцент и чувствительность к кане) В полях varchar и text это также влияет на кодировку, но это не самое разумное решение вашей проблемы.