Правильная кодировка для работы с вьетнамскими символами (это не Юникод) в PHP

Question

Я искал вокруг какое-то время и еще не нашел что-то, что будет работать для меня. Я использую форму PHP для отправки данных в SAP с использованием API SAP DI. Мне нужно выяснить, какой набор символов позволит мне хранить и работать с вьетнамскими персонажами.

UTF8, похоже, работает для многих персонажей, но ô становится Ã'. Что еще более важно, существуют ограничения на характер, а UTF-8 нарушает лимиты символов. Если у меня строка из 30 символов, она сообщает API, что это больше, чем 50. То же самое верно для хранения в MySQL - если есть предел символов varchar, UTF-8 заставляет строку перемещаться над ней.

К сожалению, когда я ищу, UTF-8, кажется, единственное, что люди предлагают для вьетнамских персонажей. Если я вообще не кодирую символы, они сохраняются как их коды символов html. Я также пробовал ISO-8859-1, конвертируя в UCS-2 или UCS-4 ... Я действительно в растерянности. Если у кого-то есть опыт работы с вьетнамскими персонажами, вам будет очень благодарна ваша помощь.

UPDATE

Похоже, проблема может быть с моей WampServer на Windows. вот немного кода, который сбивает с толку меня:

$str = 'VậTCôNG'; 
$str1 = utf8_encode($str); 
if (mb_detect_encoding($str,"UTF-8",true) == true) { 
    print_r('yes'); 
    if ($str1 == $str) { 
     print_r('yes2'); 
    } 
} 
echo $str . $str1; 

Это печатает «да», но не «да2», и $ str.str1 = «VậTCôNGVáºTCÃ'NG» в браузере.

У меня есть файл php.ini с:

default_charset = "utf-8" 

и мой файл httpd.conf с:

AddDefaultCharset UTF-8 

и мой файл PHP Я выбега:

header("Content-type: text/html; charset=utf-8"); 

Так что теперь я задаюсь вопросом: если исходная строка была utf-8, почему бы ей не равняться самой кодировке utf8? и почему кодировка utf8 возвращает неверные символы? Что-то не так в конфигурациях wampserver?

Answer 1

Измените его на VISCII.

Input: ô 
Output: ô 

Вы можете проверить его на Charset converter.

Answer 2

ô является «Mojibake» для ô. То есть у вас do есть UTF-8, но что-то в коде исказило его.

См. Trouble with utf8 characters; what I see is not what I stored и найдите Mojibake. Он говорит, чтобы проверить их:

• Байт для хранения должен быть кодирован в формате UTF-8. Почини это.
• Соединение, когда в тексте INSERTING и SELECT необходимо указать utf8 или utf8mb4. Почини это.
• Столбец должен быть объявлен CHARACTER SET utf8 (или utf8mb4). Почини это.
• HTML должен начинаться с <meta charset=UTF-8>.

Возможно восстановить данные в базе данных, но это зависит от деталей, которые еще не предоставлены.

http://mysql.rjweb.org/doc.php/charcoll#fixes_for_various_cases

Каждый вьетнамский характер принимают 2-3 байт для кодирования в UTF-8. Неясно, является ли «жесткий 50» действительно символом лимит или байт предел.

Если вам посчастливилось иметь родственную «двойное кодирование» кракозябры, а затем вьетнамский персонаж будет принимать 4-6 байт и чувствовать себя как 2-3 символов. См. «Проверка данных» в первой ссылке.

Пример того, как «отменить» Mobibake в MySQL: CONVERT(BINARY(CONVERT('VậTCôNG' USING latin1)) USING utf8mb4) ->'VậTCôNG'

«Двойное кодирование» вроде как кракозябры дважды. То есть одна сторона рассматривает его как latin1, а другая как UTF-8, но дважды.

VậTCôNG, как UTF-8, является шестнадцатеричным 56e1baad5443c3b44e47. Если этот hex обрабатывается как набор символов cp850 или keybcs2, строка VậTCôNG.