1.7 文本编辑
理解纯文本、字符编码与换行符,掌握 VS Code 的安装、基础操作、常用编辑技巧与正则表达式
本节 AI 摘要
本节介绍纯文本、字符编码与换行符,并用 VS Code 演示文件编码恢复、多光标、查找替换、正则表达式、代码片段与配置同步;正则部分还涵盖常用元字符与捕获组,可用于批量匹配和替换结构化文本。编译器、工具链与 SSH 等环境配置参见 1.14 Windows 环境配置。
INFO
源代码、配置文件与 Markdown 文档等都以文本为主要载体。编辑这些文件之时,不只需要会输入内容,还应了解文件采用的字符编码和换行规则。
本节重点介绍 VS Code 的安装与常用功能;编译器、工具链和 SSH 配置详见 1.14 Windows 环境配置。
一、文件内容与文档格式
1.1 纯文本、富文本与版式文档
文件并不只分成“纯文本”和“富文本”两类。日常接触的文件,大体是下面三种形态:
| 类型 | 特点 | 典型文件 | 适合场景 |
|---|---|---|---|
| 纯文本 | 直接保存字符序列,不记录字体与页面布局 | .txt、.md、.py、.cpp | 代码、配置、笔记 |
| 富文本 | 同时保存文字与字体、颜色等格式 | .docx、.rtf | 报告、简历、协作文档 |
| 版式文档 | 重点保存页面呈现结果 | .pdf | 发布、打印、归档 |
二、字符编码
2.1 字符、编码与解码
字符编码定义字符与字节序列之间的映射。把字符转换为字节称为编码,把字节还原为字符称为解码,将文本从一种编码转换为另一种编码称为转码。
正确转码会先按源编码解码,再按目标编码重新编码。例如,把 GBK 文件转换为 UTF-8 时,必须先确认源文件确实是 GBK;直接把 GBK 字节当成 UTF-8 读取并不是转码,而是错误解码。
2.2 常见编码对比
| 编码 | 编码长度 | 支持范围 | 使用情况 |
|---|---|---|---|
| ASCII | 每个字符 1 字节,最高位为 0 | 128 个字符,包含英文字母、数字、标点和控制字符 | 仍广泛用作多种文本格式的兼容子集,不支持中文 |
| GB2312 | ASCII 范围字符 1 字节,汉字等字符通常 2 字节 | 以简体中文常用字符为主 | 旧式简体中文编码,字符范围小于 GBK |
| GBK | ASCII 范围字符 1 字节,汉字等字符通常 2 字节 | 扩展 GB2312,收录更多汉字与符号 | 常见于旧版 Windows 中文软件和历史文件 |
| UTF-8 | 每个 Unicode 标量值 1-4 字节 | Unicode | Web 与跨平台文本的主流编码,ASCII 字节保持不变 |
| UTF-16 | 每个 Unicode 标量值使用 1 或 2 个 16 位代码单元 | Unicode | 常见于 Windows API 和部分语言运行时接口;字节序需由协议、BOM 或编码名称确定 |
“字符数”不一定等于“字节数”
UTF-8 中,ASCII 字符占 1 字节,常用汉字通常占 3 字节,许多 emoji 对应的单个码点占 4 字节。UTF-16 中,常用汉字通常使用 1 个 16 位代码单元,许多 emoji 等增补字符需要一对代码单元。用户看到的一个字形还可能由多个 Unicode 码点组成,因此不能笼统地把“一个字符”固定为某个字节数。
2.3 乱码是如何产生的
同一串字节交给不同解码器,可能得到完全不同的文本,也可能因字节序列不合法而产生错误。下表中的箭头表示错误解码,不是正确转码;结果由解码器的错误处理策略决定,这里以常见的“使用 U+FFFD 替换无法解码的字节”为例。
| 原始文本与实际字节 | 错误解码方式 | 典型结果 |
|---|---|---|
你好 的 UTF-8 字节:E4 BD A0 E5 A5 BD | UTF-8 字节误按 GBK 解码 | 浣犲ソ |
中文 的 UTF-8 字节:E4 B8 AD E6 96 87 | UTF-8 字节误按 GBK 解码 | 涓�鏂� |
你好 的 GBK 字节:C4 E3 BA C3 | GBK 字节误按 UTF-8 解码 | ��� |
中文 的 GBK 字节:D6 D0 CE C4 | GBK 字节误按 UTF-8 解码 | ���� |
UTF-8 字节误按 GBK 解码时,有些字节组合恰好能映射为 GBK 字符,因此常出现 浣犲ソ 这类可读但无意义的汉字;不合法或无法配对的字节仍可能显示为 �。GBK 字节误按 UTF-8 解码时,许多字节序列不符合 UTF-8 规则,编辑器可能报错、拒绝打开,或显示一个或多个 �,不能把结果概括成固定数量的替换字符。
在 VS Code 中恢复编码错误
发现乱码后不要立即保存。点击状态栏中的编码名称,选择「通过编码重新打开」(Reopen with Encoding),依次尝试项目约定的编码或已知的源编码;内容正常后,再选择「通过编码保存」(Save with Encoding)转换为目标编码。
「重新打开」只改变当前字节的解释方式,不改写文件;「保存」会按所选编码重新生成字节。若乱码内容已经覆盖原文件,尤其是原始字节被替换为 � 后又保存,丢失的信息通常无法仅靠切换编码恢复,应从 Git、备份或原始数据源找回。
“锟斤拷”与“烫烫烫”
两个连续的替换字符 �� 以 UTF-8 保存时对应 EF BF BD EF BF BD;这 6 个字节再误按 GBK 解码,会得到“锟斤拷”。单个 � 的 3 字节并不能完整解码为这三个汉字。
“烫烫烫”来自另一条路径:Microsoft C/C++ 调试运行库会使用 0xCC 填充部分未初始化内存,而 GBK 中 CC CC 对应“烫”。它反映的是调试内存填充值被当作文本读取,不属于 UTF-8 与 GBK 互转。
2.4 编码约定与 BOM
BOM(Byte Order Mark,字节序标记)是写在文件开头的一组特殊字节,用于标记编码方式。UTF-16 的 BOM 用于区分字节序:以 FF FE 开头表示 UTF-16 LE,以 FE FF 开头表示 UTF-16 BE。UTF-8 不存在字节序问题,它的 BOM(EF BB BF)只作为编码签名,帮助工具识别文件是 UTF-8。
- 新项目优先采用 UTF-8;VS Code 默认使用不带 BOM 的 UTF-8
- 是否使用 BOM 取决于文件格式、协议和工具链要求;UTF-8 不存在字节序问题,BOM 在其中只作为编码签名
- 团队应通过项目文档、编辑器配置或工具链明确编码;
.editorconfig只有在仓库实际采用并被相关工具支持时才有效 - 旧式工具、课程评测系统或历史文件可能要求 GBK 等编码,不能未经确认直接批量转为 UTF-8
不要依赖编辑器猜测编码
无 BOM 的文本通常没有足够信息唯一确定编码,自动检测只能给出推测。新版 Windows 记事本和 VS Code 默认使用 UTF-8,但旧文件与旧工具仍可能采用本地代码页。提交作业或处理历史数据时,应以课程、项目或数据源的明确要求为准,并在目标工具中验证。
三、换行符
3.1 常见换行符
文本文件常见的行结束序列有两种:
| 换行符 | 名称 | 常见环境 |
|---|---|---|
\n | LF(Line Feed) | Linux、现代 macOS、许多跨平台项目 |
\r\n | CRLF(Carriage Return + Line Feed) | Windows 原生工具与部分 Windows 项目 |
换行符不一致不会造成字符乱码,但可能让 Git 将每一行都识别为已修改。Shell 脚本的 shebang(解释见 1.12 Shell 基础)或命令末尾若带有多余的 \r,在类 Unix 环境中还可能出现 bad interpreter、command not found 等错误。
3.2 跨平台协作的处理
项目可以在根目录使用 .gitattributes 明确换行规则。该文件随仓库提交,比每位成员各自配置更容易保持一致:
# 自动识别文本文件,并在 Git 索引中规范为 LF
* text=auto
# 签出到工作区时,Shell 脚本使用 LF,批处理文件使用 CRLF
*.sh text eol=lf
*.bat text eol=crlf
*.cmd text eol=crlfeol 控制文件签出到工作区时的行结束符;被识别为文本的文件在 Git 索引中会规范为 LF。仓库没有约定时,个人配置 core.autocrlf 才会参与决定转换行为。修改全局设置前可查看当前值:
# 未配置时可能没有输出
git config --global --get core.autocrlf规则变更不会自动改写所有已跟踪文件
新增或修改 .gitattributes 后,仓库维护者可在干净工作区使用 git add --renormalize . 检查需要规范化的文件,并把换行变更作为独立提交。不要在存在其他未提交修改时直接执行整仓库规范化。
四、VS Code:下载、安装与首次使用
本节只介绍 VS Code 的安装与基础使用;编译器等环境配置将在 1.14 Windows 环境配置 中介绍。
4.1 下载与安装
到 VS Code 官网下载页,根据 CPU 架构选择 x64 或 Arm64。System Installer 安装包进行下载。
如何判断 CPU 架构
按 Win + I 打开「设置」,进入「系统 → 系统信息」,查看「系统类型」:
显示「基于 x64 的处理器」时选择 x64,显示「基于 ARM 的处理器」时选择 Arm64。
也可以在命令提示符中执行 echo %PROCESSOR_ARCHITECTURE%。
AMD64 表示 x64,即使处理器来自 Intel 也会使用这一历史名称。
运行安装程序并阅读每一步的选项。推荐勾选 「将“通过Code打开”操作添加到Windows资源管理器文件上下文菜单」与 「将“通过Code打开”操作添加到Windows资源管理器目录上下文菜单」。
安装程序默认会将 code 命令加入 PATH;安装完成后需要重新打开终端,才能用 code . 打开当前文件夹。快捷方式和文件关联可按实际需要选择。
验证安装: 从开始菜单启动 VS Code;也可重新打开终端,执行 code --version 检查命令是否可用。
4.2 安装中文语言包
习惯英文界面的读者可以跳过本节。其余读者:
- 打开侧边栏的「扩展」面板(
Ctrl + Shift + X) - 搜索
Chinese (Simplified) (简体中文) Language Pack for Visual Studio Code - 点击「安装」,完成后点击
Change Language And Restart,VS Code 会自动重启并切换为简体中文
4.3 界面速览与常用入口
| 区域 | 作用 |
|---|---|
| 活动栏 | 最左侧图标列,切换资源管理器、搜索、源代码管理等 |
| 侧边栏 | 显示当前活动面板的内容,如文件树 |
| 编辑区 | 中间区域,打开的文件在这里编辑,支持多标签 |
| 面板 | 底部区域,集成终端、输出、调试等 |
| 状态栏 | 底部状态条,可查看编码、换行符、行号等信息 |
常用入口:
- 打开文件夹:
Ctrl + K,松开后再按Ctrl + O(「文件 → 打开文件夹」) - 集成终端:
Ctrl + `(「终端 → 新建终端」) - 命令面板:
Ctrl + Shift + P(详见下文)
扩展安装时的「信任发布者」弹窗
发布者名称或验证标记不能单独证明扩展安全。安装前应核对扩展标识、发布者、权限说明、隐私政策、更新记录和项目主页,只安装当前工作确实需要的扩展。组织管理的设备还应遵守组织的扩展白名单。
五、VS Code 进阶技巧
5.1 多光标编辑
多光标可以同时编辑多个位置。以下是 Windows 默认键位;快捷键可能被显卡驱动、系统工具或自定义键位覆盖:
| 操作 | 作用 |
|---|---|
Alt + 单击 | 在点击位置添加一个光标 |
Ctrl + Alt + ↑/↓ | 在上下行添加光标(列编辑) |
Ctrl + D | 选中下一个与当前选区相同的词 |
Ctrl + Shift + L | 选中所有与当前选区相同的词 |
Shift + Alt + 拖拽 | 矩形选区 |
例如,需要修改若干处相同文本时,可选中其中一处并按 Ctrl + D 逐个加入匹配项;遇到不应修改的位置,按 Ctrl + K,松开后按 Ctrl + D 跳过当前匹配。确认所有选区都正确后再输入替换内容。
不要用文本替换代替语义重构
把变量名、函数名或类型名改成新名称时,优先使用 F2 调用语言服务的重命名功能。多光标和查找替换只依据文本匹配,可能误改注释、字符串或同名但无关的符号。
5.2 查找与替换
| 快捷键 | 作用 |
|---|---|
Ctrl + F | 当前文件查找 |
Ctrl + H | 当前文件替换 |
Ctrl + Shift + F | 在已打开的文件夹或工作区中查找 |
Ctrl + Shift + H | 在已打开的文件夹或工作区中替换 |
点击查找框中的 .* 图标可启用正则表达式。例如,下列规则能匹配单行且参数中不含右括号的简单 console.log(...) 调用,并保留括号内的内容:
查找: console\.log\(([^\r\n()]*)\)
替换: console.debug($1)这不是通用的 JavaScript 代码转换规则:console.log(fn())、跨行参数、字符串中的右括号等情况都可能无法正确处理。
执行全项目替换前应先查看预览;涉及代码结构时应使用语言服务、AST 工具或逐项确认。
5.3 正则表达式
查找与替换的进阶玩法是正则表达式(Regular Expression),用符号描述匹配模式,一次就能匹配一整类文本,而不是逐字查找。VS Code 查找框右上角的 .* 图标即是开启正则的开关。
常用元字符:
| 写法 | 含义 | 示例 |
|---|---|---|
. | 任意单个字符(换行符除外) | a.c 匹配 abc、a2c |
\d | 任意一个数字 | \d\d 匹配两位数字 |
\w | 字母、数字或下划线 | \w+ 匹配一个单词 |
\s | 空白字符(空格、Tab、换行) | a\s+b 匹配 a 与 b 之间的空白 |
[abc] | 括号内任一字符 | [0-9] 匹配任意一位数字 |
{n} | 前面的元素重复 n 次 | \d{4} 匹配四位数字 |
* | 前面的元素重复 0 次或多次 | ab* 匹配 ab、abbb(也匹配 a) |
+ | 前面的元素重复 1 次或多次 | \d+ 匹配一个或多个数字 |
? | 前面的元素出现 0 次或 1 次 | colou?r 匹配 color、colour |
^ | 行首 | ^TODO 匹配行首的 TODO |
$ | 行尾 | TODO$ 匹配行尾的 TODO |
| | 或 | cat|dog 匹配 cat 或 dog |
( ... ) | 分组并保存捕获组 | (ab)+ 匹配 abab |
\ | 转义下一个字符 | \. 匹配字面的句号 . |
要点:
.、*、(、|、\等在正则中都有特殊含义;要匹配符号本身,需在前面加\转义(如\.、\()。( ... )会把匹配到的内容存成捕获组,替换时用$1、$2依次引用。例如把日期格式从2024-11-15改成2024/11/15:
查找: (\d{4})-(\d{2})-(\d{2})
替换: $1/$2/$3- 通配符不是正则。1.12 Shell 基础 中的
*.cpp用于匹配一整段文件名,而正则匹配任意文本片段,并可用\d+、(ab)+等描述更复杂的模式。 - 不同工具的正则语法并不完全相同:VS Code 使用 Rust 正则引擎,
.不匹配换行;grep默认使用“基础正则(BRE)”,其中+、(等要写成\+、\(才有特殊含义。用到某个工具前,先看它的语法说明。
正则不是万能的解析器
正则适合结构规整、单行的文本。遇到成对括号、HTML 标签或跨多行的内容时,正则很容易写成“看起来对、实际错”的模式,应改用语言解析器或专门的工具。
5.4 代码片段(Snippet)
经常重复输入的代码块可以做成代码片段,输入几个字母按 Tab 自动展开。在 VS Code 中:Ctrl + Shift + P → Configure User Snippets → 选择语言。
例如为 C++ 新建一个快速输出片段:
{
// 快速插入 cout 语句
"Print": {
"prefix": "cout",
"body": ["std::cout << ${1:内容} << std::endl;"],
"description": "快速插入 cout 语句"
}
}之后输入 cout 按 Tab,就会自动展开,并把光标停在 ${1:内容} 处等待输入。
关于代码片段扩展
VS Code 扩展市场提供许多预制代码片段,但扩展也会增加权限范围、维护成本和潜在冲突。 少量稳定模板适合直接写入用户或项目代码片段;只有现有片段较多且来源可信时,才有必要安装扩展。
5.5 命令面板
Ctrl + Shift + P 打开命令面板。它会列出当前环境中已注册的命令,适合按关键词查找设置入口和操作,不必记住每一层菜单。
INFO
本文列出的是 Windows 默认键位。安装键位映射扩展或修改 keybindings.json 后,实际快捷键可能不同。可在命令面板中运行「首选项:打开键盘快捷方式」查询和修改。
5.6 其他常用快捷键速览
以下操作可通过默认快捷键或命令面板调用:
| 快捷键 | 作用 |
|---|---|
Ctrl + P | 按文件名快速跳转文件 |
Alt + ↑ / Alt + ↓ | 上移 / 下移当前行 |
Shift + Alt + ↓ | 向下复制当前行 |
Ctrl + / | 切换行注释 |
Ctrl + B | 显示 / 隐藏侧边栏 |
Ctrl + ` | 显示 / 隐藏集成终端 |
F2 | 通过可用的语言服务重命名符号 |
Shift + Alt + F | 使用当前语言可用的格式化器格式化文档 |
Ctrl + K Z | 禅模式(全屏专注,连续按两次 Esc 退出) |
常用设置既可以只作用于当前用户,也可以随项目共享。
六、编辑器配置与同步
6.1 JSON 配置文件
VS Code 同时提供图形化设置界面和 JSON 配置文件。JSON 适合精确编辑、审查差异和共享工作区配置:
- 用户设置:
Ctrl + Shift + P→Preferences: Open User Settings (JSON) - 工作区设置:项目
.vscode/settings.json,只对当前项目生效
常用配置示例:
{
// 字体大小
"editor.fontSize": 14,
// 缩进位数
"editor.tabSize": 4,
// 保存时自动格式化
"editor.formatOnSave": true,
// 自动换行
"editor.wordWrap": "on",
// 延迟自动保存
"files.autoSave": "afterDelay",
// 终端字体大小
"terminal.integrated.fontSize": 13
}6.2 设置同步
登录 GitHub 或 Microsoft 账户后,可以按需开启 Settings Sync。 可同步的项目以当前版本界面为准,通常包括设置、快捷键、用户代码片段和扩展信息,并可分别启用或停用。 它不包含项目文件,不能替代 Git 或备份;WSL、SSH 和开发容器中的远程扩展也需要在对应目标环境中确认。
七、其他编辑器
本节使用 VS Code,我们也可使用其他的编辑器与 IDE。
7.1 编辑器 vs IDE
| 类型 | 特点 | 代表 |
|---|---|---|
| 通用编辑器 | 核心功能相对精简,可按语言和任务安装扩展 | VS Code、Sublime Text、Vim / Neovim |
| 集成开发环境(IDE) | 通常集成项目模型、语言分析、构建、调试、测试与重构能力 | Visual Studio、IntelliJ IDEA、CLion、PyCharm |
两类工具的边界并不绝对:VS Code 安装语言扩展后也能提供调试和重构能力,IDE 也可以精简界面与插件。选择标准应是项目支持、语言工具链、团队约定和资源占用,而不是工具类别本身。
7.2 推荐选择
| 场景 | 可考虑的工具 |
|---|---|
| 通用编辑、写算法与课程练习 | VS Code |
| Windows 原生 C++ / .NET | Visual Studio |
| 跨平台 C / C++ 工程 | VS Code、CLion |
| Python 开发 | VS Code、PyCharm |
| 交互式数据分析 | JupyterLab、VS Code 的 Jupyter 扩展 |
| Java / Kotlin 工程 | IntelliJ IDEA、VS Code |
| 终端与远程环境 | Vim / Neovim、VS Code Remote SSH |
具体功能、系统要求和授权政策会变化,安装前应查阅产品官网;学生授权也不等同于产品永久免费。
Dev C++ 与小熊猫 C++
Dev C++ 在许多入门教程、课程评测环境里仍然出现,但它长期缺乏系统性维护、对新 C++ 标准(C++11 之后)支持滞后,不推荐作为长期主力工具。若课程要求类似 Dev C++ 的界面,可改用开源且持续维护的小熊猫 C++(Red Panda C++):royqh.net/redpandacpp,兼容 Dev C++ 的操作习惯,并内置更新的 GCC/MinGW 工具链。
避免脱离需求比较工具
能否可靠打开项目、使用现有工具链、运行调试与测试,比功能数量或快捷键风格更重要。
八、TODO 清单
- 了解纯文本、富文本与版式文档的区别
- 能区分编码、解码与转码,并了解 UTF-8 / GBK 乱码的成因
- 能独立下载并安装 VS Code,并切换为中文界面
- 能用「通过编码重新打开」检查乱码,而不是直接覆盖保存
- 能在编辑器中查看并切换文件编码
- 尝试使用多光标、全项目搜索和预览替换结果
- 尝试下载安装一款 JetBrains 系的 IDE,如 CLion 等,并尝试进行简单的探索与使用
(比如,搞点新花样,来个。World, Hello!)
九、值得我们思考的问题
修改编码、换行符或执行全项目替换,如何判断是否安全?
操作前确认 Git 工作区状态、源编码和项目约定,并把范围缩小到必要文件。编码转换应保留原始副本或处于可回退的版本控制状态;全项目替换应逐项查看预览。操作后检查差异,再运行受影响的格式化、检查或测试命令。
编码、换行符和正文内容不宜混在同一次批量修改中,否则难以判断差异来自哪里。.gitattributes 适合维护仓库级换行约定,但引入规则后的首次规范化仍应单独审查和提交。