NodeJS
2018-04-27
sudo apt install -y nodejs npm
# 已经不需要这句了:
# sudo ln -s `which nodejs` /usr/bin/node
# node -v
# npm -v
npm config set registry=https://registry.npm.taobao.org
sudo npm upgrade -g npm
# sudo npm install -g yarn --registry=https://registry.npm.taobao.org
curl --compressed -o- -L https://yarnpkg.com/install.sh | bash
yarn config set registry https://registry.npm.taobao.org
配置
echo registry=https://registry.npm.taobao.org > ~/.npmrc
npm config get registry
https://registry.npmjs.org/
npm config set registry=https://registry.npm.taobao.org
yarn config get registry
https://registry.yarnpkg.com
yarn config set registry https://registry.npm.taobao.org
SMTP Email
2018-04-24
RFC#821 定义的 SMTP 协议非常简单(简陋)。
1993 年,RFC#1425 SMTP Service Extensions 定义了 SMTP 协议的拓展框架。
这个向前兼容的安全拓展框架是通过 EHLO 命令来实现。
Email
2018-04-16
注意:这边不是讨论 邮箱地址的格式。
格式
含义
- SMTP 会话(投递)
- Mail From 真实投递的发信人
- Rcpt To 真实投递的收信人
- 邮件内容(显示)
From
发信人
- 如果和 Mail From 地址不同,可能会显示:由 xxx 代发
To
收信人
Cc
抄送人
Bcc
密送人
Rely-To
回复地址
- 客户端点击回复的时候用的
- 如果没有这个字段,就会回复 From 地址
Sender
发信人
Return-Path
/ Reverse-Path
/ Envelope-From
- 作用是在邮件投递出现问题的时候,邮件服务将邮件退回这个地址
- 如果我们看到这几个名字
- 可能是发信人自己在邮件中声明
- 可能是收信方收到邮件之后添加的,单独字段,或放在 Received 头中
关于抄送和密送
碳式复写纸 carbon paper
副本,抄送 carbon copy => CC
密送 blind carbon copy => BCC
按照设计,密送地址不希望被其他收信人、抄送人察觉,只是密送地址才知道自己是密送。
CC, BCC in SMTP
SMTP 服务器不处理 CC、BCC,SMTP 客户端应该自行处理
TO 地址 + CC 地址 + BCC 地址一起放到 SMTP 会话的 RCPT TO 字段
所以,按照我的理解,邮件客户端:
在一次 SMTP 会话中,如果有 3 个 TO/CC 地址,2 个 BCC 地址,应该对那 3 个地址批量发送,然后对那 2 个 BCC 地址分别加上 BCC 头,分别发送。
更稳妥一点:如果是批量发送邮件,不要放 BCC 到邮件头!!!显示一个 密送:xxx
也没啥意义。
- PS:MSN(Outlook),网易邮箱发出去的邮件,不会加 BCC 头
甚至网易可能在显示邮件原文的时候会移除 BCC 头(给网易邮箱发的 BCC 头都不见了)
- PS:Gmail,QQ 邮箱发出去的邮件,密送人会看到 BCC 头
from_addr = "from@markjour.com"
to_addrs = ["to@markjour.com"]
cc_addrs = ["cc1@markjour.com", "cc2@markjour.com"]
bcc_addrs = ["bcc@markjour.com"]
msg = f"""
From: {from_addr}
To: {", ".join(to_addrs)}
Cc: {", ".join(cc_addrs)}
Hello World
""".strip()
send_to = to_addrs + cc_addrs + bcc_addrs
server = smtplib.SMTP('smtp.126.com')
server.set_debuglevel(1)
server.login(api_user, api_key)
server.sendmail(from_addr, send_to, msg)
server.quit()
Python
2018-04-13
import logging
import smtplib
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart
logging.basicConfig(level=logging.DEBUG)
SMTP_HOST = 'smtp.example.com'
SMTP_PORT = 587
SMTP_USERNAME = 'your_username'
SMTP_PASSWORD = 'your_password'
SMTP_STARTTLS = True
sender = 'sender@example.com'
recipients = ['rcpt01@example.com', '中国 <rcpt02@example.com>']
subject = 'Test Email'
content_text = 'This is a test email.'
content_html = '<html><h1>Hello</h1></html>'
def encode_recipient(name, addr):
pass
msg = MIMEMultipart()
msg['From'] = sender
msg['To'] = ', '.join(recipients)
msg['Subject'] = subject
msg.attach(MIMEText(content_text))
msg.attach(MIMEText(content_html))
print(msg.as_string())
def smtp_debug(self, *args):
msg = ' '.join(map(str, args))
logging.debug(msg)
smtp = smtplib.SMTP(SMTP_HOST, SMTP_PORT)
smtp._print_debug = smtp_debug
smtp.set_debuglevel(1)
smtp.ehlo()
if SMTP_STARTTLS:
smtp.starttls()
smtp.ehlo()
if SMTP_USERNAME and SMTP_USERNAME:
smtp.login(SMTP_USERNAME, SMTP_PASSWORD)
smtp.sendmail(sender, recipients, msg.as_string())
smtp.quit()
Email 时间
2018-04-10
比如:
Sun, 20 Jun 2018 00:47:04 -0700 (PDT)
Thu, 10 Jun 2021 16:10:03 -0700 (PDT)
Thu, 10 Jun 2021 08:06:31 -0700 (PDT)
定义
定义在 RFC 822 的 5. DATE AND TIME SPECIFICATION。
date-time = [ day "," ] date time ; dd mm yy hh:mm:ss zzz
day = "Mon" / "Tue" / "Wed" / "Thu" / "Fri" / "Sat" / "Sun"
date = 1*2DIGIT month 2DIGIT ; day month year e.g. 20 Jun 82
month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
time = hour zone ; ANSI and Military
hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT]
; 00:00:00 - 23:59:59
zone = "UT" / "GMT" ; Universal Time
; North American : UT
/ "EST" / "EDT" ; Eastern: - 5/ - 4
/ "CST" / "CDT" ; Central: - 6/ - 5
/ "MST" / "MDT" ; Mountain: - 7/ - 6
/ "PST" / "PDT" ; Pacific: - 8/ - 7
/ 1ALPHA ; Military: Z = UT;
; A:-1; (J not used)
; M:-12; N:+1; Y:+12
/ ( ("+" / "-") 4DIGIT ) ; Local differential
; hours+min. (HHMM)
总结就是:
[day-of-week,] day month year hour:minute[:second] timezone
- 周几和秒是可选的,据我观察,没有邮件省略这两部分
- 周几和月份采用三字母英文缩写(首字母大写)
- 年份是 2 位数字,后来的规范更新中建议采用 4 位数字。出于兼容性考虑,一般都保留了对 RFC 822 两位数字年份的支持。
- 时区除了数字之外,可以使用
UT
、GMT
、EST
、EDT
、CST
、CDT
、MST
、MDT
、PST
、PDT
,
还有 25 个字母(J 没有使用),Z 表示 UTC/GMT 时间,A - M 表示 -1 ~ -12 时区,N - Y 表示 1 到 12 时区。
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
9 |
10 |
11 |
12 |
West |
A |
B |
C |
D |
E |
F |
G |
H |
I |
K |
L |
M |
Eest |
N |
O |
P |
Q |
R |
S |
T |
U |
V |
W |
X |
Y |
Python
生成符合要求的时间字符串比较简单:
import time
time.strftime('%a, %d %b %Y %H:%M:%S %z')
# 'Tue, 10 Apr 2018 09:10:05 +0800'
但是由于这个灵活度比较大,解析起来最好借助专业的库(email.utils
)来做这个事。
import time
import datetime
import email.utils
import pytz
# 解析 ############################################
date_str = 'Sun, 20 Jun 2018 00:47:04 -0700 (PDT)'
email.utils.parsedate_to_datetime(date_str)
# datetime.datetime(2018, 6, 20, 0, 47, 4, tzinfo=datetime.timezone(datetime.timedelta(days=-1, seconds=61200)))
email.utils.parsedate_tz(date_str)
(2018, 6, 20, 0, 47, 4, 0, 1, -1, -25200)
# 生成 ############################################
# email.utils.formatdate(timeval=None, localtime=False, usegmt=False)
email.utils.formatdate()
# 'Tue, 10 Apr 2018 09:10:41 -0000'
# email.utils.format_datetime(dt, usegmt=False)
dt = datetime.datetime.now()
email.utils.format_datetime(dt)
# 'Tue, 10 Apr 2018 09:16:43 -0000'
tz = pytz.timezone('Asia/Shanghai') # <DstTzInfo 'Asia/Shanghai' LMT+8:06:00 STD>
dt = datetime.datetime(2018, 4, 10, 9, 10, 0, tzinfo=tz)
# datetime.datetime(2018, 4, 10, 9, 10, tzinfo=<DstTzInfo 'Asia/Shanghai' LMT+8:06:00 STD>)
email.utils.format_datetime(dt)
# 'Tue, 10 Apr 2018 09:10:00 +0806'
Email
2018-04-07
规范
规范定义比较复杂,甚至支持注释。
我简化一下(去掉注释,去掉双引号,去掉 [IPv4]
/ [IPv6]
/ 主机名
做域):
- 格式:
域内部分@域
-
域内部分:
-
长度不超过 64
- 大小写字母 + 数字(62)
-
ASCII 标点符号(19)
!#$%&'*+-/=?^_`{|}~
-
可以加入点号(.
)隔开,不放首尾,不连续出现
-
域名
-
每一级域名 1 - 63 个字符,总长度不超过 253
这个限制和 DNS 报文设计有关
国际化域名转换成 Punycode 之后也必须遵守这个约定
- 允许包含数字、字母(大小写不敏感)和短横线(
-
)
- 短横线不能出现在首尾位置
实践
实际上的邮件地址会更加简单:
- 长度限制
- QQ 邮箱 3 - 18
- 网易邮箱 6 - 18
- Gmail 6 - 30
- 新浪邮箱 4 - 16
- 字符限制:字母数字 +
.-_
- 一般大小写不敏感
- 连字符(
.-_
)不可连续出现
- 网易免费邮箱只支持下划线,网易 VIP 邮箱支持点和下划线
- Gmail 只支持点和加号
- 在实际投递中,点和加号会被忽略
- 点可以用作单词风格
- 加号通常用做来信归类,比如注册淘宝时
+taobao
,订阅开发者头条时 +toutiao
,相关邮件就方便搜索归类。
- 部分邮箱不支持全数字(别有用途,或是避免 QQ 号冲突,或是避免手机号冲突)
- 开头结尾字符限制:
- 字母数字开头 + 字母数字结尾
- 字母开头 / 字母数字结尾
正则表达式
以规范为准,参考真实场景下的实践:
域内部分:
/[a-z0-9]+([.-_#][a-z0-9]+)+/;
域名部分:
/[a-z0-9]+(-[a-z0-9]+)?(\.[a-z0-9]+(-[a-z0-9]+)?)+/;
汇总在一起就是:
/^[a-z0-9]+([.-_#][a-z0-9]+)+@[a-z0-9]+(-[a-z0-9]+)?(\.[a-z0-9]+(-[a-z0-9]+)?)+$/;
参考资料与拓展阅读
虚拟化 云计算 OpenStack 计算机网络 LinuxNetwork
2018-03-24
相关文章:
物理设备
- VLAN 虚拟局域网,设备层面上的网络分区,网络设备提供的功能
网络报文给 VLAN Tag 分配了四个字节,其中 3 个字节用于 VLAN ID,1 个字节用于 VLAN Priority。
作为 VLAN ID 的 12bit(0-4095)中,首位两数作为保留值,也就是说 VLAN 技术支持的最大网络数是 4094。
Linux 网络技术
在 Linux 内核的网络设备管理层,虚拟设备和物理设备是同等地位。
- network namespace 网络隔离,虚拟化的基础
- bridge 网桥,相当于交换机,二层数据交换
- veth 虚拟网口,成对出现,两个虚拟网口之间可以相互连接(可以跨 namespace)
- tap/tun
- tap TAP 设备,虚拟二层网络,处理 TCP/UDP 包,
有自己的 MAC 地址,可以桥接到物理网卡
- tun TUN 设备,虚拟三层网络,处理 IP 包
- iptables 网络管理
确切的说是以 iptables 为代表的一系列网络管理技术
KVM / Neutron
- qvb neutron 网络桥
- qvo neutron 网络虚拟接口
Neutron 网络模式:
- VLAN
- VXLAN 虚拟拓展局域网,在三层 UDP 协议中封装二层数据包,突破 VLAN 的限制
- GRE Gerneral Routing Encapsulation,通用路由封装协议
英语
2018-03-18
类别 |
英语名称 |
简写 |
说明 |
名词 |
noun |
n |
- |
动词 |
verb |
v |
- |
形容词 |
adjective |
adj |
- |
副词 |
adverb |
ad/adv |
- |
介词 |
preposition |
perp |
in on at |
连词 |
conjunction |
conj |
and or but if |
代词 |
pronoun |
pron |
I you he she |
数词 |
numeral |
num |
one two three |
冠词 |
article |
art |
the a an |
感叹词 |
interjection |
interj |
oh hey |
- 名词:
- 冠词:不定冠词,定冠词,零冠词;
- 数词:基数词,序数词;
Mermaid Markdown
2018-02-09
! mermaid.js
物理
2018-02-03
基础认知
- 速度单位:米每秒 $m/s$
- 加速度单位:米每平方秒 $m/s^2$
也等于牛顿每千克 $N/kg$
- 重力加速度就是天体重力产生的加速度,符号 $g$
有一个重力常数,符号是 $G$
- 地表附近的重力加速度约为 9.81
重力引起的标准加速度(或自由落体的标准加速度),有时缩写为标准重力,通常用 $ɡ_0$ 或 $ɡ_n$ 表示,是物体在地球表面附近真空中的标称重力加速度。
标准定义为 $9.80665 m/s^2$(约 $32.17405 ft/s^2$)。
该值由第三届国际度量衡大会确定,用于将物体的标准重量定义为其质量和标称加速度的乘积。
地球表面附近物体的加速度是由于重力和地球自转的离心加速度的综合作用(但后者足够小,在大多数情况下可以忽略不计);
两极的总重力(视重力)比赤道高约百分之二。
参见:标准重力
https://en.wikipedia.org/wiki/Standard_gravity
运动