这是一个创建于 179 天前的主题，其中的信息可能已经有所发展或是发生改变。
如题。
 |
1
guxingke 179 天前  10
任何情况下 都不应该考虑
|
 |
2
sakura6264 179 天前 1
除了有人要求你的情况下，比如政府公文，否则忘掉 GBK
|
 |
3
22092 179 天前
对象主要是给未来的考古学家查看的情况下，因为这(些)编码可能在未来不存在
|
 |
4
AkaGhost 179 天前
除了你的用户喜欢拿记事本修改或查看以外（而且是不支持 UTF-8 的记事本版本），否则永远不要使用 GBK ，用 UTF-8 。其它的只会带来无穷无尽的麻烦。
|
 |
5
tool2d 179 天前
不是前端项目，不是和别人合作项目，我觉得用什么编码都无所谓。
但是前端最好用 utf8 ，你 gbk 有些特殊 unicode 字符没办法表示出来。 |
 |
6
realpg 179 天前
不跟别的系统互通的小系统，随便……
|
 |
7
lambdaq 179 天前
存大量中文 && 存储空间是金子做的情况下，gbk 比 utf8 节约 33.333% 的空间。
|
 |
8
x86 179 天前 1
现在在点错的情况下才会用 GBK
|
 |
9
gzhjj 179 天前 via Android
某些默认支持 GBK 的专用设备的软件项目
|
 |
10
pkoukk 179 天前
我穿越回 2008 年的情况下
|
|
11
pkoukk 179 天前
其实最近搞到的一个私服源代码是用 GBK 的，因为代码里有大量硬编码的字符串，这些字符串会直接序列化给客户端，客户端是 GBK 编码的
整个项目非常混乱，想拦截一下统一处理编码工作量太大，干脆躺平了 |
 |
12
felix0liu 179 天前
CSV 文件，如果是 UTF-8 格式用 Excel 打开会乱码
|
 |
13
Muniesa 179 天前 via Android
@felix0liu Excel 这个确实烦，我一般保存成带 BOM 的 UTF-8 ，关键是它明明有个从 CSV 导入数据的选项是可以直接读 UTF-8 的，但是直接打开就乱码
|
 |
14
xiangyuecn 179 天前
小硬件存储空间是金子做的情况下，gbk 很常用，物料价格估计能便宜几毛。
|
 |
15
Jooeeee 179 天前
gbk 是固定 2 字节，utf 是变长。想要根据长度读字符的时候可以用
|
 |
16
zzzmh 179 天前 3
公司拖欠你半年工资没给你，还让你继续开发新项目的时候
|
 |
17
Binwalker 179 天前 1
存中文小说的可以用 GBK ，但仅限于小说的 txt 文件，然后用来提供下载，可以节省 1/3 的空间
|
 |
18
brader 179 天前 1
写代码就不要了。我能想到现在还用 GBK 编码存储并让我感到合理的就是：我用的一些国内的本地 IP 库，作者就是用 GBK 编码存储，大概十几 M ，如果换成 UTF8 的话大挺多，这个场景我感觉很合理
|
 |
19
Conantv2 179 天前 1
想坑维护费的情况下用 GBK 。GBK 交付，后续增加生僻字功能，又赚一笔。
|
 |
21
devopsdogdog 179 天前 via Android
银行项目，我维护过
|
 |
22
potatowish 179 天前 via iPhone
银行、保险项目用 oracle 数据库，编码就是 gbk ，据说是节省存储空间
|
 |
24
shijingshijing 179 天前 1
某些点阵类的中文显示设备，字库是硬编码的 GBK ，你的输入不弄成 GBK 试试。。。
|
 |
25
Ally 179 天前
人傻了的情况下🐶
|
 |
26
preach 179 天前
在错误的情况下
|
 |
27
atuocn 179 天前
GBK/GB18030 的编码密度要大于 utf-8 。一坨坨中文字的网文 “巨著” ，用 GBK/GB18030 保存，文件大小远小于 utf8 。用来看小说可以用，但是也可以用 utf-16 。
除此之外，以及环境特殊情况，还是 utf8 吧。 |
 |
28
laqow 179 天前
不加 BOM 的 utf8 和 GBK 性质不是一样的？不指定编码都是乱码。加 BOM 的 utf8 头两个字节一不小心就变 bug
|
Select Language