如果你刚开始刷算法题，多半会在某个OJ的入门字符串题单里碰到一个叫“密码翻译”的题目，它的编号可能是B2115，也可能叫别的，但考察的东西一样：给一行字符串，把英文字母按字母表循环后移两位，非字母字符原样输出。这题看起来就是“遍历一遍改一下字符”的事，但我翻了翻周围人的提交，第一次做的人普遍要WA个一两回才过，而且大多数WA不是栽在译码逻辑上，而是栽在输入读取上。这篇就从一个过来人的角度，把这题的考点、写法、坑和延伸一起捋清楚。
B2115这类题最迷惑人的地方在于：它太简单了，简单到让人觉得不需要动脑子。可越是这样，越容易在细节上翻车。我见过有人把字母加2就提交，结果'y'变成了'{'；也见过有人用scanf读字符串，结果带空格的测试数据一进来就错。等你把这些问题全部解决完，才会意识到这道题真正想训练的不是“你知道凯撒密码”，而是“你能不能把字符串处理得滴水不漏”。
1. 看懂题目真正的考点：字符串替换背后的基本功
1.1 题目究竟让你做什么
先按最常见的题目描述来拆解。B2115密码翻译的规则通常是这样的：输入一行字符串，其中可能包含大写字母、小写字母、数字、空格和各种标点。你要做的，是把每一个英文字母替换成字母表中它后面第二个位置的字母。
举个例子：a变成c，b变成d，X变成Z。问题是到了边界怎么办？y和z后面已经没有字母了，所以题目规定循环处理——y变成a，z变成b。非英文字符，比如空格、数字、逗号、句号，一律原样输出，不改变。
不同OJ上这题的描述会有细微差别，有的版本把后移位数改成3，有的版本会给你加密函数让你写解密函数，还有的版本要求字母表整体倒序映射。但核心逻辑完全一样：这本质上是凯撒密码（Caesar Cipher）的变种，把明文字母沿着字母表平移固定的位数。要是题目把规则换成后移三位，你就想象成古罗马的将领在传递军令；换成后移两位，其实就是常见的“往前推两个字”的小把戏。
你只要抓住“字符到数字、数字加偏移量、取模回绕、再变回字符”这一条主线，不管题目怎么改写，代码骨架都不用动。
1.2 题目真正想考察的三个层次
这道题在竞赛和OJ入门题单里出现频率极高，不是因为它有难度，而是因为它是很好的“字符串基本功试金石”。按我的理解，它一共考了三层东西：
第一层是输入输出能力。OJ的测试数据往往不止一组，而且字符串可能自带空格，怎么把一整行完整读进来，怎么检测文件结束，这是第一个要被拷问的点。习惯用scanf("%s")读字符串的初学者，在这一步就会爆雷。
第二层是字符运算能力。英文字母在计算机里本质是整数，对应ASCII码。你需要明白'A'是65、'a'是97，并且能熟练地在字符和0到25的数字之间来回转换。取模运算在这里的核心作用是处理“循环”，不理解这一点，边界字母永远处理不对。
第三层是程序结构能力。一个成熟的解法应该把“字符翻译”抽成独立的逻辑，而不是把住main函数里塞一堆if-else。这样代码不仅可读性高，将来规则一变，你只需要改一个参数。
这三层能力，在B2115里都能得到充分训练。所以别嫌这道题简单，它就是用来检验你基础扎不扎实的。
2. 三种主流解法拆解：从C语言到Python的取舍
2.1 最朴素的逐字符判断写法（C/C++实现）
如果你参加的是C/C++比赛，最常见的写法就是逐字符遍历，判断大小写后分别处理。我先把完整代码放出来：
#include <stdio.h> int main() { char s[1005]; while (fgets(s, sizeof(s), stdin)) { for (int i = 0; s[i] && s[i] != '\n'; i++) { if (s[i] >= 'a' && s[i] <= 'z') { s[i] = (s[i] - 'a' + 2) % 26 + 'a'; } else if (s[i] >= 'A' && s[i] <= 'Z') { s[i] = (s[i] - 'A' + 2) % 26 + 'A'; } } printf("%s", s); } return 0; }这段代码里有几个地方值得单独拎出来讲。
fgets(s, sizeof(s), stdin)负责读取一整行，包括空格。这是处理带空格字符串的可靠方案。fgets会把换行符也读进来放进数组末尾，所以我用s[i] != '\n'作为循环停止条件之一，否则你可能会错误地把换行符当空格处理。
最核心的是那一句(s[i] - 'a' + 2) % 26 + 'a'。它的意思是：先把字符转成它在字母表中的序号，比如'a'是0，'b'是1……'z'是25；然后加2得到平移后的序号；用% 26做回绕，这样25加2变成27，取模后变成1，对应'b'；最后再加上'a'的ASCII码，把序号变回字符。大写同理，只是基准值从'a'换成了'A'。
这个写法的好处是直白、没有多余依赖、执行效率也高。坏处是如果你第一次接触，可能看不懂那一长串表达式是在干嘛。建议你在草稿纸上拿'y'手推一遍：'y'的序号是24，24+2=26，26%26=0，0+97=97，也就是'a'，完全正确。
2.2 Python风格的简洁实现及其适合人群
对于刷Python的选手，代码会更简洁，也更贴近自然语言：
import sys for line in sys.stdin: res = [] for ch in line: if 'a' <= ch <= 'z': res.append(chr((ord(ch) - ord('a') + 2) % 26 + ord('a'))) elif 'A' <= ch <= 'Z': res.append(chr((ord(ch) - ord('A') + 2) % 26 + ord('A'))) else: res.append(ch) print(''.join(res), end='')Python里没有C语言那种“字符就是整数”的隐式转换，所以需要ord()把字符转成ASCII码，处理完再用chr()转回来。没有end=''的话，print会自动追加一个换行符，而原字符串末尾本身已经有换行符了，会多出一个空行。这种细节不是题目考察的重点，但却是实际提交时最容易影响结果的隐藏因素。
从学习角度说，Python写起来舒服，能帮你更专注于字符运算的逻辑本身。如果目标是为了熟悉算法竞赛，我还是建议你用C/C++把同样的逻辑也实现一遍。用两种语言各写一次，你会对“字符与整数转换”“取模回绕”这些概念理解得更透。
2.3 为什么不建议一上来就查表和硬编码
我还见过一种解法：直接把映射关系写成一个查表字符串，比如用"cdefghijklmnopqrstuvwxyzab"来映射小写字母，大写同理。这样做在小偏移量下确实能过，但我不推荐，因为这里有个性价比问题。
硬编码查表有三个明显的坑。第一是可扩展性差，题目如果改成偏移三位、偏移五位，你得重新写一遍映射表，还很容易写错。第二是肉眼检查困难，一串26个字母你很难一眼看出哪里丢了字符或者多错位了一位，排错成本很高。第三是它完全绕开了字符运算的训练，失去了这道题本来的练习价值。
从工程角度讲，查表法在特定场景（比如替换规则极其复杂、无法用公式表达）是有意义的，但对于B2115这种规则清晰的题目，数学表达式才是最稳妥、最优雅的方案。我把三种写法摆在一起对比一下：
| 写法 | 可读性 | 扩展性 | 出错风险 | 适用场景 |
|---|---|---|---|---|
| 字符加减取模 | 中等，需要理解ASCII | 强，改一个数字即可 | 低 | OJ刷题、竞赛 |
| Python字符处理 | 高，接近自然语言 | 强 | 低 | 快速原型、日常脚本 |
| 硬编码查表 | 高，但维护性差 | 弱，每次规则变化都要重写 | 较高 | 规则复杂且固定的业务 |
3. 我在提交时反复踩的坑：输入陷阱与边界条件排错实录
3.1 带空格的整行字符串：scanf的失效现场
先说我自己第一次WA的经历。当时我用的是scanf("%s", s)，然后在本地试了abc，输出cde，一切正常。我很自信地提交，结果判了个WA，而且完全不知道错在哪。
后来我拿测试数据改成本地文件一跑，发现输入hello world，程序只输出了jgnnq，后面的world整个消失了。查了文档才反应过来：scanf("%s")是按空白字符切分的，读到空格就停，所以它只处理了“hello”这一小段。
这个坑是所有C语言初学者都会踩的，差别只是早晚。解决办法很简单：用fgets读整行，或者用getchar()配合循环自己拼字符串。之后我就形成了条件反射——只要题目说“给定一行字符串”且可能含空格，绝不碰scanf("%s")。
这里还要提一下EOF。OJ通常会有多组测试数据，代码得一直读到输入结束才能停。fgets读到文件尾时会返回NULL，所以while (fgets(...))就是标准的读满全部数据的写法。换成Python就是sys.stdin的迭代。
3.2 循环移位的取模运算：字母表“转圈”的数学处理
如果你理解不了取模，边界永远是个坎。有人图省事，直接写s[i] = s[i] + 2，结果'y'加2变成ASCII码123对应的'{'，直接原地爆炸。问题就出在没有人告诉程序“字母表是循环的”，它也不知道到了'z'要折回'a'。
取模运算% 26是处理这种循环的数学手段。关键是先做“字符到序号”的转换，再进行加减和取模，最后还原成字符。还有个进阶细节：如果题目要求的是“前移”（比如反向翻译），你会写出(s[i] - 'a' - 2) % 26，但C语言里负数取模的结果是负数，比如(0 - 2) % 26在C里是-2而不是24。这时必须做“加26再取模”的修正，写成(s[i] - 'a' - 2 + 26) % 26。
当时我盯着负数的测试数据想了好一阵，还以为是取模运算坏了。后来才意识到这是C语言负数整除的规则问题。你如果也遇到类似现象，记住一句话：先加一个模数把负数修正掉，再取模，就不会出错。
3.3 大小写分支与非法字符处理：三个if的顺序问题
大小写和非法字符的处理看起来是纯体力活，但分支顺序直接影响正确性。我的习惯是先判断'a'到'z'的范围，再判断'A'到'Z'的范围，最后剩下的全部原样保留。
这里有个容易被忽略的点：'Z'的ASCII码（90）其实是小于'a'的ASCII码（97）的，所以不要想当然地认为“先大写后小写”就一定正确，关键是范围判断要写完整。比如有人漏写了<= 'Z'，只写了if (s[i] >= 'A')，那么所有小写字母也会落入这个分支，得到一堆乱码。
还有一种高级写法是用ctype.h里的isalpha、islower、isupper，能省不少事，但要注意：在标准C里，这些函数只保证对“属于该分类的字符”返回非零结果，对非字母字符直接调用tolower如果没有配合判断，在某些实现下会有未定义行为风险。稳妥的做法永远是先判断范围，再改字符。
4. 从B2115延伸出去：凯撒密码、ROT13与OJ字符串题的通用套路
4.1 把规则泛化成“偏移量”，一套代码通吃
B2115这题实际上就是一个固定偏移量的凯撒密码。如果你看穿了这一点，完全可以把代码里的“2”提炼成一个参数，写一个通用的翻译函数。比如Python版本：
def caesar_shift(text, offset): result = [] for ch in text: if 'a' <= ch <= 'z': result.append(chr((ord(ch) - ord('a') + offset) % 26 + ord('a'))) elif 'A' <= ch <= 'Z': result.append(chr((ord(ch) - ord('A') + offset) % 26 + ord('A'))) else: result.append(ch) return ''.join(result)这样一改，B2115的答案是caesar_shift(line, 2)，如果哪天题目要求后移3位，就是把第二个参数改成3，其他完全不动。以后遇到任何“偏移式”的密码题，你都可以直接复用。
更妙的是，这个函数同时支持加密和解密。偏移量为正就是加密，为负就是解密。你只需要注意负数偏移要像前面说的那样修正取模，比如(ord(ch) - ord('a') + offset) % 26在Python里本身对负数取模会得到正确结果，但在C语言里就必须写成(ord(ch) - ord('a') + offset + 26) % 26。跨语言对比一下，你会发现语言特性差异也能帮你加深对取模运算的理解。
4.2 真正能拉开差距的扩展思考
B2115这种题做一遍就够了吗？从刷题策略上讲，它只是个起点。围绕它至少可以延伸出三类值得继续钻的方向。
第一类是变种规则。比如ROT13，它是偏移量固定为13的凯撒密码，因为26的一半是13，所以加密两次就得到原文。这种对称性很有趣，在论坛上有人用它来隐藏剧透内容，背后就是B2115的同一套原理。你可以在本机把刚才的函数offset改成13，试试把一段英文加密再解密，验证一下效果。
第二类是性能优化。如果输入数据量极大，逐字符用printf输出会非常慢，因为每次调用都有I/O开销。实际竞赛中，可以把结果先存进一个大的缓冲区，最后一次性输出，或者使用更快的输入输出函数。这种“I/O即性能瓶颈”的思路，对后面做更难的题很有帮助。
第三类是字符串题目的通用解法框架。B2115要求“保留原格式、只改字母”，这一模式和很多字符串处理题一脉相承：先确定字符子集（是不是字母），再按规则做变换，最后拼回去。你看回文判断、单词反转、大小写转换、进制转换，底层都是这套东西。把B2115的骨架吃透，等于给你的字符串处理内功做了一次小升级。
4.3 实测下来我对这题的最终体会
最后一次过掉这题之后，我又专门试了几种写法。实测下来的体会是：这个题的难度不在题本身，而在你能不能一次想清楚边界条件。我的最终固定写法就三步——先把“字符转序号”想成把字母映射到一圈数字上，再规定好移动方向和步数，最后解决走过头了怎么办。只要这三步在脑子里跑通，提交就不会慌。
对刚开始刷题的朋友，我有一个朴素建议：AC之后别急着看下一题，把代码里处理输入的部分注释掉，换一种输入方式再写一遍，再把这题改成偏移三位重新跑一遍。这种“强迫自己换个姿势写同一道题”的做法，比连续刷三道同类型题还涨功夫。我当年就是靠着这种笨办法，把字符串处理的基础打得比较扎实，后面遇到类似的题目，基本都是一次过，不再需要反复试错。
最后分享一个自检小技巧。你可以把自己代码的输出结果重新作为输入，用同样的翻译规则再处理一遍，看能不能还原出原字符串。这个“往返测试”对凯撒密码类题目尤其好用，写完代码后在本地跑一遍这个测试，90%的边界问题都能提前暴露。这套方法不光适用于B2115，以后做任何有对称性的编码解码题，都可以照葫芦画瓢。
