循序渐进Oracle：数据库的字符集和字符集文件

导读：本文来自『墨天轮』专栏“循序渐进Oralcle”（https://www.modb.pro/topic/6289，复制到浏览器中打开或者点击“阅读原文”），介绍《循序渐进Oracle》第三章的3.1-3.4节：字符集的基本知识、数据库的字符集、字符集文件及字符支持、NLS_LANG的设置与影响、导入导出及字符转换。

Oracle全球支持(即Globalization Support)允许我们使用本地语言和格式来存储和检索数据。通过全球支持，Oracle可以支持多种语言及字符集，得以展示数据库的强大魅力。这篇介绍第三章的3.1-3.4： 字符集的基本知识、数据库的字符集、字符集文件及字符支持、NLS_LANG的设置与影响、导入导出及字符转换。

在创建数据库的过程中，如图3-1所示的界面用于选择字符集。

图3-1  选择字符集

由于不同语言及字符集的共同存储存在设置上具有一定的复杂性，字符集一度成为普遍困扰大家的一个主要问题。

本章就字符集一些常见问题进行讨论，并对字符集转化等本质内容进行探索。

3.1  字符集的基本知识

如果从头说起，字符集最早的编码方案来自于与ASCII，这也是最常见的编码方式。该方案起源于20世纪60年代初期，最初是美国国会图书馆制定用来作为美国图书馆界书目交换的共同标准，最后完善成为美国的国家标准ASCII（American Standard Code for Information Interchange），之后进一步演变成世界性的计算机字符编码标准ISO646（其全名为7-bit coded character set for information interchange），于是成为计算机编码方案的基础。

ASCII第一次作为规范标准是在1967年发表，最后一次更新则是在1986年，至今为止共定义了128个字符，其中33个字符无法显示，这33个字符多数是陈废的控制字符，控制字符的用途主要是用来操控已经处理过的文字，在33个字符之外的是95个可显示的字符，包含用键盘敲下空白键所产生的空白字符也算1个可显示字符（显示为空白）。

Oracle数据库最早支持的编码方案也就是US7ASCII。

由于英文字符一般是以一个字节来存储的，7位的编码方案最多只能代表128个字符；经过扩展的8位编码方案也只能代表256个字符，这远远不能满足计算机发展的需要，对于亚洲国家复杂的字符存储需要更多的码位，于是各种编码方案随之而生。

为了容纳全世界各种语言的所有字符和符号，解决不同编码之间的兼容和转换问题，1991年1月，十多家公司共同出资，组建Unicode协会，随后Unicode编码产生了。

Unicode协会的口号是：给每个字符提供了一个唯一的数字，不论是什么平台，不论是什么程序，不论什么语言。

最初Unicode编码使用2-Byte（16bit）来进行编码，但是最多只能容纳65536个字符，仍然不够使用，后来进行了扩充，也就是Unicode 3.1标准，增加了额外的补充字符定义，现在Unicode 5.2标准已经发布，具体可以参考Unicode官方站点（http://www.unicode.org ）。

Unicode编码方案主要有3个实施标准：UTF-8、USC-2和UTF-16。Oracle从7.2开始支持UTF-8编码，提供Unicode编码支持。

按照各种标准的含义，Oracle推荐，如果数据库需要存放不同语言的不同符号和字符，建议使用Unicode编码方案。诚然，Unicode方案可以表示更多的字符，但是由于多位的存储，需要额外的存储空间和网络传输，所以选择最适合的数据库字符集仍然需要慎重考虑。

3.2  数据库的字符集

字符集在创建数据库时指定，在创建后一般不能更改，所以在创建数据库时能否选择一个正确的字符集就显得尤为重要。

在创建数据库时，可以指定字符集（CHARACTER SET）和国家字符集（NATIONAL CHARACTER SET）。

字符集的主要作用如下:

    用于存储CHAR, VARCHAR2, CLOB, LONG等类型数据

    用来标示诸如表名、列名以及PL/SQL变量等

    用于存储SQL和PL/SQL代码等

国家字符集用以存储NCHAR、NVARCHAR2、NCLOB等类型数据。

这些设置在数据库创建时指定，回顾一下前面章节中曾引用的数据库创建脚本：

CREATE DATABASE "eygle"
MAXINSTANCES 8 MAXLOGHISTORY 1 MAXLOGFILES 16 MAXLOGMEMBERS 3 MAXDATAFILES 100
DATAFILE SIZE 300M AUTOEXTEND ON NEXT  10240K MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL
SYSAUX DATAFILE SIZE 120M AUTOEXTEND ON NEXT  10240K MAXSIZE UNLIMITED
SMALLFILE DEFAULT TEMPORARY TABLESPACE TEMP TEMPFILE SIZE 20M AUTOEXTEND ON NEXT  640K MAXSIZE UNLIMITED
SMALLFILE UNDO TABLESPACE "UNDOTBS1" DATAFILE SIZE 200M AUTOEXTEND ON NEXT  5120K MAXSIZE UNLIMITED
CHARACTER SET ZHS16GBK
NATIONAL CHARACTER SET AL16UTF16
……




以上用粗体显示的就是数据库的字符集和国家字符集设置。




在创建数据库的过程中，一定要注意选择字符集。对于简体中文平台，一般缺省的字符集是ZHS16GBK。一旦字符集选定了，数据库中能够存储的字符就受到了限制，所以选择字符集应该尽可能多地容纳所有将用到字符。




常见的中文字符集有：

ZHS16CGB231280 CGB2312-80 16-bit Simplified Chinese   MB, ASCII
   ZHS16GBK       GBK        16-bit Simplified Chinese MB, ASCII,   UDC

  

其中GB2312码是中华人民共和国国家汉字信息交换用编码，全称《信息交换用汉字编码字符集──基本集》，由国家标准总局发布，1981年5月1日实施，通行于中国内地。新加坡等地也使用此编码。

GBK编码是1995年12月颁布的指导性规范，GBK与国家标准GB 2312-80信息处理交换码所对应的、事实上的内码标准兼容；同时，在字汇一级支持ISO/IEC 10646-1和GB 13000-1 的全部中日韩（CJK）汉字（20902字），包含了更多的编码。

但是，ZHS16GBK并非是ZHS16CGB231280的严格超集（虽然后者的汉字在前者中都存在，但是同样的编码在不同两个字符集中可能表达不同的汉字），所以在做数据库字符转换时仍然需要特别注意。

Oracle的字符集命名通常遵循以下命名规则：

，

即<语言><比特位数><编码>，例如ZHS ·16·GBK。

但是需要说明的是，有些字符集命名违背了这个规范，Oracle 8/Oralce 8i中的UTF-8是第一个打破这个命名规范的字符集。

可以看到一类字符集以AL开头，如AL16UTF16，其中AL代表ALL，指适用于所有语言（All Languages），按照这个标准当年UTF-8本应被命名为AL24UTF8。

3.3  字符集文件及字符支持

Oracle的全球支持是通过Oracle NLS Runtime Library（NLSRTL）来实施的，NLS运行库通过独立的函数来完成运行时和语言相关的转换及控制。字符集相关的文件在数据库服务器上是单独存储的，这些文件的位置受环境变量参数ORA_NLS*参数的控制，在不同版本中，这个环境变量的参数并不相同，在Oracle 7.2中，这个环境变量是ORA_NLS；在Oracle 7.3中，这个环境变量值变更为ORA_NLS32；在Oracle 8/Oracle 8i/Oracle 9i的各个版本中，该环境变量为ORA_NLS33；在Oracle 10g中，该环境变量参数又变更为ORA_NLS10。通常缺省地，可以不设置这个变量。

在Oracle 9i中，这个参数指向的字符文件缺省位置为$ORACLE_HOME/ocommon/nls/ admin/data。在Oracle 10g/11g中，这个参数指向的字符文件缺省位置为$ORACLE_HOME/ nls/data。

该目录下存放3类文件分别用来定义语言（NLS_LANGUAGE）、区域（NLS_TERRITORY）和字符集（NLS_CHARACTERSET），其中中文语言的文件为lx00023.nlb，如图3-2所示。

图3-2  选择语言文件

用Oracle提供的Locale Builder工具打开该文件，就可以看到在中文语言环境下的相关设置，如月份、星期等，如图3-3所示。

图3-3  月份和星期格式

当然最终要得文件是字符集文件，用Locale Builder工具打开相关的字符集文件（ZHS16GBK字符集文件为lx20354.nlb），如图3-4所示，就可以看到和字符集相关的设置信息。

图3-4  打开字符集文件

通过字符集文件，Oracle将所有汉字编码存放在数据库之中，这样当存放和转换汉字时才有了依据，我们看一下字符编码，如图3-5所示。

图3-5  字符编码

在上图中可以看到，汉字“盖”的编码为0xb8c7，这也就是Oracle在数据库中存放汉字时的编码，有了这个编码方案，Oracle才能知道在一个字符集中，字符0xb8c7真正代表什么：

SQL> select dump('盖') from dual;
DUMP('盖')
---------------------
Typ=96 Len=2: 184,199
 
SQL> select concat(to_char(184,'xx'),to_char(199,'xx')) from dual;
CONCAT
------
 b8 c7




这个过程完全可逆，在同样字符集的数据库中，可以进行如下转换：

SQL> select to_number('b8c7','xxxxxx') from dual;
TO_NUMBER('B8C7','XXXXXX')
--------------------------
                     47303
SQL> select chr(47303) from dual;
CH
--
盖

通过以上介绍可以知道这些字符文件非常重要，如果这个字符文件丢失或损坏，则数据库将会出现故障。在Windows上做一个简单的测试：

C:\oracle\10.2.0\nls\data>dir lx20354.nlb
 2006-10-10  14:52           477,772 lx20354.nlb
C:\oracle\10.2.0\nls\data>move lx20354.nlb lx20354.nlb.b
C:\oracle\10.2.0\nls\data>net start oracleserviceeygle
OracleServiceEYGLE 服务正在启动 ...
OracleServiceEYGLE 服务已经启动成功。
 
C:\oracle\10.2.0\nls\data>sqlplus "/ as sysdba"
Error 5 initializing SQL*Plus
NLS initialization error




以上测试显示，当字符集文件被移除之后，由于不能正常读取字符集文件，SQL*Plus已经不能正常登录，此时可以修改NLS_LANG参数设置其他字符集，使得SQL*Plus可以完成初始化：

C:\oracle\10.2.0\nls\data>set nls_lang=AMERICAN_AMERICA.US7ASCII
C:\oracle\10.2.0\nls\data>sqlplus "/ as sysdba"
 
SQL*Plus: Release 10.2.0.3.0 - Production on Mon Jun 18 17:10:46 2007
Copyright (c) 1982, 2006, Oracle.  All Rights Reserved.
 
ERROR:
ORA-03113: end-of-file on communication channel

此时SQL*Plus可以执行，但是无法登录数据库，这是因为SQL*Plus执行时就需要调用字符集文件，在Linux系统下，可以通过系统命令strace跟踪到这些调用行为。

以下命令通过strace命令将SQL*Plus的调用过程跟踪写入sqlplus.log文件：

[oracle@wapdb ~]$ strace -o sqlplus.log sqlplus /nolog
SQL*Plus: Release 11.1.0.6.0 - Production on Mon Sep 27 10:23:52 2010
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
SQL> exit




过滤一下跟踪文件，可以得到SQL*Plus启动依次调用的字符文件：

[oracle@wapdb ~]$ grep nls sqlplus.log
open("/opt/oracle/product/11.1.0/nls/data/lx1boot.nlb", O_RDONLY) = 3
open("/opt/oracle/product/11.1.0/nls/data/lx00001.nlb", O_RDONLY) = 3
open("/opt/oracle/product/11.1.0/nls/data/lx20354.nlb", O_RDONLY) = 3
open("/opt/oracle/product/11.1.0/nls/data/lx10035.nlb", O_RDONLY) = 3
open("/opt/oracle/product/11.1.0/nls/data/lx20001.nlb", O_RDONLY) = 3
open("/opt/oracle/product/11.1.0/nls/data/lx40001.nlb", O_RDONLY) = 3
open("/opt/oracle/product/11.1.0/nls/data/lx10001.nlb", O_RDONLY) = 8

注意以上调用中lx1boot.nlb是字符集的初始化文件，而lx20354.nlb正是SQL*Plus软件启动时需要调用的ZHS16GBK字符集文件。如果没有了字符集文件，应用软件（包括SQL*Plus和Oracle执行软件）都是无法完成初始化的。

3.4  NLS_LANG的设置与影响

导入导出（IMP/EXP）是一个常用的数据迁移及转化工具，因其导出文件具有平台无关性，所以在跨平台迁移中，最为常用；进一步的，从Oracle10g开始，数据泵（IMPDP/EXPDP）作为新一代高效数据导入导出工具被引入进来。

在使用EXP工具进行导出操作时，非常重要的是客户端的字符集设置，也就是客户端的NLS_LANG设置。

NLS_LANG参数由以下部分组成：

NLS_LANG=_.

其中LANGUAGE参数指定Oracle消息使用的语言，日期中月份和日的显示；TERRITORY参数指定货币和数字格式，地区和计算星期及日期的习惯；CHARACTERSET控制客户端应用程序使用的字符集，这个字符集用于对数据库传输过来的数据进行解码。

来看一个简单的测试，来了解一下这几个参数的作用及其对于数据显示的影响，在LANGUAGE设置为简体中文时，提示是中文输出：

E:\>set NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16GBK
E:\>sqlplus "/ as sysdba"
连接到:Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
 
SQL> select sysdate from dual;
SYSDATE
----------
01-11月-03
已选择 1 行。




当LANGUAGE设置为American时，提示信息等是英文输出：

E:\>set NLS_LANG=AMERICAN_AMERICA.ZHS16GBK
E:\>sqlplus "/ as sysdba"
Connected to:Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
 
SQL> select sysdate from dual;
SYSDATE
---------
01-NOV-03
1 row selected.

客户端的NLS_LANG设置不仅影响数据转储，还会影响到查询显示，是极其重要的参数。查看客户端NLS_LANG设置可以使用以下方法：

· Windows客户端的NLS_LANG设置受注册表参数影响，所以可从注册表中找到当前的参数设置，具体键值位于HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\下。

   对于不同的版本，其具体键值可能不同，如Oracle 10g的键值可能为KEY_OraDb10g，Oracle 11g的键值可能为KEY_OraDb11g_home1，其他客户端安装可能使用键值HOMExx\（xx指存在多个ORACLE_HOME时系统编号）。

通常需要设置这相应键值下的NLS_LANG和数据库字符集相同，以避免查询乱码等麻烦。

· 在UNIX环境下可以使用从环境变量中取得当前的NLS_LANG设置，例如：

[oracle@wapdb ~]$ env|grep NLS
NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16GBK




传统的导入和导出工具（IMP/EXP）是客户端软件，同SQL*PLUS和Oracle Forms一样，因此，使用EXP/IMP工具将同样按照NLS_LANG定义的方式调用字符集文件，并且在服务器和客户端之间根据设置进行字符集转换：

[oracle@wapdb ~]$ export NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16GBK
[oracle@wapdb ~]$ strace -o exp.log exp
 
Export:  Release  11.1 .0 .6 .0 - Production  on 星期一  9月  27  10: 39: 05  2010
Copyright (c)  1982,  2007, Oracle.   All rights reserved.
Username:
Password:
[ oracle@wapdb ~]$ grep nls exp.log
open( "/opt/oracle/product/11.1.0/nls/data/lx1boot.nlb", O_RDONLY) =  3
open( "/opt/oracle/product/11.1.0/nls/data/lx00023.nlb", O_RDONLY) =  3
open( "/opt/oracle/product/11.1.0/nls/data/lx20354.nlb", O_RDONLY) =  3
open( "/opt/oracle/product/11.1.0/nls/data/lx10035.nlb", O_RDONLY) =  3
open( "/opt/oracle/product/11.1.0/nls/data/lx20001.nlb", O_RDONLY) =  3
open( "/opt/oracle/product/11.1.0/nls/data/lx00001.nlb", O_RDONLY) =  3
open( "/opt/oracle/product/11.1.0/nls/data/lx10001.nlb", O_RDONLY) =  3
open( "/opt/oracle/product/11.1.0/nls/data/lx207d0.nlb", O_RDONLY) =  9

在执行导出数据操作时，导出使用的字符集将会记录在导出的DMP文件中，当文件导入时，将会检查导出时使用的字符集设置，如果这个字符集不同于导入客户端的NLS_LANG设置，字符集将根据导入客户端NLS_LANG设置进行转换，如果必要，在数据插入数据库之前还会进行进一步转换。

所以通常在执行导出操作时，最好把客户端字符集设置得和数据库相同，这样可以避免在导出时发生不必要的数据转换，导出文件将和数据库具有相同的字符集，数据得以完好备份。即使将来会把导出文件导入到不同字符集的数据库中，这样做也可以把转换延缓至导入时刻。

3.4  导入导出及字符转换

当进行数据导入时，主要存在以下两种情况。

· 源数据库和目标数据库具有相同字符集设置。

这时，只需要设置NLS_LANG等于数据库字符集即可导入（前提是，导出使用的是和源数据库相同字符集，即三者相同）

· 源数据库和目标数据库字符集不同。

如果导出时候使用的NLS_LANG是和源数据库相同的字符集，那么导入时就可以设置客户端NLS_LANG等于导出时使用的字符集，这样转换只发生在数据库端，而且只发生一次。

 

例如进行从WE8MSWIN1252到UTF8的转换，以下是一个常用的参考步骤：

（1）使用NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252导出数据库。这时创建的导出文件包含WE8MSWIN1252的数据。

（2）导入时使用NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252。这时转换仅发生在insert数据到UTF8的数据库中。

以上假设的转换只在目标数据库字符集是源数据库字符集的超集时才能转换。如果不同，一般就需要进行一些特殊的处理。

 

再来看一下执行导入时Oracle的一些判断和处理过程（以Oracle 8i为例）：

（1）首先确定导出数据库字符集环境。通过读取导出文件头，可以获得导出文件的字符集设置

（2）确定导入session的字符集，即导入Session使用的NLS_LANG环境变量。

（3）通过IMP读取导出文件。读取导出文件字符集ID，和导入进程的NLS_LANG进行比较。

（4）如果导出文件字符集和导入Session字符集相同，那么在这一步骤内就不需要转换，如果不同，就需要把数据转换为导入Session使用的字符集。然而这种转换只能在单byte字符集之间进行。

来看一个测试，首先设置导入session NLS_LANG为US7ASCII：

E:\nls2>set NLS_LANG=AMERICAN_AMERICA.US7ASCII




执行导入操作：

E:\nls2>e:\oracle\ora8i\bin\imp eygle/eygle file=Sus7ascii-Cus7ascii-exp817.dmp fromuser=eygle touser=eygle tables=test

这个导出文件是从US7ASCII数据库导出，导出客户端NLS_LANG也是US7ASCII：

Import: Release 8.1.7.1.1 - Production on Fri Nov 7 00:59:22 2003
(c) Copyright 2000 Oracle Corporation.  All rights reserved.
 
Connected to: Oracle8i Enterprise Edition Release 8.1.7.1.1 - Production
With the Partitioning option
JServer Release 8.1.7.1.1 - Production




这时导入，在DMP文件和NLS_LANG之间不需要进行字符集转换，但是由于导出文件字符集和数据库字符集（ZHS16GBK）不同，在数据导入Server时需要进行转换。

Export file created by EXPORT:V08.01.07 via conventional path
import done in US7ASCII character  set  and ZHS16GBK  NCHAR  character  set
import  server uses ZHS16GBK  character  set (possible  charset conversion)
export  server uses UTF8  NCHAR  character  set (possible ncharset conversion)
. . importing  table                          "TEST"           2  rows imported
Import  terminated successfully  without warnings.

（5）对于多Byte字符集的导入（如UTF8），需要设置导入Session字符集和导出字符集相同，否则就会遇到以下错误：IMP-16 "Required character set conversion (type %lu to %lu) not supported"。

E:\nls2>set NLS_LANG=AMERICAN_AMERICA.ZHS16GBK




导入Session字符集设置为ZHS16GBK，导入US7ASCII的导出文件：

E:\nls2>e:\oracle\ora8i\bin\imp eygle/eygle file=Sus7ascii-Cus7ascii-exp817.dmp fromuser=eygle touser=eygle
 
Import: Release 8.1.7.1.1 - Production on Fri Nov 7 00:38:55 2003
(c) Copyright 2000 Oracle Corporation.  All rights reserved.
 
Connected to: Oracle8i Enterprise Edition Release 8.1.7.1.1 - Production
With the Partitioning option
JServer Release 8.1.7.1.1 - Production
 
IMP-00016: required character set conversion (type 1 to 852) not supported
IMP-00000: Import terminated unsuccessfully

在从导出文件US7ASCII到导入NLS_LANG设置为ZHS16GBK的过程中，不支持单Byte字符集向多Byte转换，报出以上错误。

（6）导入Session字符集应该是导出字符集的超集，否则，专有的字符将难以正确转换。

（7）当数据转换为导入Session字符集设置以后，如果导入Session字符集仍然不同于目标数据库字符集，那么数据在插入数据库之前还需要进行最后一步转换，这要求目标数据库字符集是导入session字符集的超集，否则某些专有字符将不能正常转换。

继续看上面的两个过程，这里有这样两个原则：

      · 如果NLS_LANG的设置和数据库相同，那么数据（在传输过程中当然是二进制码）不经过转换就直接插入数据库中。

      · 如果NLS_LANG的设置和数据库不同，那么数据需要转换后才能插入数据库中。

 

再回头来看上面的第一个例子：

Export file created by EXPORT:V08.01.07 via conventional path
import done in US7ASCII character set and ZHS16GBK NCHAR character set
import server uses ZHS16GBK character set (possible charset conversion)
export server uses UTF8 NCHAR character set (possible ncharset conversion)
. . importing table                         "TEST"          2 rows imported
Import terminated successfully without warnings.




这时候经过第一步转换后的数据，US7ASCII到ZHS16GBK丢失首位，原样插入数据库，可以看到这时数据库中存放的就是错误的字符（在后面部分做了详细的转换）：

E:\nls2>sqlplus eygle/eygle
Connected to:Oracle8i Enterprise Edition Release 8.1.7.1.1 - Production
With the Partitioning option
JServer Release 8.1.7.1.1 - Production
 
SQL> select * from test;
NAME
--------------------
2bJT
test

对于Oracle 10g开始引入得数据泵（expdp/impdp）工具，不再存在以前EXP/IMP的字符集转换问题，expdp/impdp实际上是通过工具在数据库服务器上提交一个任务，真正的导出及导入操作都是在数据库服务器上完成的，这就简化了Oracle的数据转储工作。


原文：https://www.modb.pro/topic/6289（复制到浏览器中打开或者点击“阅读原文”）

出处：

扩展阅读

---

1. 
   

数据和云小程序『DBASK』在线问答，随时解惑  欢迎了解和关注。

在线问答

即时回复

数据和云

ID：OraNews

如有收获，请划至底部，点击“在看”，谢谢！

资源下载

关注公众号：数据和云（OraNews）回复关键字获取

help，30万+下载的完整菜单栏

2019DTCC，数据库大会PPT

2018DTCC , 数据库大会PPT

2018DTC，2018 DTC 大会 PPT

ENMOBK，《Oracle性能优化与诊断案例》

DBALIFE，“DBA 的一天”海报

DBA04，DBA 手记4 电子书

122ARCH，Oracle 12.2体系结构图

2018OOW，Oracle OpenWorld 资料

产品推荐

云和恩墨BethuneX 企业版，集监控、巡检、安全于一身，你的专属数据库实时监控和智能巡检平台，漂亮的不像实力派，你值得拥有！

云和恩墨zData一体机现已发布超融合版本和精简版，支持各种简化场景部署，零数据丢失备份一体机ZDBM也已发布，欢迎关注。

云和恩墨大讲堂 | 一个分享交流的地方

长按，识别二维码，加入万人交流社群

请备注：云和恩墨大讲堂