开发者常用的在线数据转换工具
在本地转换日期、Cron 表达式、JSON、YAML、TOML、宽松伪 JSON、表格与进制。
选择一个工具
只有当类型和时区一起活下来时，转换才算保住了原意。
这里的六个工具，跨越的是在类型、顺序和时间规则上互不相同的格式。两个关于时间，三个关于把文档换一种形态，一个关于数字怎么写。所有情况下，输出都可能在预览里看着完全正确，却被下一个加载它的系统读错，因为这些格式对「一个裸值是什么意思」并不一致。
先进入 JSON，再从 JSON 出去
手里的东西根本不是 JSON 时，宽松 JSON 转标准 JSON 是那道门：日志里 dump 出来的 Java Map 或 Lombok toString，键不带引号、用等号而不是冒号。先跑它，因为下游任何解析器都不接受这种结构。
文档确实是 JSON 之后，由目的地决定用哪个工具。JSON 转表格与 CSV 把它摊平成可读的行并导出 CSV，适合查看数据，也适合交给电子表格。JSON 转 YAML / TOML 则保留嵌套，把文档搬进配置格式。
两者不能互相替代。表格会迫使你决定嵌套对象和数组怎么处理，这个决定必然丢信息。YAML 和 TOML 保留结构，却强加了自己的类型规则——不带引号的 yes 会变成布尔值，问题就出在这儿。
时间：时间戳转换与 Cron 表达式解析
时间戳与时区转换处理 Unix 时间戳、时区和相对时间。最费时间的歧义是秒与毫秒，因为两者看上去都像一个合理的整数，猜错了就会落到 1970 年或者五万多年以后。第二个是时区：一个没有把时区一并记下来的转换结果，算不上一个事实。
Cron 表达式解析校验语法并预测接下来的执行时间。Cron 不是一种语言：五字段是经典形态，六字段多了秒，Quartz 还有自己一套星期语义。请按调度器实际使用的方言和时区预览，并记住夏令时切换可能会跳过或重复一次执行。
进制转换，以及预览证明不了的事
进制转换工具在二进制、八进制、十进制和十六进制之间搬运数值，同时支持 RFC 4648 编码和自定义字典。请把两件事分开：把同一个数换一种进制书写，和把一段字节序列做编码，不是一回事。
这里每个工具产出的东西在屏幕上都像模像样。在它成为运行数据之前，先用真正的消费方加载一遍：服务用的那个 YAML 加载器、拥有这条 Cron 条目的调度器、将要读这份 CSV 的导入程序。
在采信结果之前
- 明确写出时间戳的单位是秒还是毫秒，并在每个转换结果旁边记下时区。
- 伪 JSON 先过一遍宽松 JSON 转换。键不带引号、用等号连接的结构不是 JSON，下游什么都解析不了。
- 转成 YAML 后检查引号。那里不带引号的 yes、no、on、off 都是布尔值，前导零还可能改变数字的进制。
- 把 JSON 导出成 CSV 之前，先决定嵌套对象和数组怎么处理，摊平本质上就是有损的。
- 按调度器自己的方言和时区预览 Cron，并验证一次夏令时切换前后的行为。
常见问题
我的时间戳转出来是 1970 年，怎么回事？
把毫秒值当成秒读了，或者反过来。至少对当前前后的日期而言，十位整数几乎总是秒，十三位几乎总是毫秒。请显式指定单位，不要让工具靠位数去猜。
为什么 YAML 的行为和它来源的 JSON 不一样？
YAML 会从不带引号的文本推断类型。yes、no 之类的词会变成布尔值，带前导零的值可能被当作八进制，而 1.10 这样的版本号会变成数字并丢掉末尾的零。凡是要保持为字符串的，都加引号。
Cron 预览会和调度器的实际行为一致吗？
只有在方言和时区都对上的前提下才一致。五字段 Cron、带秒的六字段 Cron 和 Quartz 之间有实质差异，而跑在 UTC 的调度器不会认同一份按本地时间做的预览。两项都要按拥有这个任务的系统来核对。