简介面向股票数据分析与Python开发者这份资源演示了如何用约20行代码解析同花顺日线.day二进制文件。.day文件是存储股票历史交易数据的专有格式包含日期、开盘价、收盘价、最高价、最低价、成交量、成交额等关键信息脚本从二进制模式打开文件、读取头信息开始逐步按固定长度记录提取字段并转换为便于分析的列表或DataFrame结构。资源共2个文件包括600000.day示例数据与getAllData.py解析脚本压缩包仅4KB轻量易携带。已有2237人学习下载适合希望掌握金融数据文件解析思路、提升Python二进制处理能力的初学者。通过阅读脚本可清晰理解字段偏移与解码方法并可快速扩展为多文件批量处理、行情导入或可视化分析工具对于需要处理本地行情数据的用户而言直接获得结构化数据可显著提高研究效率。2. 同花顺日线文件解析从二进制还原K线数据搞量化和自建数据仓库的朋友十有八九会遇到一个尴尬场景手头只有同花顺客户端想拿历史日线数据做回测但导出功能要么收费要么导出来的是Excel格式字段还不全。我之前也卡在这个环节后来干脆直接去解析同花顺本地落盘的日线文件把二进制数据还原成干净的DataFrame一劳永逸。这篇文章就围绕同花顺日线文件解析来写讲讲这个文件到底长什么样、字段是怎么排布的、为什么按这种方式存、以及你拿到手之后怎么用Python把它完整读出来。内容适合正在做量化回测、本地数据备份、或者想搞清楚行情软件底层数据结构的读者基础要求只有一点点会用Python、能安装第三方库就行。2.1 同花顺日线文件里到底存了什么先说结论同花顺的日线文件本质上是一个自定义的二进制文件不是文本文件所以用记事本打开只能看到乱码。它按股票代码分文件存放每个文件里是一连串固定长度的记录每条记录对应一个交易日的数据包含日期、开盘价、最高价、最低价、收盘价、成交量、成交额这些基础字段。这里有一个很关键的背景知识几乎所有国内行情软件同花顺、通达信、大智慧的本地数据文件都采用“二进制定长记录”的存储方式。为什么这么做因为当你需要一次性加载几千只股票、每只股票又有一千多个交易日的历史数据时定长记录的随机读取效率极高——你只要知道文件偏移量就能直接跳到某个日期附近读数据完全不需要像文本文件那样逐行扫描。同花顺的日线文件基础版本用的是32字节定长记录这个设计沿用了很多年后来虽然加入了扩展字段但核心结构没有变过。咱们要解析的就是这32字节的结构。在这个结构里日期不是以“2024-01-15”这种字符串存的而是用一个整数表示价格也不是直接存浮点数而是用整数存储、显示时再除以100之类的精度换算。这个设计初看很绕但实际想一下浮点数在二进制里的小数位是近似表示的如果直接存float做区间比较和复权计算时容易埋精度误差的雷用整数存本质上就是把所有价格都看作“厘”这个单位既保精度又省空间还方便做索引和差值计算。这是所有老牌行情软件的一致选择。2.2 为什么不能直接拿现成工具非要自己解析你可能会问同花顺不是有数据导出吗或者直接用第三方库比如pytdx拉数据不行吗我的回答是能用现成工具当然先用现成工具但“自己解析本地文件”这条路有它不可替代的价值。第一同花顺客户端的数据导出有诸多限制。免费版导出的字段有限而且每当你切换股票或者更改前复权/后复权设置导出的数据会跟着变口径不稳定。第二第三方网络接口拉历史数据一般有频率限制如果你要并行处理几千只股票速度慢不说还可能被封。第三本地文件解析的最大优势是离线可用、一次性全量读取配合pandas做清洗和转存整个流程是可复现的。我自己做这件事的契机是当时需要把同花顺里一个有十几年历史的指数成分股日线数据清洗后导到自己的数仓量级大概在3000只股票的文件用导出功能根本不可行。于是我把同花顺安装目录下的日线数据文件翻出来发现是同花顺自有的日线数据文件不同版本可能路径不同具体路径需根据实际安装情况确认顺着文件结构逆向了一遍字节布局才彻底搞定。接下来我会把完整的字节字段解剖和解析流程写出来你看完也能自己复现。3. 核心细节字节级字段解剖与排布逻辑3.1 32字节记录里每个字段的含义同花顺日线文件的一条记录固定是32字节字段顺序和类型大致如下表所示不同版本可能存在字段微调但主体逻辑稳定字段类型长度说明日期uint324字节通常存为整数例如20240115开盘价uint324字节整数存储实际价格需换算最高价uint324字节同上最低价uint324字节同上收盘价uint324字节同上成交额float324字节单位通常为元有些版本为万元成交量uint324字节单位通常为股/手需确认保留字段uint324字节可能是复权因子或扩展标记这些字段看起来简单但里面有两个比较容易踩坑的地方。第一个坑是价格精度。不同同花顺版本或不同市场比如港股、美股的价格精度可能不一样有的按1/1000存有的按1/100存甚至有的按1/10存。你得先拿一只你知道真实价格的股票反推一下精度。比如某股票某日收盘价是12.35元如果文件里存的是12350那精度就是1/1000如果存的是1235那精度就是1/100。用已知股票反推是最稳妥的校验手段。第二个坑是成交量的单位。A股个股成交量在行情接口里通常以“股”为单位但同花顺本地文件里为了节省空间可能存成“手”1手100股或者干脆存成原始股数这个不统一必须通过对比已知历史数据确认。我见过有人直接把成交量当成“股”来用结果画出来的量能图数值全偏了100倍。另外那个4字节的“保留字段”也不该忽略。在某些版本的同花顺日线文件中这个字段存放的是后复权因子相关的信息或者是扩展的标记字段。解析时即使不直接用它也建议把它一并读出来后续做复权处理时会很关键。3.2 时间编码与价格换算的底层逻辑日期字段用整数存储有一个直观的好处直接比较大小就能排序。比如20240115和20240116整数数值大的一天就是后一天。但如果我们想在pandas里按日期索引就得把这个整数转换成真正的datetime类型。转换方式先把整数转字符串再解析成日期。比如20240115转成2024-01-15然后用pd.to_datetime处理。这一步在字段量大的时候会慢一些其实可以向量化处理先把整个日期列拼成字符串数组再统一to_datetime性能会好很多。价格换算的逻辑也很直接假设精度为d比如d100实际价格 原始整数值 / d。需要注意的是读取时要先把二进制里的小端序整数转成Python整数再做除法。如果直接拿原始字节去整除会得到错误结果。成交额字段本身是float32精度已经有限如果文件里存的是“元”那float32差不多能保住到个位数的精度如果存的是“万元”那数值本身已经做了缩放。无论哪种情况建议在入库时统一换算成“元”而不是保留原始单位这样后面所有指标计算都不用再关心单位换算。我在实操中会选择把读出的原始字段全部转成统一单位之后再写入parquet文件这样后续查询速度会快很多。4. 实操过程从二进制到DataFrame的完整实现4.1 Python解析代码逐字节读取并校验明确了字段结构解析代码就不复杂了。我用Python的struct模块来做二进制解包整个脚本大概是这样的import struct import pandas as pd from pathlib import Path # 假设文件是32字节定长记录 # 字段顺序日期(4) 开盘(4) 最高(4) 最低(4) 收盘(4) 成交额(4) 成交量(4) 保留(4) RECORD_SIZE 32 RECORD_FORMAT IIIIIfII def parse_tdx_daily(file_path: Path): 解析同花顺日线文件 返回DataFrame列名date, open, high, low, close, amount, volume rows [] with open(file_path, rb) as f: while True: chunk f.read(RECORD_SIZE) if len(chunk) RECORD_SIZE: break # 解包 date_int, open_int, high_int, low_int, close_int, amount_float, volume_int, reserve struct.unpack(RECORD_FORMAT, chunk) # 按精度换算示例用100表示1/100 price_scale 100.0 rows.append({ date: pd.to_datetime(str(date_int), format%Y%m%d), open: open_int / price_scale, high: high_int / price_scale, low: low_int / price_scale, close: close_int / price_scale, amount: amount_float * 10000 if amount_float 100000 else amount_float, volume: volume_int, }) df pd.DataFrame(rows) return df上面这段代码看起来简单但有几个细节值得展开。第一struct.unpack的格式字符串IIIIIfII中尖括号表示小端序I是无符号整型4字节f是单精度浮点4字节。因为同花顺这类Windows时代落盘的软件全部按小端序写文件所以解包时务必加否则字段会错位。第二成交额的换算我写了一个条件判断如果读出来的金额小于10万就认为单位是万元需要乘以10000如果本身就很大就认为单位是元。这个判断是启发式的实际使用中建议先人工核对一个交易日的数据确认好单位后再写死换算规则不要依赖自动判断。第三如果文件末尾不够32字节直接break。为什么要有这个判断因为同花顺在写文件时偶尔会出现断电或强制退出导致的末尾残缺记录。不处理这最后几个字节整个文件读取就会抛异常。我在实际解析一只长期停牌又复盘的股票时就遇到过末尾多了6个字节的情况加了长度判断后才稳定跑通。4.2 后复权与前复权的处理思路解析出原始数据只是第一步做回测的人更关心复权价格。同花顺本身在客户端里显示的是前复权价格但本地文件里的价格一般是不复权的原始价格——也就是说你看到的文件里的收盘价是当时真实成交的收盘价没有考虑除权除息。为什么要关注复权因为如果某只股票中间经历了10送10那么除权当天股价会直接腰斩这个价格断层如果不处理你算出来的收益率全是错的。复权有两种常见方式前复权以最新价格为基准把历史价格往前调整适合看“当前视角下”的走势。后复权以上市首日价格为基准把后续价格往后调整适合做数学统计和回测因为它的长期收益率曲线是完全连续的不会因为新增交易日而变化。同花顺本地文件里那个保留字段有些版本其实存的就是后复权因子或者和复权因子的计算有关。拿到这个因子后后复权价格 不复权价格 * 因子。如果保留字段没有有效信息那就需要自己维护一份除权除息记录表然后按日期计算复权因子。我这里用最常见的方案自己维护一个复权因子序列。def apply_adjust_factor(df, factor_series): df: 不规则日期索引的原始日线 factor_series: 日期-复权因子 返回后复权价格 merged df.join(factor_series.rename(factor), howleft) # 缺失因子时向前填充因为复权因子在除权日当天才变化 merged[factor] merged[factor].ffill().fillna(1.0) for col in [open, high, low, close]: merged[col] merged[col] * merged[factor] return merged你在实际操作中一定要记得成交量是不做复权调整的除权当天流通股本可能变化但成交量文件里存的是当时成交的真实股数不应参与复权乘法。很多新手在这里会顺手把volume也乘以因子最后量能曲线面目全非。4.3 读取效率与内存控制的工程化考虑一次性读几千个文件时解析速度和内存占用是绕不开的问题。我在第一版实现里直接用struct.unpack逐条记录循环读单文件一千多行倒还好但一旦批量处理3000个文件Python循环的开销就会成为瓶颈。我后来做了一步优化先把整个文件read进内存然后用struct.iter_unpack配合列表生成式一次性解包全部记录。这样虽然后续要处理一整个列表但减少了解包函数的重复调用速度提升大概2-3倍。再进一步如果你愿意用numpy的frombuffer配合自定义dtype直接从字节数组批量读取那性能会更好代码也更接近c语言风格。import numpy as np def parse_fast(file_path: Path): dtype np.dtype([ (date, u4), (open, u4), (high, u4), (low, u4), (close, u4), (amount, f4), (volume, u4), (reserved, u4), ]) raw np.fromfile(file_path, dtypedtype) df pd.DataFrame(raw) df[date] pd.to_datetime(df[date].astype(str), format%Y%m%d) for col in [open, high, low, close]: df[col] df[col] / 100.0 return df这段代码最大的好处是numpy的fromfile直接在C层完成读文件和解包而不是在Python层循环因此性能特别好。实测下来用这种方法批量处理几千个文件时基本成了“等磁盘读取”而不是“等CPU解包”。内存方面真正吃内存的大户其实是pandas的DataFrame。如果你一次把所有文件读进一个大的DataFrame几千只股票、每只上千行那内存轻松上G。这里有两个思路一是分批读取每读完100只股票就落盘一次parquet然后释放DataFrame二是用category类型压缩股票代码列因为股票代码只有几千个枚举值用字符串存会有不少内存冗余。5. 常见问题与排查技巧实录5.1 解析出来数据对不上多半是精度或单位问题我在解析过程中遇到最多的问题就是读出来的价格和客户端显示的对不上。比如客户端显示某日收盘价为5.20元我解析出来的是52.0或者成交额差了好几个数量级。这类问题的原因十有八九是精度位或单位换算没搞清楚。检查方法很简单选一只你熟悉历史走势的股票比如贵州茅台600519打开同花顺客户端找到某一天的收盘价、成交量和成交额然后和你的解析结果对比。如果不匹配就尝试调整price_scale的数值从100、1000、10000逐个试成交量如果差100倍就把它除以或乘以100成交额如果差10000倍就按万元和元的单位差来处理。还有一个小细节某些同花顺版本在写入文件时会做“当日无成交”填充也就是说遇到停牌的交易日它也可能写入一条全为0的记录或者不写记录。两者行为不一样影响的是数据对齐。我在复盘一只长期停牌股时发现文件里直接跳过了停牌日期没有补零记录所以你在分析和复权时要做的是“缺失日期不填补”而不是“全0填充”否则会把停牌日误认为有交易。5.2 文件读取中途报错警惕尾部残缺和编码问题二进制解析最怕的就是“多了几个字节”或者“少了几个字节”。同花顺客户端如果异常退出尾部记录可能只写了一半导致文件大小不是32的整数倍。你如果直接用固定长度读最后一条记录会解包失败。解决方式就是在while循环里加长度判断。而如果用numpy的fromfile当文件末尾不足一个dtype长度时也会自动丢弃所以numpy方案天然更抗残缺。另外文件路径和文件名的编码问题也值得留意。同花顺安装目录下的文件名本身一般是股票代码不太容易乱码但如果你把文件复制出来放在一个带有中文路径的目录下Windows下Python的open函数默认会用系统编码解码路径有时候会出现文件找到了但路径解析失败的情况。稳妥的做法是给Path对象传字符串路径时用Path类的原生支持或者在打开文件时显式用errorsignore来处理路径中的异常字符。5.3 数据质量验证怎么确认你解析出来的数据是准的数据解析本身不难难的是你不能盲信自己的代码一次就对。我在每次解析完一批文件之后都会做三个校验步骤第一随机抽若干只股票对比最近10个交易日的收盘价与同花顺客户端显示的收盘价要求全部一致。第二用解析出的数据计算每只股票的区间收益率与同花顺客户端显示的区间涨幅对比误差应该在0.01%以内。第三检查数据是否有明显的异常值比如单日涨跌幅超过50%、成交量出现负值、日期跳变到未来等。这些检查不需要很复杂的逻辑一条pandas表达式就能搞定。如果你解析出的数据用于量化回测建议额外做一次“边界交易日”校验检查每只股票在上市首日和最后交易日的记录是否完整。某些文件在写入时会遗漏个别日期导致序列中间出现缺口这种缺口对收益率计算的影响很大。6. 总结与经验延展最后分享一点个人体会。解析同花顺日线文件这件事看起来是一个小众的二进制格式逆向问题但它背后的思路可以推广到很多类似场景通达信的.day文件、大智慧的数据文件、甚至一些游戏存档和EDA工具的二进制格式核心方法都是一样的——先确定定长记录的字段排布再确定字节序和精度最后用struct或numpy高效解包。我在完成这个解析脚本之后顺手把同花顺本地文件里的其他数据格式也摸了一遍后面甚至做了一个本地的“日线数据自动更新”方案每天收盘后自动解析新数据并追加到自己的parquet库中。这里分享几个值得继续扩展的方向一是如果你需要做分钟级别的回测可以尝试解析同花顺的分钟线文件。分钟线记录的字段和日线类似但每天有多条记录所以格式里会多一个时间字段。解析逻辑大同小异但要注意分钟线的成交量往往不是纯加总可能要额外校验。二是如果配合同花顺自动交易API做程序化交易本地日线文件的解析可以作为历史数据的初始化来源。API接口适合拿实时行情但历史数据的完整性和离线回放能力始终要靠本地文件来兜底。三是如果未来同花顺更新了文件格式或者你在某个版本上发现字节布局不对最好的方法还是老办法找一只已知价格走势的股票手工对比客户端显示的数值和文件里的二进制内容一点点倒推字段含义。这个方法听着笨但是最可靠比我在这里写一百个“可能为”都管用。数据解析这条路看似在跟文件格式死磕实际上是在跟“数据源稳定性”死磕。搞定了本地文件的解析你手里就相当于有了一套完全自主可控的历史行情数据源后续不管是写策略、画图表还是做数据研究都能事半功倍。本文还有配套的精品资源点击获取
