JSON specialchars JSON php 5.2.13 - PullRequest
Новая
       3

JSON specialchars JSON php 5.2.13

1 голос
/ 13 июля 2010

Я схожу с ума от этих проб кодирования ...

Я использую json_decode и json_encode для хранения и извлечения данных.Я выяснил, что json всегда нужен utf-8.Нет проблем там.Я даю json 'hellö' в utf-8, в моей БД это выглядит как hellu00f6.Хорошо, кодовая точка.Но когда я использую json_decode, он не декодирует код обратно, поэтому у меня все еще есть hellu00f6.Кроме того, в php 5.2.13 кажется, что в JSON до сих пор нет дополнительных тегов.Как я могу преобразовать символы кодовой точки обратно в правильный специальный символ для отображения в браузере?

Greetz и спасибо

Maenny

Ответы [ 2 ]

1 голос
/ 13 июля 2010

Это может быть из-за обратной косой черты, предшествующей кодовой точке в строке Unicode JSON: ö представляется \u00f6.При хранении в вашей БД СУБД не знает, как интерпретировать \u00f6, поэтому я предполагаю, что она читает (и сохраняет) ее как u00f6.

Используете ли вы экранирующую функцию?

Попробуйте добавить обратную косую черту в символы, экранированные юникодом: 

$json = str_replace("\\u", "\\\\u", $json);
0 голосов
/ 13 июля 2010

Предыдущий пост уже объясняет, почему ваш пример не сработал, как ожидалось.Тем не менее, при работе с базами данных есть несколько хороших методов кодирования, которые важны для повышения безопасности вашего приложения (т. Е. Предотвращения SQL-инъекций).

В следующем примере приведены некоторые из этих практик и предполагается, чтоPHP 5.2 и MySQL 5.1.(Обратите внимание, что все файлы и записи базы данных хранятся в кодировке UTF-8.)

База данных, используемая в этом примере, называется test, и таблица была создана следующим образом: 

CREATE TABLE `test`.`entries` (
`id` INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY ,
`data` VARCHAR( 100 ) NOT NULL
) ENGINE = InnoDB CHARACTER SET utf8 COLLATE utf8_bin

(Обратите внимание, что кодировка установлена ​​на utf8_bin.)

Это следует за php-кодом, который используется для добавления новых записей и создания JSON: 

<?
$conn = new PDO('mysql:host=localhost;dbname=test','root','xxx');
$conn->exec("SET NAMES 'utf8'"); // Enable UTF-8 charset for db-communication ..

if(isset($_GET['add_entry'])) {
    header('Content-Type: text/plain; charset=UTF-8');
    // Add new DB-Entry:
    $data = $conn->quote($_GET['add_entry']);
    if($conn->exec('INSERT INTO `entries` (`data`) VALUES ('.$data.')')) {
        $id = $conn->lastInsertId();
        echo 'Created entry '.$id.': '.$_GET['add_entry'];
    } else {
        $info = $conn->errorInfo();
        echo 'Unable to create entry: '. $info[2];
    }
} else {
    header('Content-Type: text/json; charset=UTF-8');
    // Output DB-Entries as JSON:
    $entries = array();
    if($res = $conn->query('SELECT * FROM `entries`')) {
        $res->setFetchMode(PDO::FETCH_ASSOC);
        foreach($res as $row) {
            $entries[] = $row;
        }
    }
    echo json_encode($entries);
}
?>

Примечаниеиспользование метода $conn->quote(..) перед передачей данных в базу данных.Как упомянуто в предыдущем посте, было бы даже лучше использовать подготовленные заявления, поскольку они уже полностью избегают.Таким образом, было бы лучше, если бы мы написали: 

$prepStmt = $conn->prepare('INSERT INTO `entries` (`data`) VALUES (:data)');
if($prepStmt->execute(array('data'=>$_GET['add_entry']))) {...}

вместо 

$data = $conn->quote($_GET['add_entry']);
if($conn->exec('INSERT INTO `entries` (`data`) VALUES ('.$data.')')) {...}

Вывод: использование UTF-8 для всех символьных данных, хранящихся или передаваемых пользователю, является разумным.Это облегчает разработку интернационализированных веб-приложений.Чтобы убедиться, что пользовательский ввод правильно отправляется в базу данных, рекомендуется использовать функцию escape.В противном случае использование подготовленных операторов делает жизнь и разработку еще проще, а также повышает безопасность приложений, поскольку предотвращается SQL-инъекция.

...