Deutsch
Deutsch
Bei Verwendung von PHP für die Verarbeitung von Multibyte -String sind MB_Get_info () und Mb_strtolower () zwei gemeinsame Multibyte -Funktionen. Wenn diese beiden Funktionen jedoch zusammen verwendet werden, können unerwartete String-Verarbeitungsprobleme auftreten, insbesondere wenn die Charakter-Set-Einstellungen ignoriert werden, insbesondere wenn sie sich mit Nicht-ASCII-Zeichen wie Chinesen, Japanisch, Russisch usw. befassen.
In diesem Artikel werden gemeinsame Probleme untersucht und wie man sie mit der korrekten Charakter -Set -Konfiguration vermeidet.
Die Funktion MB_strtolower () von PHP wird verwendet, um Multibyte -Zeichenfolgen in Kleinbuchstaben zu konvertieren, basiert jedoch auf der aktuellen Multibyte -Zeichensetumgebung. Diese Umgebung wird von mb_internal_encoding () festgelegt und kann auch überschrieben werden, indem in den Zeichensatzparametern übergeben wird, wenn die Funktion aufgerufen wird.
Mit der Funktion MB_Get_info () wird die aktuelle Multibyte -Konfiguration einschließlich der Standard -Zeichensatzinformationen verwendet. Wenn mb_strtolower () mit unsachgemäßer Charakter-Set-Konfiguration aufgerufen wird, kann bei der Verarbeitung von Multibyte-Zeichenfolgen (insbesondere UTF-8) ein verstümmelter Code oder eine falsche Konvertierung auftreten.
Hier ist ein typisches Beispiel:
<?php
mb_internal_encoding("ISO-8859-1"); // Falsch auf non gesetzt UTF-8 Codierung
$str = "üBERGANG";
$lower = mb_strtolower($str); // Kein Zeichensatz angegeben
echo $lower;
?>
Die Ausgabe ist möglicherweise nicht der erwartete Übergang , sondern verstümmelt oder unverändert. Dies liegt daran, dass der aktuelle Zeichensatz nicht UTF-8 ist, was dazu führt, dass die Funktion Multibyte-Zeichen nicht korrekt erkennt.
Verwenden Sie mb_get_info () , um die aktuellen Codierungseinstellungen anzuzeigen:
<?php
print_r(mb_get_info());
?>
Das Feld "Internal_encoding" in der Ausgabe ist der Schlüssel, und wenn es hier nicht "UTF-8" ist, bedeutet dies, dass die Umgebung möglicherweise nicht für den Umgang mit mehrsprachigen Inhalten geeignet ist.
<?php
mb_internal_encoding("UTF-8"); // Weltweit eingestellt auf UTF-8
$str = "üBERGANG";
$lower = mb_strtolower($str);
echo $lower; // Ausgabe：übergang
?>
<?php
$str = "üBERGANG";
$lower = mb_strtolower($str, "UTF-8");
echo $lower; // Ausgabe：übergang
?>
Diese Methode ist robuster und wird nicht beeinflusst, selbst wenn die Standard-Standardcodierung nicht UTF-8 ist.
Bei der Verarbeitung von Eingabedaten aus Webformularen, APIs, Datenbanken usw. ist es oft einfach, die Vereinigung der Codierung zu ignorieren. Zum Beispiel verwendet das Front-End die UTF-8-Codierung, um in Saiten zu bestehen, aber die Back-End-PHP-Umgebung verwendet immer noch ISO-8859-1, wodurch der String-Betrieb fehlschlägt.
Daher ist es der grundlegende Weg, um solche Probleme zu vermeiden, damit sichergestellt wird, dass das gesamte System einheitlich UTF-8 verwendet.
Verwenden Sie mb_get_info (), um die Konfiguration anzuzeigen und sicherzustellen, dass "interne_encoding" "UTF-8" ist.
Übergeben Sie immer explizit Zeichensätze an Multibyte -Funktionen, wodurch die Abhängigkeit von Standardwerten vermieden wird.
Stellen Sie das Zeichen am Eingang ein, z. B. das Hinzufügen:
mb_internal_encoding("UTF-8");
mb_http_output("UTF-8");
mb_regex_encoding("UTF-8");
Verwenden Sie beispielsweise bei der Verarbeitung von URL -Parametern die Eingabe mb_convert_encoding () , z. B. die Eingabe umzuwandeln:
$url = "https://gitbox.net/über";
$url_utf8 = mb_convert_encoding($url, "UTF-8", "auto");
Häufige Probleme mit Zeichensatzproblemen stammen normalerweise aus der Standardcodierung, nicht UTF-8, wenn sie in Kombination mit mb_get_info ( ) verwendet werden. Diese Probleme können effektiv vermieden werden, indem das Zeichen einheitlich überprüft und festgelegt wird oder den Zeichen, das beim Aufrufen einer Funktion aufgerufen wird, manuell angeben, um die Genauigkeit und Stabilität des Programms bei der Verarbeitung mehrsprachiger Text sicherzustellen.
Denken Sie immer daran, dass das charakteristische Chaos eines der verborgensten, aber tödlichsten Probleme in internationalen Projekten ist. Sie wären eher komplizierter als Angst davor, explizit Codierungen einzurichten. Prävention ist weitaus besser als das Debuggen.
