【问题标题】:HTML posted form data gets written as jibberish into MySQL databaseHTML 表单数据以乱码形式写入 MySQL 数据库
【发布时间】:2019-09-30 16:56:17
【问题描述】:

当我尝试用希腊字母在文本字段中输入数据时,我的 wsgi 脚本将该数据保存为 MySQL 数据库中的乱码,我不知道为什么。 下面是即将通过form方法发布数据时的相关代码:

pdata = pdata + '''
<form methods="POST" enctype="multipart/form-data" action="%s">
    <tr>
            <td> <center>   <input type="text"  name="task"     size=50>    </td>
            <td> <center>   <input type="text"  name="price"    size=5>     </td>
            <td> <center>   <input type="text"  name="lastvisit">           </td>
        </table><br><br>
        <td>    <input type="image" src="/static/img/submit.gif" name="update" value="Ενημέρωση!">  </td>
    </tr>
</form>
''' % app.get_url( '/update/<name>', name=name )


pdata = pdata + "<meta http-equiv='REFRESH' content='200;%s'>" % app.get_url( '/' )
return pdata

这里是相关的回调函数,它试图将发布的表单数据输入 MySQL 数据库。

@app.route( '/update/<name>' )

def update( name ):

pdata = ''

task = request.query.get('task')
price = request.query.get('price')
lastvisit = request.query.get('lastvisit')


# check if date entered as intented, format it properly for MySQL
lastvisit = datetime.strptime(lastvisit, '%d %m %Y').strftime('%Y-%m-%d')


if( ( task and len(task) <= 200 ) and ( price and price.isdigit() and len(price) <= 3 ) and lastvisit != "error" ):
    # find the requested client based on its name
    cur.execute('''SELECT ID FROM clients WHERE name = %s''', name )
    clientID = cur.fetchone()[0]

    try:
        # found the client, save primary key and use it to issue hits & money UPDATE
        cur.execute('''UPDATE clients SET hits = hits + 1, money = money + %s WHERE ID = %s''', ( int(price), clientID ))

        # update client profile by adding a new record
        cur.execute('''INSERT INTO jobs (clientID, task, price, lastvisit) VALUES (%s, %s, %s, %s)''', ( clientID, task, price, lastvisit ))
    except:
        cur.rollback()

我无法理解为什么将数据作为乱码而不是正确的 utf-8 存储到数据库中。也尝试使用 utf-8 编码类型也不起作用。

<form methods="POST" enctype="utf-8" action="%s">

【问题讨论】:

  • 愚蠢的问题,但是数据库中的列是否以接受 UTF-8 的方式设置?这也可能是后端问题
  • 是的 MySQL 表和列配置为 utf8_general_ci。
  • 你能展示一个python中数据的例子,以及MySQL中产生的损坏数据吗? repr 两者都很好。
  • 听起来 MySQL 配置不正确。您可以通过在此处粘贴文本、接受默认值并查看输出来查看您的文本是如何被错误编码的:string-functions.com/encodedecode.aspx 您还可以从这些其他答案中收集一些信息:stackoverflow.com/questions/6202726/…stackoverflow.com/questions/4404768/…
  • 如果您使用文档中建议的点表示法,数据是否正确保存?例如request.query.task 而不是request.query.get('task')

标签: python html bottle


【解决方案1】:

要发布的 html 表单数据是“αυτή είναι μια δοκιμή”,数据库中的最终结果是“αυτή είναιμια δοκιμή”,数据库中的最终结果是“αυτή είναιμια δοκιμή”,最终结果是“αυτή είναιμια δοκιμή”,数据库中的最终结果是“αυτή είναιμια δοκιμή ”

但是,“αυτή είναι μια δοκιμή”显然是无效的 UTF-8,因为 第 38 位的字节 (ή) 表示它是一个两字节的 UTF-8 字符,但后面只有一个字节 (reference)。

如果这正是传递给代码的数据;那么您需要检查并确认 HTML 表单以正确的 UTF-8 格式提交数据。

<form accept-charset='UTF-8'>

假设您的输入字符串是正确的 UTF-8 编码,那么您的输出字符串 "αÏÏή είναι μια δοκιμή" 是 UTF-7 或更可能ISO-8859-1 编码 (reference)。

因此问题可能是传输机制(如上定义;在 HTML 表单提交中)或数据库存储编码。

是的,MySQL 表和列配置为utf8_general_ci

这也可能是个问题。 MySQL utf8_NOT 完整的 UTF-8 (wat?!),因为它是 3 字节而不是 4 字节;因此,如果您存储了一个 4 字节的 UTF-8 字符,它将偏移 所有后面的字符字节,并使它们看起来像垃圾。

解决方案:

将您的 MySQL 列和所有排序规则更新为 utf8mb4_unicode_ci

同时检查以确保您的 MySQL 传输机制也在使用 utf8mb4_

Read This

【讨论】:

    【解决方案2】:

    根据 wsgi_mod 文档,WSGIDaemonProcess 默认编码是 ASCII。 ASCII 中不包含希腊字符,并且您的输入未正确解码。如果要允许使用希腊字符,则必须使用 UTF-8 或 iso-8859-1。通常服务器是由 init 系统启动的守护进程,并且 99% 的时间仍然使用 ASCII 作为默认编码。在开发或调试时,您通常不会遇到这些问题,因为 python 脚本会继承当前用户的环境,该环境通常使用 UTF-8。

    $env
    .....
    LANG=en_GB.UTF-8
    .....
    

    从 wsgi_mod 中引用 apache:

    语言=语言环境 设置当前语言区域。这与设置 LANG 环境变量相同。 您需要在许多 Linux 系统上设置此项,其中 Apache 从系统初始化脚本启动时使用默认 C 语言环境,这意味着默认系统编码是 ASCII。除非您需要特殊的语言区域设置,否则将其设置为 en_US.UTF-8。 lang 或 locale 选项是否最有效取决于所使用的系统。如果您不确定哪个合适,请同时设置。

    语言环境=语言环境 设置当前语言区域。这与设置 LC_ALL 环境变量相同。 您需要在许多 Linux 系统上设置此项,其中 Apache 从系统初始化脚本启动时使用默认 C 语言环境,这意味着默认系统编码是 ASCII。除非您需要特殊的语言区域设置,否则将其设置为 en_US.UTF-8。 lang 或 locale 选项是否最有效取决于所使用的系统。如果您不确定哪个合适,请同时设置。

    【讨论】:

    • UF-8 &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; iso-8859-1
    猜你喜欢
    • 2019-01-12
    • 2014-05-15
    • 2014-06-21
    • 2011-12-04
    • 2013-07-10
    • 1970-01-01
    • 2021-02-07
    • 2014-04-30
    • 1970-01-01
    相关资源
    最近更新 更多