jQuery / Backbone是否破壞了我的UTF-8字符？

Question

我正在將網站的前端從舊的YUI2框架遷移到jQuery / BackBone。 PHP / mySQL后端未更改。 一切都很好，只不過通過Backbone save（通過$ .ajax）發送的UTF-8字符變得混亂了，我不知道為什么。

這是我所知道的：

1. 后端可以正常處理UTF-8。 作為此重建的一部分，它沒有更改。 我知道這是真的，因為當我更改配置以加載舊的YUI2前端時，UTF-8字符可以正常工作。 它們是使用YAHOO.util.Connect.asyncRequest使用escape(string)進行escape(string) ，並通過YAHOO.util.Connect.asyncRequest作為JSON在XMLHttpRequest傳遞，並且未轉義並以UTF-8 escape(string)保存在數據庫中，完全可讀且美觀。
2. 在新的前端中，我向所有頁面添加了<meta charset="UTF-8">和<meta http-equiv="content-type" content="text/html; charset=UTF-8">頭。 舊的前端沒有這些設置。 我只提到這是因為兩者有所不同。
3. 在新的前端中，將UTF-8字符另存為<form>提交時，它們可以正常工作。
4. 在新的前端中，請求Content-Type在控制台中看起來不錯。 Content-Type:application/x-www-form-urlencoded; charset=UTF-8

如何在新的前端傳遞數據？

• 有時通過常規Backbone model.save（），有時通過以下選項傳遞數據：

   var text = $('#input-' + targetId).val(); var atts = {}; atts['target_id'] = targetId; atts['user_id'] = userId; atts['text'] = text; var comment = new Comment(atts); comment.save( {}, { type: 'POST', url: '/api/comment?', data: atts, processData: true, success: function(comment, response){ //success handling }, error: function(model, response){ //error handling }, }, ); 

那么，這些殘缺不全的特殊字符是什么樣的呢？

• 在輸入中輸入：テクステクサンテクステクサン

• ：當我通過完全轉義 ，他們在表單數據部分控制台請求看起來很好text: テクス テクサン テクス テクサンクステクサン，但在數據庫中錯位ãã¯ã¹ ãã¯ãµã³ ãã¯ã¹ ãã¯ãµã³ 。 也許這是一個線索，我不知道。 通過AJAX傳遞時，我總是會轉義用戶輸入的文本。

• 當我escape(text) ，我在text:%u30C6%u30AF%u30B9%20%u30C6%u30AF%u30B5%u30F3%20%u30C6%u30AF%u30B9%20%u30C6%u30AF%u30B5%u30F3收到以下text:%u30C6%u30AF%u30B9%20%u30C6%u30AF%u30B5%u30F3%20%u30C6%u30AF%u30B9%20%u30C6%u30AF%u30B5%u30F3 テクス%20テクサン%20テクス%20テクサン 。

更好，但是與使用escape(text)的舊前端不同，它通過%u30C6%u30AF%u30B9%20%u30C6%u30AF%u30B5%u30F3%20%u30C6%u30AF%u30B9%20%u30C6%u30AF%u30B5%u30F3 ，在控制台中顯示為text: (unable to decode value)並保存為未轉義為テクステクサンテクステクサン的數據庫

• 當然，現在是2016年，我們都知道不應該使用escape() 。 我們應該改用encodeURIComponent() 。 因此，當我encodeURIComponent(text) ，這是控制台中顯示的內容： text: %E3%83%86%E3%82%AF%E3%82%B9%20%E3%83%86%E3%82%AF%E3%82%B5%E3%83%B3%20%E3%83%86%E3%82%AF%E3%82%B9%20%E3%83%86%E3%82%AF%E3%82%B5%E3%83%B3已保存為數據庫中的%E3%83%86%E3%82%AF%E3%82%B9%20%E3%83%86%E3%82%AF%E3%82%B5%E3%83%B3%20%E3%83%86%E3%82%AF%E3%82%B9%20%E3%83%86%E3%82%AF%E3%82%B5%E3%83%B3技術上講是decodeURIComponent ，並且在顯示此文本時我始終可以decodeURIComponent ，但這確實很痛苦，而且只是掩蓋了問題。

• 我還嘗試了unescape(encodeURIComponent(text)) ，結果如下： text:ãã¯ã¹ ãã¯ãµã³ ãã¯ã¹ ãã¯ãµã³控制台中的ãÂÂã¯ã¹ ãÂÂã¯ãµã³ ãÂÂã¯ã¹ ãÂÂã¯ãµã³在數據庫中的ãÂÂã¯ã¹ ãÂÂã¯ãµã³ ãÂÂã¯ã¹ ãÂÂã¯ãµã³ 。

似乎正在進行某種形式的雙重編碼，或者后端被構建為處理通過YUI2異步請求傳遞的特定格式。 我不知道。

關於下一步應該嘗試的任何想法？ 最佳做法是什么？

Answer 1

既然我已經睡了一個晚上，我已經意識到了一些事情，我想我已經找到了解決方案。

現在很清楚， 舊的前端未正確傳遞數據...這在發送請求時在控制台中顯示了text: (unable to decode value) 。 某種程度上，即使api或db存儲類中沒有解碼，PHP后端也能夠處理傳遞的文本。 這又是一個謎。

這是我為解決此問題所做的工作：

1. 從前端傳遞文本作為encodeURIComponent(text)
2. 使用$comment->set_text(urldecode(Request::get('text')));在PHP后端api中解碼文本$comment->set_text(urldecode(Request::get('text')));

文本以可讀的UTF-8字符形式轉義存儲在數據庫中，我不需要在讀取/顯示上做任何特殊的事情。 我將需要在后端的所有api端點上添加urldecode ，但這聽起來像是一種可靠的方法，所以我認為它已解決。

我想聽聽有關在前端使用encodeURIComponent並在后端使用urldecode想法。 這是解決問題的最佳方法嗎？