A. 我的股票要进行要约收购了,我要怎么操作啊
您好，如果您是融资买入的，需要保持维保比例超过300%，才可以将涉及要约收购的证券转至普通账户进行要约收购。（转出后，维保比例不得低于300%）
如果您是选择融券卖出的股票涉及到要约收购，需要在上市公司发布公告之日起5个交易日内，了结该笔融券负债。否则会进入平仓程序。
B. 股票要约收购到底有多久
收购要约约定的收购期限不得少于30日，并不得超过60日，但是出现竞争要约的除外。要约收购是指收购人向被收购的公司发出收购的公告，待被收购上市公司确认后，方可实行收购行为。这是各国证券市场最主要的收购形式，通过公开向全体股东发出要约，达到控制目标公司的目的。
【法律依据】
《中华人民共和国证券法》六十七条
收购要约约定的收购期限不得少于三十日，并不得超过六十日。
第四百八十三条
承诺生效时合同成立，但是法律另有规定或者当事人另有约定的除外。
《民法典》第四百八十四条
以通知方式作出的承诺，生效的时间适用本法第一百三十七条的规定。承诺不需要通知的，根据交易习惯或者要约的要求作出承诺的行为时生效。
C. 股市数据如何获取
股市的数据通过炒股软件，每天就可以自动收取
D. 我的股票要进行要约收购了,我要怎么操作啊
溢价20%豪气买股：高溢价要约收购又来！如何操作请看这十问十答
胡华雄
A股市场又来要约收购了，这次的主角是钱江水利。
简单来说，就是钱江水利的大股东愿意出高价买你手中的股票。
它想以15.36元/股的价格，最多买入占公司总股本10%的股票，如果你有钱江水利股票，可以选择以15.36元/股的价格卖给它。
钱江水利在公布要约收购方案前的股价为12.80元，15.36元的要约收购价较上述价格足足溢价了20%！是不是有一种“捡到宝”的感觉？
这不，在12日晚间公告要约收购的消息后，13日公司股价就先来了一个涨停！
6我前面同意卖给收购方，但后来股价涨起来了，可以反悔吗？
可以。要约收购有效期限内，所有的预受要约都只是暂存在中登公司，撤单时“买入”即可拿回你已“卖出”的股份。但切记，在要约期届满前3个交易日内，不能撤单！
7公司股票停牌期间能不能操作？
可以。停牌期间仍可办理预受要约的申报手续。
8如果后面公司更改了方案，以前挂的单还有效吗？
无效，会自动撤销。如果你接受新方案，要重新挂单。
9已预受要约的股票是否可以卖出？
已申报预受要约的股份当日可以申报卖出，卖出申报未成交部分仍计入预受要约申报。
10要约收购会导致公司退市吗？
在A股基本不可能，毕竟壳还是很值钱的。不以退市为前提的要约收购案例，收购方会在公告中明确表示，将采取各种合规手段，确保本次要约收购不触发退市。因此，对于选择继续持股的投资者，可以在要约收购后，正常买卖该公司股票。
按照法律规定，上市公司社会公众持股比例不足公司股份总数的25%，或者公司股本总额超过4亿元，社会公众持股比例不足公司股份总数的10%，将退市，但会有很多方法来规避出现这种极端情况的，就算万一出现，也有缓冲期来应对，所以不要担心啦。
E. 股票的要约收购如何操作
股票要约收购具体流程如下：一、沪市一般情况下，申报流程与股票限价买卖委托一致，输入要约代码，要约价格，要约数量（申报方向以具体公告为准）。二、深市1、您本人带身份证在交易时间到开户营业部办理。2、至诚版（核新交易）：股票--其它交易--预受要约，输入证券代码、要约代码及数量；3、电话委托：拨打95575（验证身份）--1委托--00要约收购--1预受要约，根据语音提示进行操作。
F. 某公司要股票上市，在哪查询他是否提交上市审批与审批进度！
交易所网站内的“最新上市公司公告”及创业板网站内的“最新公司公告”栏,他们亦可在香港交易所网站的“上市公司公告搜寻”一栏内找寻他们需要的公告或上市公司文件。
G. 如何通过雪球查询股票之前的变动状况
一. 雪球公司介绍
雪球 聪明的投资者都在这里。
web 1.0：新闻资讯，股价信息，K线图
web 2.0：SNS 订阅，分享，聊天
web 3.0：移动 APP，交易闭环
雪球现在员工数还不到100，其中技术人员占一半。去年9月C轮融资4kw刀。我们现在的技术栈由下列组件组成：Java，Scala，Akka，Finagle，Nodejs，Docker ，Hadoop。我们当前是租用IDC机房自建私有云，正在往“公私混合云”方向发展。
在雪球上，用户可以获取沪深港美2w+股票的新闻信息，股价变化情况，也可以获取债券，期货，基金，比特币，信托，理财，私募等等理财产品的各类信息，也可以关注雪球用户建立的百万组合，订阅它们的实时调仓信息，还可以关注雪球大V。雪球当前有百万日活跃用户，每天有4亿的API调用。App Store 财务免费榜第 18 名。历史上曾排到财务第二，总免费榜第 19。
二. 雪球当前总体架构
作为一个典型的移动互联网创业公司，雪球的总体架构也是非常典型的设计：
最上层是三个端：web端，android端和iOS端。流量比例大约为 2：4：4 。web3.0 的交易功能，在 web 端并不提供。
接入层以及下面的几个层，都在我们的自建机房内部。雪球当前只部署了一个机房，还属于单机房时代。正在进行“私有云+公有云混合部署”方案推进过程中。
我们当前使用 nodejs 作为 web 端模板引擎。nodejs 模块与android 和 ios 的 app 模块一起属于大前端团队负责。
再往下是位于 nginx 后面的 api 模块。跟 linkedin 的 leo 和微博的 v4 一样，雪球也有一个遗留的大一统系统，名字就叫 snowball 。最初，所有的逻辑都在 snowball 中实现的。后来慢慢的拆出去了很多 rpc 服务，再后来慢慢的拆出去了一些 http api 做成了独立业务，但即便如此，snowball 仍然是雪球系统中最大的一个部署单元。
在需要性能的地方，我们使用 netty 搭建了一些独立的接口，比如 quoto server，是用来提供开盘期间每秒一次的股价查询服务，单机 qps 5w+，这个一会再细说；而 IM 服务，起初设计里是用来提供聊天服务，而现在，它最大的用途是提供一个可靠的 push 通道，提供 5w/s 的消息下发容量，这个也一会再细说。
雪球的服务化拆分及治理采用 twitter 开源的 finagle rpc 框架，并在上面进行了一些二次开发和定制。定制的功能主要集中在 access log 增强，和 fail fast，fail over 策略及降级开关等。 finagle 的实现比较复杂，debug 和二次开发的门槛较高，团队内部对此也进行了一些讨论。
雪球的业务比较复杂，在服务层中，大致可以分为几类：第一类是web1.0，2.0 及基础服务，我们称为社区，包括用户，帖子，新闻，股价，搜索等等，类比对象就是新浪财经门户+微博；第二类是组合及推荐，主要提供股票投资策略的展示和建议，类比对象是美国的motif；第三类是通道，类似股市中的“支付宝”，接入多家券商，提供瞬间开户，一键下单等等各种方便操作的功能。
雪球的业务实现中，包含很多异步计算逻辑，比如搜索建索引，比如股票涨跌停发通知，比如组合收益计算等等，为此，我们设计了一个独立的 Thread/Task 模块，方便管理所有的后台计算任务。但随着这些 task 越来越多，逻辑差异越来越大，一个统一的模块并不是总是最佳的方案，所以，我们又把它拆成了两大类：流式的，和批量式的。
雪球的推荐体系包括组合推荐“买什么”和个性化推荐。我们最近正在重新梳理我们的大数据体系，这个感兴趣的话可以单聊。
最下面是基础设施层。雪球基础设施层包括：redis，mysql，mq，zk，hdfs，以及容器 docker。
线上服务之外，我们的开发及后台设施也很典型：gitlab开发，jenkins打包，zabbix 监控系统向 openfalcon 迁移，redimine向confluence迁移，jira，以及内部开发的 skiing 后台管理系统。
** 三. 雪球架构优化历程**
首先描述一下标题中的“股市动荡”定语修饰词吧：
上证指数从年初的3000点半年时间涨到了5000多，6月12号达到最高点5200点，然后就急转直下，最大单日跌幅 8.48%，一路跌回4000点以下。最近一周都在3900多徘徊。
3月最后一周，A股开户 166万户，超过历史最高纪录 2007年5月第二周165万户。
4月份，证监会宣布A股支持单用户开设多账户。
6月底，证金公司代表国家队入场救市。
7月份，证监会宣布严打场外配资。
中国好声音广告第一晚，带来超过平时峰值200倍的注册量
挑战：小 VS 大：
小：小公司的体量，团队小，机器规模小
大：堪比大公司的业务线数量，业务复杂度，瞬间峰值冲击
雪球的业务线 = 1个新浪财经 + 1 个微博 + 1 个 motif + 1 个大智慧/同花顺。由于基数小，API调用瞬间峰值大约为平时峰值的 30+ 倍。
挑战：快速增长，移动互联网 + 金融，风口，A股大盘剧烈波动。
首先，在app端，在我们核心业务从 web2.0 sns 向 3.0 移动交易闭环进化的过程中，我们开发了一个自己的 hybrid 框架：本地原生框架，加离线 h5 页面，以此来支撑我们的快速业务迭代。当前，雪球前端可以做到 2 周一个版本，且同时并行推进 3 个版本：一个在 app store 等待审核上线，一个在内测或公测，一个在开发。我们的前端架构师孟祥宇在今年的 wot 上有一个关于这方面的详细分享，有兴趣的可以稍后再深入了解。
雪球App实践—构建灵活、可靠的Hybrid框架 http://wot.51cto.com/2015mobile/ http://down.51cto.com/data/2080769
另外，为了保障服务的可用性，我们做了一系列的“端到端服务质量监控”。感兴趣的可以搜索我今年4月份在环信SM meetup上做的分享《移动时代端到端的稳定性保障》。其中在 app 端，我们采用了一种代价最小的数据传输方案：对用户的网络流量，电池等额外消耗几乎为0
每个请求里带上前一个请求的结果
succ or fail ： 1 char
失败原因：0 - 1 char
请求接口编号： 1 char
请求耗时：2 - 3 char
其它：网络制式，etc
炒股的人大多都会盯盘：即在开盘期间，开着一个web页面或者app，实时的看股价的上下跳动。说到“实时”，美股港股当前都是流式的数据推送，但国内的A股，基本上都是每隔一段时间给出一份系统中所有股票现价的一个快照。这个时间间隔，理论上是3秒，实际上一般都在5秒左右。 交了钱签了合同，雪球作为合作方就可以从交易所下属的数据公司那里拿到数据了，然后提供给自己的用户使用。
刚才介绍总体架构图的时候有提到 quote server ，说到这是需要性能的地方。
业务场景是这样的，雪球上个人主页，开盘期间，每秒轮询一次当前用户关注的股票价格变动情况。在内部，所有的组合收益计算，每隔一段时间需要获取一下当前所有股票的实时价格。起初同时在线用户不多，这个接口就是一个部署在 snowball 中的普通接口，股价信息被实时写入 redis ，读取的时候就从 redis 中读。后来，A股大涨，snowball 抗不住了。于是我们就做了一个典型的优化：独立 server + 本地内存存储。开盘期间每次数据更新后，数据接收组件主动去更新 quote server 内存中的数据。 后续进一步优化方案是将这个接口以及相关的处理逻辑都迁移到公有云上去。
对于那些不盯盘的人，最实用的功能就是股价提醒了。在雪球上，你除了可以关注用户，还可以关注股票。如果你关注的某只股票涨了或跌了，我们都可以非常及时的通知你。雪球上热门股票拥有超过 50w 粉丝（招商银行，苏宁云商）粉丝可以设置：当这支股票涨幅或跌幅超过 x%（默认7%）时提醒我。曾经连续3天，每天超过1000股跌停，证监会开了一个会，于是接下来2天超过1000股涨停
原来做法：
股票涨（跌）x%，扫一遍粉丝列表，过滤出所有符合条件的粉丝，推送消息
新做法：
预先建立索引，开盘期间载入内存
1%：uid1，uid2
2%：uid3，uid4，uid5
3%：uid6
问题：有时候嫌太及时了：频繁跌停，打开跌停，再跌停，再打开。。。的时候
内部线上记录：
4台机器。
单条消息延时 99% 小于 30秒。
下一步优化目标：99% 小于 10 秒
IM 系统最初的设计目标是为雪球上的用户提供一个聊天的功能:
送达率第一
雪球IM：Netty + 自定义网络协议
Akka ： 每个在线client一个actor
推模式：client 在线情况下使用推模式
多端同步：单账号多端可登录，并保持各种状态同步
移动互联网时代，除了微信qq以外的所有IM，都转型成了推送通道，核心指标变成了瞬间峰值性能。原有架构很多地方都不太合适了。
优化：
分配更多资源：推送账号actor池
精简业务逻辑：重复消息只存id，实时提醒内容不推历史设备，不更新非活跃设备的session列表等等
本地缓存：拉黑等无法精简的业务逻辑迁移到本地缓存
优化代码：异步加密存储，去除不合理的 akka 使用
akka这个解释一下：akka 有一个自己的 log adapter，内部使用一个 actor 来处理所有的 log event stream 。当瞬间峰值到来的时候，这个 event stream 一下子就堵了上百万条 log ，导致 gc 颠簸非常严重。最后的解决办法是，绕过 akka 的 log adapter，直接使用 logback 的 appender
线上记录：5w/s （主动限速）的推送持续 3 分钟，p99 性能指标无明显变化
7月10号我们在中国好声音上做了3期广告。在广告播出之前，我们针对广告可能带来的对系统的冲击进行了压力测试，主要是新用户注册模块，当时预估广告播出期间2小时新注册100万
压测发现 DB 成为瓶颈：
昵称检测 cache miss > 40%
昵称禁用词 where like 模糊查询
手机号是否注册 cache miss > 80%
注册新用户：5 insert
优化：
redis store：昵称，手机号
本地存储：昵称禁用词
业务流程优化：DB insert 操作同步改异步
下一步优化计划：
将 sns 系统中所有的上行操作都改成类似的异步模式
接口调用时中只更新缓存，而且主动设置5分钟过期，然后写一个消息到 mq 队列，队列处理程序拿到消息再做其它耗时操作。
为了支持失败重试，需要将主要的资源操作步骤都做成幂等。
前置模块HA：
合作方合规要求：业务单元部署到合作方内网，用户的敏感数据不允许离开进程内存
业务本身要求：业务单元本身为有状态服务，业务单元高可用
解决方案：
使用 Hazelcast In-Memory Data Grid 的 replication map 在多个 jvm 实例之间做数据同步。
java 启动参数加上 -XX:+DisableAttachMechanism -XX:-UsePerfData，禁止 jstack，jmap 等等 jdk 工具连接
关于前置模块，其实还有很多很奇葩的故事，鉴于时间关系，这里就不展开讲了。以后有机会可以当笑话给大家讲。
组合净值计算性能优化：
一支股票可能在超过20万个组合里（南车北车中车，暴风科技）
离线计算，存储计算后的结果
股价3秒变一次，涉及到这支股票的所有组合理论上也需要每 3 秒重新计算一次
大家可能会问，为什么不用户请求时，实时计算呢？这是因为“组合净值”中还包括分红送配，分股，送股，拆股，合股，现金，红利等等，业务太过复杂，开发初期经常需要调整计算逻辑，所以就设计成后台离线计算模式了。当前正在改造，将分红送配逻辑做成离线计算，股价组成的净值实时计算。接口请求是，将实时计算部分和离线计算部分合并成最终结果。
实际上，我们的计算逻辑是比较低效的：循环遍历所有的组合，对每个组合，获取所有的价值数据，然后计算。完成一遍循环后，立即开始下一轮循环。
优化：
分级：活跃用户的活跃组合，其它组合。
批量：拉取当前所有股票的现价到 JVM 内存里，这一轮的所有组合计算都用这一份股价快照。
关于这个话题的更详细内容，感兴趣的可以参考雪球组合业务总监张岩枫在今年的 arch summit 深圳大会上的分享：构建高可用的雪球投资组合系统技术实践 http://sz2015.archsummit.com/speakers/201825
最后，我们还做了一些通用的架构和性能优化，包括jdk升级到8，开发了一个基于 zookeeper 的 config center 和开关降级系统
四. 聊聊关于架构优化的一些总结和感想
在各种场合经常听说的架构优化，一般都是优化某一个具体的业务模块，将性能优化到极致。而在雪球，我们做的架构优化更多的是从问题出发，解决实际问题，解决到可以接受的程度即可。可能大家看起来会觉得很凌乱，而且每个事情单独拎出来好像都不是什么大事。
我们在对一个大服务做架构优化时，一般是往深入的本质进行挖掘；当我们面对一堆架构各异的小服务时，“架构优化”的含义其实是有一些不一样的。大部分时候，我们并不需要（也没有办法）深入到小服务的最底层进行优化，而是去掉或者优化原来明显不合理的地方就可以了。
在快速迭代的创业公司，我们可能不会针对某一个服务做很完善的架构设计和代码实现，当出现各种问题时，也不会去追求极致的优化，而是以解决瓶颈问题为先。
即使我们经历过一回将 snowball 拆分服务化的过程，但当我们重新上一个新的业务时，我们依然选择将它做成一个大一统的服务。只是这一次，我们会提前定义好每个模块的 service 接口，为以后可能的服务化铺好路。
在创业公司里，重写是不能接受的；大的重构，从时间和人力投入上看，一般也是无法承担的。而“裱糊匠”式做法，哪里有性能问题就加机器，加缓存，加数据库，有可用性问题就加重试，加log，出故障就加流程，加测试，这也不是雪球团队工作方式。我们一般都采用最小改动的方式，即，准确定义问题，定位问题根源，找到问题本质，制定最佳方案，以最小的改动代价，将问题解决到可接受的范围内。
我们现在正在所有的地方强推3个数据指标：qps，p99，error rate。每个技术人员对自己负责的服务，一定要有最基本的数据指标意识。数字，是发现问题，定位根源，找到本质的最重要的依赖条件。没有之一。
我们的原则：保持技术栈的一致性和简单性，有节制的尝试新技术，保持所有线上服务依赖的技术可控，简单来说，能 hold 住。
能用cache的地方绝不用db，能异步的地方，绝不同步。俗称的：吃一堑，长一智。
特事特办：业务在发展，需求在变化，实现方式也需要跟着变化。简单的来说：遗留系统的优化，最佳方案就是砍需求，呵呵。
H. 如何判断股票进入拉升期，如何找到进入快速拉升期的股票
股价拉升前特征之一：股价暴涨暴跌
受主力操纵的股票价格极易出现这种现象，因为在市场环境较为宽松的条件下，主力先拼命将股价推高，或者因送股等造成股价偏低的假象，在获得足够的空间后开始出货，并且利用投资者抢反弹或者除权的机会连续不断地抛出以达到其牟取暴利的目的，其结果就是股价长期下跌不可避免。
造成这种局面，同上市公司股利分配政策不完善也有一定关系，主力客观上不可能依靠现金分红来获取回报并降低风险，在二级市场赚取差价成为唯一选择。
股价拉升前特征之二：成交量忽大忽小
主力无论是建仓还是出货都需要有成交量配合，有的主力会采取底部放量拉高建仓的方式，而主力派发时则会造成放量突破的假象借以吸引跟风盘介入从而达到出货目的。
另外，主力也经常采用对敲、对倒的方式转移筹码或吸引投资者注意。无论哪一种情况都会导致成交量的急剧放大，而这些行为显然已经违反了法律的有关规定。同时由于主力的筹码主要集中在少数人手中，其日常成交量会呈现极度萎缩的状况，从而在很大程度上降低了股票的流动性。
股价拉升前特征之三：交易行为表现异常
主力走势经常出现的几种情况是，股价莫名其妙地低开或高开，尾盘拉高收盘价或偶而出现较大的买单或抛单，人为做盘迹象非常明显。还有盘中走势时而出现强劲的单边上扬，突然又大幅下跌，起伏剧烈，这种现象在行情末期尤其明显，说明主力控盘程度已经非常高。
股价拉升前特征之四：经营业绩大起大落
大多数主力的市场表现则同公司基本面有密切关系，在股价拉高过程中，公司业绩会有明显提高，似乎股价的上涨是公司业绩增长的反映，有较强的迷惑性，如对应银广夏股价连续翻番的是业绩的翻番，而这种由非正常因素引起的公司业绩是异常提高还是异常恶化都是不正常的现象，对股东的利益都会造成损害。同时很多主力在股价下跌到一定阶段后，业绩随即出现大滑坡，这种上市公司利润的数据就很值得怀疑。
股价拉升前特征之五：股东人数变化大
根据上市公司的年报或中报中披露的股东数量可以看出主力的股价完成一个从低到高，再从高到低的过程，实际也是股东人数从多到少，再从少到多的过程。主力在股东名单上通常表现为有多个机构或个人股东持有数量相近的社会公众股。
因为主力要想达到控盘目的的同时又避免出现一个机构或个人持有的流通股超过总股本5%的情况就必须利用多个非关联帐户同时买进，这种做法也给市场的有效监管增添了难度。
股价拉升前特征之六：逆市而动
一般股票走势都是随大盘同向波动，但主力往往在这方面表现却与众不同。在建仓阶段，逆市拉抬便于快速拿到筹码；在震盘阶段，利用先期搜集到的筹码，不理会大盘走势，对倒打压股价，造成技术上破位，引起市场恐慌，进一步增加持筹集中度；在拉升阶段，由于在外浮筹稀少，逆市上涨不费吹灰之力，其间利用对敲等违规虚抬股价手法，股价操纵易如反掌，而且逆市异军突起，反而容易引起市场关注，培植跟风操作群体，为将来顺利出货打下伏笔；到了出货阶段，趁大势企稳回暖之机，抓住大众不再谨慎的心理，借势大幅震荡出货，待到货出到一定程度，就上演高台跳水反复打压清仓的伎俩，直至股价从哪里来再到哪里去。
I. 如何操作股票要约收购
要约收购的程序操作：
一、持股百分之五以上者须公布信息。
即通过证券交易所的证券交易，投资者持有一个上市公司已发行的股份的百分之五时，应当在该事实发生之日起三日内，向国务院证券监督管理机构、证券交易所作出书面报告，通知该上市公司，并予以公告。
二、持股百分之三十继续收购时的要约。
发出收购要约，收购人必须事先向国务院证券监督管理机构报送上市公司收购报告书，并载明规定事项。
三、终止上市。
收购要约的期限届满，收购人持有的被收购上市公司的股份数达到该公司已发行的股份总数的百分之七十五以上的，该上市公司的股票应当在证券交易所终止上市。
四、股东可要求收购人收购未收购的股票。
收购要约的期限届满，收购人持有的被收购公司的股份达到该公司已发行的股份总数的百分之九十以上时，其余仍持有被收购公司股票的股东，有权向收购人以收购要约的同等条件出售其股票，收购人应当收购。
五、要约收购要约期间排除其他方式收购。
六、收购完成后股票限制转让。
收购人对所持有的被收购的上市公司的股票，在收购行为完成后的六七月内不得转让。
七、股票更换。
通过要约收购方式获取被收购公司股份并将该公司撤销的，为公司合并，被撤销公司的原有股票，由收购人依法更换。
八、收购结束的报告。收购上市公司的行为结束后，收购人应当在十五日内将收购情况报告国务院证券监督管理机构和证券交易所，并予公告。
(9)如何查询股票要约进程扩展阅读
要约收购报告书
以收购要约方式应当按照规定编制要约收购报告书。收购人应当自公告收购要约文件之日起三十日内就本次要约收购在中国证监会指定报刊上至少做出三次提示性公告。
一、编制要约收购报告书的一般要求
1.引用的数据应提供资料来源，事实应有充分、客观、公正的依据;
2.引用的数字应采用阿拉伯数字，货币金额除特别说明外，应指人民币金额，并以元、千元或万元为单位;
3.收购人可根据有关规定或其他需求，编制要约收购报告书外文译本，但应保证中、外文本的一致性，并在外文文本上注明：“本要约收购报告书分别以中、英(或日、法等)文编制，在对中外文本的理解上发生歧义时，以中文文本为准”;
4.要约收购报告书全文文本应采用质地良好的纸张印刷，幅面为209×295毫米(相当于标准的A4纸规格);
5.不得刊载任何有祝贺性、广告性和恭维性的词句。
二、编制要约收购报告书的其他要求
1.收购人属于一致行动人或者实际控制人的，参与一致行动或存在实际控制关系的各成员可以推选其中一名成员以全体成员的名义统一编制并提交要约收购报告书，各成员的法定代表人(或者主要负责人)均应在报告上签字、盖章。
2.由于商业秘密(如核心技术的保密资料、商业合同的具体内容等)等特殊原因，某些信息确实不便披露的，收购人可向中国证监会申请豁免，并在要约收购报告书中予以说明。
3.在不影响信息披露的完整性和不致引起阅读不便的前提下，收购人可采用相互引证的方法，以避免重复和保持文字简洁。
4.要约收购报告书的文字应简洁、通俗、平实和明确，格式应符合相关要求。在指定报刊刊登的要约收购报告书最小字号为标准6号字，最小行距为0.02.
5.收购人应当按照《收购办法》的规定将要约收购报告书摘要及要约收购报告书刊登于至少一种中国证监会指定的报刊，并根据证券交易所的要求刊登于指定网站，或者提示刊登该报告的收购人或上市公司的网址。收购人应当将要约收购报告书和备查文件备置于上市公司住所和证券交易所，以备查阅。
6.收购人可将要约收购报告书或摘要刊登于其他网站和报刊，考|试/大 但不得早于在中国证监会指定报刊和网站的披露。
7.收购人董事会及全体董事(或者主要负责人)应保证要约收购报告书内容的真实性、准确性、完整性，并承诺其中不存在虚假记载、误导性陈述或重大遗漏，并就其保证承担个别和连带的法律责任。
8.收购人的律师受收购人委托编制要约收购报告书，应对要约收购报告书及相关文件进行核查和验证，并出具法律意见书，并就其负有法律责任的部分承担相应的责任。
9.收购人聘请的律师、注册会计师、财务顾问及其所服务的专业机构应书面同意收购人在要约收购报告书中引用由其出具的专业报告或意见的内容。